vSAN 6.6 Configuration Assist

一通り環境チェックをしてくれるので便利でいいんだけれども、vMotionネットワークをvMotion専用のTCP/IPスタックで構成していると失敗ステータスになるのが微妙。ま、そのうち治るんだろうけれども。これはリリースノートにも明記されているので、既知の問題扱い。
http://pubs.vmware.com/Release_Notes/en/vsan/66/vmware-virtual-san-66-release-notes.html

vMotion network connectivity test incorrectly reports ping failures
The vMotion network connectivity test (Cluster > Monitor > vSAN > Health > Network) reports ping failures if the vMotion stack is used for vMotion. The vMotion network connectivity (ping) check only supports vmknics that use the default network stack. The check fails for vmknics using the vMotion network stack. These reports do not indicate a connectivity problem.

Workaround: Configure the vmknic to use the default network stack. You can disable the vMotion ping check using RVC commands. For example: vsan.health.silent_health_check_configure -a vmotionpingsmall

Workaroundがdefaultのネットワークスタックを利用するか、Ping Checkを無効化するかって…オイ(^_^;)。

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)であるというだけではなく、論理ネットワークケーブルによって上位スイッチの論理ポートに接続されるまでの全体を意味しているということだ。図示するとこんな感じ。

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

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

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

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

…ということで、この三段論法によって、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 と表示される。面白いね。

vCenter Server Appliance のアップグレード 6.0 -> 6.5

SUSEベースからPhoton OSベースに変わるので、一時的に別IPアドレスで仮想アプライアンスをデプロイしてデータを移行することになるわけだけれども、まぁ色々とハマりどころはある。

が、色々ある中で、何をまずやっておけばいいかといえば、VCSA6.0仮想アプライアンスのrootアカウントのパスワード変更。vSphere 6.5のリリースノートにも下記のように記載があるので、おそらくこれが原因で上手くいかない場合が多く発生しているのではないかと推測している。

-Attempts to upgrade a vCenter Server Appliance or Platform Services Controller appliance with an expired root password fail with a generic message that cites an internal error
During the appliance upgrade, the installer connects to the source appliance to detect its deployment type. If the root password of the source appliance has expired, the installer fails to connect to the source appliance, and the upgrade fails with the error message: Internal error occurs during pre-upgrade checks.

Workaround:

  1. Log in to the Direct Console User Interface of the appliance.
  2. Set a new root password.
  3. Retry the upgrade.

日常操作的にはまったく問題なくrootアカウントでのSSHログインなどはできるので気付きづらいが、vCenterサービスに対するSingle Sign-onとしては有効期限が切れている場合、サービスの制御ができないのでアップグレード処理(Pre-upgrade check)に失敗する。

VCSAのrootパスワードそのものがわからん!もしくはログインすらできん!という場合はKB2069041参照。

この点以外にも、リリースノートに書かれている "Upgrade Issues" の項目はどれもアップグレード作業実施前に目を通しておいて損はない気がする。リリースからこれまでいろいろな人達が踏んできた課題の主な項目そのものだと思われるので。

RVC (Ruby vSphere Console)にadministratorアカウントでログインできない場合

vSANについて色々どうにかしたい場合に必要になるRVCだが、ログイン時に使用されるドメインはデフォルトドメインとして指定されている対象が使用される。つまり、たとえば rvc administrator@localhost としてログインする場合、デフォルトの設定を使用している場合は [email protected] アカウントを意味するということになる。

デフォルトドメインを変更したい場合は、vSphere Web Clientにおいてホームから[管理]-[シングルサインオン]-[構成]配下の[アイディンティティソース]タブを選択し、デフォルトに指定したいドメインを選択して[デフォルトドメインに指定]ボタンをクリックする。設定は即時反映される。

その上で、RVCにログインする。以下はVCSAのローカルShellからログインしている場合の例。

Command> rvc administrator@localhost
Install the "ffi" gem for better tab completion.
WARNING: Nokogiri was built against LibXML version 2.7.6, but has dynamically loaded 2.9.2
password:
0 /
1 localhost/
>

参考KB
Cannot log in to the Ruby vCenter Console using administrator@localhost (2088096)
https://kb.vmware.com/kb/2088096

