Настройка bonding на CentOS 6

Эта статья посвящена вопросу настройки объединения сетевых интерфейсов Link Aggregation (LAG) и использованию протокола LACP (Link Aggregation Control Protocol). Казалось бы все просто – взял сделал бондинг по мануалу и сразу на серваке увеличилась пропускная способность и появилась отказоустойчивость. Отказоустойчивость и правда появится, на тестовое выдергивание одного из сетевых проводов сервер отреагирует вполне лояльно, но менее явная неисправность интерфейса вряд ли будет определена правильно. Пропускная способность объединенного интерфейса очень сильно зависит от того как и в каких направлениях бегает по сети трафик, бывает люди для увеличения скорости между сервером 1с предприятия и терминальным в каждый из них покупают 4-х портовые сетевые карты и настраивают на них 802.3ad, а итоге на тестах получается что скорость между серверами достигает максимум 900Мбит/с.

1. Чуть-чуть теории

Link Aggregation (LAG) – это объединение нескольких физических каналов в один логический с целью объединить пропускную способность и повысить отказоустойчивость.

Объединение пропускной способности происходит при помощи алгоритма балансировки, при этом алгоритм балансировки выбирается на отправляющей стороне. Простой пример – сервер и коммутатор между ними настроен LAG,  все исходящие пакеты сервер сам балансирует и сам распределяет их по интерфейсам, а вот все входящие на сервер пакеты балансируются уже коммутатором. Те алгоритм балансировки должен быть настроен на обоих сторонах, в противном случае трафик будет бежать через одни интерфейс – простая истина, но много граблей на этом сломано.

Большинство алгоритмов балансировки распределяют пакеты по интерфейсам на основе хеш-суммы MAC адресов, IP-адресов, портов назначения и отравителя в TCP/UDP-пакетах, базовые алгоритмы зашитые в большинстве коммутаторов работаю только с MAC или IP+MAC, при этом получается следующая ситуация – все пакеты отправленные с одного сервера на другой могут занять максимум один интерфейс, полную утилизацию 2-х интерфейсов мы сможем получить только если к серверу обратиться два разных клиента с разными MAC адресами и не меньшей скоростью интерфейсов. Исключением является алгоритм balance-rr (round robin) – он умеет разбрасывать трафик между несколькими интерфейсами, но ему нужна поддержка транков или EtherChannel со стороны коммутатора.

Link Aggregation (LAG) может быть статическим или динамическим, главное отличие между ними в том что статика не умеет определять «неявную»  неисправность одного из интерфейсов, поэтому все стремяться сделать динамический LAG. Один из протоколов для динамического объединения каналов  LACP (Link Aggregation Control Protocol) описанный в стандарте IEEE 802.3ad. При использовании LACP обе стороны обмениваются между собой пакетами LACPDU и на основании этих пакетов участники определяют принадлежат ли порты к одному логическому каналу и проверяют состояние физических интерфейсов. При этом стоит заметить что LACP не передает никакой информации об алгоритмах балансировки, они все также выбираются на оборудовании. Как говорят доки, LACP требует минимальной настройки оборудования, вроде как просто указать что он включен, на самом деле на не сильно дорогих железках вроде Cisco SG 200-50, 3com 2924-SPF или HP V1910-48G протокол LACP настраивается для каждой группы портов точно также как и статика.

2. Настройка

Предположим у нас в сервере есть два интерфейса eth0 и eth1, эти интерфейсы мы будем объединять в bond0 и настраивать на них LACP.
Открываем для редактирования /etc/sysconfig/network-scripts/ifcfg-eth0 и приводим его к следующему виду.

DEVICE=eth0
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
HWADDR=00:04:23:D3:EA:F8
ONBOOT=yes

По сути мы добавляем в него MASTER=bond0, SLAVE=yes и удаляем все что связано с настройками IP. Тоже самое проделаем с /etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE="eth1"
BOOTPROTO="none"
MASTER=bond0
SLAVE=yes
HWADDR="00:04:23:D3:EA:F9"
ONBOOT="yes"

Создаем файл с настройками объединенного сетевого интерфейса /etc/sysconfig/network-scripts/ifcfg-bond0.

DEVICE="bond0"
BOOTPROTO="none"
IPADDR=192.168.10.40
NETMASK=255.255.255.0
GATEWAY=192.168.10.1
BONDING_OPTS="mode=802.3ad miimon=100 xmit_hash_policy=layer2+3"
ONBOOT="yes"

Расскажу немножко про BONDING_OPTS, часто и очень часто натыкаюсь на то что люди пытаются прописывать в /etc/modprobe.conf загрузку модуля bonding и кучу параметров к нему, не делайте так – это все пережитки прошлого. Было когда-то время и это был единственный способ подцепить бондинг, но в CentOS 5 и 6 директива BONDING_OPTS работает без как часы, при этом менять параметры бондинга можно просто перезапуском сервиса network.
Основной параметр BINDING_OPTS это параметр mode – он определяет в каком режиме будет работать объединенный интерфейс, в нашем случает это 802.3ad – используем LACP протокол. Дальше параметр miimon – отвечает за хардварный мониторинг линка на случай скажем выдергивания сетевого провода, устанавливает в миллисекундах частоту проверки, а по-умолчанию отключен. Говорят что параметр miimon работает не на всех сетевых карточках, проверить его можно через ethtool.

