クラウドはネットワークで初めて完結する、Cisco ACIと主要仮想化基盤の連携を解説：Cisco ACI×Microsoft／Red Hat／VMware後編

　仮想化／クラウド基盤の運用で大きな課題となりやすいのは、ネットワークだ。Cisco ACIはネットワークセグメント分割から高度なネットワークセキュリティに至るまで、これをマルチベンダーで実現できる、稀有なツールだ。シスコが9月8日に東京都内で開催した 「Microsoft／Red Hat／VMware クラウド基盤の最前線とCisco ACIご紹介セミナー」における、レッドハットとヴイエムウェアのプラットフォーム戦略、およびCisco ACIと3社の仮想化／クラウド基盤の具体的な連携についての講演をレポートする。

[PR／＠IT]

　仮想化／クラウド基盤の運用で大きな課題となりやすいのは、ネットワークだ。各テナントや、個々のアプリケーションのニーズにきめ細かく応えるネットワーク構成を、即座に提供できなければならない。Cisco ACIはネットワークセグメント分割から高度なネットワークセキュリティに至るまで、これをマルチベンダーで実現できる、稀有なツールだ。

　シスコが9月8日に東京都内で開催した 「Microsoft／Red Hat／VMware クラウド基盤の最前線とCisco ACIご紹介セミナー」における、マイクロソフト、レッドハット、ヴイエムウェアのクラウドプラットフォームベンダー3社とシスコの講演からこれを探る2回シリーズの後編として、レッドハットとヴイエムウェアのプラットフォーム戦略、およびCisco ACIと3社の仮想化／クラウド基盤の具体的な連携についての講演をレポートする。

（前編はこちら）

仮想化／IaaSもコンテナ／PaaSも、オープンソースを推進するレッドハット

レッドハット グローバルサービス本部　プラットフォームソリューション統括部 クラウドエバンジェリストの小島 克俊氏

　レッドハットは、Linux OSの主要製品である「Red Hat Enterprise Linux （RHEL）」でよく知られているが、同社の現在の活動は、プラットフォームおよびミドルウエアを幅広く網羅している。

　「レッドハットにはさまざまな製品があるが、現在のトレンドは、PaaS基盤製品の『OpenShift by Red Hat（略称OpenShift）』と、IaaS基盤製品の『Red Hat Enterprise Linux OpenStack Platform（略称RHEL OSP）』の2つだ」と、レッドハット グローバルサービス本部　プラットフォームソリューション統括部 クラウドエバンジェリストの小島 克俊氏が紹介した。

OpenStack／RHEL OSPとネットワーク

　OpenStackは、AWSでできることをオンプレミスでもやりたいというのが発想のスタートだ。このため、数千台のIAサーバーを集約管理する、仮想ゲストOSをとにかく早く提供する、といったことを得意としている。

　OpenStackには、機能ごとに開発プロジェクトがあり、ネットワークのプロジェクトはNeutronである。Cisco ACIとの連携でも、Neutronがポイントとなる。

　Neutronは有用な技術だが、現時点で欠点とされるものに以下がある。

• HAの標準的な手法がない
• ネットワークのパフォーマンスに不安がある
• インストーラーはディストリビューションごとに個性がある

　ネットワークの課題を解決するため、CPUでパケット処理を高速化する「DPDK（Data Plane Development Kit）」や、仮想NICとネットワークアダプターを直結する「SR-IOV」といった技術が話題になっている。一方、OpenStackは各リリースのライフサイクルが短いことも意識しておく必要がある。

　RHEL OSP 6の新機能のうち、ネットワークに関わるものには、SR-IOVや「VRRP」（レイヤ3でのHA機能）への対応がある。また、ベータ版に当たる「テックプレビュー」として、Distributed Virtual Routing（DVR）を実装した。これは、仮想ルーターを全ての仮想化ホストに分散配置するという機能だ。

　さらに現時点での最新版であるRHEL OSP 7では、「RHEL OSP director」というインストーラーが新機能として追加されている。HA機能も実装した。しかしDVRは、まだテックプレビューである。Cisco ACIは、この部分を埋める役割を果たせる。また、RHEL OSP directorでは、インストールの際にスイッチ群は触らない、というより触れない。そこで、統合管理のためにCisco ACIのようなツールが必要になる。

進化するVMware vSphereとネットワーク機能

