「ACI がどのようにお役に立てるのか」について、技術的な詳細というよりも実践的な価値にフォーカスして、5 回にわたってご紹介するシリーズ。今回は久々の更新となる第 3 回となります。第1回、第2回をまだご覧なられていない場合は、ぜひ第 1 回からお読みいただければ幸いです。
- 第1回：ACI をシンプルに L2/L3 スイッチとして考えてみる
- 第2回：アプリケーションとネットワークを結びつけるポリシーってどう役立つの？
- 第3回：連携してもいい・連携しなくてもいい、という使い方 ～物理・仮想・コンテナ・L4-7サービス…
- 第4回：ネットワークをサービスとして提供するために必要なこととは
- 第5回：進化し続ける ACI
第3回のテーマは、「連携してもいい・連携しなくてもいい、という使い方 ～物理・仮想・コンテナ・L4-7サービス…」です。
多くの SDN ソリューションは何らかの連携の上に実装されています。特定の Hypervisor を前提とするものや、特定の Container を前提とするものなど、その前提とする範囲だけを対象とするのであれば便利でしょうが、その範囲外と組み合わせるとなった途端に色々と制約があったり、逆に運用管理が難しくなってしまったりすることがあります。
対して、VXLAN Fabric を始めとする Network Fabric ソリューションは、あらゆる Ethernet/IP による通信対象に対してネットワークの接続性を提供することができるため、ネットワーク接続を必要とする物理・仮想など形態を問わないあらゆるリソースに対して接続性を区分けなく提供することが可能です。しかし単なる Network Fabric は、何らかの SDN ソリューションのための単なる Underlay として利用されるだけといった、いわば土管としての使われ方になってしまいがちです。
それ故に、多くのソフトウェアベースの SDN ソリューションは、物理ネットワークには依存しないとしつつも、実際には何らかの Network Fabric との組み合わせでの利用を推奨しています。性能や可用性は Network Fabric が提供し、動的な変更や管理は SDN が提供する、確かにこの組み合わせは両者の弱点を補完し合うため、実際に多くのお客様がこの組み合わせでの SDN + Network Fabric の導入を行っています。逆に言えば、SDN は Network Fabric を必要としており、Network Fabric もまた SDN を必要としている、といえます。
しかし、SDN と Network Fabric が分離して存在する限り、結局はそれぞれの弱点は解決されていません。SDN を使うということは何らかの前提に依存するということであり、単なる Network Fabric はネットワークとしての接続性を提供する従来のネットワークとしての価値のままに留まります。それぞれをコントローラによって統合管理したとしても、SDN コントローラと Fabric コントローラの少なくとも 2つのコントローラを使い分けた管理が必要となります。
Application Centric Infrastructure（ACI）は、SDN 的な側面と Network Fabric 的な側面の両方を併せ持つソリューションです。物理スイッチの管理はもちろん、その上に構成する論理ネットワークとしての VXLAN Fabric、そしてアプリケーション視点での「つながり」までを統合的に管理するからこそ、従来のネットワークでは困難だった「アプリケーション視点でのつながりの管理」を実現することが可能となります。公平性のために書いておくならば、ACI は ACI-mode に構成した Nexus 9000 スイッチを必要としますので、Network Fabric を構成するスイッチがいわば「前提」となるわけですが、ACI Fabric の導入は既存のネットワークと L2/L3 でシームレスに接続することが可能となっており、何らかのゲートウェイを配置しないと既存ネットワークとは接続できないといったこともありません。
ACI は特定の Hypervisor や Container には依存しませんので、Ethernet/IP で通信するあらゆる Endpoint に対して接続性を提供することができます（補足ですが FC にも対応しています）。OS 種別を問わず物理サーバ、仮想マシン、コンテナ、各種アプライアンスなど、どのようなコンピューティング リソース形態であったとしても、どのベンダーのどの L4-L7 デバイスであったとしても、ACI に接続してご利用いただくことができます（通信制御ができない等の制約を理解した上でならば ACI Fabric の Leaf スイッチ配下に何らかの L2-L3 スイッチを接続して利用することも可能）。Nexus スイッチ自体にEthernet や IP による通信について互換性に関する制限がないように、ACI に接続して利用頂ける機器に制限はありませんし、何らかの連携を前提とすることもありません。たとえば、vCenter によって管理された ESXi スイッチを ACI Fabric に接続して利用する場合においても、ACI とは連携せずに利用する場合は従来のスイッチの場合等と同様に構成する VLAN を合わせる等によって「設定を合わせる」ことが必要となりますが、逆に言えば標準仮想スイッチであろうと分散仮想スイッチであろうと利用できますし、一切の追加的なコンポーネントを vSphere 側に導入する必要もありません。
ただし、Hypervisor のマネージャや Container のオーケストレーターなどと連携することのメリットもあります。たとえば vSphere や Hyper-V などの仮想化環境であれば、仮想マシンは仮想スイッチを経由してネットワークに接続するため、それらの仮想スイッチを ACI Fabric と統合して管理すればネットワーク管理の一元性を向上することができます。ACI では各種仮想化環境やコンテナ環境との連携を構成することも可能となっています。たとえば、ACI のコントローラであるApplication Policy Infrastructure Controller（APIC）と vCenter を連携させることによって、ACI 側で構成したネットワーク情報に基づいて自動的に vCenter によって管理された分散仮想スイッチに紐付いた Port Group を自動的に作成することなどが可能となります（vCenter が一般に公開している標準 API を通じて連携するため、一切の特別な設定や追加のエージェントなどの導入は不要）。構成する VLAN ID をあわせたり、事前にネットワーク側に必要とする VLAN を通しておくなどの対応も不要となるため、よりシンプルに「必要なタイミングで、必要な設定を、必要な箇所に構成する」管理を実現することができます。
しかし、これらは必ず連携しなければならないものではなく、「連携すればより便利に、より一元的に管理が可能となる仕組み」として実装されています。この『連携してもいい、連携しなくてもいい』という点は非常に重要な点だと考えています。なぜならば、連携しなければ使うことができない仕組みは、その前提が対象とする範囲外に対して適用することはできないからです。バージョンや対応モデル、構成など、連携を前提とした仕組みはその前提を満たすためにも様々な対応が必要となりますし、それが密結合な連携の場合はその後の運用フェーズにおいてもバージョンアップやメンテナンスなどの際に連携していることを相互に考慮した対応が必要となります。Hypervisor 上にネットワークの要素を追加することは、サーバのメンテナンス時などに VM についてだけでなくネットワークについても考慮が必要になることを意味していますし、ネットワークのためにコンピューティングリソースを消費することは、その分サービスのために利用できるコンピューティングリソースが減ってしまうことを意味しています。
ACI が『連携してもいい、連携しなくてもいい』対象は、Hypervisor や Container などのコンピューティング リソースに限りません。ACI では管理連携しなくてよいのであれば、どんなベンダーの、どんなモデルの、物理アプライアンスと仮想アプライアンスいずれであっても、Firewall や Load Balancer / ADC などの L4-L7 デバイスもしくは IDS/IPS、パケット シェーピング機等の L1-L2 デバイス等をご利用いただくことが可能です。Policy Based Redirect（PBR）を用いて特定要件にマッチする通信だけをそれらのサービス デバイスに折り曲げて処理させることもできますし、IP SLA 機能によってサービス デバイスの稼働状況を監視することも可能です。
このように、ACI は物理的な管理からアプリケーション視点での管理までを一元的に管理しているからこそ可能な『連携してもいい、連携しなくてもいい』使い方ができるネットワークを実現します。
日本語でのACIの技術的な情報については、以下のACI How Toサイトで公開しています。ぜひ御覧ください。
https://learningnetwork.cisco.com/community/connections/jp/aci-howto
Authors