Различия

Показаны различия между двумя версиями страницы.

--- dpi:dpi_components:platform:dpi_reserve:start [2023/08/30 11:45] – elena.krasnobryzh
+++ dpi:dpi_components:platform:dpi_reserve:start [Дата неизвестна] (текущий) – удалено - внешнее изменение (Дата неизвестна) 127.0.0.1
@@ Строка 1: / Строка 1: @@
-====== Резервирование ======
-{{indexmenu_n>15}}
-===== 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>
-. keepalived привязывается к конкретному интерфейсу, через который идет обмен VRRP-пакетами. Это обычный интерфейс Linux (управляющий, ctl-интерфейс), а не in/out девайс СКАТ. Собственно, именно на этот интерфейс keepalived назначает виртуальный IP-адрес при переходе в режим master. Нам же нужно, чтобы в идеале keepalived не привязывал наш виртуальный IP-адрес на этот интерфейс, а просто вызывал скрипты перевода СКАТ в режим master или backup.
-. Аналогично п.1 - при переводе в master демон keepalived шлет gARP через управляющий интерфейс. Нам также этого не нужно (быть может, это даже вредно).
-. Если п.1 и п.2 нерешаемы в рамках конфигурации keepalived, можно рассмотреть возможность работы keepalived через vlan-интерфейсы, созданные на ctl-интерфейсе. Для всех компьютеров VRRP-группы на их ctl-интерфейсах Linux создаем vlan-интерфейсы с уникальным vlan, выделенном для VRRP, и привязываем keepalived именно к этим vlan-интерфейсам. Тогда пусть keepalived назначает виртуальные IP-адреса на эти vlan-интерфейсы и рассылает gARP через них, - это не должно никому помешать. Нам важно только, чтобы keepalived вовремя вызывал скрипты master/backup.
-. Проверить, как поведут себя коммутаторы, подключенные к СКАТ к in/out девайсам, в vlan/qinq-сетях. Дело в том, что СКАТ рассылает обучающие gARP без всяких VLAN. Распознают ли в этом случае коммутаторы, что трафик нужно переключать с портов СКАТ-1 на порты СКАТ-2 в случае перевода СКАТ-2 в master-режим (а СКАТ-1, соответственно, в backup).

Аккаунт

Настройки

Различия