その他、諸々の環境からRVCに接続したい場合については、以下のBlogが参考になる。
http://www.virten.net/2013/12/getting-started-with-ruby-vsphere-console-rvc/

Java Web Startのアプリケーション (.jnlp) で unable to launch the application となって起動しない場合の対処方法

備忘録メモ。はやくフロントエンドのJavaは全部HTML5に置き換わればいいのさ。

  • Java Control Panel
    • [General] - [Network Settings]でProxy経由になっている場合は "Direct Connection" にしてみる
    • [General] - [Settings]で[Delete Files]をしてみる
    • [Security] - [Exception Site list]に対象のアドレスを追記してみる
  • 以下のあたりをフォルダごとごっそり消してみる。
    • C:\Users\username\AppData\Local\Sun
    • C:\Users\username\AppData\Local\Oracle
    • C:\Users\username\AppData\LocalLow\Sun
    • C:\Users\username\AppData\Roaming\Oracle

Detailsを表示させた際に以下の例のように (Unknown Source) とかなっている状態の場合は、おそらくこれで改善する。…たぶん。

com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://x.x.x.x/ucsm/unpacked/ccore.jar
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

もちろん、自己責任で。

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がサポートする・しないという制約条件はありません。

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ルーティングできるという部分は一般的なスイッチと違いは一切ありません。

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


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


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のセキュリティグループを活用することが可能となります。

当然ながら、仮想マシンを含め、すべてのネットワーク接続を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通信にも対応

分散仮想スイッチもACIの一部です! 仮想マシン情報に基づく制御もグループ内セグメンテーションもおまかせあれ。

本エントリーは、 vExpert Advent Calendar 12/18 分となります。

VMwareも会社が大きくなり、製品ラインナップも際限なく増え続けており、もう知らない製品とかよくわからない製品も増えてきましたね。そういう意味でも、vExpert Advent Calendarではエキスパートな皆様が色々な製品について説明してくれるので、このシリーズを通して目を通してみるのはなかなかよい1年の総決算かと思います。

さて、本エントリーはみんな大好きvSphereの基本?に立ち返り、分散仮想スイッチについて書いてみたいと思います。ただし、Cisco ACI (Application Centric Infrastructure) との連携における分散仮想スイッチですけどね。ACIはvSphereとも仲良しですよ、いや本当に。これほどvSphereとの組み合わせで価値を提供できるネットワークもないんじゃないかと、はい。

分散仮想スイッチは、一定以上の規模のvSphereベースの仮想化基盤を運用されている方にとっては、必須ともいえる機能でしょう。ESXiホストの台数が増えてくると、ホスト毎に標準仮想スイッチを個別に設定・管理する様な運用は現実的ではありません。分散仮想スイッチはESXiホストの枠を超えて、vCenterサーバによって管理されているデータセンターの範囲内であたかもESXiサーバを跨って伸びた巨大な仮想スイッチが存在する様なイメージで管理することができます。

…で、そんな分散仮想スイッチですが、市場の中ではVMware標準の分散仮想スイッチ(以下、vDS)と、CiscoのNX-OSベースでの管理・運用を可能としたNexus 1000vの2つが、商用レベルで現時点でも選択肢となりえる分散仮想スイッチソリューションといえるでしょう。本エントリーの公開時点ではまだ正式に vSphere 6.5対応したNexus 1000vはリリースされていませんが、近いうちにリリースされるでしょう。きっと。

さて、ここからが本題です。

Ciscoはデータセンター向けの統合ネットワーク基盤としてACIを提供しています。ACIはSDNの一種として見られることも多いのですが、私としてはSDN的にも使えるし、これまでのネットワークの延長線としてよりシンプルに管理・運用できるネットワークとしても使えるし、さらには単なるSDNに留まらない、現実的なスケール性や管理性を併せ持ちつつAPI制御や各種管理ツールとの連携なども可能とするネットワーク技術だと思っています。

ACIではスイッチハードウェアのNexus 9000とコントローラであるAPICを使って、アプリケーション視点の論理モデルをデザインするだけで自動的に仮想・物理の壁を越えた構成が作られる仕組みを実現しています。

