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/06/07 (水)

[]APIとか言われましても…な人向けの便利機能(UCS ManagerのGUI操作をスクリプトに自動変換)

CiscoはUCSの管理操作をPowerShellから実行するためのPowerToolと呼ばれるCmdletプラグインや、Pythonから実行するためのPython SDKなどを提供している。PowerToolの方はもう正式サポート範囲なのでcisco.comから、Python SDKの方はまだバージョン0.9扱いでコミュニティサイトから入手する形になっている(どちらもDevNet経由でも入手可能)。

PowerToolの方のオブジェクト数を数えてみると2300を超えている。基本的にUCS ManagerのGUI操作でできることは、PowerToolを用いたPowerShellスクリプトでも操作できるといっていい。

f:id:takaochan:20170606163901p:image

でも、だからといってすぐにスクリプトを活用した運用を実践できるかというと、なかなか難しいであろうこともまた事実。ちょっと頑張れば人力処理で片付いてしまう設定変更などをスクリプト化する労力をかけるかどうか迷っているうちにずるずると、といった場面も多いんじゃないかと思う。

そんな場合に便利なのが、GUI操作をスクリプトに変換してくれる機能。もちろん、これだけで運用に必要なスクリプトを準備できるわけではないけれども、GUI操作とスクリプトを結びつけて確認することができるので、スクリプトをどう書けばよいのか参考にすることができるし、まずはパラメータを手作業で修正して使用するだけでも、GUI操作あるあるであるオペミスを削減することもできるだろう。次に変数部分を代入できるようにすれば、立派に自動化の第一歩だし、さらに繰り返し処理で展開や構成変更などをできるようにしてしまえば、オペミスも無ければ無駄なことに時間が取られることもない、ステキな運用が実現できる。

現状、UCS ManagerにはJavaアプレット版とHTML5版がある。方法は違えども、どちらを利用した場合でもGUI操作をスクリプトに変換できる。

Java版の場合はローカルでネイティブアプリ(JavaVM経由ではあるけれど)として動作するので、ログファイルをリアルタイムで監視することによって操作を即スクリプトに変換させることができる。

f:id:takaochan:20170606163902p:image

HTML5版の場合は、ログファイルをローカルに吐き出すことがちょっとむずかしいので、操作ログをXMLとして生成した上で、それを元にスクリプトを生成させるという手順になる。下記のように、HTML5版のUCS Managerにログイン後、Ctrl-Alt-Qを押すと画面上部に[Record XML]というリンクが表示されるので、ログに記録したい操作を開始する前にクリックし、必要な操作を終えたら再度同じ場所にある[Stop XML Recording]というリンクをクリックしてログファイルを出力させればよい。

f:id:takaochan:20170606163903p:image

あとはJava版の場合とほぼおなじ。ただし、リアルタイムでは変換は行えないし、ログファイルを指定する必要がある。

f:id:takaochan:20170606163904p:image

このログファイルからは、PowerShellスクリプトだけでなく、Python SDKを用いてPythonスクリプトに変換することもできる。

f:id:takaochan:20170606163905p:image

まずはこうした機能を使って、何度も繰り返すことが多いGUI操作からスクリプト化してみる、という辺りから始めてみるのはいかがでしょうか?

2017/05/25 (木)

[]ESXiホストにNexus 1000v/AVS の VEM (Virtual Ethernet Module)をアンインストール・インストールする手順

vSphere ESXiホストの分散仮想スイッチを拡張するNexus 1000vやAVS(Application Virtual Switch)では、Kernelモジュールに加えてユーザランドでVEMの管理プロセス(VEM Agent/vemdpa)が動作している。インストールしているバージョンなどはesxcliコマンドで確認することが可能。

[root@esx3:~] esxcli software vib list | grep cisco-vem
cisco-vem-v365-esx             5.2.1.3.2.14.0-6.0.1                   Cisco   PartnerSupported  2017-03-28

ちなみに上記は Cisco ACI のための 拡張分散仮想スイッチである AVS の例となっているので、サポートレベルは PartnerSupported となる。最新のVEMは vSphere 6.5 もサポート。まぁVMwareは将来的にパートナー向けに公開していたAPIを塞ぐらしいが…。

