Резервирование Active/Backup (VRRP)

Это предварительное описание для версии 10.3 (предположительно). Его надо дополнить описанием конфигурации keepalived после тестов

Поддержка VRRP реализована в СКАТ при помощи Linux-демона keepalived. Собственно VRRP-протокол реализует демон, в котором конфигурируются скрипты вызова CLI-команд для перевода СКАТ в режим master или backup.

В режиме master доступна вся функциональность СКАТ, в режиме backup СКАТ работает только как мост in_dev ↔ out_dev, никакие пакеты сам СКАТ не эмитирует. Предполагается, что в режиме backup на СКАТ не должно приходить вообще никакого трафика. Но есть подозрение, что какие-то служебные L2 протоколы, необходимые для функционирования сети оператора, все же могут поступать на СКАТ в режиме backup, - именно поэтому режим прозрачного моста остается включенным в режиме backup.

Поддержка VRRP включается в СКАТ конфигурационным параметром vrrp_enable в fastdpi.conf:

    # [hot] Флаг включения поддержки VRRP
    # 0 - выключено (default)
    # 1 - включено
vrrp_enable=1

По умолчанию поддержка VRRP отключена.

Все СКАТ, входящие в одну VRRP-группу, должны иметь одинаковую конфигурацию. В частности, следующие параметры обязательно должны быть заданы и быть одинаковыми во всех СКАТ VRRP-группы, так как они задают виртуальные MAC и IP-адреса:

bras_arp_mac - виртуальный MAC-адрес СКАТ
bras_arp_ip - виртуальный IP-адрес СКАТ

Если включена поддержка IPv6, то также должны быть заданы и быть одинаковыми параметры bras_ipv6_link_local и bras_ipv6_address - виртуальные link-local и глобальный IPv6-адреса соответственно.

Перевод СКАТ в режим master/backup производится CLI-командами:

   # перевести СКАТ в режим master
   # эту команду должен вызывать keepalived-скрипт notify_master
fdpi_cli vrrp set master

   # перевести СКАТ в режим backup
   # эту команду должен вызывать keepalived-скрипт notify_backup
fdpi_cli vrrp set backup

СКАТ всегда стартует в режиме master. Предполагается, что сразу после старта демон keepalived увидит, что участник VRRP-группы ожил, и вызовет соответствующий скрипт. То есть сразу после старта СКАТ должен быть явно переведен в режим master или backup.

Постоянная работа двух или более экземпляров СКАТ одновременно в режиме master является ошибкой. Master должен быть только один.

При переводе СКАТ в режим master CLI-командой fdpi_cli vrrp set master СКАТ посылает gARP (gratuitous ARP) на все свои in и out-интерфейсы, чтобы сообщить коммутаторам, что виртуальный MAC и IP адреса (bras_arp_mac и bras_arp_ip соответственно) теперь находятся на портах коммутаторов, к которым подключен данный экземпляр СКАТ. Получив такой gARP, коммутатор должен понять, что виртуальный MAC/IP-адрес СКАТ теперь находится на данном порту, и переключить весь трафик на этот СКАТ (в этот порт). Число gARP-оповещений и интервал между ними регулируются следующими параметрами fastdpi.conf:

    # Параметры отправки gratuitous ARP при переходе в master-режим
    # gratuitous ARP отправляются на все интерфейсы СКАТа
    # На каждый интерфейс отправляется vrrp_arp_count gratuitous ARP пакетов
    # с интервалом между пакетами vrrp_arp_timeout секунд
    #
    # [hot] Тайм-аут между отправками, секунд (default=1)
#vrrp_arp_timeout=1
    # [hot] Число повторных отправок, default=10
#vrrp_arp_count=10

Текущий режим работы СКАТ можно узнать CLI-командой

fdpi_cli vrrp stat

Открытые вопросы

Данный раздел следует удалить после полноценного тестирования. Ответы на вопросы данного раздела в виде рекомендаций по типовой конфигурации keepalived должны быть в теле основного раздела выше

1. keepalived привязывается к конкретному интерфейсу, через который идет обмен VRRP-пакетами. Это обычный интерфейс Linux (управляющий, ctl-интерфейс), а не in/out девайс СКАТ. Собственно, именно на этот интерфейс keepalived назначает виртуальный IP-адрес при переходе в режим master. Нам же нужно, чтобы в идеале keepalived не привязывал наш виртуальный IP-адрес на этот интерфейс, а просто вызывал скрипты перевода СКАТ в режим master или backup.

2. Аналогично п.1 - при переводе в master демон keepalived шлет gARP через управляющий интерфейс. Нам также этого не нужно (быть может, это даже вредно).

3. Если п.1 и п.2 нерешаемы в рамках конфигурации keepalived, можно рассмотреть возможность работы keepalived через vlan-интерфейсы, созданные на ctl-интерфейсе. Для всех компьютеров VRRP-группы на их ctl-интерфейсах Linux создаем vlan-интерфейсы с уникальным vlan, выделенном для VRRP, и привязываем keepalived именно к этим vlan-интерфейсам. Тогда пусть keepalived назначает виртуальные IP-адреса на эти vlan-интерфейсы и рассылает gARP через них, - это не должно никому помешать. Нам важно только, чтобы keepalived вовремя вызывал скрипты master/backup.

4. Проверить, как поведут себя коммутаторы, подключенные к СКАТ к in/out девайсам, в vlan/qinq-сетях. Дело в том, что СКАТ рассылает обучающие gARP без всяких VLAN. Распознают ли в этом случае коммутаторы, что трафик нужно переключать с портов СКАТ-1 на порты СКАТ-2 в случае перевода СКАТ-2 в master-режим (а СКАТ-1, соответственно, в backup).