ACIでは様々な識別子に基づいてあらゆるネットワーク接続要素(End Point = サーバ、F/W、L/B、ルータなど)をEPG (End Point Group)としてグルーピングし、EPGEPGの間を通信ルールを定めたContractで結びつけるとそのEPG間での通信ができるようになったり、通信ルールとして定めたF/WやL/Bなどを使用する構成とすることができたりします。本エントリーはACIと分散仮想スイッチにフォーカスしますので、ACIの技術については必要最小限のみとしますが、「アプリケーション視点の論理モデル」を構成する2つの要素、EPGとContractについてはこの後の説明をご理解いただくうえで必要となりますので、覚えておいてください。

ACIはネットワークですので、どのベンダーのどんなネットワーク機器であっても、仮想マシンでも物理サーバでも、UNIXでもホストコンピュータであっても、IPプロトコルさえ使っていればご利用頂けます*1。そんなわけで、もちろんvSphere環境との組み合わせでもご利用頂けます。ACIとvCenterの間で管理連携せずに使用するのであれば標準仮想スイッチでももちろんご利用頂けますが、分散仮想スイッチが使用可能なのであれば、vCenterサーバとACIの管理コントローラであるAPIC (Application Policy Infrastructure Controller)とを管理連携を構成すると、もはや分散仮想スイッチをACIファブリックネットワークの一部として一体化してご利用頂くことができるようになります。ハードウェアの性能や可用性・信頼性に基づきつつもソフトウェアの管理性・柔軟性を活用することができる、という点がACIのメリットと言えるでしょう。

APICとvCenterの管理連携を構成すると、このようにAPIC側からもvCenterを通じて仮想マシンやvDSのネットワーク情報等を確認することができるようになります。

もちろんvDSをACIと連携して使用できますし、このエントリーでご紹介する様々な機能も使えますので、多くの場合においてはvDSをそのままご利用頂ければと思うのですが、CiscoはACI用として拡張されたNexus 1000vとして、Application Virtual Switch (以下、AVS)の提供もしています。ACIと組み合わせてしか使用できない代わりに!? AVSは特に追加コストなくご利用いただけますし、通信プロトコルとしてVLANだけでなくVXLANを使用することも出来るなどの機能的な違いもありますが、vDSとAVSのどちらを選ぶのかは、私個人としてはAVSを使用するとメリットのあるパターンに該当する場合にはAVSを、それ以外の場合にはvDSを使うという判断で良いのではないかと思います。

AVSを選ぶべき、もしくは選ぶと管理がしやすくなるパターンとしては、以下の4つがあります。

  1. ESXiホストがACIファブリックを構成しているNexus 9000もしくはNexus 2000 (FEX)に直接接続もしくは1段のみスイッチを挟んで接続されていない(つまり2段以上のスイッチを挟む)構成の場合
  2. 同一ESXiホスト上の仮想マシン間の通信についても通信監視を構成したい場合
  3. L4 StatefullなFirewall機能をFirewall専用機を使わずに構成したい場合
  4. ESXiホストにブレードサーバを使用している場合

1〜3についてが要件となる場合は、AVSを使用する必要があります。

1は接続検出の方式の違いによる理由です。vDSの場合はCDP/LLDPを使った隣接検出が使用されますが、AVSの場合はOpFlexプロトコルを使った連携動作が使用されます。

2はACIファブリックが持つ柔軟な通信のミラーリングなどの機能を活用するためにAVSをホスト内ではスイッチングを行わないモードとして使用する方式です。Nexusシリーズにおいて遠隔拡張ポートとして使用できるFEXことNexus 2000シリーズと同じような構成をACIファブリックとAVSの間で構成するようなパターンといえるでしょう。

3はAVSが持つStatefull機能を使って、行きパケットに対する戻りパケットを認識することによって、SYN+ACKアタックのような攻撃からネットワークを守りたい場合などに使用できます。

4のブレードサーバをESXiホストとして使用する場合については、AVSでVXLANモードとして構成することによりネットワークを追加で必要とする際に都度VLANをブレードサーバとACIファブリック間をつなげるスイッチに設定する作業を不要にすることが出来るという意味で「管理がしやすくなる」パターンといえます。

