データセンター

シスコ アプリケーション セントリック インフラストラクチャにおけるネットワーク プログラマビリティ

ホワイト ペーパー





シスコ アプリケーション セントリック インフラストラクチャにおけるネットワーク プログラマビリティ



概要

本文書では、Cisco® アプリケーション セントリック インフラストラクチャ(ACI)におけるプログラマビリティのサポートについて説明します。Cisco ACI プログラマビリティ モデルを使用すると、プログラムを通じてアプリケーション セントリック インフラストラクチャにアクセスできます。Cisco ACI では、標準の Representational State Transfer(REST)API を通じて、システム全体のすべての物理属性と論理属性を表す基盤オブジェクト モデルへの読み取りと書き込みのアクセスができます。このアクセス機能により、管理ツールとモニタリング ツールにネットワーク導入を組み込んだり、プログラムを通じて新しいワークロードを導入したりできます。

ネットワーク プログラマビリティに対する既存のアプローチの課題

現在使われているネットワークの多くは、コマンドライン インターフェイス(CLI)を使用して管理および運営できるように、ソフトウェアと緊密に統合されたハードウェアを基盤としています。このようなシステムは、スタティック ネットワーク構成でスタティック ワークロードを扱い、アプリケーションを拡張するための変更が予測可能で変化の速度が遅い場合は問題なく機能します。データセンター ネットワークが仮想化され、クラウドや俊敏性の高い IT モデルへの移行が始まると、このモデルは機能しなくなります。

このためベンダーは、既存のサービスやデバイス OS にプログラマビリティを追加しようと取り組んでいます。このアプローチで機能を増やすことはできますが、プログラマビリティを組み込む方法として理想的とはいえません。このモデルでは、一般にネットワーク コントローラと認識される新しい管理ポイントを導入することで、柔軟性のないネットワーク構造にアプリケーションとユーザ ポリシーを人為的に対応させるため、管理が複雑になります。さらに、このようなネットワーク コントローラとベンダーが採用するモデルはネットワーク機能に限定されており、その他のインフラストラクチャをサポートするために拡張することはできません。真のプログラマビリティを実現するには、後付けで追加するのではなく基盤に組み込む必要があります。インフラストラクチャ コンポーネントと採用される構造は、開発者がすぐに理解して活用できるモデルを使用し、基盤にプログラマビリティを導入するよう設計する必要があります。

オブジェクト指向データ モデルと REST API による Cisco ACI プログラマビリティ

シスコは Cisco ACI ソリューションを通じてプログラム可能なネットワーク インフラストラクチャを構築するにあたって、根本的なアプローチを採用しました。このインフラストラクチャはファブリック レベルで単一のシステムとして動作し、Cisco Application Policy Infrastructure Controller(APIC)によって集中管理されます。このアプローチでは、データセンター ネットワーク全体が密接に結び付けられ、ビジネスをサポートするアプリケーション用のインテリジェントなトランスポート システムとして扱われます。このファブリックに含まれるネットワーク デバイスでは、このシステム ビューをサポートするための命令が OS のコアに書き込まれ、プログラマビリティに対応したアーキテクチャが基盤に組み込まれます。

前世代のソフトウェア定義型ネットワーク(SDN)ソリューションのようにプログラムによるインターフェイスを通じてネットワーク機能の一部を開放するのではなく、インフラストラクチャ全体にプログラムを通じてアクセスできます。この機能は、Cisco ACI オブジェクト モデルへのアクセスを可能にすることで実現しています。このオブジェクト モデルは、インフラストラクチャ全体における個々のソフトウェア コンポーネントとハードウェア コンポーネントの完全な構成とランタイム状態を表します。標準の REST インターフェイスを通じてこのオブジェクト モデルを利用できるため、オブジェクト モデル、つまりシステムの構成とランタイム状態へのアクセスと操作が容易になります。

概説すると、Cisco ACI オブジェクト モデルは約束理論(Promise Theory)に基づき、コントローラ クラスタが要求するステート変更を自律オブジェクトが実行することで、スケーラブルな制御アーキテクチャを実現します。詳細レベルの構成と現状を細かく把握する必要がある従来のトップダウン型管理システムに比べて、このアプローチは拡張性に優れています。約束理論では、必要なステート変更が指示されるとオブジェクトがその変更を実行し、必要に応じてエラーを報告します。

この大まかな概念のベースとなるのが、Cisco ACI プログラマビリティの中核を担うオブジェクト モデルです。このモデルは大きく論理パートと物理パートの 2 つに分かれます。モデルベースのフレームワークにより、洗練された方法でデータを表現できます。Cisco ACI モデルは、基盤となる情報モデルへの包括的なアクセスを提供し、ポリシーの抽象化、物理モデル、データのデバッグと実装を実現します。図 1 は、Cisco ACI モデルのフレームワークを示しています。このモデルは REST API を通じてアクセスできるため、システムにプログラマビリティを組み込むことができます。

