Special
» 2015年11月30日 10時00分 UPDATE

Cisco ACI×Microsoft/Red Hat/VMware前編:SDNは何のためにあるか、ネットワークをサービス化するためにある

「Cisco ACI」でシスコが実現しようとしているのは、ネットワーク、そしてITのサービス化だ。シスコが9月8日に東京都内で開催した 「Microsoft/Red Hat/VMware クラウド基盤の最前線とCisco ACIご紹介セミナー」における、シスコとマイクロソフトの講演を、要約してお伝えする。

[PR/@IT]
PR

 SDN(Software Defined Networking)は何かの役に立たなければ意味がない。「SDNを超えるSDN」である「Cisco ACI(Application Centric Infrastructure)」でシスコが実現しようとしているのは、ネットワーク、そしてITのサービス化だ。

 パブリッククラウドサービスのユーザーにしても。企業の事業部門にしても、やりたいことはアプリケーションの機能の提供あるいは利用だ。アプリケーションの利用者であるユーザーからの要求はビジネス状況の変化に伴って変化していくこととなるため、アプリケーションは以前にも増して、迅速・機動的に展開しなければならなくなっている。ITインフラは、アプリケーションが必要としているリソースを適切に提供できる必要があり、その邪魔をしてはならない。つまり、アプリケーションのためのサービスレベルとセキュリティは適切に確保されなければならないが、デプロイに際して必要となるITインフラの設定に掛かる時間は最低限にとどめられなければならない。

 だから、ACIとクラウド基盤は相性がいい。クラウド基盤はサーバー、ストレージを中心に、配備および運用に関わる作業を大幅に自動化する。一方で、ネットワークの配備・運用については、ネットワーク製品ベンダーがプラグイン等を用意することで、クラウド基盤との連動を進める動きは出てきているものの、実際には別の担当者が存在し、配備や運用の作業も切り離されていることが多い。また、現実にはネットワークは設定作業そのものよりも設計やデザインに時間を必要とする。このため、サーバー/ストレージとネットワークの間で、自動化の流れが途切れてしまっているのが現実だ。

 ACIはこの現状を変えることができる。ネットワーク運用担当者は、従来通り、ネットワークのサービスレベルおよびセキュリティを確保する責任を果たしながら、これをテンプレートとしてユーザーに提供することができる。ユーザー側は、クラウド基盤を通じ、テンプレートを自らの配備するサーバー/アプリケーションに適用すればいい。ACIでは、シスコおよびそれ以外の、ファイアウォールや負荷分散装置など ネットワーク/セキュリティ製品の適用を統合的に設定できる。

 自動化の流れを途切れさせることなく、複数製品にまたがる複雑なネットワーク/セキュリティ設定を、アプリケーションに対して瞬時に適用できるわけで、こうなってこそネットワークを含めたITインフラのサービス化が完結できる。

 以下では、シスコが9月8日に東京都内で開催した 「Microsoft/Red Hat/VMware クラウド基盤の最前線とCisco ACIご紹介セミナー」における、マイクロソフト、レッドハット、ヴイエムウェアのクラウドプラットフォームベンダー3社とシスコの講演を、要約してお伝えする。

Cisco ACIの仕組みとメリット

im_ait_ciscoacis01.jpg シスコ データセンター バーチャライゼーション事業部 テクニカルソリューションアーキテクト 水島 勇人氏

 最初のセッションでは、シスコシステムズ合同会社 データセンター バーチャライゼーション事業部 テクニカルソリューションアーキテクト 水島 勇人氏が、Cisco ACIの概要を説明し、概要をデモで紹介した。

 「ACI」とは「Application Centric Infrastructure」、つまり「アプリケーション中心のインフラストラクチャ管理」という意味だ。これまでは、各ネットワーク機器に対し、個別にネットワークの用語を使って設定しなければならなかった。だが、ACIではアプリケーション視点で、ITインフラをビジネスの言葉で管理できる。

 特長として挙げられるのは、以下のような点だ。

  • アプリケーション視点の管理モデルでネットワークを構成できるので、時間・手間・工数が少ない
  • 物理サーバー、仮想サーバーの双方に対応し、一貫したネットワークサービスを提供できる
  • ファイアウォールや暗号化、ロードバランサーなどは専用装置が必要だが、オープンなエコシステム連係により実現する

