# 8. Балансировщик: конфигурация [← Оглавление](../README.md) · [← Раздел 7: Балансировщик: аппаратная платформа](balancer-platform.md) --- Настройка балансировщика (EcoFilter Balancer) начинается после установки прошивки и конфигурации сегмента управления. В отличие от фильтра, на балансировщике **нет дефолтной конфигурации** — все секции (порты, линки, группы балансировки, фильтры) необходимо создавать вручную. ## 8.1. CLI: операционный режим / конфигурационный режим (`edit`) CLI балансировщика, как и у фильтра, имеет **два режима** работы: | Режим | Переход | Назначение | | -------------------- | -------------------- | ----------------------------------------- | | **Операционный** | по умолчанию | Просмотр информации: команды `show` | | **Конфигурационный** | команда **`edit`** | Изменение всех настроек устройства | > **Отличие от фильтра:** на фильтре для перехода в конфигурационный режим используется команда `config`, а на балансировщике — **`edit`**. ### 8.1.1. Интерфейс похож на Juniper CLI Интерфейс командной строки балансировщика **очень похож на CLI Juniper**. Настройки задаются с помощью команды `set`: ```text set <путь> <параметр> <значение> ``` Для тех, кто знаком с оборудованием Juniper, работа с CLI балансировщика не вызовет затруднений. ### 8.1.2. `apply` — применить, `save` — сохранить в startup После внесения изменений их необходимо применить и сохранить: ```text Внесение изменений ──► apply ──► save │ │ │ │ │ └─ Сохранение в startup-config │ │ (переживёт перезагрузку) │ │ │ └─ Применение конфигурации │ (изменения вступают в силу) │ └─ Изменения только в буфере (не активны, не сохранены) ``` | Команда | Действие | | ----------- | ------------------------------------------------------------------------- | | **`apply`** | Применяет конфигурацию — изменения вступают в силу | | **`save`** | Сохраняет конфигурацию в startup-config (переживёт перезагрузку) | > **Важно:** в прошивке пилотного проекта (Урал) команда `apply` одновременно и применяла, и сохраняла конфигурацию в startup-config. В текущих (федеральных) прошивках это поведение изменено: `apply` только применяет, а для сохранения нужна отдельная команда `save`. ## 8.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) | ### 8.2.1. Два раздела прошивок (A/B), автоматический rollback (3 попытки / 20 мин) Как и на фильтре, балансировщик хранит **два раздела** прошивок — **A** и **B**: | Раздел | Описание | | ------ | ---------------------------------------------------------- | | **A** | Первый раздел для прошивки | | **B** | Второй раздел для прошивки | Для каждого раздела отображается: - **Активность** — активна эта прошивка или нет; - **Версия** — номер версии прошивки; - **Tries** — счётчик попыток загрузки. Новая прошивка всегда устанавливается **вместо неактивной** в данный момент. **Механизм автоматического rollback:** Балансировщик отслеживает **количество неудачных попыток** загрузки с конкретной прошивки. Если устройство **более 3 раз подряд** не смогло загрузиться с определённой прошивки в течение приблизительно **20 минут**, эта прошивка считается **ненадёжной**, и балансировщик автоматически переключается на другой раздел. > **Практический совет:** если вам нужно несколько раз перезагрузить балансировщик в короткий промежуток времени (например, для тестирования), помните о лимите в 3 перезагрузки. После третьей перезагрузки за короткий период прошивка будет признана нестабильной. Количество попыток и временной интервал **не настраиваются** — они зашиты в прошивке. ### 8.2.2. `call rdp firmware reset-tries` Для сброса счётчика попыток загрузки используется команда: ```text call rdp firmware reset-tries ``` Эта команда обнуляет значение **tries**, позволяя продолжить перезагрузки без риска автоматического переключения на другой раздел. В промышленной эксплуатации эта команда практически не требуется, но знать о ней полезно. ## 8.3. Настройка физических портов Настройка физических портов — это **первый шаг** конфигурации балансировщика. Поскольку дефолтной конфигурации нет, все порты необходимо создавать вручную. Для каждого порта задаются следующие параметры: | Параметр | Описание | | --------------- | ------------------------------------------------------------ | | **Имя порта** | Произвольное имя (рекомендуется формат `p<порт>-<линия>`, для 100G — `p<порт>`) | | **number** | Номер физического интерфейса на лицевой панели (1–32) | | **lane** | Номер линии внутри физического порта (1–4) | | **speed** | Скорость порта: 10G, 25G или 100G | | **mtu** | Максимальный размер кадра | | **description** | Текстовое описание порта | Пример конфигурации двух 10-гигабитных портов на одном физическом интерфейсе: ```text set ports p2-1 number 2 lane 1 speed 10g set ports p2-2 number 2 lane 2 speed 10g ``` ### 8.3.1. Имя порта, номер физического порта (number), линия (lane), скорость (speed) Имя порта может быть **произвольным**, однако рекомендуется придерживаться единообразной схемы именования, отражающей номер физического порта и номер линии: ```text p<номер_порта>-<номер_линии> ``` Например: | Имя порта | Физический порт | Линия | Скорость | Описание | | --------- | --------------- | ----- | -------- | ------------------------------------ | | `p2-1` | 2 | 1 | 10G | Порт 2, линия 1 — первый 10G-канал | | `p2-2` | 2 | 2 | 10G | Порт 2, линия 2 — второй 10G-канал | | `p2` | 2 | — | 100G | Порт 2, все линии — 100G-канал | ### 8.3.2. 10G: указание lane (1–4), 100G: все lane задействованы Поведение параметра **lane** зависит от выбранной скорости: **При 10G (или 25G):** Каждый физический порт QSFP28 содержит 4 линии. При использовании гидры (breakout-кабеля) каждая линия становится отдельным 10-гигабитным портом. Для каждого такого порта необходимо явно указать номер линии (`lane 1`, `lane 2`, `lane 3`, `lane 4`): ```text set ports p2-1 number 2 lane 1 speed 10g set ports p2-2 number 2 lane 2 speed 10g set ports p2-3 number 2 lane 3 speed 10g set ports p2-4 number 2 lane 4 speed 10g ``` В результате из одного физического QSFP28-разъёма получается **4 независимых порта** по 10 Гбит/с. **При 100G:** Все 4 линии объединены в один канал. Параметр `lane` **не указывается**, так как задействованы все линии: ```text set ports p2 number 2 speed 100g ``` > **Рекомендация:** все физические порты настраиваются в соответствии со схемой организации связи на конкретной площадке. Единых «стандартных» настроек нет — конфигурация полностью зависит от того, какие устройства и на каких скоростях подключены к балансировщику. ## 8.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 p2-2 wan-port p2-1 set links link1 description "Bypass1-Mon0/Mon1" ``` | Параметр | Описание | | ---------------- | ----------------------------------------------------------- | | **Имя линка** | Произвольное название (рекомендуется единообразная схема) | | **lan-port** | Порт в сторону абонентов (LAN) | | **wan-port** | Порт в сторону интернета (WAN) | | **description** | Описание — к какому байпасу и интерфейсу подключен линк | > **Рекомендация:** в описании линка указывайте, к какому конкретно байпасу и к каким его интерфейсам подключён данный линк. Это значительно упрощает диагностику. ## 8.5. Настройка группы балансировки После настройки портов и линков необходимо создать **группу балансировки** (balance group) и привязать к ней группы портов в сторону фильтров. ```text Линки (оператор) Группа балансировки Фильтры │ │ │ ┌────┴────┐ ┌──────┴──────┐ ┌─────┴─────┐ │ link1 │ │ │ │ Filter │ │ link2 │──────► │ Balance │──────│ Group 1 │──► Фильтр 1 │ link3 │ Flow │ Group │ │ Group 2 │──► Фильтр 1 │ ... │ rules │ │ │ Group 3 │──► Фильтр 2 └─────────┘ └──────┬──────┘ │ ... │ │ └───────────┘ Профиль Keep-Alive (liveness) ``` ### 8.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-порт, смотрящие в сторону конкретной пары интерфейсов фильтра. ### 8.5.2. nat-unit-queues: количество ядер фильтра минус один Параметр **`nat-unit-queues`** сообщает балансировщику количество ядер на подключённых фильтрах, которые участвуют в обработке трафика: ```text set ecofilter-balancer nat-unit-queues <число> ``` Значение **всегда равно общему количеству ядер процессора фильтра минус один**: | Модель фильтра | Ядер всего | nat-unit-queues | | ----------------------------- | ---------- | --------- | | Xeon 2695 (18 ядер) | 18 | 17 | | Xeon 2699 (22 ядра) | 22 | 21 | | Xeon Gold 6212 (24 ядра) | 24 | 23 | Причина вычитания единицы: на фильтре **все ядра, кроме одного**, отданы под процесс EcoNAT, который обрабатывает трафик. Одно ядро — **сервисное**: на нём работает Linux, системные логи, управление. Оно не участвует в обработке трафика. Этот параметр **напрямую влияет на балансировку** — балансировщик распределяет трафик не только между фильтрами, но и между их ядрами, обеспечивая равномерную нагрузку. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр `cores`). ## 8.6. Профиль Keep-Alive (liveness profile) К группе балансировки привязывается **профиль Keep-Alive** (liveness profile, параметр группы `liveness-profile`), определяющий параметры отправки keep-alive-пакетов через группы портов в сторону фильтров. Профиль настраивается отдельно: ```text set liveness profile <имя_профиля> active-pairs <число> set liveness profile <имя_профиля> initial-delay <мс> set liveness profile <имя_профиля> interval <мс> set liveness profile <имя_профиля> probes-down-count <число> set liveness profile <имя_профиля> probes-up-count <число> ``` ### 8.6.1. Допустимая задержка, интервал, пороги потерь и восстановления | Параметр | Описание | | -------------------------- | -------------------------------------------------------------------- | | **`initial-delay`** | По руководству производителя — максимально допустимая задержка между keep-alive-пакетами, при превышении которой срабатывает счётчик потерь; по эксплуатационным описаниям — пауза перед началом отправки keep-alive после поднятия интерфейсов, чтобы фильтр успел их инициализировать (например, 1000 мс). Подробнее — [раздел 6.6.1](balancer.md) | | **`interval`** | Периодичность отправки keep-alive-пакетов, мс (например, 100) | | **`probes-down-count`** | Количество последовательно потерянных пакетов, после которых filter group считается **неактивной** (например, 5) | | **`probes-up-count`** | Количество последовательно полученных ответов, после которых неактивная filter group снова считается **активной** (например, 5) | Механизм работы: балансировщик отправляет keep-alive пакет в LAN-порт filter group и ожидает получить его через парный WAN-порт. Время прохождения пакета (`time-on-path`) измеряется в наносекундах — например, около 27 мкс; конкретное значение зависит от площадки. При потере заданного количества последовательных пакетов filter group переводится в состояние **bypass** — трафик не отправляется на фильтр, а перекладывается из одного порта в другой на уровне логики балансировщика. ### 8.6.2. Минимальное количество активных пар Параметр **минимальное количество активных пар** (`active-pairs`) определяет, при каком количестве рабочих filter groups вся группа балансировки **целиком** считается активной. Пример: если задано значение 8, то группа балансировки будет считаться рабочей, пока хотя бы 8 filter groups активны — неважно, сколько их всего. > **Уральский пилотный проект:** минимальное количество активных пар было установлено **равным общему количеству** пар в сторону фильтров. В результате при потере хотя бы одного интерфейса вся группа балансировки переходила в неактивное состояние, балансировщик прекращал отправку heartbeat на байпас GL Sun, и тот переводил линки в аппаратный байпас с флапом у оператора ([раздел 5.3.1](bypass.md)). Весь трафик ТСПУ снимался из-за одного упавшего интерфейса. Такое поведение **не обязательно** — значение можно настроить более гибко. ### 8.6.3. Перебалансировка: включение/выключение Параметр **перебалансировки** (`rebalance`, значения enable/disable) задаётся в настройках группы балансировки, а не в профиле Keep-Alive, и определяет, что происходит при выходе из строя одной из filter groups: | Значение | Поведение | | --------------- | ---------------------------------------------------------------------- | | **Включена** | Трафик пересчитывается и распределяется по оставшимся filter groups | | **Выключена** | Для упавшей filter group включается программный bypass, остальные работают без изменений | **Перебалансировка** занимает определённое время и вычислительные ресурсы. При пересчёте хэша сессии могут попасть на **другие интерфейсы и другие фильтры**, что в общем случае может быть нежелательным: новый фильтр видит такие сессии «с середины», а контекст анализа на прежнем фильтре теряется. > **Рекомендация:** в федеральном проекте перебалансировку планируется **отключить**. При потере filter group для конкретной пары интерфейсов включается **программный bypass** — трафик не отправляется на фильтр, а перекладывается из LAN-порта в WAN-порт и наоборот. Последствия минимальны: небольшая часть трафика временно не фильтруется. Это меньшее зло, чем флапание линков или массовый переезд сессий при перебалансировке. Система мониторинга получает уведомления (логи, SNMP traps), и проблема устраняется вручную. ## 8.7. Настройка фильтров (Flow rules) **Фильтр** на балансировщике — именованный набор правил (flows), который привязывается к линкам в сторону оператора (параметр `apply-to-links`, [раздел 8.7.4](#874-привязка-фильтров-к-линкам)). Каждое правило состоит из условия (match) и действия (action); порядок проверки задаёт приоритет (priority, [раздел 8.7.3](#873-приоритеты-правил)): | Часть | Описание | | ---------- | ----------------------------------------------------------- | | **Match** | Условия, по которым отбирается трафик (заголовки пакетов) | | **Action** | Действие с пакетом при совпадении | ### 8.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-условия можно использовать как для **включения** трафика в обработку, так и для **исключения** определённого трафика. ### 8.7.2. Actions: `balancing-as mag-hash` → balance group / `bypass` Действие (action) определяет, что происходит с пакетом при совпадении: | Action | Описание | | ----------------------- | ---------------------------------------------------------------- | | **balancing-as mag-hash** | Отправить трафик на группу балансировки. Балансировка выполняется по хэшу от source IP, destination IP и протокола | | **bypass** | Пропустить трафик прозрачно — переложить из одного порта в другой, не отправляя на фильтры | При использовании `balancing-as mag-hash` дополнительно указывается **целевая группа балансировки**: ```text set filters <имя_фильтра> flows <имя_правила> action balancing-as mag-hash 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-as mag-hash 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 ``` ### 8.7.3. Приоритеты правил Каждому правилу назначается **приоритет** (priority), определяющий порядок обработки. Пакет проверяется по правилам в порядке убывания приоритета — от **высшего** к **низшему**. Первое совпавшее правило определяет действие. Типовая структура правил: ```text Приоритет Правило Action ───────────────────────────────────────────────────── 100 VLAN 1 → на фильтр balancing-as mag-hash 90 VLAN 2 → на фильтр balancing-as mag-hash 80 VLAN 3 → на фильтр balancing-as mag-hash ... ... ... 1 Всё остальное → bypass bypass ``` Правило с **самым низким приоритетом** и **без match-условий** (совпадает со всем) обычно задаёт action `bypass`. Это означает: всё, что не попало под предыдущие правила, пропускается прозрачно. > **Применение для диагностики:** при траблшутинге можно создать правило с высоким приоритетом, которое перехватывает трафик конкретного VLAN и выполняет action `bypass`. Это позволяет исключить конкретный трафик из обработки фильтрами и проверить, влияет ли ТСПУ на проблему. По статистике правила (количество пакетов/байт) можно убедиться, что трафик действительно проходит через это правило. ### 8.7.4. Привязка фильтров к линкам После настройки правил необходимо **привязать фильтр к линкам** — указать, на каких линках (в сторону оператора) данные правила будут действовать: ```text set filters <имя_фильтра> apply-to-links [ <линк1> <линк2> ... ] ``` Пример: ```text set filters main apply-to-links [ link1 link2 link3 link4 ] ``` Один набор правил (фильтр) может быть привязан к **нескольким линкам** одновременно. Все линки, привязанные к фильтру, используют одни и те же flow rules. ## 8.8. Настройка Heartbeat для GL Sun (пилотный проект) Данная настройка актуальна **только для пилотного проекта на Урале**, где используются байпасы GL Sun. В федеральном проекте с байпасами Silicom эта настройка **не требуется** — Silicom самостоятельно генерирует и проверяет heartbeat-пакеты. На Урале балансировщик работает в активном режиме и сам должен отправлять heartbeat-пакеты на байпас GL Sun: | Параметр | Описание | | --------------------------- | --------------------------------------------------------------- | | **IPv4-адрес байпаса** | IP-адрес байпаса GL Sun (`ipv4`) | | **Порт** | TCP- или UDP-порт байпаса для heartbeat (`tcp-port` / `udp-port`, по умолчанию 4001) | | **Период отсылки** | Периодичность отправки heartbeat (`watchdog-delay`), в микросекундах; рекомендованное значение — 30 мс (30000), по умолчанию — 10000 (10 мс) | | **Группа балансировки** | Группа, для которой работает отправка heartbeat (`balance-group`) | | **Список линков байпаса** | Идентификаторы сущностей на стороне байпаса GL Sun (`links`) | | **ToS** | Тип сервиса в IP-заголовке heartbeat-пакетов (`type-of-service`, по умолчанию 184) | | **Автоматический возврат** | Возможность автоматического возврата трафика в режим primary при восстановлении группы балансировки (`autoreturn`) | Параметры задаются в профиле heartbeat (`bypass-unit profile`), а линк балансировщика связывается с линком байпаса параметром `bypass-unit link-id` в настройках линка. Heartbeat-пакеты отправляются только при условии, что **группа балансировки находится в состоянии Active**. При переходе группы в неактивное состояние отправка прекращается, и связь с байпасом (по TCP) разрывается — состояние переходит в `disconnected`. > **Примечание:** с байпасами Silicom логика работы другая — Silicom самостоятельно отсылает heartbeat и проверяет доступность интерфейсов, а балансировщик прозрачно пропускает эти пакеты между своими портами. ## 8.9. Management-интерфейс: IP, маска, default gateway Настройка management-интерфейса балансировщика выполняется аналогично другим сетевым устройствам: ```text set management ip set management mask <маска_подсети> set management default-gateway ``` Management-интерфейс обеспечивает доступ к устройству по SSH и используется для управления, мониторинга и взаимодействия с ЦСУ. > **Напоминание:** management Ethernet работает **только** на скорости 1 Гбит/с (см. [раздел 7.2](balancer-platform.md)). --- ## Общий порядок настройки балансировщика Для наглядности — последовательность настройки балансировщика «с нуля»: ```text 1. Установить прошивку │ 2. Настроить management-интерфейс │ 3. Настроить физические порты (ports) │ 4. Настроить линки (links) — пары LAN/WAN в сторону оператора │ 5. Настроить группу балансировки (balance group) └── Создать filter groups (пары портов в сторону фильтров) └── Задать nat-unit-queues └── Привязать профиль Keep-Alive │ 6. Настроить профиль Keep-Alive (liveness profile) │ 7. Настроить фильтры (flow rules) — правила обработки трафика └── Привязать фильтры к линкам │ 8. apply + save ``` --- [← Оглавление](../README.md) · [← Раздел 7: Балансировщик: аппаратная платформа](balancer-platform.md) · [Раздел 9: Балансировщик: мониторинг и диагностика →](balancer-monitoring.md)