Linux Bonding: сетевая избыточность и агрегация каналов

Linux bonding — это объединение нескольких физических сетевых интерфейсов в один логический. Зачем? Две причины: отказоустойчивость и увеличение пропускной способности. Сервер с двумя интерфейсами по 1 Гбит может иметь либо 2 Гбит суммарно, либо автоматическое переключение при обрыве кабеля — в зависимости от выбранного режима.

В нашей практике bonding появляется на всех серверах, которые нельзя перезагружать по ночам ради замены сетевой карты. Dell PowerEdge R640 с двумя портами 10G — стандартная конфигурация для клиентских серверов. Без bonding потеря одного порта = даунтайм. С bonding — замена карты в рабочее время без остановки сервисов.

Основные режимы Linux bonding:

• mode=0 (balance-rr) — round-robin по всем интерфейсам, увеличивает пропускную способность
• mode=1 (active-backup) — один активен, остальные в резерве, классическое резервирование
• mode=2 (balance-xor) — балансировка по XOR MAC-адресов
• mode=4 (802.3ad / LACP) — стандартная агрегация каналов, требует поддержки коммутатора
• mode=5 (balance-tlb) — адаптивная балансировка исходящего трафика
• mode=6 (balance-alb) — адаптивная балансировка входящего и исходящего

Mode=1 — самый простой и надёжный вариант. Не требует настройки коммутатора. Работает даже с разными коммутаторами на разных интерфейсах.

Mode=4 даёт настоящую агрегацию — трафик распределяется по всем активным интерфейсам. Два 10G порта = 20 Гбит суммарной полосы. Но нужна поддержка со стороны коммутатора.

Настроить bonding — половина дела. Важно знать, как убедиться, что он работает, и как диагностировать проблемы.

В реальной инфраструктуре bonding редко стоит один. Обычно поверх bond0 создаются VLAN-интерфейсы для разных подсетей, или bridge для виртуальных машин.

На гипервизоре bond почти никогда не получает IP-адрес сам. Я делаю его портом Linux-моста, а адрес управления и сети виртуальных машин вешаю уже на мост. Так отказоустойчивость получают сразу и хост, и все гости: при обрыве одного кабеля ВМ даже не замечают переключения.

В Proxmox VE конфигурация живёт в /etc/network/interfaces, и документация Proxmox приводит именно такую схему:

auto bond0
iface bond0 inet manual
      bond-slaves eno1 eno2
      bond-miimon 100
      bond-mode 802.3ad
      bond-xmit-hash-policy layer2+3

auto vmbr0
iface vmbr0 inet static
        address  10.10.10.2/24
        gateway  10.10.10.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Строки bridge-vlan-aware yes и bridge-vids 2-4094 делают мост VLAN-aware: тег VLAN я задаю прямо в настройках сетевой карты ВМ, а не создаю отдельные мосты под каждую подсеть. Адрес хоста в служебном VLAN оформляется интерфейсом вида vmbr0.5.

Два ограничения, о которых прямо пишет Proxmox:

• режимы balance-tlb и balance-alb не подходят для моста с гостевыми машинами — они подменяют MAC-адреса в ARP-ответах и рассчитаны на то, что хосту известны все локальные адреса;
• для сети кластера Corosync bond не нужен: Corosync сам переключается между несколькими сетями (link0, link1), а некоторые режимы bonding для него проблемны. Я отдаю Corosync два отдельных линка без агрегации.

Если коммутатор LACP не умеет, на гипервизоре ставлю bond-mode active-backup — остальная схема с мостом не меняется.

Большинство проблем с bonding, которые я разбираю, — это не баг драйвера, а значение по умолчанию, о котором забыли. Сверяю по документации ядра (Documentation/networking/bonding) и man systemd.netdev:

• Мониторинг линка. У модуля ядра miimon по умолчанию 100 мс, если не задан arp_interval. А у systemd-networkd MIIMonitorSec= по умолчанию 0, то есть мониторинг выключен. Без мониторинга драйвер считает все линки живыми и продолжает слать трафик в оборванный кабель. Поэтому MIIMonitorSec=100ms пишу всегда явно.
• updelay/downdelay. По умолчанию 0. Значение должно быть кратно miimon, иначе ядро округлит его вниз до ближайшего кратного.
• Хеш-политика. xmit_hash_policy по умолчанию layer2: весь трафик к одному соседу (например, к шлюзу) идёт через один интерфейс. layer2+3 добавляет IP-адреса, layer3+4 — порты. Но даже с layer3+4 одно TCP-соединение не разложится на несколько линков, а сама политика по документации ядра не полностью совместима с 802.3ad.
• Скорость LACPDU. lacp_rate по умолчанию slow — партнёр шлёт LACPDU раз в 30 секунд; fast — раз в секунду.
• MinLinks. По умолчанию 0: bond в режиме 802.3ad держит carrier, пока жив хотя бы один агрегатор. Если сервису нужно минимум два линка, задаю MinLinks=2.
• MAC при переключении. fail_over_mac по умолчанию none — все slave-интерфейсы получают один MAC. Значения active и follow нужны для карт, которые не умеют менять свой MAC-адрес.

Отдельно проверяю ожидания заказчика. Агрегация двух линков по 1 Гбит не превращает копирование одного файла в 2 Гбит/с: документация ядра прямо говорит, что во всех режимах, кроме balance-rr, одно соединение не использует больше полосы одного интерфейса. Выигрыш виден, когда к серверу одновременно ходит много клиентов.