Hyper-Vのネットワーク (6) - 設定情報と設定対象を分離して管理する〜ネットワークプロファイルとポート分類(1)

やばい、４月が終わってしまう！(^_^;)…ということで、１ヶ月ぶりの更新です…。えーっと、前回は何を書いたんだっけ？状態です…。

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

前回はSCVMMによって管理されるまさに論理的なスイッチである「論理スイッチ」について見てきましたが、今回は「ネットワークプロファイル」と「ポート分類」について見て行きたいと思います。

まずネットワークプロファイルですが…話が脱線するかもしれませんが、SCVMMの機能ではあるものの、このネットワークプロファイルというが概念はとてもCisco的な思想が色濃く反映されているように私には思えます。SCVMMに対してNexus 1000V for Microsoft Hyper-Vを実装するためには、SCVMM側がそれに対応した仕様になっている必要があり、その最大のポイントともいえる機能が、この対象スイッチとは分離されて管理されるポートプロファイル機能だと言えるからです。

さて、ではポートプロファイルとは何なのか。簡単にいえば、ポートプロファイルは設定対象とは分離して管理されているパラメータ情報、です。

＜ポートプロファイル＞

この画面は、SCVMM2012R2のポートプロファイル画面です。一般的によく使われるであろうことが想定される項目については、デフォルトで用意されています。また、高帯域／中帯域／低帯域など、ポートプロファイルを使ってどのような分類を行えばよいのかについて参考になるのではないかと思います。

ポートプロファイルには、種類として「アップリンク」と「仮想」があります。前回のエントリーで見たように、論理スイッチにおいて、アップリンクにはアップリンクポートプロファイルが直接的に、仮想マシンが接続する側の仮想ポートについては、ポート分類に対して紐付けられたパラメータとして仮想ポートプロファイルがリンクされます。つまり、ポートプロファイルにおいて定義した構成は、論理スイッチにおいて実際の設定対象と紐付けられることになります(厳密には、論理スイッチはさらに各Hyper-Vホストにおいて物理アダプターに紐付けられるわけで、抽象化が階層化されているわけですが)。

ポートプロファイルにおいて、アップリンクポートプロファイルと仮想ポートプロファイルでは異なるプロパティを持ちます。

＜アップリンクポートプロファイル＞

なんといってもアップリンクポートプロファイルの特徴は、上図のようにアップリンクポートに対する定義パラメータを持つことです。アップリンクポートとしてインターフェイスにおける負荷分散アルゴリズムと、チーミングモードを定義することができます。Windowsホストとして持つチーミング定義と、SCVMMにおけるアップリンクポートプロファイルとして構成するチーミング定義が併存していることも、ちょっとSCVMMによって管理されるHyper-V環境をわかりづらくしている要因の１つといえるかもしれません。

負荷分散アルゴリズムとしては、以下の選択肢から選ぶことができます。

• ホストの既定
• アドレスのハッシュ
• Hyper-Vポート
• 動的

• • 「ホストの既定」は、特にSCVMMから指定を定義しない選択肢です。設定は、各ホスト毎に定義を行う必要があります。
  • 「アドレスのハッシュ」は、送信先・送信元のMACアドレスやIPアドレス、ポート番号などを元にハッシュ計算した結果に基づいてアップリンクポートが選択される負荷分散アルゴリズムです。ハッシュ計算に使用されるヘッダ情報の組み合わせについては、プロトコル種別などによって異なり、どの組み合わせを優先的に使用するかについてはPowerShellを使って定義を変更することも可能です(…が、あまり変更することは推奨されませんが)。
  • 「Hyper-Vポート」は、Hyper-Vのアップリンクポートとして使用する場合のみ使用することができる負荷分散アルゴリズムです。仮想ポート毎に指定されているポートIDに基づいて、使用するアップリンクポートが選択されます。そのため、ある仮想マシンは当該アップリンクポートがダウンしない限り、ずっと特定のアップリンクポートのみを使用し続けます。つまり、仮想マシン毎に見ると負荷分散はされていなくても、仮想スイッチ全体としては負荷分散されていることになる方式といえます。
  • 「動的」は、単純にチーミングを構成する各アダプターの負荷状況に基づいて使用する経路を動的に変更する負荷分散アルゴリズムです。これはWindows Server 2012R2から実装された新方式ですが、ハッシュ計算などの負荷が小さいため、2012R2では既定の負荷分散アルゴリズムとなっています。

