web-dev-qa-db-ja.com

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

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

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

_iperf3_テストの設定では、4つのテストクライアントすべてからのトラフィックが異なるポートの中央スイッチに入るように注意を払っています。

LACP test setup

各テストマシンにラックスイッチへの独立したパスがあり、ファイルサーバー、そのNIC、およびスイッチにはすべて、_lagg0_グループを分割して割り当て、このIntelネットワークカードの4つのインターフェイスのそれぞれに個別のIPアドレス。その構成では、最大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用に構成されます。

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

FreeBSD側の_ifconfig lagg0_はこう言っています：

_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番目の4ポートサーバーはありませんNIC。4つの個別のインターフェイスでのテストが成功したため、ハードウェアはどれも破損しています。３

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

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

  2. FreeBSD lagg構成をもう少し見つめ、何かを見落としていたことを期待します。4

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

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

脚注

  1. なぜFreeBSD 10に移行しないのですか？ FreeBSD 10.0-RELEASEは引き続きZFSプールバージョン28を使用し、このサーバーはFreeBSD 9.3の新機能であるZFSプール5000にアップグレードされています。 10。バツ FreeBSD 10.1が出荷されるまで、行はそれを取得しません それから約1か月 。そして、いいえ、これは本番サーバーであるため、ソースから再構築して10.0-STABLEブリーディングエッジに移行することはオプションではありません。

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

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

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

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

freebsdbandwidthbondinglacp
10
Warren Young

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

これに関する私のすべての経験は、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を変更して、負荷分散パターンを変更するかどうかを確認します。

2
suprjami