レイヤ 4 ~ レイヤ 7 統合のついて
ACME 社 は、同社が新しいアプリケーションを設計したとき、たとえば、ファイアウォール、ロード バランサ、IDS/IPS、あるいはその他のタイプの higher-layer サービス デバイスなど、一部のサービスを組み込む必要があることに気づいていました。
従来のインフラストラクチャでは、サービスを挿入するにはデバイスを直列(インライン)に配置またはリダイレクトし、サービス デバイスへのトラフィックへ流れるようにする必要がありますたとえば、ファイアウォールを「bump in the wire」として、またはゲートウェイ ルータまたはスイッチ近くの付加サービス デバイスとして、直接インラインに配置することができます。一般的に、ファイアウォールは、静的設定のブロックを構築することで、デバイスごとに構成します。これらの静的設定ブロックは構成が機能する状況を生み出すために経時的に増大しますが、柔軟性が低く、壊れやすくなり、それによって変更管理が困難になる可能性があります。
シスコのアプリケーション セントリック インフラストラクチャ(ACI)の主要なテクノロジー イノベーションの 1 つとして、サービス グラフの適用によるサービス挿入のポリシー ベースの管理があります。この章の残りの部分では、レイヤ 4 ~ レイヤ 7 のサービスを効率的に管理するために、プロセスがどのように機能するかと、ACME がサービス グラフをどのように利用するかの概要を示します。
データセンター ファブリック機器は、ファブリック内の物理ホストや仮想ホスト間での入力からファブリックまでと、ファブリックからの出力への高速かつ効率的な転送を主な目的としています。有効なインフラストラクチャの実装では、この高速なファブリックをレイヤ 4 ~ レイヤ 7 サービスの統合をスマートに行うためにも利用します。レイヤ 4 ~ レイヤ 7 サービスには、次のようなものがあると考えられます。
- Firewalls
- ロード バランサ
- トラフィック検査のアプライアンス
- SSL オフロード機能
- アプリケーション フローのアクセラレーション機能
サービスと Cisco ACI サービス グラフとの統合サービスは、ACME に次の利点を提供します。
- ポリシー ベースの構成管理
- ACI オブジェクト モデルによる柔軟な構成状態の抽象化
- すべて一貫した ACI オブジェクト モデルに基づいた、APIC GUI、REST API、または Python を使用した統合構成の管理
- 複雑なトポロジモデル上で論理フローを繋げていくことで、複数のデバイス間を結ぶ抽象化されたリンクを作成
- ポリシー ベースのプロビジョニングによる高速で複雑なトポロジの展開
- 構成の同期化による、手動による介入を必要としない動的なワークロードのプロビジョニングとデプロビジョニング
- アプリケーション中心のテンプレート ベースの構成管理およびオブジェクトの再利用によるインフラストラクチャ実装タイムラインの短縮
- ファブリックおよびサービス デバイス内のインフラストラクチャ マルチテナント
サービス挿入設計の原則
ACI のスパインリーフ アーキテクチャと総合的なファブリック管理という側面により、サービス デバイスに出入りするトラフィック フローはきわめて効率的に管理されるため、ネットワーク ファブリック内の特定の場所にデバイスを配置する必要はありません。サービス アプライアンスは物理的でも仮想でも可能であり、ACI ファブリックの管理下のいずれのリーフにも接続できます。該当する場合は、物理アプライアンスを複数のコンテキストモードで実行させ、ファブリック転送のマルチテナント マッピングや、テナント固有のサービス構成を可能にできます。
EPG 通信へのサービス グラフの適用
ACI ファブリック内のエンドポイント グループ間の通信を許可するには、コントラクトを正しい個所に設定する必要があります。このコントラクトは、指定したプロトコルおよびポートで定義した特定のコンシューマ/プロバイダーの関係という形式をとる場合があります。完全にオープンな通信を許可する「すべてを許可」というコントラクトである場合もあります。このコントラクトは、基本的に、エンドポイント グループ間の通信フローを制御します。また、サービス グラフをコントラクトに付加することによってサービス挿入を含めるように拡張できます。この場合、サービス グラフは、ポリシー ベースの構成を備えることで解決されたサービス デバイスにコントラクトを結び付けます。
サービス グラフのレンダリング
Cisco Application Centric Infrastructure (ACI) では、ユーザが次の方法でポリシーを定義できます。
- Application Policy Infrastructure Controller (APIC) GUI
- Python SDK(Cobra)
- RESTful API
これらのポリシー オブジェクトを作成、操作、再利用できます。レイヤ 4 ~ レイヤ 7 のサービスに関連することから、これらのオブジェクトは、アプリケーションに関してそのオブジェクトを使用することが目的であることを表します。
アプリケーション プロファイルが展開され、エンドポイントがリーフ スイッチに接続されると、サービス グラフのオブジェクトが特定のデバイスの設定に変換され、レンダリングと呼ばれるプロセスを通じてサービス デバイスにプッシュされます。また、APIC もネットワーク転送パスを設定し、適切な転送アクションが行われて、処理を行うためのサービス デバイスへのトラフィック フローが得られていることを確認します。
この構成管理の抽象化プロセスは、想定される動作を定義できるポリシー テンプレートのように機能し、2 つのエンドポイント グループをリンクし、それらの関係をポリシーに委ねます。このポリシーは、必要に応じてコピー、再利用、再パッケージ化できます。レンダリングには、ACI ファブリックとレイヤ 4 ~ レイヤ 7 デバイスの両方に必要な設定の割り当てと設定が含まれます。
多くの顧客と同様に、ACME にはファイアウォールすべてとロードバランシング サービスのためのいくつかのテンプレートがあります。これらのテンプレートの初期定義は手間がかかる可能性がありますが、その後でテンプレートを再利用すると、IP アドレス、ポート、オブジェクト グループなどの値を置き換えることで、非常に扱いやすくなります。
統合サポート機能
Cisco Application Centric Infrastructure (ACI) モデルでは、サービス デバイスとの通信がデバイス パッケージのインポートによってサポートされています。これらのデバイス パッケージには、デバイスの説明や公開された機能が備わっており、構成スクリプトのコンテンツも備えています。デバイス パッケージをインポートすると、デバイスで何が実行できるか、ファブリックにどのように接続するか、トラフィックをデバイスに送り込み、トラフィックをデバイスから戻すためのパスをどのように構築するか、ポリシーの意図をデバイス固有の構成にどのように変換するかがすべて ACI ファブリックにわかるようになっています。このデバイス パッケージは、製造元のベンダーからすぐに入手できるベンダー開発のパッケージです。
API を使用しているパートナーの最新リストは、次の URL で確認できます。
http://www.cisco.com/c/en/us/solutions/data-center-virtualization/unified-fabric/aci_ecosystem.html