チーミングモードとしては、以下の選択肢から選ぶことができます。

• 静的チーミング
• スイッチに非依存
• LACP

• • 「静的チーミング」は、ホストから見て対向の接続先は１台と認識されるスイッチ(物理的に１台のスイッチ、スタック構成のスイッチ、vPCなどの論理的に１台のスイッチとして認識できる論理スイッチ)と接続する必要のあるチーミングモードです。
  • 「スイッチに非依存」は、チーミングの構成ポートが異なるスイッチに接続することが可能なチーミングモードです。負荷分散アルゴリズム次第で、各アップリンクポートがActive/Activeとなるか、Active/Standbyとなるかが決まります。
  • 「LACP」は、対向のスイッチでLACPを構成・使用できるチーミングモードです。LACPが構成されていれば、スタック構成やvPCなどの対向からは論理的に１台と認識される構成などで使用することができます。

アップリンクポートは、Hyper-Vホストの物理構成を意識してポートプロファイルを定義する必要があるため、対象とするネットワークサイトを指定することができます。

あー…思わず細かく書き出してしまったら、ここまでですでにだいぶ長くなってきてしまったので、アップリンクポートプロファイルだけで一区切りさせていただきます。
次回は仮想ポートプロファイルに続きます…。

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

＜ポート分類の一覧＞

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

＜ポート分類＞

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

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

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

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

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

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

Hyper-Vのネットワーク (4) - 何のための、ネットワークなのか。〜論理ネットワーク

第4回にしてやっとSystem Center Virtual Machine Manager (SCVMM)によるネットワーク管理に入っていきます。ははは…。

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

前回のエントリーで最後に書いたとおり、今回はこの絵の私なりの見方？から始めたいと思います。

SCVMMによって管理されるHyper-Vのネットワークは、論理ネットワークから全てが始まります。この絵ではLogical Networkと表記されている、ちょうど真ん中の項目が論理ネットワークです。別にこの絵は素直に、一番上の仮想マシン(Virtual Machines)から、一番下の物理ネットワーク(Physical Network)に至るまでの一連の階層として捉えてもよいかとは思うのですが、私としては、論理ネットワーク(Logical Network)を抽象度合いの頂点として、上下の抽象度が最も低い(=OSにとってのNIC認識に紐付く)仮想マシンの仮想NICと物理サーバの物理NICそれぞれを結びつける階層図として捉えてみると、分かりやすいのではないかと考えています。

ちょっと書き加えてみると、こんなかんじでしょうか。

なお、Hyper-Vであっても、ゲストOSはネットワークをネットワークアダプタの先にあるものと捉えています。ただし、せっかくの機会？なのでついでにちょっとここで脱線しておくと、Hyper-Vにおける第2世代の仮想マシンはデバイス構成の深いところではかなり物理サーバとは異なるマシン環境となっています。この辺りはHypervisorとOSの両方を開発しているMicrosoftならではの最適化戦略がよく表れているところで、以下のように、ネットワークアダプタを含めた「外部とのやり取りを行う」デバイス群はHyper-V環境に最適化された仮想マシンバス(VMBus)の子デバイスとしてドライバが構成されています。

このような構成とすることで、MicrosoftはOSそのものをHyper-V環境に対して最適化しています。ドライバ実装レベルですから、このような対応は別にWindowsだからできるということでもなく、最近のMicrosoftはLinuxディストリビューションに対しても、けっこうキチンと最適化されたドライバ類を提供／Kernelにマージしていたりします。

そろそろ話を戻して、論理ネットワークにおいて定義する項目は以下の通りです。

• 名前
• 説明
• 「この論理ネットワークに新規に作成されるVMネットワークがネットワークの仮想化を使用することを許可する」チェックボックス

