DanielLavrushin_tspu-docs/docs/balancer.md

6. Балансировщик: принцип работы

← Оглавление · ← Раздел 5: Байпас

---

6.1. Назначение: распределение трафика по фильтрам

Балансировщик (EcoFilter Balancer) — это высокопроизводительный программируемый коммутатор. Его основная задача — принимать трафик операторских каналов от байпасов и равномерно распределять его по подключённым фильтрам, а внутри каждого фильтра — по его процессорным ядрам. Для сети оператора балансировщик, как и остальное оборудование ТСПУ, прозрачен на уровне L2.

Помимо балансировки, балансировщик выполняет следующие функции:

• согласование скоростей — операторские каналы (как правило, 10G и 100G) распределяются по портам фильтров, которые в проекте в большинстве случаев подключаются интерфейсами 10G. Число фильтров определяется только объёмом трафика, поэтому число портов в сторону фильтров не совпадает с числом операторских каналов;
• исключение служебного трафика — возврат оператору без обработки трафика, который не нужно отправлять на фильтры (правила с действием bypass, раздел 6.4);
• контроль доступности фильтров — отправка keep-alive-пакетов через каждую пару портов в сторону фильтров;
• программный байпас — вывод из обработки отдельной пары портов или всех фильтров сразу без флапа линков у оператора;
• прозрачный пропуск heartbeat-пакетов байпаса Silicom между парными портами линка (раздел 5.4).

Балансировщик работает только с заголовками пакетов уровней L2–L4 и ничего не знает о том, что происходит на фильтрах: распознавание протоколов, DPI-листы и блокировки его не касаются. По документации производителя он поддерживает также прозрачный режим с зеркалированием: трафик пропускается мимо фильтров, а на фильтры отправляется только копия. В проекте фильтры в режиме копии трафика не используются; для вывода фильтров из обработки служит программный байпас (раздел 6.6.2).

В ТСПУ тип А используется балансировщик EcoFilter Balancer; в эшелонированной системе (ТСПУ тип Б) на той же аппаратной платформе работает балансировщик с другим программным обеспечением — Eco Highway (раздел 4). Количество балансировщиков на площадке определяется количеством каналов связи оператора и объёмом трафика. В простейшей конфигурации — один-два канала и один фильтр — балансировщик не нужен, и байпас подключается к фильтру напрямую (раздел 2.3).

С завода балансировщик поставляется с заводской (factory) прошивкой ограниченной функциональности и базовой версией рабочей прошивки, но без рабочей конфигурации. После установки нужной версии прошивки и настройки сегмента управления в конфигурации нет ни линков, ни групп балансировки, ни правил, а все используемые порты нужно настроить самостоятельно — всё это создаётся при проектировании конкретного узла (раздел 8).

6.2. Аппаратная платформа: 32-портовый, 1U, пропускная способность 3.2 Тбит/с

Параметр	Значение
Форм-фактор	1U
Порты	32 × QSFP28
Пропускная способность	3,2 Тбит/с; скорость провода обеспечивается на пакетах размером более 160 байт
Скорости портов	Платформа поддерживает 10/25/40/50/100GE (в зависимости от настроек и трансиверов); типовые скорости в проекте — 10G и 100G
Питание	2 блока питания с горячим резервированием
Передняя панель	Консоль, порт управления Ethernet (работает только на 1 Гбит/с), USB, диагностический разъём

Существуют также двухюнитовые балансировщики на 65 портов, но в проекте АСБИ используются только одноюнитовые. По техническому описанию производителя в основе балансировщика — P4-программируемый коммутатор; одноюнитовой 32-портовой модели соответствует платформа EcoSwitch 1032, в линейке есть также модель 2065 (2U, 65 × QSFP28, до 6,4 Тбит/с). Коммутационный чип платформы — Barefoot Tofino.

Каждый порт QSFP28 состоит из четырёх линий (lane) по 25 Гбит/с. На скорости 100G задействованы все четыре линии; если настроить каждую линию отдельно на 10G, один физический порт даёт до четырёх портов 10G. Для их подключения используются «гидры» — breakout-кабели QSFP → 4 × SFP+, оптические или DAC.