Cisco ACIの構成要素と動作

 ACIを構成する要素は3つある。物理レイヤである「ファブリック」、管理ポイントである「コントローラー」、アプリケーション中心の管理性を実現するための「ポリシーモデル」だ。「このアプリーションにはこういう接続性が必要」というイメージをポリシーにしてコントローラーに渡すと、コントローラーが自動的に物理的なスイッチを構成してくれるイメージだ。

ファブリック

 ファブリックとは、Cisco Nexus 9000をベースとしたスイッチ群で、「スパイン」と「リーフ」から成る2階層型ネットワークだ。このアーキテクチャでは、スケールアウトが簡単だ。ポート数を増やしたければリーフスイッチを増やせばいいし、パフォーマンス(帯域)を増やしたければスパインスイッチを増やせばいい。すべてのパスはアクティブに使用され、物理的な複雑性のないシンプルなデザインを実現することができる。

コントローラー

 従来型のネットワークでは、個々のネットワークデバイスに対してネットワーク設定を行っていたが、ACIではファブリックをAPIC(Application Policy Infrastructure Controller)というソフトウェアでコントロールする。APICは、シスコのUCSサーバにプリインストールされたアプライアンスとして提供される。

ポリシーモデル

 ポリシーとは、アプリケーションが持つ接続要件をモデル化したものである。例えばECアプリケーションの接続要件は、以下のようになる。

  • フロントエンドのウェブサーバがインターネット越しに利用者と繋がっている
  • Webサーバーからの情報をアプリケーションサーバーが受け取って必要な処理を行う
  • アプリケーションサーバーは処理に必要なデータをデータベースからもってくる

 この内容を、抽象化された「ネットワークプロファイル」として、宣言型で記述する。「Webサーバーとアプリケーションサーバーの接続」といった形で定義をするため、IPアドレスやポート番号、さらにはサーバーが物理なのか仮想なのかすら気にする必要はなくなり、個々のネットワーク機器のCLIから解放される。

 ポリシーの要素は2つある。同じ機能を提供するサービス群である「EPG(End Point Group)」と、それらを接続する「コントラクト」だ。コントラクトは接続性をサービス化したもので、内容は「○が提供する接続性を△が利用」というように定義する。1つのアプリケーションは、複数のEPGとそれらを繋ぐコントラクトで構成される。当然、1つのEPGに物理サーバや異なるハイパーバイザー上の仮想マシンが混在していても問題ない。

 ポリシーを定義するには、コマンドを打ち込むのではなく、図で描いていく。APICのポリシー管理画面でEPGのアイコンをコントラクトの矢印で繋げば、背後で物理的なスイッチが構成されて、ネットワークが提供される。

 これらの要素により、ACIは以下のように動作する。

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

2.APICからファブリックへポリシーを伝達、ファブリックを自動構成

3.サーバーを接続(物理・仮想を問わず)

4.ファブリックがポリシーに応じた接続性を提供

 IPアドレスベースから抽象的な管理に変わることで、オートメーションもシンプルになる。クラウド環境にはクラウド基盤(統合ネットワーク、統合ストレージ、統合コンピュート)と、クラウド管理基盤(オートメーション、サービスカタログ、クラウドポータル)が必要だが、ACIは、統合ネットワークに加えて、ストレージ接続性や仮想スイッチ、システム連係などの機能を提供できる。

