Резервирование BRAS Active-Standby (Master-Backup) [Документация VAS Experts]
Документация VAS Experts Документация VAS Experts-mobile
in

Настройки

  • Показать страницу
  • История страницы
  • Экспорт в PDF
  • Свернуть / развернуть всё
  • Ссылки сюда
  • Показать страницу
  • История страницы
  • Экспорт в PDF
  • Свернуть / развернуть всё
  • Ссылки сюда

    • Различия

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

    Ссылка на это сравнение

    Следующая версия    		Предыдущая версия
    dpi:bras_bng:replication [2024/09/26 15:29] – создано - внешнее изменение 127.0.0.1dpi:bras_bng:replication [2025/09/29 09:05] (текущий) – [Описание алгоритма переключения для BRAS L2 (DHCP, Static IP)] atereschenko
    Строка 1: Строка 1:
    -====== Резервирование BRAS L2 в режиме Active-Standby ======+====== Резервирование BRAS Active-Standby (Master-Backup) ======
     {{indexmenu_n>12}} {{indexmenu_n>12}}
    -<note>Вебинар по теме: +===== Описание алгоритма переключения для BRAS L2 (DHCP, Static IP) ===== 
    -{{youtube>wCkuTfqoKQc?}}</note>+  * Резервирование 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 сервере. 
      
    -Резервирование BRAS в режиме L2 предполагает включение двух СКАТ в один широковещательный L2 домен. +{{ :dpi:bras_bng:bras_replication.png?nolink&900 |}}
    -Один в режиме Master, другой в режиме Slave.  +
    -Master осуществляет обработку трафика, авторизацию пользователей через PCRF сервер. +
    -Slave не пропускает трафик через себя, интерфейсы DPDK находятся в режиме ожидания трафика (down). Синхронизация информации об абонентах происходит через PCRF сервер. +
    -Slave отслеживает доступность и работоспособность Master, при сбое в работе Slave в автоматическом или ручном режиме активирует (up) DPDK интерфейсы и начинает обрабатывать трафик. +
    -Пример включения и прохождения трафика представлено на схеме. +
    -{{ :dpi:bras_bng:replication:bras_l2_reservation.png?nolink&750 |}}+
      
    -===== Репликация данных авторизации и Синхронизация базы данных нескольких BRAS===== +===== Скрипт мониторинга состояния работы Master сервера ===== 
    -В СКАТ BRAS состоит из компонент  +Скрипт должен быть установлен на Backup сервере, где он работает в непрерывном цикле, мониторя состояние Master сервера через SSH.\\ 
    -  * fastDPI - обработка трафика абонентов. +Используется **4 проверки** для подтверждения нормальной работы Master сервера: 
    -  * fastPCRF - интеграция по протоколу Radius между fastDPI и Radius сервером. Один fastPCRF может обслуживать несколько fastDPI серверов. +
    - +
    -Возможны две схемы интеграции: +
    -  - Два fastDPI и один вынесенный fastPCRF и  - есть возможность синхронизировать данные UDR двух fastDPI +
    -  - На каждом сервере fastDPI свой fastPCRF - нет возможности синхронизировать данные UDR двух fastDPI, после переключения идет наполнение UDR из ответов от Radius сервера. +
    - +
    -Для первого варианта применяется следующая схема репликации для согласования данных об абонентах на всех fastDPI-серверах: fastPCRF шлет ответы авторизации и CoA-запросы на все fastDPI серверы, перечисленные в параметрах [[dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup|fdpi_server]].  +
    -<note important>Отправка параметров авторизации производится через персистентную очередь, так что даже если какой-то из серверов fastDPI был отключен на момент отправки данных, при включении он получит все данные за время своего простоя.</note> +
    - +
    -==== Применение данных на fastDPI при синхронизации UDR==== +
    -При приеме данных авторизации сервер fastDPI видит, его это был запрос или же это ответ на чужой запрос (для этого в пакете есть специальная метка). Если это ответ на свой запрос, данные применяются "по полной": создается DHCP или PPPoE-сессия, если это был запрос DHCP или PPPoE-авторизации, данные запоминаются в UDR. Если же это ответ на чужой запрос, fastDPI просто запоминает "чужие" данные у себя в UDR. Тем самым при отключении основного fastDPI-сервера и переводе нагрузки на резервный, у резервного fastDPI-сервера в UDR уже будут все свойства абонента - его услуги, полисинг, L2-свойства - MAC-адрес, VLAN и пр. То есть UDR у основного и резервного серверов будут по большому счету согласованы. Абонентская сессия на резервном fastDPI будет в статусе неизвестен (unknown) и после переключения трафика по первому пакету будет запущен процесс авторизации абонента. +
    - +
    - +
    -===== Описание алгоритма переключения для BRAS L2===== +
    -**Концепция резервирования СКАТ — MASTER-SLAVE:**\\ +
    -MASTER является активным сервером и обрабатывает трафик во время нормальной работы сети. SLAVE в свою очередь находится в состоянии ожидания с выключенными интерфейсами и активно опрашивает состояние MASTER и в случае проблем на нем включается в работу. +
    - +
    -**Нормальная работа сети:**\\  +
    -Через MASTER проходит обработка всего трафика, авторизация и т.д, SLAVE в обработке трафика не участвует, но через mgmt интерфейс опрашивает состояние MASTER. Происходит несколько проверок состояния: +
    -  * Проверка, что процесс fastDPI запущен; +
    -  * Проверка, что процесс fastDPI работает стабильно и не находится в состоянии циклического рестарта; +
    -  * //Опционально// — проверка состояния интерфейсов. В зависимости от схемы подключения такая проверка может быть не нужна, поэтому данная проверка опциональна. +
    - +
    -Если все проверки прошли успешно, то SLAVE остается в режиме ожидания и не предпринимает никаких действий.\\ +
    -В случае обнаружения ошибки SLAVE берет на себя роль MASTER. +
    - +
    -**Переключение MASTER→SLAVE:**\\ +
    -При обнаружении на MASTER ошибки SLAVE начинает обрабатывать трафик самостоятельно, для этого отправляется команда на отключение MASTER, отключение интерфейсов СКАТ и остановки процесса fastDPI. В это же время SLAVE включает свои интерфейсы. Следует отметить, что автоматического переключения обратно не реализовано, так как необходима проверка инженером что проблема на основном сервере устранена и можно переключать траффик обратно. +
    - +
    -**Переключение SLAVE→MASTER:**\\ +
    -После устранения проблем на основном сервере необходимо выключить интерфейсы резервного сервера, запустить обработку трафика основным сервером и включить сервис резервирования на SLAVE.  +
    - +
    -===== Скрипт для активного резервирования fastDPI===== +
    -Скрипт должен быть установлен на резервном fastDPI, где он работает в непрерывном цикле, мониторя состояние основного fastDPI через SSH.\\ +
    -Этот скрипт использует **4 проверки** для подтверждения того, что основной fastDPI работает: +
       - Сервер доступен по сети (pingcheck)   - Сервер доступен по сети (pingcheck)
       - Процесс fastDPI присутствует    - Процесс fastDPI присутствует 
       - PID процесса fastDPI не изменился (нет неконтролируемого перезапуска процесса)   - PID процесса fastDPI не изменился (нет неконтролируемого перезапуска процесса)
    -  - Состояние ссылки на основном fastDPI не изменилось (необязательная проверка). Эта проверка отключена по умолчанию, так как может быть не нужна в некоторых топологиях.+  - Состояние ссылки на основном fastDPI не изменилось (необязательная проверка). Эта проверка отключена по умолчанию, так как может быть не нужна в некоторых топологиях
      
    -**Процесс установки:** +**Процесс установки скрипта:** 
    -  - Скачать все файлы из {{:dpi:bras_bng:replication:reservation_script.zip|архива}} на целевой резервный сервер. +  - Скачать все файлы из {{:dpi:bras_bng:replication:reservation_script.zip|архива}} на целевой резервный сервер 
    -  - Настроить IP-адрес основного сервера в скрипте ''SRS.sh''. +  - Настроить IP-адрес Master сервера в скрипте ''SRS.sh'' 
    -  - Создать пару SSH-ключей на резервном сервере с помощью команды <code bash>ssh-keygen -t ed25519</code> +  - Создать пару SSH-ключей на Backup сервере с помощью команды <code bash>ssh-keygen -t ed25519</code> 
    -  - Создать нового пользователя с правами sudo на основном сервере. +  - Создать нового пользователя с правами sudo на Master сервере 
    -  - Скопировать приватные SSH-ключи с резервного сервера в файл ''authorized_keys'' нового аккаунта на основном сервере.+  - Скопировать приватные SSH-ключи с Backup сервера в файл ''authorized_keys'' нового аккаунта на Master сервере
       - Добавить права на выполнение установочного скрипта с помощью команды <code bash>chmod +x install.sh</code>   - Добавить права на выполнение установочного скрипта с помощью команды <code bash>chmod +x install.sh</code>
    -  - Запустить ''install.sh''.+  - Запустить <code bash>install.sh</code>
      
     **Управление сервисом:** **Управление сервисом:**
    Строка 69: Строка 33:
       - Остановка сервиса: <code bash>systemctl stop fastsrs</code>   - Остановка сервиса: <code bash>systemctl stop fastsrs</code>
       - Проверка логов сервиса: <code bash>journalctl -u fastsrs</code>   - Проверка логов сервиса: <code bash>journalctl -u fastsrs</code>
     +
     +=====Скрипт синхронизации профилей услуг=====
     +Скрипт синхронизирует профили услуг [[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/''
     +  - Добавить разрешения для скрипта с помощью команды <code bash>chmod +x /usr/local/bin/profile_sync.sh</code>
     +  - Настроить пользователя и IP Backup сервера внутри скрипта. Пользователь должен иметь возможность записи в каталог ''/etc/dpi,'' самый простой вариант — использовать пользователя root. Также можно настроить другого пользователя с соответствующими правами.
     +  - Настроить cron для выполнения скрипта с желаемыми интервалами **(опционально)**:<code bash>crontab -u root -e
     +0 * * * * * /bin/bash /usr/local/bin/profile_sync.sh</code>
     +  - Добавить псевдоним bash для запуска скрипта по желанию:<code bash>echo "alias dpi_sync='/bin/bash /usr/local/bin/profile_sync.sh'">> ~/.bashrc</code>
     +  - Создать каталог ''/etc/dpi/service18'' и сохранить в нем все файлы service 18.
     +
     +Работа скрипта:\\
     +Скрипт запускается crontab с указанными интервалами или вручную с помощью команды ''dpi_sync''.
     +
     +Обратите внимание, что если профиль сервиса применен к абоненту, он не будет удален. Также обратите внимание, что любые файлы, не сохраненные в папке ''service18'', не будут перенесены на Backup сервер, и, таким образом, синхронизированный профиль услуги 18 не будет работать. При отсутствии alias ''dpi_sync'' cкрипт следует запускать через ''sudo bash /usr/local/bin/profile_sync.sh''.