Внутри чипа Tofino — два независимых конвейера (pipeline) со своими ресурсами, каждый обслуживает свою половину портов. На EcoFilter Balancer оба конвейера настроены одинаково, поэтому к какому из них относится порт, значения не имеет — в отличие от Eco Highway (раздел 4.4). Подробно аппаратная часть описана в разделе 7.

6.3. Организация портов: пары LAN/WAN, линки

Все порты балансировщика логически делятся на две группы:

• порты в сторону оператора — подключены через байпасы к каналам связи оператора;
• порты в сторону фильтров — подключены к фильтрам.

Порты обеих групп работают парами LAN + WAN:

• пара портов в сторону оператора называется линком (link). В линк всегда входит ровно один LAN-порт и один WAN-порт — они соответствуют одному разорванному каналу оператора (портам Mon0 и Mon1 одного сегмента байпаса). Имя линка произвольное, но его лучше строить по единому правилу; в описании линка можно указать, к какому байпасу и какому его сегменту он подключён;
• пара портов в сторону фильтра называется filter group. Filter groups объединяются в группу балансировки (balance group), по которой и распределяется трафик; групп балансировки может быть несколько.

Количество filter groups равно количеству пар портов в сторону фильтров: один фильтр с 16 портами — это 8 filter groups, десять таких фильтров — 80. Filter group — это именно пара портов, а не фильтр целиком: при проблеме с одной парой остальные пары того же фильтра продолжают работать.

Имена портов задаются при настройке. Рекомендуется придерживаться схемы «номер физического порта — номер линии»: p4-2 — вторая линия порта 4 (10G), p10 — порт 10 целиком (100G). Номера портов в примерах условны.

          Оборудование оператора (через байпасы)
            │           │                   │           │
        p4-2 LAN     p4-1 WAN            p10 LAN      p9 WAN
            └─────┬─────┘                   └─────┬─────┘
            Линк 1 (10G)                   Линк 2 (100G)
                  │                               │
     ┌────────────┴───────────────────────────────┴────────────┐
     │                      Балансировщик                      │
     │        фильтры (flow rules) → группа балансировки       │
     └──────┬───────────┬─────────────┬───────────┬────────────┘
        p1-2 LAN     p1-1 WAN     p1-4 LAN     p1-3 WAN   ...
            └─────┬─────┘             └─────┬─────┘
           filter group 1            filter group 2
                  │                         │
          Фильтр 1: te2/te1         Фильтр 1: te4/te3

6.3.1. Принцип чётных/нечётных портов

На фильтрах разделение портов жёсткое: в каждой паре чётный порт — LAN, нечётный — WAN (раздел 11.5). На балансировщике жёсткой привязки нет — порт становится LAN или WAN только при настройке линка или filter group. Для однозначности при проектировании принят тот же принцип, что и на фильтрах:

• чётные порты — LAN (в сторону абонентов);
• нечётные порты — WAN (в сторону интернета).

Для 10-гигабитных портов чётность определяется по номеру линии: p4-2 — LAN, парный ему p4-1 — WAN. У 100-гигабитных портов номера линии нет, и определяющим является номер порта: p10 — LAN, p9 — WAN. Принцип действует как для портов в сторону операторского оборудования, так и для портов в сторону фильтров. На балансировщике Eco Highway он не соблюдается: там LAN- и WAN-порты разнесены по разным конвейерам (раздел 4.4.1).

6.3.2. Жёсткая привязка: трафик возвращается в тот же линк

Пакет, вошедший в LAN-порт линка, после обработки выходит только через WAN-порт того же линка, и наоборот: вошедший через p4-2 выйдет только через p4-1, вошедший через p4-1 — только через p4-2. Ни в какой другой порт пакет попасть не может — это сделано специально, чтобы пакеты разных линков никогда не смешивались.