図 1 Cisco ACI オブジェクト指向データ モデルと REST API

図 1. Cisco ACI オブジェクト指向データ モデルと REST API

図 1 に示すとおり、論理モデルはシステムとのインターフェイスです。API、CLI、または GUI を通じて、管理者または上位のクラウド管理システムが論理モデルとやり取りします。論理モデルを変更すると、その内容が物理モデルに反映されます。物理モデルは一般にハードウェア構成を表します。

論理モデル自体は、構成、ポリシー、ランタイム状態などの操作可能なオブジェクトと、その属性で構成されます。Cisco ACI フレームワークでは、このモデルは管理情報ツリー(MIT)と呼ばれます。MIT の各ノードは、管理対象のオブジェクトまたはオブジェクトのグループを表します。これらのオブジェクトは階層型で構成され、論理オブジェクトのコンテナを形成しています。図 2 は、MIT オブジェクト モデルの論理階層を示しています。

図 2 管理情報ツリー(MIT)

図 2. 管理情報ツリー(MIT)

MIT 内のオブジェクト

Cisco ACI は情報モデルベースのアーキテクチャを使用しており、管理プロセスによって制御できるすべての情報がモデルによって表されます。オブジェクト インスタンスは管理対象オブジェクト(MO)と呼ばれます。システム内のすべての管理対象オブジェクトは固有の識別名(DN)によって識別されます。このアプローチにより、グローバルにオブジェクトを参照できます。

またオブジェクトの識別名のほか、各オブジェクトを相対名(RN)で参照することもできます。相対名は、親オブジェクトに対して相対的にオブジェクトを識別します。指定されたオブジェクトの識別名は、親オブジェクトの識別名に相対名を加えることで取得できます。識別名は URL に直接マッピングされます。MIT 内におけるオブジェクトの現在位置に応じて、相対名または識別名のいずれかを使用してオブジェクトにアクセスできます。管理対象オブジェクト、相対名、および識別名の関係を図 3 に示します。

図 3 管理対象オブジェクト、相対名、識別名

図 3. 管理対象オブジェクト、相対名、識別名

図 3 は、指定された管理対象オブジェクトのインスタンスを一意に表す識別名と、そのオブジェクトを親管理対象オブジェクトに対する位置で表す相対名を示しています。ツリー内のオブジェクトはすべて、ルート オブジェクトの下に存在します。

ツリーは階層型で構成され、属性システムを使用してオブジェクト クラスを識別できるため、さまざまな方法でツリー内にある管理対象オブジェクトの情報を照会できます。クエリは、識別名を使用してオブジェクト自体に対して実行するか、スイッチ シャーシなどのオブジェクトのクラスに対して実行するか、ツリー レベルで実行してオブジェクトのすべてのメンバーを検出できます。図 4 は、ツリーレベルのクエリを示しています。

図 4 ツリーレベルのクエリ

図 4. ツリーレベルのクエリ

図 4 は、照会対象の 2 つのシャーシをツリー レベルで示しています。どちらのクエリも、参照されたオブジェクトと、その子オブジェクトを返します。このアプローチは、大規模なシステムのコンポーネントを検出するツールとして役立ちます。

図 4 の例では、指定したスイッチ シャーシのカードとポートを検出しています。図 5 は、別のタイプのクエリとしてクラスレベル クエリを示しています。

図 5 クラスレベル クエリ

図 5. クラスレベル クエリ

図 5 に示すとおり、クラスレベル クエリでは指定したクラスのすべてのオブジェクトを返します。このアプローチは、MIT で使用できる特定のタイプのオブジェクトをすべて検出する場合に役立ちます。この例で使用しているクラスはカードで、カード タイプのすべてのオブジェクトを返します。

3 つ目のクエリ タイプはオブジェクトレベル クエリです。オブジェクトレベル クエリでは、識別名を使用して特定のオブジェクトを返します。図 6 は、2 つのオブジェクトレベル クエリを示しており、1 つはノード 1/シャーシ 2、もう 1 つはノード 1/シャーシ 1/カード 1/ポート 2 を照会しています。

図 6 オブジェクトレベル クエリ

図 6. オブジェクトレベル クエリ

すべての MIT クエリで、サブツリー全体またはサブツリーの一部を返すよう選択できます また、システム内のロールベース アクセス コントロール(RBAC)メカニズムによって、返されるオブジェクトが決まります。必ず、ユーザが表示権限を持つオブジェクトのみが返されます。

管理対象オブジェクトのプロパティ

