サーバ仮想化の技術に関してVMware vSphereを中心に携わってきて、正直Microsoft Hyper-Vについてはこれまではあまりマジメに取り組んできませんでした(^_^;)。もちろん、Hyper-Vが登場して以降、継続的に触ってみてはいましたし、製品として進化していく過程を、注目してウォッチもしてきました。Windows Server 2012になって、Server Coreを使ったHyper-Vや、Cluster Shared Volume (CSV) を使った共有ストレージへの仮想マシンの配置、Live Migration、Windows Server Failover Cluster (WSFC)を使った仮想マシンのフェイルオーバー等々、主要な機能についてはつまみ食い程度に構築してみた(遊んでみた)ことはありましたが、前職ではMicrosoft関連は別チームが担当していたこともあり、実用レベルでしっかりと検証・設計・構築をする動機がなかった、ということもあります。
ソフトウェア製品としてのSystem Centerはとても良くできていると思いますし、製品群全体で運用管理をトータルにカバーしているという部分においては現時点においてはVMwareに勝っていると思っています。ちょっと前までは複雑怪奇なライセンス体系でしたが、最近はシンプルになっているようですし、ライセンスの価格付けも競合を意識して戦略的に対応されていますので、別に馬鹿高いというわけでもありません。
そんな状況であるにもかかわらず、私がある程度まで検証してもそれ以上の段階まで進まなかった技術面での理由が、ぶっちゃけ、Hyper-Vマネージャはまったく問題ないんですが、その先に進むために必要となるSystem Center Virtual Machine Manager (SCVMM)の敷居の高さでした。インストール段階でもVMware vCenterと比べると何かと手間がかかるのですが(^_^;)、それはそれとして、それ以上に、SCVMM経由での管理が、Hyper-Vマネージャ経由での管理とは大きく異なっている、ということが私が感じた最大の「敷居の高さ」でした。人それぞれだとは思うのですが、システムの構成を絵や図としてイメージしながら理解していくタイプの私の場合、こうした一足飛びに発展するというか変化する？仕様はとても大きな課題でした。
が、いつまでもこのままではダメでしょ！ということで、ちょいと奮起しまして本エントリーから何回かに渡って、Hyper-Vのネットワーク管理について、超基本的なところからSCVMMによる管理まで、ちょっと書いてみたいと思います。本格的な大規模な仮想化基盤の詳細設計や実装にも携わった経験のあるVMware vSphereに対して、私のSCVMM+Hyper-Vの経験値は正直たいしたことありませんので、間違っていたり、認識不足な面も色々とありそうなのでオープンに書くことはけっこう怖いのですが、あえてぶっちゃけてみたいと思います。ぜひぜひ誤りなどがあれば、ご指摘頂ければと思います。
第1回目のテーマは、SCVMM以前の部分として、『どこにあるのさ!!仮想スイッチ』です(^_^;)
今に始まった話じゃないのですが、Hyper-Vにおける仮想スイッチの存在ってどうもイメージしづらいと思いませんか？私は、イメージしづらいです(^_^;)。どちらがいいか論議はさておきHypervisor用途に特化しているESXiに対して、Hyper-Vはその多くの機能をペアレントOSとして動作するWindows Serverに依存していることが、おそらくそもそもの理由なのではないかと思っています。Windows Serverは、汎用OSとして作られているため、Hypervisorに特化・最適化されてはいません。もちろん、仮想化のためのHyper-Vバイナリ部分はHypervisorとして特化されていますが、仮想スイッチ自体の機能はペアレントOS部分にあるため、基本的にはWindowsのネットワークアダプタ―管理機能を拡張して仮想スイッチが実装されています。この方式にはWindows用のネットワークアダプタ―ドライバをそのまま使用することができるというメリットがありますが、元々エンドホストノード用として用意されていたWindowsのネットワークアダプター管理機能を拡張して使用するため、以下の画面キャプチャのように、物理的なデバイスに対してドライバを通じて認識した いわば物理ネットワークアダプタ―と、チーミングによって構成される論理ネットワークアダプター、さらには仮想スイッチを通じて通信する仮想ネットワークアダプタ―などがずらっとまとめて同列に表示されます*1。
このGUIにおいて、仮想スイッチはリストとしては存在しません。物理ネットワークアダプターもしくは論理ネットワークアダプタ―と、仮想ネットワークアダプタ―の間には、概念的には仮想スイッチが存在しているのですが、「見た目」としては存在しません。あえて仮想スイッチはどれなのか、といえば、仮想スイッチのアップリンクポートとなるネットワークアダプターのプロパティにある「Hyper-V拡張可能仮想スイッチ」機能がそれだということになります。
どうすればイメージとして腑に落ちるかたちで理解できるか色々と考えたのですが、Hyper-Vにおいては概念としての仮想スイッチは存在していても、実装としての仮想スイッチは存在しない、と考えた方がすっきりすることに気が付きました。そこまで言うとちょっと言い過ぎなのですが、仮想スイッチというコンポーネントを考えてしまうから悩むのであり、単なるドライバというかネットワークアダプタ―に対して構成された機能の1つであると捉えるべきだと思います。
Windowsは昔からネットワークアダプタ―をブリッジとして使用することができました(＝ブリッジ接続ドライバが標準で提供されたという意味です。Windows XPおよびWindows 2003 Serverからかな？たぶん)。そして、ネットワークデバイスとしてはブリッジを多対多で実装したものがスイッチです*2。仮想スイッチとしてソフトウェア処理だということを考えれば、どちらかといえば仮想スイッチはブリッジよりの存在といってしまっていいかもしれません。つまり、Hyper-Vにおける仮想スイッチの実体は、物理／論理ネットワークアダプターと仮想ネットワークアダプタ―間でのブリッジを論理的にまとめて管理するもの(+仮想ネットワークアダプター間のブリッジングも可能とするもの)、といえるのではないかと思います。もちろん、VLANの管理や、オフロード、拡張機能対応、さらにはネットワーク仮想化への対応など、実際の処理においては単純にブリッジングしているわけではありませんが、Hyper−Vにおける仮想スイッチの実装はブリッジ実装を拡張したものと考えるととてもシンプルに理解できます*3。
Windows8のHyper-Vなどで、WiFiアダプタを通じて仮想マシンを通信させたい場合などにおいて、Hyper-Vで構成した内部仮想スイッチと物理WiFiネットワークアダプタの間でブリッジを使用するテクニックはよく知られている方法のようですので、クライアントOSでHyper-Vを触っている人たちにはこの認識は当たり前なのかもしれませんが…(^_^;)
ちなみに、Hyper-Vにおける仮想スイッチの実装が、アップリンクとなるネットワークアダプタ―と仮想マシンの仮想ネットワークアダプタ―間のブリッジとして実装されていると考えると、Hyper-Vでは、仮想スイッチに対してではなく仮想ネットワークアダプタ―毎にVLANや帯域制御など、様々なパラメータを構成する仕組みになっていることも、腑に落ちる気がするのですがいかがでしょうか？
ちなみに、ペアレントOSは仮想スイッチとしての役割を担わない物理ネットワークアダプタ―を自身の通信のために使用することもできますし、「管理オペレーティングシステムにこのネットワークアダプタ―の共有を許可する」のチェックを有効にすれば、仮想スイッチのアップリンク用として使用する物理ネットワークアダプタ―を通じて通信する＝ペアレントOSでも仮想ネットワークアダプタ―を使用する、という構成を取ることが可能です。
もちろんその場合、ペアレントOSにも仮想ネットワークアダプタ―が登場します。また、元の物理ネットワークアダプタ―に対して構成されていたネットワークパラメータは、基本的にこの仮想ネットワークアダプターに再割当されます。…が、たまに再割当に失敗します。リモートでこの状態に陥ると、ちょっと悲惨です(^_^;)*4
ネットワークアダプタ―の機能は、それぞれ以下のようになります
仮想スイッチのアップリンクとして使用される物理ネットワークアダプタ―は、すでに上にあった通り、」「Hyper-V拡張可能仮想スイッチ」機能だけが有効となります。ただし、Windowsのチーミング機能を使用してチーミングされた論理ネットワークアダプタ―の場合は、合わせてロードバランシング／フェイルオーバー機能が有効となります。
ちょっと脱線ですが、チーミングのメンバーとなった物理ネットワークアダプタ―では、「Microsoft Network Adapter Multiplexor Protocol」だけが有効となります。
このあたりをもう少し仮想スイッチっぽく？視覚的にも管理できるようにして頂けると、それだけでもだいぶHyper-Vが取っつきやすくなる気がするんですけれどもね！あれ？SCVMMにまったくたどり着いていない…。それどころか、まだSCVMMに入る前に何回かエントリーを書けてしまいそうな気も…。ま、いいや。
では、また次回。
*1:ちなみに、この管理画面において物理ネットワークアダプタ―として認識されているアダプターも、実はCisco UCS専用のネットワークアダプタ―であるVirtual Interface Card (VIC)によって論理的に構成された仮想NICなのですが…まぁその話はまた別のエントリーで。
*2:もちろん、色々違いがあるとは思っていますが…まぁそれはそれということで。この辺りでも読んで下さい…。
*3:通常のブリッジだと、ネットワークの管理画面にブリッジアダプターが表示されるのですが、仮想スイッチ実装ではペアレントOS以外は基本的にすべてVM-Bus経由での接続となりペアレントOSでブリッジを表示する必要性がないためか、表示はされません。まぁされたら余計分かりづらくなってしまいますしね…。
*4:CiscoのUCSはOSに依存しないコンソールを提供するCisco IMCを標準搭載していますので安心！とか書いてみたりしてみたり…。