Это правило обеспечивает прозрачность ТСПУ для сети оператора: если оператор отправил пакет в конкретный канал, ТСПУ вернёт его в продолжение того же канала, независимо от того, каким фильтром пакет был обработан. Механизм — служебный 4-байтный заголовок, по которому балансировщик узнаёт исходный линк вернувшегося от фильтра пакета (раздел 6.5.3).

6.3.3. Асимметричный трафик: все линки — на один балансировщик

Оба направления каждого потока должны попадать на один и тот же фильтр и одно его ядро; проще всего это обеспечить, когда оба направления проходят через один и тот же балансировщик. Поэтому на один балансировщик заводятся все линки, по которым могут идти прямое и обратное направления одного и того же трафика. В частности, все каналы одного агрегированного линка (LAG) оператора приходят на один балансировщик: оборудование оператора с каждой стороны распределяет потоки по каналам агрегата своим хэшем, и прямое и обратное направления одной сессии могут оказаться в разных каналах. Поэтому при проектировании узла у оператора выясняют, какие каналы входят в агрегаты.

Речь идёт о случае, когда оба направления проходят через ТСПУ, но по разным каналам. Если одно из направлений вообще минует ТСПУ, тип А такой трафик обработать не может — для этого предназначена эшелонированная система (раздел 4.2).

Если одного балансировщика недостаточно, применяется перекрёстная (кроссированная) схема с несколькими балансировщиками, к которым подключены одни и те же фильтры. Чтобы поток попадал на один и тот же фильтр и одно ядро, на какой бы балансировщик он ни пришёл, группы балансировки на всех балансировщиках такой схемы настраиваются одинаково — те же фильтры в том же порядке, то же число ядер; в новых версиях ПО для сверки предусмотрена контрольная сумма конфигурации группы балансировки (show ecofilter-balancer balancing-config-hash). В эшелонированной системе такая схема может не подойти, поскольку фильтры там подключаются по схеме on-a-stick (раздел 4.3.3).

6.4. Фильтры на балансировщике (Flow rules)

Примечание о версиях ПО. Имена параметров в этой главе — группы балансировки (balance-groups) с парами портов filter-group, наборы правил filters с привязкой apply-to-links, действие balancing-as mag-hash с to-balance-group, параметры nat-unit-queues и rebalance — относятся к ранней модели конфигурации балансировщика, по которой построен и раздел 8. В новых версиях ПО модель другая: группа балансировки задаётся как ecofilter-balancer ecofilter-unit с парами портов pair и числом ядер cores, правила — как ecofilter-balancer flow с действиями bypass (по умолчанию), drop и to-ecofilter, а метод хэширования — одним параметром для всего устройства (ecofilter-balancer balancing-method). Логика работы при этом та же.

Термин «фильтр» на балансировщике означает не устройство, а именованный набор правил, который привязывается к линкам в сторону оператора (параметр apply-to-links). Каждое правило (flow) состоит из трёх частей:

• match — условия совпадения;
• action — действие с совпавшим пакетом;
• priority — приоритет: правила проверяются в порядке приоритета, от высшего к низшему, и срабатывает первое совпавшее. Направление шкалы — больше или меньше число означает более высокий приоритет — в документации производителя описано противоречиво, поэтому его стоит проверять на используемой версии ПО.

Действий в ТСПУ тип А два: отправить трафик на группу балансировки, то есть на фильтры, или вернуть его оператору без обработки (bypass). В документации производителя для новых версий ПО описаны также действие drop и блокировка по таблицам, загружаемым с внешнего gRPC-сервера (external-acl, действие block). В рассматриваемой схеме ТСПУ тип А блокировку выполняют фильтры, а балансировщик трафик не блокирует — в отличие от эшелонированной системы (раздел 4).

Правила можно строить двумя способами: перечислить трафик-исключения с действием bypass, а всё остальное отправить на фильтры, — либо, наоборот, перечислить трафик, который нужно отправить на фильтры, а всё остальное вернуть оператору завершающим правилом. Обычно правил на балансировщике ТСПУ тип А немного, они задаются вручную и описывают исключения — например, служебный VLAN возвращается оператору, а весь остальной трафик отправляется на фильтры. На Eco Highway, наоборот, правила загружаются из ЦСУ и исчисляются десятками и сотнями тысяч (раздел 4.3.1). По каждому правилу балансировщик считает пакеты и байты; эта статистика используется при диагностике (разделы 9.5 и 23.4).

