それぞれ最大500mbpsに制限されたボンディングギガビットインターフェイス
この問題は、私を何日も悩ませてきました！私は最近、いくつかのLinuxサーバー上のeth0/eth1インターフェースを次の構成でbond1に結合しました（すべてのシステムで同じ）：
DEVICE=bond0
ONBOOT=yes
BONDING_OPTS="miimon=100 mode=4 xmit_hash_policy=layer3+4
lacp_rate=1"
TYPE=Bond0
BOOTPROTO=none
DEVICE=eth0
ONBOOT=yes
SLAVE=yes
MASTER=bond0
HOTPLUG=no
TYPE=Ethernet
BOOTPROTO=none
DEVICE=eth1
ONBOOT=yes
SLAVE=yes
MASTER=bond0
HOTPLUG=no
TYPE=Ethernet
BOOTPROTO=none
ここで、ボンディングステータスを確認できます。イーサネットチャネルボンディングドライバー：v3.6.0（2009年9月26日）
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: fast
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 3
Number of ports: 2
Actor Key: 17
Partner Key: 686
Partner Mac Address: d0:67:e5:df:9c:dc
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:25:90:c9:95:74
Aggregator ID: 3
Slave queue ID: 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:25:90:c9:95:75
Aggregator ID: 3
Slave queue ID: 0
そしてEthtoolの出力：
Settings for bond0:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: 2000Mb/s
Duplex: Full
Port: Other
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Link detected: yes
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
サーバーは両方とも同じDellPCT 7048スイッチに接続されており、各サーバーの両方のポートが独自の動的LAGに追加され、アクセスモードに設定されています。すべて大丈夫ですよね？それでも、2つのスレッドを使用して1つのサーバーから別のサーバーにiperfテストを試行した結果は次のとおりです。
------------------------------------------------------------
Client connecting to 172.16.8.183, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 172.16.8.180 port 14773 connected with 172.16.8.183 port 5001
[ 3] local 172.16.8.180 port 14772 connected with 172.16.8.183 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 561 MBytes 471 Mbits/sec
[ 3] 0.0-10.0 sec 519 MBytes 434 Mbits/sec
[SUM] 0.0-10.0 sec 1.05 GBytes 904 Mbits/sec
明らかに両方のポートが使用されていますが、1Gbpsに近い場所では使用されていません。これは、結合する前に個別に作業したものです。さまざまなボンディングモード、xmitハッシュタイプ、mtuサイズなどを試しましたが、個々のポートが500メガビット/秒を超えることはできません.....ボンド自体が制限されているようです。どこかで1Gに！誰かアイデアはありますか？
追加1/19：コメントと質問をありがとう、私はこれらのサーバーのパフォーマンスを最大化することにまだ非常に興味があるので、ここでそれらに答えようとします。まず、Dellスイッチのインターフェイスカウンターをクリアしてから、本番トラフィックを少しの間処理させました。送信サーバーの結合を構成する2つのインターフェースのカウンターは次のとおりです。
Port InTotalPkts InUcastPkts InMcastPkts
InBcastPkts
--------- ---------------- ---------------- ---------------- --------
--------
Gi1/0/9 63113512 63113440 72
0
Port OutTotalPkts OutUcastPkts OutMcastPkts
OutBcastPkts
--------- ---------------- ---------------- ---------------- --------
--------
Gi1/0/9 55453195 55437966 6075
9154
Port InTotalPkts InUcastPkts InMcastPkts
InBcastPkts
--------- ---------------- ---------------- ---------------- --------
--------
Gi1/0/44 61904622 61904552 48
22
Port OutTotalPkts OutUcastPkts OutMcastPkts
OutBcastPkts
--------- ---------------- ---------------- ---------------- --------
--------
Gi1/0/44 53780693 53747972 48
32673
トラフィックは完全に負荷分散されているようですが、rxとtxを組み合わせると、帯域幅のグラフはインターフェイスごとにほぼ正確に500mbpsを示します。
また、本番トラフィックを処理しているときは、常により多くの帯域幅を要求し、同時に複数の他のサーバーと通信していることも確かです。
編集＃2 1/19：Zordache、おそらくIperfテストは1つのポートと1つのインターフェイスのみを使用する受信側によって制限されていると思われたので、server1の2つのインスタンスを同時に実行して「iperf-s」を実行しましたserver2とserver3で。次に、サーバー1からサーバー2および3に同時にIperfテストを実行しました。
iperf -c 172.16.8.182 -P 2
------------------------------------------------------------
Client connecting to 172.16.8.182, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 172.16.8.225 port 2239 connected with 172.16.8.182 port
5001
[ 3] local 172.16.8.225 port 2238 connected with 172.16.8.182 port
5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 234 MBytes 196 Mbits/sec
[ 3] 0.0-10.0 sec 232 MBytes 195 Mbits/sec
[SUM] 0.0-10.0 sec 466 MBytes 391 Mbits/sec
iperf -c 172.16.8.183 -P 2
------------------------------------------------------------
Client connecting to 172.16.8.183, TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.8.225 port 5565 connected with 172.16.8.183 port
5001
[ 4] local 172.16.8.225 port 5566 connected with 172.16.8.183 port
5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 287 MBytes 241 Mbits/sec
[ 4] 0.0-10.0 sec 292 MBytes 244 Mbits/sec
[SUM] 0.0-10.0 sec 579 MBytes 484 Mbits/sec
追加された両方のSUMはまだ1Gbpsを超えません！他の質問については、私のポートチャネルは次の2行で設定されています。
hashing-mode 7
switchport access vlan 60
ハッシュモード7は、デルの「拡張ハッシュ」です。それが何をするのか具体的には述べていませんが、私は他の6つのモードのさまざまな組み合わせを試しました。
Hash Algorithm Type
1 - Source MAC, VLAN, EtherType, source module and port Id
2 - Destination MAC, VLAN, EtherType, source module and port Id
3 - Source IP and source TCP/UDP port
4 - Destination IP and destination TCP/UDP port
5 - Source/Destination MAC, VLAN, EtherType, source MODID/port
6 - Source/Destination IP and source/destination TCP/UDP port
7 - Enhanced hashing mode
何か提案があれば、他のモードをもう一度試すか、ポートチャネルの構成を変更してください。
コンピューターでは、ボンドはハッシュポリシーを使用していますTransmit Hash Policy: layer3+4、基本的には、特定の接続に使用されるインターフェースがIP /ポートに基づいていることを意味します。
Iperfテストは2つのシステム間で行われ、iperfは単一のポートを使用します。したがって、すべてのiperfトラフィックは、ボンディングされたインターフェイスの単一のメンバーに制限される可能性があります。
両方のインターフェースが使用されている、またはその半分が各インターフェースによって処理されていると思わせるものが表示されているかどうかはわかりません。 Iperfは、threadごとに結果を報告しているだけです。インターフェイスごとではありません。スイッチのインターフェイスカウンターを確認する方が興味深いでしょう。
さまざまなハッシュモードで遊んでいるとおっしゃいました。スイッチに接続しているので、スイッチのハッシュモードも変更する必要があります。コンピューターの構成は、送信されたパケットにのみ適用されます。また、スイッチでハッシュモードを構成する必要があります（ハードウェアのオプションである場合でも）。
ボンディングは、2つのシステム間で使用する場合はそれほど有用ではありません。ボンディングでは、両方のインターフェイスの全帯域幅が得られるわけではありません。一方のインターフェイスを使用する接続と、もう一方のインターフェイスを使用する接続を使用できるようにするだけです。 2つのシステム間で少し役立つモードがいくつかありますが、せいぜい25〜50％の改善です。両方のインターフェースの全容量を取得することはほとんどありません。
単一のTCP接続のスループットを向上させることができる唯一のボンディングモードはbalance-rr（またはモード0）です。このボンディングモードは、実際には2つ（またはそれ以上）の使用可能なインターフェイスで発信パケットを「ストライプ」します。ただし、独自の落とし穴があります。
- 正しいパケットの順序は保証されません。
- 送信パケットにのみ影響します。
- スイッチで常に安全に動作するとは限りません（MACポイズニング/フラッピングの形式として検出できます）。
- 標準のLACPモードではありません。
から Linuxカーネルのドキュメント ：
balance-rr：このモードは、単一のTCP/IP接続が複数のインターフェイス間でトラフィックをストライプ化できるようにする唯一のモードです。したがって、これは、単一のTCP/IPストリームが複数のインターフェイスに相当するスループットを利用できるようにする唯一のモードです。ただし、これにはコストがかかります。ストライピングにより、通常、ピアシステムがパケットを順不同で受信し、TCP/IPの輻輳制御システムが起動します。多くの場合セグメントを再送信します。
Balance-rrの使用方法の実際の例については、 ここ をお読みください。
セットアップに戻ります。802.3ad/モード4（LACP）を使用しているため、システムは単一の接続に複数のインターフェースを使用できません。単一のTCPまたはUDPストリームを開くことにより、iperfはLACPの恩恵をまったく受けません。一方、マルチセッション対応プロトコル（例：SMB 3.0+）は、追加のインターフェイスを完全に使用できます。