このエントリーは、Cisco Advent Calendar 2020 および vExpert Advent Calendar 2020 の12/7分として公開しています。
Cisco Advent Calendar 2020 は今年は2枚ありますので、ぜひ他のエントリーもお読み下さい!! 過去のCisco Advent Calendarへのリンクもあります。
- Cisco Advent Calendar 2020 1枚目 https://qiita.com/advent-calendar/2020/cisco
- Cisco Advent Calendar 2020 2枚目 https://qiita.com/advent-calendar/2020/cisco2
vExpert Advent Calendar 2020 はこちらです。ぜひ他のエントリーもお読み下さい!! 過去のvExpert Advent Calendarへのリンクもあります。
- vExpert Advent Calendar 2020 https://adventar.org/calendars/5343
まず初めに、2つのAdvent Calendarへの参加を1つのエントリーでまとめて済ませようという横着者の私をお許し下さい…(・・;) ちょうど、両方の要素が入っているんです…。
あと、このエントリーには全くプログラミング的な要素もCLI的な要素も1行も登場しません。Qiitaさん、スミマセン(・・;)
ただその分、ボリューム厚めに書きました!!昨年に続き、これはもはや読み物です(・_・;)
ちょっと長めですが、お時間ありましたらお読み頂けると嬉しいです。
はじめに
国内ネットワーク仮想化／自動化プラットフォーム市場シェア
IDCが2020/9/3に発表した「国内ネットワーク仮想化／自動化プラットフォーム市場シェア」では、提供形態を切り口として「NVO (Network Virtualization Overlay)ソフトウェア」と「コントローラアプライアンス」の2つに分類した国内市場シェアが発表されており、NVOソフトウェア市場ではVMwareが 76.9%、コントローラアプライアンス市場ではCiscoが66.7%となっていました。いずれも前回2019年の調査時点よりもシェアを拡大する状況となっており、国内のSDN市場も次第に成熟とともに製品毎に明暗が別れ、淘汰も進み、良くも悪くも収斂されつつあるようにも見えます。
IDCの「国内ネットワーク仮想化／自動化プラットフォーム市場シェア」については以下URLを参照下さい。
https://www.idc.com/getdoc.jsp?containerId=prJPJ46799620
このシェアのカウント対象としては、VMwareの中にはNSX-VとNSX-Tが、Ciscoの中にはACIとDNA Centerが含まれていると思われますが、IDCによるNVOソフトウェアとコントローラアプライアンスという分類が適切なのかどうかはさておき、これらはいずれも世間一般ではSDNという領域に位置づけられており、どちらもOverlay技術を利用してはいるものの、実態としてはOverlayを利用する目的が大きく異なるソリューションです。そしてそれは、最も違いが明確に現れている両者のOverlayの実装形態から見てみると明らかです。
本エントリーでは、その違いが何なのかについて、そしてそれを利用する上ではどのような考慮点や特徴があるのかについて、ACIとNSX-Tの2つに絞ってその違いと組み合わせ方法について考えていきたいと思います。
改めて、ACIとNSX-TがOverlayを使う理由を考えてみる
ACI = Switch-based Overlay
ACIはNexus 9000スイッチ上でOverlayを利用します。つまり、Switch-based Overlayといえます。Overlayを利用する通信はスイッチ間の通信、つまりACI Fabric内部だけで利用されています1。COOP (Council of Oracle Protocol)を用いたEndpoint管理の仕組みや、VXLANヘッダの未割当領域を利用してEPGを識別するpcTag情報を付加した「拡張されたVXLAN」である "iVXLAN" を利用していることなどから、ACI FabricとしてTEP動作できるスイッチは基本的にはNexus 9000シリーズに限定されます2。その代わり、スイッチに接続する物理サーバ・仮想マシンやルータ、さらにはLBやFWなどのサービスノードからはOverlayの存在は完全に透過的であり、接続するEndpointやサービスノードに一切の制限はありません。
NSX = Host-based Overlay
対して、NSX-TはVIBファイルをインストールしたESXiホストや、サポートされるOpen vSwitch及び関連ソフトウェアをインストールしたLinux KVMホスト、ベアメタルエージェントをインストールしたサポートされるバージョンのOS等の上(中？)でTEPを構成しOverlayを利用します。つまり、Host-based Overlayといえます。ホスト自身でOverlayを扱う必要があるため、ホストにとってOverlayは透過的な存在ではなく自身が構成し管理する対象そのものとなり、対応するホストだけがOverlayの中に加わることができます。つまり、Host-based Overlayに属するホストと属さないホストの間ではOverlayの中と外をつなぐ境界を介した通信が必要となります。その代わり、Host-based Overlayの利用に際してホスト間の物理ネットワークには一切依存しません。
このOverlayが "Switch-based" なのか "Host-based" なのかという実装上の違いは、"表裏"な使い方なのか、"中外"な使い方なのか、という点が大きな違いですが、単に「Overlayする場所が違う」という以上に、ACIとNSX-TのそれぞれがOverlayを利用する目的に直結した違いをもたらしています。つまり、(ベンダーの思惑として)何を目的にOverlayを利用しているのか、です。
ベンダー側がOverlayを実装したい理由を考えてみる
利用されるお客様にとってのメリット、という側面でのOverlayを使う理由？は多く語られていますが、ここではあえて、あまり語られることがない!?ベンダーとしての思惑？という視点で考えてみたいと思います。経済学的な視点、とでも言えるかもしれません(・_・;)。ただし、これはあくまでも筆者の個人的な見解であることはお忘れなく。
Cisco ACI の理由
CiscoのACIは、L1-L3の領域を押さえることを目的としていると言えます。つまりは物理的なサーバ収容と、それらに対するスイッチングおよびルーティングの提供です。先述したように、ACI Fabricを構成できるスイッチはNexus 9000スイッチに限られますので、必然的にACI Fabricを採用した環境においてはNexus 9000ベースでネットワークを構成することとなりますし、増設時等においてもACI利用できるNexus 9000スイッチを検討することとなります。つまり、Switch-based OverlayではIP Fabricを構成するスイッチに対するロックインが働きます。
VMware NSX-T の理由
対して、VMwareのNSX-Tはメッセージングとしては物理ネットワークへの非依存を掲げていますが、それと同じぐらいおそらく重要視していることとして、Hypervisorの領域を押さえることはもちろん、加えてL4-L7のネットワークサービス領域を取り込むことを目的としているのではないかと思っています(しつこいようですが、これは執筆者の個人的見解です!!)。なぜならば、Overlayされたネットワーク内でL4-L7を利用したければ、必然的にOverlayネットワークの中に組み込むことが出来る・使いやすいLBやFWなどを使う必要性が生じるため、つまりは事実上はNSXが提供する組み込まれた各種L4-L7サービス機能を利用することとなるからです。仮想アプライアンス型のL4-L7デバイスを組み込むことも可能は可能ですが、サーバ側のDefault GWとなるTier-0/1GWでこれらのL4-L7サービスを動作させることがネットワーク構成的にも理にかなっており、逆に言えばNSX-Tを使うと必然的にNSX-TのL4-L7サービスを利用することが事実上求められると言えます。標準技術への対応、つまりは標準化が求められるL2-L3と比較して、ネットワークは上位レイヤーになればなるほど独自実装や差別化要素が組み込みやすくなるため、NSXに組み込まれたL4-L7サービスを一旦使い始めてもらえれば、それは他への移行コストを引き上げることにつながり、結果的には強力なロックインを働かせることができます。
このちょっと生々しい!?(でも自明ですよね) ベンダーの立場から見たOverlay利用の目的の違いは、CiscoがACIにおいてNexusスイッチを中心に置いており、VMwareがvSphere、HypervisorとしてのESXiを中心に置いていることから必然的にもたらされた結果であると言えます。もちろんそれは、単なるベンダーとしての都合だけではなく、利用者にとって大きな価値を提供するものであると考えているからこその実装ではあるわけですが、同時にベンダーとしての思惑もそこには存在します。
このように、両者はいずれもOverlayを使う動機があって使っているわけですが、その結果として確保したいと考えている領域には違いがあり、両者はOverlayの利用という部分的な競合はしていることは確かであるものの、どちらかといえばCiscoのACIにとってはL1-L3の領域におけるスイッチ・ルータ等のベンダーが競合であり、VMwareのNSX-TにとってはL4-L7の領域におけるFWやLBなどのベンダーが競合であると見ることができます。CiscoがNexus 9000の心臓部であるCloud Scale ASICに引き続き投資していることから見ても、VMwareがAvi Networksを買収したことから見ても、この方向性は明らかでしょう。
ACI視点で考えるNSX-Tとの違いと共存
さて、ではここからはACIの視点からvSphereと組み合わせた場合、そしてさらにはNSX-Tと組み合わせて利用する場合について見ていきたいと思います。
連携する・連携しない、それぞれの価値
ACI FabricにおいてvSphereを利用する場合、ACIでは「連携して利用する方法」と「連携せずに利用する方法」の2通りが可能です。「連携せずに利用する」とは、従来のスイッチとvSphereの使い方と同様に「VLANを合わせる」ことによって通信を構成するやり方です。連携しないのであれば、当然ながらvSphere側に一切の要件はありません。標準仮想スイッチであっても分散仮想スイッチであってもいいですし、無償のvSphere HypervisorでもOKです。
連携しないことの価値
個人的には、『連携せずに利用することも出来る』ということは1つの大きな価値であると考えています。こうした類の製品を検討する際には、ついついどれだけ便利に「連携できるのか」にフォーカスしがちですが、あまりにも密な連携は、導入当初はともかく、その後に長く続く運用フェーズにおいて運用上の課題を生じさせる可能性があります。例えば、いずれか一方のアップデートが必要になった際に、互換性要件によって他方もアップデートしなければならなくなったり等、連携していなければ発生しない新たな課題を生み出してしまうケースもあり得ます。「連携しなければ使えないSDN」は、この課題から逃れることができません。SDNはアップデートのサイクルが早く進化し続けるからこそ、サーバやHypervisor等に対して依存関係を持たない使い方も選択可能であることはとても大切です。
連携するなら疎結合であるべき理由
そして「連携して利用する方法」としては、ACIのVMware連携においては、ACIがリリースされた当初からACIはvCenterに対してAPIを通じた連携する機能を提供してきました。AgentやModuleなど、何らかのソフトウェアを相手にインストールするタイプの連携を「密結合な連携」方式とすれば、APIのみでつながる連携は「疎結合な連携」方式であるといえます。事実、ACIが利用しているvCenterのAPIはNSXや他社でも利用されている公開された非常に基本的なもののみが利用されており、その結果として以下のACIのVirtualization Compatibility Matrixにもある通り、ACIはvSphere 5.1から7.0までの全てのvSphere環境との間でAPIを通じた疎結合な連携をご利用頂くことが可能となっています。
https://www.cisco.com/c/dam/en/us/td/docs/Website/datacenter/aci/virtualization/matrix/virtmatrix.html
つまり、この範囲のvSphereをご利用なのであれば、ACIとの連携をご利用頂く際にvSphere側をアップグレードしなければならないということもないですし、逆にACI側のアップグレードを行ったとしてもvSphere側をアップグレードしなければならないということもありません。相手側にAgentなどを導入していませんので、何らかのモジュールのアップデートや入れ替え等も必要ありません。
ACIのvCenter連携
ACIはvCenterとAPI連携することによって、以下を実現しています。
・ACI側において論理的なEndpointのグルーピング単位であるEPG (Endpoint Group)に紐づくかたちでvDS(分散仮想スイッチ)にポートグループを自動生成する
→ACI側で管理するVLAN Poolの中から自動的にポートグループに構成するVLANが払い出されるため、払い出すVLANの管理や、物理ネットワーク側と仮想ネットワーク側でそれぞれVLANを「合わせる」必要性をなくす
・仮想マシンの情報(VM名、MACアドレス・IPアドレス、電源ステータス、接続しているvNICなど)を取得する
→運用管理やトラブルシューティングなどの際に、サーバの管理者とネットワークの管理者は双方の視点で状態を確認することができる
・vCenterが管理している情報(ゲストOSの種類やTagなど)に基づくマイクロセグメンテーション
→ネットワークヘッダに含まれない情報に基づくネットワーク制御の実現(ゲスト名、タグ、ゲストOS種別等)
前述したとおり、ACIはSwitch-based Overlayですので、ACI連携によって用意されるvDSはvCenterのWeb UIやAPIを通じて作成するvDSそのものです。また、ACIは同時に多数のvCenter (検証済のスケーラビリティとしては、同時に最大200のvCenterとの間での連携が可能)との間で連携することが可能となっているため、1つのシステム環境に複数バージョンのvSphere環境(及びそこに構成されたvDS)が混在して存在しているような場合であっても、ACIを通じてvCenterの管理範囲を超えて、共通のネットワークポリシーを適用することが可能です(もちろん物理サーバやHyper-V仮想マシン、RHEV仮想マシンなどとも共通ポリシーを適用できます)。
ACIのNSX-T連携
さて、ここからが本題です(えっ!! ここまでが前フリ？と思った方、はい私もそう思います…)。NSX-Tを使いたい理由が統合管理されたL4-L7サービスである場合、つまりはNSX-Tが提供する分散FWやNAT、VPN、DHCP、LBなどの統合されたサービス機能を利用したいケースに対して、ACIはどのように組み合わせて利用することができるのか、です。
従来、ACIはvCenterとは連携できましたがNSX Managerとは連携できなかったため、NSXによって管理されたN-VDSに接続された仮想マシンをEndpointとして扱うことができませんでした。なぜならば、NSX管理下にある仮想マシンの通信はHost-based Overlayによってホスト側でOverlayされてしまうため、ACIから見ると個別の仮想マシン毎の通信を識別することはできず、単にESXiホストに構成されたTEP動作しているVMkernel間での通信としてしか識別できなかったためです。また、NSX-Tによって管理されているセグメントはvCenterからはRead-onlyであり、ACIのvCenterとの連携を通じて構成することもできませんでした3。
しかし、ACI 5.1からはNSX-Tを利用している場合であっても、NSX-Tのトランスポートゾーン上に構成されたL2ネットワークである論理スイッチ/セグメントに接続された個別の仮想マシンを識別してACIのポリシーを、さらにはACIがL2/L3接続を提供することが可能となりました。これを実現するために、ACIは従来のvCenterとの連携に加えて、NSX Managerとの連携に対応したのです。この連携は、NSX-T 3.0以降に対してご利用頂けます4。
NSX-TではOverlayを使わなければいい、という選択肢
ところで、NSX-Tを使うならばHost-basedなOverlay(GENEVE)を使用しなければならない、と思っていませんか？いいえ、違います。NSX-Tを使用する上で、Overlayの利用は必須ではありません。NSX-T Data Cetner 管理ガイドにも記載されていますが、NSX-Tで構成するL2ドメインであるセグメントは、Overlayを利用するものと、VLANを利用するものの2種類が構成できるようになっています。
以下は NSX-T Data Center 管理ガイド からの抜粋です。
https://docs.vmware.com/jp/VMware-NSX-T-Data-Center/3.0/administration/GUID-316E5027-E588-455C-88AD-A7DA930A4F0B.html
このVLANを利用したセグメントを構成できる理由は、主にはEdgeノードに構成したTier0ルータの上位ネットワーク側として物理ネットワークに接続するためにOverlayのネットワーク側から出てこなければならない為ですが、このVLANバックドなセグメントは仮想マシンを接続するセグメント用としても利用できます。つまり、Host-basedなOverlayを利用しないNSX-Tを構成できるのです。通常、この様な構成がNSX-Tで利用されることはないかと思います。なぜならば、Host-based Overlayを利用しないことはNSX-Tのメリットである物理ネットワークへの非依存というメリットをなくしてしまう構成だからです。そして、前述したとおり、この構成はNSX-TのL4-L7を利用してもらうという裏の目的!?においても都合がいいとは言えません。しかし、Host-based Overlayを利用しないことには、ユーザにとっては何物にも代えがたい大きなメリットがあります。それは、「Overlayの中と外」というHost-basedなOverlayを利用することによって生じてしまうネットワークの境界を取り払うことが出来る、という点です。
Host-based Overlayを利用すると、Host-based Overlay上のネットワークは、外の世界とは隔離された「第2のネットワーク(Overlay) = 中のネットワーク」となります。このHost-based Overlay上のネットワークは既存ネットワークのトポロジーに依存することなく自由にL2/L3を構成することが可能ですが、同時にOverlayとVLANの間を結ぶ境界GW(NSX-TにおいてはEdge)を通らないと「第1のネットワーク(Underlay) = 外のネットワーク」、つまりは既存のネットワークと接続できません。これは、ネットワークとしては大きな制約です。なぜならば、ネットワークの性能も可用性も、全てはこの境界GW次第ということになるからです。どんなに物理ネットワークの可用性や帯域を拡張させたとしても、境界GWの性能と可用性がNSX-Tの中と外の間の通信に置いては制約となってしまうことになります。
しかしHost-based Overlayを利用しなければ、そもそも第2のネットワークなどという存在は生じませんし、もちろん境界GWという存在も不要となります。もちろん物理ネットワークが持つ性能と可用性を最大限活用することもできます。
ACIとNSX-Tが連携する価値
NSX-T範囲のVMを個別に識別するために
ACIはNSX-Tと連携し仮想マシン接続用としてVLANを使ったセグメントの構成を可能とすることで、vCenterとの連携に寄って実現していた状態と同等の以下のような疎結合な連携を実現します。
・ACI側のEPGに紐づくNSX-Tセグメントを自動生成する
・NSX-T接続のVMに対してL2/L3接続性を提供する
・NSX-Tが管理する情報を取得する
NSX-T連携においては、ACIのVMM Domain = NSX-TのVLAN Transport Zoneとなります。VLANバックドなTransport Zoneとして構成されるため、NSX-TにおいてこのTransport Zone内に構成されるセグメント(論理スイッチ)はVLANに紐付きます。前述の通り、NSX-TでのOverlayは使用しません。
ACI側から見ると、従来のvCenter連携のVMM Domainと使い勝手や利用方法は全く変わりません。EPGに対してNSX-T連携されたVMM Domainを紐付けると、自動的にNSX-Tを通じてセグメントがVLANバックドなTransport Zone内に作成されます。割り当てられるVLAN IDはACI側のVLAN Poolから払い出されるため、ACI側の認識とNSX-T側の認識は自動的に揃えられます。
NSX-Tを使っていてもネットワークを中と外に分断しないために
ACIとNSX-Tを連携した構成においては、ルータとしてのEdgeの構成は必要ありません。なぜならば、ACI Fabric側がL2 Subnetはもちろん、L3のDefault GWも提供するからです。つまり、NSX-TのTier-0 GWもTier-1 GWも必要としません。これにより、NSX-T管理下の仮想マシンは、NSX-Tの管理下にないESXi上の仮想マシンとの間であっても、物理サーバとの間であっても、境界GWとしてのEdgeを利用することなくシームレスな通信が可能となります。以下のように、VLANバックドなNSX-Tセグメントに接続されたVMはACI側から個別に認識することが可能ですので、特別な扱いをする必要もありません。NSX-Tに接続したVMと物理サーバが同じサブネットに属することも、NSX-Tに接続したVMに対して物理アプライアンスのL4-L7デバイスによるサービスを提供するとことも、NSX-Tのセグメントに接続されたVMからの通信をACIのService Graph機能を用いて特定要件を満たした通信のみをL4-L7サービスノードに折り曲げることも、問題ありません。
以下は、vCenterから見た分散仮想スイッチです。vSphere 7.0以降ではN-VDSを使わずにVDSの中にNSX-Tのセグメントに紐づくポートグループ!?を作成できますが、この場合でもACI連携したNSX-Tを通じてポートグループが作成されていますので、vCenterから見てもNSX-Tと連携した場合の通常の動作ですし、NSX-Tとしても全く通常のセグメントを構成しているだけでACIとNSX-Tの連携が特殊なことをやっているわけではありません。なお、ここではvSphere 7.0からサポートされたVDS内にNSX-Tセグメントが作成される構成例となっていますが、N-VDSを利用する構成でもACIのNSX-T連携はご利用いただけます(つまりvSphere 6.5や6.7でもご利用いただけます)。
vCenter連携した場合と同様に、ACIはNSX-T Managerからも情報を取得するため、APICのGUIを通じてネットワークの状態や接続されている仮想マシンの情報などを確認することが可能です。これにより、仮想環境の管理者はNSX-T Managerを通じて、ネットワークの管理者はAPICを通じて状態を把握することができます。
また、ACIではないネットワークとの間の接続においてもACIのL3outを通じて接続することができますので、BGPやStatic Routeはもちろん、OSPFやEIGRPでのルーティング構成も問題ありません。また、NSX-T側に接続されている仮想マシン間や外部との通信に対して、物理・仮想のあらゆるベンダーのFWやLBを挿入することも問題なく可能です。つまり、ACIと連携することによって、NSXの中の世界と外の世界の間にあった境界を完全に取り払うことができるわけです。
Overlayを使わなかったらスケーラビリティが制限される？そんなことはない
OverlayからVLANベースに戻ってしまったらVLAN数の制約を受けてしまう、と思われるかもしれませんが、そんなこともありません。ACIは、基本的にはLeafスイッチ毎に、そして一定の条件のもとではポート毎のVLANを、それぞれ別のものとして扱うことが出来るようになっています。つまり、Leaf1に届くVLAN 100と、Leaf2に届くVLAN 100を、別のユーザの、別のネットワークとして扱うことが可能です5。なぜならば、ACIの内部ではそれらのVLANを別のVXLAN IDで扱うことが出来るからです。つまり、複数のNSXのトランスポートゾーンを構成している場合には、それぞれで重複するVLANを構成できることになりますので、VLAN IDの数の上限がネットワーク全体で構成できるセグメント数の制約となってしまうこともありません。
このように、NSX-Tの環境においてNSX-T側のOverlayを利用せずにL2/L3をACI側で巻き取る構成とすることによって、NSX-Tが根本的に抱えるOverlayとUnderlay間の通信にGW(Tier-0 GWを実行する場所としてのEdge)を必要とする、という課題を解決することができます。
NSX-TのEdgeを使いたければ、使うことが出来る
また、このACIとNSX-Tとの連携を利用した場合にはNSXでEdgeが使えなくなるわけでもありません。すでに構成済のNSX-TセグメントではそのままEdgeをTier-0/1 GWとして引き続き利用しつつ、新たに構成するセグメントではACI側でL2/L3を構成する、といったことが可能です。もちろん、ACI側でL2/L3を提供するセグメントと、Tier-0 GWを経由するセグメント間で通信することも可能です。
ACIはTier-0 GWとの間ではBGPでL3ピアを構成すると同時に、VLANベースのセグメントに接続されたVMに対してL2 BroadcastドメインおよびL3 GWを提供することが可能です。つまり、Edgeが提供する境界FWやLB、NAT、VPN等の機能を利用したければ、ACIから見るとそれらのネットワークをEdgeによってL3接続されたネットワークとして、Edgeが提供するL4-L7サービスを利用しない(NSX-Tが提供するL4-L7サービスを使わずに他のL4-L7サービスを利用したい場合や、NSX-T外のサーバとの境界を経由しないL2/L3接続が必要な場合)のであればACIに接続されたEndpointとして、柔軟に使い分けながらNSX-Tの環境をACIと組み合わせてご利用頂くことができます。
NSX-Tの分散FWを利用する上でNSX-TでOverlayを使う必要性はない
NSX-Tの分散FWはNSX-Tによって管理されてはいますが、実際のFWルールの適用はHypervisorに導入されたモジュールによって仮想NICのすぐ先で適用されています。この分散FWを利用する上では、トランスポートゾーンの種別による制限などはありません。つまり、VLANバックドなセグメントに接続されているVMに対しても、Overlayバックドなセグメントに接続されているVMに対しても、同じ様に機能します。また、分散FWを利用する上でTier-0 GW/Tier-1 GWの利用も必要ではありません。
よって、特にNSX-Tを採用する目的が分散FWを利用したセキュリティなのであれば、NSX-TのOverlay機能を利用しなければならない必要性はないはずです。特にACIをあわせてご利用頂いているのであれば、今回ご紹介したACIとNSX-Tの連携を利用することによって、両者のメリットをかけ合わせつつも副作用としてのデメリットを最小化することが可能となります。この点において、ACIとNSX-Tは競合製品としてではなく、逆にお客様にとっての課題解決のための手段としてより役立つ組み合わせとしてご利用頂けるようになるのではないでしょうか。
まとめ
昨年のAdvent Calendarのエントリー「何らかの『連携を前提としたSDN』を採用する前に考えるべきこと。」でも書きましたが、技術自体は究極的にはどこまでいっても手段であるべきです。
https://qiita.com/twtko/items/42ab07b1e06478a0cb05
解決したい課題に対して、最も有効なアプローチはどうあるべきなのか、という軸をぶらさないことが大切です。手段として、ACIやNSX-Tがどう目的である課題解決に役立つことが出来るのか、ここではACIとNSX-Tの連携についてフォーカスしてご紹介してきましたが、連携せずにACI上でNSX-Tをご利用頂くことももちろん可能です。どんな技術にも、メリットとデメリットが存在します。目的を達成する手段としてどう使えるのかを考えると同時に、その手段をどう組み合わせて使えばデメリットを最小化出来るのか、もしくは回避することが出来るのか、検討しておくことで運用フェーズに入った後での「こんなはずじゃなかった」を最大限回避することができます。
ソリューションを検討する中で、製品選定、という言葉がありますが、その先には機能選定もあるはずです。製品が備える機能の内、どの機能を必要としているのか、そして、その機能を利用することによって得られるメリットと発生するデメリットは何なのか。メリットについては語られても、デメリットについてはベンダーとしてもあまり語りたがないものですが、利用する立場であるからこそ、きちんとそこを見極めることは大切です。
冒頭で書いたように、ACIの上でNSXを利用されているお客様はすでに国内外に多くいらっしゃいます。ACIやNSX-Tを手段として用いることで、解決したい課題は解決されましたか？同時に、これらを導入したことで生じた新たな課題はありませんか？
ACIやNSX-Tをシステムを構成するピースとしてどうはめ込むのか、そのパターンは1つだけではありません。運用フェーズに入ると構成を大きく変えることは難しいとは思いますが、だからといってより便利に、より楽に、よりシンプルに、活用できる手段となるように、それぞれにとって最適な使い方を追求し続けること、改善し続けることは大切だと思います。
ネットワークはここ数年でConfigするものからProgramするものへと大きく変化しつつあります。しかしネットワークはProgramすることが目的ではありません。従来は実現が困難であったことや、やりたくでもできなかったこと等を実現する手段として、そして属人的であったりノウハウに基づくのではない、次のステップの運用管理を実現する手段として、プログラマブルな仕組みを備えたネットワークの利用はもはや特別なことではなく、必要なものになりつつあると思います。
このエントリーが、そして Cisco Advent Calendar / vExpert Advent Calendar として公開された全てのエントリーが、皆様のお役に立てる情報であることを願っております。
A Happy Holiday Season!!
-
実際にはApplication Virtual Switch (AVS)やACI Virtual Edge (AVE), Open vSwitchを利用したKubernetes, OpenStack連携などではホスト側までVXLANが張り出します。 ↩
-
Nexus 2000 (Fabric Extender)をNexus 9000のLeafスイッチに接続し、ポート拡張モジュールとして利用することが可能です。また、ACI非対応のスイッチをLeafスイッチ配下に接続する構成も可能です。ただし、ACI非対応スイッチを配下に接続した場合、そのスイッチで折り返されてしまうL2通信についてはACIによる通信制御・ポリシー管理を行うことはできません。
↩ -
NSX-Vの場合は分散仮想スイッチのポートグループをそのまま利用していたため、NSX-VのEVSが提供するL4-L7サービスを利用しつつもACI側でL2-L3をカバーする組み合わせでの構成は可能でした。 ↩
-
上述のCiscoが公開しているACI Virtualization Compatibility Matrixにある通り、このエントリー公開日2020/12/9時点ではNSX-T 3.1はまだ公式にはサポートされていません。
↩ -
同一Leaf範囲でポート毎のVLANを個別に扱いたい場合には、ACI側のAccess Policyにおいて、Scope設定をGlobalからPort Localに変更します。 ↩