https://blog.it-kb.ru/2016/06/20/network-bonding-with-vlan-and-802-3ad-lacp-on-centos-linux-7-2-and-lag-channel-group-on-switch-cisco-catalyst-ws-c3560g-with-testing-load-balancing-and-high-availability/ Настройка Network Bonding c LACP в CentOS Linux 7.2
Проверим наличие модуля поддержки bonding (команда должна отработать без ошибок):
# modinfo bonding
В ниже представленном примере мы рассмотрим сценарий настройки логического bond-интерфейса bond0 (master-интерфейс), членами которого будут два имеющихся в сервере физических интерфейса enp3s0 и enps5s0 (slave-интерфейсы). А затем на созданном bond-интерфейсе мы создадим дочерний VLAN-интерфейс, имеющий доступ к изолированной тегированной сети с определённым номером VLAN. Всю настройку мы будем выполнять путём прямой правки файлов интерфейсов.
Создадим файл с конфигурацией нового агрегирующего интерфейса bond0:
# nano /etc/sysconfig/network-scripts/ifcfg-bond0
Наполним файл параметрами бонда bond0:
DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_MASTER=yes
IPV6INIT=no
MTU=9000
ONBOOT=yes
USERCTL=no
NM_CONTROLLED=no
BOOTPROTO=none
BONDING_OPTS="mode=802.3ad xmit_hash_policy=layer2+3 lacp_rate=1 miimon=100"
Опции BONDING_OPTS можно передавать и через файл /etc/modprobe.d/bonding.conf, но вместо этого лучше использовать файлы ifcfg-bond*. Исключением здесь является лишь глобальный параметр max_bonds. Это замечание описано в документе
Create a Channel Bonding Interface.
Получить информацию о всех возможных опциях BONDING_OPTS и вариантах их значений можно в документе
Using Channel Bonding.
В нашем примере используется несколько опций:
- mode=802.3ad, который определяет режим работы bond-а (bonding policy). В нашем случае выбран режим с использованием протокола LACP. Этот режим для корректной работы должен поддерживаться и коммутатором, к которому подключаются сетевые интерфейсы bond-а.
- lacp_rate=fast, который заставляет bonding-интерфейс отсылать пакеты LACPDU ежесекундно, в то время как значение по умолчанию slow, которое определяет 30-секундный интервал.
- xmit_hash_policy=layer2+3, который определяет режим вычисления хешей при организации балансировки нагрузки между интерфейсами бонда. Эта опция используется только для режимов работы бонда (ранее описанный mode) поддерживающих балансировку нагрузки, таких как balance-xor и 802.3ad. Значение layer2+3 говорит о том, что для вычисления хешей будут использоваться как MAC адреса получателей/отправителей пакета, так и их IP адреса, если это возможно. Значение по умолчанию для этой опции - layer2, что определяет вычисление хеша только по MAC-адресам.
- miimon=100, который определяет количество миллисекунд для мониторинга состояния линка с помощью механизмов MII, который, к слову говоря, должен поддерживаться физическим сетевым контроллером. Значение опции miimon по умолчанию - 0, что значит, что данный функционал не используется.
Чтобы проверить то, может ли наш сетевой контроллер работать с MII, можно выполнить:
# ethtool enp3s0 | grep "Link detected:"
Link detected: yes
Значение yes в данном случае говорит о поддержке MII.
Если вы используете режим active-backup bonding, то есть
рекомендация настраивать дополнительную опцию bond-интерфейса: fail_over_mac=1. Как я понял, это нужно для того, чтобы использовать для bond в качестве основного MAC-адреса, MAC-адрес backup-интерфейса, что позволит сократить время потери соединений в процессе fail-over.
Создадим файл с конфигурацией slave-интерфейсов, то есть физических Ethernet-портов, которые будут участниками bond0 (файл скорее всего уже существует, так что просто отредактируем его под свою задачу):
# nano /etc/sysconfig/network-scripts/ifcfg-enp3s0
Содержимое файла
DEVICE=enp3s0
NAME=bond0-slave0
TYPE=Ethernet
MTU=9000
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
NM_CONTROLLED=no
Второй slave-интерфейс настраиваем по аналогии:
# nano /etc/sysconfig/network-scripts/ifcfg-enp5s0
Параметры файла аналогичные за исключением параметров DEVICE и NAME
DEVICE=enp5s0
NAME=bond0-slave1
TYPE=Ethernet
MTU=9000
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no
NM_CONTROLLED=no
Если используется служба NetworkManager, то перезагрузим её конфигурацию с учётном созданных/изменённых файлов ifcfg-*:
# nmcli con reload
Перезапускаем slave-интерфейсы:
# ifdown enp3s0 && ifup enp3s0
# ifdown enp5s0 && ifup enp5s0
Если отдельное отключение/включение интерфейсов приводит к ошибкам (это возможно в случае если ранее подключения контролировались службой NetworkManager), то перезапускаем сеть полностью:
# service network restart
Убедимся в том, что созданные интерфейсы успешно запущены со статусом UP и заданными нами настройками, например обратим внимание на размер MTU.
# ip link show
...
2: enp3s0:
mtu 9000 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
link/ether 00:1f:28:0a:f7:f4 brd ff:ff:ff:ff:ff:ff
3: enp5s0:
mtu 9000 qdisc mq master bond0 state UP mode DEFAULT qlen 1000
link/ether 00:1f:28:0a:f7:f4 brd ff:ff:ff:ff:ff:ff
4: bond0:
mtu 9000 qdisc noqueue state UP mode DEFAULT
link/ether 00:1f:28:0a:f7:f4 brd ff:ff:ff:ff:ff:ff