6.4.1. Байпас служебного трафика (BGP, мультикаст, маршрутизация)

Действие bypass возвращает совпавший трафик оператору через парный порт линка сразу на входе, не отправляя его на фильтры. Так поступают с трафиком, который не нужно и нежелательно анализировать:

• протоколы маршрутизации и сигнализации — например, BGP (TCP-порт 179);
• мультикаст-трафик;
• служебный трафик оператора, выделенный в отдельный VLAN;
• прочий трафик, анализ которого не требуется.

С таким трафиком на фильтрах ничего плохого произойти не должно, но лучше его не трогать: фильтровать в нём нечего, а служебные протоколы чувствительны к задержкам и потерям. Кроме того, это разгружает фильтры.

Если правила построены по второму способу, набор завершается правилом с самым низким приоритетом, пустым условием (совпадает всё) и действием bypass: весь трафик, не попавший под предыдущие правила, возвращается оператору без обработки. Тогда на фильтры попадает только трафик, явно отобранный правилами, а всё, что правилами не перечислено, остаётся без фильтрации.

Отбором по VLAN пользуются и при подключении BRAS или CGNAT по схеме on-a-stick: на фильтры отправляют только VLAN одного участка — до или после BRAS/CGNAT, в обоих направлениях, — чтобы каждая сессия обрабатывалась один раз (раздел 3.4.2).

6.4.2. Отправка трафика на группу балансировки

Действие балансировки задаётся как balancing-as mag-hash — распределение по хэшу от адресов источника, назначения и IP-протокола — вместе с целевой группой (to-balance-group): групп балансировки может быть несколько, и правило определяет, в какую из них отправить трафик. В новых версиях ПО этому соответствует действие to-ecofilter, а метод хэширования задаётся отдельно для всего устройства (раздел 6.5.1).

Пример: правило с условием «первый VLAN-тег равен 1» и действием балансировки отправляет трафик VLAN 1 на фильтры, а завершающее правило bypass возвращает оператору всё остальное.

Условия совпадения (match) — по документации производителя; имена условий приведены для текущих версий ПО:

Критерий	Описание
VLAN-теги	Значения первого, второго и третьего тега (vlan0-tag, vlan1-tag, vlan2-tag) и число тегов в кадре (vlan-depth)
MPLS	Число MPLS-меток в кадре (mpls-depth)
IPv4 / IPv6	Адрес или подсеть источника и назначения — с префиксом или маской
IP-протокол	Значение поля протокола (ip-proto)
Порты L4	Порты источника и назначения TCP и UDP, а также SCTP, DCCP и UDP-Lite
MAC-адреса	MAC-адрес источника и назначения, в том числе с маской
Тип кадра	EtherType (packet-type) и поля LLC

В одном правиле можно комбинировать несколько условий, например VLAN и IPv4-подсеть. Настройка правил описана в разделе 8.7.

6.5. Балансировка трафика

6.5.1. Хэш-сумма: source IP + destination IP + протокол

Трафик распределяется по filter groups на основе хэш-суммы от трёх полей IP-пакета:

1. Source IP — адрес источника;
2. Destination IP — адрес назначения;
3. IP-протокол — номер протокола (TCP, UDP и т. д.).

В новых версиях ПО метод хэширования задаётся для всего устройства параметром ecofilter-balancer balancing-method; описанной схеме соответствует метод layer-3, он же используется по умолчанию, а в качестве хэш-функции производитель указывает CRC32. Доступны и другие методы — только по адресу назначения (dst-ip) и с добавлением портов TCP/UDP (layer-4), — но в ТСПУ используется балансировка по адресам и протоколу.

Для вычисления хэша балансировщик разбирает стек инкапсуляции и добирается до IP-заголовка (раздел 6.7). Если IP-пакет не найден, трафик пропускается прозрачно и на фильтры не отправляется.

