Безотказная работа сети (network bonding) в Redhat - реализация(продолжение)

После статьи Обеспечение безотказной работы сети в RedHat Linux (bonding) для нескольких IP сетей прошло достаточно много времени, а тут мне (точнее начальству) приспичило сделать супер безотказную сетку :)

По "свежим следам", пока помню, опишу, т.к. задача была чуть более сложная, чем описано ранее, и как результат, проявились отличия.

Итак, постановка задачи:

• Имеем бокс с четырмя сетевыми картами подключенные к двум свичам


• Имеем две сети (два VLAN'а)


• Задача: пока жив хоть один свич и один порт, все должно работать :)

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


Первые грабли проявились, когда задачу пришлось уточнить. У нас четыре сетевушки и два свича. Вполне логично было бы настроить так, чтобы трафик шел в разные сетевые карты и на разные свичи, распределив таким образом нагрузку.

Как несложно найти в документации на модуль bonding делается это параметром модуляprimary= Вот тут-то и поджидал подводный комень. Параметр, записанный в /etc/modprobe.conf, отказался восприниматься для второго интерфейса bond1 ! Попытка поднять через modprobe.conf второй модуль bonding1 тоже не прошла! Как оказалось (согласно информации в Сети), это особенности сборки RedHat. Надо действовать по-другому.

Во-первых, немного меняем содержимое /etc/modprobe.conf. Теперь оно будет вот таким:
alias bond0 bonding
alias bond1 bonding
options bonding max_bonds=2 miimon=100

Как видим, здесь два отличия от предыдущего варианта. первое, самое главное: прописывается options для bonding, а не bondX. Во вторых, параметров модулю передается самый минимум. Все остальное будет в другом месте.

Про настройку физических интерфейсов и VLAN я повторяться не буду, все уже описано ранее. Оговорюсь только, что для четырех интерфейсов придется создавать больше файлов настройки, по два (один файл - один VLAN), т.е. получим восемь файлов.

Зато изменения возникнут в настройке логических интерфейсов bondX. Вот, к примеру, содержимое ifcfg-bond0:
# Main virtual network device
DEVICE=bond0
IPADDR=192.168.1.2
NETWORK=192.168.1.0
NETMASK=255.255.255.0
USERCTL=no
BOOTPROTO=static
ONBOOT=yes
BONDING_OPTS="downdelay=0 updelay=60000 mode=active-backup primary=eth0.10 fail_over_mac=active"

ifcfg-bond1 отличается только IP адресом и именем интерфейса в параметре primary

Стоит обратить внимание на некоторое отличие от варианта, описанного в предыдущей статье. Появилась переменная BONDING_OPTS, в которую помещаются дополнительные параметры для модуля bonding. тут стоит остановиться подробнее. параметры подобраны не просто так :)

• downdelay=0 значит, что переключаемся сразу, как видим проблему (без задержки)


• updelay=60000 задержка при переключении назад после восстановления работоспособности порта. Значение в 60 сек вычислено экспериментальным путем для нашего оборудования и может отличаться для разных случаев. В процессе проведения тестирования оказалось, что после подключения порта нужно некоторое время (от 30 до 60 сек) на то, чтобы полностью все заработало. На эту проблему я обращал внимание в одной из предыдущих статей, и, вот, нашел решение


• mode=active-backup режим, когда активна только одна сетевая карта, вторая в горячем резерве


• primary=eth0.10 основной интерфейс (по умолчанию), через которуй будет идти трафик. Обращаю внимание - указан логический интерфейс, созданный для VLAN, а не физический! Т.е. один из тех интерфейсов, которые прописаны ка SLAVE для bondX


• fail_over_mac=active в случае переключения использовать "родной" MAC-адрес сетевой карты и не пытаться его переопределять. Єто оказался единственній подошедщий мне режим. Почему-то follow у меня нормально не заработал, а жаль :(

Собственно это все ключевые моменты. Тестирование показало, что переключение active-standby и обратно происходит чисто, без обрывов и незаметно для приложений.