LINUX.ORG.RU
решено ФорумAdmin

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

 , ,


1

1

Приветствую! Есть ceph-кластер из трёх нод. Они подключены к коммутатору (Eltex MES5324) 10Gb SFP+. Только что подключил ещё по одному 10Gb шлангу к каждой ноде, настроил на коммутаторе группы агрегации портов, добавил туда попарно нужные порты. Группы выглядят примерно так:

Po3 is up (connected)
  Interface index is 1002
  Hardware is aggregated ethernet interface(s), MAC address is xx:xx:xx:xx:xx:xx
  Interface MTU is 9000
  Link is up for 0 days, 0 hours, 36 minutes and 4 seconds
    Link aggregation type is static LAG
    No. of members in this port-channel: 2 (active 2)
      tengigabitethernet1/0/3, full-duplex, 10000Mbps (active)
      tengigabitethernet1/0/15, full-duplex, 10000Mbps (active)
    Active bandwidth is 20000Mbps

На нодах настроил бондинг вот таким макаром:

auto bond0
allow-hotplug bond0
iface bond0 inet static
address x.x.x.0/24
gateway x.x.x.y
dns-nameservers x.x.x.z
up /sbin/ifenslave bond0 eno7
up /sbin/ifenslave bond0 eno8
postup ifconfig eno7 mtu 9000 && ifconfig eno8 mtu 9000 && ifconfig bond0 mtu 9000

Так работает, но iperf показывает скорость передачи данных между нодами 9.86 Gbits/sec - столько и было до включения бондинга. Что я делаю не так, товарищи?

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

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

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

roman77 ★★★★★ ()
Последнее исправление: roman77 (всего исправлений: 3)
Ответ на: комментарий от dpronyaev

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

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

CaveRat ★★ ()
Ответ на: комментарий от roman77

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

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
dpronyaev ()
Ответ на: комментарий от CaveRat

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

dpronyaev ()

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

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

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

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

ZANSWER ()
Ответ на: комментарий от CaveRat

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

dpronyaev ()

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

Таблица 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

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

ZANSWER ()
Ответ на: комментарий от ZANSWER

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

dpronyaev ()
Ответ на: комментарий от targitaj

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

ZANSWER ()
Ответ на: комментарий от ZANSWER

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

При запуске 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», не больше.

dpronyaev ()
Ответ на: комментарий от dpronyaev

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

ZANSWER ()
Ответ на: комментарий от dpronyaev

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

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

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

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

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

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

ZANSWER ()

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.