====== Резервирование BRAS Active-Standby (Master-Backup) ====== {{indexmenu_n>12}} ===== Описание алгоритма переключения для BRAS L2 (DHCP, Static IP) ===== * Резервирование BRAS L2 для IPoE (DHCP и Static IP) рекомендуется по схеме Active-Standby, что предполагает включение двух СКАТ BRAS в один широковещательный L2 домен: Один в режиме Master, другой [[dpi:licensing#резервная_лицензия_скат|в режиме Backup (горячий резерв)]]. * Master является активным сервером и обрабатывает трафик во время нормальной работы сети. Backup находится в состоянии ожидания и не пропускает трафик через себя, интерфейсы DPDK в сторону абонентов (IN порты) административно выключены (down). * Backup сервер осуществляет мониторинг работы Master сервера с помощью скрипта (heartbeat) через выделенные порты управления. При регистрации сбоя Master сервера Backup сервер в автоматическом режиме активирует (up) DPDK интерфейсы в сторону абонентов (IN порты) и начинает обрабатывать трафик. * Реализовано одиночное переключение трафика на Backup сервер и остановка Master сервера с целью избежать множественного перевода трафика и влияния на сеть. Обратное переключение трафика на Master осуществляется сетевым администратором в ручном режиме. * Для корректной работы необходимо, чтобы все профили услуг были идентично сконфигурированы на Master и Backup сервере, рекомендуем использовать скрипт синхронизации профилей. * Необходимо обратить внимание, что СКАТ BRAS поддерживает динамическую (OSPF, BGP) и статическую маршрутизацию. В случае динамической маршрутизации для Static IP абонентов с публичными IP адресами анонс изменится автоматически при переключении на Backup сервер, для абонентов с приватными адресами будет применен профиль NAT, под тем же именем, но из другого публичного пула адресов, который заведен на Backup сервере. {{ :dpi:bras_bng:bras_replication.png?nolink&900 |}} ===== Скрипт мониторинга состояния работы Master сервера ===== Скрипт должен быть установлен на Backup сервере, где он работает в непрерывном цикле, мониторя состояние Master сервера через SSH.\\ Используется **4 проверки** для подтверждения нормальной работы Master сервера: - Сервер доступен по сети (pingcheck) - Процесс fastDPI присутствует - PID процесса fastDPI не изменился (нет неконтролируемого перезапуска процесса) - Состояние ссылки на основном fastDPI не изменилось (необязательная проверка). Эта проверка отключена по умолчанию, так как может быть не нужна в некоторых топологиях **Процесс установки скрипта:** - Скачать все файлы из {{:dpi:bras_bng:replication:reservation_script.zip|архива}} на целевой резервный сервер - Настроить IP-адрес Master сервера в скрипте ''SRS.sh'' - Создать пару SSH-ключей на Backup сервере с помощью команды ssh-keygen -t ed25519 - Создать нового пользователя с правами sudo на Master сервере - Скопировать приватные SSH-ключи с Backup сервера в файл ''authorized_keys'' нового аккаунта на Master сервере - Добавить права на выполнение установочного скрипта с помощью команды chmod +x install.sh - Запустить install.sh **Управление сервисом:** - Запуск сервиса: systemctl start fastsrs - Проверка статуса сервиса: systemctl status fastsrs - Остановка сервиса: systemctl stop fastsrs - Проверка логов сервиса: journalctl -u fastsrs =====Скрипт синхронизации профилей услуг===== Скрипт синхронизирует профили услуг [[dpi:dpi_options:opt_filtration:filtration_ctrl#активация_управления_услуги_фильтрации_на_уровне_абонентов_-_subscriber_management|4 (фильтрация по черному списку)]], [[dpi:dpi_options:opt_capture:capt_mgmt#управление_профилем_по_умолчанию_5_услуга|5 (белый список и Captive Portal)]], [[dpi:dpi_options:opt_shaping:shaping_session|18 (полисинг по сессии и переопределение классов трафика)]] и [[dpi:dpi_components:platform:subscriber_management:policing_mng|полисинга]] между Master и Backup серверами.\\ Скрипт запускается на Master сервере, профили услуг на Backup сервере будут приведены к виду профилей на Master сервере. Перенос профилей осуществляется с помощью команд ''fdpi_ctrl'' и удаленного доступа по ssh. Требования к системе: * SSH * Bash * Jq * установенный СКАТ * Rsync Логика работы скрипта:\\ Скрипт получает текущий профиль услуги от Master сервера и затем отправляет его на указанный Backup сервер. Затем скрипт подключается к Backup серверу и получает данные для профилей, присутствующих на Master сервере, получает данные профиля на Backup сервере, сопоставляет их и удаляет профили, отсутствующие на Master сервере. ====Установка и управление==== - Настроить авторизацию через сертификат: создать сертификат на Master сервере с помощью ''ssh-keygen -t ed25519'', проще всего использовать для авторизации учетную запись root. - Загрузить {{:dpi:bras_bng:profile_sync.sh|скрипт}} на Master сервер и поместить его в каталог ''/usr/local/bin/'' - Добавить разрешения для скрипта с помощью команды chmod +x /usr/local/bin/profile_sync.sh - Настроить пользователя и IP Backup сервера внутри скрипта. Пользователь должен иметь возможность записи в каталог ''/etc/dpi,'' самый простой вариант — использовать пользователя root. Также можно настроить другого пользователя с соответствующими правами. - Настроить cron для выполнения скрипта с желаемыми интервалами **(опционально)**:crontab -u root -e 0 * * * * * /bin/bash /usr/local/bin/profile_sync.sh - Добавить псевдоним bash для запуска скрипта по желанию:echo "alias dpi_sync='/bin/bash /usr/local/bin/profile_sync.sh'">> ~/.bashrc - Создать каталог ''/etc/dpi/service18'' и сохранить в нем все файлы service 18. Работа скрипта:\\ Скрипт запускается crontab с указанными интервалами или вручную с помощью команды ''dpi_sync''. Обратите внимание, что если профиль сервиса применен к абоненту, он не будет удален. Также обратите внимание, что любые файлы, не сохраненные в папке ''service18'', не будут перенесены на Backup сервер, и, таким образом, синхронизированный профиль услуги 18 не будет работать. При отсутствии alias ''dpi_sync'' cкрипт следует запускать через ''sudo bash /usr/local/bin/profile_sync.sh''.