第2回 Hyper-V 2.0のライブ・マイグレーション設計のポイント：Hyper-V 2.0実践ライブ・マイグレーション術（2/4 ページ）

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

■ネットワーク
　ライブ・マイグレーションの構成で最もポイントとなるのが、ネットワーク・インターフェイス（NIC）のポート数だ。実運用環境を考慮すると、下表のように最低6ポートは用意しておきたい。なお、一部のサーバ・ベンダはHyper-VでのNICチーミング（複数のNICをまとめて1つのNICのように扱い、帯域幅や冗長性を向上させる技術）をサポートしていなかったり、制約を設けていたりするので注意が必要だ。

	用途	接続先	NICチーミング	必要な帯域幅（例）
Port 1 Port 2	・ゲストOSのサービス用	仮想マシン	実施	2Gbit/s〜
Port 3 Port 4	・システム管理用 ・バックアップ用 ・WSFCハートビートの副回線 ・CSV通信の副回線	親パーティション	実施	1Gbit/s〜
Port 5 Port 6	・ライブ・マイグレーション用 ・WSFCハートビートの主回線 ・CSV通信の副回線		実施	2Gbit/s〜
実運用環境におけるライブ・マイグレーションのネットワーク構成 テスト環境の場合、NICは2ポート以上あればライブ・マイグレーションが構成できる。しかし、実運用番環境では帯域幅や冗長性を考慮して最低でも6ポートは用意しておきたい。なお、Windows Server 2003まではハートビート回線に対してNICチーミングを利用できなかったが、Windows Server 2008からは可能となっている（NICドライバ側の利用可否も確認が必要）。 * 別ポートにバックアップ回線を敷いているためNICチーミング設定は不要

　この表では、「ゲストOSのサービス用」と「ライブ・マイグレーション用」の必要な帯域を2Gbit/s以上と記載している。

　前者の理由は、マルチコア化の進んだ昨今のサーバ・マシンでは、1台当たり10台前後のサーバを集約するためである。10台集約した場合、1台当たり100Mbit/sを消費するとして合計1Gbit/sの帯域が必要となるが、ギガビット・イーサネット（GbE）の実効速度はそれに満たないため、Link Aggregation（IEEE802.3ad）方式によるNICチーミングなどを利用して2Gbit/sは用意した方がよいだろう。業務側がより速いスピードを要求する場合は、それに応じた帯域増強が必要となる。

　後者の理由は、ライブ・マイグレーションの帯域と所要時間が反比例するためである。第1回で解説したように、このネットワークはメモリ・データの転送に利用されるため、帯域が狭いと所要時間が増加し、ライブ・マイグレーションの処理自体も失敗するケースが増えてしまう。また、ライブ・マイグレーションは複雑な処理であるため、実行中のホストは高負荷状態となる。トラブルを防ぐためにも2Gbit/s以上は用意することをお勧めしたい。

ライブ・マイグレーション用ネットワークの消費帯域
ライブ・マイグレーションは複雑な処理であり、実行中のホストは高負荷状態となる。トラブルを防ぐためにも2Gbit/s以上の帯域を用意しておきたい。この画面の例では、実際に980Mbit/sの帯域が消費されており、ギガビット・イーサネット（GbE）の実効速度では足りないことが分かる。
　 （1）2Gbit/sで接続していながら、ネットワークの使用率は49.01％と、980Mbit/sの帯域が消費されていることが分かる。

■ストレージ
　ライブ・マイグレーションを利用する場合、仮想マシンのデータ格納用にWSFCとCSVに対応した共有ストレージが必要となる。ストレージを選定する場合はHyper-V 2.0とCSVに対応していることを確認するようにしよう。技術的にはSCSI-3のSPC-3（SCSI Primary Commands-3）コマンドに対応したストレージということになるが、Windows Server 2003ではSPC-3は要件になかったため、古い世代のストレージを活用したり、相乗りを予定したりしている場合は特に注意しよう。

　ストレージの接続方式はFibre Channel（ファイバ・チャネル: FC）や共有型のShared SAS（SAS）、iSCSIの3種類のインターフェイスから選択することになる。このうちiSCSIは、現在の主流が1Gbit/sであり、帯域不足で性能劣化を起こしかねない。iSCSIを選択する理由がコスト目的というのであれば、Hyper-V 2.0におけるハードウェア選定のポイントでも紹介したShared SASの採用をお勧めする。

