← Оглавление · ← Раздел 3: Байпас
Балансировщик (EcoFilter Balancer) — это высокопроизводительный программируемый коммутатор, основная задача которого — принимать трафик от байпасов и равномерно распределять его по подключённым фильтрам для анализа и обработки.
Помимо балансировки, балансировщик выполняет следующие функции:
- фильтрация служебного трафика — байпас (прозрачный пропуск) трафика, который не нужно отправлять на фильтры;
- программный байпас — возможность заворачивать трафик обратно к оператору, минуя фильтры;
- контроль доступности фильтров — отправка keep-alive пакетов и автоматическое отключение неисправных фильтров;
- прозрачный пропуск heartbeat-пакетов байпаса Silicom между своими портами.
Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. По умолчанию балансировщик поставляется без конфигурации — все порты, линки и правила необходимо создавать вручную при проектировании конкретного узла.
Балансировщик представляет собой компактное одноюнитовое (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) физического порта объединяются и работают совместно.
Все порты балансировщика логически делятся на две группы:
- Порты в сторону оператора (через байпасы) — подключены к каналам связи оператора;
- Порты в сторону фильтров — подключены к фильтрам для передачи трафика на обработку.
Порты внутри каждой группы объединяются в пары LAN + WAN и далее — в логические сущности, называемые линками.
Оборудование оператора (через байпасы)
│ │ │ │
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
По договорённости, принятой при проектировании, на балансировщике соблюдается тот же принцип, что и на фильтрах:
- Чётные порты — LAN (в сторону абонентов);
- Нечётные порты — WAN (в сторону интернета).
Например: порт P42 (чётный) — LAN-порт, парный ему P41 (нечётный) — WAN-порт. Для 100-гигабитных портов, у которых нет второй цифры (номера линии), определяющей является единственная цифра: P10 (чётный) — LAN, P9 (нечётный) — WAN.
Этот принцип распространяется как на порты в сторону операторского оборудования, так и на порты в сторону фильтров.
Трафик, пришедший через конкретный порт оператора, обязательно возвращается через парный порт того же линка. Пакет, вошедший через P42 (LAN), после обработки выйдет только через P41 (WAN) — и никуда больше. Аналогично, пакет из P41 вернётся только в P42.
Это фундаментальное правило обеспечивает прозрачность ТСПУ для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его обратно в тот же канал, независимо от того, каким фильтром пакет был обработан.
Механизм реализации: при балансировке к пакету добавляется 4-байтовый заголовок, который, помимо информации о ядре фильтра, содержит идентификатор исходного линка. Когда фильтр возвращает обработанный пакет с этим заголовком, балансировщик по нему определяет, в какой операторский линк вернуть пакет.
Перед отправкой трафика на фильтры балансировщик пропускает каждый пакет через правила фильтрации (flow rules). Каждое правило состоит из двух частей:
- Match — условие совпадения (по каким критериям определять трафик);
- Action — действие (что делать с совпавшим трафиком).
Правила привязываются к линкам в сторону оператора и обрабатываются в порядке приоритетов.
Действие action bypass позволяет указать, что совпавший трафик должен быть немедленно возвращён в сторону оператора, минуя фильтры. Это используется для служебного трафика:
- BGP (TCP-порт 179) — протоколы маршрутизации;
- Мультикаст-трафик — групповые рассылки;
- Другие служебные протоколы, которые нежелательно пропускать через DPI.
С таким трафиком на фильтрах ничего плохого не произойдёт (он будет прозрачно пропущен), но лучше его не трогать — это снижает нагрузку на фильтры и исключает потенциальное влияние.
Типичная конфигурация: все правила для конкретного трафика задаются с высоким приоритетом и действием bypass, а в самом конце ставится правило-«заглушка» с самым низким приоритетом, без условий совпадения и с действием bypass. Таким образом, всё, что не попало под явные правила отправки на фильтры, байпасится.
Действие 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-подсеть). Матчить можно как для включения трафика в обработку, так и наоборот — для исключения.
Балансировка трафика по фильтрам выполняется на основе хэш-суммы, вычисляемой по трём параметрам IP-пакета:
- Source IP — адрес источника;
- Destination IP — адрес назначения;
- IP-протокол — номер протокола (TCP, UDP и т.д.).
Для вычисления хэша балансировщик разбирает стек заголовков инкапсуляции (VLAN-теги, MPLS-метки) и добирается до IP-заголовка. Если IP-пакет не обнаружен, трафик прозрачно пропускается (байпасится), не отправляясь на фильтры.
Балансировка работает эффективно за счёт огромного количества сессий в реальном операторском трафике. Произведение количества source IP × destination IP × протоколов даёт число, достаточное для равномерного распределения по всем фильтрам и ядрам. Однако одну единственную сессию (один source IP, один destination IP, один протокол) разбалансировать невозможно — весь её трафик попадёт на один фильтр и одно ядро.
Параметр N_UNIT_QA на балансировщике задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение всегда равно общему количеству ядер процессора фильтра минус один, поскольку одно ядро является сервисным — на нём работает ОС Linux, системные логи, управление. Все остальные ядра отданы процессу EcoNAT для обработки трафика.
Параметр N_UNIT_QA напрямую влияет на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между ядрами каждого фильтра.
В точке балансировки к пакету добавляется дополнительный 4-байтовый заголовок. По структуре он похож на VLAN-тег, но VLAN-тегом не является. Этот заголовок выполняет две функции:
- Для фильтра — сообщает, на какое ядро направить данный пакет для обработки;
- Для балансировщика — при возврате обработанного пакета от фильтра определяет, в какой операторский линк вернуть пакет.
Фильтр после обработки возвращает пакет с тем же 4-байтовым заголовком. Балансировщик считывает заголовок, определяет исходный линк, удаляет заголовок и отправляет пакет обратно оператору.
Хэш-функция балансировщика симметрична: при вычислении хэша для обратного пакета (от интернета к абоненту) source и destination IP меняются местами, но итоговая хэш-сумма совпадает с прямым пакетом.
Это гарантирует:
- оба направления одной сессии всегда попадают на один и тот же фильтр;
- более того — на одно и то же ядро этого фильтра;
- сессия никогда не распределяется по разным фильтрам.
Благодаря этому фильтр всегда видит полную картину сессии (и запрос, и ответ), что критически важно для корректной работы DPI-анализа. Сессию любого абонента можно найти на одном конкретном фильтре.
Важно: балансировщик не ведёт логов о том, куда отправил конкретный пакет — вся обработка происходит на аппаратном уровне. Чтобы найти, на каком фильтре «приземлилась» конкретная сессия, необходимо обойти все фильтры площадки. При 2–3 фильтрах это делается вручную; при большем количестве (до 15) — автоматизируется скриптом.
Балансировщик непрерывно контролирует доступность фильтров, отправляя keep-alive пакеты через каждую пару портов (filter group) в сторону фильтров.
Принцип работы:
- Балансировщик отправляет keep-alive через LAN-порт filter group;
- Пакет проходит через фильтр (заворачивается на первой проверке, т.к. не является IP-пакетом);
- Пакет возвращается через парный WAN-порт;
- Балансировщик фиксирует время прохождения (time of pass) — в штатном режиме порядка 27 микросекунд.
Параметры keep-alive настраиваются в профиле проверки доступности (availability profile):
| Параметр | Описание |
|---|---|
| Начальная задержка | Время ожидания после старта перед началом отправки |
| Интервал | Периодичность отправки (типично ~100 мс) |
| Порог потерь | Число потерянных пакетов для признания группы неактивной (типично 5) |
| Порог восстановления | Число успешных пакетов для восстановления активности |
| Мин. количество активных пар | Порог, ниже которого вся balance group считается неактивной |
Keep-alive пакеты проверяют не только физическую доступность канала, но и работоспособность фильтра в целом: если «мозг» фильтра завис или перегружен настолько, что не может обрабатывать даже не-IP-пакеты, keep-alive не вернётся, и балансировщик это обнаружит.
При потере keep-alive пакетов для конкретной filter group балансировщик переводит эту группу в состояние программного байпаса: трафик, предназначенный для данной пары портов, не отправляется на фильтр, а заворачивается обратно с LAN-порта на WAN-порт (и наоборот) непосредственно на балансировщике.
Ключевые особенности:
- Программный байпас применяется индивидуально к каждой filter group — остальные группы продолжают работать;
- Переключение не вызывает флапов линков оператора — оператор ничего не заметит;
- Единственное последствие — часть трафика временно перестаёт фильтроваться;
- При восстановлении доступности фильтра группа автоматически возвращается в активное состояние.
Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса приводила к переключению всей площадки на байпас с флапами линков у оператора.
Программный байпас можно также включить вручную — для диагностики или при проведении технических работ. Существует возможность перевести все фильтры в режим программного байпаса одной командой, полностью исключив ТСПУ из обработки трафика без влияния на оператора.
Альтернативой программному байпасу является перебалансировка трафика на оставшиеся рабочие filter group. Эта возможность настраивается в профиле проверки доступности, но, как правило, отключена по следующим причинам:
- Перебалансировка занимает время и вычислительные ресурсы;
- Происходит пересчёт хэша для всех сессий — сессии могут попасть на другие фильтры;
- Существующие сессии на «старых» фильтрах разрываются (фильтр теряет контекст сессии);
- В общем случае это может быть нежелательно.
Рекомендуемый подход для федерального проекта: программный байпас на уровне отдельной filter group без перебалансировки. Часть трафика временно не фильтруется — это меньшее зло, чем перерыв в работе всей площадки или разрыв всех сессий.
Балансировщик не снимает и не модифицирует никакие теги, метки и заголовки инкапсуляции. Вся обработка ограничивается чтением заголовков:
- VLAN-теги — могут использоваться в условиях match для правил фильтрации (например, байпас служебного VLAN);
- MPLS-метки — балансировщик может определить их наличие и количество, но матчить по конкретным значениям MPLS-меток не имеет практического смысла;
- QinQ (двойные VLAN-теги) — поддерживается чтение с учётом глубины тегов.
Для вычисления хэша балансировщик разбирает весь стек инкапсуляции и добирается до IP-заголовка. Это облегчает работу фильтра, у которого ограничения на типы инкапсуляции несколько строже.
Пакет передаётся на фильтр в неизменном виде (с добавлением только 4-байтового заголовка балансировки). Все VLAN-теги, MPLS-метки и прочие заголовки сохраняются.
При блокировке ресурсов фильтру необходимо отправить абоненту HTTP-редирект (код 302, перенаправление на страницу-заглушку) или TCP Reset (для HTTPS-трафика). Особенность связана с тем, что канал между балансировщиком и фильтром фактически однонаправленный с точки зрения конкретного порта.
Если трафик содержит MPLS-метки или другую инкапсуляцию, фильтр не может самостоятельно сгенерировать ответный пакет с правильными заголовками. Поэтому используется следующая логика:
- Пакет от абонента в сторону интернет-ресурса пропускается как есть;
- Фильтр ожидает обратный пакет от интернет-ресурса в рамках той же сессии;
- Когда обратный пакет приходит (уже с корректными MPLS-метками и заголовками), фильтр подменяет его содержимое на HTTP-редирект или TCP Reset;
- Модифицированный пакет отправляется абоненту с сохранением всей инкапсуляции.
Для HTTP — подставляется редирект на страницу-заглушку. Для HTTPS — отправляется TCP Reset (так как содержимое зашифровано и подмена невозможна). В обоих случаях механизм одинаков: дождаться ответа сервера и подменить пакет.