Балансировка работает за счёт огромного количества разных сочетаний «адрес источника — адрес назначения — протокол», реально встречающихся в операторском трафике: когда таких сочетаний много и ни одно из них не несёт заметной доли трафика, хэш распределяет нагрузку по всем filter groups и ядрам достаточно равномерно.

Обратная сторона: порты TCP/UDP в хэш не входят, поэтому весь трафик между одной парой адресов по одному протоколу — сколько бы соединений в нём ни было — попадает на одну пару портов одного фильтра и на одно его ядро. Разбалансировать такой поток невозможно: если, например, 200 Гбит/с идут с одного адреса на один адрес по одному протоколу, весь этот трафик будет направлен в одну пару портов и на одно ядро одного фильтра — и в пару портов 10G он физически не поместится. Это стоит учитывать для адресов, за которыми стоит много абонентов, — например, при установке ТСПУ после CGNAT (раздел 3.3): трафик многих абонентов с одного внешнего адреса к одному и тому же ресурсу (узлу CDN, кэш-серверу, популярному сервису) попадает на одно ядро.

6.5.2. Учёт количества ядер фильтров

Параметр nat-unit-queues задаёт количество ядер на подключённых фильтрах, которые занимаются обработкой трафика. Это значение всегда равно общему количеству ядер процессора фильтра минус один: все ядра, кроме одного, отданы процессу EcoNAT, обрабатывающему трафик, а одно ядро сервисное — на нём работают Linux, системные логи и управление.

Параметр напрямую влияет на балансировку: он учитывается при вычислении хэша, чтобы трафик равномерно распределялся не только между фильтрами, но и между ядрами каждого фильтра. В новых версиях ПО число ядер задаётся в настройках группы балансировки (параметр cores, по умолчанию 1 — поэтому значение нужно задавать явно). Настройка — в разделе 8.5.2.

6.5.3. Дополнительный 4-байтный заголовок для фильтров

В точке балансировки к пакету добавляется дополнительный 4-байтный заголовок. По структуре он похож на VLAN-тег, но VLAN-тегом не является. Заголовок выполняет две функции:

1. Для фильтра — сообщает, на какое ядро направить пакет для обработки;
2. Для балансировщика — при возврате обработанного пакета от фильтра указывает, в какой операторский линк его вернуть.

Фильтр возвращает пакет с тем же 4-байтным заголовком. Балансировщик считывает заголовок, определяет исходный линк, удаляет заголовок и отправляет пакет обратно оператору.

В эшелонированной системе вместо этого заголовка используется VLAN-тег: балансировщик Eco Highway помечает им трафик, а фильтр после обработки меняет его на другой (раздел 4.3.3).

Из-за 4-байтного заголовка кадры на участке между балансировщиком и фильтром на 4 байта длиннее исходных: максимальный кадр оператора вместе с заголовком должен укладываться в MTU портов балансировщика в сторону фильтров и в L2 MTU фильтра, иначе крупные кадры будут отбрасываться. В проекте на портах балансировщика выставляется MTU около 9000 байт (по умолчанию 9000, платформа допускает до 10240), а на фильтрах — L2 MTU 9216 (раздел 15.2.4); если оператор использует кадры крупнее, MTU нужно согласовать при проектировании.

6.5.4. Симметричность хэша: одна сессия — один фильтр, одно ядро

Хэш вычисляется симметрично: у обратного пакета (от интернета к абоненту) адреса источника и назначения поменялись местами, но итоговое значение совпадает со значением для прямого пакета. Сама функция CRC32 несимметрична, так что симметрию обеспечивает способ формирования входных данных хэша.

Это гарантирует:

• оба направления одной сессии всегда попадают на один и тот же фильтр;
• более того — на одно и то же ядро этого фильтра, а если оба направления проходят через один балансировщик, — и на одну и ту же пару портов;
• сессия никогда не распределяется по разным фильтрам.

