サーバー仮想化技術は、プライベートクラウド環境を実現する際の必要条件の一つです。今回はサーバー仮想化技術について、ネットワークの視点から、その要件、検討上の注意点、検討の方針を解説します。
仮想化技術の導入とネットワークに求められる要件
ネットワークからサーバー仮想化技術を見た場合、従来提供している機能と大きな違いはありませんが、通信対象が「物理サーバー」から「仮想サーバー」に変化し、物理的に接続したサーバーは仮想マシンのリソースプールと見なされます。
リソースプール上で仮想サーバーが移動(仮想マシンモビリティ)し、性能の最適化や可用性、柔軟性、俊敏性を実現します。仮想サーバー環境を導入する際、仮想マシンの移動は必須要件となります。その実現のためにネットワークに求められる要件（=仮想マシンモビリティの制約）として、「フラットなレイヤー2ネットワーク」と「統合ストレージネットワーク」が求められます。
フラットなレイヤー2ネットワーク
フラットなレイヤー2ネットワークでの仮想化技術に対する過度な期待とその現実
フラットなレイヤー2ネットワークは、データセンター内だけでなく、広域（＝データセンター間）で利用することもできます。こうしたことを検討しているとき、「仮想マシンのライブマイグレーションを活用して無停止の災害対策が実現できるのでは？」といった議論や、「複数あるデータセンター（拠点）内のサーバーすべてをリソースとして活用できるのでは？」といった議論をすることが多いです。
サーバー仮想化技術の視点のみで検討すると確かに実現可能なように見えますが、ネットワーク視点、ストレージ視点から考えると非現実的です。
まず、IPネットワークの視点から考えると、各仮想マシンがローカルサイトで保持しているIPアドレスやVLAN、VRF（Virtual Routing and Forwarding）の設定は、仮想マシンのライブマイグレーション機能によりマイグレーション後も維持されます。同時にデフォルトルーターも引き継いでしまいます。
つまり、ライブマイグレーション機能により仮想マシンが移動しても、IP通信に利用するルーターはローカルサイトにあるため、サイト間ネットワークを経由して通信を行うことになります。この状況は、サイト間ネットワークに対するトラフィックの増加とレスポンス低下を招きます。
また、仮想マシンが外部ストレージにデータを保持している場合、データコピーはストレージ側で行われ、かつ非同期コピー機能が用いられることから、仮想マシンがライブマイグレーションされても、その仮想マシンが保持するデータはローカルサイトに残っています。
仮にリモートサイトのボリュームに切り替えたとしても、マイグレーション時と全く同じ状態とは限りません。たとえ遠隔地とのネットワークとしてフラットなレイヤー2ネットワークが導入された場合でも、災害対策の視点では従来の災害対策環境と同様の切り替え運用が必要となります。
フラットなレイヤー2ネットワーク環境での運用管理上の変化の一例
フラットなレイヤー2ネットワークの広域化に伴い、物理的に距離が離れた環境にあるリソース(物理サーバー)が一つのリソースプールとして管理される場合があります。とはいえ、前述の通り実際に仮想マシンをマイグレーションする先として、遠隔のリソースを使うことは非現実的です。
同一の管理対象内ではあるが、サーバー名からロケーション判断(＝ライブマイグレーションしていいリソースなのかどうか)ができるような命名規則の検討など、従来は意識しなかった部分の検討が運用上の混乱を避けるために必要です。
フラットなレイヤー2環境での災害対策環境とは？
フラットなレイヤー2ネットワークが広域で実現できた場合においても、従来の災害対策や拠点の役割は変わりません。拠点間でのライブマイグレーションを検討する場合には、近距離で検討し、災害対策環境は非常時のみの利用を前提として遠隔地に配置すべきです。