さておき、VEM Agentはvemコマンドを通じて様々なVEMの情報を取得したり管理操作を行ったりすることができるツールで、以下のようにvemコマンドでバージョンやステータスなどを確認することが可能。

[root@esx2:~] vem status

VEM modules are loaded

Switch Name      Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch0         4082        6           128               1500    vmnic2,vmnic3
vSwitch1         4082        3           128               9000    vmnic4,vmnic5
DVS Name         Num Ports   Used Ports  Configured Ports  MTU     Uplinks
VMM-AVS-DC2      1024        18          1024              1500    vmnic1,vmnic0

VEM Agent (vemdpa) is running

stopDpa
VEM SwISCSI PID is
Warn: DPA running host/vim/vimuser/cisco/vem/vemdpa.37515
Warn: DPA running host/vim/vimuser/cisco/vem/vemdpa.37515
watchdog-vemdpa: Terminating watchdog process with PID 37507

このように常時VEM Agentが動作している為、単にesxcliコマンドで削除しようとしても下記のようにエラーとなる。

[root@esx3:~] esxcli software vib remove --vibname cisco-vem-v365-esx
 [LiveInstallationError]
 Error in running rm /tardisks/cisco_ve.v00:
 Return code: 1
 Output: rm: can't remove '/tardisks/cisco_ve.v00': Device or resource busy

 It is not safe to continue. Please reboot the host immediately to discard the unfinished update.
 Please refer to the log file for more details.

よって、VEMのアンインストール操作を行う場合は、仮想マシンの退避と分散仮想スイッチからのホストの削除を行った上で、さらにvem stopコマンドでVEM Agentを停止させる必要がある。VEMをアンインストールしなければならない状況としては、AVSは冒頭で書いたとおりPartnerSupportedのモジュール扱いとなるため、ESXiホストを6.0から6.5にアップグレードする場合などは一旦アンインストールした上で実施する必要がある。

VEMがインストールされたままでESXiを6.0から6.5にアップグレードしようとすると、以下のようなエラーになる。これはISOファイルを使ってアップグレードしようとした場合の例。

f:id:takaochan:20170524174927p:image

VEMはvibファイルとして提供されているので、ESXiホストのアップグレード後に改めてesxcliコマンドでインストールすれば良い。一旦アンインストールしているので、アップグレードではなくインストール。

[root@esx3:~] esxcli software vib install -v "http://x.x.x.x/Cisco/ACI/2.2(2e)/CiscoAVS_3.2-5.2.1.SV3.3.2-pkg/CiscoAVS_3.2-5.2.1.SV3.3.2/CiscoAVS_3.2-5.2.1.SV3.3.2
/cross_cisco-vem-v395-5.2.1.3.3.2.0-6.5.1.vib"
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: Cisco_bootbank_cisco-vem-v395-esx_5.2.1.3.3.2.0-6.5.1
   VIBs Removed:
   VIBs Skipped:

こんな感じで、ESXi 6.5でもちゃんとAVS用のVEMは動作しておりますョ(*´艸`*)

[root@esx2:~] vem version
Running esx version -4564106 x86_64
VEM Version: 5.2.1.3.3.2.0-6.5.1
OpFlex SDK Version: 2.2(2e)
System Version: VMware ESXi 6.5.0 Releasebuild-4564106
ESX Version Update Level: 0

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からも、APICのGUIからも、仮想マシン毎に認識することができるようになります。

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通信にも対応

2016/12/18 (日)

[]分散仮想スイッチも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を使って、アプリケーション視点の論理モデルをデザインするだけで自動的に仮想・物理の壁を越えた構成が作られる仕組みを実現しています。

f:id:takaochan:20161217210213p:image

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

f:id:takaochan:20161217210214p:image

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

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

f:id:takaochan:20161217210209p:image

もちろん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プロトコルを使った連携動作が使用されます。

f:id:takaochan:20161217210210p:image

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

f:id:takaochan:20161217210211p:image

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

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

f:id:takaochan:20161217210212p:image

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

uSeg EPG機能

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

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

f:id:takaochan:20161217210215p:image

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

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

Intra EPG Isolation機能

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

f:id:takaochan:20161217210216p:image

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

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

また、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を参照している画面です。

f:id:takaochan:20161217210217p:image

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

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

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

2016/11/22 (火)

[]VCSAのShellモード(Appliance Shell/Bash Shell)

自分で設定しておいて忘れていたのだけれども、vCenter Server Applianceは普通以下のAppliance Shellがデフォルトになっている。

この場合、Bash Shellに移行するには KB2100508 にあるとおり、shell.set --inabled true したうえで shell すればよい。

Using username "root".

VMware vCenter Server Appliance 6.0.0.20000

Type: vCenter Server with an external Platform Services Controller

Last login: Tue Nov 22 01:11:50 2016 from 172.16.254.1
Connected to service

    * List APIs: "help api list"
    * List Plugins: "help pi list"
    * Enable BASH access: "shell.set --enabled True"
    * Launch BASH: "shell"

Command>

でも、私の環境では自分で昔設定したんだろうけど、Bash Shellが最初に表示されるようになっていた。上記KBにもあるけれど、おそらく chsh -s /bin/bash root してデフォルトをBashに変更していたっぽい。

この状態からデフォルトのAppliance Shellに戻すには、まぁKBにあるとおり chsh -s /bin/appliancesh root して一旦Shellをログアウトすればよい。

ただの備忘録。

2015/12/05 (土)

[] VIX APIってご存知ですか? - vExpert Advent Calendar

vExpert Advent Calendar 12/5 エントリーです。

VMware仮想マシンを実行する製品には、共通してVIX APIというAPIが用意されています。公式のVMwareウェブサイトではこちら。

https://www.vmware.com/support/developer/vix-api/

このAPIは、vSphere ESXiはもちろん、WorkstationやPlayer、そしてFusionでも使用することができる共通のものとなっています。

…で、このAPIを使うと何ができるかといいますと、VMware Toolsがインストールされて動作しているゲストOSに対して、ネットワークを通すことなく様々な制御をすることができます。いわば公式なバックドア(^_^;)として使用することができる…とまで言うといいすぎですが、まぁ悪いこともできなくはないですね。

Workstation環境だと、こんな感じの仕組みとなります。

f:id:takaochan:20151205172208p:image

この機能はデフォルトが有効です。無効にしたい場合は、vmxファイルに以下の指定します。ESXiホストの場合は、/etc/vmware/config で指定することによってホスト全体で無効化することも可能です。

guest.commands.enabled = "FALSE"

この情報に関するVMwareのKBはこちら。

http://kb.vmware.com/kb/1010103

その他、VIX APIはセキュリティリスクになり得ますので、気になるという方は以下の情報を一読されることをオススメします。

https://www.vmware.com/support/developer/vix-api/vix115_reference/security.html

上記公式サイトにサンプルのコードもあります。以下のリファレンスページに、設定方法や使い方なども載っています。CやPerl、C#などに対応しています。

https://www.vmware.com/support/developer/vix-api/vix115_reference/

vSphere 5 からは以下のようにVIX APIはvSphere APIの一部となっています。そのため、vCenterサーバを通じてゲストOSに対して処理を投げることができるようになっています。

f:id:takaochan:20151205171959p:image

そんなわけで、ためしにLinux環境からvCenterを通じてESXiホストで実行される仮想マシン上で動作するゲストOSに対してVIX APIを通じてコマンドを実行してみるサンプルプログラムを作ってみました。

[root@localhost tmp]# ./vixtestcommand http://(vCenter IP Address)/sdk (vCenter Account) (vCenter Password) "[(Datastore)](VM Folder)/(VM Name).vmx" (Guest OS Account) (Guest OS Password) (Script)
DEBUG: Success jobHandle  34603071
DEBUG: Success hostHandle 34603070
DEBUG: Before Opening VM
DEBUG: Opening VM....
DEBUG: Opened the VM
DEBUG: waiting for tools
DEBUG: tools up
DEBUG: logged in to guest
DEBUG: about to execute remote command
DEBUG: about to execute remote command (Script)
DEBUG: with args
Script execution status is 0
Script command exitCode is 0
DEBUG: execution completed....

おー、ちゃんとvCenterを通じて、仮想マシンが実行されているホストに接続し、仮想マシンに接続し、VMware Toolsを通じてゲストOSに接続し、コマンド実行されました。こんな感じで、ゲストOSがネットワークにつながっていなくても、vCenterサーバの管理者アカウントとパスワード、そしてゲストOSのアカウントとパスワードさえわかっていれば、ゲストOSに対する処理を実行できます。管理環境からネットワーク的な接続性のないゲストOS環境に対して処理を実行することができますので、上手く使えば仮想マシン展開後の管理に便利に使えそうです。

ただ、ゴメンナサイ、このサンプルプログラムには一部オープンになっていないコードを含む可能性がある拾い物を8割ぐらい使ってささっと作ってしまったため、コードの公開は残念ながらできません…。ただ、上記のサンプルコードとリファレンスの情報があれば、同じようなプログラムを作ることはそんなに大変ではないのではないかと思います。

Happy Cording!!

え、プログラミングとか面倒?そんな方にはCisco UCS Director(^_^;)。VIX API機能を簡単に使えるワークフローを書くことができる機能が標準で実装されています。すぐにVIX APIを活用できますよ!!

f:id:takaochan:20151205173122p:image

http://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/ucs-director/vix-script/VIXScriptUseCaseGuide.pdf

Enjoy Happy Life!!

2015/12/04 (金)

[] ACI本刊行記念!! ACIとNSX - vExpert Advent Calendar

vExpert Advent Calendar 12/4 エントリーです

本日、皆さま待望の『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』がついに発売されました!!

よく知りませんが本書は何千部もは刷られていないと思うので、大きな書店かAmazonなどオンラインでぜひお買い求めください(帰りに忘年会行く前に本屋さんへGo!)。なかなか技術書が売れないご時勢ではありますが、ACI関連本もVMware関連本ぐらいは売れる様になるといいんですけどね。

なお、本書の著者の一人 Lucien Avramov は大の日本好きでこれまでも何度も日本に訪問しております。まだ未定ですが、年明け2/24の開催を予定している ACI友の会#3 にもしかしたら…。乞うご期待。なお、Twitterでもつぶやきましたが、何らかのかたちで私とつながっている方で、本書を買ったという方には、ご希望であれば英語版の本書を差し上げます(私の手元に在庫がある限り…)。ACIの理解を深めるついでに英語の勉強にいかがですか?(^_^;) 何らかの方法でご連絡ください。

…と宣伝っぽい内容はそれくらいにして…vExpert Advent Calendarでこのネタはどうなんだってご意見もおありでしょうが…どなたか譲るよ!って書いたのに誰も手を上げないんだから仕方がない!縛りなしってルールだし!そして別に何かをディスるつもりもないし(^_^;)!!

そんなわけで、本エントリーでは『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』日本語版の出版を記念して?、いいとか悪いとかではない視点のCisco ACI (Application Centric Infrastructure) /VMware NSX論を少し書いてみたいと思います。お約束としては、あくまでも個人の意見、個人の視点です。会社の人間として喋るときにはちょっと別の言い方をしているかもしれません(^_^;)。また、あまりテクニカルに深くは踏み込みません。

本書『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』の英語版はほぼ1年前に出版されたものですので、ACIの情報としては残念ながらすでに最新の内容ではありません。原著が出版された時点ではまだ対応していなかった機能や構成が可能になっている部分もすでに沢山あります。今月リリース予定の新バージョンでも、すでにこちらのオフィシャルブログなどでも触れられている通り、かなり楽しみな機能が数多く追加・拡張されていく予定です。ACIは新しい製品ですので、まだまだ積極的に様々な機能が追加・拡張されているフェーズにありますが、そうした新機能の学習という目的には本書はあまり適していないかもしれません。しかしタイトルの通り、本書は主にはアーキテクチャ、コンセプト、メソドロジーなどといった、バージョンがあがったり機能が拡張されていったとしても陳腐化することのないそもそもの部分、つまりはACIの根本的な思想・考え方といった内容に比較的比重が多く割かれていますので、ACIを表面的な部分だけでなくしっかりと「どういう考え方に基づいてACIはデザインされているのか」といった基礎的な部分から理解されたい方にとっては、今読んでも十分にお役に立てる内容が詰まっているのではないかと思っています。

さて、本エントリーではACIそのものについてはあまり書くつもりはありません。そのあたりはぜひ本書をお読みください(しつこい?といっても、本書が売れても別に私には1円も入ってきませんけど)。このエントリーで書きたいテーマは「手段としてのネットワークを活用するために」といったようなふわっとした感じの内容です。

OpenStackやDocker、そしてもちろんSDNなど、最近はコンピューティングの側面から見てもネットワーキングの側面から見てもITインフラストラクチャに求められることが大きく変化しつつあります。トレンドや技術動向をしっかりと把握しておくことは大切ですが、そうした情報に流されて「わが社もクラウドだ!」「SDNを導入しよう!」などとそれ自体を目的化させてしまわずに、ぜひ自社のIT基盤に求められているもの、ひいてはビジネスを支える要素として求められているものは何なのか、といった目的をしっかり踏まえたうえで、手段としてこれらの新しい流れを活用することができるのかどうか、冷静に検討頂ければと思います。

この流れを生み出したきっかけはやはりサーバ仮想化技術にあるでしょう。2000年代中ごろから現在にかけてのVMwareの飛躍はまさにそれを体現したものといえます。サーバ仮想化はITインフラリソースをソフトウェア的に構成することができる時代への入り口を開いたと言えます。その流れはインターネットの普及と高速化と相まってパブリッククラウドへとつながり、そして現在では雲の向こう側かこちら側かなどといった違いを超えて、どのような形態であろうとも、ITリソースは「必要なときに、必要な対象に対して、必要なリソースを、必要なだけ」提供することを可能とするサービス化された仕組みが求められるようになりつつあります。

サーバの役割を持つコンピュートリソースは物理サーバであろうと仮想マシンであろうと、そして最近ではコンテナであろうとその上で提供されるサービスという視点から見るとどのような形態で仕組みが作られていようと関係ないわけで、ITインフラリソースの要素の中で最も論理化が進みやすい要素でした。そしてまずは「それまで使われていた」タイプの企業が必要としているいわゆるクライアントサーバ型的なエンタープライズアプリケーションであっても問題なく使用できるサーバ仮想化が普及し、そして「これから使われていく」タイプのモジュール同士がAPIやQueueで結び付きながらブラウザやアプリを通じて柔軟にサービスを提供していく新しいカタチのアプリケーションが次第に広まっていく中で、Dockerのようなもはや仮想化ですらないアプリケーション実行環境そのものを展開する仕組みへと発展しつつあります。

このITリソースのサービス化の流れは当然ストレージやネットワークにも波及し、その流れの中でネットワークの範囲としてはCiscoのACIやVMwareのNSXが登場してきたと言えます。

そんなACIは確かにネットワークのソリューションではあるのですが、その根本的な製品思想はこれまでの企業ネットワーク製品とは大きく異なっています。そういう意味では、既存ネットワークの延長線上として「ソフトウェア的に論理的なネットワークを作ることによってネットワークの構成管理運用の柔軟さと展開の速さを高めよう」という、いわゆるSDNという括りにも収まるのだろうか?と思う部分も多くあります。まぁSDNという括り自体も人それぞれなので、括りに収まるもなにもないのかもしれませんが。

また、SDNをどう捉えるのか、という問題でもあるかと思うのですが、SDNをソフトウェア「だけ」で実現する新たなネットワークと考えるのだとしたら、物理的なハードウェアスイッチであるNexus 9000シリーズに依存したソリューションであるACIはそもそもSDNではないということになってしまいます。しかし、SDNをソフトウェア「によって」実現する新たなネットワークと考えるのであれば、ACIの論理的な側面は完全にAPIによって制御が可能なソフトウェアとしての側面を持ちます。ハードウェアによる処理性能・安定性と、ソフトウェアによる論理的なデザインと構成、その両面をACIは併せ持っています。

ACIは単に「これまでのネットワークの要素をソフトウェア化する」(=ネットワーク仮想化?)ものではありません。ネットワークリソースにサービス化が求められるなら、それはどうあるべきなのか?という根底から検討し、それを実現する手段として最適なかたちを目指して製品化されたソリューションです。そんなわけで、ACIに対しては、わかりづらい/よくわからない、既存のネットワーク管理のノウハウやナレッジが通用しないのではないか、アプリケーション視点のポリシー管理?これまでとまったく違う管理手法を取り入れるのには抵抗がある、など等のご意見が多数あることは事実かと思っていますし、そうであるからこそ、ACIのアーキテクチャ、コンセプト、メソドロジーといった部分をご理解いただくために本書のようなものが必要だと思っています。

会社としても、そして世の中としても、CiscoのACIとVMwareのNSXは競合であるとして色々なところで扱われています。確かに「新しいネットワークのカタチ」としてお客様がいわゆるSDNを検討された際に土俵に上げられるソリューション同士であるという意味では、競合といえる部分はあるかと思います。しかし、両者を見ているとおそらく次第にこの2つのソリューションは別のものであるという認識が少しずつ理解されていくのではないかとも思っています。

NSXの強みの1つは、やはりvSphere環境との高い密結合にあると思います。vSphere環境を前提としたNSX-vとNiciraの流れを持つNSX-MHがありますが、おそらく前者が次第に拡大していく方向で統合されていくことになるのではないかと思われます(中の人じゃないので知りませんけど)。NSXのコンポーネントには仮想アプライアンスとしていわば仮想マシンの一種として存在している要素(主にNorth-South方向の通信に関わる)と、ESXiのVMkernelの中に組み込まれる要素(主にEast-West方向の通信に関わる)の両方がありますが、NSXの肝はVMkernelに組み込まれて動作する分散仮想ルータや分散仮想ファイアウォールにあると思います。VMkernelに組み込まれるからこそ、vSphere環境の仮想マシンとの親和性が非常に高く、かつ他社にはまねできないソリューションを実現することができているわけです*1。NSXはサーバ仮想化のESX同様にハードウェアとしてのネットワークに依存しない(土管化?)仕組みを実現することを基本思想として持っているので、仮想アプライアンスとKernelモジュールでネットワーク機能を実現する仕組みはそれを体現する実装といえると思います。

f:id:takaochan:20151204134109p:image

逆にACIは、特定のホスト側の仕組みには依存しない、ということを設計思想に持つ疎結合型のソリューションです。特定のHypervisor、特定のOS、物理仮想の違いなどに依存せずに、あらゆるコンピューティングの形態に対して統一されたポリシーを提供することができます。しかし逆にハードウェアとしてのネットワークには強く依存する実装であるため、物理スイッチであるNexus 9000、そして物理アプライアンスとして提供されているAPIC (Application Policy Infrastructure Controller)と、ACIを使用するためには前提としてハードウェアが必要です。ACIを多くの基盤でご利用いただきたいと考えていますが、誰もが必要とするものでもないとも考えています。論理的なネットワークを動的に追加・構成・管理・変更していく、いわばネットワークに柔軟性を求める使い方をしたいという場合にはACIはとても有用ですが、静的に安定して個々のスイッチが自立分散して動作していてシンプルに広帯域・低遅延の拡張性のあるネットワークが欲しいという場合には、ACIではなく、いわゆるイーサネットファブリック的な使い方の方が向いているかもしれません。また、これまでどおりの、各ネットワーク機器を個別に構成し、標準化されたルーティングプロトコルなどによって情報交換は行っても各機器は自立して動作する使われ方は、SDNの登場によって使われなくなるということもないと思います。これらの向き不向きは業種や規模というよりも、ネットワークに求めている「使い方」次第といえるでしょう。

f:id:takaochan:20151204135639p:image

この先しばらくの間はSDNという括りでCiscoのACIとVMwareのNSXについては両者の比較やら競り合いやら色々な情報がニュース記事や両社からの発表などによって出てくることになると思います。しかし、5年後ぐらいにはきっと、ルータとスイッチほどとは行かないまでも、CiscoのスイッチでいえばNexusとCatalystぐらいのカタチで目的や使われ方が違うものとして認知されるようになっているのではないでしょうか。

明日のvExpert Advent Calendarもなぜか私なので、明日はまったく今日とは正反対の感じで短めのエントリーでVMwareがらみの小ねたを紹介したいと思います。

*1VMware以外のいわゆるサードパーティベンダーがVMkernelに組み込まれて動作するソフトウェアを実装することができないわけではありませんが、vSphereそのものの進化にきちんとアラインされたかたちで継続的にリリースしていくことはVMware以外にはかなりハードルが高いといえます