Благодаря этому фильтр всегда видит полную картину сессии — и запрос, и ответ, — что необходимо для корректного распознавания трафика и применения политик. Распределение детерминировано, пока состав группы балансировки не меняется (раздел 6.6.3).

Балансировщик не ведёт логов о том, куда отправлен конкретный пакет: балансировка выполняется аппаратно, программируемым чипом, на скорости провода. Чтобы найти, на каком фильтре обслуживается сессия абонента, нужно обойти фильтры площадки — вручную, если их два-три, или простым скриптом, если их много (на некоторых площадках — около полутора десятков); скрипт справляется примерно за десяток секунд (раздел 23.2).

6.6. Отказоустойчивость

6.6.1. Keep-alive пакеты к фильтрам

Балансировщик непрерывно проверяет каждую filter group keep-alive-пакетами. С байпасами Silicom это второй, независимый от heartbeat байпаса контур контроля: heartbeat байпаса проверяет канал до балансировщика и дальше него не проходит, а keep-alive балансировщика — путь до фильтра и обратно (раздел 5.4).

Принцип работы:

1. Балансировщик отправляет keep-alive-пакеты в оба порта filter group — в LAN-порт и в WAN-порт;
2. Пакет проходит через фильтр: keep-alive — служебный не-IP-пакет, и фильтр передаёт его в парный порт сразу, на первой же проверке («IP-пакет или нет»);
3. Пакет возвращается на балансировщик через парный порт той же filter group;
4. Балансировщик фиксирует время прохождения — time-on-path, в наносекундах, отдельно для каждого направления (в ранних версиях ПО — to-lan и to-wan в состоянии filter group, в новых — по портам в выводе show liveness profile-status). Например, 27 000 нс, то есть 27 мкс (раздел 9.6.2).

На фильтре принятые keep-alive-пакеты учитываются счётчиком cr_pass_ecobalancer_keepalive — по нему можно убедиться, что пакеты балансировщика до фильтра доходят.

Keep-alive проверяют не только физический канал, но и то, что фильтр продолжает обрабатывать трафик: даже первую проверку («IP-пакет или нет») выполняет процессор фильтра, поэтому если фильтр завис или перегружен настолько, что не пропускает пакеты, keep-alive не вернётся. Оценивать загрузку фильтра — не основная задача keep-alive, однако сильно перегруженный фильтр — например, при загрузке таблиц сессий заметно выше рекомендованных 20 % — теоретически может начать терять и их (раздел 9.6).

Параметры проверки задаются в профиле Keep-Alive (liveness profile), который привязывается к группе балансировки:

Параметр	Назначение
initial-delay	Допустимая задержка keep-alive, мс (см. примечание ниже)
interval	Периодичность отправки keep-alive-пакетов, мс
probes-down-count	Число последовательных потерь, после которого пара портов считается неактивной (DOWN): её трафик уходит в программный байпас, а при включённой перебалансировке перераспределяется по остальным парам
probes-up-count	Число последовательно полученных keep-alive, после которого пара возвращается в работу
active-pairs	Минимальное число активных пар, при котором группа балансировки целиком считается рабочей

В типовой конфигурации keep-alive отправляются каждые 100 мс, а пара портов считается неактивной после пяти последовательных потерь.

Примечание. Параметр initial-delay трактуется по-разному. В руководстве производителя он описан как максимально допустимая задержка между keep-alive-пакетами: при её превышении срабатывает счётчик потерь probes-down-count. По названию же и по эксплуатационным описаниям это пауза после загрузки балансировщика или поднятия интерфейсов в сторону фильтров, перед началом отправки keep-alive, — чтобы фильтр успел инициализировать интерфейсы (например, 1000 мс). От трактовки зависит и время обнаружения отказа: если это порог задержки, отказ фиксируется не раньше, чем через initial-delay (по умолчанию 8000 мс, в примерах производителя — 6000 мс), а не через interval × probes-down-count. Точное поведение стоит проверять для используемой версии ПО.

Когда число активных пар в группе балансировки опускается ниже active-pairs, неактивной считается вся группа: её состояние становится bypass, и весь её трафик возвращается оператору без обработки.

