レイヤー3 LACP宛先アドレスハッシュはどの程度正確かつ具体的に機能しますか？

1年前の以前の質問（多重化された1 Gbpsイーサネット？）に基づいて、LACPリンクが至る所にある新しいISPで新しいラックをセットアップしました。これが必要なのは、インターネット全体で数千台のクライアントコンピューターにサービスを提供する個々のサーバー（1つのアプリケーション、1つのIP）が1 Gbpsを超えるためです。

このLACPのアイデアは、10GoEスイッチとNICに大金を費やすことなく、1Gbpsの障壁を打破できると考えられています。残念ながら、アウトバウンドトラフィックの配信に関する問題に遭遇しました。（これは、上記のリンクされた質問でケビン・クファールの警告にもかかわらず。）

ISPのルーターは、ある種のシスコです。（これはMACアドレスから推測しました。）私のスイッチはHP ProCurve 2510G-24です。サーバーは、Debian Lennyを実行しているHP DL 380 G5です。1台のサーバーはホットスタンバイです。アプリケーションをクラスター化することはできません。これは、IP、MAC、およびインターフェイスを備えたすべてのレレバンネットワークノードを含む簡略化されたネットワーク図です。

それはすべての詳細を持っていますが、私の問題を扱い、説明するのは少し難しいです。したがって、簡単にするために、ノードと物理リンクに縮小されたネットワーク図を示します。

そこで、私は出発してキットを新しいラックに取り付け、ISPのケーブルをルーターから接続しました。両方のサーバーにスイッチへのLACPリンクがあり、スイッチにはISPルーターへのLACPリンクがあります。最初から、LACP構成が正しくないことに気付きました。テストでは、各サーバーとの間のすべてのトラフィックが、サーバーからスイッチとスイッチからルーターの両方の間で1つの物理GoEリンクを通過しました。

いくつかのグーグル検索とLinux NICボンディングに関する多くのRTMF時間により、修正によりNICボンディングを制御できることを発見しました。 /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

これにより、予想どおり、両方のNICを介してサーバーを出るトラフィックが取得されました。しかし、トラフィックは、1つの物理リンクのみでスイッチからルーターに移動していました。

両方の物理リンクを経由するトラフィックが必要です。2510G-24の管理および構成ガイドを読んで再読したところ、次のことがわかりました。