前述したとおり、論理ネットワークはSCVMMによって管理されたネットワークにおいて最も抽象化レベルが高い階層です。そのため、論理ネットワークを考える上で、実際の物理構成は考慮に入れる必要はありません。…というか、物理を一切意識しないことこそが逆に重要です。では、何を基準として論理ネットワークを設計するべきなのか。それは、『何のための、ネットワークなのか。』という1点です。

ただし、もちろんSCVMMにおける設定は最終的に実設定に落とし込まれる必要があります。つまり、非常に抽象的な『何のための、ネットワークなのか。』という視点は、当たり前ですがどこかではリアルなネットワークの実装とリンクする必要があります。論理ネットワークのパラメータにおいては、それは「ネットワークサイト」の部分にあります。

1つの論理ネットワークに対して、ネットワークサイトは複数定義することができます。そして、ネットワークサイトは、ホストグループに対して紐付けられます。ホストグループをどう分類するかもまた1つの設計ポイントとなるのですが、基本的には用途と場所に基づいてグルーピングされることが多いのではないかと思います。たとえば、Publicネットワークと位置付けた論理ネットワークであっても、東京のデータセンター側と、大阪のデータセンター側では実際に接続するネットワークは異なる場合が多いでしょう。この状態を論理ネットワークに対して紐付けるパラメータが「ネットワークサイト」です。

「ネットワークサイト」にはホストグループに加えて必須ではありませんがVLANとIPサブネットを関連づけることができます。なお、1つのネットワークサイトには、複数のVLAN/IPサブネットの組み合わせを紐付けることができます。『何のための、ネットワークなのか。』という視点で論理ネットワークを設計した場合に、実際のVLAN/IPサブネットは1つになるとは限らないわけですから、そのためにこのような構成になっています。なお、ネットワークサイトに対してVLAN/IPサブネットを定義しない場合は、「ネットワークサイト」はVLANを使わないかたちで扱われます。

なお、この段階でネットワークの仮想化(つまりはHyper-VにおいてはNVGREについて)の有効・無効も実際の項目としてはあるのですが、このあたりまで話を広げるとちょっと話がややこしくなりすぎる？ため、このへんについては取りあえずはあえて保留しておくこととさせて頂ければと思います。その辺りを超詳しく知りたい！という方は、この本が来月には刊行されるそうなので、ぜひ読んでみて下さい。

ネットワーク仮想化技術NVGREのすべて

さて、そんなわけで(どんなわけで？)次回は論理ネットワークとの違いがちょっと分かりづらい気もする論理スイッチについて考えてみたいと思います。ではまた次回。

Hyper-Vのネットワーク (3) - Hyper-Vのネットワークは3階層で考えるべし

なんだかんだで『Hyper-Vのネットワーク』シリーズも第3回、です。しかし、果たして何回シリーズなんでしょうか？これ…。

1. どこにあるのさ!! 仮想スイッチ
2. 仮想スイッチには、標準スイッチと論理スイッチがある

さて、System Center Virtual Machine Manager (SCVMM)によって管理されているHyper-Vはちょっとだいぶ？わかりづらい(^_^;)と何度も書いてきましたが、逆に、わかってくると、なかなかよく考えられているんだなとも思える実装です。まぁその「わかってくる」までの敷居の高さ？がちょっと問題ではあるのですが…。

何度か書きましたが、System CenterはMicrosoftがAzure基盤を管理するために開発したソフトウェアのサブセット版であると考えると多少理解やしやすくなります。ネットワークについても同様に考えるべきで、SCVMMは一気に大規模なクラウド仕様にも対応できるだけの機能をそなえています(Azure級はそのままでは管理できないでしょうが…それでも、エッセンスとしてはそのレベルへの対応に必要な機能が残されている、という意味です)。つまりSCVMMはVMwareでいえば、vCenter Serverの役割と(あえて書けば)vCloud Directorの的な役割を併せ持ったような実装になっているがゆえに一気に敷居が上がる「気がする」のです。

さてそのSCVMMでは、ネットワークに関する設定箇所があちこちにあります。大したことない事項のようにも思えそうですし、きっと毎日SCVMMの画面と睨めっこしている人はもはや気にもならない当たり前のことなのかもしれませんが、私としては、このちょっとした点が、Hyper-VマネージャからSCVMMに移行してきた際の敷居の1つではないかと思っています。

