vPathまたは仮想化環境でサービスチェーンを作成する方法

最小限の時間コストで仮想化アプリケーションのコンポーネント間のトラフィック制御を提供する方法は？ ネットワーク構成やアプリケーション自体の構成を変更せずに、ファイアウォール、パケットフィルター、トラフィックバランシングシステムなどの複数のサービスコンポーネントを介してチェーンでトラフィックを転送できるテクノロジーはありますか？ ここでは、Cisco vPathテクノロジーについて説明します。これにより、ハイパーバイザーの製造元に依存せずに、仮想化環境でサービスチェーンを適切に作成できます。

1.問題の声明

ソースデータ：

• WEB、APP、DBなど、いくつかのコンポーネントで構成されるアプリケーションがあります。
• コンポーネントは仮想マシン（VM）であり、ハイパーバイザーのクラスター内にあります。
• すべてのコンポーネントは同じネットワークセグメントに接続され、1つのデフォルトゲートウェイを使用して外部と通信します。

アプリケーションコンポーネントのネットワーク接続の構成図は、図2のようになります。 1。


図 1アプリケーションをネットワークに接続する組織の論理図

デフォルトでは、アプリケーションコンポーネントと外部の世界との間の相互作用マトリックスは次のようになります。


図 2アプリケーションコンポーネント間の相互作用のソースマトリックス

アプリケーションコンポーネント間で送信されるトラフィックは、いかなる方法でも制御されません-すべてがすべての人に許可されます。

一般的な形式の問題の説明：

• アプリケーション構成を変更せずに、アプリケーションコンポーネント間のトラフィックを制御する機能を提供します。
• 制御とは、アプリケーションコンポーネント間のトラフィック転送のパスに沿ってサービス要素を透過的に埋め込む機能を意味します。
• サービス要素は、パケットフィルタリング、負荷分散、アプリケーションレベルでの詳細検査、トラフィック圧縮、ネットワークトラフィック分析などを実行する仮想マシンです。 など。
• タスクの重要な部分- いくつかのサービス要素が存在する可能性があり、埋め込みの複雑さはその量に依存すべきではありません。
• チェーンでサービス要素を構築することが可能であるべきです。

実際のタスク番号1の例-パケットフィルターの埋め込み

アプリケーション間のトラフィックを制御する機能は、 Cisco VSGなどのパケットフィルターと呼ばれるサービス要素によって提供されます。 パケットフィルターは、仮想マシン間のデータ転送のパスに組み込まれています。 フィルターを埋め込んだ後、相互作用行列が変化し、次のようになります。


図 3透過埋め込みパケットフィルター

図の注 3 ：図は、パケットフィルターが実行する論理演算を示しています。 一般に、1つの仮想マシンがこのタスクを処理できます。 この注記は、以下の図にも関連しています。

パケットフィルターの機能：

• 外部セグメントからユーザーのアプリケーションのWEBコンポーネントへの着信トラフィックのみを許可します。
• 外部セグメントからAPPおよびDBアプリケーションコンポーネントへのトラフィックは禁止されています。
• WEB-APPとAPP-DBコンポーネントのペア間のトラフィックは、既知のプロトコルとポートを介して許可されます。
• 他のすべてのトラフィックは禁止されています。

実際のタスク番号2の例-サービスチェーンの作成

実際のプロジェクトの経験に基づいて、多くの場合、アプリケーション所有者、ネットワーク管理者、およびセキュリティ管理者は、インフラストラクチャからの単なるパケットフィルタリング以上のものを求めています。 プロジェクトで毎日遭遇する問題に近い問題の定式化は、このように見えます。


図 4アプリケーションコンポーネント間のサービスチェーン

アプリケーションのWEBコンポーネント宛てのユーザートラフィックは、最初のサービスチェーンを通過します。

• トラフィックは、まずCisco Netscaler 1000Vなどのロードバランサーに送られる必要があります。
• 次に、バッグフィルターの大まかなクリーニングを行います。
• 次に、ファイアウォールを使用して、たとえばCisco ASAv *など、より細かいクリーニングを行います。
• そして、バランスの取れた、クリーンな、検査されたトラフィックがWEBコンポーネントに転送される必要があります。

* ASAv 9.2（1）の現在のバージョンには、vPathサポートがありません。 その実装は近い将来に計画されています。

サービスコンポーネントのセットと順序が異なる他のサービスチェーンは、トラフィックパスに沿って発生する場合があります。 この例では、2番目のサービスチェーンはパケットフィルターとファイアウォールで構成されています。

