bonding: нет прироста скорости

Один коннект использует 1 интерфейс.

2 и более коннекта используют 2 интерейса.

Проще говоря: так и должно быть. Распаралелить одно соединение на 2 интерфейса так низя. Прогони 2 iperf параллельно с bonding и без, все увидишь.

А какой у тебя bonding mode?

И как ты на коммутаторе настройку делал? В каком режиме?

В режиме статической агрегации, без LACP.

bonding mode=0 miimon=100

mode 0 - это LB Round Robin. AFAIK, оно работает так, как уже сказали выше.

PS А зачем тебе там агрегация? Я просто не особо копенгаген, как работает Ceph. Если просто для того, чтобы быстрее отдавать данные по iscsi - то iscsi умеет multipathIO, который по тестам быстрее, чем бондинг.

Попробовал одновременно с двух хостов

iperf -c UP -t 30

- вот что получилось:

# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local x.x.x.x port 5001 connected with x.x.x.y port 60946
[  5] local x.x.x.x port 5001 connected with x.x.x.z port 54260
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.0 sec  17.5 GBytes  5.00 Gbits/sec
[  5]  0.0-30.0 sec  17.5 GBytes  5.00 Gbits/sec

Совсем разные уровни абстракции. Толстый канал нужен не для быстрой передачи данных кластер <-> клиент, а для взаимодействия между нодами.

А что они там между собой гоняют и как? Синхронизируют данные?

Ваш клиент передаёт кадры поочерёдно, через каждый из интерфейсов группы, что даёт вам ваши 20 Gbit/s, до коммутатора.

Коммутатор получив ваши кадры выполняет их коммутацию между интерфейсами, тем или иным способом, а вот их отправку через свои интерфейсы входящие в группу, он выполняет согласно определённому алгоритму.

Полученные кадры анализируются, далее хеш функции передаётся в качестве входных данных, к примеру SRC MAC и DST MAC, на основе этих данных создаётся хеш, который идентифицирует данный поток. Затем данный поток передаётся через один из интерфейсов группы, всегда один и тот же, это позволяет избежать получения кадров вне очереди.

Если коммутатор является достаточно продвинутым, то он может использовать в качестве входных параметров так же SRC/DST IP или SRC/DST PORT, это позволяет добиться большего распределения кадров между интерфейсами группы.

Да, в основном синхронизация. Ведь все данные должны размазываться по всем нодам. А самое интересно когда одна из нод некоторое время была оффлайн, например, для замены HDD - тогда нужно как можно скорее залить\распределить данные при её возвращении в кластер.

А вот, что написано в документации к вашему коммутатору:

Таблица 5.52 – Команды режима глобального конфигурирования

Команда
port-channel load-balance {src-dst-mac-ip | src-dst-mac |src-dst-ip | src-dst-mac-ip-port | dst-mac | dst-ip | src-mac | src-ip}

Значение/Значение по умолчанию
-/src-dst-mac
Задает механизм балансировки нагрузки для группы агрегированных портов.

Действие
- src-dst-mac-ip – механизм балансировки основывается на MAC-адресе и IP-адресе;
- src-dst-mac – механизм балансировки основывается на MAC-адресе;
- src-dst-ip – механизм балансировки основывается на IP-адресе;
- src-dst-mac-ip-port – механизм балансировки основывается на MAC-адресе, IP-адресе и TCP-порте назначения;
- dst-mac – механизм балансировки основывается на MAC-адресе получателя;
- dst-ip – механизм балансировки основывается на IP-адресе получателя;
- src-mac – механизм балансировки основывается на MAC-адресе отправителя;
- src-ip – механизм балансировки основывается на IP-адресе отправителя

Попробуйте ввести данную команду: port-channel load-balance src-dst-mac-ip-port

Это позволит вашему коммутатору гораздо более точно разделять кадры полученные от одного и того же клиента, на разные потоки, а значит и передавать через разные порты группы.

Всё так, это нормально. Запускай второй iperf параллельно.

Спасибо, попробую. Я как раз допетрил перевести порты из статического режима агрегации в режим LACP - в нем и действуют приведенные вами команды.

У него по умолчанию балансировка по SRC/DST MAC, можно запустить хоть четыре iperf, это не поможет.

Привело к интересному результату:

При запуске iperf одновременно с двух хостов было:

[  4]  0.0-30.0 sec  17.5 GBytes  5.00 Gbits/sec
[  5]  0.0-30.0 sec  17.5 GBytes  5.00 Gbits/sec

стало:

[  4]  0.0-30.0 sec  34.6 GBytes  9.89 Gbits/sec
[  5]  0.0-30.0 sec  34.6 GBytes  9.89 Gbits/sec

Но при запуске теста с ОДНОГО хоста показывает всё те же «почти 10 Gbits», не больше.

Это всегда хорошая идея воспользоваться услугами Link Aggregation Control Protocol или Port Aggregation Protocol, поскольку они позволяют избежать проблем не согласованного состояния портов на разных сторонах, автоматически могут заблокировать порт у которого нарушена работа, к примеру возникла ситуация с односторонней передачей, когда отсутствует RX, но TX всё ещё в рабочем состоянии и тд.

В случае, когда вы запускаете тестирование с одного узла, они отправляют данные на один и тот же TCP порт или разные?

Важно иметь ввиду, что балансировка в данном случае опирается на следующие параметры:

- src-dst-mac-ip-port – механизм балансировки основывается на MAC-адресе, IP-адресе и TCP-порте назначения;

Я не люблю русскоязычную документацию, за возможные ошибки перевода, но найти англоязычную мне пока не удалось.

И хотя из названия данного режима можно сделать вывод, что в качестве входных параметров хеш функция принимает SRC/DST MAC и SRC/DST IP, а так же SRC/DST PORT, тем не менее, документация утверждает, то берёт только TCP порт и только DST.

Это значит, что если на стороне принимающего узла, у вас запущен только один экземпляр iperf то балансировка осуществляться между портами группы не будет. Если это возможно то, принимающий узел должен слушать два разные TCP порта, в таком случае, будет достигнута балансировка.

Короч. На сервере бонд режим lacp. Xmit hash policy = layer3+4.

На свитче - lacp. Хеш полиси на максимум что позволяет. Лучше layer 4. Проверить загрузку цпу потом, мало ли что.

Понял, спасибо за помощь!