10fb7f4e18
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
249 lines
28 KiB
Markdown
249 lines
28 KiB
Markdown
# 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)
|