8月が終わってしまう！(^_^;)
本日のエントリーは、Cisco ACI (Application Centric Infrastructure) についてのエントリーなのですが、あえて少々Cisco UCSについて振り返って見るところから書き始めてみたいと思います。
Cisco UCS (Unified Computing System) は様々な革新をサーバ市場にもたらしましたが、中でもUCS最大の価値は、UCS Managerによって「サーバ自体から分離された構成情報のパーツ」をPolicyとして、そして「それらのPolicyをまとめてサーバに適用する一揃いの構成情報セット」をService Profileとして管理する仕組みを実装した点でしょう。BIOS構成、Firmwareバージョン、論理インターフェイスの接続先VLANやSAN構成、対象サーバが使用するMACアドレスやWWNアドレスなど、これまでサーバを構成する上で意外と手間で時間がかかったり、もしくは設定内容の確実性を担保する方法がなかったような部分に対して、サーバの実体の有無などに関係なく事前に構成したPolicyとProfileに基づいて確実な構成と管理が可能となったのです。
Cisco UCSの管理ツールであるUCS Managerの対象は物理的なサーバやネットワークではありますが、PolicyやService Profileはいずれも完全に物理とは切り離された、ソフトウェア的に制御することが可能なプログラマブルな定義情報です。ソフトウェアだけで実装するような形だとどうしても置き去りにされてしまう(もしくは、オーバーレイなどによって単純化してしまう)ハードウェアの部分について、まるっとまるごと切り離してしまうのではなく、あくまでも管理ポイントと管理対象だけを分離し、可能な限りプログラマブルな対象とするために考えぬかれた実装方式こそが、Policyとそれを組み合わせたService Profileに基づく制御であるといえます。このように実装することによって、ソフトウェア的に構成・制御すべき部分はソフトウェアで、ハードウェア的に構成・制御すべき部分はハードウェアで実装することを可能としつつ一体化された管理を可能としたわけです。
UCSのリリースから5年、こうしたPolicyとProfileに基づく管理手法をサーバの範囲からデータセンター向けのネットワーク全体に拡張する新たな実装こそが ACI (Application Centric Infrastructure) です。ACIでは、Nexus 9000シリーズで構成されるEthernet Fabricを基盤として使用し、そのステータスをコントローラである APIC (Application Policy Infrastructure Controller) が完全に制御し把握していますが、同時に利用者に対しては そのEthernet Fabric自体をネットワークリソースとして提供するのではなく、アプリケーションが必要とする論理ネットワークという形で物理的なEthernet Fabricを一切意識せずに使用することができる抽象化されたカタチで提供します。ACIにおいては、IPアドレスも、VLANも、接続ポートも、単なる識別子として扱われます。まったく同じVLANであったとしても、たとえば接続先スイッチが違ったり、管理連携しているvCenterが違ったりすれば、まったくちがうテナントの、まったく違うシステムの構成要素として扱うことも可能です(逆に、同じ構成要素として扱うことも可能です)。そして、そうしたネットワークをアプリケーション視点での定義を可能とするPolicyとProfile (Application Network Profile) を実装した点こそがUCS同様、ACIの革新といえます。
物理サーバであっても仮想マシンであっても、vSphereのVMであってもHyper-VのVMであっても、VLANを使っていようとVXLANをつかっていようと、そしてどのスイッチに接続されていようとも、同じPolicyの適用対象のグループに属すると定義すれば同じように通信が制御されます。仮想マシンがライブマイグレーションで移動しようとも、新たにWebサーバが100台一気に追加されようとも、Policy適用のルールが変わらない限りは「どのサーバがどの利用者の、どのアプリケーションのどの役割に属しているのか」という情報の管理だけでネットワークを制御することができます。
ネットワークに対する構成変更を手作業で個別機器それぞれに対して行う必要がない、という点がいわゆるFabricと呼ばれるネットワークの特徴の1つですが、ACIではさらに一歩踏み込んでネットワークをレガシーな意味でのネットワークとして管理するのではなく、抽象化された論理ネットワークとしてポリシー制御できるレベルへと進んでいます。UCSにおいて、Service Profileによるソフトウェア的な論理的な管理を実現するために FI (Fabric Interconnect) や FEX (Fabric Extender), VIC (Virtual Interface Card) などといったハードウェアコンポーネントとの組み合わせでその仕組みを作り上げた様に、ACIにおいても Application Network Profile による抽象化された論理ネットワーク管理を実現するために、Nexus 9000シリーズはもちろん、様々なL4-L7サービスと連携するための Device Package や、VMware環境における仮想スイッチをACIに完全統合する AVS (Application Virtual Switch)、そして OpFlexプロトコルなど、ハードウェアとソフトウェアの組み合わせで新しい時代におけるネットワークを実現しています。
最後に、ACIのコントローラである APIC (Application Policy Infrastructure Controller) は、個別機器の構成情報そのものを管理しているわけではありません。つまりACI Fabricを構成する各Nexus 9000スイッチの個別ConfigをAPICは管理していません。APICはあくまでもPolicyを管理しており、PolicyをACI Fabricを構成する機器に対して伝えます。伝えられたPolicyを基に自身がどのように構成されるべきなのかについては、各機器の側で判断し制御されます。このように、Policyベースでの管理を実現することによって、コントローラ側はスケール性を非常に大きく持つことができるようになりますし、各機器側は自身での判断と構成が求められる分、柔軟な実装拡張と自律動作が可能となります。
このエントリーではあくまでもACIを対象として書いてきましたが、こうしたポリシーベースでの制御方式は様々なネットワークにおける新しい管理手法として今後、様々な仕組みの中で使われるようになっていくはずです。OpenStackやOpenDaylightなどのプロジェクトにおいても、現在ポリシーベースの管理手法が取り入れられようとしています。そして、それはネットワークがプログラマブルになる時代の本格的な幕開けを意味します。
次回のエントリーでは、プログラマブルなネットワークとは？という点にフォーカスしてみたいと思います。
