Пояснення мережевого бондингу: всі 7 режимів, архітектура та реальне налаштування

Network bonding — також відомий як NIC teaming, агрегація каналів або Ethernet bonding — це техніка об’єднання двох або більше фізичних мережевих інтерфейсних карт (NIC) в єдиний логічний інтерфейс, яким керує ядро операційної системи. Результатом є уніфікований мережевий пристрій, що забезпечує збільшену сукупну пропускну здатність, автоматичне перемикання при відмові та розподіл навантаження по всіх каналах-учасниках одночасно.

На рівні ядра в Linux-системах bonding реалізується через модуль ядра `bonding`, який представляє єдиний віртуальний інтерфейс (зазвичай з назвою `bond0`) мережевому стеку. Ця абстракція означає, що застосунки, таблиці маршрутизації та правила брандмауера взаємодіють з одним інтерфейсом незалежно від кількості фізичних NIC під ним — критична архітектурна деталь, що спрощує управління, забезпечуючи при цьому відмовостійкість корпоративного рівня.

Чому Network Bonding важливий у виробничих середовищах

Перш ніж заглиблюватися в режими, варто точно зрозуміти, яку проблему вирішує bonding — і де він не допомагає. Один порт Gigabit Ethernet має жорстку стелю пропускної здатності приблизно 125 МБ/с. Для сервера баз даних, вузла зберігання або веб-застосунку з високим трафіком ця стеля досягається швидко. Об’єднання двох NIC 1 GbE не подвоює магічним чином пропускну здатність для одного TCP-потоку (це поширена хибна думка), але дозволяє кільком одночасним потокам насичувати обидва канали, ефективно подвоюючи сукупну ємність.

Окрім чистої пропускної здатності, bonding усуває єдину точку відмови, яку являє собою одиночний NIC або кабель. У середовищах, де час безвідмовної роботи вимірюється дев’ятками, це надзвичайно важливо.

Основні переваги в короткому огляді

• Сукупна пропускна здатність: Кілька фізичних каналів забезпечують загальну пропускну здатність для одночасних потоків трафіку
• Автоматичне перемикання при відмові: Виявлення відмови каналу (через MII або ARP-моніторинг) запускає перемикання менш ніж за секунду на інтерфейс, що залишився
• Розподіл навантаження: Трафік розподіляється між інтерфейсами-учасниками відповідно до активного алгоритму bonding
• Прозорість для застосунків: Інтерфейс bond має єдину MAC-адресу та IP, не вимагаючи жодних змін на рівні застосунків
• Економічна ефективність обладнання: Об’єднання звичайних NIC може бути економічно вигіднішим, ніж перехід на одну карту 10 GbE в деяких сценаріях

Архітектура Network Bonding: як це працює зсередини

Драйвер bonding ядра Linux працює між рівнем 2 (канальним) та драйверами фізичних NIC. Під час передачі кадру політика передачі драйвера bonding вибирає, який підлеглий інтерфейс використовувати. При отриманні всі підлеглі інтерфейси передають кадри головному bond-інтерфейсу, який усуває дублікати та доставляє їх до мережевого стеку.

Моніторинг каналів — це механізм виявлення відмов. Існують два методи:

• MII (Media Independent Interface) моніторинг: Опитує фізичний стан каналу кожного NIC з налаштованим інтервалом (параметр `miimon`, зазвичай 100 мс). Швидкий та надійний для виявлення відключення кабелю або відмови NIC.
• ARP-моніторинг: Надсилає ARP-запити до цільового IP та очікує відповідей. Більш корисний, коли потрібно перевірити наскрізне з’єднання, а не лише фізичний стан каналу, але вводить залежність від досяжної ARP-цілі.

Параметри `downdelay` та `updelay` додають гістерезис — запобігаючи швидким коливанням при нестабільному каналі. Встановлення їх по 200 мс кожен є поширеним базовим значенням для виробничих середовищ.

Усі 7 режимів Linux Bonding: технічний поглиблений аналіз

Драйвер bonding Linux визначає сім окремих режимів (від 0 до 6). Кожен реалізує різну політику передачі та поведінку при відмові. Вибір неправильного режиму є однією з найпоширеніших помилок конфігурації при розгортанні серверів.

Режим 0 — Round-Robin (balance-rr)

Пакети передаються послідовно через усі активні підлеглі інтерфейси в циклічному порядку: пакет 1 через eth0, пакет 2 через eth1, пакет 3 через eth0 і так далі.

