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

Настройки

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

    • Различия

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

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

    Предыдущая версия справа и слеваПредыдущая версия
    Следующая версия    		Предыдущая версия
    dpi:bras_bng:replication:start [2024/05/20 09:35] – [Описание алгоритма] elena.krasnobryzhdpi:bras_bng:replication:start [Дата неизвестна] (текущий) – удалено - внешнее изменение (Дата неизвестна) 127.0.0.1
    Строка 1: Строка 1:
    -====== Резервирование BRAS L2 в режиме Active-Standby ====== 
    -{{indexmenu_n>12}} 
    -<note>Вебинар по теме: 
    -{{youtube>wCkuTfqoKQc?}}</note> 
    - 
    -Резервирование BRAS в режиме L2 предполагает включение двух СКАТ в один широковещательный L2 домен. 
    -Один в режиме Master, другой в режиме Slave.  
    -Master осуществляет обработку трафика, авторизацию пользователей через PCRF сервер. 
    -Slave не пропускает трафик через себя, интерфейсы DPDK находятся в режиме ожидания трафика (down). Синхронизация информации об абонентах происходит через PCRF сервер. 
    -Slave отслеживает доступность и работоспособность Master, при сбое в работе Slave в автоматическом или ручном режиме активирует (up) DPDK интерфейсы и начинает обрабатывать трафик. 
    -Пример включения и прохождения трафика представлено на схеме. 
    -{{ playground:opt_bras_l2:start:резервирование_bras_l2.png?nolink&400 |}} 
    - 
    -===== Репликация данных авторизации и Синхронизация базы данных нескольких BRAS===== 
    -В СКАТ BRAS состоит из компонент  
    -fastDPI - обработка трафика абонентов. 
    -fastPCRF - интеграция по протоколу Radius между fastDPI и Radius сервером. Один fastPCRF может обслуживать несколько fastDPI серверов. 
    -Применяется следующая схема репликации для согласования данных об абонентах на всех fastDPI-серверах: fastPCRF шлет ответы авторизации и CoA-запросы на все fastDPI серверы, перечисленные в параметрах [[dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup:start|fdpi_server]].  
    -<note important>Отправка параметров авторизации производится через персистентную очередь, так что даже если какой-то из серверов fastDPI был отключен на момент отправки данных, при включении он получит все данные за время своего простоя.</note> 
    - 
    -==== Применение данных на fastDPI ==== 
    -При приеме данных авторизации сервер fastDPI видит, его это был запрос или же это ответ на чужой запрос (для этого в пакете есть специальная метка). Если это ответ на свой запрос, данные применяются "по полной": создается DHCP или PPPoE-сессия, если это был запрос DHCP или PPPoE-авторизации, данные запоминаются в UDR. Если же это ответ на чужой запрос, fastDPI просто запоминает "чужие" данные у себя в UDR. Тем самым при отключении основного fastDPI-сервера и переводе нагрузки на резервный, у резервного fastDPI-сервера в UDR уже будут все свойства абонента - его услуги, полисинг, L2-свойства - MAC-адрес, VLAN и пр. То есть UDR у основного и резервного серверов будут по большому счету согласованы. 
    - 
    - 
    -===== Описание алгоритма ===== 
    -**Концепция резервирования СКАТ — MASTER-SLAVE (L2-BRAS):**\\ 
    -MASTER является активным сервером и обрабатывает трафик во время нормальной работы сети. SLAVE в свою очередь находится в состоянии ожидания с выключенными интерфейсами и активно опрашивает состояние MASTER и в случае проблем на нем включается в работу. 
    - 
    -**Нормальная работа сети:**\\  
    -Через MASTER проходит обработка всего трафика, авторизация и т.д, SLAVE в обработке трафика не участвует, но через mgmt интерфейс опрашивает состояние MASTER. Происходит несколько проверок состояния: 
    -  * Проверка, что процесс fastDPI запущен; 
    -  * Проверка, что процесс fastDPI работает стабильно и не находится в состоянии циклического рестарта; 
    -  * //Опционально// — проверка состояния интерфейсов. В зависимости от схемы подключения такая проверка может быть не нужна, поэтому данная проверка опциональна. 
    - 
    -Если все проверки прошли успешно, то SLAVE остается в режиме ожидания и не предпринимает никаких действий.\\ 
    -В случае обнаружения ошибки SLAVE берет на себя роль MASTER. 
    - 
    -**Переключение MASTER→SLAVE:**\\ 
    -При обнаружении на MASTER ошибки SLAVE начинает обрабатывать трафик самостоятельно, для этого отправляется команда на отключение MASTER, отключение интерфейсов СКАТ и остановки процесса fastDPI. В это же время SLAVE включает свои интерфейсы. Следует отметить, что автоматического переключения обратно не реализовано, так как необходима проверка инженером что проблема на основном сервере устранена и можно переключать траффик обратно. 
    - 
    -**Переключение SLAVE→MASTER:**\\ 
    -После устранения проблем на основном сервере необходимо выключить интерфейсы резервного сервера, запустить обработку трафика основным сервером и включить сервис резервирования на SLAVE.