　なお、Fibre Channel、Shared SAS、iSCSIのいずれの接続方式を取っても、ストレージ接続用にホスト・バス・アダプタ（HBA）やネットワーク・インターフェイス（NIC）が必要となる。これらは冗長性を考慮して最低2ポートは用意しよう。

■ディスク容量の見積もり
　ディスク容量の見積りは、各仮想マシンの「ディスク割り当て容量＋メモリ割り当て容量+100Mbytes」の合計を目安にするとよい（スナップショットを利用しない場合）。

　ポイントとなるのが、仮想マシンの実行中は割り当てたメモリと同サイズのファイルがディスク上に作成されるということだ。ここを意識し忘れると、ディスクの空き容量が不足して仮想マシンを立ち上げられないといった設計ミスに陥ってしまうので、気を付けよう。

仮想マシンに割り当てたメモリと同サイズのファイルが作成される
仮想マシンの実行中は、毎回自動的に作成されるので注意しよう。この画面では、仮想マシンに割り当てた4Gbytesのメモリと同容量のファイルが作成されている（（1））のが分かる。

■仮想ディスク
　Hyper-V 2.0では、仮想マシンのディスクの実体である「仮想ディスク」として、下記の4つのモードから選択できる。

[↑速い]
・パススルー・ディスク
・VHD（容量固定）
・VHD（容量可変）
・VHD（差分ディスク）
[↓遅い]

　これら４つのモードのうち、最もI/O性能が高いのはパススルー・ディスク（物理的なディスク・ドライブを直接使う形態）であるが、親パーティションを介さないためCSVでは管理できない。つまり、ライブ・マイグレーションで利用できないので注意しよう。

　またHyper-V 1.0では、クイック・マイグレーションを利用する場合に、仮想マシンとLUN（論理ユニット番号）が1:1に制限されていた。Hyper-V 2.0では、CSVを利用することでこの制限は撤廃されている。なお、クラスタ・ファイル・システムを利用している他製品と違い、CSVはメタデータの排他制御にSCSI Reservationを利用していないため（詳細は第1回を参照）、1つのLUNに格納する仮想マシンの推奨数は、特に明言されていないものの20〜30台格納しても支障はないと推測される。

LUN当たりの仮想マシン数
Hyper-V 2.0では、CSVを利用することで1つのLUNに複数の仮想マシンが格納できるようになった。

ブレード・サーバを採用する場合は注意が必要

　もし、流行のブレード・サーバを検討している場合は、搭載できるI/Oポートの最大数に注意しよう。ここまで説明したとおり、実運用環境を意識するとストレージ用に2ポート、ネットワーク用に6ポートの合計8ポートが推奨されるが、ケースの小さなブレード・サーバではこのようなI/Oポートを8つも搭載できないものが多い。

　このような場合、回避策として10Gbit/sに対応したNICを利用して、複数のVLANに論理分割するタグVLAN機能を利用する方法が考えられる。しかし、Hyper-Vには帯域制限機能がないため、あるVLANポートで10Gbit/sの帯域を使い切ってしまい、ほかのVLANポートが必要とする帯域を保てないといったトラブルが発生してしまう可能性がある。

　また、タグVLANはWindowsの標準機能ではないため、NICドライバの機能を利用することになるが、NICドライバによってWSFCと相性問題が発生したり、そもそもWSFCをサポートしていなかったりするものもあるので注意しよう。

　こういった問題に対応するために、一部ベンダのブレード・サーバでは、10Gbit/sのNICをハードウェア・レベルで分割するテクノロジが実装されている。例えば、日本ヒューレット・パッカードの主要なブレード・サーバでは「HP Flex-10」という技術で、内蔵される2つの10Gbit/s NICを8つのNICに分割できる。分割はハードウェア・レイヤで実施されるため、WSFCなどのOSレイヤに制約が発生しないほか、分割された各NICに任意の帯域を割り振ることが可能だ。

日本ヒューレット・パッカードの「HP Flex-10」テクノロジ
ブレード・サーバに内蔵される2つの10Gbit/sを8つのNICに分割する。分割はハードウェア・レイヤで行われるため、デバイス・マネージャを見ると、あたかも複数のNICが搭載されているように認識される。WSFCなどのOSレイヤとも相性がよく、分割された各NICに任意の帯域を割り振ることもできるため、Hyper-Vの弱点が補完可能だ。

• HP Flex-10テクノロジ（日本ヒューレット・パッカード）