Що насправді відбувається: Round-robin працює на рівні пакетів, а не потоків. Це означає, що пакети одного TCP-з’єднання можуть бути доставлені не по порядку, якщо два шляхи мають різну затримку. TCP-стек хоста-отримувача впорядкує їх, але це спричиняє повторні передачі та зниження пропускної здатності на практиці — особливо помітно при великих передачах файлів через одне з’єднання.

Вимога до комутатора: Порти комутатора повинні бути налаштовані як статична LAG (Link Aggregation Group) без LACP. Без цього комутатор побачить кадри з однієї MAC-адреси, що надходять на кілька портів, і може ініціювати відключення для захисту від петель.

Найкраще використання: Навантаження з масовою передачею даних з багатьма одночасними короткочасними з’єднаннями, де допустиме переупорядкування пакетів.

Режим 1 — Active-Backup

Лише один підлеглий інтерфейс активний у будь-який момент часу. Всі інші перебувають у стані гарячого резерву. Коли активний канал відмовляє (виявляється через MII або ARP-моніторинг), драйвер bonding підвищує резервний підлеглий інтерфейс та надсилає безоплатний ARP для оновлення таблиць MAC-адрес мережі.

Критичний нюанс: У режимі active-backup bond-інтерфейс завжди представляє мережі одну й ту саму MAC-адресу (MAC активного на даний момент підлеглого інтерфейсу). Це означає, що спеціальна конфігурація комутатора не потрібна — з точки зору комутатора, це звичайне з’єднання з одним хостом. Це єдиний режим, який коректно працює на комутаторах без будь-якої конфігурації LAG.

Час перемикання при відмові: З `miimon=100`, `downdelay=200`, `updelay=200` можна очікувати перемикання приблизно за 200–300 мс — достатньо швидко, щоб уникнути розривів TCP-сесій у більшості випадків.

Найкраще використання: Сценарії високої доступності, де простота та сумісність важливіші за пропускну здатність — інтерфейси управління, позасмуговий доступ або будь-яке середовище, де комутатор не перебуває під вашим контролем.

Режим 2 — Balance-XOR

Трафік розподіляється за допомогою політики хешування передачі, що застосовується до кожного пакету. Хеш за замовчуванням — `(source_MAC XOR destination_MAC) modulo slave_count`. Політики вищого рівня (`layer3+4`) використовують IP-адреси та номери портів для кращого розподілу.

Політика layer3+4: Налаштування `xmit_hash_policy=layer3+4` значно покращує розподіл шляхом хешування за IP-адресою джерела, IP-адресою призначення, портом джерела та портом призначення. Це забезпечує розподіл різних TCP-потоків до одного сервера призначення між каналами, чого не може досягти хеш за замовчуванням на основі MAC.

Вимога до комутатора: Статична конфігурація LAG на комутаторі (як і в режимі 0), але без проблеми переупорядкування пакетів, оскільки всі пакети в межах одного потоку проходять через один інтерфейс.

Найкраще використання: Середовища, що потребують балансування навантаження без підтримки LACP, особливо в поєднанні з політикою хешування `layer3+4`.

Режим 3 — Broadcast

Кожен пакет передається одночасно на всіх підлеглих інтерфейсах. Кожен підлеглий надсилає ідентичну копію кожного кадру.

Коли це насправді корисно: Режим broadcast — це не про пропускну здатність, а про гарантовану доставку до кількох мережевих сегментів одночасно. Він використовується в спеціалізованих сценаріях кластеризації з високою доступністю, де два окремі комутатори або мережеві шляхи повинні отримувати кожен пакет (наприклад, певні системи реплікації сховищ або фінансові торгові системи з резервними мережевими структурами). Також використовується в деяких налаштуваннях мережевого моніторингу.

Вартість пропускної здатності: З двома NIC у режимі broadcast ви споживаєте подвійну пропускну здатність для кожного пакету. З чотирма NIC — четверну. Цей режим ніколи не слід використовувати для загального трафіку.

Режим 4 — 802.3ad / LACP (динамічна агрегація каналів)

Це стандарт IEEE 802.3ad, реалізований через Link Aggregation Control Protocol (LACP). Драйвер bonding та комутатор обмінюються LACP PDU (Protocol Data Units) для динамічного узгодження того, які канали утворюють групу агрегації, їх параметрів та стану.

Як працює узгодження LACP: Кожна сторона надсилає LACP PDU, рекламуючи пріоритет системи, пріоритет порту та ключ агрегації. Канали з відповідними ключами з обох сторін утворюють LAG. Якщо канал відмовляє, LACP виявляє це та видаляє його з групи без будь-якого ручного втручання.

