Связанные гигабитные интерфейсы ограничены скоростью ~ 500 Мбит / с каждый
Эта проблема уже несколько дней сводит меня с ума! Недавно я связал интерфейсы eth0 / eth1 на нескольких серверах Linux в 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
Здесь вы можете увидеть статус связывания: Драйвер связывания каналов Ethernet: v3.6.0 (26 сентября 2009 г.)
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
Оба сервера подключены к одному и тому же коммутатору Dell PCT 7048, причем оба порта для каждого сервера добавлены к его собственной динамической LAG и установите режим доступа. Все в порядке, правда? И все же, вот результаты попытки тестирования iperf с одного сервера на другой с 2 потоками:
------------------------------------------------------------
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
Очевидно, что используются оба порта, но не на скорости, близкой к 1 Гбит / с - над чем они работали индивидуально, прежде чем связывать их. Я пробовал всевозможные различные режимы связывания, типы хэшей xmit, размеры MTU и т. Д. И т. Д. И т. Д., Но просто не могу заставить отдельные порты превышать 500 Мбит / с ..... это почти как если бы сам Bond был ограничен до 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
Кажется, что трафик идеально сбалансирован по нагрузке, но графики пропускной способности по-прежнему показывают почти точно 500 Мбит / с на интерфейс, когда rx и tx объединены:
Я также могу с уверенностью сказать, что когда он обслуживает производственный трафик, он постоянно требует большей пропускной способности и одновременно обменивается данными с несколькими другими серверами.
Редактировать № 2 1/19: Zordache, вы заставили меня подумать, что, возможно, тесты Iperf были ограничены принимающей стороной только с использованием 1 порта и только 1 интерфейса, поэтому я запустил 2 экземпляра server1 одновременно и запустил "iperf -s" на server2 и server3. Затем я запустил тесты Iperf с сервера 1 на серверы 2 и 3 одновременно:
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 все равно не превысят 1 Гбит / с! Что касается вашего другого вопроса, мои каналы портов настроены только с помощью следующих двух строк:
hashing-mode 7
switchport access vlan 60
Hashing-mode 7 - это «Расширенное хеширование» Dell. Он не говорит конкретно, что он делает, но я пробовал различные комбинации из других 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 находится между двумя системами, а iperf использует один порт. Таким образом, весь трафик iperf, скорее всего, будет ограничен одним элементом связанного интерфейса.
Я не уверен, что вы видите, что заставляет вас думать, что используются оба интерфейса или что половина его обрабатывается каждым интерфейс. Iperf просто сообщает результаты в ветке . Не на интерфейс. Было бы интереснее взглянуть на счетчики интерфейса на коммутаторе.
Вы упомянули, что игрались с различными режимами хеширования. Поскольку вы подключаетесь к коммутатору, вам также необходимо убедиться, что вы изменили режимы хеширования на коммутаторе. Конфигурация на вашем компьютере применяется только к передаваемым пакетам. Вам также необходимо настроить режим хеширования на коммутаторе (если это даже вариант с вашим оборудованием).
Связывание просто не так полезно при использовании между двумя системами. Связывание не дает вам полной пропускной способности обоих интерфейсов, оно просто позволяет некоторым соединениям использовать один интерфейс, а другим - другой. Есть несколько режимов, которые могут немного помочь между двумя системами, но это улучшение в лучшем случае на 25-50%. Вы почти никогда не сможете использовать оба интерфейса на полную мощность.
Единственным режимом связывания, который может увеличить пропускную способность одного TCP-соединения, является balance-rr (или режим 0). Этот режим связывания фактически "зачищает" исходящие пакеты на 2 (или более) доступных интерфейсах. Однако у него есть свои "подводные камни":
- правильный порядок следования пакетов не гарантируется;
- он влияет только на исходящие пакеты;
- он не всегда безопасно работает с коммутаторами (которые могут обнаружить его как форму отравления/повторения MAC);
- он не является стандартным LACP режимом.
Из документации по ядру Linux:
balance-rr: Этот режим - единственный режим, который разрешает одиночный TCP/IP-соединение с полосовым трафиком через несколько интерфейсов. поэтому единственный режим, который позволит одному TCP/IP потоку использовать более одного интерфейса. Это достигается за счет Однако, стоимость: чередование, как правило, приводит к однородным системам. получение пакетов, выходящих из строя, что приводит к контролю перегрузок TCP/IP Для фактического примера использования balance-rr прочтите здесь
Назад к настройке: поскольку вы используете 802.3ad/mode 4 (LACP), ваша система не может использовать несколько интерфейсов для одного соединения. При открытии одного TCP или UDP потока
.iperfвообще не использует LACP. С другой стороны, многосессионный протокол (например, SMB 3.0+) может полностью использовать Ваши дополнительные интерфейсы.