Связанные гигабитные интерфейсы с ограничением скорости ~ 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 с одного сервера на другой с двумя потоками:
------------------------------------------------------------
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 объединены:
Я также могу с уверенностью сказать, что, обслуживая производственный трафик, он постоянно требует большей пропускной способности и одновременно обменивается данными с несколькими другими серверами.
Edit # 2 1/19: Zordache, вы заставили меня подумать, что, возможно, тесты Iperf были ограничены принимающей стороной только с использованием 1 порта и только 1 интерфейса, поэтому я запускал 2 экземпляра server1 одновременно и запускал "iperf -s" на server2 и server3. Затем я запустил тесты Iperf с server1 на серверы 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
Режим хеширования 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 / port.
Ваш тест iperf находится между двумя системами, а iperf использует один порт. Таким образом, весь трафик iperf, вероятно, будет ограничен одним членом связанного интерфейса.
Я не уверен, что вы видите, что заставляет вас думать, что используются оба интерфейса или что половина из них обрабатывается каждым интерфейсом. Iperf просто сообщает результаты по нить. Не на интерфейс. Интереснее было бы посмотреть счетчики интерфейсов на коммутаторе.
Вы упомянули, что играете с разными режимами хеширования. Поскольку вы подключаетесь к коммутатору, вам также необходимо убедиться, что вы изменили режимы хеширования на коммутаторе. Конфигурация на вашем компьютере применяется только к передаваемым пакетам. Вам также необходимо настроить режим хеширования на коммутаторе (если это даже вариант с вашим оборудованием).
Соединение просто не так полезно при использовании между двумя системами. Связывание не дает вам полной пропускной способности обоих интерфейсов, оно просто позволяет некоторым соединениям использовать один интерфейс, а другим - другой. Есть несколько режимов, которые могут немного помочь между двумя системами, но в лучшем случае это улучшение на 25-50%. Вы почти никогда не сможете использовать оба интерфейса на полную мощность.
Единственный режим связывания, который может увеличить пропускную способность одного TCP-соединения, - это balance-rr (или режим 0). Этот режим связывания фактически "разделяет" ваши исходящие пакеты на 2 (или более) доступных интерфейса. Однако здесь есть свои подводные камни:
- правильный порядок пакетов не гарантируется;
- это только влияет исходящий пакеты;
- он не всегда перестраховывается с переключателями (которые могут обнаружить это как форму отравления / переключения MAC);
- это не стандартный режим LACP.
баланс-rr: Этот режим является единственным режимом, который позволяет одному TCP / IP-соединению распределять трафик по нескольким интерфейсам. Следовательно, это единственный режим, который позволяет одному потоку TCP / IP использовать пропускную способность более чем одного интерфейса. Однако за это приходится платить: чередование обычно приводит к тому, что одноранговые системы получают пакеты не по порядку, вызывая срабатывание системы контроля перегрузки TCP / IP, часто путем повторной передачи сегментов.
Фактический пример использования balance-rr см. В Вот
Вернемся к вашей настройке: поскольку вы используете 802.3ad / режим 4 (LACP), ваша система не может использовать несколько интерфейсов для одного подключения. Открыв один поток TCP или UDP,iperf LACP не дает никакой пользы. С другой стороны, протокол с поддержкой нескольких сеансов (например, SMB 3.0+) может полностью использовать ваши дополнительные интерфейсы.