Настройка lacp centos 7

Обновлено: 02.07.2024

Собрал bond на CentOS 7. С одной стороны супермикра с 10G-адаптером Intel X520, с другой стороны -- 2 коммутатора Nexus 5672UP с VPC. Настроен LACP, поверх которого VLAN trunk. После ребута сервера связь до него отсутствует, т. к. несмотря на поднятые интерфейсы, таблица маршрутизации пустая от слова вообще. Если зайти в локальную консоль и просто сделать "service network restart", то всё начинает работать. Но как-то хотелось бы, чтобы оно само при старте запускалось.

Перезапуск сети выглядит как-то вот так:

[ 1257.967750] lag0: Removing an active aggregator
[ 1257.972292] lag0: Releasing backup interface enp1s0f0
[ 1257.984512] ixgbe 0000:01:00.0: removed PHC on enp1s0f0
[ 1258.068162] ixgbe 0000:01:00.1 enp1s0f1: NIC Link is Down
[ 1258.074602] IPv6: ADDRCONF(NETDEV_UP): lag0: link is not ready
[ 1258.080458] 8021q: adding VLAN 0 to HW filter on device lag0
[ 1258.107980] ixgbe 0000:01:00.0: registered PHC device on enp1s0f0
[ 1258.215755] IPv6: ADDRCONF(NETDEV_UP): enp1s0f0: link is not ready
[ 1258.221954] 8021q: adding VLAN 0 to HW filter on device enp1s0f0
[ 1258.221992] ixgbe 0000:01:00.0 enp1s0f0: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 1258.264914] (unregistered net_device): Released all slaves
[ 1258.279227] IPv6: ADDRCONF(NETDEV_UP): enp1s0f0: link is not ready
[ 1258.285454] ixgbe 0000:01:00.0 enp1s0f0: detected SFP+: 5
[ 1258.290543] lag0: Setting MII monitoring interval to 100
[ 1258.290578] lag0: Setting up delay to 0
[ 1258.290611] lag0: Setting down delay to 0
[ 1258.290674] lag0: Setting ad_actor_sys_prio to 65535
[ 1258.290709] lag0: Setting ad_select to stable (0)
[ 1258.290743] lag0: Setting ad_user_port_key to 0
[ 1258.290810] lag0: Setting arp_all_targets to any (0)
[ 1258.290842] lag0: Setting fail_over_mac to none (0)
[ 1258.290876] lag0: Setting LACP rate to fast (1)
[ 1258.291005] lag0: Setting min links value to 0
[ 1258.291040] lag0: Setting primary_reselect to always (0)
[ 1258.291073] lag0: Setting resend_igmp to 1
[ 1258.291107] lag0: Setting use_carrier to 1
[ 1258.291140] lag0: Setting xmit hash policy to layer2 (0)
[ 1258.291255] IPv6: ADDRCONF(NETDEV_UP): lag0: link is not ready
[ 1258.291256] 8021q: adding VLAN 0 to HW filter on device lag0
[ 1258.291264] IPv6: ADDRCONF(NETDEV_UP): lag0.104: link is not ready
[ 1258.304631] IPv6: ADDRCONF(NETDEV_UP): lag0.104: link is not ready
[ 1258.379932] ixgbe 0000:01:00.0: removed PHC on enp1s0f0
[ 1258.471230] ixgbe 0000:01:00.0: registered PHC device on enp1s0f0
[ 1258.578412] 8021q: adding VLAN 0 to HW filter on device enp1s0f0
[ 1258.585708] lag0: Enslaving enp1s0f0 as a backup interface with a down link
[ 1258.590499] ixgbe 0000:01:00.0 enp1s0f0: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 1258.648453] ixgbe 0000:01:00.0 enp1s0f0: detected SFP+: 5
[ 1258.654357] ixgbe 0000:01:00.1 enp1s0f1: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 1258.743200] ixgbe 0000:01:00.0 enp1s0f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 1258.822504] lag0: link status definitely up for interface enp1s0f0, 10000 Mbps full duplex
[ 1258.830765] lag0: Warning: No 802.3ad response from the link partner for any adapters in the bond
[ 1258.839632] lag0: first active interface up!
[ 1258.843915] IPv6: ADDRCONF(NETDEV_CHANGE): lag0: link becomes ready
[ 1258.850208] IPv6: ADDRCONF(NETDEV_CHANGE): lag0.104: link becomes ready
[ 1259.097854] lag0: Removing an active aggregator
[ 1259.102393] lag0: Releasing backup interface enp1s0f0
[ 1259.115574] ixgbe 0000:01:00.0: removed PHC on enp1s0f0
[ 1259.198078] IPv6: ADDRCONF(NETDEV_UP): lag0: link is not ready
[ 1259.203923] 8021q: adding VLAN 0 to HW filter on device lag0
[ 1259.209613] IPv6: ADDRCONF(NETDEV_UP): lag0.104: link is not ready
[ 1259.236824] ixgbe 0000:01:00.0: registered PHC device on enp1s0f0
[ 1259.344753] IPv6: ADDRCONF(NETDEV_UP): enp1s0f0: link is not ready
[ 1259.350908] ixgbe 0000:01:00.0 enp1s0f0: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 1259.379995] 8021q: adding VLAN 0 to HW filter on device enp1s0f0
[ 1259.387561] IPv6: ADDRCONF(NETDEV_UP): enp1s0f0: link is not ready
[ 1259.414060] ixgbe 0000:01:00.0: removed PHC on enp1s0f0
[ 1259.419328] ixgbe 0000:01:00.0 enp1s0f0: detected SFP+: 5
[ 1259.512040] ixgbe 0000:01:00.0: registered PHC device on enp1s0f0
[ 1259.619411] 8021q: adding VLAN 0 to HW filter on device enp1s0f0
[ 1259.626208] lag0: Enslaving enp1s0f0 as a backup interface with a down link
[ 1259.631186] ixgbe 0000:01:00.0 enp1s0f0: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 1259.694487] ixgbe 0000:01:00.0 enp1s0f0: detected SFP+: 5
[ 1259.752038] lag0: Releasing backup interface enp1s0f0
[ 1259.762368] ixgbe 0000:01:00.0: removed PHC on enp1s0f0
[ 1259.846568] IPv6: ADDRCONF(NETDEV_UP): lag0: link is not ready
[ 1259.852421] 8021q: adding VLAN 0 to HW filter on device lag0
[ 1259.858148] IPv6: ADDRCONF(NETDEV_UP): lag0.104: link is not ready
[ 1259.885439] ixgbe 0000:01:00.0: registered PHC device on enp1s0f0
[ 1259.993739] IPv6: ADDRCONF(NETDEV_UP): enp1s0f0: link is not ready
[ 1259.999924] 8021q: adding VLAN 0 to HW filter on device enp1s0f0
[ 1259.999935] ixgbe 0000:01:00.0 enp1s0f0: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 1260.036384] IPv6: ADDRCONF(NETDEV_UP): enp1s0f0: link is not ready
[ 1260.061563] ixgbe 0000:01:00.0: removed PHC on enp1s0f0
[ 1260.066827] ixgbe 0000:01:00.0 enp1s0f0: detected SFP+: 5
[ 1260.154998] ixgbe 0000:01:00.0: registered PHC device on enp1s0f0
[ 1260.262402] 8021q: adding VLAN 0 to HW filter on device enp1s0f0
[ 1260.269705] lag0: Enslaving enp1s0f0 as a backup interface with a down link
[ 1260.274496] ixgbe 0000:01:00.0 enp1s0f0: WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
[ 1260.337452] ixgbe 0000:01:00.0 enp1s0f0: detected SFP+: 5
[ 1260.407397] IPv6: ADDRCONF(NETDEV_UP): lag0.104: link is not ready
[ 1260.643437] ixgbe 0000:01:00.0 enp1s0f0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
[ 1260.746805] lag0: link status definitely up for interface enp1s0f0, 10000 Mbps full duplex
[ 1260.755096] lag0: Warning: No 802.3ad response from the link partner for any adapters in the bond
[ 1260.764010] lag0: first active interface up!
[ 1260.768307] IPv6: ADDRCONF(NETDEV_CHANGE): lag0: link becomes ready
[ 1260.775327] IPv6: ADDRCONF(NETDEV_CHANGE): lag0.104: link becomes ready

На серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. C точки зрения повышения доступности и балансировки нагрузки, более эффективными методом использования нескольких сетевых интерфейсов сервера является объединение этих интерфейсов в логические сущности с использованием технологий Network Bonding и Network Teaming.

В этой заметке на конкретном примере мы рассмотрим то, как с помощью технологии Network Bonding в ОС CentOS Linux 7.2 можно организовать объединение физических сетевых интерфейсов сервера в логический сетевой интерфейс (bond), а уже поверх него создать виртуальные сетевые интерфейсы под разные задачи и сетевые службы с изоляцией по разным VLAN. Агрегирование каналов между коммутатором и сервером будет выполняться с помощью протокола Link Aggregation Control Protocol (LACP) регламентированного документом IEEE 802.3ad. Использование LACP, с одной стороны, обеспечит высокую доступность агрегированного канала, так как выход из строя любого из линков между сервером и коммутатором не приведёт к потери доступности сетевых сервисов сервера, и с другой стороны, обеспечит равномерную балансировку нагрузки между физическими сетевыми интерфейсами сервера. Настройка в нашем примере будет выполняться как на стороне коммутатора (на примере коммутатора Cisco Catalyst WS-C3560G), так и на стороне Linux-сервера с двумя сетевыми интерфейсами (на примере сервера HP ProLiant DL360 G5 с контроллерами Broadcom NetXtreme II BCM5708/HP NC373i)