Політика хешування передачі: Як і режим 2, режим 4 використовує політику хешування для розподілу навантаження. Тут також настійно рекомендується політика `layer3+4`. Зверніть увагу, що LACP не гарантує балансування навантаження на рівні пакетів — він розподіляє потоки між каналами, тому одна велика передача файлу все одно використовуватиме лише один фізичний канал.

Конфігурація комутатора: На комутаторі повинен бути увімкнений LACP на відповідному port channel. Невідповідні режими LACP (active vs. passive) є частою причиною збоїв bonding. Обидві сторони можна встановити в `active`, щоб гарантувати успішне узгодження.

Найкраще використання: Центри обробки даних, високопродуктивні сервери та будь-яке середовище, де ви контролюєте конфігурацію комутатора. Це золотий стандарт для виробничого bonding за наявності підтримки комутатора.

Режим 5 — Balance-TLB (адаптивне балансування навантаження при передачі)

Режим 5 розподіляє вихідний трафік між усіма підлеглими інтерфейсами на основі поточного навантаження кожного інтерфейсу (найменш завантажений підлеглий отримує наступний вихідний пакет). Вхідний трафік приймається лише на одному призначеному підлеглому інтерфейсі.

Ключова перевага: Конфігурація комутатора взагалі не потрібна. Bond-інтерфейс використовує різні MAC-адреси джерела для кожного підлеглого при вихідному трафіку, що є допустимою поведінкою, яку будь-який комутатор обробляє прозоро.

Обмеження: Вхідний трафік не балансується. Якщо ваш сервер переважно отримує великі обсяги даних (сервер завантажень, репліка бази даних, що отримує потоки реплікації), режим 5 не дає жодної переваги для цього напрямку. Якщо ваш сервер переважно надсилає дані, режим 5 є дуже ефективним.

Поведінка при відмові: Якщо підлеглий інтерфейс, що приймає трафік, відмовляє, інший підлеглий перебирає роль приймача. Балансування вихідного навантаження продовжується між підлеглими інтерфейсами, що залишилися.

Режим 6 — Balance-ALB (адаптивне балансування навантаження)

Режим 6 розширює режим 5, додаючи балансування вхідного навантаження через ARP-узгодження. Драйвер bonding періодично надсилає ARP-відповіді з різними MAC-адресами джерела різним клієнтам, змушуючи ці клієнти надсилати зворотний трафік на різні підлеглі інтерфейси.

Механізм маніпуляції ARP: Це хитра частина. Драйвер перехоплює ARP-відповіді та ротує MAC-адресу джерела між підлеглими інтерфейсами. Клієнти кешують ці ARP-записи та направляють свій трафік до того підлеглого MAC, який вони дізналися. Це досягає балансування вхідного навантаження без будь-якої конфігурації на стороні комутатора.

Практичне застереження: Балансування вхідного трафіку на основі ARP працює лише для хостів, які нещодавно спілкувалися з bonded-сервером. Нові з’єднання завжди надходять на основний підлеглий інтерфейс, поки не буде надіслана ARP-відповідь. У сценаріях з високою частотою з’єднань розподіл вхідного трафіку може бути нерівномірним.

Найкраще використання: Середовища без комутаторів з підтримкою LACP, що потребують двонаправленого балансування навантаження. Хороший вибір для середовищ VPS Хостингу, де віртуальний комутатор гіпервізора може не підтримувати LACP.

Таблиця порівняння режимів Bonding

Налаштування Network Bonding на Linux

Передумови

“`bash

Verify bonding module is available

modinfo bonding

Load the module if not already loaded

modprobe bonding

“`

Конфігурація через systemd-networkd (сучасний підхід)

Створіть `/etc/systemd/network/bond0.netdev`:

“`ini

[NetDev]

Name=bond0

Kind=bond

[Bond]

Mode=802.3ad

TransmitHashPolicy=layer3+4

MIIMonitorSec=100ms

LACPTransmitRate=fast

“`

Створіть `/etc/systemd/network/bond0.network`:

“`ini

[Match]

Name=bond0

[Network]

Address=192.168.1.10/24

Gateway=192.168.1.1

“`

Створіть `/etc/systemd/network/eth0.network` та `eth1.network`:

“`ini

[Match]

Name=eth0

[Network]

Bond=bond0

“`

Конфігурація через `/etc/network/interfaces` (Debian/Ubuntu)

“`bash

auto bond0

iface bond0 inet static

address 192.168.1.10

netmask 255.255.255.0

gateway 192.168.1.1

bond-slaves eth0 eth1

bond-mode 4

bond-miimon 100

bond-lacp-rate 1

bond-xmit-hash-policy layer3+4

auto eth0

iface eth0 inet manual

bond-master bond0

auto eth1

iface eth1 inet manual

bond-master bond0

“`

