настройка bond в linux
Бонд. Джеймс Бонд или объединение сетевых интерфейсов (бондинг)
Подобная статья уже была от автора AccessForbidden: «Объединение сетевых интерфейсов в linux».
Эта статья именно о настройке, и установке. Пишу её потому, что недавно столкнулся с проблемами установки и настройки бондинга.
Ситуация была такова: Был стааренький компьютер на четырёх-поточном пентиуме, с гигабайтом ОЗУ, и встроенным гигабитным интерфейсом на мат.плате. Он был мне как шлюзом, так медиацентром, и NAS’ом. Но вот, когда уже дома появилось N-ное количество девайсов (телевизор, смартфоны и компьютеры) пропускной способности начало не хватать. Но была у меня хорошая интеловская сетевая карточка (тоже гигабитная) и я решил погуглить на тему объединения интерфейсов
Вообще, Ethernet bonding (если быть точнее) — это объединение двух или более физических сетевых интерфейсов в один виртуальный для обеспечения отказоустойчивости и повышения пропускной способности сети. Или (простым языком говоря)Raid для сетевых карт. Только их «заточенность» на пропускную способность, на одинакового производителя- не важна
Ну, для начала, нужно убедится, нуждаетесь вы в этом или нет (скорее всего, если вы это читаете, значит вам это возможно нужно. ). Перед тем, как начнём, предупреждаю: делать нужно всё на сервере и от рута.
Итак, начнём!
Вставляем сет.карту, если не вставали. ну и подключаем к свитчу (коммутатору) или роутеру обе карты
Этап подготовки:
Теперь, нам нужно поставить ifenslave. на данный момент, актуальна версия 2.6. Ставим:
Теперь, нам нужно выключить интерфейсы, которые мы объединяем (в моём случае, это — eth0, eth1).
Ну и останавливаем сеть:
Этап настройки:
Теперь нам нужно настроить файл /etc/network/interfaces
(я лично пользуюсь «нано»).
Поскольку показываю, как делал я, у меня он
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto usb0
allow-hotplug usb0
iface usb0 inet dhcp
auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
auto eth1
iface eth1 inet dhcp
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto usb0
allow-hotplug usb0
iface usb0 inet dhcp
iface bond0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
slaves eth0 eth1
bond-mode balance-rr
bond-miimon 100
bond-downdelay 200
bond-updelay 200
Хочу обратить ваше внимание на:
Первое — если у вас dhcp сервер, то в /etc/default/isc-dhcp-server, в Interfaces я указал bond0. так и с остальными серверами.
Второе — тоже про dhcp. если у вас оный сервер, то в address, netmask, network bond’а0, указываем те же параметры что и у интерфейса на который до этого, работал dhcp
Третье — должен быть только bond0 (0 — в данном случае. Кстати, их может быть куча). Интерфейсы, которые мы объединили написав в строку slaves, мы убираем.
После сделанного пишем (в терминале уже):
Только его!
«включаем» сеть. Кстати на ошибки можно не обращать внимания. Они не критичны.
Можем перезагрузится.
bond0 Link encap:Ethernet HWaddr 00:16:e6:4d:5e:05
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::216:e6ff:fe4d:5e05/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:33518 errors:0 dropped:0 overruns:0 frame:0
TX packets:30062 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6687125 (6.3 MiB) TX bytes:17962008 (17.1 MiB)
eth0 Link encap:Ethernet HWaddr 00:16:e6:4d:5e:05
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:16630 errors:0 dropped:0 overruns:0 frame:0
TX packets:15031 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3288730 (3.1 MiB) TX bytes:8966465 (8.5 MiB)
Interrupt:43 Base address:0x6000
eth1 Link encap:Ethernet HWaddr 00:16:e6:4d:5e:05
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:16888 errors:0 dropped:0 overruns:0 frame:0
TX packets:15031 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3398395 (3.2 MiB) TX bytes:8995543 (8.5 MiB)
Interrupt:17 Memory:e1080000-e10a0000
Можно ещё добавлять интерфейсы bond0:0 и т.д.
Подходящий для вас режим, указывайте в /etc/network/interfaces в строке: bond-mode.
Объединение сетевых интерфейсов в Linux. Настройка bonding
Объединение сетевых интерфейсов(Bonding) – это механизм, используемый Linux-серверами и предполагающий связь нескольких физических интерфейсов в один виртуальный, что позволяет обеспечить большую пропускную способность или отказоустойчивость в случае повреждения кабеля. В данном руководстве мы разберем реализацию объединения интерфейсов в Linux для Ubuntu/Debian и CentOS/RHEL/Fedora.
Агрегация сетевых интерфейсов в Ubuntu и Debian
Важно! Если у вас используется Ubuntu версии 17.10 и выше, то необходимо установить пакет ifupdown или настраивать агрегацию каналов нужно через netplan
Прежде всего нужно установить модуль ядра для поддержки объединения и при помощи команды modprobe проверить, загружен ли драйвер.
В более старых версиях Debian или Ubuntu может потребоваться установка пакета ifenslave:
Для создания связанного интерфейса из двух физических сетевых карт вашей системы выполните следующую команду. К сожалению, при использовании такого метода объединение интерфейсов не сохраняется после перезагрузки системы:
Чтобы активировать объединенный интерфейс, перезапустите сетевую службу, отключите физические интерфейсы и включите объединенный интерфейс, либо перезагрузите машину, чтобы ядро определило новый объединенный интерфейс.
Настройки связанного интерфейса можно проверить при помощи следующих команд:
Подробную информацию об объединенном интерфейсе можно получить, просмотрев содержимое следующего файла ядра командой cat:
Для отладки ошибок можно использовать команду tail
Проверку параметров сетевой карты можно выполнить при помощи инструмента mii-tool:
Режимы работы
mode=0 (balance-rr)
При этом методе объединения трафик распределяется по принципу «карусели»: пакеты по очереди направляются на сетевые карты объединённого интерфейса. Например, если у нас есть физические интерфейсы eth0, eth1, and eth2, объединенные в bond0, первый пакет будет отправляться через eth0, второй — через eth1, третий — через eth2, а четвертый снова через eth0 и т.д.
mode=1 (active-backup)
Когда используется этот метод, активен только один физический интерфейс, а остальные работают как резервные на случай отказа основного.
mode=2 (balance-xor)
В данном случае объединенный интерфейс определяет, через какую физическую сетевую карту отправить пакеты, в зависимости от MAC-адресов источника и получателя.
mode=3 (broadcast) Широковещательный режим, все пакеты отправляются через каждый интерфейс. Имеет ограниченное применение, но обеспечивает значительную отказоустойчивость.
mode=4 (802.3ad)
Особый режим объединения. Для него требуется специально настраивать коммутатор, к которому подключен объединенный интерфейс. Реализует стандарты объединения каналов IEEE и обеспечивает как увеличение пропускной способности, так и отказоустойчивость.
mode=5 (balance-tlb)
Распределение нагрузки при передаче. Входящий трафик обрабатывается в обычном режиме, а при передаче интерфейс определяется на основе данных о загруженности.
mode=6 (balance-alb)
Адаптивное распределение нагрузки. Аналогично предыдущему режиму, но с возможностью балансировать также входящую нагрузку.
Объединение сетевых интерфейсов в CentOS, RHEL и Fedora
Такая строка в файле /etc/modprobe.d/bonding.conf требуется для каждого bond интерфейса.
Для агрегации интерфейсов создайте в директории /etc/sysconfig/network-scripts/ файл конфигурации с именем ifcfg-bond0. Вот пример содержимого файла конфигурации (IP-адреса в вашей системе могут отличаться):
После создания объединённого интерфейса нужно настроить его и связанные с ним сетевые карты, добавив в файлы конфигурации директивы MASTER и SLAVE. Для всех связанных интерфейсов эти файлы могут быть почти одинаковыми. Например, у двух интерфейсов eth0 и eth1, связанных в один, они могут иметь следующий вид. Отредактируйте их, как показано ниже.
Для eth0
Значение этих директив следующее:
DEVICE: определяет имя устройства
USERCTL: определяет, может ли пользователь управлять интерфейсом (в данном случае нет)
ONBOOT: определяет, включать ли интерфейс при загрузке
MASTER: есть ли у этого устройства ведущий интерфейс (здесь это bond0)
SLAVE: работает ли это устройство каки ведомое
BOOTPROTO: Определяет получение IP-адреса по DHCP. При статическом IP-адресе устанавливается значение none
Перезагрузите сетевую службу и проверьте конфигурацию командой ifconfig.
Заключение
Объединение сетевых интерфейсов — удобный и функциональный механизм для обеспечения качественной и бесперебойной работы вашей сети. Надеемся, данное руководство было полезным. Более подробную информацию об используемых командах можно получить в соответствующих man-страницах.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Ubuntu Documentation
Bonding, also called port trunking or link aggregation means combining several network interfaces (NICs) to a single link, providing either high-availability, load-balancing, maximum throughput, or a combination of these. See Wikipedia for details.
Interface Configuration
Step 1: Ensure kernel support
Before Ubuntu can configure your network cards into a NIC bond, you need to ensure that the correct kernel module bonding is present, and loaded at boot time.
Edit your /etc/modules configuration:
Ensure that the bonding module is loaded:
Note: Starting with Ubuntu 9.04, this step is optional if you are configuring bonding with ifup/ifdown. In this case, the bonding module is automatically loaded when the bond interface is brought up.
Step 2: Configure network interfaces
Ensure that your network is brought down:
Then load the bonding kernel module:
Now you are ready to configure your NICs.
Edit your interfaces configuration:
For example, to combine eth0 and eth1 as slaves to the bonding interface bond0 using a simple active-backup setup, with eth0 being the primary interface:
The bond-primary directive, if needed, needs to be part of the slave description (eth0 in the example), instead of the master. Otherwise it will be ignored.
As another example, to combine eth0 and eth1 using the IEEE 802.3ad LACP bonding protocol:
The bond statements in 12.04 are dashed instead of underscored. The config above is updated based on Stéphane Graber’s bonding example at : http://www.stgraber.org/download/complex-interfaces
For bonding-specific networking options please consult the documentation available at BondingModuleDocumentation.
Finally, bring up your network again:
Checking the bonding interface
Link information is available under /proc/net/bonding/. To check bond0 for example:
Bringing up/down bonding interface
To bring the bonding interface, run
To bring down a bonding interface, run
Ethernet Bonding modes
Ethernet bonding has different modes you can use. You specify the mode for your bonding interface in /etc/network/interfaces. For example:
Descriptions of bonding modes
Round-robin policy: Transmit packets in sequential order from the first available slave through the last. This mode provides load balancing and fault tolerance. Mode 1
Active-backup policy: Only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails. The bond’s MAC address is externally visible on only one port (network adapter) to avoid confusing the switch. This mode provides fault tolerance. The primary option affects the behavior of this mode. Mode 2
XOR policy: Transmit based on selectable hashing algorithm. The default policy is a simple source+destination MAC address algorithm. Alternate transmit policies may be selected via the xmit_hash_policy option, described below. This mode provides load balancing and fault tolerance. Mode 3
Broadcast policy: transmits everything on all slave interfaces. This mode provides fault tolerance. Mode 4
IEEE 802.3ad Dynamic link aggregation. Creates aggregation groups that share the same speed and duplex settings. Utilizes all slaves in the active aggregator according to the 802.3ad specification.
Adaptive transmit load balancing: channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load (computed relative to the speed) on each slave. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed receiving slave.
Adaptive load balancing: includes balance-tlb plus receive load balancing (rlb) for IPV4 traffic, and does not require any special switch support. The receive load balancing is achieved by ARP negotiation. The bonding driver intercepts the ARP Replies sent by the local system on their way out and overwrites the source hardware address with the unique hardware address of one of the slaves in the bond such that different peers use different hardware addresses for the server.
Descriptions of balancing algorithm modes
The balancing algorithm is set with the xmit_hash_policy option.
Possible values are:
layer2 Uses XOR of hardware MAC addresses to generate the hash. This algorithm will place all traffic to a particular network peer on the same slave.
layer2+3 Uses XOR of hardware MAC addresses and IP addresses to generate the hash. This algorithm will place all traffic to a particular network peer on the same slave.
layer3+4 This policy uses upper layer protocol information, when available, to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection will not span multiple slaves.
encap2+3 This policy uses the same formula as layer2+3 but it relies on skb_flow_dissect to obtain the header fields which might result in the use of inner headers if an encapsulation protocol is used.
encap3+4 This policy uses the same formula as layer3+4 but it relies on skb_flow_dissect to obtain the header fields which might result in the use of inner headers if an encapsulation protocol is used.
The default value is layer2. This option was added in bonding version 2.6.3. In earlier versions of bonding, this parameter does not exist, and the layer2 policy is the only policy. The layer2+3 value was added for bonding version 3.2.2.
UbuntuBonding (последним исправлял пользователь sbright 2017-11-07 14:58:45)
The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details
Настройка Network Bonding с LACP между CentOS Linux 7.2 и коммутатором Cisco 3560G
На серверах имеющих несколько сетевых интерфейсов каждый отдельно взятый интерфейс можно использовать под какую-то выделенную задачу, например отдельный интерфейс под трафик управления хостом и отдельный интерфейс под трафик периодического резервного копирования. Может возникнуть мысль о том, что такая конфигурация имеет свои плюсы, например, позволяет максимально жёстко разграничить утилизацию интерфейсов под особенности разных задач. Но на этом плюсы, пожалуй, и заканчиваются. Ибо при таком подходе может получиться так, что один интерфейс будет постоянно чем-то чрезмерно нагружен, а другой интерфейс будет периодически полностью простаивать. К тому же, в такой схеме каждый из физических интерфейсов будет выступать как конкретная сущность, при выходе из строя которой будет происходить остановка того или иного сетевого сервиса, жёстко связанного с этой сущностью. 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 :
В нашем примере используется несколько опций:
Чтобы проверить то, может ли наш сетевой контроллер работать с MII, можно выполнить:
Значение yes в данном случае говорит о поддержке MII.
Создадим файл с конфигурацией slave-интерфейсов, то есть физических Ethernet-портов, которые будут участниками bond0 (файл скорее всего уже существует, так что просто отредактируем его под свою задачу):
Второй slave-интерфейс настраиваем по аналогии:
Параметры файла аналогичные за исключением параметров DEVICE и NAME
Если используется служба NetworkManager, то перезагрузим её конфигурацию с учётном созданных/изменённых файлов ifcfg-* :
Перезапускаем slave-интерфейсы:
Если отдельное отключение/включение интерфейсов приводит к ошибкам (это возможно в случае если ранее подключения контролировались службой NetworkManager), то перезапускаем сеть полностью:
Убедимся в том, что созданные интерфейсы успешно запущены со статусом UP и заданными нами настройками, например обратим внимание на размер MTU.
Итак, bond создан и запущен в работу, и теперь переходим к созданию виртуальных интерфейсов с поддержкой VLAN поверх нашего bond-а.
Проверим наличие модуля поддержки VLAN (команда должна отработать без ошибок)
Попробуем поднять созданный 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-линк смог полностью перестроиться для того, чтобы не было потерь пакетов. Если же эту паузу не сделать, то несколько пакетов может таки потеряться, но потом соединение всё-же будет автоматически восстановлено.
Проверка балансировки нагрузки соединения
Начнем с проверки входящего трафика.
Установим на проверяемом сервере KOM-AD01-VM32 утилиты iperf и nload а затем на время теста выключим брандмауэр (либо можете создать разрешающее правило для порта, который будет слушать запущенный серверный iperf, по умолчанию это TCP 5001). Запустим утилиту iperf в режиме сервера (с ключом -s), то есть ориентированную на приём трафика:
Здесь же, но в отдельной консоли, запустим утилиту nload, которая в реальном времени будет показывать нам статистические значения нагрузки на интерфейсы. В качестве параметров укажем названия интерфейсов, за нагрузкой которых нужно следить:
Затем выполняем отсылку трафика с помощью iperf (в режиме клиента) с компьютеров KOM-AD01-SRV01 и KOM-AD01-SRV02 (запустим одинаковую команду одновременно на обоих этих компьютерах):
В качестве параметров iperf укажем следующие значения:
После того, как iperf в режиме клиента начнёт работу на обоих серверах, переходим на проверяемый сервер KOM-AD01-VM32 и наблюдаем за статистикой nload. На начальном экране увидим статистику по входящему и исходящему трафику по первому интерфейсу ( enp3s0 ). Обращаем внимание на значения по входящему трафику:
Чтобы увидеть статистику по следующему интерфейсу ( enp5s0 ) просто нажмём Enter:
Как видим, скорость на обоих интерфейсах распределена равномерно и равна примерно 100 мегабит/с, значит балансировка входящего трафика работает успешно.
Запускаем на компьютере KOM-AD01-VM32 третью консоль и наблюдаем за ситуацией в nload
На этот раз обращаем внимание на исходящий трафик на первом интерфейсе…
…и исходящий трафик на втором интерфейсе…
Как видим, трафик распределён по разным интерфейсам нашего bond-a, значит балансировка исходящего трафика работает успешно.
Если ранее на время теста отключался брандмауэр, то по окончанию теста не забываем включить его обратно:
Дополнительные источники информации: