Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

ECMPロードバランシングのためのカスタマイズされたハッシュフィールド選択

概要: カスタム ハッシュ機能

Contrail Networking では、ECMP(イコール コスト マルチパス)のロード バランシング時にハッシュに使用するフィールドのセットを設定できます。

カスタム ハッシュ機能を使用すると、ユーザーは、適格な ECMP 候補のセットの中から転送パスを選択する際に、ハッシュするフィールドの正確なサブセットを設定できます。

カスタム ハッシュ構成は、次の方法で適用できます。

  • グローバル

  • 仮想ネットワーク当たり (VN)

  • 仮想ネットワークインターフェイス(VMI)当たり

VMI 設定は VN 設定よりも優先され、VN 設定はグローバル レベルの設定(存在する場合)よりも優先されます。

カスタム ハッシュは、特定の送信元から発信され、特定の宛先に宛てられたパケットが、転送中に同じサービス インスタンスのセットを通過する必要がある場合に役立ちます。これは、送信元、宛先、またはトランジットノードがフローに基づいて特定の状態を維持し、状態の動作を、同じ送信元アドレスと宛先アドレスのペア間の後続の新しいフローにも使用できる場合に必要になることがあります。このような場合、後続のフローは、同じサービス ノードのセットの後に最初のフローが続く必要があります。

次の図に示すように、Contrail Web UI を使用して 、[> ネットワーキング > ネットワークの設定 ] ウィンドウの [ECMP ハッシュ フィールド] セクションで、ハッシュするネットワーク内の特定のフィールドを識別できます。

仮想ネットワークにハッシュ フィールドが設定されている場合、その VN を宛先とするすべてのトラフィックは、vRouter による ECMP パスを介した転送中に、カスタマイズされたハッシュ フィールド選択の対象となります。これは、宛先ネットワークへのすべてのトラフィックを、IPファブリック上のより小さなパスセットに歪める可能性があるため、すべての場合において望ましくない場合があります。

より実用的なシナリオは、送信元と宛先の間のフローがその間の同じサービス インスタンスを経由する必要がある場合で、サービス インスタンスの仮想マシン インターフェイス用にカスタマイズされた ECMP フィールドを設定できます。その後、その仮想マシンインターフェイスから発信される各サービスチェーンルートは、目的のECMPフィールド選択をパス属性として適用し、最終的にingress vRouterノードに伝播されます。次の例を参照してください。

ECMP ハッシュフィールド選択の使用

カスタムハッシュフィールドの選択は、宛先に対して複数のECMPパスが存在するシナリオで最も役立ちます。通常、複数の ECMP パスが指すのはイングレス サービス インスタンス ノードであり、Contrail クラウド内の任意の場所で実行できます。

サービスチェーン上のECMPハッシュフィールドの設定

ECMP over Service チェーンでカスタマイズされたハッシュフィールドを作成するには、次の手順に従います。

  1. サービスチェイニングとECMPロードバランシングを使用して、相互接続に必要な仮想ネットワークを作成します。

  2. サービス テンプレートを作成し、スケーリングを有効にします。

  3. サービス インスタンスを作成し、サービス テンプレートを使用して、次を選択して構成します。

    • スケールアウトに必要なインスタンス数

    • 左右の仮想ネットワークを接続します

    • 共有アドレス空間は、インスタンス化されたサービスがそれぞれ左と右に同じIPアドレスを持つようにします

    この設定により、転送中にこれらすべてのサービス インスタンス間で ECMP が有効になります。

  4. ポリシーを作成し、以前に作成したサービス インスタンスを選択して、目的の VMI または VN にポリシーを適用します。

  5. サービス VM がインスタンス化されると、左右のインターフェイスのポートを使用してさらに構成できるようになります。[ネットワーク] の [Contrail Web UI ポート] セクションで、サービス インスタンスの左側のインターフェイス(仮想マシン インターフェイス)のポートを選択し、目的の ECMP ハッシュ フィールド設定を適用します。

    メモ:

    現在、サービス インスタンスの左または右インターフェイスの ECMP フィールド選択構成を適用するには、「ネットワーク」の [ポート(VMI)]セクションを使用し、インスタンス化された各サービス インスタンスの VMI に対して ECMP フィールド選択を明示的に構成する必要があります。最適なパスのみのロード バランス属性がイングレス vRouter に引き継がれるため、最終結果が期待どおりになるように、グループのすべてのサービス インターフェイスに対してこれを行う必要があります。ロードバランス属性が設定されていない場合、他のパスにその設定があっても、イングレス vRouter には伝送されません。