[LACPは、発信リンクを介してアウトバウンドトラフィックを配信するために、ソース/宛先アドレスペア（SA / DA）を使用します。SA / DA（送信元アドレス/宛先アドレス）により、スイッチは送信元/宛先アドレスのペアに基づいて、トランクグループ内のリンクにアウトバウンドトラフィックを配信します。つまり、スイッチは、同じトランキングリンクを介して同じ送信元アドレスから同じ宛先アドレスにトラフィックを送信し、異なるリンクを介して同じ送信元アドレスから別の宛先アドレスにトラフィックを送信します。トランク内のリンク。

ボンディングされたリンクは1つのMACアドレスのみを提示するため、サーバーからルーターへのパスは常にスイッチからルーターへの1つのパスを経由します。各ポート）LACPされた両方のリンク用。

とった。しかし、これは私が欲しいものです：

より高価なHP ProCurveスイッチは、2910alがハッシュでレベル3の送信元および宛先アドレスを使用することです。ProCurve 2910alの管理および構成ガイドの「トランクリンクを介したアウトバウンドトラフィック分布」セクションから：

トランクを通過するトラフィックの実際の分布は、送信元アドレスと宛先アドレスのビットを使用した計算に依存します。IPアドレスが使用可能な場合、計算にはIP送信元アドレスとIP宛先アドレスの最後の5ビットが含まれます。それ以外の場合、MACアドレスが使用されます。

OK。したがって、これが目的どおりに機能するためには、送信元アドレスが固定されているため、宛先アドレスがキーになります。これは私の質問につながります：

レイヤー3 LACPハッシュはどの程度正確かつ具体的に機能しますか？

どの宛先アドレスが使用されているかを知る必要があります。

• クライアントのIP、最終目的地？
• または、ルーターのIP、次の物理リンク送信先。

まだ行っていないので、交換用のスイッチを購入しました。レイヤ3 LACP宛先アドレスハッシュが必要なものかどうかを正確に理解してください。別の無駄なスイッチを購入することはオプションではありません。

探しているものは、一般に「送信ハッシュポリシー」または「送信ハッシュアルゴリズム」と呼ばれます。フレームを送信する集約ポートのグループからのポートの選択を制御します。

802.3ad規格に手を出すのは難しいと判明しました。これにお金をかけたくないからです。そうは言っても、私はあなたが探しているものに光を当てる半公式の情報源からいくつかの情報を収集することができました。あたり2007オタワ、ON、CA IEEE高速研究会の会合からこのプレゼンテーションの802.3ad規格は、「フレーム分配」のために、特定のアルゴリズムを強制しません。

この規格は、特定の配布アルゴリズムを強制するものではありません。ただし、任意の配信アルゴリズムは、43.2.3で指定されているようにフレームコレクターによってフレームが受信されたときに、a）特定の会話の一部であるフレームの誤った順序付け、またはb）フレームの複製を引き起こさないことを保証するものとします。フレームの順序を維持するための上記の要件は、特定の会話を構成するすべてのフレームがMACクライアントによって生成された順序で単一のリンクで送信されるようにすることで満たされます。したがって、この要件には、MACフレームへの情報の追加（または変更）や、フレームを並べ替えるための対応するフレームコレクター側のバッファリングや処理は含まれません。

そのため、スイッチ/ NICドライバーが送信フレームを配布するために使用するアルゴリズムはすべて、そのプレゼンテーションで述べられている要件（おそらく標準から引用されている）に準拠する必要があります。特定のアルゴリズムは指定されておらず、準拠する動作のみが定義されています。

アルゴリズムは指定されていませんが、特定の実装を調べて、そのようなアルゴリズムがどのように機能するかを理解することができます。たとえば、Linuxカーネルの「ボンディング」ドライバには、機能を適用する802.3ad準拠の送信ハッシュポリシーがあります（カーネルソースのDocumentation \ networkingディレクトリにあるbonding.txtを参照）。

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

これにより、送信元と宛先の両方のIPアドレス、および送信元と宛先のMACアドレスがポートの選択に影響します。

このタイプのハッシュで使用される宛先IPアドレスは、フレームに存在するアドレスになります。少し考えてみてください。サーバーからインターネットに向かうイーサネットフレームヘッダーのルーターのIPアドレスは、このようなフレームのどこにもカプセル化されません。このようなフレームのヘッダーにはルーターのMACアドレスが存在しますが、ルーターのIPアドレスは存在しません。フレームのペイロードにカプセル化された宛先IPアドレスは、サーバーに要求を行うインターネットクライアントのアドレスになります。

送信元と宛先の両方のIPアドレスを考慮した送信ハッシュポリシーは、クライアントのプールが非常に多様であると仮定すると、非常にうまくいくはずです。一般に、このような集約されたインフラストラクチャを通過するトラフィックの送信元および/または送信先IPアドレスがより広く変化すると、レイヤー3ベースの送信ハッシュポリシーが使用されると、より効率的に集約されます。

ダイアグラムには、インターネットからサーバーに直接送信されるリクエストが表示されますが、プロキシが状況に対して何を行うかを指摘する価値があります。クライアント要求をサーバーにプロキシしている場合、chrisが答えで述べているように、ボトルネックを引き起こす可能性があります。そのプロキシがインターネットクライアントのIPアドレスからではなく、独自のソースIPアドレスから要求を行っている場合、厳密なレイヤー3ベースの送信ハッシュポリシーで考えられる「フロー」が少なくなります。

802.3ad標準の要件を満たしている限り、送信ハッシュポリシーもレイヤー4情報（TCP / UDPポート番号）を考慮することもできます。このようなアルゴリズムは、質問で参照しているように、Linuxカーネルにあります。そのアルゴリズムのドキュメントは、断片化のためにトラフィックが必ずしも同じパスに沿って流れるとは限らないため、アルゴリズムが厳密に802.3adに準拠していないことを警告していることに注意してください。

非常に驚くべきことに、数日前のテストでは、xmit_hash_policy = layer3 + 4が2つの直接接続されたLinuxサーバー間で影響を及ぼさず、すべてのトラフィックが1つのポートを使用することが示されました。両方とも、ボンディングデバイスをメンバーとして持つ1つのブリッジでxenを実行します。ほとんどの場合、ブリッジが問題を引き起こす可能性がありますが、ip + portベースのハッシュが使用されることを考えるとまったく意味がありません。

一部の人々が実際に結合されたリンク上で180MB以上をプッシュすることを知っている（つまりcephユーザー）ので、一般に機能します。考えられるもの：-古いCentOS 5.4を使用しました-OPの例は、2番目のLACPが接続を「ハッシュ解除」することを意味します-これは理にかなっていますか？

このスレッドとドキュメントの読み取りなどが私に示したもの：

• 一般的に、誰もがこれについて多くのことを知っており、ボンディングのハウツーやIEEE標準から理論を暗唱するのが得意ですが、実際の経験はほとんどありません。
• RHELのドキュメントはせいぜい不完全です。
• ボンディングのドキュメントは2001年のものであり、最新版ではありません
• layer2 + 3モードは明らかにCentOSにはありません（modinfoには表示されず、テストでは有効にするとすべてのトラフィックがドロップされます）
• SUSE（BONDING_MODULE_OPTS）、Debian（-o bondXX）、およびRedHat（BONDING_OPTS）のすべてが、ボンドごとのモード設定を指定するための異なる方法を持っていることは役に立ちません
• CentOS / RHEL5カーネルモジュールは「SMPセーフ」ですが、「SMP対応」ではありません（facebookの高性能トークを参照）-CPUが1つを超えてスケ​​ーリングしないため、CPUクロックが高い>多くのコアを結合する

誰かが優れた高性能ボンディングのセットアップを終えた場合、または彼らが話していることを本当に知っている場合、LACPを使用した1つの実用的な例を文書化する新しい小さなハウツーを書くのに30分かかったら素晴らしいでしょう> 1つのリンク

スイッチが真のL3宛先を認識した場合、それをハッシュできます。基本的に、リンクが2つある場合、リンク1は奇数番号の宛先、リンク2は偶数番号の宛先であると考えます。ネクストホップIPを使用するように設定されていない限り、使用することはないと思いますが、これはターゲットのMACアドレスを使用するのとほとんど同じです。

遭遇する問題は、トラフィックに応じて、宛先が常に単一サーバーの単一IPアドレスになるため、他のリンクを使用しないことです。宛先がインターネット上のリモートシステムである場合、均等に配信されますが、システムが宛先アドレスであるWebサーバーのようなものである場合、スイッチは常に利用可能なリンクの1つのみでトラフィックを送信します。

ロードバランサーがどこかにあると、さらに悪い状態になります。「リモート」IPは常にロードバランサーのIPまたはサーバーのいずれかになるためです。ロードバランサーとサーバーで多数のIPアドレスを使用することで、これを少し回避できますが、それはハックです。

ベンダーの視野を少し広げたいと思うかもしれません。極端なネットワークなどの他のベンダーは、次のようなものをハッシュできます。

L3_L4アルゴリズム：レイヤ3およびレイヤ4、送信元および宛先IPアドレスの組み合わせ、送信元および宛先TCPおよびUDPポート番号。SummitStackおよびSummit X250e、X450a、X450e、およびX650シリーズスイッチで利用可能。

したがって、基本的にクライアントのソースポート（通常は大幅に変更される）が変更される限り、トラフィックを均等に分散します。他のベンダーにも同様の機能があると確信しています。

ミックスにロードバランサーがない限り、ホットスポットを回避するには、ソースIPと宛先IPのハッシュでも十分です。

ルーターではなく、クライアントIPから離れていると思います。実際の送信元IPと宛先IPは、パケット内の固定オフセットにあり、高速にハッシュを実行します。ルーターIPをハッシュするには、MACに基づいた検索が必要ですよね？

私はここに戻ったので、今までに学んだいくつかのこと：白髪を避けるには、layer3 + 4ポリシーをサポートする適切なスイッチが必要です。これはLinuxでも同じです。

かなりの場合、ALB / SLB（mode6）と呼ばれる標準を破壊するトーチがより適切に機能する場合があります。しかし、運用上はひどいです。

私は、可能な場合は3 + 4を使用しようとします。これは、2つの隣接するシステム間で帯域幅が必要になることが多いためです。

また、OpenVSwitchを使用してみましたが、トラフィックフローが中断するインスタンスが1回ありました（最初のパケットが失われるたびに...わかりません）