レイヤー3 LACP宛先アドレスハッシュはどのように正確に、具体的には機能しますか？
1年以上前の以前の質問（ Multiplexed 1 Gbps Ethernet？ ）に基づいて、LACPリンクが至る所にある新しいISPで新しいラックをセットアップしました。これが必要なのは、累積1Gbpsを超えるインターネット上の何千ものクライアントコンピュータにサービスを提供する個々のサーバー（1つのアプリケーション、1つのIP）があるためです。
このLACPのアイデアは、10GoEスイッチとNICに大金を費やすことなく、1Gbpsの壁を打ち破ることを可能にするはずです。残念ながら、私はアウトバウンドトラフィックの分配に関していくつかの問題に遭遇しました。 （これは、上記のリンクされた質問でのKevin Kuphalの警告にもかかわらずです。）
ISPのルーターは、ある種のシスコです。 （MACアドレスから推測しました。）私のスイッチはHP ProCurve 2510G-24です。サーバーはHP DL Debian Lennyを実行する380 G5です。1台のサーバーはホットスタンバイです。アプリケーションをクラスター化することはできません。ここに、IP、MACを含むすべての関連ネットワークノードを含む簡略化したネットワーク図を示します。およびインターフェース。
詳細はすべて記載されていますが、問題を処理して説明するのは少し難しいです。したがって、簡単にするために、ノードと物理リンクに限定したネットワーク図を次に示します。
それで私は外に出てキットを新しいラックに取り付け、ISPのケーブルをルーターから接続しました。どちらのサーバーにもスイッチへのLACPリンクがあり、スイッチにはISPルーターへのLACPリンクがあります。 LACP構成が正しくないことに最初から気づきました。テストでは、各サーバーとの間のすべてのトラフィックが、サーバーからスイッチとスイッチからルーターの両方の間で排他的に1つの物理GoEリンクを通過していることがわかりました。
いくつかのグーグル検索とLinuxに関するRTMF時間の大幅なNICボンディングにより、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つの物理リンクstillだけを介してスイッチからルーターに移動していました。
両方の物理リンクを通過するトラフィックが必要です。 2510G-24の 管理および構成ガイド を読んで再読した後、次のことがわかりました。
[LACPが使用する]送信元と宛先のアドレスペア（SA/DA）は、トランクリンクを介して送信トラフィックを分散します。 SA/DA（送信元アドレス/宛先アドレス）により、スイッチは送信元/宛先アドレスのペアに基づいて、トランクグループ内のリンクに送信トラフィックを分散します。つまり、スイッチは、同じトランクアドレスを介して同じ送信元アドレスから同じ宛先アドレスにトラフィックを送信し、別のリンクを介して同じ送信元アドレスから別の宛先アドレスにトラフィックを送信します。トランク内のリンク。
結合されたリンクはMACアドレスを1つしか提示しないようです。そのため、スイッチからルーターへのMACは1つしか見えないため（2つではなく1つから）、サーバーからルーターへのパスは常に1つのパスを経由します。各ポート）両方のLACPリンク。
とった。しかし、これは私が欲しいものです：
より高価なHP ProCurveスイッチは、2910alがハッシュでレベル3の送信元アドレスと宛先アドレスを使用することです。 ProCurve 2910alの「 管理および構成ガイド ：」の「トランクリンクを介した送信トラフィックの分配」セクションから：
トランクを介したトラフィックの実際の分配は、送信元アドレスと宛先アドレスのビットを使用した計算に依存します。 IPアドレスが使用可能な場合、計算にはIP送信元アドレスとIP宛先アドレスの最後の5ビットが含まれます。それ以外の場合は、MACアドレスが使用されます。
OK。したがって、これが私が望むように機能するためには、送信元アドレスが固定されているため、宛先アドレスが重要です。これは私の質問につながります：
レイヤー3 LACPハッシュはどのように正確かつ具体的に機能しますか？
どの宛先アドレスが使用されているかを知る必要があります。
- クライアントのIP、最終宛先？
- またはルーターのIP、次の物理リンクの送信先。
まだ交換せずに交換用スイッチを購入しました。レイヤー3 LACP宛先アドレスハッシュが必要かどうかを正確に理解してください。別の不要なスイッチを購入することはできません。
あなたが探しているものは一般に「送信ハッシュポリシー」または「送信ハッシュアルゴリズム」と呼ばれています。フレームを送信する集約ポートのグループからのポートの選択を制御します。
802.3ad標準を手に入れることは、お金を使う気がないので難しいことがわかっています。そうは言っても、私はあなたが探しているものにいくつかの光を当てる半公式の情報源からいくつかの情報を収集することができました。ごと 2007年オタワ、オンタリオ州、カリフォルニア州IEEE 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アドレスや宛先IPアドレスのバリエーションが多ければ多いほど、レイヤ3ベースの送信ハッシュポリシーを使用すると、集約がより効率的になります。
ダイアグラムには、インターネットからサーバーに直接送られる要求が示されていますが、プロキシが状況に対して何を行うかを指摘することは価値があります。クライアント要求をサーバーにプロキシしている場合、 クリスが答えで語っている のように、ボトルネックを引き起こす可能性があります。そのプロキシがインターネットクライアントのIPアドレスからではなく、独自のソースIPアドレスから要求を行っている場合、厳密にレイヤー3ベースの送信ハッシュポリシーでは、可能な「フロー」が少なくなります。
送信ハッシュポリシーは、802.3ad標準の要件を満たしている限り、レイヤー4情報（TCP/UDPポート番号）も考慮することができます。質問で参照しているように、そのようなアルゴリズムはLinuxカーネルにあります。そのアルゴリズムのドキュメントでは、断片化のため、トラフィックが必ずしも同じパスに沿って流れるとは限らないため、アルゴリズムが厳密に802.3adに準拠しているわけではないことに注意してください。
非常に驚いたことに、数日前にテストを行ったところ、xmit_hash_policy = layer3 + 4は、直接接続された2つのLinuxサーバー間では効果がなく、すべてのトラフィックが1つのポートを使用することがわかりました。どちらも、ボンディングデバイスをメンバーとして持つ1つのブリッジでxenを実行します。ほとんどの場合、ブリッジが問題を引き起こす可能性がありますが、意味がないというだけですAT ALL ip + portベースのハッシュが使用されることを考えると、.
ボンディングリンクを介して実際に180 MB以上のプッシュを実行している人（つまり、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のハイパフォーマンストークを参照）-1つのCPUを超えてスケーリングしないため、より高いCPUクロック>多くのコアを結合します。
anyoneが優れた高性能のボンディング設定になるか、または彼らが何を話しているかを本当に知っている場合、彼らが新しい小さなハウツーを作成するのに30分かかったとしたら、それは素晴らしいことでしょう。 LACP、奇妙なものと帯域幅なし> 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に基づいたルックアップが必要でしょう。