Перевірка стану Bond

“`bash

Check bond status and slave states

cat /proc/net/bonding/bond0

Monitor interface statistics

ip -s link show bond0

Check LACP negotiation state (Mode 4)

cat /proc/net/bonding/bond0 | grep -A5 "LACP"

“`

Вивід `/proc/net/bonding/bond0` є найважливішим діагностичним інструментом. Він показує активний підлеглий інтерфейс, стан каналу кожного учасника, статус MII та (для режиму 4) інформацію про партнера LACP.

Network Bonding на виділених серверах та VPS

На фізичних Виділених серверах ви маєте повний контроль як над конфігурацією NIC сервера, так і (зазвичай) над конфігурацією портів комутатора, що робить режим 4 (LACP) природним вибором для виробничих навантажень. Більшість провайдерів центрів обробки даних можуть налаштувати LACP на ваших портах комутатора за запитом.

У середовищах VPS з cPanel мережевий рівень гіпервізора обробляє базовий bonding на рівні хоста. Гостьова VM зазвичай бачить один віртуальний NIC, але хост може запускати bonded фізичні інтерфейси під ним — забезпечуючи резервування прозоро.

При розгортанні GPU-інтенсивних навантажень на інфраструктурі GPU Хостингу network bonding стає критично важливим для достатньо швидкої подачі даних до GPU-вузлів для запобігання I/O-голодуванню. Конвеєри навчання та обслуговування інференсу виграють від сукупної пропускної здатності, яку забезпечує LACP bonding.

Поширені підводні камені та граничні випадки

Конфлікти Spanning Tree Protocol (STP): При додаванні bonded-портів до комутатора STP може тимчасово блокувати порти під час узгодження. Налаштуйте PortFast (або еквівалент) на портах комутатора, щоб запобігти 30-секундним затримкам під час подій підняття каналу.

Невідповідність MTU: Всі підлеглі інтерфейси в bond повинні мати однакові налаштування MTU. Невідповідність спричиняє переривчасту втрату пакетів, яку надзвичайно важко діагностувати. Завжди перевіряйте за допомогою `ip link show` після конфігурації.

Режими таймауту LACP: LACP підтримує режими таймауту «повільний» (30 секунд) та «швидкий» (1 секунда). Завжди використовуйте `lacp-rate fast` (`bond-lacp-rate 1`) у виробничому середовищі. Повільний режим означає, що відмовлений канал може бути видалений з LAG до 90 секунд.

Живе перенесення віртуальних машин: Якщо VM з bonded-інтерфейсом переноситься на інший хост, MAC-адреси bond можуть змінитися залежно від гіпервізора. Це може спричинити застарілі записи в ARP-кеші та короткочасну втрату з’єднання. Попередньо підготуйте безоплатні ARP у ваших скриптах міграції.

Асиметричне хешування: З режимом 4 та хешуванням `layer3+4` трафік від сервера A до сервера B може проходити через eth0, тоді як зворотний трафік від B до A проходить через eth1 на bond сервера B. Це нормально та очікувано — кожен кінцевий вузол незалежно хешує свій вихідний трафік.

Втручання NetworkManager: На системах RHEL/CentOS NetworkManager може заважати вручну налаштованим bond. Або налаштуйте bond через інтерфейс nmcli NetworkManager, або вимкніть NetworkManager для відповідних інтерфейсів за допомогою `NM_CONTROLLED=no` у файлі конфігурації інтерфейсу.

Bonding порівняно з іншими техніками мережевої високої доступності

Network bonding — не єдиний підхід до резервування NIC. Розуміння того, коли використовувати альтернативи, не менш важливе.

MLAG (Multi-Chassis Link Aggregation) заслуговує на особливу увагу: він дозволяє серверу з режимом 4 bonding підключити два NIC до двох фізично окремих комутаторів, обидва з яких беруть участь в одній логічній LAG. Це усуває сам комутатор як єдину точку відмови — рівень резервування, який стандартний LACP з одним комутатором не може забезпечити.

Матриця рішень: вибір правильного режиму Bonding

Використовуйте цю схему для вибору режиму bonding:

Чи контролюєте ви конфігурацію комутатора?

• Ні → Перейдіть до режиму 1, 5 або 6
• Потрібне двонаправлене балансування навантаження? → Режим 6
• Переважно вихідний трафік? → Режим 5
• Чисте перемикання при відмові, максимальна простота? → Режим 1
• Так → Перейдіть до режиму 0, 2 або 4
• Потрібне динамічне узгодження та відповідність найкращим практикам? → Режим 4 (LACP)
• Статична LAG, простіше налаштування? → Режим 2 з хешем layer3+4
• Спеціалізована вимога до broadcast? → Режим 3