2.従来の方法による問題の解決

従来の方法を使用してサービスチェーンを作成する場合、1つのサービスコンポーネントから別のサービスコンポーネントにトラフィックをリダイレクトする問題は、ネットワークトポロジを変更することで解決されます。 考えられたばかりの「実際の問題2」をどのように解決できるかを見てみましょう。 サービス仮想マシンとアプリケーションの間で、唯一可能なデータ転送パスが作成されます。図を参照してください。 5。


図 5トポロジを変更してサービスチェーンを作成する

サービスコンポーネントは、物理トラフィックパスに組み込まれています。 サービスチェーンの論理的な変更は、ネットワークトポロジの物理的な変更につながります。 図からわかるように 5.元の問題の1つのスイッチと1つのVLANの代わりに、2つの論理スイッチ（内部/外部）と9つのVLANがあります。 従来のトポロジ手法を使用すると、vPathが提供するものと比較して、トポロジの複雑度が何倍になるかを個別に計算できます。 VLANの代わりに、VXLANトポロジの複雑さがありますが、これは減少しません。

3.記事の主な質問

仮想化されたアプリケーションのサービスチェーンの作成を促進するために、シスコは何を提供できますか？ インフラストラクチャの複雑さを増やさずに、ハイパーバイザーに依存しない柔軟なツールを取得する方法を教えてください。

4.記事の主な答え

シスコは、仮想化環境でエレガントなサービスチェーンを実現するvPathテクノロジーを提供しています。 vPathは、Cisco Nexus 1000V分散仮想スイッチの機能です。 Cisco Nexus1000Vスイッチは、 Hyper-V 、 KVM *、 vSphereなどのすべての主要なハイパーバイザーで現在利用可能です。 vPathがどのように設計され、どのように構成され、カプセル化がどのように見えるかを見てみましょう。

* KVMバージョン5.2（1）SK1（2.2）の最初のNexus 1000Vリリースでは、vPathがサポートされていません。 その実装は、今後のリリースで計画されています。

5. vPathアーキテクチャ

vPathテクノロジーを使用するには、次のものが必要です。

• Cisco Nexus 1000V仮想スイッチ
• vPathをサポートするサービス仮想マシン。

アプリケーションのネットワーク接続を整理する最初の論理スキームを見てみましょう。 1.図6は、vPathを実装するときに行う必要がある変更を示しています。


図 6 vPathの主要なアーキテクチャコンポーネント

何が変わった？

• ハイパーバイザーに「接続」されている標準スイッチがNexus 1000Vスイッチに置き換えられました。
• 標準スイッチからNexus 1000Vに移行されたWEB、APP、DB仮想マシン。
• また、vPathをサポートするサービス仮想マシンも追加されました。これは、フィルタリング、バランス調整、ファイアウォールの使い慣れた役割を実行します。

トラフィックオペレーションを実行するために必要な数のサービスマシンを追加できます。または、実際のタスク1の例で既に見たように、1つのパケットフィルターで対応できます。 追加のスイッチおよび新しいVLAN / VXLANは登場していません。 トポロジ的には、スキームは変更されていません。

Nexus 1000Vアーキテクチャ

先に進み、vPathの仕組みを理解する前に、Nexus 1000Vスイッチデバイスについて理解しましょう。


図 7 Nexus 1000Vスイッチアーキテクチャ

図からわかるように、Nexus 1000V 7、2つのコンポーネントがあります。

• VEMモジュール（仮想イーサネットモジュール）-ハイパーバイザーに組み込まれ、トラフィックスイッチングを提供するプログラムコード。
• VSMモジュール（仮想サービスモジュール）-VEMモジュールの集中管理と構成を提供するコンポーネント。

アーキテクチャ内のNexus 1000Vは、VSM-スーパーバイザ（制御モジュール）として機能し、VEM-ラインカードとして機能する物理的なモジュラースイッチに非常に似ています。

仮想マシンをVEMモジュールに接続するために使用されるインターフェイスの設定はすべて、ポートプロファイルと呼ばれる設計に保存されます。

vPathの機能を実証するために、Nexus 1000Vを使用します。Nexus1000Vは、地元の研究室に導入されています。 ラボの仮想マシンポートは次のように構成されています。

port-profile type vethernet V-CONT.WEB switchport mode access switchport access vlan 21 no shutdown state enabled port-profile type vethernet V-CONT.APP switchport mode access switchport access vlan 21 no shutdown state enabled port-profile type vethernet V-CONT.DB switchport mode access switchport access vlan 21 no shutdown state enabled 