ネットワークリソースをプール化できるCisco ACI

 Cisco ACIは、ネットワークリソースをプール化できるのが特長だ。ネットワーク接続性やネットワークセキュリティはすべてAPICで一元管理し、物理サーバーか仮想サーバーかに関わらず、必要なサイズを切り出してポリシーを付与し、サーバーに提供することができる。サーバーはファブリックのどこにでも接続可能で、移設・移動しても設定変更は必要ない。将来的にはコンテナなどの新しいコンピュートリソースの形態が出てきても柔軟に対応することができる。また、ポリシーで表現されたネットワークを、ファブリックが自動的に実装してくれるため、障害時も自動的に再構成される。技術的には、EPGが定義されるとそのグループ用のVXLANが定義される。サーバの役割グループ毎に個別のVXLANが作成されるため論理的に分割されたネットワークとなり高いセキュリティを確保できる。またVXLANの実装においては、スイッチのハードウェアレベルでASICに実装しているため、VXLAN間のルーティングが速くかつ管理などもネットワーク・プロトコルにより自立化しているので、スイッチやリンクの障害があっても自動的に転送ルートが切り替わり収束速度も早い。

マイクロソフトのプライベートクラウドとCisco ACIの連係

 最近のマイクロソフトは、AzureやOffice 365など、クラウドに関するメッセージを強めている。その中で、日本マイクロソフト エバンジェリスト 高添 修氏は、クラウドをビジネスの中心に据え始めたマイクロソフトの考えるプライベートクラウドと説明するとともに、これにCisco ACIがどう繋がるかを紹介した。

ITの価値は使われることで生まれる

im_ait_ciscoacis02.jpg 日本マイクロソフト エバンジェリスト 高添 修氏

 パブリッククラウドの便利さは否定しようがない。しかし、多くの企業では、何もかもをパブリッククラウドに持って行くわけにはいかない。パブリッククラウドのメリットを最大限に生かしながら、自社内の環境を構築するにはどうすればいいのだろうか。マイクロソフトが勧めるのは、パブリッククラウドとしてMicrosoft Azureを使い、プライベートクラウドをWindows Azure Packで構築するという方法だ。

 Azure Packは、Azureと同じアーキテクチャのプライベートクラウドを構築するソリューション。たとえばFlexPodを採用すればシスコ、ネットアップ、マイクロソフトで検証済みの構成が提供されるため、プライベートクラウドといっても一から積み上げる必要はない。ネットワークの設定は、ACIと連係することでポリシーモデルを利用できる。

 利用者から見ると、ポータル画面や作業がパブリッククラウドと共通化される。ACIと連係することでネットワークもサービス化されるため、ネットワークの設計を考えることなく社内の仮想サーバーを作成できる。

Azure PackからAzure Stackへ

 最近のマイクロソフトは、クラウド生まれの技術を社内向け製品へ展開するようになってきた。Azureポータルの大幅なリニューアルや新ハイブリッド戦略も、クラウドファーストの技術を社内へという流れだ。

 新ハイブリッド戦略では、Azureとオンプレミスのデータセンターを、画面だけでなくコンセプトもテクノロジーも同じにすることを狙っており、そのためのオンプレミス用ソリューションとして「Azure Stack」を定義している。Azure Stackは、2016年のWindows Server 2016の発表と近いタイミングで登場する予定で、基盤が完全にAzureと共通化される。

 ITに対してビジネスからの要求が高まり、アプリケーションのパラダイムシフトが起きつつある。その要求に応えられるプラットフォームには、ハードウエア、ソフトウエア定義のインフラ、OS、タスク分散処理といった階層がある。その中でも、絶対になくならないのがハードウエアとアプリケーションだ。シスコのACIは、ハードウエアに対するアプローチとして非常にユニークだ。また社内のITには、「使いたくなるサービスかどうか」という利用者の視点と、「構築・運用の効率化」という視点が不可欠だ。この2つの視点を兼ね備えたマイクロソフトのプライベートクラウドとシスコのACIの組み合わせは、新しい選択肢だと、高添氏は話した。

後編に続く)

Copyright© 2017 ITmedia, Inc. All Rights Reserved.


提供:シスコシステムズ合同会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2015年12月29日

関連記事

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

関連特集

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。