Различия

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

--- dpi:bras_bng:replication [2024/10/25 11:04] – elena.krasnobryzh
+++ dpi: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}}
-<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)
   - Процесс 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>
-  - Запустить ''install.sh''.
+  - Запустить <code bash>install.sh</code>
 **Управление сервисом:**
@@ Строка 71: / Строка 35: @@
 =====Скрипт синхронизации профилей услуг=====
-Скрипт синхронизирует профили услуг 4, 5, 18 и полисинга между двумя DPI. Скрипт запускается на основном DPI, профили услуг на резервном DPI будут приведены к виду профилей на основном DPI. Перенос профилей осуществляется с помощью команд ''fdpi_ctrl'' и удаленного доступа по ssh.
+Скрипт синхронизирует профили услуг [[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
+  * SSH
   * Bash
   * Jq
-  * СКАТ DPI
+  * установенный СКАТ
   * Rsync
-Логика скрипта:\\
+Логика работы скрипта:\\
-Скрипт получает текущий профиль услуги от главного устройства и затем отправляет его на указанный удаленный DPI. Затем скрипт подключается к удаленному DPI и получает данные для профилей, присутствующих на удаленном DPI, получает данные профиля на текущем DPI, сопоставляет их и удаляет профили, отсутствующие на основном DPI.
+Скрипт получает текущий профиль услуги от Master сервера и затем отправляет его на указанный Backup сервер. Затем скрипт подключается к Backup серверу и получает данные для профилей, присутствующих на Master сервере, получает данные профиля на Backup сервере, сопоставляет их и удаляет профили, отсутствующие на Master сервере.
 ====Установка и управление====
-  - Для установки этого скрипта сначала настройте авторизацию через сертификат. Создайте сертификат на главном сервере с помощью ssh-keygen -t ed25519,  проще всего использовать для авторизации учетную запись root.
+  - Настроить авторизацию через сертификат: создать сертификат на Master сервере с помощью ''ssh-keygen -t ed25519'',  проще всего использовать для авторизации учетную запись root.
-  - Загрузите скрипт на главный сервер и поместите его в каталог /usr/local/bin/
+  - Загрузить {{:dpi:bras_bng:profile_sync.sh|скрипт}} на Master сервер и поместить его в каталог ''/usr/local/bin/''
-  - Добавьте разрешения для скрипта с помощью команды chmod +x /usr/local/bin/profile_sync.sh
+  - Добавить разрешения для скрипта с помощью команды <code bash>chmod +x /usr/local/bin/profile_sync.sh</code>
-  - Настройте пользователя и ip удаленного сервера внутри скрипта. Пользователь должен иметь возможность записи в каталог /etc/dpi, самый простой вариант — использовать пользователя root, вы также можете настроить другого пользователя с соответствующими правами.
+  - Настроить пользователя и IP Backup сервера внутри скрипта. Пользователь должен иметь возможность записи в каталог ''/etc/dpi,'' самый простой вариант — использовать пользователя root. Также можно настроить другого пользователя с соответствующими правами.
-  - Настройте cron для выполнения скрипта с желаемыми интервалами(опционально):
+  - Настроить cron для выполнения скрипта с желаемыми интервалами **(опционально)**:<code bash>crontab -u root -e
-crontab -u root -e
+* * * * * /bin/bash /usr/local/bin/profile_sync.sh</code>
-* * * * * /bin/bash /usr/local/bin/profile_sync.sh
+  - Добавить псевдоним bash для запуска скрипта по желанию:<code bash>echo "alias dpi_sync='/bin/bash /usr/local/bin/profile_sync.sh'">> ~/.bashrc</code>
-. Добавьте псевдоним bash для запуска скрипта по желанию:
+  - Создать каталог ''/etc/dpi/service18'' и сохранить в нем все файлы service 18.
-echo "alias dpi_sync='/bin/bash /usr/local/bin/profile_sync.sh'">> ~/.bashrc
-  - Создайте каталог /etc/dpi/service18 и сохраните в нем все файлы service 18.
-Работа:\\
-Скрипт запускается crontab с указанными интервалами или вручную с помощью команды ''dpi_sync''.\\
-Обратите внимание, что если профиль сервиса применен к абоненту, он не будет удален. Также обратите внимание, что любые файлы, не сохраненные в папке ''service18'', не будут перенесены на удаленный DPI, и, таким образом, синхронизированный профиль услуги 18 не будет работать. При отсутствии alias ''dpi_sync'' cкрипт следует запускать через ''sudo bash /usr/local/bin/profile_sync.sh''.
+Работа скрипта:\\
+Скрипт запускается crontab с указанными интервалами или вручную с помощью команды ''dpi_sync''.
+Обратите внимание, что если профиль сервиса применен к абоненту, он не будет удален. Также обратите внимание, что любые файлы, не сохраненные в папке ''service18'', не будут перенесены на Backup сервер, и, таким образом, синхронизированный профиль услуги 18 не будет работать. При отсутствии alias ''dpi_sync'' cкрипт следует запускать через ''sudo bash /usr/local/bin/profile_sync.sh''.

Аккаунт

Настройки

Различия

Различия

Что вы хотели найти?