具体的には、[VMとサービス]には『VMネットワーク』という項目がありますし、[ファブリック]の配下にも『ネットワーク』という項目があり、その中には、『論理ネットワーク』やら『論理スイッチ』やらと、色々と並んでいます。この時点で、(私を含めて)あまりSCVMMには慣れていない多くの方が？？？となるはずです。Hyper-Vマネージャでは、単純に仮想スイッチという１つだけであったネットワークに関する設定パラメータが、ここで一気に複雑さを増すからです。

[VMとサービス] - 『VMネットワーク』

[ファブリック] - 『ネットワーク』

このあたりをどう乗り越えていくのか(^_^;)については、やり方は人それぞれで、ひたすら触り倒して理解する人、情報を読み込んで読み込んで納得するまで読み込む人、PowerShellコマンドに落とし込みながら理解する人など、色々です。このエントリーを書きながらも、結局は自分なりのやり方で触らないとわからないよね、とは私自身思っていますし、その通りだとも思います。しかし、触ってみるうえで、イメージを整理するためのきっかけというか、サポートぐらいにはなるかなという思いで、このエントリーは書いています。

さて、そのコツというか私なりのポイントは、本エントリーのタイトルの通りなのですが、SCVMMによって管理されるHyper-V環境のネットワークは3階層で考えると理解しやすい、ということです。

具体的には…

1. 仮想マシンの仮想ネットワークアダプタが接続する先となる仮想構成に基づいたネットワーク
2. Hyper-Vホストの配置ラック・接続先ネットワークなどの物理構成に基づいたネットワーク
3. 用途や目的といった抽象的な論理構成に基づいたネットワーク

…の3階層です。

各パラメータは、どのネットワークを対象としているのか。各階層間を結び付けているパラメータはどれなのか、といった視点でSCVMMによって管理されているネットワークを見てみると、おそらくより明確に、SCVMM管理環境におけるHyper-Vネットワークを理解できるのではないかと思います。

ソフトウェアによって、下から見ていった方が理解しやすいものと、上から見ていった方が理解しやすいものがあると思いますが、SCVMMは断然上からでしょう。なぜなら、設計思想として完全に抽象化されたリソース管理が必須となるAzureのために作られているソフトウェアだからです。前段の3階層についても、統合管理のために必要とも言えますが、根本的にはAzureにおいてこうした実装が必要であったから、といえるのではないかと思っています。

基本的には…

仮想マシンが接続する先となる 仮想構成に基づいたネットワーク	『ファブリック』‐『ネットワーク』設定項目
Hyper-Vホストの配置などの 物理構成に基づいたネットワーク	『VMとサービス』‐『VMネットワーク』の設定項目
用途や目的といった 論理構成に基づいたネットワーク	ホストおよびクラスタにおける仮想スイッチの設定項目

…なのですが、当然ながら、各階層をリンクするパラメータがお互いに必要であり、それらがどこでつながりあっているのかなどを把握しないと理解しづらいでしょう。

ところで、Microsoftが『Microsoft System Center: Building a Virtualized Network Solution』を無料のeBookとして公開しました。本書では、このあたりのアーキテクチャ構成を下図で示しています。

次回はこの図をどう見ればいいのか、あたりから進めていきたいと思います。
さて、今回は短めでしたが、区切りがいいところですので…また次回^_^;。

Hyper-Vのネットワーク (2) - 仮想スイッチには、標準スイッチと論理スイッチがある

さて、わかりづらい？Hyper-Vのネットワーク第2弾。今回はチーミングまわりについて…なんて少し思っていたのですが、タイミング良く素晴らしい記事をHP小川さんが@ITで公開されましたので、そちらを参照頂ければもう書くことないです^_^; …ということで、今回のエントリーではHyper-Vにおける仮想スイッチまわりにフォーカスを当ててみます。