В пилотном проекте на Урале значение active-pairs было равно общему числу пар в сторону фильтров, поэтому проблема с одним-единственным интерфейсом переводила всю группу балансировки в неактивное состояние. Балансировщик прекращал отправку heartbeat-пакетов на оптический байпас GL Sun, и вся площадка уходила в аппаратный байпас с флапом линков у оператора (раздел 5.3.1). Такое значение не обязательно — порог можно задать гибче.

6.6.2. Программный байпас при потере группы портов

При потере keep-alive для конкретной filter group балансировщик переводит эту пару портов в программный байпас: трафик, который по хэшу приходится на неё, не отправляется на фильтр, а сразу перекладывается с входного порта линка на парный и возвращается оператору.

Ключевые особенности:

• программный байпас применяется индивидуально к каждой filter group — остальные пары продолжают работать;
• переключение не вызывает флапов линков оператора — оператор ничего не замечает;
• основное последствие — часть трафика временно не фильтруется; кроме того, возможны кратковременные потери пакетов — пока неисправность ещё не обнаружена и в момент переключения, а после возврата пары в работу сессии, открытые во время байпаса, приходят на фильтр «с середины»;
• когда keep-alive снова начинают проходить, пара автоматически возвращается в работу (если перебалансировка выключена);
• о переключении балансировщик пишет в журнал. В стандартный набор SNMP-трапов (перезагрузка, авторизация, состояние физических портов, блоки питания) такое событие не входит; в новых версиях ПО трап на изменение состояния можно настроить отдельно (условие xpath). Так система мониторинга узнаёт о проблеме, и её можно устранить.

Это значительное улучшение по сравнению с пилотным проектом на Урале, где потеря хотя бы одного интерфейса переводила всю площадку в аппаратный байпас с флапом линков у оператора (раздел 6.6.1), а возврат в работу требовал повторного флапа.

Программный байпас можно включить и вручную — для диагностики или на время технических работ. Вручную переключается группа балансировки целиком: в новых версиях ПО это команда call ecofilter-balancer set-bypass-ecofilter-unit с режимами auto (штатная работа: трафик идёт на фильтры, пока группа активна), bypass (весь трафик группы идёт мимо фильтров) и primary (трафик принудительно направляется на фильтры) (раздел 9.7); команды ручного переключения перенесены в EcoFilter Balancer из программного байпаса Eco Highway. Так можно одной командой исключить ТСПУ из обработки трафика без какого-либо влияния на линки оператора; такой режим применялся при испытаниях эшелонированной системы.

Если фильтр перегружен и теряет keep-alive, filter group может периодически переключаться между работой и программным байпасом. Физических флапов у оператора это не вызывает, но при каждом переключении теряется небольшое количество пакетов (раздел 9.6). Чтобы перегрузку заметить раньше, система мониторинга должна отслеживать загрузку таблиц на фильтрах и срабатывать на превышение оптимального значения.

6.6.3. Перебалансировка трафика (опционально)

Альтернатива программному байпасу — перебалансировка (параметр группы балансировки rebalance): трафик пропавшей filter group перераспределяется по оставшимся рабочим парам портов. В примерах конфигурации перебалансировка включена, но в проекте её планируется выключить, поскольку:

• перебалансировка занимает время и вычислительные ресурсы;
• хэш пересчитывается для всех сессий, и сессии могут перейти на другие пары портов и другие фильтры;
• новый фильтр видит такие сессии «с середины», без начального обмена, а контекст анализа на прежнем фильтре теряется; чтобы такие сессии вообще заводились в обработку, на фильтрах должен быть включён приём TCP-сессий без SYN (раздел 15.2.6).

Производитель описывает этот режим как резервирование N+X: неисправный фильтр исключается из группы балансировки, его потоки перераспределяются между исправными, а при выходе из строя всех фильтров срабатывает режим bypass. В проекте резервирование фильтров по схеме N+1 не предусмотрено: число фильтров рассчитывается так, чтобы пропустить трафик оператора в худшем сценарии; допустим ли при этом выход из строя одного фильтра, определяется расчётом мощностей конкретной площадки (раздел 1.4).