ヴイエムウェア ゼネラルビジネスSE統括部 パートナーSE部 シニア システムズエンジニアの青山 健二氏

　ヴイエムウェアは、ユーザーが必要としているITは「One Cloud, Any Application, Any Device」(単一のクラウドで、あらゆるアプリケーションを、あらゆるデバイスから、利用できるようにする) ）」であるとしている。そのためのクラウド基盤として進化する「VMware vSphere」について、ヴイエムウェア ゼネラルビジネスSE統括部 パートナーSE部 シニア システムズエンジニアの青山 健二氏が紹介した。

　vSphereの最新バージョンは6.0で、2015年3月にリリースされた。このバージョンでは、例えば以下のような機能強化が行われている。

• スケーラビリティが強化された。5.5では1クラスタ当たりのホスト数が最大32だったが、6.0では64と2倍に強化
• vSphere Fault Tolerance（FT）が、最大4仮想CPUのマルチプロセッサー・アプリケーションに対応
• ストレージ製品に仮想マシンを認識させるVirtual Volumesが提供開始
• ホスト上で稼働している仮想マシンを停止させずに別のホストに移動させるvMotionでは、異なるタイプの仮想スイッチ間でのvMotionや、vCenterをまたいだvMotionなどが実現

マルチテナント環境でのトラフィック制御

　ヴイエムウェアはネットワーク関連で、標準仮想スイッチと分散仮想スイッチという2つのタイプの仮想スイッチを提供している。標準仮想スイッチはESXiホストに紐付く形で1対1対応し、分散仮想スイッチはホストをまたぐ形で構成できる。分散仮想スイッチを作ると、データプレーンとコントロールプレーンを分離して実行させ、管理プレーンはvCenter側で集中制御できる。ESXiホストが少ない場合は1対1構成でもいいが、ホスト台数が多い場合は分散仮想スイッチを構成する方が運用しやすい。

　VMware vSphereは、ネットワークでは「Network I/O Control（NIOC ）」という機能を提供しているが、vSphere 6.0ではバージョン3が登場した。これは、分散仮想スイッチで実装されている。

　従来のNICOCでは、「仮想マシントラフィックを、他のシステムトラフィックよりも優先する」という優先付けになるため、仮想マシンごとにSLAを担保するのは難しかった。その部分がバージョン3で改善され、仮想マシン単位、テナント単位でSLAを定義できるようになった。

Cisco ACIで実現するマルチハイパーバイザーネットワーク

シスコシステムズソリューションズシステムズエンジニアリング コンサルティングシステムズエンジニアの畝高 孝雄氏

　Cisco ACIには、SDNという側面もあれば、ネットワークファブリックという側面もある。「ポリシーで管理されるネットワーク」とも表現できるし、シスコは「アプリケーション視点のネットワーク」という言い方もしている。どれも間違いではないが、様々な視点でCisco ACIを表現しているため、少し分かりづらいというのもまた事実だろう。

　だが、仮想化／クラウド基盤との連携という切り口にフォーカスすることによって、Cisco ACIの管理面におけるメリットの一端がはっきり見えてくる。そこで、シスコシステムズソリューションズシステムズエンジニアリング コンサルティングシステムズエンジニアの畝高 孝雄氏は、デモを交え、マイクロソフト、レッドハット、ヴイエムウェアの仮想化／クラウド基盤とCisco ACIとの連携を説明した。

Cisco ACIと仮想化／クラウド基盤を連携するメリット

　これまでは、アプリケーションが必要とするネットワークのデザインを、ネットワークエンジニアが各ネットワーク機器の設定に変換して設計・設定していた。多くのSDNソリューションはその内の「設定」作業をソフトウエア的な設定だけで実現するものが多いが、一番時間が掛かるのは、ソフトウエア要件をネットワーク要件に変換する「設計」に関する部分だ。Cisco ACIは、抽象化と自動化によって、この作業を大幅に簡素化する。

　具体的には、次のような流れとなる。

1.アプリケーションの接続要件をポリシーとして定義

2.APICというコントローラーからスイッチ群であるファブリックに伝達

3.ファブリックは自律的にポリシーに応じた構成になり、接続性を提供

　今回のセミナーではハイパーバイザーとの連携がメインだが、ACIはポート番号、IPアドレス、VLAN名、MACアドレスなどの情報を元に通信を分類することによってハイパーバイザーと連携しない形態でも使うことができる。連携しない場合と、連携する場合との違いは、次の通りだ。

