FreeBSDリンク集約は単一リンクよりも速くありません

我々は、4ポート置くインテルI340-T4のFreeBSD 9.3サーバにNICを¹とするために構成されたリンクアグリゲーションでLACPモード -2-にマスタ・ファイル・サーバからのデータの16のTiBにはミラー8に要する時間を短縮しようとして並行して4つのクローン。最大で4ギガビット/秒の総帯域幅が得られると期待していましたが、何を試しても、1ギガビット/秒の総帯域幅より速くなることはありません。²

iperf3静止LANでこれをテストするために使用しています。³最初のインスタンスは予想どおりほぼギガビットに達しますが、2番目のインスタンスを並行して開始すると、2つのクライアントの速度が約½ギガビット/秒に低下します。3番目のクライアントを追加すると、3つすべてのクライアントの速度が〜⅓Gbit /秒に低下します。

iperf34つのテストクライアントすべてからのトラフィックが、異なるポートの中央スイッチに入るようにテストを設定しました。

各テストマシンにはラックスイッチへの独立したパスがあり、ファイルサーバー、そのNIC、およびスイッチにはすべて、lagg0グループを分割してそれぞれに個別のIPアドレスを割り当てることでこれを実現する帯域幅があることを確認しましたこのIntelネットワークカードの4つのインターフェイスのうち。その構成では、4ギガビット/秒の総帯域幅を実現しました。

この道を歩み始めたとき、私たちは古いSMC8024L2管理スイッチでこれを行っていました。（PDFデータシート、1.3 MB。）それは当時の最高のスイッチではありませんでしたが、これを行うことができるはずです。スイッチは古くなっているため故障しているのではないかと考えましたが、はるかに高性能なHP 2530-24Gにアップグレードしても症状は変わりませんでした。

HP 2530-24Gスイッチは、問題の4つのポートが実際に動的LACPトランクとして構成されていると主張しています。

# show trunks
Load Balancing Method:  L3-based (default)

  Port | Name                             Type      | Group Type    
  ---- + -------------------------------- --------- + ----- --------
  1    | Bart trunk 1                     100/1000T | Dyn1  LACP    
  3    | Bart trunk 2                     100/1000T | Dyn1  LACP    
  5    | Bart trunk 3                     100/1000T | Dyn1  LACP    
  7    | Bart trunk 4                     100/1000T | Dyn1  LACP    

パッシブLACPとアクティブLACPの両方を試しました。

4つのNICポートすべてがFreeBSD側でトラフィックを取得していることを確認しました。

$ sudo tshark -n -i igb$n

奇妙なtsharkことに、クライアントが1つだけの場合、スイッチは1ギガビット/秒のストリームを2つのポートに分割し、明らかにそれらの間でピンポンしていることを示しています。（SMCスイッチとHPスイッチの両方がこの動作を示しました。）

クライアントの総帯域幅は1か所（サーバーのラック内のスイッチ）でのみ集まるため、そのスイッチのみがLACP用に構成されます。

どのクライアントを最初に開始するか、またはどの順序で開始するかは関係ありません。

ifconfig lagg0 FreeBSD側で言う：

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
    ether 90:e2:ba:7b:0b:38
    inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::92e2:baff:fe7b:b38%lagg0 prefixlen 64 scopeid 0xa 
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
    media: Ethernet autoselect
    status: active
    laggproto lacp lagghash l2,l3,l4
    laggport: igb3 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
    laggport: igb0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

FreeBSDネットワークチューニングガイドのアドバイスは、状況に応じて適用しています。（最大FDの増加に関するものなど、その多くは無関係です。）

TCPセグメンテーションオフロードをオフにしてみましたが、結果は変わりませんでした。

2番目のテストをセットアップするための2番目の4ポートサーバーNICはありません。4つの個別のインターフェースでのテストが成功したため、ハードウェアはどれも損傷していないと想定しています。^３

私たちはこれらの道のりを前向きに考えていますが、どれも魅力的ではありません。

1. SMCのLACP実装がうまくいかず、新しいスイッチの方が優れていることを期待して、より大きくてより悪いスイッチを購入します。（HP 2530-24Gへのアップグレードは役に立ちませんでした。）

2. FreeBSDのlagg設定をもう少し見つめて、何かを見逃したことを期待します。⁴

3. リンク集約を忘れ、代わりにラウンドロビンDNSを使用して負荷分散を実行します。

4. サーバーのNICを交換して再度切り替えます。今回は、このLACP実験のハードウェアコストの約4倍で、10 GigEのものに交換します。

脚注

1. なぜFreeBSD 10に移行しないのですか？FreeBSD 10.0-RELEASEは引き続きZFSプールバージョン28を使用し、このサーバーはFreeBSD 9.3の新機能であるZFSプール5000にアップグレードされています。10 のxラインは、FreeBSDまで10.1船ことを得ることはありませんので、約一ヶ月を。そして、いいえ、これは本番サーバーであるため、ソースから再構築して10.0-STABLEの最先端に到達することはオプションではありません。

2. 結論にジャンプしないでください。質問の後半のテスト結果から、これがこの質問の複製ではない理由がわかります。

3. iperf3純粋なネットワークテストです。最終的な目標は、ディスクからその4ギガビット/秒の集約パイプを試行して埋めることですが、ディスクサブシステムはまだ関与していません。

4. バギーやデザインの悪さは、多分、工場を去ったときと同じくらい壊れていません。

5. 私はそれをすることからすでに目を見張っています。

システムとスイッチの両方で使用されているロードバランシングアルゴリズムは何ですか。

これに関する私のすべての経験は、FreeBSDとSMCではなく、LinuxとCiscoに関するものですが、同じ理論が依然として適用されます。

LinuxボンディングドライバーのLACPモード、および2950などの古いCiscoスイッチのデフォルトのロードバランシングモードは、MACアドレスのみに基づいてバランシングすることです。

つまり、すべてのトラフィックが1つのシステム（ファイルサーバー）から他の1つのMAC（デフォルトゲートウェイまたはスイッチのスイッチ仮想インターフェイス）に送信される場合、送信元と宛先のMACは同じになるため、スレーブは1つだけになります。利用される。

ダイアグラムからは、デフォルトゲートウェイにトラフィックを送信しているようには見えませんが、テストサーバーが10.0.0.0/24にあるかどうか、またはテストシステムが他のサブネットにあり、経由してルーティングされているかどうかはわかりませんスイッチのレイヤ3インターフェイス。

スイッチでルーティングする場合は、答えがあります。

これに対する解決策は、異なる負荷分散アルゴリズムを使用することです。

繰り返しますが、BSDやSMCの経験はありませんが、LinuxとCiscoは、L3情報（IPアドレス）またはL4情報（ポート番号）に基づいてバランスを取ることができます。

テストシステムごとに異なるIPを使用する必要があるため、L3情報に基づいてバランスを調整してください。それでも機能しない場合は、いくつかのIPを変更して、負荷分散パターンを変更するかどうかを確認します。