[root@bksrv ~]# ethtool eth0 | grep "Link detected:"
        Link detected: yes

Параметр xmit_hash_policy определят алгоритм по которому Linux будет распределять трафик по сетевым интерфейсам, бывает три варианта: layer2 – по MAC, layer2+3 – по MAC и IP; layer3+4 – по IP и порту. Алгоритм layer2+3 полезен для случая когда между сервером и клиентами установлен роутер, если роутера нет, то вполне можно использовать layer2.
Готово, перезапускаем сервис network.

[root@bksrv ~]# service network restart

3. Проверяем

Посмотреть состояние объединенного интерфейса можно в /proc/net/bonding

[root@bksrv ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
 
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
 
802.3ad info
LACP rate: slow
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
        Aggregator ID: 4
        Number of ports: 2
        Actor Key: 17
        Partner Key: 1001
        Partner Mac Address: f4:ea:67:7d:c7:dc
 
Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: a0:b3:cc:e7:d9:90
Aggregator ID: 4
Slave queue ID: 0
 
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: a0:b3:cc:e7:d9:91
Aggregator ID: 4
Slave queue ID: 0

В результате мы видим те параметры которые забили в BINDING_OPTS, потом 802.3ad info и состояние двух интерфейсов. Важно обратить внимание на 802.3ad info если “Partner Mac Address” равен 00:00:00:00:00:00 – это значит что обмен пакетами LACPDU не произошел и на коммутаторе скорее всего не настроен или не поддерживается LACP.

802.3ad info
LACP rate: slow
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
        Aggregator ID: 4
        Number of ports: 1
        Actor Key: 17
        Partner Key: 1
        Partner Mac Address: 00:00:00:00:00:00

4. Тестируем скорость

Завершающим аккордом думаю стоит протестировать получилось ли у нас объединение по скорости двух интерфейсов, ибо случаи бывают разные, бывает коммутатор трафик только на один интерфейс гонит, а бывает и мы в настройках чего-нибудь не докрутили. Для тестирования нам понадобится непосредственно наш сервер bksrv (IP: 192.168.10.40) и любые два компьютера-сервера подключенные к тому-же коммутатору, для примера назовем их node1 (IP: 192.168.10.51) и node2 (IP: 192.168.10.52).
Ставим на всех участниках (bksrv, node1 и node2) две утилиты iperf для тестирования скорости и ifstat для отображения загруженности по интерфейсам.
Начнем с входящей скорости, запускаем на проверяемом сервере bksrv утилиту iperf, а затем с другой консоли ifstat

[root@bksrv ~]# iperf -s
[root@bksrv ~]# ifstat -S
       eth0                eth1               bond0
 KB/s in  KB/s out   KB/s in  KB/s out   KB/s in  KB/s out
    0.09      0.00      0.19      0.22      0.28      0.22

Теперь запускаем iperf с двух клиентов node1 и node2:

[root@node1 ~]#  iperf -c 192.168.10.40 -t 600 -i 2

[root@node2 ~]#  iperf -c 192.168.10.40 -t 600 -i 2

Смотрим на ifstat и если скорость на обоих интерфейсах равна приближенно 100MB/s – значит все ок, иначе начинаем разбираться по какому алгоритму коммутатор раскидывает трафик и вообще делает ли он это. Для большей правдоподобности иногда стоит подключится большим количеством клиентов, к примеру вместо двух клиентов node1 и node2, запустить iperf сразу с штук пяти.

[root@bksrv ~]# ifstat -S
       eth0                eth1               bond0
 KB/s in  KB/s out   KB/s in  KB/s out   KB/s in  KB/s out
117739.3    471.22  119662.3    489.40  237401.7    960.43

Теперь тестируем исходящую скорость, технология та же самая, на клиентах node1 и node2 запускаем iperf в режиме сервера.

[root@node1 ~]# iperf -s

[root@node2 ~]# iperf -s

И с разных консолей сервера bksrv запускаем iperf в режиме клиента.

[root@bksrv ~]# iperf -c 192.168.10.51 -t 600 -i 2

[root@bksrv ~]# iperf -c 192.168.10.52 -t 600 -i 2

Смотрим через iperf исходящую скорость на обоих интерфейсах, и если что не так крутим драйвера интерфейсов и настройки алгоритма балансировки на сервере.

[root@bksrv ~]# ifstat -S
       eth0                eth1               bond0
 KB/s in  KB/s out   KB/s in  KB/s out   KB/s in  KB/s out
 2300.05  104330.2   2619.03  120508.5   4919.08  224838.7

5. Заключение

Вроде бы простую настройку, которую многие проделывают не задумываясь на каждом новом сервере, удалось таки растянуть в достаточно длинную статью. Надеюсь что эта статья была для вас полезной и вы подчеркнули из нее что-то интересное и нужное. Если хочется лучше разобраться в настройке бондинга, то очень неплохое описание есть в доках к ядру.

[root@bksrv ~]# yum install kernel-doc.noarch
[root@bksrv ~]# less /usr/share/doc/kernel-doc-2.6.32/Documentation/networking/bonding.txt

Желаю успехов. Есть дополнения – пишите.