前回書いた通り、Hyper-Vの仮想スイッチはネットワークアダプタ―における機能として実装されています。実装というよりも概念的な構成図を描いてみました。この図は物理・論理・仮想のネットワークアダプタ―を中心に書いてあります。実際には、Hyper-VのParent Partitionは仮想スイッチの役割を果たすネットワークアダプタ―を共有しなくてもよいので、必ずしもこのような構成にはなりませんし、またチーミング機能と仮想スイッチ機能は別ですので、このように3段構成とする必要があるわけでもありませんが、いわゆる良くある構成例、といった感じです。

ちょっと脱線すると、チーミング機能と仮想スイッチ機能はWindowsの中でそれぞれ独立した機能でありながら組み合わせた設計が必要であるところも、Hyper-Vのネットワークまわりをわかりづらくしている1つの要因といえるかと思います。…でありながら、上記の@ITの記事にも記載がありますが、VLAN対応をする実装がチーミング機能と仮想スイッチ機能の2つHyper-V環境で使用するWindowsの中に存在しており、Hyper-V環境でVLANを使用する場合はチーミング側でVLAN仮想アダプターを構成してはいけないといった点があることもまた、Hyper-Vをちょっと使いづらいものにしている気がします。こうした細かい事項の蓄積で、Hyper-Vは全体的にちょっとわかりづらかったり、使いづらかったりしてしまっているところは、ちょっと残念なところです。この取っつきずらさ？が、実はHyper-Vの普及を阻害してしまっている最も大きな理由なのかもしれません。個別の機能面や全体的に備えている機能の総合力としてはだいぶいい感じだと思うんですけれどもね…。

また、上図 下の方の、Cisco UCS、およびVirtual Interface Card (VIC)については、また別のエントリーで詳しく！書くことにしたいと思いますが、物理的には1つでも、Hyper-V/Windowsホストが物理NICだと思い込んで認識するネットワークアダプタ―(これまで、物理ネットワークアダプターとして表記してきたもの)を好きな数、自由に構成することができる優れものです。…が、こういうこと書いちゃうから、ますますどこの階層を物理というのか等がわかりづらくなってしまうんですよね、はい。

さて、本題に戻りましょう。

Hyper-Vマネージャで構成することができる仮想スイッチは、とてもシンプルです。仮想スイッチを新規に作成しようとすると、「外部」「内部」「プライベート」の3種類いずれかの仮想スイッチを構成できます。

外部こと「外部ネットワーク」を選択した場合は、その名の通り、外部と通信可能な仮想スイッチを構成します。そのため、仮想スイッチにとってアップリンクポートとなるネットワークアダプタ―の指定が必要となります。前回のエントリーで書いた通り、ここで「管理オペレーティングシステムにこのネットワークアダプタ―の共有を許可する」にチェックを付けると、この仮想スイッチに対して接続するための仮想ネットワークアダプタ―がParent Partitionの役割を持ったWindows Serverに対して構成されることになります。

「内部ネットワーク」と「プライベートネットワーク」は、ちょっと違いが分かりづらい。要はParent PartitionのWindows Serverも接続できる仮想スイッチを構成するか、仮想マシンに対してのみ接続を提供するか、の違いです。ただ、個人的には、この2つはわざわざ用意しなくてもいいのではないかと思っています。なぜなら、内部ネットワークは、外部ネットワークにおいて「アップリンクポートとなるネットワークアダプターを選択しない」という選択肢を用意すればいいですし、プライベートネットワークは、「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」のチェックをつけないことと基本的には同じことを意味するからです。VMwareでは、仮想スイッチにこれらを区別する選択肢は用意されていません。直感的には、その方が分かりやすいのではないかと思います。

なお、VLANの構成については、仮想スイッチではParent Partitionを接続する場合に割り当てるVLAN使用の有無と使用する場合のVLAN IDの指定だけを構成します。各仮想マシンのVLANについては、仮想マシン毎の仮想ネットワークアダプターにおいて構成するためここでは設定しません。つまり、VMware vSphereの場合におけるポートグループのような論理グループは、ここでは設定しません。VMwareな人にとっては、ポートグループ的な概念ないの？って思ってしまうところですね*1。

さて、まだSCVMMについては改めて今後のエントリーで扱うこととしたいと思いますが、今回のエントリーではSCVMMを通じて仮想スイッチを構成する部分についてだけ、見てみたいと思います。