設定が完了すると、vRouterは、さまざまなサービスインスタンスへのECMPパスを含むルーティングテーブルでプログラムされます。また、vRouterには、トラフィックの負荷分散時に使用する望ましいECMPハッシュフィールドがプログラムされています。

負荷分散システムのための流れの粘着性

フローの固執性は、Contrail Networkingリリース21.3のベータ機能で、負荷分散システム内の等コストマルチパス(ECMP)グループ間でのフローの再マッピングを最小限に抑えるのに役立ちます。

ここでは、3メンバーのECMPロードバランシングシステムに新しいメンバーが追加されたときに発生するフロー再マッピングの問題の例を示します。ワークフローについては、 図 1 を参照してください。

図 1: スケールアップ シナリオ Example for Scale-Up Scenarioの例

この例では、フロー要求を IP アドレス 1.2.3.4 に送信します。これは VIP アドレスが 1.2.3.4 の 3 メンバー グループであるため、vRouter はフロー ハッシュ計算に基づいて pod1 に要求を送信します。同じ VIP グループに新しいメンバー pod4 を追加しましょう。これで、要求は転送され、フロー ハッシュの再計算に基づいて pod4 にリダイレクトされます。

フローのスティッキリ性により、このようなフローの再マッピングが減少し、新しいメンバーpod4が追加されても、pod1への元のパスでフローが保持されます。pod4 を追加するとフローに影響する場合、vRouter はフローテーブルを再プログラムし、pod1 とフローのバランスを取り直します。

表 1 は、スケールアップおよびスケールダウンのシナリオで予想される通常のハッシュとフローのスティクネスの結果を示しています。

表 1: ECMP グループにメンバーが追加または削除された場合に期待される結果

シナリオ例

通常(静的)ハッシュ結果

フロー粘着性結果

ECMP グループ サイズは 3 です。

フローハッシュに基づいて、トラフィックはpod1に送信されます。

フローハッシュに基づいて、トラフィックはpod1に送信されます。

同じサービスにもう 1 つのポッドを追加します。ECMP グループ サイズは 4 です。

フローの再分配が可能になり、トラフィックを別のポッドにリダイレクトできるようになりました。

トラフィックは引き続きポッド1に送信されます。

同じサービスからポッドを 1 つ削除します。ECMP グループ サイズは 2 です。

フローの再分配が可能になり、トラフィックを別のポッドにリダイレクトできるようになりました。

pod1 が削除されない限り、トラフィックは引き続きポッド 1 に送信されます。pod1 が削除された場合、クライアントからセッションを再開する必要があります。

フローの持続性は、スケールアップまたはスケールダウンの前後にフローが ECMP フローである場合にのみサポートされます。

フローの粘着性が期待どおりに機能しない方法の例を次に示します。

導入例

シナリオ

結果

2 つのコンピューティングで 2 つのポッド (それぞれに 1 つ)。

スケールアップ前

トラフィックを転送するコンピューティングに関しては、フローは非ECMPになります。

スケールアップ後

フローは ECMP フローになり、再ハッシュをトリガーします。これにより、フローの粘着性が失敗する可能性があります。

リリース履歴テーブル
リリース
説明
21.3
フローの固執性は、Contrail Networkingリリース21.3のベータ機能で、負荷分散システム内の等コストマルチパス(ECMP)グループ間でのフローの再マッピングを最小限に抑えるのに役立ちます。