Рекомендуемый подход для федерального проекта — программный байпас на уровне отдельной filter group без перебалансировки. Часть трафика временно не фильтруется, но это меньшее зло, чем флап линков оператора или массовый переезд сессий.

6.7. Работа с различными инкапсуляциями (VLAN, MPLS)

Балансировщик не снимает и не модифицирует теги, метки и другие заголовки инкапсуляции — он только читает их, чтобы добраться до IP-заголовка. По документации производителя балансировщик разбирает:

• до трёх VLAN-тегов (802.1Q, QinQ);
• до шести MPLS-меток;
• PPPoE;
• туннели GRE и IP-in-IP —

и находит в них пакеты IPv4 и IPv6.

Заголовки инкапсуляции можно использовать в условиях правил: значения VLAN-тегов и их число, число MPLS-меток (раздел 6.4.2). Отбора по значениям MPLS-меток среди условий нет, да он и не был бы надёжным: значения меток на линке назначает соседний маршрутизатор оператора (при LDP и RSVP-TE — динамически), и они могут меняться при перестроении LSP.

Балансировщик сам разбирает сложную инкапсуляцию — множество тегов и меток — и сам выбирает ядро фильтра, сообщая его в 4-байтном заголовке, поэтому распределять такой трафик по ядрам фильтру не нужно. Это облегчает работу фильтра, у которого ограничений на типы инкапсуляции и их балансировку больше. Разбирать заголовки для анализа фильтр всё равно должен сам и работает только с IP-пакетом; глубина разбора VLAN-тегов на фильтре задаётся параметром VLAN Mode (раздел 15.2.1).

На фильтр пакет уходит с исходным стеком заголовков и добавленным 4-байтным заголовком балансировки, а обратно оператору — с тем же стеком, с каким пришёл. Кадры, в которых IP-пакет не найден, на фильтры не отправляются и прозрачно передаются в парный порт линка. Heartbeat-пакеты байпаса Silicom также до фильтров не доходят — балансировщик передаёт их между парными портами.

6.8. Обработка HTTP-редиректов и TCP Reset через фильтры

При блокировке ресурса фильтр отправляет абоненту HTTP-редирект (перенаправление на страницу-заглушку; по документации производителя — ответ «307 Temporary Redirect») для HTTP или TCP Reset для HTTPS: подменить содержимое зашифрованного соединения невозможно, а сам ресурс определяется по SNI в ClientHello (раздел 17.5.3). Для трафика без MPLS-меток фильтр формирует такой пакет сам.

С MPLS-трафиком так не получается. MPLS-путь однонаправлен: метки, с которыми пакет абонента пришёл на фильтр, действительны только для направления в сторону интернета, а стек меток обратного направления фильтру неизвестен — собранный им самим пакет оборудование оператора отбросит или доставит не туда. Поэтому для трафика с MPLS-метками используется другая логика:

1. Пакет абонента к ресурсу пропускается как есть;
2. Фильтр ожидает обратный пакет от ресурса в рамках той же сессии;
3. Обратный пакет приходит уже с правильными метками обратного направления, и фильтр подменяет его содержимое на HTTP-редирект или TCP Reset, сохраняя метки;
4. Балансировщик по 4-байтному заголовку возвращает модифицированный пакет в тот же линк, и пакет доходит до абонента с корректной инкапсуляцией.

Роль балансировщика здесь двоякая. Разбирая стек меток и вычисляя симметричный хэш по IP-адресам под ними, он приводит ответ сервера на тот же фильтр и то же ядро, которые обработали запрос абонента, хотя метки у ответа другие. А при возврате он не трогает метки и отправляет пакет строго в исходный линк, поэтому подменённый ответ проходит ровно тем же путём, что и настоящий ответ сервера. Решение о блокировке и отправке редиректа или Reset принимает фильтр (раздел 10.1.5).

---

← Оглавление · ← Раздел 5: Байпас · Раздел 7: Балансировщик: аппаратная платформа →