Настройка конфигурации LACP на коммутаторе Cisco

Активация механизмов LACP на коммутаторе Cisco сводится к созданию виртуальной группы портов channel-group и включению в эту группу нужных нам портов коммутатора.

Очищаем существующую конфигурацию портов коммутатора, которые будем включать в channel-group (в нашем примере это будут порты 21 и 22 ):

Создаём channel-group и включаем в неё нужные нам порты коммутатора, предварительно эти отключив порты:

Вносим изменения в свойства появившегося виртуального интерфейса Port-channel2:

Изменения в свойствах первого порта-участника channel-group вносим минимальные, так как основные параметры наследуются портом с виртуального интерфейса channel-group:

Вносим изменения в свойства второго порта-участника channel-group:

Не забываем сохранить изменения:

Проверяем итоговую конфигурацию портов:

Проверяем статус подключения портов:

До тех пор, пока на стороне нашего Linux-сервера не будет настроен LACP, статус портов будет отображаться как suspended/notconnect, а после настройки статус должен будет измениться на connected (это можно будет проверить позже):

Проверяем внутренний статус LACP:

Здесь аналогично, до тех пор, пока на стороне нашего Linux-сервера не будет настроен LACP, статус LACP будет соответствующий, а после настройки статус должен будет измениться:

Теперь можем перейти к настройке Network Bonding с LACP на стороне Linux-сервера.

Настройка Network Bonding c LACP в CentOS Linux 7.2

Проверим наличие модуля поддержки bonding (команда должна отработать без ошибок):

В ниже представленном примере мы рассмотрим сценарий настройки логического bond-интерфейса bond0 (master-интерфейс), членами которого будут два имеющихся в сервере физических интерфейса enp3s0 и enps5s0 (slave-интерфейсы). А затем на созданном bond-интерфейсе мы создадим дочерний VLAN-интерфейс, имеющий доступ к изолированной тегированной сети с определённым номером VLAN. Всю настройку мы будем выполнять путём прямой правки файлов интерфейсов.

Создадим файл с конфигурацией нового агрегирующего интерфейса bond0 :

Наполним файл параметрами бонда bond0 :

Опции 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, можно выполнить:

Значение yes в данном случае говорит о поддержке MII.

Если вы используете режим active-backup bonding, то есть рекомендация настраивать дополнительную опцию bond-интерфейса: fail_over_mac= 1 . Как я понял, это нужно для того, чтобы использовать для bond в качестве основного MAC-адреса, MAC-адрес backup-интерфейса, что позволит сократить время потери соединений в процессе fail-over.

Создадим файл с конфигурацией slave-интерфейсов, то есть физических Ethernet-портов, которые будут участниками bond0 (файл скорее всего уже существует, так что просто отредактируем его под свою задачу):

Второй slave-интерфейс настраиваем по аналогии:

Параметры файла аналогичные за исключением параметров DEVICE и NAME

Если используется служба NetworkManager, то перезагрузим её конфигурацию с учётном созданных/изменённых файлов ifcfg-* :

Перезапускаем slave-интерфейсы:

Если отдельное отключение/включение интерфейсов приводит к ошибкам (это возможно в случае если ранее подключения контролировались службой NetworkManager), то перезапускаем сеть полностью:

Убедимся в том, что созданные интерфейсы успешно запущены со статусом UP и заданными нами настройками, например обратим внимание на размер MTU.

