ECMPアフィニティとパーシステンス

Equal-Cost Multi-Path (ECMP) ルーティングはフローを分散します。ユーザー、クッキー、ログインセッション、またはアプリケーショントランザクションを理解することはありません。安定したECMPハッシュをパーシステンス機能として扱うのではなく、アプリケーションを認識するレイヤーでアプリケーションパーシステンスを設計してください。

ハッシュはユーザーではなくフローを識別する

多くのルーターは、Internet Protocol（IP）およびトランスポートヘッダー内のフィールドからイコールコストパスを選択します。一般的な入力は、送信元アドレス、送信先アドレス、プロトコル、送信元ポート、送信先ポートの5つ（5タプル）です。正確なフィールド、シード、および動作はプラットフォームによって異なります。

選択されたフィールドが同じパケットは、ECMPセットが安定している限り、通常は同じパスをたどります。新しい接続は異なる送信元ポートを使用できるため、別のCEを選択する可能性があります。HTTP/1.0、HTTP/1.1、HTTP/2、ブラウザ接続の再利用、プロキシ、およびNetwork Address Translation（NAT）はすべて、1つの見かけ上のユーザーセッションを表すトランスポート接続の数を変化させます。

その動作はフローアフィニティにすぎません。送信元アドレスパーシステンス、クッキーパーシステンス、またはセッション状態のレプリケーションではありません。

送信元ポートを除外するとトレードオフが変わる

一部のルーターでは、ECMPハッシュから送信元ポートを除外できます。これにより、送信元アドレスと送信先アドレスが同じ接続を同じパスに維持する頻度が高くなりますが、トラフィックを分散するために利用可能な値が減少します。その結果、1つのNATアドレスの背後にいる多くのユーザーが単一のCEに集中する可能性があります。

この設定でも、アプリケーションパーシステンスは保証されません。

パスセットの変更により、ハッシュが再マッピングされる可能性があります。
CEに障害が発生すると、新しいトラフィックは別のCEに移動します。
クライアントアドレスが変更される可能性があります。
アプリケーション状態は、ルーターによってCE間でコピーされません。

厳密なパーシステンスは正しいレイヤーに配置する

アプリケーションがユーザーを同じ処理コンテキストに戻す必要がある場合は、サポートされているアプリケーションレイヤーのパーシステンスメカニズムを使用するか、セッション状態を外部化してください。例としては、クッキーパーシステンス、アプリケーション認識型ロードバランサによって実装される送信元アドレスパーシステンス、共有セッションストアなどがあります。

要件を正確に規定します。

要件	適切なメカニズム
1つのトランスポートフロー内のパケットを1つのパスに維持する	ECMPフローハッシュ
1つのアドレスからの新しい接続を1つのターゲットに維持する	送信元アドレスアフィニティ（NAT集中を考慮）
認証された1人のユーザーを1つのアプリケーションインスタンスに維持する	アプリケーションレイヤーのパーシステンス
選択されたCEまたはアプリケーションインスタンスの損失から回復する	レプリケートされたセッション状態、または外部セッションストアとヘルス対応フェイルオーバーの組み合わせ

仮定ではなく、トラフィックで検証する

複数の独立した接続を生成し、パスごと、またはCEごとのカウンタを比較します。NATの背後にあるクライアント、スコープ内のすべてのHTTPバージョン、存続期間の長い接続、およびパスセットの変更を含めます。リクエストが成功することは到達可能性を証明しますが、均等分散やパーシステンスを証明するものではありません。

パスセット変更のルーティング側については、ルーティングとフェイルオーバーを参照してください。

標準リファレンス

RFC 2992 は、イコールコストのネクストホップにフローを分散させるモデルの1つと、ネクストホップのセットが変更されたときに発生する中断について説明しています。