| Предыдущая версия справа и слеваПредыдущая версияСледующая версия | Предыдущая версия |
| dpi:dpi_components:platform:dpi_reserve:start [2023/11/09 12:57] – elena.krasnobryzh | dpi:dpi_components:platform:dpi_reserve:start [Дата неизвестна] (текущий) – удалено - внешнее изменение (Дата неизвестна) 127.0.0.1 |
|---|
| ====== Резервирование ====== | |
| {{indexmenu_n>13}} | |
| |
| ===== Active/Backup (VRRP) ===== | |
| |
| <note important>Это предварительное описание для версии 10.3 (предположительно). Его надо дополнить описанием конфигурации keepalived после тестов</note> | |
| |
| Поддержка [[https://ru.wikipedia.org/wiki/VRRP|VRRP]] реализована в СКАТ при помощи Linux-демона [[https://linux.die.net/man/8/keepalived|keepalived]]. | |
| Собственно VRRP-протокол реализует демон, в котором конфигурируются скрипты вызова CLI-команд для перевода СКАТ в режим master или backup. | |
| |
| В режиме master доступна вся функциональность СКАТ, в режиме backup СКАТ работает только как мост in_dev <-> out_dev, никакие пакеты сам СКАТ не эмитирует. Предполагается, что в режиме backup на СКАТ не должно приходить вообще никакого трафика. Но есть подозрение, что какие-то служебные L2 протоколы, необходимые для функционирования сети оператора, все же могут поступать на СКАТ в режиме backup, - именно поэтому режим прозрачного моста остается включенным в режиме backup. | |
| |
| Поддержка VRRP включается в СКАТ конфигурационным параметром ''vrrp_enable'' в fastdpi.conf: | |
| <code> | |
| # [hot] Флаг включения поддержки VRRP | |
| # 0 - выключено (default) | |
| # 1 - включено | |
| vrrp_enable=1 | |
| </code> | |
| По умолчанию поддержка 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-командами: | |
| <code> | |
| # перевести СКАТ в режим master | |
| # эту команду должен вызывать keepalived-скрипт notify_master | |
| fdpi_cli vrrp set master | |
| |
| # перевести СКАТ в режим backup | |
| # эту команду должен вызывать keepalived-скрипт notify_backup | |
| fdpi_cli vrrp set backup | |
| </code> | |
| СКАТ всегда стартует в режиме master. Предполагается, что сразу после старта демон keepalived увидит, что участник VRRP-группы ожил, и вызовет соответствующий скрипт. То есть сразу после старта СКАТ должен быть явно переведен в режим master или backup. | |
| <note warning>Постоянная работа двух или более экземпляров СКАТ одновременно в режиме master является ошибкой. Master должен быть только один.</note> | |
| |
| При переводе СКАТ в режим 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: | |
| <code> | |
| # Параметры отправки 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 | |
| </code> | |
| |
| Текущий режим работы СКАТ можно узнать CLI-командой | |
| <code> | |
| fdpi_cli vrrp stat | |
| </code> | |
| |
| ===== Открытые вопросы ===== | |
| <note warning>Данный раздел следует удалить после полноценного тестирования. Ответы на вопросы данного раздела в виде рекомендаций по типовой конфигурации keepalived должны быть в теле основного раздела выше</note> | |
| |
| 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). | |