このように、SCVMMを通じて仮想スイッチを構成する場合には、Hyper-Vマネージャでの仮想スイッチの作成とは違い、「標準スイッチ」と「論理スイッチ」の2つから選択して仮想スイッチを作成することになります。

標準スイッチは、基本的にはHyper-Vマネージャによって作成する仮想スイッチと同じものです。以下の画面のように、構成内容もHyper-Vマネージャでの場合とまったく同じです。Hyper-Vマネージャを通じて作成した仮想スイッチも、SCVMMでは標準スイッチとして分類されます。

対して、論理スイッチは基本的にはSCVMMを通じてのみ構成される仮想スイッチです。以下の画面のように、論理スイッチでは標準スイッチの場合とは構成するパラメータが異なります。各パラメータについては、今後のエントリーで詳しく見ていきたいと思いますが…設定する項目は、標準スイッチの場合とまったく異なります。スイッチとしての定義は、仮想スイッチ自身から分離されているため、最終的な仮想マシンのための仮想スイッチとしては最小限、アップリンクとして使用するネットワークアダプターとアップリンクポートグループのみとなります。この辺りの詳細は、また追々。

ところで、VMware vSphereの分散仮想スイッチも、実際には各ESXiホストに仮想スイッチを構成し、それを透過的に統合管理することによって「論理的には」ホストをまたいで構成された仮想スイッチを構成します。これと同様に、Hyper-Vにおける論理スイッチもまた、ホストをまたいでSCVMMによって統合管理される仮想スイッチとなります。しかし、分散仮想スイッチで管理されている個別ホスト側の仮想スイッチが上手く隠蔽されているのに対して、Hyper-VではParent PartitonとしてWindows Serverを使用している宿命と言えるかもしれませんが、普通にHyper-Vマネージャから見えてしまいます。

さらに、ここがまたHyper-Vのややこしいところなのですが、Hyper-Vマネージャでは標準スイッチと論理スイッチの2つを識別しないため、Hyper-Vマネージャを通じてそのスイッチを参照しても、違いはありません。

このように、論理スイッチの場合は設定についてはSCVMMからHyper-Vホストに対して定義が行われますが、仮想スイッチとしては外部ネットワークと同じように扱われます。そういうものだと理解すればまぁ別に困りはしないのですが、Hyper-Vのネットワークはこんな感じで、標準スイッチと論理スイッチがあるということをまず押さえておかないとHyper-Vマネージャによる管理の先には進めません。

そんな感じで、ではまた次回。

*1:SCVMMを通じて、の場合には事実上のポートグループ的な概念は存在するのですが…この段階ではない、というところも、数あるわかりづらい？気がする点の1つ…。

Hyper-Vのネットワーク(1) - どこにあるのさ!! 仮想スイッチ

サーバ仮想化の技術に関して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を標準搭載していますので安心！とか書いてみたりしてみたり…。

2013 - 2014 年末年始に読んだ本

2014年になりました。今年もよろしくお願いいたします。今年最初のエントリーは、久しぶりに読んだ本に関して。

2013年最後の海外作家小説は、ダン・ブラウンの『インフェルノ』。かなり映画化を強く意識しているのか、だいぶ映像的でめまぐるしい展開の作品だったが、面白かった。『ダヴィンチ・コード』に続きトム･ハンクス主演での映画化も決定しているとか。ま、だろうね。
[asin:B00GSE805Y:detail]

2013年最後の国内作家小説は、伊坂幸太郎の文庫版『マリアビートル』。伊坂幸太郎の作品は、新作が出るとついついハードカバーを買ってしまうのですが、文庫化される際に大幅に加筆修正されることが常なので、たまに文庫版も買ってしまう。本作も、ハードカバー版を所有しているが、ついつい文庫版も買ってしまった(^_^;)。文庫版には、マリアビートルの前章的な短編作品『ついていないから笑う』が含まれている。

マリアビートル (角川文庫)