これまでのところ、すべてのポートの構成は同じです。 ただし、各ポートに独自のサービスチェーンを実装するため、3つの異なるプロファイルを設定します。

VPathのコアアイデア

主なアイデアは、既存のネットワークトポロジから抽象化し、必要なサービスコンポーネントを介してトラフィックをネットワークデバイスとエンド仮想マシンの両方に透過的に渡すことができるメカニズムを作成することです。 すべてのソースの例で、仮想マシンは同じVLANにあることに注意してください。

vPathはこれをどのように行いますか？

VEMモジュールは、送信されるすべてのデータストリームを追跡します。 このデータはフローテーブルに収集されます。 ストリームは、発信元IPアドレス、宛先IPアドレス、発信元ポート、宛先ポート、プロトコル、VLANの6つのエンティティによって識別されます。 ネットワークに新しいストリームが表示されるたびに、ストリームテーブルに新しいエントリが表示されます。


図 8 VEMモジュールを介して送信されるストリームの表

新しく検出された各ストリームの最初のパケットは、サービスデバイスに送信されます。 したがって、VEMモジュールはサービスデバイスに質問を「尋ね」ます。それを渡すことができるかどうか。 パケットがサービスデバイスに転送されると、vPathカプセル化されたヘッダーが追加されます。


図 9 vPathロジック

サービスデバイスは、セキュリティ、アプリケーション、またはネットワーク管理者によって構成されたルールとポリシーに従ってパッケージを検査します。 次に、サービスはvPathカプセル化を使用して同じ方法でソースパッケージをVEMモジュールに返します。vPathカプセル化には、答えが含まれています。はい、パケットをさらに転送できます。

サービスデバイスからパッケージを受け取るVEMモジュール：

• 応答をストリームテーブルのActionフィールドに書き込みます。
• ForwardコマンドがActionフィールドにあった場合、vPathカプセル化なしでパケットを宛先ポートに送信します。
• [リダイレクト]コマンドが[アクション]フィールドにある場合、vPathヘッダーを使用してパッケージをチェーンの下に移動します。
• DropコマンドがActionフィールドにあった場合、パケットを破棄します。

Cisco VSGパケットフィルタの場合のように、サービスの性質がサービス要素を介した一定のデータ送信を必要としない場合、後続のすべてのパケットは、キャッシュに記録されたサービスデバイスからの応答を使用してサービス要素をバイパスして送信されます。

以下は、アプリケーションコンポーネント間でバッチフィルタリングを整理する必要がある場合の単純化されたvPathアルゴリズムです。


図 Cisco VSGの10 vPathアルゴリズム

6. vPathの構成

それでは、ラボベンチでのvPathメカニズムの実際的なセットアップに移りましょう。 次のトポロジを実装しました。


図 11実験台のトポロジー

最初に、トラフィックのリダイレクト先となるサービスノードを登録します。

 vservice node ASA-1 type asa ip address 10.0.21.1 adjacency l2 vlan 21 fail-mode close vservice node VSG-1 type vsg ip address 10.0.21.254 adjacency l2 vlan 21 fail-mode close 

Nexus 1000Vが登録済みモジュールを「認識」し、そのステータスがAliveであることを確認します。

 N1K# show vservice brief -------------------------------------------------------------------------------- License Information -------------------------------------------------------------------------------- Type In-Use-Lic-Count UnLicensed-Mod asa 2 -------------------------------------------------------------------------------- Node Information -------------------------------------------------------------------------------- ID Name Type IP-Address Mode State Module 1 VSG-1 vsg 10.0.21.254 v-21 Alive 4, 2 ASA-1 asa 10.0.21.1 v-21 Alive 4, <  > 

以前に登録した2つのモジュールのサービスチェーンを作成します。

 vservice path WEB-CHAIN node VSG-1 profile WEB_SP order 1 node ASA-1 profile TEST-EDGE-SP order 3 

Nexus 1000Vがサービスチェーンを「見る」ことを確認します。

 N1K# show vservice brief <  > -------------------------------------------------------------------------------- Path Information -------------------------------------------------------------------------------- Name:WEB-CHAIN NumOfSvc:2 Mod:4, Node Order Profile VSG-1 1 WEB_SP ASA-1 3 TEST-EDGE-SP -------------------------------------------------------------------------------- <  > 

