Hyper-Vのネットワーク (5) - つまりは分散仮想スイッチ〜論理スイッチ

さて、第5回は予定通り?SCVMMによって構成される仮想スイッチである「論理スイッチ」について見ていきたいと思います。

  1. どこにあるのさ!! 仮想スイッチ
  2. 仮想スイッチには、標準スイッチと論理スイッチがある
  3. Hyper-Vのネットワークは3階層で考えるべし
  4. 何のための、ネットワークなのか。〜論理ネットワーク

前回見てきた論理ネットワークはvSphereに存在しないレイヤーの管理概念でしたが、今回の論理スイッチはおおよそVMwareにおける分散仮想スイッチと同階層の位置づけといえます(ただし、カバーしている範囲はだいぶ異なりますが…ポジショニング的には、おおよそここです)。Hyper-Vマネージャでは、Hyper-Vホストに対して個別に仮想スイッチを構成していましたが、System Center Virtual Machine Manager (SCVMM) を通じて管理されているHyper-Vホストの場合は、SCVMM側によって統合管理される論理スイッチの定義をHyper-Vホストに対して展開することができるようになります。そのため、SCVMMでは「SCVMMによって統合管理されない=Hyper-Vホスト毎に構成情報を保持する仮想スイッチ」を『標準スイッチ』、「SCVMMによって統合管理される仮想スイッチ」を『論理スイッチ』と区分して扱います。この辺りについては、本シリーズの第2回『仮想スイッチには、標準スイッチと論理スイッチがある』を参照頂ければと思います。

<標準スイッチと論理スイッチ>

ただ、標準仮想スイッチと分散仮想スイッチが別物として扱われているVMware vSphereの場合と異なり*1、SCVMMにおける論理スイッチはあくまでも管理面がSCVMM側に統合されているだけなので、実際の各Hyper-Vホストにおける仮想スイッチとしては標準スイッチも論理スイッチも違いはありません。違いが見えるのは、ホスト側というよりも仮想マシンの仮想ネットワークアダプタ―に対する構成先のネットワークとしての設定方法における違いの部分となります。

仮想スイッチに対して直接的に構成情報を定義する標準スイッチに対して、論理スイッチでは以下の3項目をポリシー的に事前定義します。これにより、Hyper-Vホストをまたいだ横断的な設定を実現しています。

拡張機能は、Windows Server 2012から対応した仮想スイッチに対する機能追加の仕組みです。Microsoft自身が提供する拡張機能もありますし、3rd Party製の拡張機能を組み込むことも可能です。Ciscoが提供するNexus 1000V for Microsoft Hyper-Vも、この拡張機能の仕組みを使ってHyper-Vにおけるネットワークに対する組み込みを実現しています(が、そのあたりはまた追々)。

アップリンクポートプロファイルは、仮想スイッチにとってのアップリンクポート、つまりはサーバにおける物理NICに対するポリシーを定義した構成情報です。このポートプロファイルについては、次回のエントリーで詳しく触れたいと思います。

そして最後の仮想ポートのポート分類は、その名の通り仮想ポートを分類するために用意されている抽象的な区分概念です。この分類そのものにはパラメータは存在していません。つまり、ポート分類はあくまでも分類として定義するための抽象化レイヤーでしかなく、特に設定値を保持してはいません。具体的なHyper-Vインフラレイヤー側から見た定義はポートプロファイルに存在しています。…が、ポートプロファイルの詳細については前述の通りまた次回。

SCVMMでは、デフォルトで以下のポート分類が用意されています。もちろん、自身で新たなポート分類を作成することも可能です。

<ポート分類の一覧>

論理スイッチでは、「この論理スイッチに対して構成できる」仮想ポートに対するポート分類を定義します。ポートプロファイルには、前述のアップリンクポートプロファイルと仮想ネットワークアダプターポートプロファイルの2つがあるのですが、直接論理スイッチに対して紐付けられるアップリンクポートプロファイルに対して、仮想ネットワークアダプターポートプロファイルについては、直接論理スイッチに紐付けられずに、ポート分類という抽象化レイヤーを間に噛ましているところがなかなか興味深いところです。アップリンクポートプロファイルは仮想マシンネットワークアダプタ側の構成には影響しない(=仮想マシンにとっては直接認識する必要のない)部分ですので、直接的に論理スイッチに対して紐付けられていると思われます。

<ポート分類>

このポート分類は、仮想マシン側でネットワークアダプタを構成する際に、選択肢として表示される対象となります。つまり、ここは仮想マシンを構成する際に「見える」部分となります。ここが、おそらくポート分類という抽象化レイヤーが用意されている理由です。論理スイッチ側の具体的なパラメータ定義を直接的に仮想マシンからは「見えない(=気にしなくてもいい/気にされない)」様にするためには、仮想ネットワークアダプターポートプロファイルをダイレクトに論理スイッチに割り当てて直接的に選択肢とさせるのではなく、ポート分類という抽象化を用いる必要があったわけです。

また、仮想マシンを構成する側にとっても、ポート分類は「目的や用途」といったかたちで選択を行うことができるようになるメリットがあります。インフラの管理者側は仮想ネットワークアダプターポートプロファイルにおいて細かなパラメータを定義するわけですが、仮想マシンを構成する側にとってはそうした細かいパラメータはいわばどうでもよく、どういった用途に使うことができるネットワークなのかさえ分かればよいのですから、この階層化は理にかなっています。実際に使われている仮想ネットワークアダプターポートプロファイルはホストグループAとBで異なっていても、用途が同じネットワークなのであれば仮想マシン側から見た際には同じ様に見せてしまおう、というわけです。

このように、論理スイッチではHyper-Vホストの具体的な物理構成や仕様などに紐付かない範囲で、仮想スイッチのパラメータを定義し、特定ホスト/ホストグループの枠を超えて使用することが可能なレベルで、基本的にはホストグループ単位に対して適用することができる概念的な仮想スイッチを定義しています。

管理上Hyper-Vホストとの紐付けが明示的ではなく、多段に抽象化レイヤーを構成しているために、VMwareの分散仮想スイッチと同じレベルを定義しているとは言いづらい部分もあるのですが、単体ホストの範囲を超えて適用することができる仮想スイッチ定義であるという大枠においては、同じ目的を持っていると言ってもよいのではないかと思います。

それでは、次回のエントリーでは、論理スイッチにおける定義に結びつけられているポートプロファイルおよびポート分類について、もう少し深く見ていきたいと思います。

*1:厳密には、内部的にはESXiホストにおいても分散仮想スイッチは標準仮想スイッチと同じベースではあったりはするのですが…それを管理者に見える形にしているかどうか、という意味での話です。