ブログトップ 記事一覧 ログイン 無料ブログ開設

Simple is Beautiful このページをアンテナに追加 RSSフィード

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2017/05/12 (金)

[]Cisco UCS Manager Plug-in for VMware vSphere Web Client

CiscoVMwareと仲良しなのでლ(´ڡ`ლ)、ACIだけでなくUCSのvCenter Pluginもきっちり提供されている。それがこのUCS Manager Plug-in for VMware vSphere Web Client。もちろんこちらも追加コストなどなく利用頂くことが可能。…とはいえ、ここではこのプラグインの全体像の説明とかはしない。1点だけ、自分が気に入ったVIF Path情報をPluginの画面で確認できるところについてだけ。なお、用語重なりが混乱の元凶なのだが、このエントリー内で書くvNICは仮想マシンにとってのネットワークアダプタを意味するvNICではなく、UCSにインストールしたOS/Hypervisorにとってのネットワークアダプタを意味する。イメージ的には世間一般には物理NIC。でもUCSではVICによって論理的に構成された仮想NICなのでvNIC。あーめんど。

UCSではVICを搭載する構成が一般的なので、結果的にVIF/論理インターフェイスを使用することが一般的といえる。UCSにインストールしたOSやHypervisorからはVIFと紐付いたvNICはネットワークアダプタそのものとして認識される。つまり、UCS側でVIFを10個構成すれば、OS/Hypervisorからは10個のvNICを搭載したサーバで動作していると認識される。VICを使う場合、VIFのない構成はない。つまり2ポートの口があるVICで2ポートのネットワークアダプタをOS/Hypervisorが認識している場合であっても、1つのポートに1つのVIFが紐付いているデフォルト構成のまま使っている、というだけの話で、つまり実際にはVIFを使っている。

他のNICベンダーのネットワークアダプタでも論理インターフェイスを構成する機能はあったりするが、おそらくここまで一般的に論理インターフェイスを構成して使用する仕組みを活用しているサーバはUCSだけだろう。なぜなら、論理インターフェイスを活用するためにはサーバ側の構成(=VICの構成)だけでは不十分で、上位スイッチ側も含めて構成して初めて活用できるからだ。ラックサーバタイプのUCSは単体でも使用できるが、ブレードサーバタイプのUCSは必ずFabric Interconnect(FI)と呼ばれるUCSの管理機能(=UCS Manager)を加えた特殊なNexusスイッチをあわせて使用する。UCS ManagerはUCS全体を管理する。つまり、UCSのサーバ部分だけではなく、自身が実行されている環境であるFIも管理している。これによって、VICにVIFを構成すると自動的にFI側も構成されているため、UCSの利用者はサーバとネットワークを意識することなく、シンプルにVIFを構成して利用することができる。つまり、VIFはOS/Hypervisorから見た論理ネットワークアダプタ(=vNIC)であるというだけではなく、論理ネットワークケーブルによって上位スイッチの論理ポートに接続されるまでの全体を意味しているということだ。図示するとこんな感じ。

f:id:takaochan:20170512172931p:image

…説明はここまでにして、vCenterのUCS Plug-inでVIF情報を確認できると何が嬉しいの?という話。

まずはVIFによって構成されているvNIC、つまりはOS/Hypervisorから見たNICについてのプラグインの画面。ここでは6ポートのNICがあるという情報になっているが、これらは当然ながら物理NICが6ポートあるのではなく、VICによってvNICが6ポート構成されているということを意味する。この画面でUCS側で管理名として設定しているvNICの名前とMACアドレスの情報を参照できる。

f:id:takaochan:20170512170636p:image

で、以下がVIFのパス情報を表示するプラグインの画面。この2つの画面によって、VIFがどの経路のポートに紐付いているかがわかる。つまり、仮想マシンと仮想スイッチのアップリンクポートの関係性みたいな、VIFにおけるvNICとパス(=ポート)の紐付けを確認できる。

f:id:takaochan:20170512165557p:image

ちなみに、ESXiホストとして認識している[物理アダプタ]は、UCS的には物理アダプタではない(^_^;)。ここでもMACアドレスは表示されているので、ここを識別子としてUCSとしてのVIFのvNICと、ESXiとしてのvmnicの紐付けを確認することができる。

f:id:takaochan:20170512171511p:image

…ということで、この三段論法によって、UCSにおけるネットワークの流れをvSphere Web Client側だけで確認できて便利だね、ということが、言いたかったこと。vCenterのプラグインはさておき、この仕組自体はUCS登場時からのお家芸。

UCSという製品の特徴はUCS Managerによる統合管理だ!というのはもちろんなのだけれども、それを支えるハードウェア的な仕組みとしてVICがある。このソフトウェアとハードウェアの組合せで実現している仕組みだからこそ、他社の追随を未だに許さない、UCSならではのネットワークの管理性、構成の自由度などを実現しているのだろう。

ちなみに脱線というかオマケだけど、UCSのブレードサーバでVIC 1240を搭載している場合、VICのメザニンカード自体の帯域は全体として40Gbある(内部的には各IOMに対して20GbでPort Channel接続している)。なので、UCSのブレードモデルにESXiをインストールして物理アダプタの項目を見ると、以下のように速度として 20000 Mb / 20Gb と表示される。面白いね。

f:id:takaochan:20170512172624p:image

2016/12/25 (日)

[]Cisco ACIとVMware NSXは競合製品なのか?

本エントリーは 2016年の vExpert Advent Calendar の〆を飾る?最終エントリーとなります。参加されたvExpertな皆さん、お疲れ様でした。年末休暇で暇な皆さま、このAdvent Calendarをはじめとして、多くのAdvent Calendarが面白いネタで25日間に渡ってリレーされていますので、それらをじっくりと読んでみるのも面白いかもしれませんよ。

さて、では vExpert Advent Calendar の最後に、こんなタイトルで 〆てみたいと思います。たまにぶっこみすぎじゃね?と言われることがあるんですが、別に私自身はそんなつもりないんですけれどもね。中の人ではないからこそ書けることがあると思っています。

では、本題。

結論から書いてしまえば、たしかにごく一部の部分においてCisco ACI (Application Centric Infrastructure) とVMware NSXはいってみれば「競合」している部分があるのは事実でしょう。別の会社の、それぞれの会社の戦略の中で開発・買収・提供が行われている製品同士なのですから、それはアタリマエのことです。しかし、私の個人的な見解としては、Cisco ACIとVMware NSXは大半の範囲については異なる位置づけの製品だと思います。言ってみれば、ルータとスイッチぐらいには異なる製品です。ネットワーク製品というくくりでは同じであっても、ルータとスイッチの使われ方や役割は異なることは誰もがおわかりでしょう。ルータにスイッチポートを搭載することができても、スイッチがルーティングの機能を持つようになっても、今でも両方の製品が使われているように、Cisco ACI とVMware NSXは根本的な製品の位置づけが異なると考えています。

本エントリーは、どちらかといえばCisco ACIの視点からみたNSXの位置づけについて考えてみたものとなりますが、世の中にあまりこうした視点でNSXについて書かれた情報はない気がしますので、何か参考になればいいなと思います。

Cisco ACIから見てVMware NSXとは

Cisco ACIから見ると、VMware NSXは数多くある管理対象として扱うことができるアプリケーションの1つです。つまり、VMware ESXiホスト上の仮想マシンに対して様々なサービスを提供するアプリケーションです。Cisco ACIとVMware NSXはお互いサポート対象ではありませんよね?と言われることがありますが、Windows上で動作するアプリケーションが、そのWindows自身の動作環境となっているハードウェアのベンダーに制約要件を持たない*1ように、NSXというネットワークを使ったアプリケーションをACIがサポートする・しないという制約条件はありません。

f:id:takaochan:20161224184013p:image

Cisco ACIは主にサーバが配置されるデータセンター向けのネットワークファブリックを基盤としたソリューションです。先日のエントリーでも書きましたが、Cisco ACIは連携する・しないはさておき、IPプロトコルを用いた通信である限り*2、あらゆる機器からのあらゆる通信に対応します。UNIXからの通信であっても、物理サーバからの通信であっても、そしてNSXからの通信であっても、そこに区別はありません。

割り切った書き方をすると誤解を生じる可能性があるので難しいのですが、Cisco ACIはネットワークファブリックとSDNを融合したソリューションです。対して、VMware NSXはSDNとNFVを融合したソリューションといえます。SDN部分で一部重なっている機能がありますが、ACIはNFV的な機能は自身では提供していませんし、NSXはすべてをソフトウェアだけで実現するためにネットワークファブリックは自身で提供していません。そしてSDN部分。製品の思想というか根幹の部分の考え方の違いとしかいいようがありませんが、「一部の仮想化環境のみを対象としたものではない、あらゆるネットワーク接続デバイスすべてを結びつけるネットワーク」に対するSDNは、ネットワークファブリックをベースとしているからこそ可能となると私は考えています。

■VXLAN on VXLAN?

VMware NSXはVXLANを使うことができますが、NSX Controllerを制御プレーンとして使用する仕組みになっています。基本的にはOVSDBを拡張したような仕組み?(教えて詳しい人。)を使ってデータプレーンとなるNSX仮想スイッチや、NSX対応した物理スイッチを制御します。つまりNSX Controllerとその共通言語でつながっている範囲でしかそのVXLANを解釈することができませんので、ACIがNSXによって制御されているVTEPによって包まれたVXLANを解釈することは残念ながらできません。

Ciscoなど、各社の間でVXLAN EVPN仕様の標準化が進められていますので、将来的には制御プレーンとして独自仕様ではなくEVPN MP-BGPを使う仕組みが標準化していけば、マルチベンダーで真の互換性のあるVXLAN相互接続が可能になるかもしれませんが、VXLANはフレーム仕様は標準化されていてもマルチキャストに依存した当初の構成ではネットワークの構成における制約や、柔軟な制御が難しいなどの課題があったため、現時点では各社が独自の制御プレーンの実装を進めてしまうという残念な状況が現時点のステータスです。

そもそもの話としてVXLANについて個人的に思うこととしては、VXLANを誰もが必要とするなら、VXLANが登場した当初にみんな飛びついたはずなのです。なのに、VXLANが今だにまだ一般化したと言えない理由は、VXLANをVXLANとして意識する使い方は、そんなに多くの人が望んでいるものではないのではないでしょうか。VLANの約4000という壁やら、マルチテナント対応やら、L3を超えたL2接続性やらと、ベンダー側はVXLANのメリットを訴えますが、逆にVXLANの存在を意識させない使い方にこそVXLANの価値はあるのではないかと思います。ACIでもマルチテナントを実現するなどの手段として内部的にVXLANを使ってはいますが、それらを意識して構成・管理するような必要性は全くありません。いわば意識せずに使うことができるVXLANがその裏側にはあるわけです。

そんなわけで、ACIはNSXのVXLANを連携によって認識はしませんが、各ESXiホストにあるVTEP間の通信はVLANに紐付いた単なるUTPパケット通信ですので、当たり前ですが認識できます。内部的にはVXLAN on VXLANになっているのでしょうが、だからどうこうといった問題はまったくありません。EthernetフレームであればL2スイッチング、IPパケットであればL3ルーティングできるという部分は一般的なスイッチと違いは一切ありません。

f:id:takaochan:20161224184012p:image

また、NSX仮想スイッチは分散仮想スイッチに依存していますので、ACIのvCenter連携によって作成された分散仮想スイッチに対してであっても、NSX仮想スイッチの実体としてのポートグループを作ることも可能です。もちろん、別の分散仮想スイッチを使用することも可能です。これらは、アップリンクに使用する物理NIC(もしくは、Cisco UCSでは標準的に使われている論理NIC)を分離するかどうかという構成次第での設計となります。

f:id:takaochan:20161224184011p:image

f:id:takaochan:20161224184010p:image

ACIのEPG (End Point Group)にどの単位でマッピングするのかも自由なところも、NSXを使う場合であってもACIをネットワークファブリックとして使うことのメリットの1つといえます。クラスター単位やポッド単位、ラック単位など、通信量やエラー状況を把握したい単位でNSXがVXLAN通信のためのVTEPポートとして使用するVMkernelのポートグループをEPGにマッピングすれば、ACI側からも通信の量やエラーを把握するヘルススコアなどを把握することが可能となります。また、EPG間のContractとしてVXLAN通信に使用する4789/utpだけを通す様に構成しておくことで、セキュリティ的にも望ましい状態を作り出すことができます。

f:id:takaochan:20161224184010p:image

f:id:takaochan:20161224184009p:image

■NSXのVXLANは使わなくてもいい

NSXのマイクロセグメンテーション機能がセキュリティなのかと言われると、私としてはあるなら使ったほうが程度のものだと思ったほうがいいのではないかと思っています。仮想マシン単位の隔離だけでは、なぜ侵入が発生したのか、どういう経路だったのか、どのアプリケーションがどういう動作をして、どこに通信しようとしているのか、そして究極的にどう問題を解決するのか等のセキュリティ的な確認・対応をしてくれるものではないからです。しかし、ほぼインフラ基盤がvSphereベースなので分散ファイアウォールを使いたい場合や、アンチウィルス連携など仮想化環境と蜜に連携しているからこそ可能となる機能を必要としている方もいるでしょう。そして、NSXを選択する理由としてそれらの機能をつかいたから、という方もいらっしゃるかもしれません。

さてそうした場合に、ネットワークそのものもNSXのVXLAN機能を使わなければならないかというと、実はそうではありません。NSXのVMkernelモジュールを展開すると、VXLANの構成を行わなくても分散ファイアウォールなどの機能は使用可能となります。また、NSX Controllerの展開も不要です。なぜならNSXの分散ファイアウォールやNSX EdgeなどはNSX Managerから直接管理されており、NSX Controllerに依存していないからです。つまり、ネットワークそのものはACIで構成し、ネットワークファブリックを活用した10/40/100GbEトラフィック性能や、EPG (End-Point Group)とContractによるネットワークのポリシー管理、ACIが提供するハードウェアベースの分散ルーティングやスイッチング、L3接続などの機能を活用し、vSphereだけに限定されない物理サーバや物理ファイアウォール・ロードバランサなども柔軟にネットワークに組み込むことを可能としつつ、分散ファイアウォールを使ってNSXのセキュリティグループを活用することが可能となります。

f:id:takaochan:20161224184008p:image

当然ながら、仮想マシンを含め、すべてのネットワーク接続をACI側で確認することができるようになるため、この組み合わせだとNSXのService Composerからも、APICGUIからも、仮想マシン毎に認識することができるようになります。

NSXが提供する分散ファイアウォールと、各社LB/FW連携によって構成されるEPG間や外部L3接続との間に挿入されるACI管理のセキュリティ機能であるService Grapthを組み合わることによって、より柔軟かつ実用的なネットワークを構成することが可能となります。

■単なる連携よりも、代替できたり、ない機能を提供したりできる方がよくないですかね?

NSXと連携するスイッチにしておきたいからと、Nexus/ACIではないスイッチだけを選択肢として考えることがあるかもしれませんが、NSX Controllerによって管理できるハードウェアVTEPとして連携できる物理スイッチは、単にNSX仮想スイッチに接続した仮想マシンと通信できる物理サーバを接続できるだけです。NSXを使わなければ、それこそどんなスイッチであってもVLANさえ処理できれば物理サーバと仮想マシンの間で通信できる構成を作ることになんの制約もないのに、NSXにしたが故に拡張OVSDBベースでのNSX連携できるスイッチでないと接続性を構成できないとか、あまりよくわかりません。しかも物理スイッチ連携を使用する場合は分散ルーティングの機能が制限されるなど、組み合わせと構成がややこしい気がします。

だったら、冒頭にも書きましたが、NSXであっても1つのアプリケーションとして扱ってしまうような、直接的な連携はせずともそれ単体でも様々な機能を提供することができて、必要であれば置き換え/代替することも可能で、NSXにはない機能も提供するACIのようなソリューションを組み合わせておいたほうが、なにかと利用者にとってもメリットが大きいのではないかと思うのですが、いかがでしょうか?

NSXを使わなくてもACIは使うことができますし、NSXの機能の多くを置き換えることも可能です。また、ACIは単なるSDN専用のネットワークソリューションではないので、コントローラによって統合管理されたあたかも巨大なL2/L3スイッチとして使うことができるネットワークファブリックとして使うだけでも多くのメリットを得ることができます。無理してSDN的な使い方やAPI制御、各種連携などをしなければ使えないというものでもありません。

話が大きくなりすぎてしまう気もしますが、元々同じコンピュータであったネットワーク・サーバ・ストレージがそれぞれの役割に特化していったのは、それぞれの役割に特化して分離することによるメリットがあったからです。HCIなど、いわゆるエンタープライズ向けの市場において最近はトレンドのゆり戻りの流れの中でこれらの要素を統合する流れであるように思いますが、逆に先を行くクラウドの中ではあらためてハードウェアの機能を活用する実装への揺り返しが進みつつあったりします。どちらがよいとかではなく、いずれにしてもソフトウェアだけ、でもハードウェアだけでもない、それぞれのいい面を上手く引き出していくことが価値を生み出す手段としてより重要になっていくでしょう。

ネットワークは、あらゆるネットワークに接続してくる要素(=点)をつなぎ合わせるいわば面ですので、限られた点だけを対象とした面では、全体的な面にはなりえません。ある特定の仮想化基盤、ある特定のアプリケーション、ある特定のシステムのためだけのネットワークを作るのであればそれでもいいかもしれませんが、vSphereなどのサーバ仮想化が目指したところは、アプリケーションごと・システムごとの垂直なIT基盤の作り方から、共通化された統合的なIT基盤への発展であったはずです。であるならば、それに対応したネットワークは、特定の要素にだけ対応するネットワークではなく、あらゆる要素に共通のポリシー・管理性を提供できるような包括的な仕組みを提供できるネットワークソリューションであるべきなのではないかと、私は思います。

そんなわけで、Cisco ACIとVMware NSXは競合製品なのかどうか、あなたはどう思いますか?

Happy Holiday season and New Year!!

*1:もちろん、特定のハードウェアに依存したアプリケーションにはハードウェア要件がありますけど。

*2:IPに加えて、FCoE NPVによるFC通信にも対応

2014/04/30 (水)

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

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

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

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

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

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

<ポートプロファイル>

f:id:takaochan:20140430224252p:image

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

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

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

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

f:id:takaochan:20140430224251p:image

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

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

f:id:takaochan:20140430224244p:image

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

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

f:id:takaochan:20140430224243p:image

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

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

f:id:takaochan:20140430224250p:image

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

次回は仮想ポートプロファイルに続きます…。

2014/03/24 (月)

[][] 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回『仮想スイッチには、標準スイッチと論理スイッチがある』を参照頂ければと思います。

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

f:id:takaochan:20140317174104p:image

ただ、標準仮想スイッチと分散仮想スイッチが別物として扱われている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におけるネットワークに対する組み込みを実現しています(が、そのあたりはまた追々)。

f:id:takaochan:20140317172629p:image

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

f:id:takaochan:20140317172628p:image

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

f:id:takaochan:20140317172627p:image

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

<ポート分類の一覧>

f:id:takaochan:20140317172626p:image

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

<ポート分類>

f:id:takaochan:20140317172625p:image

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

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

f:id:takaochan:20140317173617p:image

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

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

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

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

2014/02/17 (月)

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

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

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

f:id:takaochan:20140208184431p:image

ちょっと脱線すると、チーミング機能と仮想スイッチ機能は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種類いずれかの仮想スイッチを構成できます。

f:id:takaochan:20140208184430j:image

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

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

f:id:takaochan:20140208184429p:image

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

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

f:id:takaochan:20140208184427p:image

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

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

f:id:takaochan:20140208184426p:image

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

f:id:takaochan:20140208184425j:image

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

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

f:id:takaochan:20140208184428p:image

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

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

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

2014/02/03 (月)

[][] 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

f:id:takaochan:20140129224230j:image

このGUIにおいて、仮想スイッチはリストとしては存在しません。物理ネットワークアダプターもしくは論理ネットワークアダプタ―と、仮想ネットワークアダプタ―の間には、概念的には仮想スイッチが存在しているのですが、「見た目」としては存在しません。あえて仮想スイッチはどれなのか、といえば、仮想スイッチのアップリンクポートとなるネットワークアダプターのプロパティにある「Hyper-V拡張可能仮想スイッチ」機能がそれだということになります。

f:id:takaochan:20140129224231p:image

どうすればイメージとして腑に落ちるかたちで理解できるか色々と考えたのですが、Hyper-Vにおいては概念としての仮想スイッチは存在していても、実装としての仮想スイッチは存在しない、と考えた方がすっきりすることに気が付きました。そこまで言うとちょっと言い過ぎなのですが、仮想スイッチというコンポーネントを考えてしまうから悩むのであり、単なるドライバというかネットワークアダプタ―に対して構成された機能の1つであると捉えるべきだと思います。

Windowsは昔からネットワークアダプタ―をブリッジとして使用することができました(=ブリッジ接続ドライバが標準で提供されたという意味です。Windows XPおよびWindows 2003 Serverからかな?たぶん)。そして、ネットワークデバイスとしてはブリッジを多対多で実装したものがスイッチです*2。仮想スイッチとしてソフトウェア処理だということを考えれば、どちらかといえば仮想スイッチはブリッジよりの存在といってしまっていいかもしれません。つまり、Hyper-Vにおける仮想スイッチの実体は、物理/論理ネットワークアダプターと仮想ネットワークアダプタ―間でのブリッジを論理的にまとめて管理するもの(+仮想ネットワークアダプター間のブリッジングも可能とするもの)、といえるのではないかと思います。もちろん、VLANの管理や、オフロード、拡張機能対応、さらにはネットワーク仮想化への対応など、実際の処理においては単純にブリッジングしているわけではありませんが、Hyper−Vにおける仮想スイッチの実装はブリッジ実装を拡張したものと考えるととてもシンプルに理解できます*3

f:id:takaochan:20140129225453p:image

Windows8のHyper-Vなどで、WiFiアダプタを通じて仮想マシンを通信させたい場合などにおいて、Hyper-Vで構成した内部仮想スイッチと物理WiFiネットワークアダプタの間でブリッジを使用するテクニックはよく知られている方法のようですので、クライアントOSでHyper-Vを触っている人たちにはこの認識は当たり前なのかもしれませんが…(^_^;)

ちなみに、Hyper-Vにおける仮想スイッチの実装が、アップリンクとなるネットワークアダプタ―と仮想マシンの仮想ネットワークアダプタ―間のブリッジとして実装されていると考えると、Hyper-Vでは、仮想スイッチに対してではなく仮想ネットワークアダプタ―毎にVLANや帯域制御など、様々なパラメータを構成する仕組みになっていることも、腑に落ちる気がするのですがいかがでしょうか?

f:id:takaochan:20140129232132p:image

ちなみに、ペアレントOSは仮想スイッチとしての役割を担わない物理ネットワークアダプタ―を自身の通信のために使用することもできますし、「管理オペレーティングシステムにこのネットワークアダプタ―の共有を許可する」のチェックを有効にすれば、仮想スイッチのアップリンク用として使用する物理ネットワークアダプタ―を通じて通信する=ペアレントOSでも仮想ネットワークアダプタ―を使用する、という構成を取ることが可能です。

f:id:takaochan:20140129224232p:image

もちろんその場合、ペアレントOSにも仮想ネットワークアダプタ―が登場します。また、元の物理ネットワークアダプタ―に対して構成されていたネットワークパラメータは、基本的にこの仮想ネットワークアダプターに再割当されます。…が、たまに再割当に失敗します。リモートでこの状態に陥ると、ちょっと悲惨です(^_^;)*4

f:id:takaochan:20140129233204p:image

ネットワークアダプタ―の機能は、それぞれ以下のようになります

仮想スイッチのアップリンクとして使用される物理ネットワークアダプタ―は、すでに上にあった通り、」「Hyper-V拡張可能仮想スイッチ」機能だけが有効となります。ただし、Windowsのチーミング機能を使用してチーミングされた論理ネットワークアダプタ―の場合は、合わせてロードバランシング/フェイルオーバー機能が有効となります。

f:id:takaochan:20140129235323p:image

ちょっと脱線ですが、チーミングのメンバーとなった物理ネットワークアダプタ―では、「Microsoft Network Adapter Multiplexor Protocol」だけが有効となります。

f:id:takaochan:20140129235324p:image

このあたりをもう少し仮想スイッチっぽく?視覚的にも管理できるようにして頂けると、それだけでもだいぶHyper-Vが取っつきやすくなる気がするんですけれどもね!あれ?SCVMMにまったくたどり着いていない…。それどころか、まだSCVMMに入る前に何回かエントリーを書けてしまいそうな気も…。ま、いいや。

では、また次回。

*1:ちなみに、この管理画面において物理ネットワークアダプタ―として認識されているアダプターも、実はCisco UCS専用のネットワークアダプタ―であるVirtual Interface Card (VIC)によって論理的に構成された仮想NICなのですが…まぁその話はまた別のエントリーで。

*2:もちろん、色々違いがあるとは思っていますが…まぁそれはそれということで。この辺りでも読んで下さい…。

*3:通常のブリッジだと、ネットワークの管理画面にブリッジアダプターが表示されるのですが、仮想スイッチ実装ではペアレントOS以外は基本的にすべてVM-Bus経由での接続となりペアレントOSでブリッジを表示する必要性がないためか、表示はされません。まぁされたら余計分かりづらくなってしまいますしね…。

*4CiscoのUCSはOSに依存しないコンソールを提供するCisco IMCを標準搭載していますので安心!とか書いてみたりしてみたり…。

2013/07/01 (月)

[][][] Nexus 1000V をサーバ管理者はどう確認するの?そりゃもちろん、Plug-inでしょ!

前回のエントリー「Nexus 1000V の vTracker はけっこう便利なのです」では、Nexus 1000Vを主にCLIで管理するネットワーク管理者側が、Nexus1000Vが連携している先の仮想化環境側を把握するための機能である vTracker について書きました。では逆に、サーバ管理者側がNexus 1000V側のステータスを把握するためには、どうすればいいのでしょうか?答えはもちろん、vSphere Clientを通じて使用できるPlug-inですよね!、ということになります。

まずそもそもとして、Nexus 1000Vは基本的に物理スイッチと同様の位置づけとしての管理が可能となる点がウリではあるわけですが、ESXiホスト側からはNexus 1000Vも分散仮想スイッチの1種であるという位置づけとなっていますので、サーバ側の構成要素であるという側面もまた併せ持っています。たとえば、Nexus 1000Vに対して各サーバが割り当てるアップリンク用の物理NIC(VMwareにおける管理要素としてはvmnic、Nexus 1000Vにおける管理要素としてはethernetインターフェイス)の割り当てや、VMkernelのインターフェイスであるvmkの接続先ポートグループの設定などは、サーバ側の構成ポイントとして、使用している仮想スイッチがVMwareの標準仮想スイッチや分散仮想スイッチであろうと、CiscoのNexus 1000Vであろうと、同じようにサーバが管理者側が管理する必要がありますし、管理できる必要があります。

そのためNexus 1000Vであっても、そうしたサーバ的な管理要素についてはvSphere Clientを通じて管理することが可能となっています。その上で、スイッチ的な管理要素については「あえて」管理できない様になっています。理由はもちろん、Nexus 1000Vとしての管理をVSM (Virtual Supervisor Module)を通じた管理操作に一元化するためです。裏側では、Nexus 1000VのVSMがvCenterサーバと連携していますので、構成情報をAPIとして流し込むことによって同期されているわけですが。

f:id:takaochan:20130628151935j:image

Nexus 1000VはESXホストにとっては仮想スイッチですが、Nexusの名を冠したCiscoのスイッチ製品でもありますので、Cisco的な管理情報や独自実装を多く持っています。Nexus 1000V vCenter Plug-inでは、そうした、VMware標準では管理されていない、Cisco的な要素についての情報を参照することができます。つまりvTracker同様、Nexus 1000V vCenter Plug-inもまた、参照機能であり、ここを通じて管理操作を行うためのものではありません。構成情報の把握であったり、障害時の対応などに活用するための位置づけとなります。

  • Nexus 1000V vCenter Plug-in提供バージョンおよび使用形態

Nexus 1000V vCenter Plug-inが提供されるNexus 1000Vは、Release 4.2(1)SV2(1.1)以降となります。これはvTrackerと同様ですね。また、Nexus 1000V vCenter Plug-inは、vSphere Web Clientを通じてのみ使用することができます。なお、対応しているvSphere Web Clientは5.1以降となります。vCenterサーバが5.0でもかまいませんが、vSphere Web Clientとしては5.1が使用されている必要があります*1

  • Nexus 1000V vCenter Plug-inの提供形態

Nexus 1000Vは別途バイナリをCisco.comなどから入手いただく必要はありません。導入済のNexus 1000VからHTTP経由でPowerShellスクリプトをダウンロードして実行頂く形態となります。ダウンロードパスは、"http://(VSMのIPアドレス)/vcplugin/registerVCPlugin.ps1"となります。

このPowerShellスクリプトではvCenterサーバなどと通信を行うため、実行環境にはVMwareから提供されているPowerCLIが事前に導入されていて使用可能となっている必要があります。PowerCLIを起動したシェル画面から、ダウンロードしたスクリプトファイルを実行し、プロンプトに回答する形でvCenterサーバのIPアドレスとユーザ名およびパスワード、Nexus 1000V VSMのIPアドレスなどを入力することにより、Plug-inの導入と構成を行うことができます。

f:id:takaochan:20130628151931j:image

(このキャプチャ例では、すでにNexus 1000V vCenter Plug-in導入済の環境に対して再度スクリプトを実行しているため、最後に上書きインストールするかの確認が出てしまっていますが…(^_^;))

  • Nexus 1000V vCenter Plug-inの使用

vSphere Web Clientにログインし、Nexus 1000Vが連携しているvCenterサーバ配下のネットワークインベントリ画面においてNexus 1000Vを選択、[監視]タブを開くと、監視項目としてCisco Nexus 1000Vという項目が追加されています。vSphere Web Clientにログイン後、初めてこの画面を表示した際にはNexus 1000Vに接続するためのアカウント情報が求められます。

f:id:takaochan:20130628151932j:image

接続すると、管理画面が表示されます。

f:id:takaochan:20130628151933j:image

  • Dashboardタブ

Dashboardタブでは、Nexus 1000Vの基本情報を参照することができます。システム情報、ネットワーク情報、ライセンス情報の3項目を確認することができます。

f:id:takaochan:20130628151934j:image

  • Switchタブ

Switchタブでは、Nexus 1000Vとしてのスイッチ管理情報を参照することができます。

    • Host/VEM

ESXホストおよび各ホストのVEM情報、スロット番号、仮想マシン数、仮想NIC数などの情報が参照できます。

f:id:takaochan:20130628151936j:image

    • VM Info

Nexus 1000Vに接続されている仮想マシンおよびVMkernelポートの一覧を参照することができます。特に仮想マシンについては、どの仮想マシンのどの仮想NICがNexus 1000V側ではどういう仮想インターフェイス(Vethernet)として管理されており、それらの仮想マシンが属しているポートグループ、VLAN、ホストID情報などを参照することができますので、Nexus 1000Vを管理しているネットワーク管理者とコミュニケーションするうえで、これらの情報をお互いに把握できていれば話もスムーズに進められるかと思います。

f:id:takaochan:20130628151937j:image

    • Port Groups

Nexus 1000Vを導入している環境の場合、vSphere側から見たPort Group / Nexus 1000V側から見た Port Profileは、Nexus 1000V側が構成することになります。VMware標準の仮想スイッチとして持っているPort Groupレベルの構成情報に加えて、Nexus 1000VではTypeやSystem VLANなどの追加的な要素も含まれているため、それらの情報も含めて一元的に確認することができるのは便利です。

f:id:takaochan:20130628151938j:image

    • vNICs

Nexus 1000V側ではVMkernelや仮想マシンの仮想NICが接続しているポートをVethernetポートして管理しています。そのため、たとえばある仮想マシンの通信がつながらない、といったような場合、サーバ管理者とネットワーク管理者は対象仮想マシンの対象仮想アダプタがどのVethernetポートに接続しているのか、という点について共通に認識したうえで対応を行う必要があります。この画面では、Nexus 1000V側のVethernetポートがどの仮想マシンのどのアダプタから接続されており、それらの仮想マシンが今どのVLAN、どのホストIDのESXi上に配置されているのか、といった情報について、一元的に把握することができます。

f:id:takaochan:20130628151939j:image

    • Uplinks

各ESXホストのvmnicについてもNexus 1000Vとしてそれぞれをポートとして管理しています。仮想マシンおよびVMkernelのためのVethernetとは区別され、Ethernetポートとして表記されます。これらUplinkポートについても、各ESXのどのポートがEthernetポート何番として管理されているのかを確認することができます。Uplinkポートですので、複数のUplinkポートをPort Channelで束ねることができますが、個別仮想マシンの通信経路についてはPinningによって特定のUplinkに紐付けておくことが可能です(もちろん、IP Hashのようにすべてのポートを使用して通信するような構成も可能です)。

f:id:takaochan:20130628151940j:image

  • Hosts/VEM

Switchのように全体ではなく、個別VEM単位での情報を確認したい場合は、こちらの画面の方が便利です。どのホスト名のESXが、Nexus 1000Vでは何番のIDが割り当てられていて、仮想マシンやVethernetポートがいくつ構成されているのか、などの情報に加えて、下部の[VM Info/Port Groups/vNICs/Uplinks]によって、VEM単位、つまりはESXホスト単位での各情報を参照することができます。

f:id:takaochan:20130628151941j:image

いずれの項目も、マウスクリックすることにより、詳細情報をポップアップ表示することができます。

f:id:takaochan:20130628151942j:image

Nexus 1000VはvSphereにおける分散仮想スイッチの仕組みを踏まえつつ、なかなかうまくNexus的な管理と融合させています。もちろん、分散仮想スイッチであるが故に、他の物理的なNexusとは異なる管理構成であったり仕組みも含まれてはいますが、NX-OSとしての管理性はけっこう共通化されています。

VXLANや本日ご紹介したPlug-inも使用可能なNexus 1000VのEssentialエディションは無償ですし、導入後60日間は評価ライセンスで全機能をお試しいただけますので、物理的なNexusを触ったことがある方もない方も、ぜひNexus 1000Vを評価してみてください。そうそう、ちょうど新しいリリースが先日でまして、マルチキャストを使用しないVXLANなども実装されていますよ!

*1:vSphere Web Clientサーバに対して、vCenterサーバの5.0が登録されている構成