Cisco ACI の管理対象オブジェクトには、管理対象オブジェクトを定義するプロパティが含まれています。管理対象オブジェクトのプロパティはチャンクに分割され、オペレーティング システム内で指定されたプロセスによって管理されます。指定されたオブジェクトには、複数のプロセスがアクセスする場合があります。これらのプロパティはすべて実行時にまとめてコンパイルされ、単一のオブジェクトとしてユーザに提示されます。図 7 はこの関係を例示しています。

図 7. 管理対象オブジェクトのプロパティ

図 7. 管理対象オブジェクトのプロパティ

図 7 に示すオブジェクトの例では、オブジェクト内のプロパティ チャンクに書き込むプロセスが 3 つあります。Cisco APIC(つまりユーザ)とオブジェクトとの間のインターフェイスとなるデータ管理エンジン(DME)、ポートの構成を処理するポート マネージャ、およびスパニング ツリー プロトコル(STP)のすべてが、このオブジェクトのチャンクとやり取りします。オブジェクト自体は、実行時にコンパイルされる単一のエンティティとして、API を通じてユーザに提示されます。

REST インターフェイスによるオブジェクト データへのアクセス

REST は、World Wide Web などの分散型システム用ソフトウェア アーキテクチャの形式で、 ここ数年、有望な Web サービス設計モデルとして注目を集めています。形式がシンプルであるため、Simple Object Access Protocol(SOAP)や Web サービス記述言語(WSDL)など、その他の設計モデルに代わって採用される機会が増えています。Cisco APIC は REST インターフェイスをサポートしており、Cisco ACI ソリューション全体へのプログラムを通じたアクセスを実現します。

Cisco ACI のオブジェクトベース情報モデルは、REST インターフェイスに非常にうまく適合しています。URL と URI は識別名に直接マッピングされ、ツリー上のオブジェクトを識別でき、MIT 上の全データを XML または JavaScript オブジェクト表記(JSON)形式でエンコードされた自己完結型の構造化テキスト ツリー ドキュメントとして記述できます。オブジェクトには、識別名とプロパティを使用して識別される親子関係があり、この関係は一連の作成、読み取り、更新、および削除(CRUD)操作によって読み取りと変更が可能です。

オブジェクトにアクセスするには、明確に定義されたアドレスである REST URL を使用します。Cisco APIC オブジェクト データを取得および操作するには標準の HTTP コマンドを使用します。使用できる URL の形式は次のとおりです。

<system>/api/[mo|class]/[dn|class][:method].[xml|json]?{options}

URL の前に指定する各構成要素は、次のとおりです。

  • Systemシステム ID、IP アドレスまたは DNS で解決可能なホスト名
  • mo | class管理対象オブジェクト、ツリー(MIT)、またはクラスレベル クエリのどれであるかを示す
  • class照会するオブジェクトの管理対象オブジェクト クラス(情報モデルでの指定に従う)。クラス名の形式:<パッケージ名><管理対象オブジェクトのクラス名>
  • dn照会するオブジェクトの識別名(MIT ツリーの階層で表されたオブジェクト固有の名前)
  • methodオブジェクトに対して呼び出すメソッドの指定(オプション)。HTTP POST リクエストにのみ適用される
  • xml | jsonエンコード形式
  • optionsクエリ オプション、フィルタ、引数

REST URL で個々のオブジェクトまたはオブジェクト クラスのアドレスを指定してアクセスできる機能により、オブジェクト ツリー全体、つまりシステム全体にプログラムを通じて完全にアクセスできます。

プログラミング環境のソフトウェア開発キット

Cisco ACI の REST API は、使用する言語や開発手法を問わず、すべてのプログラム環境に簡単に統合できます。一般に使用されているプログラミング環境でさらに開発を加速させるため、Cisco ACI のソフトウェア開発キット(SDK)の提供が予定されています。Cisco ACI-pysdk は Python ベースの SDK で、Python プログラミング環境に対応しています。この SDK に含まれている Python ライブラリと API は、基盤となる REST API 呼び出しを抽象化し、Python ベースのソフトウェア スイートに簡単かつ迅速に統合できます。

まとめ

Cisco ACI オブジェクト指向データ モデルは、ネットワーク プログラマビリティを実現できるよう一から設計されています。デバイス レベルでは、オペレーティング システムは Cisco ACI に対応した完全なオブジェクトベースのスイッチ オペレーティング システムとして書き換えられています。Cisco ACI のコンポーネントは、REST API の全機能を提供する Cisco APIC によって管理されます。この API に加えて、CLI と GUI の両方を使って日々の管理業務を行います。

このオブジェクト モデルによって、REST API を使用した柔軟なプログラマビリティと、基盤となるインフラストラクチャ コンポーネントへのフル アクセスを実現します。オブジェクトは階層型モデルで論理的に構成され、MIT に保存されます。このアプローチは、ネットワーク制御とプログラマビリティのフレームワークを提供し、その他のシステムにはないオープン性を実現します。

詳細情報

http://www.cisco.com/jp/go/aci を参照してください。