# 4. Балансировщик (EcoFilter Balancer) [← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md) --- ## 4.1. Назначение: распределение трафика по фильтрам Балансировщик (EcoFilter Balancer) — это **высокопроизводительный программируемый коммутатор**, основная задача которого — принимать трафик от байпасов и **равномерно распределять** его по подключённым фильтрам для анализа и обработки. Помимо балансировки, балансировщик выполняет следующие функции: - **фильтрация служебного трафика** — байпас (прозрачный пропуск) трафика, который не нужно отправлять на фильтры; - **программный байпас** — возможность заворачивать трафик обратно к оператору, минуя фильтры; - **контроль доступности фильтров** — отправка keep-alive пакетов и автоматическое отключение неисправных фильтров; - **прозрачный пропуск heartbeat-пакетов** байпаса Silicom между своими портами. Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. По умолчанию балансировщик поставляется **без конфигурации** — все порты, линки и правила необходимо создавать вручную при проектировании конкретного узла. ## 4.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с Балансировщик представляет собой компактное одноюнитовое (1U) устройство: | Параметр | Значение | | -------------------------- | --------------------------------------- | | **Форм-фактор** | 1U (одноюнитовый) | | **Количество портов** | 32 порта QSFP28 | | **Пропускная способность** | 3.2 Тбит/с (на пакетах > 160 байт) | | **Скорости портов** | 10G / 25G / 100G | | **Питание** | 2 блока питания, горячее резервирование | | **Передняя панель** | Консоль, Management Ethernet (1G), USB | Существуют также двухюнитовые балансировщики (65 портов), но в проекте АСБИ используются **только одноюнитовые** модели. Для подключения 10-гигабитных интерфейсов используются **гидры** (breakout-кабели): один порт QSFP28 разветвляется на четыре порта SFP+ (10G) с помощью оптических или DAC-кабелей. Таким образом, один физический QSFP28-порт может предоставить до четырёх 10G-портов. При работе на скорости 100G все четыре линии (lane) физического порта объединяются и работают совместно. ## 4.3. Организация портов: пары LAN/WAN, линки Все порты балансировщика логически делятся на две группы: - **Порты в сторону оператора** (через байпасы) — подключены к каналам связи оператора; - **Порты в сторону фильтров** — подключены к фильтрам для передачи трафика на обработку. Порты внутри каждой группы объединяются в **пары** LAN + WAN и далее — в логические сущности, называемые **линками**. ```text Оборудование оператора (через байпасы) │ │ │ │ P42(L) P41(W) P10(L) P9(W) └─────┬─────┘ └─────┬─────┘ Линк 1 Линк 2 (10G) (100G) │ │ ┌───────────┴─────────────────────┴──────────┐ │ Балансировщик │ │ │ │ Flow rules → Balance Group │ └───┬─────┬─────┬──────────┬─────┬─────┬─────┘ P21(L) P22(W) P31(L) P32(W) P41(L) P42(W) └──┬──┘ └──┬──┘ └──┬──┘ Filter Group 1 Filter Group 2 Filter Group 3 │ │ │ Фильтр 1 Фильтр 2 Фильтр N ``` ### 4.3.1. Принцип чётных/нечётных портов По договорённости, принятой при проектировании, на балансировщике соблюдается тот же принцип, что и на фильтрах: - **Чётные** порты — **LAN** (в сторону абонентов); - **Нечётные** порты — **WAN** (в сторону интернета). Например: порт P42 (чётный) — LAN-порт, парный ему P41 (нечётный) — WAN-порт. Для 100-гигабитных портов, у которых нет второй цифры (номера линии), определяющей является единственная цифра: P10 (чётный) — LAN, P9 (нечётный) — WAN. Этот принцип распространяется как на порты в сторону операторского оборудования, так и на порты в сторону фильтров. ### 4.3.2. Жёсткая привязка: трафик возвращается в тот же линк Трафик, пришедший через конкретный порт оператора, **обязательно возвращается** через парный порт того же линка. Пакет, вошедший через P42 (LAN), после обработки выйдет только через P41 (WAN) — и никуда больше. Аналогично, пакет из P41 вернётся только в P42. Это фундаментальное правило обеспечивает **прозрачность ТСПУ** для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его обратно в тот же канал, независимо от того, каким фильтром пакет был обработан. Механизм реализации: при балансировке к пакету добавляется 4-байтовый заголовок, который, помимо информации о ядре фильтра, содержит идентификатор исходного линка. Когда фильтр возвращает обработанный пакет с этим заголовком, балансировщик по нему определяет, в какой операторский линк вернуть пакет. ## 4.4. Фильтры на балансировщике (Flow rules) Перед отправкой трафика на фильтры балансировщик пропускает каждый пакет через **правила фильтрации** (flow rules). Каждое правило состоит из двух частей: - **Match** — условие совпадения (по каким критериям определять трафик); - **Action** — действие (что делать с совпавшим трафиком). Правила привязываются к **линкам** в сторону оператора и обрабатываются в порядке **приоритетов**. ### 4.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация) Действие `action bypass` позволяет указать, что совпавший трафик должен быть **немедленно возвращён** в сторону оператора, минуя фильтры. Это используется для служебного трафика: - **BGP** (TCP-порт 179) — протоколы маршрутизации; - **Мультикаст-трафик** — групповые рассылки; - **Другие служебные протоколы**, которые нежелательно пропускать через DPI. С таким трафиком на фильтрах ничего плохого не произойдёт (он будет прозрачно пропущен), но лучше его не трогать — это снижает нагрузку на фильтры и исключает потенциальное влияние. Типичная конфигурация: все правила для конкретного трафика задаются с высоким приоритетом и действием `bypass`, а в самом конце ставится правило-«заглушка» с самым низким приоритетом, без условий совпадения и с действием `bypass`. Таким образом, **всё, что не попало** под явные правила отправки на фильтры, **байпасится**. ### 4.4.2. Отправка трафика на группу балансировки Действие `action balancing s_mac` отправляет совпавший трафик в указанную **группу балансировки** (balance group) для распределения по фильтрам. Параметр `s_mac` означает балансировку по source IP, destination IP и протоколу. Пример правила: «все пакеты с VLAN ID = 1 отправить на группу балансировки `group_filter`». Трафик конкретного VLAN будет обработан фильтрами, а весь остальной трафик, не попавший под это правило, — байпасится. Условия совпадения (match) могут включать: | Критерий | Описание | | ----------------- | -------------------------------------- | | **VLAN ID** | Номер VLAN-тега (один или несколько) | | **IPv4 src/dst** | Адрес или подсеть источника/назначения | | **L4 port** | Порт TCP/UDP | | **MAC-адрес** | Source или destination MAC | | **MPLS** | Количество MPLS-меток | | **Глубина тегов** | Количество VLAN-тегов в пакете | В одном правиле можно комбинировать несколько условий (например, VLAN + IPv4-подсеть). Матчить можно как для включения трафика в обработку, так и наоборот — для исключения. ## 4.5. Балансировка трафика ### 4.5.1. Хэш-сумма: source IP + destination IP + протокол Балансировка трафика по фильтрам выполняется на основе **хэш-суммы**, вычисляемой по трём параметрам IP-пакета: 1. **Source IP** — адрес источника; 2. **Destination IP** — адрес назначения; 3. **IP-протокол** — номер протокола (TCP, UDP и т.д.). Для вычисления хэша балансировщик разбирает стек заголовков инкапсуляции (VLAN-теги, MPLS-метки) и добирается до IP-заголовка. Если IP-пакет не обнаружен, трафик **прозрачно пропускается** (байпасится), не отправляясь на фильтры. Балансировка работает эффективно за счёт **огромного количества сессий** в реальном операторском трафике. Произведение количества source IP × destination IP × протоколов даёт число, достаточное для равномерного распределения по всем фильтрам и ядрам. Однако одну единственную сессию (один source IP, один destination IP, один протокол) **разбалансировать невозможно** — весь её трафик попадёт на один фильтр и одно ядро. ### 4.5.2. Учёт количества ядер фильтров Параметр **N_UNIT_QA** на балансировщике задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение **всегда равно общему количеству ядер процессора фильтра минус один**, поскольку одно ядро является сервисным — на нём работает ОС Linux, системные логи, управление. Все остальные ядра отданы процессу EcoNAT для обработки трафика. Параметр N_UNIT_QA **напрямую влияет** на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между **ядрами** каждого фильтра. ### 4.5.3. Дополнительный 4-байтный заголовок для фильтров В точке балансировки к пакету добавляется **дополнительный 4-байтовый заголовок**. По структуре он похож на VLAN-тег, но VLAN-тегом не является. Этот заголовок выполняет две функции: 1. **Для фильтра** — сообщает, на какое ядро направить данный пакет для обработки; 2. **Для балансировщика** — при возврате обработанного пакета от фильтра определяет, в какой операторский линк вернуть пакет. Фильтр после обработки возвращает пакет **с тем же 4-байтовым заголовком**. Балансировщик считывает заголовок, определяет исходный линк, удаляет заголовок и отправляет пакет обратно оператору. ### 4.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро Хэш-функция балансировщика **симметрична**: при вычислении хэша для обратного пакета (от интернета к абоненту) source и destination IP меняются местами, но итоговая хэш-сумма совпадает с прямым пакетом. Это гарантирует: - оба направления одной сессии **всегда попадают на один и тот же фильтр**; - более того — на одно и то же **ядро** этого фильтра; - сессия **никогда не распределяется** по разным фильтрам. Благодаря этому фильтр всегда видит полную картину сессии (и запрос, и ответ), что критически важно для корректной работы DPI-анализа. Сессию любого абонента можно найти на одном конкретном фильтре. Важно: балансировщик **не ведёт логов** о том, куда отправил конкретный пакет — вся обработка происходит на аппаратном уровне. Чтобы найти, на каком фильтре «приземлилась» конкретная сессия, необходимо **обойти все фильтры** площадки. При 2–3 фильтрах это делается вручную; при большем количестве (до 15) — автоматизируется скриптом. ## 4.6. Отказоустойчивость ### 4.6.1. Keep-alive пакеты к фильтрам Балансировщик непрерывно контролирует доступность фильтров, отправляя **keep-alive пакеты** через каждую пару портов (filter group) в сторону фильтров. Принцип работы: 1. Балансировщик отправляет keep-alive через **LAN-порт** filter group; 2. Пакет проходит через фильтр (заворачивается на первой проверке, т.к. не является IP-пакетом); 3. Пакет возвращается через парный **WAN-порт**; 4. Балансировщик фиксирует **время прохождения** (time of pass) — в штатном режиме порядка 27 микросекунд. Параметры keep-alive настраиваются в **профиле проверки доступности** (availability profile): | Параметр | Описание | | -------------------------------- | -------------------------------------------------------------------- | | **Начальная задержка** | Время ожидания после старта перед началом отправки | | **Интервал** | Периодичность отправки (типично ~100 мс) | | **Порог потерь** | Число потерянных пакетов для признания группы неактивной (типично 5) | | **Порог восстановления** | Число успешных пакетов для восстановления активности | | **Мин. количество активных пар** | Порог, ниже которого вся balance group считается неактивной | Keep-alive пакеты проверяют не только физическую доступность канала, но и **работоспособность фильтра** в целом: если «мозг» фильтра завис или перегружен настолько, что не может обрабатывать даже не-IP-пакеты, keep-alive не вернётся, и балансировщик это обнаружит. ### 4.6.2. Программный байпас при потере группы портов При потере keep-alive пакетов для конкретной filter group балансировщик переводит эту группу в состояние **программного байпаса**: трафик, предназначенный для данной пары портов, **не отправляется на фильтр**, а заворачивается обратно с LAN-порта на WAN-порт (и наоборот) непосредственно на балансировщике. Ключевые особенности: - Программный байпас применяется **индивидуально** к каждой filter group — остальные группы продолжают работать; - Переключение **не вызывает флапов** линков оператора — оператор ничего не заметит; - Единственное последствие — часть трафика временно перестаёт фильтроваться; - При восстановлении доступности фильтра группа **автоматически возвращается** в активное состояние. Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса приводила к переключению **всей площадки** на байпас с флапами линков у оператора. Программный байпас можно также включить **вручную** — для диагностики или при проведении технических работ. Существует возможность перевести все фильтры в режим программного байпаса одной командой, полностью исключив ТСПУ из обработки трафика без влияния на оператора. ### 4.6.3. Перебалансировка трафика (опционально) Альтернативой программному байпасу является **перебалансировка** трафика на оставшиеся рабочие filter group. Эта возможность настраивается в профиле проверки доступности, но, как правило, **отключена** по следующим причинам: - Перебалансировка **занимает время** и вычислительные ресурсы; - Происходит **пересчёт хэша** для всех сессий — сессии могут попасть на другие фильтры; - Существующие сессии на «старых» фильтрах **разрываются** (фильтр теряет контекст сессии); - В общем случае это может быть **нежелательно**. Рекомендуемый подход для федерального проекта: программный байпас на уровне отдельной filter group без перебалансировки. Часть трафика временно не фильтруется — это меньшее зло, чем перерыв в работе всей площадки или разрыв всех сессий. ## 4.7. Работа с различными инкапсуляциями (VLAN, MPLS) Балансировщик **не снимает и не модифицирует** никакие теги, метки и заголовки инкапсуляции. Вся обработка ограничивается **чтением** заголовков: - **VLAN-теги** — могут использоваться в условиях match для правил фильтрации (например, байпас служебного VLAN); - **MPLS-метки** — балансировщик может определить их наличие и количество, но матчить по конкретным значениям MPLS-меток не имеет практического смысла; - **QinQ** (двойные VLAN-теги) — поддерживается чтение с учётом глубины тегов. Для вычисления хэша балансировщик **разбирает весь стек** инкапсуляции и добирается до IP-заголовка. Это облегчает работу фильтра, у которого ограничения на типы инкапсуляции несколько строже. Пакет передаётся на фильтр **в неизменном виде** (с добавлением только 4-байтового заголовка балансировки). Все VLAN-теги, MPLS-метки и прочие заголовки сохраняются. ## 4.8. Обработка HTTP-редиректов и TCP Reset через фильтры При блокировке ресурсов фильтру необходимо отправить абоненту **HTTP-редирект** (код 302, перенаправление на страницу-заглушку) или **TCP Reset** (для HTTPS-трафика). Особенность связана с тем, что канал между балансировщиком и фильтром фактически **однонаправленный** с точки зрения конкретного порта. Если трафик содержит MPLS-метки или другую инкапсуляцию, фильтр не может самостоятельно сгенерировать ответный пакет с правильными заголовками. Поэтому используется следующая логика: 1. Пакет от абонента в сторону интернет-ресурса **пропускается** как есть; 2. Фильтр **ожидает обратный пакет** от интернет-ресурса в рамках той же сессии; 3. Когда обратный пакет приходит (уже с корректными MPLS-метками и заголовками), фильтр **подменяет** его содержимое на HTTP-редирект или TCP Reset; 4. Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции. Для **HTTP** — подставляется редирект на страницу-заглушку. Для **HTTPS** — отправляется TCP Reset (так как содержимое зашифровано и подмена невозможна). В обоих случаях механизм одинаков: дождаться ответа сервера и подменить пакет. --- [← Оглавление](../README.md) · [← Раздел 3: Байпас](03.md) · [Раздел 5: Фильтр →](05.md)