2013年最後の1冊は、森博嗣の『森博嗣のTOOL BOX』。発行部数もそんなに多くないであろう本書がたまたま入ったBOOKOFFで100円でたたき売られていたので…(^_^;)。日経パソコン連載のエッセイをまとめた1冊。パソコンや電卓など、日経パソコンらしいモノについての紹介もあれば、ノギスやら天秤、タイプライターのフォントヘッド、本人もよくわからない機器から、スターリングエンジン模型などなど…。なかなか面白い1冊。

森博嗣の TOOL BOX

2014年最初の1冊は、三谷幸喜の『オンリー・ミー』(文庫版)。オビに「60万部突破のロングセラー」って書いてあるだろ！って話なんだけど、棚に表紙が見える形で並べられていて新作かと思って買ってみたら、なんとすでに第57版だったという…(>_<)。ま、でも面白かったから許す。なお、この冬には原作本も買った『清洲会議』も映画館に観に行ったし、WOWOW無料日に放送されていたワンシーンワンカットの映画『Short Cut』も観たしと、だいぶ三谷幸喜づいていた気がする…。

オンリー・ミー―私だけを (幻冬舎文庫)

2013年からの継続モノ？としては、海堂尊の『ガンコロリン』。短編集だったので、ついつい途中で止まってしまっていたので、この週末にやっと読了。継続的にハード本でも新作を購入している作家は、発刊数の多い作家だと伊坂幸太郎と海堂尊ぐらいになってしまったかも…。

ガンコロリン

2013年〜2014年にかけて読んだ技術書は、けっこう色々とあるが…主なところだけ。

まずは、だいぶ積ん読状態で溜め込んだ『Software Design』多数。特集だけ読んで、それ以外は読んでいないなど、ヌケヌケで読んでいるので追いつかないが…それでも、何冊かはなんとか…。

Software Design (ソフトウェア デザイン) 2014年 01月号 [雑誌]

書籍版では、やはりまずは待ちわびていたこの1冊『Windows Server 2012 R2 Hyper-V システム設計ガイド』。日本語のWindows Server 2012 R2に対応したHyper-V関連本としては初の刊行であることに加え、著者陣も1流なので、内容のクオリティも心配なしということで、即買い。

Windows Server 2012 R2 Hyper-Vシステム設計ガイド

Kindle版関連では、
『イーサネットファブリックとOpenFlow (Interop Tokyoセミナー)』

イーサネットファブリックとOpenFlow Interop Tokyoセミナー (Interop Tokyoセミナー（NextPublishing）)

『SDNの実践技術 (Interop Tokyoセミナー)』

SDNの実践技術 Interop Tokyoセミナー (Interop Tokyoセミナー（NextPublishing）)

…のInteropセミナーを書籍化した2冊なども読んだ。『イーサネットファブリック...』の方が面白かったかな。
一番ページ数のあった技術本は年末にちょうど刊行されたCisco UCSの導入ノウハウをまとめた『Implementing Cisco UCS Solutions』かな。Kindle版での購入だから、ページ数がよくわからないけれども。日本でも技術書はなかなか厳しいようだが、Cisco UCSについての本の刊行が日本でも企画されるぐらいになるといいのだが…。

Implementing Cisco UCS Solutions

2014年になって発売が開始されたものとしては、『VMwareの基本〜仮想化のための設計・構築・運用のポイント〜』。中の人による技術本としては、『VMware徹底入門』シリーズだが、vSphere5.5対応版は刊行されなさそうなので(というわけではないだろうけど)、こちらが。vSphereに関してのデザイン指針、設計ポイント、テストの考慮点や運用まわりのノウハウなど、けっこういい内容になっていると思う。

VMwareの基本　?仮想化のための設計・構築・運用のポイントがわかる

ところでだいぶ技術書はKindle版での購入が増えてきている気が。技術書はおそらく一般書に先駆けてどんどんと電子書籍化されてくことになるのだろうな…。

これ以外にもけっこう色々な本をつまみ読みしてはいるのですが、まぁそれはまた追々ということで…。ここ数年はTwitterと録音したJUNKを聞くことが通勤時間の中でだいぶ時間を取るようになっていましたが、今年は改めて読書の時間を確保するようにしたいですね。