Це інтерфейс управління/IPMI? Завжди використовуйте Режим 1. Ніколи не ризикуйте інтерфейсом управління в режимі, що вимагає конфігурації комутатора.

Ви на хмарній або віртуальній платформі? Перевірте, чи підтримує віртуальний комутатор гіпервізора LACP. Якщо ні, Режим 6 забезпечує найкращий баланс розподілу навантаження та сумісності.

Для команд, що керують кількома серверами через Панелі управління VPS, перевірка стану bonding повинна бути частиною стандартного контрольного списку після розгортання поряд з перевіркою SSL через SSL Сертифікати та перевіркою поширення DNS після Реєстрації домену.

Технічний контрольний список ключових висновків

• Завжди встановлюйте `miimon=100` та `downdelay=200 updelay=200` як базові значення для MII-моніторингу у виробничому середовищі
• Використовуйте `xmit_hash_policy=layer3+4` з режимами 2 та 4 для забезпечення розподілу на рівні потоків, а не на рівні MAC
• Перевіряйте `/proc/net/bonding/bond0` одразу після конфігурації — не припускайте, що все працює
• Налаштуйте швидкість LACP на `fast` в режимі 4, щоб скоротити час виявлення відмови з 90 секунд до 3 секунд
• Переконайтеся, що всі підлеглі NIC мають однакові налаштування MTU, швидкості та дуплексу перед додаванням їх до bond
• На виробничих Виділених серверах завжди запитуйте конфігурацію LACP у вашого провайдера центру обробки даних, а не використовуйте статичну LAG
• Явно перевіряйте перемикання при відмові, від’єднуючи один кабель — не припускайте, що конфігурація правильна, поки не перевірите її в умовах відмови
• Документуйте, який фізичний NIC відповідає якому підлеглому інтерфейсу (eth0, eth1) за допомогою `ethtool -i eth0`, щоб уникнути плутанини під час фізичного обслуговування
• Для резервування між комутаторами в критичних середовищах досліджуйте MLAG перед тим, як зупинитися на LACP з одним комутатором

FAQ

Чи подвоює network bonding швидкість завантаження одного файлу?

Ні. Bonding розподіляє трафік між каналами на рівні потоків (або на рівні пакетів у режимі 0). Одне TCP-з’єднання використовує лише один фізичний канал одночасно в більшості режимів. Bonding збільшує сукупну пропускну здатність для кількох одночасних з’єднань, а не швидкість окремого з’єднання.

У чому різниця між режимом 4 bonding (LACP) та статичною LAG?

Статична LAG (використовується режимами 0 та 2) вручну визначає, які порти утворюють групу агрегації без будь-якого узгодження. LACP (режим 4) динамічно узгоджує LAG за допомогою керуючих пакетів, автоматично виявляючи неправильні конфігурації, відмовлені канали та додаючи/видаляючи учасників. LACP є більш надійним та є галузевим стандартом для виробничих розгортань.

Чи можна налаштувати network bonding на VPS?

Це залежить від гіпервізора та хостинг-провайдера. Більшість хмарних VPS-екземплярів представляють гостю один віртуальний NIC, а bonding обробляється на рівні гіпервізора. Деякі провайдери, що пропонують VPS, подібні до bare-metal, або виділені хмарні екземпляри, підтримують bonding на рівні гостя. Уточніть у вашого провайдера перед спробою налаштувати bonding всередині гостя VPS.

Що відбувається з активними з’єднаннями при відмові bonded-каналу?

У режимі 1 (Active-Backup) bond надсилає безоплатний ARP після перемикання, оновлюючи таблиці MAC комутатора. Існуючі TCP-з’єднання відчувають короткочасну паузу (зазвичай менше 300 мс при швидкому MII-моніторингу), але загалом виживають. У режимі 4 LACP виявляє відмову та перерозподіляє потоки на канали, що залишилися — існуючі потоки на відмовленому каналі потребуватимуть повторного встановлення застосунком.

Чому мій bond режиму 4 показує лише один активний підлеглий інтерфейс у `/proc/net/bonding/bond0`?

Найпоширенішою причиною є неправильна конфігурація на стороні комутатора. Перевірте, що порти комутатора налаштовані в одному port channel з увімкненим LACP в активному режимі. Також перевірте, що `lacp-rate` встановлено однаково з обох сторін. Невідповідний ключ LACP або пріоритет системи можуть перешкодити агрегації навіть коли фізичні канали активні.