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

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

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 |

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)としてグルーピングし、EPGEPGの間を通信ルールを定めた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の基本は、EPGEPGを結びつける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機能

EPGEPGの間では、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機能については、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を参照している画面です。

f:id:takaochan:20161217210217p:image

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

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

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

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証