10GbEと1GbEを比較すると、性能は10倍なのに対し、コストは数倍程度で済む。となれば、1GbEを10本近く用意するよりも10GbEを採用してしまった方が安価で構成もシンプルだ。
これを踏まえ、10GbEをベースにしてHyper-Vのネットワーク設計を実践してみよう。ちなみに、冒頭で紹介した米マイクロソフトPFEチームも10GbEの利用を例に挙げている。
表1「中規模クラスのHyper-V本番サーバで必要となるネットワーク」を思い出してほしい。1サーバあたりに用意したい帯域は最低8Gbps、IPストレージを利用する場合で13Gbpsと解説した。帯域的には前ページの図7「2013年より出荷が開始された10GBase-T製品」のような2ポート10GbE NICが1枚あれば十分だが、これではもう1つの要件である系統数を達成できない。
この課題をOS(ソフトウェア)側で対応するには、仮想マシン用ネットワークの分離にも利用する「VLAN」を使う。実際にどのように設定するか、一般的な構成例をベースに解説しよう。
次のような構成のVLANを想定する。
■接続先:仮想マシン
・仮想マシン用ネットワーク: VLAN ID=100〜200
■接続先:親パーティション
・ホスト・アクセス用ネットワーク: VLAN ID=10
・WSFCハートビート+CSV通信: VLAN ID=20
・ライブ・マイグレーション用: VLAN ID=30
当然ながら、回線障害に備えてNICチーミングも必要だ。Windows Server 2012以降ではOS標準の「LBFO(負荷分散とフェイルオーバ)」機能でNICチーミングを行う。またLBFOはNICチーミングだけでなく、VLAN分割の際も利用する。上記例での設定手順を「素直に」考えると、次のようになるだろう。
しかしながら、実はこの設計は不正解だ。例外はあるものの、大半のHyper-V環境では動作しないだろう。なぜなら、VLAN IDが10、20、30であるかどうかを識別するために、LBFOを通過するすべてのパケットからVLANタグ(VLAN ID)を剥がしてしまうためだ。パケットに付いていたVLAN IDがセカンダリ・インターフェイスにない場合は、既定のルート(プライマリ・インターフェイス)を通じて仮想スイッチに届くものの、VLANタグはすでに剥がされてしまっているために、仮想スイッチ上でVLAN IDの識別ができず、あて先の仮想マシンと通信できない。
VLAN設定を行った仮想マシンと正しく通信させるには、その識別を担う仮想スイッチまでVLAN IDが残されていなければならない。冒頭の米マイクロソフトのベスト・プラクティスにも記述されているが、LBFO環境でこれを行うにはセカンダリ・インターフェイスを作成せず、既定のプライマリ・インターフェイスだけで、すべてのパケットを仮想スイッチに転送するように構成しておく必要がある。VLAN IDの識別を多段で行うことはできない。
具体的には、WSFCハートビートやiSCSIといった親パーティションあてパケットについてもいったん仮想スイッチに送り、仮想スイッチのVLAN ID識別機能を利用する必要がある。ただし図11「Hyper-Vマネージャによる親パーティションへのスイッチ・ポート作成」のように、GUI(Hyper-Vマネージャ)では親パーティション向けの仮想スイッチ・ポートは1個しか作成できないが、PowerShellを使えば複数作成することが可能だ。
PowerShellコマンドで、仮想スイッチに親パーティション向けポートを作成するには次のようにする。
Add-VMNetworkAdapter -ManagementOS -Name <識別名> -SwitchName <仮想スイッチ名>
作成したポートにVLAN IDを設定するには次のようにする。
Set-VMNetworkAdapterVlan ManagementOS -VMNetworkAdapterName <識別名> -Access -VlanId <VLAN ID>
正しい手順をまとめると次のようになる。
ただし、この構成を使う場合は次の2つの点に注意しなければならない。
第1の注意点は、「帯域を共有する」という点だ。例えば、ライブ・マイグレーションを実行すると、その処理にかなりの帯域を奪われてしまい、ほかのネットワークに影響が生じるもしれない。IPストレージを使うとなれば、日常的に帯域を奪われてしまうリスクもある。
1ページ目の図1「Hyper-Vの帯域幅管理機能」で紹介した仮想マシンの帯域幅管理機能と同様に、仮想スイッチに作成した親パーティションポートに対しても、PowerShellから帯域をコントロールすることができる。ただし、各パラメータの意味をきちんと理解してから設定しよう。この設定は意外とシビアであり、設定不足や設定ミスが大きなネットワーク・トラブルを引き起こすリスクがある。詳しくは以下のページを参照していただきたい。
もう1つの注意点はCPU負荷である。専用のASICを搭載したスイッチ機器と違い、ソフトウェアでスイッチング処理を行う仮想スイッチは、転送量が増えるにつれてCPUに負担がかかる。Hyper-Vの仮想スイッチはこのスイッチング負荷が比較的高く、10Gbpsクラスのスループットを仮想スイッチで処理すると結構なCPUリソースを奪われてしまうだろう。このため、米インテルを中心としたNICベンダが、これを抜本的に解決する「SR-IOV(Single Root I/O Virtualization)」という技術の普及を進めている。
米マイクロソフトのベスト・プラクティスをベースにした今回のネットワーク構成では、親パーティションあてのI/Oはいったんすべて仮想スイッチに送っている。つまり、このI/OもCPUベースのソフトウェア・スイッチングの対象となり、それなりのCPU負荷が予想される。こういった意味でも、iSCSIやSMBといったIPストレージの採用はよく考えて判断しなければならない。
OS標準機能(仮想スイッチ+VLAN)には細かい点で懸念があるし、1GbEでは大量のポートが必要となり、費用がかさんで物理スペース的にも厳しくなる。では、やはりHyper-Vは小規模向きで本格採用できないのかというと、そうとも限らない。ベンダ各社が“仮想化向け”と位置付けているサーバの多くは「NICパーティショニング」という技術を備えており、これを用いることで帯域共有やCPU負荷の問題を解決できる(図13)。
実際のNICパーティショニング技術については、各ベンダの資料などを参照していただきたい。
NICパーティションニング機能を使ったHyper-Vネットワーク設計の例を次に示す。この例では2ポートの10GbEを8つの仮想的なNICに分割し、それぞれの用途に最適な帯域を割り当てている。VLANの設定といった面倒な作業は不要である。
確かに現在のHyper-Vだけでは限界がある。しかし、すべてをHyper-Vのレイヤで実現する必要はない。ハードウェアとソフトウェアが互いの強みを活かして補完しあうと、「可用性」「性能」「コスト」を両立する優れたシステムを実現可能だ。少ない予算でよりよいシステムを実現するために、このような“エコシステム”な設計を心掛けていこう。
今回は10GbEなどを中心に、コストを意識したHyper-Vネットワーク設計のベスト・プラクティスを解説した。次回は連載の最後として、今回触れることのできなかったInfiniBandや、Hyper-Vシステム全体の最適設計方法についてまとめる。
Copyright© Digital Advantage Corp. All Rights Reserved.