連携、というタイトルで書き始めましたが、Cisco Application Centric Infrastructure (ACI)は、別に連携を構成しないとvSphere環境やHyper-V環境と組み合わせて使えないわけではありません。ACIは特定の物理的なサーバやHypervisorに依存していませんし、モジュール等をそれらの環境にインストールする必要もありませんので、特に連携を構成せずに使うことはもちろん可能です。この点は結構重要で、今後様々な新たな形態の要素がネットワークに接続してくることになったとしても(たとえばDockerのようなコンテナ単位であったり、様々なIoTデバイス類など)、いちいち連携実装を新たに用意せずともそれらを柔軟に受け入れることが可能であるということを意味します。
同時に、ACIはアプリケーション視点でのネットワーク管理を実現するために、ネットワークにおける「位置情報」となりうる要素についての依存性を極力排除できるように設計されています。残念ながらOSや様々なIP通信を行う端末側ではIPアドレスに紐付いてサブネットマスクやそれと紐付くVLANなどの概念が今現在はまだありますので、それらについて無視するわけにはいかないのですが、ACIにおいてはVLANが違っていても、逆にサブネットが同一であっても、それらが通信可否を決定する要素にはならない実装となっています。
その上で、なぜ連携する機能があるのかといえば、それは連携することによって管理がより便利になるから、です。たとえば、vSphere環境においてはポートグループが、Hyper-V環境においてはVMネットワークが、仮想マシンにおける仮想NICが接続する先となる論理的なネットワークを意味するわけですが、ポリシーに基づいてネットワークを制御するACIといえども、仮想マシンの接続点となるそれらの要素と、ACIにおける制御単位であるEPG (End Point Group) の間でのマッピングが必要となるわけで、ACIのコントローラであるAPIC (Application Policy Infrastructure)と各仮想化環境の管理サーバ(vCenter ServerもしくはSystem Center)と連携することによって、そのマッピングの構成を自動的に行うことが可能となります。逆に言えば、手動でそれらのマッピングを構成するのであれば、連携せずともACIとこれらのHypervisorを組み合わせて使用することが可能となるわけです。
さらには、仮想化環境との連携によって仮想化環境側で保持している識別子をACIで活用することも可能となります。ACIにおけるEPGの識別子はVLANや接続ポートなども使用できますが、たとえば仮想マシン名であったり、ゲストOS種類であったりといった要素に基づいて識別してもよいわけで、より柔軟に対象のEPGへのマッピングが可能となればより柔軟な管理が可能となるわけです。ACIでは、新たにそうした仮想マシン名などを識別子として使用することが可能となっています。