【パイパーバイザーと連携しない場合】

• ネットワーク設定はサーバー側とネットワーク側の両方にそれぞれ必要
• 仮想マシンが移動したり、頻繁にコンテナを作ったり消したりする環境では、ネットワークは自動的には追従できない
• ACIとの連携ができないベンダーやバージョンのハイパーバイザーなど、IP通信でありさえすればどのようなハイパーバイザーでも利用することが可能

【ハイパーバイザーと連携した場合】

• ネットワーク設定はACIのコントローラーに対して行うだけでいい
• 仮想マシンが移動したり、頻繁にコンテナを作ったり消したりする環境でも、ネットワークは自動的に構成を変えて追従可能
• パイパーバイザー側に一定のベンダーおよびバージョン・構成に関する条件がある

　また、ACIと仮想化／クラウド基盤との連携には、以下の2つの側面がある。

（1）管理連携

ACIコントローラーであるAPICと、仮想化環境の管理ポイント(VMware vCenterサーバやMicrosoft System Centerなど)との間での連携（仮想マシンの識別など）

（2）ホスト連携

ACIのファブリックであるNexus 9000と、仮想化基盤であるホスト側の仮想スイッチとの間での連携（通信の識別など）

Cisco ACIとVMware vSphereの連携

　vSphereには、標準仮想スイッチと分散仮想スイッチという2種類の仮想スイッチがある。標準仮想スイッチを使用する場合ではACIを「連携しない」形で利用し、分散仮想スイッチではACIと連携して統合管理可能となる。

▼標準仮想スイッチで利用する場合

　vSphere 標準仮想スイッチは、「ホスト単位で管理する仮想スイッチ」であるため、ACIとvSphereは管理連携しない構成となる。仮想スイッチはポートグループ単位でVLANを割り当て、ACIはスイッチもしくはポート単位でVLANに基づく識別ポリシーを構成する（事前に接続スイッチおよびポートを指定する）。どのVLANをどう使用するのかは、人や上位ツールが判断する必要がある。

　APIC側での操作は、EPGに特定スイッチ・ポートのVLAN通信を紐付ける。一方、vCenter側での操作としては、ポートグループにVLANを定義して仮想マシンを接続する。

　デモでは、このやり方で問題なく繋がるものの、APICとvCenterの双方に対する設定作業が必要となるため自動化するためには課題がある点が指摘された。しかし、この方法によって分散仮想スイッチを使用できないエディションのESXiホストを使用している場合や、vCenterによって管理されていないESXiホストをACIファブリックに接続して使用することが可能になる。また、Cisco ACIはマルチテナント対応なので、テナントが違えばIPアドレスやVLANが同じでも違うものとして扱えることを、畝高氏は強調した。これにより、NATなどを使うことなく容易にマルチテナント構成でACIを使用することができる。

▼分散仮想スイッチで利用する場合

　vSphereの分散仮想スイッチを使用する場合は、APICとvCenterサーバーが連携することによって、自動的にネットワークが準備される。仮想マシンの管理者は用意されたポートグループに仮想マシンを接続するだけでよく、ACIはvCenterと連携してVLANに基づくポートグループを自動生成する。どのVLANをどのテナントのどのEPGと紐付けるのかは、APICが判断する。

　この場合、APIC側での操作としては、EPGに連携対象のVMドメインを割り当てるだけだ。また、vCenter側での操作としては、APICによって自動的に作成されたポートグループにVMを接続するだけでよい。

　デモでは、APICにvCenterを登録すると、その配下の仮想サーバーや仮想スイッチをAPICから把握できることが紹介された。これで、何がどこに繋がっているか、ネットワーク管理者とハイパーバイザー管理者でやり取りする必要がなくなる。そのため、ネットワーク管理者がネットワークをデプロイすると、仮想環境からは、すぐにそれをサービスとして使えることになる。

▼vSphereとCisco Application Virtual Switch（AVS）の連携

　AVSはACI専用のシスコ製の分散仮想スイッチだ。ACIが提供するポリシーモデルに基づく管理を仮想スイッチまで拡大するとともに、vCenterの持つ情報(仮想マシン名やID、管理するvCenterサーバ名やクラスタ名など)に基づく仮想マシンの制御を実現する。用意されたポートグループに仮想マシンを接続するだけで、vCenter情報に基づく識別やいわゆるマイクロセグメンテーションに対応する。ACIはvCenterと連携して、EPGと紐付くポートグループを自動生成する。