ASAとVSGで構成されるサービスチェーンを、WEB仮想マシンのネットワークへの接続を定義するプロファイルに接続します。

 port-profile type vethernet V-CONT.WEB org root/tenant-01 vservice path WEB-CHAIN 

Nexus 1000Vが設定されたチェーンを「見る」ことを確認します。

 N1K# show vservice brief <  > -------------------------------------------------------------------------------- Port Information -------------------------------------------------------------------------------- PortProfile:V-CONT.WEB Org:root/tenant-01 Path:WEB-CHAIN Node Profile(Id) VSG-1(10.0.21.254) WEB_SP(9) ASA-1(10.0.21.1) TEST-EDGE-SP(8) Veth Mod VM-Name vNIC IP-Address 15 4 r1-web-v2 1 10.0.21.10 <  > 

ここで、APPおよびDB仮想マシンに送信されるトラフィックがパケットフィルターを介して送信されることを確認します。

 port-profile type vethernet V-CONT.APP org root/tenant-01 vservice node VSG-1 profile APP_SP port-profile type vethernet V-CONT.DB org root/tenant-01 vservice node VSG-1 profile DB_SP 

その結果、実験室で複数の構成ラインを使用して、次のトラフィック転送スキームがVLAN = 21内に実装されました。 同時に、新しい補助スイッチまたはVLANを作成しませんでした。 図 図12は、判明したサービスチェーンを示しています。


図 12例で構成されたサービスチェーン

提示された構成からわかるように、サービス要素をそれに合わせてネットワークトポロジを変更する必要がある場合に行う必要のある変更と比較すると、非常に簡単です。 もう一度強調します-元のトポロジは変更されていません。

7. vPathカプセル化

vPathは、ソースパッケージを次のようにヘッダーにパッケージ化します。



図 13 vPathカプセル化

サービス仮想マシンが同じセグメントにある場合、トランスポートL2ヘッダーが元のパケットに追加されます。 サービスマシンが別のセグメントにある場合、トランスポートL3ヘッダーが追加されます。 元のフレームの本体は変更されません。 トランスポートヘッダーとソースパッケージの間には、vPathヘッダーがあります。

vPathヘッダーは、3つの必須コンポーネントで構成されています。

• ベースヘッダー
• サービスヘッダー
• プラットフォームヘッダー。

図 14 vPathヘッダー

ベースヘッダー：

• プロトコルバージョンとサービスチェーン識別子が含まれます。

サービスチェーン自体はヘッダーに含まれないことに注意してください。 一意の識別子のみが存在します。 チェーンに関する情報は、特別なテーブルサービステーブルに保存されます。サービステーブルは、FlowTableと同様、すべてのVEMモジュールにあります。 このテーブルは、システム所有者が構成を変更するときにVSMモジュールから集中的にプログラムされます。

サービスヘッダー：

• vPathの使用済みバージョンの承認手順を実装します。
• サービスデバイス上のプロファイル識別子に関する情報を転送します。
• VEMモジュールとサービスデバイス間の要求/応答手順を実装します。

プラットフォームヘッダー：

• vPathを実装するプラットフォームに固有の情報を転送します。
• 送信元ポート識別子が含まれています
• VLAN、VXLANのセグメントタイプの識別子が含まれます。
• セグメント識別子を含む-VLAN番号、VXLAN番号。

VEMモジュールが仮想マシンから受信し、サービスモジュールにリダイレクトするパッケージを次に示します。 後者は、このパケットをサービスチェーンに沿ってさらに送信できるかどうかを決定する必要があります。 サービスヘッダーでは、REDIRECT関数が実行されていることがわかります。 サービスモジュールは、L2を介してVEMモジュールに接続されます。


図 15 VEMがサービスモジュールに送信するパケット

次のスクリーンショットは、パッケージの検査後にVEMモジュールがサービスモジュールから受け取ったパッケージです。 Service Context HeaderフィールドにはRESPONSE識別子が含まれ、ACTIONフィールドはPERMITに設定されます。これは、このパケットを渡すことができることを意味します。


図 16 VEMが検査後にサービスモジュールから受信するパケット

8.結論

この記事では、データセンターでサービスチェーンを作成する問題について説明しました。 仮想化インフラストラクチャの所有者の多くは、アプリケーションを展開するときにこの問題に直面しています。 ネットワークトポロジを変更してサービスデバイスに合わせて問題を解決すると、ネットワーク構成がより複雑になります。 しかし、Nexus 1000Vスイッチを展開し、いくつかの簡単なコマンドで構成されたvPathテクノロジーを使用して、この問題を解決する簡単な方法を見ました。