【仮想化基盤】クラスタ間のVM片寄せを想定内に収める、Shared-Nothing vMotion
前回の記事では、設計値（最大値）ベースの管理が招く「偽の逼迫」の構造を解説しました。実使用値を正しく評価すると、資料上は限界に見えるクラスタであっても、現実のハードウェアにはまだ十分な余裕があるケースがほとんどです。
スポンサーリンク
この“現実の余力”を活かしてインフラの最適化へ踏み出す際、次に検討されるのが 異なるクラスタ間へのVM片寄せ（集約） です。物理ホストやライセンス費用を抑制するための合理的な施策ですが、「共有ストレージを持たないクラスタ間で、仮想マシンを無停止で移動できるのか？」と疑問に思われるかもしれません。
結論として、現在のハイパーバイザーには Shared-Nothing vMotion という、非共有ストレージ環境でも無停止でVMを丸ごと移動できる強力な機能が標準で備わっています。ただし、実務で安全に運用するためには、技術・運用・法規の3つの変数を同時にコントロールする設計が不可欠です。
本記事では、クラスタ間のVM片寄せを「すべて想定内」に収めるための設計思想を解説します。
1. 実使用値が示す“次の合理的アクション”
多くのエンタープライズ環境では、各システムが実際に消費するリソースは設計値の20〜40%程度に収まります。紙の上では逼迫して見えるクラスタでも、物理ホストの平均利用率を評価すると、驚くほどの余剰リソースが眠っていることが分かります。
この稼働実態を正しく把握したとき、次にとるべき合理的なアクションが 稼働率の低いクラスタへのVM集約 です。
VM片寄せがもたらす効果
- 維持コストの削減：物理サーバー削減に伴う保守費・ラック費・電気代の最適化
- ライセンス費用の圧縮：CPUソケット数やコア数に紐づくライセンスを最小化
- 資産の有効活用：高性能ホストを新規プロジェクトや検証環境へ再配分
ただし、クラスタ間の移動は同一クラスタ内の通常vMotionとは異なり、ネットワーク・運用ルール・ライセンスという3つのドメインが複雑に絡みます。
2. 異なるクラスタ間の無停止移行を支える「Shared-Nothing vMotion」の仕様
異なるクラスタ間でVMの片寄せ（集約）を検討する際、技術的な核となるのが Shared-Nothing vMotion です。
仮想化基盤の運用において馴染み深い「Storage vMotion」と混同されがちですが、この2つの機能は「移動させる対象のリソース」および「移行時のシステムリソースの消費傾向」が根本的に異なります。すべてを想定内に収めるための前提知識として、その違いを整理します。
📊 Storage vMotionとShared-Nothing vMotionの比較
| 項目 | Storage vMotion | Shared-Nothing vMotion (ホストとストレージの両方を変更) |
|---|---|---|
| 移動させるリソース | 💾 ストレージ（仮想ディスク）のみ | 💻 ホスト（CPU/メモリ） ＋ 💾 ストレージ の両方 |
| 実行ホストの変更 | なし（同一の物理サーバー上で稼働） | あり（別の物理サーバーへ移動） |
| データの移動経路 | Aデータストア ➡ Bデータストア | Aホスト＋Aデータストア ➡ Bホスト＋Bデータストア |
| 主なユースケース | ・ストレージ筐体のメンテナンス ・データストアの空き容量枯渇対策 ・SSDへのリプレイスに伴う高速化 | ・異なるクラスタ間でのVM片寄せ ・古いハードウェアからの無停止引っ越し |
| 共有ストレージ要件 | 不要（移動元と移動先が見えていればOK） | 不要（ネットワークさえ繋がっていればOK） |
| 移行時のシステム負荷 | 低（ストレージ専用ネットワーク内） | 相応の負荷（LAN/vMotionネットワーク経由） |
💡 概念の整理：リソース移動の範囲
- Storage vMotion（ストレージのみの変更）
仮想マシンを処理するCPUやメモリ（実行ホスト）は同じ物理サーバーに留まったまま、仮想ディスクの配置場所（データストア）だけを別のボリュームへと移行させるオペレーションです。 - Shared-Nothing vMotion（ホストとストレージの同時変更）
移行元と移行先の間で何も共有していない、全く別のクラスタに所属する物理サーバーおよびストレージへと、システムを停止することなく仮想マシンを丸ごと移行させる高度な機能です。
🔍 物理設計が最適化されていても考慮すべき「リソースの配分」
Shared-Nothing vMotionは、共有ストレージがなくてもネットワーク疎通さえあれば無停止でVMを移動できる強力な機能です。vMotion専用NICや専用VLANで本番通信と帯域を分離している環境では、ネットワーク競合を心配する必要はほとんどありません。
ただし、移行時に問題となるのは帯域ではなく ホストCPU と ストレージIOPS の挙動です。Shared-Nothing vMotionでは転送効率を高めるためにデータの圧縮・解凍処理が走り、移行先ホストのCPUを一定量消費します。もし移行先がすでに高負荷であれば、CPU Ready Timeの上昇を招き、既存VMのパフォーマンスに影響する可能性があります。
また、転送されたデータは移行先ストレージへ一気に書き込まれるため、コントローラやキャッシュに負荷が集中し、同じデータストアを利用する他VMのレスポンスに影響することがあります。
そのため、ネットワーク分離という「点」の設計だけでなく、移行先ホストのCPU余力やストレージ全体の負荷といった「面」での利用状況を踏まえ、夜間・休日などシステム負荷が低い時間帯を作業ウィンドウに選定することが重要です。
3. 全てを想定内に収める！移行を阻む「アフィニティルール」の壁とライセンスの地雷
Shared-Nothing vMotionの実施スケジュールを、ハードウェアやストレージの負荷が低い「最適な時間帯」を選定したとしても、まだクリアすべき大きな壁があります。それが、仮想化基盤の運用ルールである「アフィニティルール（Affinity Rules）」と、法的な制約である「OSのライセンス」です。
技術的に「ボタンが押せるか・動かせるか」だけでなく、事前の設定やコンプライアンスまでを完璧にコントロールできている必要があります。
🛑 3-1. ルール解除を怠った際の「Must」と「Should」の挙動
一部の重要VMにおいては、特定の物理ホストに固定するためにアフィニティルール（またはアンチアフィニティルール）が適用されている場合があります。これらを解除・変更せずにShared-Nothing vMotionを実行しようとした場合、ルールの強制力の強さ（MustかShouldか）によって挙動が全く異なります。
① 【Must（必須ルール）】の場合：ウィザードで即座にブロック
条件が「〜しなければならない（Must）」という強い強制力で設定されている場合、移行ウィザードの互換性チェック（Compatibility）の段階で、赤い「×」エラー（Virtual machine… would violate an affinity rule）が表示されます。「次へ」のボタンがグレーアウトするため、Shared-Nothing vMotion自体を実行できません。
② 【Should（努力ルール）】の場合：警告をスルーして実行できてしまう罠
一方で、条件が「〜することが好ましい（Should）」という緩い設定、あるいはVM同士を分散させるルール（例：ADサーバーの1号機と2号機を別ホストに分けるなど）の場合、挙動はさらに厄介になります。
ウィザードでは黄色の「！」警告が出るものの、「次へ」が進めるため、システム的には実行できてしまいます。しかし、移行が完了した直後に、移動元のクラスタに残されたペアVMとの間でルール違反状態が発生します。
もしDRS（自動最適化）が有効な環境であれば、「ルールを守るために、DRSがVMを元のクラスタへ勝手に引き戻そうとする（vMotionのループ・競合）」といった想定外の怪奇現象や、ネットワーク・ホストCPUの無駄遣いが発生する原因になります。
鉄則： 全てを想定内に収めるため、ルールの強弱に関わらず、「事前のルール解除 ➡ 移行 ➡ 移行先での再設定（ルールは自動追従しない）」のステップを踏む運用設計が必要です。
💵 3-2. 最大の地雷：Windows Serverライセンスと「移行時間帯」の盲点
そもそも、なぜアフィニティルールでVMをホスト固定する運用が必要なのでしょうか？その最大の理由の1つが「Windows Serverのライセンス問題」です。
Windows Server（Standardエディション等）のライセンスは、仮想マシンではなく、それが動作する「物理ホストの物理コア数」に対して割り当てます。ライセンスを購入していないホストへDRS等でVMが勝手に移動（vMotion）すると、その瞬間にライセンス違反（コンプライアンス違反）になるため、アフィニティルールで厳しく縛っているのです。
ここでインフラ設計者が絶対に忘れてはならないのが、「移行作業時間帯の一時的な状態」です。
📢 「数時間だけ退避させる」でも、即アウトの原則
ストレージの片寄せ要請を受け、「数時間だけ一時的に異なるクラスタへ退避させるだけだから」という理由でShared-Nothing vMotionを実行する場合、移行先クラスタに十分なWindowsライセンスがプールされていなければ、移行を開始（パケット転送を開始）した瞬間から、移行期間中を含めて完全に「ライセンス違反状態」になります。
マイクロソフトのライセンス監査において、「メンテナンス時間帯の一時的な退避だからセーフ」という免責は一切存在しません。
💡 合法的に想定内に収める2つのアプローチ
このコンプライアンス上の地雷を完全に回避し、すべてを想定内に収めるには、以下のいずれかの設計が必要です。
- 移行先ホストにもあらかじめライセンスを重複して割り当てておく
- SA（ソフトウェアアシュアランス）やサブスクリプションを契約し、「ライセンスモビリティ（90日移動制限の免除）」の権利を行使する（※この場合も、移動後はライセンス台帳上の管理を移動先に変更する必要があります）
技術的に「無停止で移動できたから成功」ではないのです。vCenterの監視画面（技術）だけでなく、自社が購入したライセンスの台帳（契約）を突き合わせて初めて、設計は完了します。
4. トラブルゼロで片寄せを成功させる4つの実践ステップ
ここまで解説してきた「Shared-Nothing vMotionの仕様」「アフィニティルールの挙動」「OSライセンスの制約」を踏まえ、異なるクラスタ間でのVM片寄せ（集約）を安全かつ確実に完遂するための、具体的な4つの実践ステップを定義します。
技術、運用、法規のすべてを調和させ、想定外の事象を排除するためのロードマップとしてご活用ください。
ステップ1：事前確認（仕様・ルール・ライセンス）
- 対象VMのアフィニティルールを洗い出す
- 移行先ホストのライセンス状況を確認
- EVC互換性、VLAN定義の一致を確認
ステップ2：最適な作業時間帯の選定
- 移行先ホストのCPU余力
- ストレージIOPSの余裕
- 業務・バッチ・バックアップのピークを避ける
- 大容量VMは段階的に移行する
ステップ3：ルール解除と移行の実行
- アフィニティルールを事前に解除
- Shared-Nothing vMotionを慎重に実行
ステップ4：移行先でのルール再定義と台帳更新
- 移行先クラスタで必要なルールを再設定
- ライセンス台帳を更新
最後に
Shared-Nothing vMotionは、非共有ストレージ環境でも無停止でVMを移動できる強力な機能です。しかし、その真価を発揮するには、技術・運用・法規の3つの変数を調和させる設計が不可欠です。
- ホストCPUとストレージIOPSの負荷特性
- アフィニティルールのMust/Shouldによる挙動
- Windows Serverライセンスの割り当て規則
これらは移行を阻む障害ではなく、システムを安全に運用するための“設計の変数”です。
技術的に移行が成功しただけでは設計は完了しません。 vCenterのステータスと、企業のライセンス台帳・運用ルールが完全に整合したとき、初めて「すべてが想定内に収まった」状態になります。
稼働実態に基づいた収容設計と確実な運用フローこそが、仮想化基盤のポテンシャルを最大限に引き出し、ビジネスの最適化に貢献するインフラエンジニアの価値です。
✈️ [こちらもcheck!] 【仮想化基盤】 設計値ベースのキャパシティ管理が正しく機能しない理由
