第4回 運用に役立つHyper-Vライブ・マイグレーションのノウハウ：Hyper-V 2.0実践ライブ・マイグレーション術（4/5 ページ）

[小川大地，日本ヒューレット・パッカード]

　ライブ・マイグレーションを構成する場合、CSV（クラスタ共有ボリューム）やメモリ転送、WSFCのハートビートなどさまざまな用途のネットワークを追加で用意する必要がある。トラブルを未然に防ぐには、それぞれをきちんと理解し、管理していかなければならない。

　ここでは、ネットワーク周りのTIPSとして、簡単なチューニングとよくあるトラブルの原因・対処方法について解説する。

■メモリ転送用ネットワークの優先順序を調整する

　WSFCではWindows Server 2003のクラスタ・システムであるMSCSと違い、さまざまな設定が自動化されている。ライブ・マイグレーションのメモリ転送に利用するネットワークも自動設定が行われるが、これについては手動で指定したいと考える管理者も多いだろう。メモリ転送では大量のデータが流れるため、サービス・ネットワーク側が利用されると業務に影響を及ぼす危険性があるためだ。

　メモリ転送に利用するネットワークは、WSFCマネージャ上で仮想マシン・リソースのプロパティ画面から設定できる。優先度を指定することはもちろん、除外するように設定することも可能だ。

「ライブ マイグレーション用ネットワーク」の画面
ネットワークごとに優先度や除外設定ができる。この画像では、ハートビート用ネットワーク「192.168.0.0」を最優先に指定し、iSCSI専用ネットワーク「192.168.100.0」を除外に設定している。
　 （1）「192.168.100.0」のチェックを外し、除外に設定する。

■CSV通信用ネットワークの優先順序を調整する

　ライブ・マイグレーション用に利用されるネットワークとして、メモリ転送用のネットワークのほかにCSVが内部通信するネットワークがある。ディスクのメタデータに対する更新や経路障害が発生した場合に利用されるネットワークだ（詳細は第1回を参照）。

　通常、CSVがどのネットワーク･インターフェイス（NIC）を利用するかについては、WSFCがメトリクスを設けて自動判断しているが、管理者がPowerShellを介して手動調整することも可能だ。

• Hyper-V: Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2［英語］（Microsoft TechNetサイト）

　大まかな手順は上記のTechNetサイトに記載されているとおりであるが、筆者の環境で実際に試した画面を下記に掲載する。

CSV通信に使用するネットワークの優先度を変更する
　 （1）「FailoverClusters」PowerShellモジュールをロードする。このモジュールはWindows Server 2008 R2のWSFCもしくはリモートサーバ管理ツール（RSAT）に含まれている。RSATについてはTIPS「RSATツールでWindows Server 2008をリモート管理する」参照。
　 （2）現在の優先順序を確認する。「Metric」の数値の小さいものほど優先度が高い。また,
「Role」列は次の画面の各選択項目を意味しており、値が「0」の場合はCSV通信では利用されない（Metricsの数値は無視される）。→［A］へ
　 （3）10.2.57.0ネットワークに手動でMetric数値を設定する。
　 （4）あらためて優先順序を確認する。（3）によって10.2.57.0ネットワークのAutoMetricが解除され、最も小さな数値となっていることが分かる。
　 （5）優先順序を自動に戻したい場合は、AutoMetricの値に「1」をセットすればよい。

［A］

CSV通信に使用するネットワークの優先度
上画面における「Role」列は、ネットワークのプロパティにおける各選択項目を意味している。各Roleに該当する選択項目は、以下のとおり。
　（1）Role＝1
　（2）Role＝3
　（3）Role＝0。この場合、Metricsの数値は無視され、CSV通信では利用されない。

　なお、第1回で解説したとおり、CSVはSMBプロトコルで通信するため「Microsoftネットワーク用クライアント」「Microsoftネットワーク用ファイルとプリンター共有」といったWindowsのSMB関係のプロトコルは有効にしなければならない。CSV周りの動きが怪しかったり、エラー・メッセージが多発したりする場合は、SMBプロトコルが無効になっていないか確認してみよう。

■移動後にネットワークがつながらない！？ ―原因と対処方法

　設定が不十分な場合、移動処理に失敗したり、仮想マシンの移動後にネットワークが通信できなくなったり、といったトラブルに見舞われることがある。こういったトラブルの主な原因と対処方法について説明しておこう。

移動先の仮想ネットワークへの接続に失敗している状態
左上はWSFCマネージャの画面、右下はHyper-Vマネージャの設定画面だ。
　 （1）WSFCマネージャの［最近のクラスター イベント］にこのようなエラーが表示される。
　 （2）Hyper-Vマネージャでは、［ネットワークアダプター］が「構成エラー」となる。

（1）仮想ネットワーク名の不一致によるトラブル

　原因の1つとして、移動元ホストで利用していた仮想ネットワーク名が、移動先ホスト上に存在しなかったケースが考えられる。仮想マシンは、これまで接続していた名前の仮想ネットワークに移動後も接続しようとする。第3回でも説明したとおり、クラスタ内の各ホストは仮想ネットワークの名前を統一しておかなければならない。

仮想ネットワーク名の不一致によるトラブル
クラスタ内の各ホストは、仮想ネットワークの名前を統一しておく必要がある。

（2）不十分な仮想マシンの構成変更によるトラブル

　もう1つ考えられるケースとして、Hyper-Vマネージャで行った仮想マシンの設定変更が、WSFC側に反映されていないというものがある。

　仮想マシンの構成情報はHyper-Vマネージャだけでなく、WSFC側でも一部を所持している。通常は、仮想マシンを作成・登録する際に実行される「高可用性ウィザード」によってWSFC側に反映されるが、Hyper-Vマネージャで構成情報を変更してしまうとWSFC内の情報と矛盾するため、移動処理に失敗してしまうのだ。

　このトラブルを未然に防ぐためには、WSFC登録後にHyper-Vマネージャで仮想マシンの構成変更を行った場合、その変更をWSFCにも反映させなければならない。WSFCマネージャ上で［仮想マシンの構成を最新の状態に更新］を実行しよう。

仮想マシンの構成を最新の状態に更新
Hyper-Vマネージャで仮想マシンの構成変更を行った場合は、その変更をWSFC側にも反映させなければならない（（1））。忘れがちなので気を付けるようにしたい。

　今回紹介したトラブルは、実はSystem Center Virtual Machine Manager（SCVMM）を利用している場合には発生しない。SCVMMは複数のホストを統合的に管理するため、仮想ネットワーク名やMACアドレスはホスト単位ではなく、SCVMM管理下のホスト全体で妥当性チェックが行われる。また、仮想マシンの構成変更の際も、Hyper-VマネージャとWSFCマネージャで矛盾が発生しないよう、フロントエンドとして双方に反映してくれる。

　なお、統合管理製品はSCVMMだけではない。Hyper-VやWSFCはWMI（Windows Management Interface）やPowerShellなどのAPIを公開しているため、サーバ・ベンダなどが提供しているサード・パーティ製の製品でも統合管理を行うことができる。SCVMMも、バックグラウンドでは多くの処理をPowerShellベースで実行している。