さて、本日はACIと分散仮想スイッチ(vDS/AVS)を組み合わせることによってもたらされるメリットの1つとして、uSeg EPG機能とIntra EPG Isolation機能を御紹介します。これらはいずれも、いわゆるマイクロセグメンテーションだと紹介すればVMwareなヒトにはわかりやすいのでしょうが、マイクロセグメンテーションだけに限られない、非常に面白い機能です。

uSeg EPG機能

ACIの基本は、EPGEPGを結びつけるContractであると説明しましたが、「どのようにEPGに紐付けるのか」こそが重要なポイントとなります。仮想マシンEPGに紐付ける場合、通常は分散仮想スイッチ連携を用いる場合にはEPGに紐付いて自動的に作成されるポートグループに仮想マシンを接続することによって、そのEPG仮想マシンが接続された状態となりますが、これだけがEPG仮想マシンを紐付けるやり方ではありません。uSeg EPGは、通常のEPGとポートグループとの紐付けに優先して、特別な条件に合致する仮想マシンに対して異なるEPGへのマッピングを実現する方法です。

特別な条件としては、IPアドレスMACアドレスも使用できますし、さらにはvCenterサーバから得た情報を活用することも可能になっています。使用可能なvCenter情報は色々な種類があり、連携対象のvCenter毎や、ゲストOS種別、Hypervisor種別、データセンター、VM ID、VM名、vNIC毎などがあります。もちろん、これらの条件を複数組み合わせて識別条件とすることが可能です。

これらの条件に合致するEPGに対してどのような通信ルールを適用するのかについても、Contract次第です。特定の文字列を仮想マシン名に含むVMだけを対象としたり、あるゲストOSがインストールされているVMにだけに特別な通信ルールを適用させたりなど、この機能によって、これまでは簡単に出来なかった動的なネットワーク制御が可能となります。

なお、このuSeg EPG機能は、vDS*2であってもAVSであっても使用できます。Hyper-Vホストと連携している場合でも使用でき、今後KVMやContainer連携でも使用できるようになっていく予定です。

Intra EPG Isolation機能

EPGEPGの間では、Contractによって通信が許可されない限りVLANが同じであろうと同じサブネットに属していようと通信できない状態が基本となるのですが、同一EPG内についてはデフォルトでは一切の通信制限がない状態となっています。Intra EPG Isolation機能を有効にすると、いわばPrivate VLANとして動作し、EPG内のEnd Point同士の間では通信はできなくなります。他のEPGとの間については、元の通りContract次第で通信可否は決定されます。

このIntra EPG Isolation機能ももちろんvDS/AVSの両方で使用可能ですし、物理サーバの場合であっても使用できます。Hyper-VおよびKVMについては今後対応予定です。

もちろん、uSeg EPG機能とIntra EPG Isolation機能は併用することができます。uSeg EPG機能については、APICAPIを通じて取得可能な情報であれば、どのようなものであっても条件情報として使用することができるので、今後、より様々な情報が使用できるようになっていく可能性があります。

また、ACIはvSphereやHyper-Vなどの仮想化基盤とも、シスコ以外の各社の物理・仮想両方のL/BやF/Wとも連携が可能となっていますので、仮想マシンEPGへの紐付けのマッピングにおける柔軟性と、各社L4-7デバイスとの連携の2面を結びつける、非常に面白いネットワークの仕組みを提供できる基盤となっています。

vCenterサーバとの連携だけにとどまらず、ACIはvRealize Automation/Orchestratorとの連携や、vCenterプラグインを通じたvSphere Web Client経由での管理機能の提供など、様々な連携がすでに提供されています。こちらはvCenterプラグインで、ASAによるF/WとF5のL/Bが挟み込まれたContractを参照している画面です。

今後も引き続き、両社の技術の連携によって様々な価値をご提供できたらいいですね。

*1:最新のACIではFCoE NPVにも対応していますので、SANも統合可能です。

*2:vDSの場合ESXiホストが、物理サーバの場合は当該物理サーバが、接続されているACIファブリック構成スイッチが-EXモデルである必要があります。