　AVSは、VMwareの分散仮想スイッチではできない、さまざまな識別ルールに対応している。例えばフラグに基づいて仮想マシンを検疫ネットワークに隔離するなどが可能だ。

▼vCenter側からネットワークを管理できるACI Plug-in（開発中）

　Cisco ACI Plug-in for vCenterは、サーバー管理者がネットワークの管理も行いたい場合に使用するプラグイン。サーバー管理者がネットワークも管理する場合は、使い慣れたvSphere Web Clientの管理画面からネットワークも管理したいという要望がある。そのためのプラグインを現在開発中だ。

Cisco ACIとHyper-Vの連携

　Hyper-Vでも、vSphereの場合と同様の管理ができる。System Center Virtual Machine Manger（SCVMM）との連携は、SCVMMとHyper-Vホストの両方にACI SCVMM Agentを導入することによって、REST APIとOpFlexの標準仕様で実現できる。OpFlexはコントローラーとスイッチ間で、ポリシー情報をやり取りするための標準規格（IETFに提案中）。APIC側での操作は、vSphereとまったく同じだ。デモでは、Hyper-Vホスト上の仮想マシンをライブマイグレーションしてもネットワーク設定が追従する様子が紹介された。

　SCVMMの論理スイッチを使用する場合も、APICとSCVMMが連携することによって、自動的にネットワークが準備される。仮想マシンの管理者は用意された仮想マシンネットワークに仮想マシンを接続するだけでよく、ACIはSCVMMと連携してVLANに基づくVMネットワークを自動生成する。どのVLANをどのEPGと紐付けるのかはAPICが判断する。

　また、ACIとWindows Azure Packとの連携も紹介された。ACIもWindows Azure Packを通じて管理することができるリソースの1つとして、仮想マシンのデプロイやWebサイトのデプロイと同じようにネットワークをセルフサービスポータルを通じて構成することが可能となる。

Cisco ACIとRed Hat KVM／OpenStackの連携

　Red Hat KVMの場合でも、オペレーションはvSphereやHyper-Vと基本的には同じだ。ただし、連携はOpenStackを通じた形態となる。シスコは、OpenStack、特にネットワークの管理を受け持つ Neutronのコミュニティに参加し、活発に活動している。そしてNeutronのネットワーク制御には、元々ACIが持つようなポリシーの考え方がなかったため、シスコが中心となってNeutronの一部としてオープンソースで「Group-Based Policy（GBP）」を実装した。また、OpFlexによる仮想スイッチのポリシー連携を実現するため、Open vSwitchにOpFlexを実装した。現在、Cisco ACIはすでにGBPに対応しているが、2015年末頃にはOpen vSwitchのOpFlexに対応する予定だ。

統合管理と設定自動化で本当のインフラ自動化へ

　3種類のハイパーバイザーとの連携をデモで紹介したが、これは、既存の仮想化環境を別の環境に移行する場合や、新たな環境を追加して混在させた場合でも、統一された管理が可能であることを意味している。今回は仮想化環境を中心に紹介したが、今後はコンテナの利用も増えると考えられる。

　シスコのACIが目指しているのは、物理サーバーであっても仮想マシンであっても、さらにはコンテナなどどのようなコンピューティングリソースの単位であっても、そしてそれらが混在しても移行されても、さらには通信プロトコルがVLANであってもVXLANであっても、管理ポイントが複数の仮想化／クラウド基盤で管理されていても、継続的で横断的な統合されたポリシー管理を実現することだ。

　ネットワークについて真のインフラ自動化を実現するためには、特定のハイパーバイザー、特定のコントローラーに依存しない統合管理とともに、オペレーションの自動化が必要だ。デモでは、ひとつひとつクリックして設定したが、当然大規模環境ではそんなことはしていられない。設定の自動化には、オーケストレーションツールとの連携が必要だ。Cisco ACIはすべての操作をAPIを通じて行うことが可能となっており、多様な仮想化／クラウド基盤と密接に連携し、サーバー／アプリケーションのニーズをネットワークに即座に反映させられる一方で、これらから独立した、継続性のあるネットワーク環境を提供できる、まさに「SDNを超えるSDN」といえる。