前回のブログではデータセンター ファブリック技術の進化として vPC、FEX、FabricPath といったテクノロジーを中心にご紹介しました。今回は 7月末にいよいよ発売される ACI（Application Centric Infrastructure）をご紹介します。
Cisco ACI の構成要素
Cisco ACI ファブリックは、新しいハードウェアとなる Cisco Nexus 9000 シリーズと、専用のコントローラである APIC（Application Policy Infrastructure Controller）から構成されます。
Cisco APIC ：ファブリックの自動化とインフラの統合管理を実現できるコントローラで物理アプライアンスとして提供されます。ファブリックの規模に応じて、最小構成である 3台クラスタから最大で 31台クラスタにまで拡張させることができます。拡張性と耐障害性をより高い次元で両立し、部分的な APIC のダウン時には正常な APIC 間でコントローラ機能を補完します。なお、すべての APIC がダウンした場合でも、ファブリックを構成する Nexus 9000 が自立して動作するため、ネットワークを止めることはありません。
Cisco Nexus 9000 シリーズ：Cisco Nexus 9500 と Nexus 9300 があります。Nexus 9000 シリーズでは、OS の入れ替えによって 2つの動作モードを使い分けるようになっています。1 つは他の Nexus シリーズと同様にスタンドアロンとして動作する NX-OS モード、もう 1 つは APIC と組み合わせて統合管理を行う ACI モードです。
ACI モードには「Spine」と「Leaf」という 2 つの役割があり、それぞれに対応する製品モデルがあります。
- Cisco Nexus 9500 シリーズ：ラインカードで Spine 用か Leaf 用を選択することができます。
Cisco Nexus 9500 シャーシ型スイッチ
- Cisco Nexus 9300 シリーズ：Spine 専用モデルと Leaf 専用モデルがあります。Nexus 9336PQ が Spine 専用モデル、Nexus 9396TX、Nexus 9396PX、Nexus 93128TX が Leaf 用モデルとなります。
Cisco Nexus 9300 固定型スイッチ
ACI Leaf 対応モデル （NX-OSモード動作可）
Cisco Nexus 9300 固定型スイッチ
ACI Spine 対応モデル （NX-OS モード動作不可）
Spine 用モデルのラインカードや固定型スイッチは NX-OS モードでは動作しないので スタントアロンとして Cisco Nexus 9000 を検討される場合はご注意ください。
Cisco ACI ファブリックの特長
これまでのファブリックと Cisco ACI ファブリックとの大きな違いは、以下の 5 つのポイントにまとめることができます。
- 個々の Nexus スイッチをコマンドラインで管理するのではなく、アプリケーション特性に合せたポリシーに基づき、APIC からファブリック全体の Nexus の統合管理およびアプリケーションごとのヘルスモニターを実施
- ファブリック内だけではなく、APIC からデータセンター間接続用のスイッチ／ルータとなる Border-leaf についても統合的に管理
- 複数のベンダーが提供するネットワーク仮想プロトコルに対応し、異なるネットワーク仮想化プロトコルの相互接続をサポート
- 複数のベンダーのファイアウォールやロード バランサ製品などに対応し、ファブリック内における自在なネットワーク サービス チェーニングを実現
- APIC には REST ベースの North-bound API が備わっているため、ユーザが作成したスクリプトによる自動化、および Open Stack や Cisco UCS Director などのオーケストレーション製品群との連携が可能
これらの特長を見ただけでこれまでのデータセンター ネットワークの多くの課題が解決できることを理解していただけると思います。さらにもう少し、ACI ファブリックの素晴らしいところを私の視点で紹介していきます。
ポリシーによるネットワーク制御
多くのデータセンター事業者やクラウド事業者は、どんなアプリケーションがいつ接続されてきても良いように事前に ToR（Top-of-Rack）スイッチに全 VLAN を通しておくというオペレーションを導入していると何度か耳にしてきました。このような運用方法は、設定が楽になり、アプリケーションの担当者のみで作業スケジュールが遂行でき、顧客へいち早くサービス提供できるといったメリットがあります。しかし、これはサービスを提供する側のメリットであって、果たしてサービスを受ける側（お客様）にとってはどうなのでしょうか？私はセキュリティの観点からもこのような運用は避けるべきだと言いたいです。
ACI は、簡単に言えばホワイト リスト型のファブリックです。アプリケーション ネットワーク ポリシーのなかで許可されたトラフィックでなければ、いかなるトラフィックも通しません。その動作は次のとおりです。
- APIC 上で作成されたアプリケーション ネットワーク ポリシーが、ファブリック内の Nexus 9000 シリーズのメモリ上に展開され保持される
- そのアプリケーション ネットワーク ポリシーに該当するサーバ（物理サーバまたは仮想サーバ）がファブリックに接続されると、Nexus のメモリ上に保持されたポリシーが Nexus のハードウェア レベルで解釈できる設定に転換される
このようにして、自動的に必要なネットワークが完成します。仮想マシンが異なるホスト サーバ上へライブ マイグレーションした場合、移動先のホストサーバを収容する ToR スイッチにも、同じアプリケーション ネットワーク ポリシーに従って必要なネットワーク設定が必要なタイミングで自動適用されるということです。このときのネットワーク的なサービス ダウンタイムは、Ping パケットが 1つ落ちるかどうか程度です。これは、通常のライブ マイグレーションとほぼ同じ速度です。
アプリケーションの展開に合わせてネットワークがこれだけ高速にインテリジェンスに動作するのであれば、不必要な VLAN を事前に通しておくようなオペレーションはもはや不要になると考えます。また、APIC はマルチテナント構成にも対応しており、完全に独立したテナント サービスを ACI ファブリック上で提供できます。テナント間での IP アドレスの重複や異なるサービス チェーニング ルールの適用など、高いセキュリティを保ちながらマルチテナントをサポートすることができます。
アプリケーションのポリシー モデルと生成
アプリケーション ネットワーク ポリシーについて少しだけ補足しておきます。APIC では、EPG（End Point Group）と呼ばれるアプリケーションとネットワークの対応表を維持しています。EPG には、同種のサーバ群によって構成されるグループが定義されており、これを VLAN、VXLAN、Port Group、サブネット、Leaf の物理ポートなどに関連付けます。具体的なグループには、Web-EPG、App-EPG、DB-EPG、DNS-EPG、Eternal-EPG（外部ルータ／スイッチなどを意味する）などがあります。そして EPG 間には、L2-L4 の情報を使ったフィルタリング処理やサービス チェーニングのためのリダイレクト処理、トラブル解析時のミラー処理といったネットワーク ポリシー（Contract）が定義されています。これらがアプリケーション ネットワーク ポリシーです。
ポリシー：アプリケーション中心のネットワーク要件の定義
統合オーバーレイ
ACI ファブリックのもう 1 つの特長として、VXLAN（Virtual Extensible LAN）ベースの IP ファブリックだということが挙げられます。これまでのファブリック、例えば FabricPath の場合、L2 ファブリックであるために、セグメント間通信には SVI を介したルーティング処理が必要でした。これに対して ACI ファブリックは、VXLAN ベースで L3 ネットワーク上に仮想 L2 ネットワークが構築され、異なる IP セグメント（サブネット）を跨いだ環境であっても同一のブリッジ ドメインとして扱うことができます。
また、Spine スイッチ上には、各 Leaf の VTEP（VXLAN Tunnel EndPoint）IP アドレスと、その Leaf 配下に収容された仮想マシンの IP アドレスや MAC アドレス、テナントなどの情報を格納するマッピング DB があります。例えば仮想マシンが ToR スイッチ間を移動してサービス チェーニングのルートが変更されると、Leaf スイッチが移動した仮想マシンを自動的に検出し、Spine スイッチ上のマッピング DB が更新されます。これにより、常に一貫したアプリケーション ネットワーク ポリシーに合せたネットワークを提供することができるのです。
ACI Fabric の統合型オーバレイ ：識別子、位置情報、ポリシーの分離
仮想インフラの統合
Leaf スイッチのもう１つ重要な役割があります。それは、各ハイパーバイザー上の仮想スイッチが提供する VXLAN や NVGRE（Network Virtualization using Generic Routing Encapsulation）、あるいはベアメタル サーバを収容するときに必要な VLAN など、異なるネットワーク仮想化プロトコルを終端し、相互接続をサポートすることです。
極端な話をすれば、Web サーバは VXLAN 上に存在し、アプリケーションサーバは NVGRE 上に存在し、DB サーバは VLAN 上に存在するようなアプリケーション システムを、特別なゲートウェイ装置なしにファブリック内で処理できるのです。つまり、一般的に VXLAN のときに必要となる Underlay Network と Overlay Network を Nexus 9000 シリーズ＋APIC によって完全に統合することで、Integrated Overlay Network を実現しています。
マルチハイパーバイザー対応
ちなみに ACI ファブリック内では VXLAN の Underlay Network に必要となるマルチキャスト環境は不要です。これにより導入のハードルはより低くなり、ネットワーク仮想化が進展すると私は考えています。OpenStack や Cisco UCS Director などと連携させれば、仮想ネットワークも仮想サーバと同じくらい迅速なプロビジョニングできます。さらに Nexus 9000 がハードウェアベースで各ネットワーク仮想化プロトコルに対する Decap 処理や Encap 処理を担うので、ワイヤレート性能をファブリックとして提供することができます。
これまで VLAN 4000 では拡張性にかけるなど課題を持ちながらも VXLAN ベースによるネットワークの仮想化へ踏み出せなかったお客様は、ぜひ一度 ACI ファブリックをお試しください。
ACI を動画で紹介
最後に ACI に関する YouTube の動画を紹介します。最初の「Cisco Application Centric Infrastructure | Overview」は英語ですが、分かりやすく ACI の機能を説明しています。2 つめと 3 つめは、日本の SE が作成したデモ ビデオです。ぜひ、ご覧ください。
Cisco Application Centric Infrastructure | Overview
Cisco ACI と OpenStack 連携デモンストレーション
Cisco ACI Service Graph デモンストレーション
Authors