Итак, bond создан и запущен в работу, и теперь переходим к созданию виртуальных интерфейсов с поддержкой VLAN поверх нашего bond-а.

Проверим наличие модуля поддержки VLAN (команда должна отработать без ошибок)

Под каждый отдельный VLAN-интерфейс создаём конфигурационные файлы в каталоге /etc/sysconfig/network-scripts по типу ifcfg-bond < номер бонда > . < номер VLAN-а > . Например создадим конфигурационный файл для bond-интерфейса bond0 с VLAN 2

Попробуем поднять созданный VLAN-интерфейс или опять-же просто перезапускаем сеть:

Чтобы разнообразные сетевые службы, используемые на нашем сервере приняли во внимание изменение сетевой конфигурации, можно перезапустить их, либо просто перезагрузить сервер.

Убедимся в том, что VLAN-интерфейс поднялся с указанными нами настройками:

Аналогичным образом мы можем создать на сервере столько выделенных виртуальных VLAN интерфейсов, сколько потребуется для разделения трафика между разными задачами и сетевыми службами исполняемыми на сервере.

Проверяем статус работы bond0 :

Если в секции 802.3ad info значение параметра Partner Mac Address не содержит MAC-адреса коммутатора, а вместо этого видно значение 00:00:00:00:00:00, это значит то, что обмен пакетами LACPDU с коммутатором по какой-то причине не выполняется (либо на стороне коммутатора неправильно настроен LACP, либо коммутатор вовсе его не поддерживает)

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

Теперь можно переходить к заключительному этапу – проверкам нашего LACP соединения на предмет устойчивости соединения при отказе любого из портов на стороне коммутатора/сервера а также на предмет корректности балансировки нагрузки.

Проверка высокой доступности соединения

Теперь попробуем проверить устойчивость нашего LACP-соединения. Для этого запустим с любой сторонней системы, например с рабочей станции администратора, ping IP-адреса bond-интерфейса сервера

Подключимся к коммутатору Cisco и выполним отключение одного из портов, входящих в группу channel-group, обеспечивающей со стороны коммутатора LACP-соединение.

Убедимся в том, что запущенная утилита ping не отражает факт потери пакетов. Если всё в порядке, включим отключенный порт коммутатора, а затем отключим второй порт входящий в группу channel-group:

Снова проверим, что ping не имеет потерь пакетов. Если всё в порядке, включим отключенный порт коммутатора и будем считать, что наше LACP-соединение Cisco channel-group <-> Linux bond успешно отрабатывает ситуацию потери соединения на любом из интерфейсов коммутатора, входящих в channel-group. Аналогичную проверку можно выполнить и со стороны Linux сервера попеременно отключая интерфейсы входящие в bond:

Здесь между включением первого интерфейса и отключением второго для чистоты эксперимента нужно сделать небольшую паузу (5-7 секунд), чтобы LACP-линк смог полностью перестроиться для того, чтобы не было потерь пакетов. Если же эту паузу не сделать, то несколько пакетов может таки потеряться, но потом соединение всё-же будет автоматически восстановлено.

Проверка балансировки нагрузки соединения

Чтобы проверить факт того, что трафик действительно распределяется по интерфейсам bond-а, воспользуемся немного более сложной процедурой тестирования, для которой используем три компьютера, то есть сам наш сервер KOM-AD01-VM32 (IP: 10.1.0.32 ) и любые два Linux-компьютера, например KOM-AD01-SRV01 (IP: 10.1.0.11 ) и KOM-AD01-SRV02 (IP: 10.1.0.12 ). Установим на все три компьютера две утилиты - iperf (для тестирования скорости) и nload (для отображения нагрузки интерфейсов в реальном времени).

Начнем с проверки входящего трафика.

Установим на проверяемом сервере KOM-AD01-VM32 утилиты iperf и nload а затем на время теста выключим брандмауэр (либо можете создать разрешающее правило для порта, который будет слушать запущенный серверный iperf, по умолчанию это TCP 5001). Запустим утилиту iperf в режиме сервера (с ключом -s), то есть ориентированную на приём трафика:

Здесь же, но в отдельной консоли, запустим утилиту nload, которая в реальном времени будет показывать нам статистические значения нагрузки на интерфейсы. В качестве параметров укажем названия интерфейсов, за нагрузкой которых нужно следить:

Затем выполняем отсылку трафика с помощью iperf (в режиме клиента) с компьютеров KOM-AD01-SRV01 и KOM-AD01-SRV02 (запустим одинаковую команду одновременно на обоих этих компьютерах):

