# 21. Балансировщик: конфигурация [← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) --- Настройка балансировщика (EcoFilter Balancer) начинается после установки прошивки и конфигурации сегмента управления. В отличие от фильтра, на балансировщике **нет дефолтной конфигурации** — все секции (порты, линки, группы балансировки, фильтры) необходимо создавать вручную. ## 21.1. CLI: операционный режим / конфигурационный режим (`edit`) CLI балансировщика, как и у фильтра, имеет **два режима** работы: | Режим | Переход | Назначение | | -------------------- | -------------------- | ----------------------------------------- | | **Операционный** | по умолчанию | Просмотр информации: команды `show` | | **Конфигурационный** | команда **`edit`** | Изменение всех настроек устройства | > **Отличие от фильтра:** на фильтре для перехода в конфигурационный режим используется команда `config`, а на балансировщике — **`edit`**. ### 21.1.1. Интерфейс похож на Juniper CLI Интерфейс командной строки балансировщика **очень похож на CLI Juniper**. Настройки задаются с помощью команды `set`: ```text set <путь> <параметр> <значение> ``` Для тех, кто знаком с оборудованием Juniper, работа с CLI балансировщика не вызовет затруднений. ### 21.1.2. `apply` — применить, `save` — сохранить в startup После внесения изменений их необходимо применить и сохранить: ```text Внесение изменений ──► apply ──► save │ │ │ │ │ └─ Сохранение в startup-config │ │ (переживёт перезагрузку) │ │ │ └─ Применение конфигурации │ (изменения вступают в силу) │ └─ Изменения только в буфере (не активны, не сохранены) ``` | Команда | Действие | | ----------- | ------------------------------------------------------------------------- | | **`apply`** | Применяет конфигурацию — изменения вступают в силу | | **`save`** | Сохраняет конфигурацию в startup-config (переживёт перезагрузку) | > **Важно:** в прошивке пилотного проекта (Урал) команда `apply` одновременно и применяла, и сохраняла конфигурацию в startup-config. В текущих (федеральных) прошивках это поведение изменено: `apply` только применяет, а для сохранения нужна отдельная команда `save`. ## 21.2. Обновление прошивки: `call rdp firmware download` / `call rdp install` Обновление прошивки балансировщика выполняется в **два этапа** — скачивание и установка: ### Этап 1: Скачивание ```text call rdp firmware download <имя_файла> ``` Скачивает образ прошивки с указанного URL и сохраняет его на устройстве под указанным именем. ### Этап 2: Установка ```text call rdp install <имя_файла> ``` Устанавливает прошивку из указанного файла. По завершении команда выводит результат — `OK` или сообщение об ошибке. ### Дополнительные команды | Команда | Действие | | -------------------------------- | ------------------------------------------------------ | | `call rdp firmware list` | Показать список файлов прошивок на устройстве | | `call rdp firmware delete` | Удалить файл прошивки | | `call rdp firmware set-active` | Установить активную прошивку на указанный раздел | | `show rdp firmware version` | Показать состояние прошивок (версия, активность, tries) | ### 21.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин) Как и на фильтре, балансировщик хранит **два раздела** прошивок — **A** и **B**: | Раздел | Описание | | ------ | ---------------------------------------------------------- | | **A** | Первый раздел для прошивки | | **B** | Второй раздел для прошивки | Для каждого раздела отображается: - **Активность** — активна эта прошивка или нет; - **Версия** — номер версии прошивки; - **Tries** — счётчик попыток загрузки. Новая прошивка всегда устанавливается **вместо неактивной** в данный момент. **Механизм автоматического rollback:** Балансировщик отслеживает **количество неудачных попыток** загрузки с конкретной прошивки. Если устройство **более 3 раз подряд** не смогло загрузиться с определённой прошивки в течение приблизительно **20 минут**, эта прошивка считается **ненадёжной**, и балансировщик автоматически переключается на другой раздел. > **Практический совет:** если вам нужно несколько раз перезагрузить балансировщик в короткий промежуток времени (например, для тестирования), помните о лимите в 3 перезагрузки. После третьей перезагрузки за короткий период прошивка будет признана нестабильной. Количество попыток и временной интервал **не настраиваются** — они зашиты в прошивке. ### 21.2.2. `call rdp firmware reset-tries` Для сброса счётчика попыток загрузки используется команда: ```text call rdp firmware reset-tries ``` Эта команда обнуляет значение **tries**, позволяя продолжить перезагрузки без риска автоматического переключения на другой раздел. В промышленной эксплуатации эта команда практически не требуется, но знать о ней полезно. ## 21.3. Настройка физических портов Настройка физических портов — это **первый шаг** конфигурации балансировщика. Поскольку дефолтной конфигурации нет, все порты необходимо создавать вручную. Для каждого порта задаются следующие параметры: | Параметр | Описание | | --------------- | ------------------------------------------------------------ | | **Имя порта** | Произвольное имя (рекомендуется формат `P<порт><линия>`) | | **number** | Номер физического интерфейса на лицевой панели (1–32) | | **lane** | Номер линии внутри физического порта (0–3) | | **speed** | Скорость порта: 10G, 25G или 100G | | **mtu** | Максимальный размер кадра | | **description** | Текстовое описание порта | Пример конфигурации двух 10-гигабитных портов на одном физическом интерфейсе: ```text set ports P21 number 2 lane 1 speed 10g set ports P22 number 2 lane 2 speed 10g ``` ### 21.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed) Имя порта может быть **произвольным**, однако рекомендуется придерживаться единообразной схемы именования, отражающей номер физического порта и номер линии: ```text P<номер_порта><номер_линии> ``` Например: | Имя порта | Физический порт | Линия | Скорость | Описание | | --------- | --------------- | ----- | -------- | ------------------------------------ | | `P21` | 2 | 1 | 10G | Порт 2, линия 1 — первый 10G-канал | | `P22` | 2 | 2 | 10G | Порт 2, линия 2 — второй 10G-канал | | `P2` | 2 | — | 100G | Порт 2, все линии — 100G-канал | ### 21.3.2. 10G: указание lane (0–3), 100G: все lane задействованы Поведение параметра **lane** зависит от выбранной скорости: **При 10G (или 25G):** Каждый физический порт QSFP28 содержит 4 линии. При использовании гидры (breakout-кабеля) каждая линия становится отдельным 10-гигабитным портом. Для каждого такого порта необходимо явно указать номер линии (`lane 0`, `lane 1`, `lane 2`, `lane 3`): ```text set ports P20 number 2 lane 0 speed 10g set ports P21 number 2 lane 1 speed 10g set ports P22 number 2 lane 2 speed 10g set ports P23 number 2 lane 3 speed 10g ``` В результате из одного физического QSFP28-разъёма получается **4 независимых порта** по 10 Гбит/с. **При 100G:** Все 4 линии объединены в один канал. Параметр `lane` **не указывается**, так как задействованы все линии: ```text set ports P2 number 2 speed 100g ``` > **Рекомендация:** все физические порты настраиваются в соответствии со схемой организации связи на конкретной площадке. Единых «стандартных» настроек нет — конфигурация полностью зависит от того, какие устройства и на каких скоростях подключены к балансировщику. ## 21.4. Настройка линков (объединение двух портов LAN+WAN в сторону оператора) **Линк** (link) в терминологии балансировщика — это объединение **двух портов** (LAN и WAN) в сторону оператора связи: ```text Оператор связи │ ┌────┴────┐ │ Байпас │ └──┬───┬──┘ │ │ LAN WAN ← это один линк │ │ ┌──┴───┴──┐ │Балансир.│ └─────────┘ ``` Каждый линк всегда содержит **ровно один LAN-порт** и **ровно один WAN-порт**. Настройка линка: ```text set links <имя_линка> lan-port <имя_LAN_порта> wan-port <имя_WAN_порта> set links <имя_линка> description "<описание>" ``` Пример: ```text set links link1 lan-port P21 wan-port P22 set links link1 description "Bypass1-Mon0/Mon1" ``` | Параметр | Описание | | ---------------- | ----------------------------------------------------------- | | **Имя линка** | Произвольное название (рекомендуется единообразная схема) | | **lan-port** | Порт в сторону абонентов (LAN) | | **wan-port** | Порт в сторону интернета (WAN) | | **description** | Описание — к какому байпасу и интерфейсу подключен линк | > **Рекомендация:** в описании линка указывайте, к какому конкретно байпасу и к каким его интерфейсам подключён данный линк. Это значительно упрощает диагностику. ## 21.5. Настройка группы балансировки После настройки портов и линков необходимо создать **группу балансировки** (balance group) и привязать к ней группы портов в сторону фильтров. ```text Линки (оператор) Группа балансировки Фильтры │ │ │ ┌────┴────┐ ┌──────┴──────┐ ┌─────┴─────┐ │ link1 │ │ │ │ Filter │ │ link2 │──────► │ Balance │──────│ Group 1 │──► Фильтр 1 │ link3 │ Flow │ Group │ │ Group 2 │──► Фильтр 1 │ ... │ rules │ │ │ Group 3 │──► Фильтр 2 └─────────┘ └──────┬──────┘ │ ... │ │ └───────────┘ Профиль проверки доступности ``` ### 21.5.1. Привязка групп портов в сторону фильтров (filter groups) К группе балансировки привязываются **filter groups** — пары портов (LAN + WAN) в сторону фильтров: ```text set balance-group <имя_группы> filter-group <имя_filter_group> lan-port <порт> wan-port <порт> ``` Количество filter groups определяется количеством пар интерфейсов в сторону фильтров: | Конфигурация площадки | Количество filter groups | | -------------------------------------------- | ------------------------ | | 1 фильтр, 16 портов (8 пар LAN/WAN) | 8 | | 10 фильтров, 16 портов каждый (80 пар) | 80 | Каждая filter group объединяет один LAN-порт и один WAN-порт, смотрящие в сторону конкретной пары интерфейсов фильтра. ### 21.5.2. N_UNIT_QA: количество ядер фильтра минус один Параметр **N_UNIT_QA** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика: ```text set balance-group <имя_группы> n-unit-qa <число> ``` Значение **всегда равно общему количеству ядер процессора фильтра минус один**: | Модель фильтра | Ядер всего | N_UNIT_QA | | ----------------------------- | ---------- | --------- | | Xeon 2695 (18 ядер) | 18 | 17 | | Xeon 2699 (22 ядра) | 22 | 21 | | Xeon Gold 6212 (24 ядра) | 24 | 23 | Причина вычитания единицы: на фильтре **все ядра, кроме одного**, отданы под процесс EcoNAT, который обрабатывает трафик. Одно ядро — **сервисное**: на нём работает Linux, системные логи, управление. Оно не участвует в обработке трафика. Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку. ## 21.6. Профиль проверки доступности (keep-alive) К группе балансировки привязывается **профиль проверки доступности** (availability profile), определяющий параметры отправки keep-alive пакетов через группы портов в сторону фильтров. ```text set balance-group <имя_группы> availability-profile <имя_профиля> ``` Профиль настраивается отдельно: ```text set availability-profile <имя_профиля> <параметр> <значение> ``` ### 21.6.1. Начальная задержка, интервал, порог потерь | Параметр | Описание | | -------------------------- | -------------------------------------------------------------------- | | **Начальная задержка** | Время ожидания перед началом отправки keep-alive после поднятия интерфейсов (например, 1000 мс). Необходимо, чтобы фильтр успел полностью инициализировать интерфейсы | | **Интервал** | Периодичность отправки keep-alive пакетов (например, 100 мс) | | **Порог потерь (down)** | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5 пакетов) | | **Порог восстановления (up)** | Количество последовательно полученных ответов, после которых неактивная filter group считается снова **активной** | Механизм работы: балансировщик отправляет keep-alive пакет в LAN-порт filter group и ожидает получить его через парный WAN-порт. Время прохождения пакета (time of pass) измеряется в наносекундах и в нормальном состоянии составляет порядка **20–30 микросекунд**. При потере заданного количества последовательных пакетов filter group переводится в состояние **bypass** — трафик не отправляется на фильтр, а перекладывается из одного порта в другой на уровне логики балансировщика. ### 21.6.2. Минимальное количество активных пар Параметр **минимальное количество активных пар** (minimum active pairs) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной. Пример: если задано значение 8, то группа балансировки будет считаться рабочей, пока хотя бы 8 filter groups активны — неважно, сколько их всего. > **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, и балансировщик включал bypass на всех линках. Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко. ### 21.6.3. Перебалансировка: включение/выключение Параметр **перебалансировки** (rebalancing) определяет, что происходит при выходе из строя одной из filter groups: | Значение | Поведение | | --------------- | ---------------------------------------------------------------------- | | **Включена** | Трафик пересчитывается и распределяется по оставшимся filter groups | | **Выключена** | Для упавшей filter group включается программный bypass, остальные работают без изменений | **Перебалансировка** занимает определённое время и вычислительные ресурсы. При пересчёте хэша сессии могут попасть на **другие интерфейсы и другие фильтры**, что в общем случае может быть нежелательным (разрыв DPI-сессий, потеря контекста анализа). > **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или разрыв всех сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную. ## 21.7. Настройка фильтров (Flow rules) **Фильтры** (flow rules) на балансировщике — это правила, определяющие, что делать с трафиком, поступающим через линки. Каждое правило состоит из двух частей: | Часть | Описание | | ---------- | ----------------------------------------------------------- | | **Match** | Условия, по которым отбирается трафик (заголовки пакетов) | | **Action** | Действие с пакетом при совпадении | ### 21.7.1. Match-условия: VLAN, IPv4 src/dst, L4 port, MAC, MPLS, глубина тегов Доступные условия для match-секции: | Условие | Описание | | ---------------------- | ------------------------------------------------- | | **VLAN ID** | Номер VLAN-тега (например, `vlan 0 id 1`) | | **IPv4 source** | IP-адрес источника (с маской / префиксом) | | **IPv4 destination** | IP-адрес назначения (с маской / префиксом) | | **L4 port** | Порт транспортного уровня (TCP/UDP) | | **MAC address** | MAC-адрес источника или назначения | | **MPLS labels** | Количество MPLS-меток | | **Глубина VLAN-тегов** | Количество VLAN-тегов (для QinQ) | В одном правиле можно комбинировать **несколько условий** одновременно. Например, одновременно проверять VLAN ID и IPv4-подсеть. Match-условия можно использовать как для **включения** трафика в обработку, так и для **исключения** определённого трафика. ### 21.7.2. Actions: `balancing s_mac` → balance group / `bypass` Действие (action) определяет, что происходит с пакетом при совпадении: | Action | Описание | | ----------------------- | ---------------------------------------------------------------- | | **balancing s_mac** | Отправить трафик на группу балансировки. Балансировка выполняется по хэшу от source IP, destination IP и протокола | | **bypass** | Пропустить трафик прозрачно — переложить из одного порта в другой, не отправляя на фильтры | При использовании `balancing s_mac` дополнительно указывается **целевая группа балансировки**: ```text set filters <имя_фильтра> flows <имя_правила> action balancing s_mac set filters <имя_фильтра> flows <имя_правила> to-balance-group <имя_группы> ``` Пример правила, отправляющего трафик с VLAN ID 1 на фильтры: ```text set filters main flows traffic-to-filter-1 match vlan 0 id 1 set filters main flows traffic-to-filter-1 action balancing s_mac set filters main flows traffic-to-filter-1 to-balance-group group-filter set filters main flows traffic-to-filter-1 priority 100 ``` Пример правила bypass для всего остального трафика: ```text set filters main flows default-bypass action bypass set filters main flows default-bypass priority 1 ``` ### 21.7.3. Приоритеты правил Каждому правилу назначается **приоритет** (priority), определяющий порядок обработки. Пакет проверяется по правилам в порядке убывания приоритета — от **высшего** к **низшему**. Первое совпавшее правило определяет действие. Типовая структура правил: ```text Приоритет Правило Action ───────────────────────────────────────────────────── 100 VLAN 1 → на фильтр balancing s_mac 90 VLAN 2 → на фильтр balancing s_mac 80 VLAN 3 → на фильтр balancing s_mac ... ... ... 1 Всё остальное → bypass bypass ``` Правило с **самым низким приоритетом** и **без match-условий** (совпадает со всем) обычно задаёт action `bypass`. Это означает: всё, что не попало под предыдущие правила, пропускается прозрачно. > **Применение для диагностики:** при траблшутинге можно создать правило с высоким приоритетом, которое перехватывает трафик конкретного VLAN и выполняет action `bypass`. Это позволяет исключить конкретный трафик из обработки фильтрами и проверить, влияет ли ТСПУ на проблему. По статистике правила (количество пакетов/байт) можно убедиться, что трафик действительно проходит через это правило. ### 21.7.4. Привязка фильтров к линкам После настройки правил необходимо **привязать фильтр к линкам** — указать, на каких линках (в сторону оператора) данные правила будут действовать: ```text set filters <имя_фильтра> links [ <линк1> <линк2> ... ] ``` Пример: ```text set filters main links [ link1 link2 link3 link4 ] ``` Один набор правил (фильтр) может быть привязан к **нескольким линкам** одновременно. Все линки, привязанные к фильтру, используют одни и те же flow rules. ## 21.8. Настройка Heartbeat для GL Sun (пилотный проект) Данная настройка актуальна **только для пилотного проекта на Урале**, где используются байпасы GL Sun. В федеральном проекте с байпасами Silicom эта настройка **не требуется** — Silicom самостоятельно генерирует и проверяет heartbeat-пакеты. На Урале балансировщик работает в активном режиме и сам должен отправлять heartbeat-пакеты на байпас GL Sun: | Параметр | Описание | | --------------------------- | --------------------------------------------------------------- | | **IPv4-адрес байпаса** | IP-адрес байпаса GL Sun | | **Порт** | Порт для heartbeat-протокола | | **Период отсылки** | Интервал отправки heartbeat (в наносекундах, например, 30 мкс) | | **Группа балансировки** | Группа, для которой работает отправка heartbeat | | **Список линков байпаса** | Идентификаторы сущностей на стороне байпаса GL Sun | | **ToS** | Тип сервиса в IP-заголовке heartbeat-пакетов | | **Автоматический возврат** | Возможность автоматического возврата трафика в режим primary при восстановлении группы балансировки | Heartbeat-пакеты отправляются только при условии, что **группа балансировки находится в состоянии Active**. При переходе группы в неактивное состояние отправка прекращается, и связь с байпасом (по TCP) разрывается — состояние переходит в `disconnected`. > **Примечание:** с байпасами Silicom логика работы другая — Silicom самостоятельно отсылает heartbeat и проверяет доступность интерфейсов, а балансировщик прозрачно пропускает эти пакеты между своими портами. ## 21.9. Management-интерфейс: IP, маска, default gateway Настройка management-интерфейса балансировщика выполняется аналогично другим сетевым устройствам: ```text set management ip set management mask <маска_подсети> set management default-gateway ``` Management-интерфейс обеспечивает доступ к устройству по SSH и используется для управления, мониторинга и взаимодействия с ЦСУ. > **Напоминание:** management Ethernet работает **только** на скорости 1 Гбит/с (см. [раздел 20.2](20.md)). --- ## Общий порядок настройки балансировщика Для наглядности — последовательность настройки балансировщика «с нуля»: ```text 1. Установить прошивку │ 2. Настроить management-интерфейс │ 3. Настроить физические порты (ports) │ 4. Настроить линки (links) — пары LAN/WAN в сторону оператора │ 5. Настроить группу балансировки (balance group) └── Создать filter groups (пары портов в сторону фильтров) └── Задать N_UNIT_QA └── Привязать профиль проверки доступности │ 6. Настроить профиль проверки доступности (availability profile) │ 7. Настроить фильтры (flow rules) — правила обработки трафика └── Привязать фильтры к линкам │ 8. apply + save ``` --- [← Оглавление](../README.md) · [← Раздел 20: Балансировщик: аппаратная платформа](20.md) · [Раздел 22: Балансировщик: мониторинг и диагностика →](22.md)