В качестве параметров iperf укажем следующие значения:

-c – работа в режиме клиента (отсылка трафика)
10.1.0.32 - IP адрес сервера, на который клиент iperf будет посылать трафик ( KOM-AD01-VM32 )
-t 600 – время, в течение которого будет выполняться отсылка трафика (600 секунд)
-i 2 - интервал в секундах для вывода статистической информации об отсылке трафика на экран (каждые 2 секунды)
-b 100m – размер пропускной способности сети, которую будет пытаться задействовать iperf при отсылке трафика (в нашем случае 100 мегабит/с)

После того, как iperf в режиме клиента начнёт работу на обоих серверах, переходим на проверяемый сервер KOM-AD01-VM32 и наблюдаем за статистикой nload. На начальном экране увидим статистику по входящему и исходящему трафику по первому интерфейсу ( enp3s0 ). Обращаем внимание на значения по входящему трафику:

Чтобы увидеть статистику по следующему интерфейсу ( enp5s0 ) просто нажмём Enter:

Как видим, скорость на обоих интерфейсах распределена равномерно и равна примерно 100 мегабит/с, значит балансировка входящего трафика работает успешно.

Далее, по аналогичной методике, протестируем механизм балансировки нагрузки для трафика исходящего с нашего подопытного сервера KOM-AD01-VM32 . Для этого iperf будет запускаться на компьютерах KOM-AD01-SRV01 / KOM-AD01-SRV02 в режиме сервера, принимающего трафик. Запустим одинаковую команду на обоих этих компьютерах, не забывая при этом про необходимость открытия порта для сервера iperf:

А на компьютере KOM-AD01-VM32 утилиту iperf запускаем в режиме клиента, отправляющего трафик на компьютеры KOM-AD01-SRV01 / KOM-AD01-SRV02 , используя при этом запуск из двух разных консолей:

Запускаем на компьютере KOM-AD01-VM32 третью консоль и наблюдаем за ситуацией в nload

На этот раз обращаем внимание на исходящий трафик на первом интерфейсе…

…и исходящий трафик на втором интерфейсе…

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

Если ранее на время теста отключался брандмауэр, то по окончанию теста не забываем включить его обратно:

В двух словах, teamd — еще один способ агрегирования сетевых интерфейсов (подобно bond). Мы рассмотрим его настройку для системы Linux CentOS (Red Hat).

Установка teamd

В системе должен быть установлен пакет teamd. Он находится в репозиториях популярных систем и в CentOS устанавливается командой:

yum install teamd

Объединение сетевых интерфейсов

Чтобы настройки были постоянными (объединение сети также работало после перезагрузки компьютера), мы настроим сеть через ifcfg-файлы.

Создаем конфигурационный файл для team:

* где TEAM_CONFIG — настройка объединения для интерфейса в формате json; подробнее, о настройке сети в CentOS читайте в статье Настройка сети в CentOS.

В примере выше мы используем runner loadbalance — балансировку трафика. Вот возможные варианты и их описание:

Runner	Описание
lacp	Объединение сетевых интерфейсов с помощью протокола LACP (802.3ad).
broadcast	Весь трафик идет через все порты.
roundrobin	Трафик идет через все интерфейсы поочередно в случайном порядке.
loadbalance	Равномерное распределение трафика между всеми интерфейсами.
activebackup	Используется только один интерфейс. Остальные подключаются, при недоступности основного в соответствии с выставленными приоритетами.

Также настроим физические интерфейсы (в данном примере ens32 и ens34):

ONBOOT=yes
DEVICE=ens32
DEVICETYPE=TeamPort
NM_CONTROLLED=no
TEAM_MASTER=team0

ONBOOT=yes
DEVICE=ens34
DEVICETYPE=TeamPort
NM_CONTROLLED=no
TEAM_MASTER=team0

Перезапускаем сетевую службу:

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

systemctl restart network

Проверяем состояние team:

teamdctl team0 state

. в моем случае это было:

setup:
runner: loadbalance
ports:
ens32
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
down count: 0
ens34
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
down count: 0

* как видим, используется runner loadbalance; объединены интерфейсы ens32 и ens34, которые находятся в состоянии up.

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

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

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 и приводим его к следующему виду.

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

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

3. Проверяем

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

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

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

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

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

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

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

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

Читайте также: