Пропускать каждый сервис через Layer-7 — неправильный подход для L4-трафика, которому нужна низкая задержка.
Корпоративный трафик состоит не только из HTTP-приложений. DNS, SIP, RADIUS, NTP, сырые TCP-сервисы, туннельные протоколы и высокообъёмные стриминг-потоки ведут себя по-разному. В этих сервисах важнее не обработка контента, а низкая задержка, низкое потребление CPU, быстрое решение и правильный обратный путь.
Когда L4- и L7-балансировка управляются как отдельные продукты, отдельные консоли или отдельные уровни лицензий, эксплуатация усложняется. Команде приходится управлять отдельным сетевым компонентом для DNS- и UDP-сервисов, отдельным ADC для веб-приложений, отдельным слоем для безопасности. В момент проблемы даже вопрос «какой трафик прошёл через какой продукт» отнимает время.
UDP-трафик требует особого внимания. Поскольку состояние соединения не так очевидно, как у TCP, persistence, поведение исходного IP, эффект NAT и обратный путь backend должны быть спроектированы правильно. В протоколах вроде SIP сессия должна оставаться на том же сервисе, тогда как в сервисах вроде DNS и NTP на первый план выходит минимально возможная задержка.
Режимы вроде прямого возврата и IP-туннеля дают большое преимущество при правильной настройке; но если сетевые требования не ясны, они создают проблемы. В режиме прямой маршрутизации на backend должны быть верно настроены VIP loopback alias, поведение ARP и обратный путь. Иначе вместо выигрыша в производительности возникает проблема доступности.
Режимы L4 TR7 собирают низколатентное распределение трафика на уровне пакетов, выбор режима под разные сетевые топологии и смешанную работу L4+L7 под единой моделью управления ADC.
Наш подход
TR7 обрабатывает L4-трафик на уровне пакетов, предоставляя централизованное управление режимом, алгоритмом, проверкой здоровья и смешанными сервисами.
L4-движок на уровне пакетов обеспечивает низкую задержку
TR7 использует инфраструктуру LVS/IPVS для L4-балансировки нагрузки. Этот подход снижает накладные расходы обработки в пространстве пользователя и обеспечивает быстрое принятие решений по TCP- и UDP-трафику.
Оркестрационный слой L4 TR7 управляет пулами сервисов
Для каждого L4-пула сервисов настраиваются протокол, алгоритм, список backend, вес, лимит соединений и проверка здоровья. Оркестрационный слой L4 TR7 преобразует эту конфигурацию в исполняемое поведение L4-балансировки.
Выбор режима делается по сетевой топологии
Режимы NAT, SNAT, прямой маршрутизации, IP-туннеля и общей переадресации протоколов служат разным потребностям. Оператор выбирает подходящий режим по обратному пути трафика, сохранению исходного IP и размещению backend.
L4- и L7-сервисы работают вместе на одном устройстве
На одном TR7 L7-сервисы на основе HTTP/TCP и L4-сервисы на основе IPVS могут работать бок о бок. Так на одном VIP разные порты можно направлять на разные движки обработки.
Возможности
Режимы L4 TR7 предлагают гибкие опции балансировки для разных протоколов, сетевых топологий и поведения сервисов.
Пять режимов работы L4 поддерживают разные сетевые проекты
TR7 поддерживает режимы NAT, SNAT, прямой маршрутизации, IP-туннеля и общей переадресации протоколов. В режиме NAT обратный трафик проходит через балансировщик нагрузки. В режиме прямой маршрутизации обратный путь течёт прямо от backend к клиенту. Режим IP-туннеля можно использовать в сценариях, требующих удалённой локации или перехода через другую сеть.
Выбор протокола TCP и UDP делается на уровне пула сервисов
L4-пул сервисов можно определить с протоколом TCP или UDP. UDP-сервисы вроде DNS, SIP, RADIUS и NTP можно балансировать, не принуждая их к L7-конвейеру обработки. TCP-сервисы можно использовать для низколатентного распределения по портам. Каждый пул работает по логике одного протокола — просто и предсказуемо.
Шесть алгоритмов IPVS предлагают разные стратегии распределения
TR7 поддерживает алгоритмы round robin, weighted round robin, least connection, weighted least connection, source hash и destination hash. Взвешенные алгоритмы можно использовать, чтобы направлять больше трафика на более мощные backend. Алгоритмы на основе хеша упрощают направление одного и того же источника или назначения на тот же сервис. Эти алгоритмы работают в L4-пулах независимо от L7-алгоритмов.
Настройки persistence держат сессию на правильном сервисе
Для persistence на основе исходного IP можно задать значение timeout. Подход по умолчанию обеспечивает направление одного источника на тот же backend в течение определённого времени. Для SIP-трафика можно использовать движок persistence на основе call-id. Эта схема помогает предотвратить разрыв поведения сессий на основе UDP.
Проверка здоровья привязывает доступность backend к L4-решению
L4-пулами сервисов можно управлять вместе с проверкой здоровья. Механизм проверки здоровья L4 может выводить непригодные backend из распределения. Через проверку на основе HTTP можно мониторить API управления или специальную конечную точку здоровья. Так L4-решения принимаются не только по определению порта, но и по реальной пригодности сервиса.
Вес и лимит соединений можно применять на каждый backend
Для каждого backend можно задать значение weight, и во взвешенных алгоритмах доля трафика определяется по нему. Лимитом соединений можно ограничить перегрузку отдельного backend. Эта возможность обеспечивает более сбалансированное использование сервисов разной ёмкости в одном пуле. Операционная команда более контролируемо управляет процессами добавления сервисов и увеличения ёмкости.
VRRP failover делает VIP высокодоступным
Механизм VRRP failover обеспечивает перенос VIP между парой HA. При потере одного узла ADC VIP может быть перехвачен на другом узле. Для UDP-сервисов кратковременная потеря сессии в большинстве сценариев приемлема, тогда как для TCP-сервисов поведение failover должно оцениваться по структуре приложения и сессии. Эта модель привязывает L4-сервисы к архитектуре высокой доступности.
Живая статистика L4 делает долю трафика видимой
Через статистику IPVS можно мониторить показатели соединений, пакетов и полосы пропускания. Можно отслеживать мгновенный CPS, скорость входящих/исходящих пакетов и значения входящей/исходящей полосы пропускания. TR7 может производить эту статистику в формате, совместимом со структурой мониторинга платформы. Операционная команда может видеть, как L4-пулы реально несут трафик.
Режим общего протокола может переадресовывать трафик вне TCP и UDP
Режим общего протокола можно использовать в сценариях общей L3-переадресации для протоколов вне TCP и UDP. Для типов трафика вроде ESP, GRE или ICMP классическая L4-модель на основе портов может быть недостаточна. В этом режиме детальная статистика соединений ограничена; видимость обеспечивается через базовые счётчики байтов. Создаёт практичную опцию переадресации для специальных сетевых переходов.
Изоляция сетевых namespace поддерживает многоарендные L4-проекты
Настройкой L4 namespace L4-пул сервисов можно запускать в контексте отдельного сетевого namespace. Эта схема важна для организаций, желающих разделять разные арендаторы или сетевые зоны. Несколько сетевых контекстов на одном устройстве можно управлять более контролируемо. Изоляция повышает операционную безопасность в смешанных проектах развёртывания.
Операционная глубина
Для корректной работы режимов L4 нужно явно спланировать отслеживание соединений, поведение failover, требования прямой маршрутизации, ограничения статистики и управление сервисами.
Скорость на уровне пакетов
L4-балансировка нагрузки на основе IPVS подходит для сервисов, требующих низкой задержки и высокого throughput. В режиме прямой маршрутизации обратный трафик обходит балансировщик нагрузки, что даёт преимущество особенно в сервисах, производящих высокообъёмные ответы. Реальная ёмкость зависит от сетевой карты, CPU, выбора режима и топологии backend.
Планирование памяти conntrack
В UDP- и интенсивных L4-сервисах размер таблицы conntrack Linux становится критичным. Значения по умолчанию могут быть недостаточны для крупномасштабного трафика; их нужно планировать под объём трафика.
Поведение VRRP failover
VIP может переноситься между парой HA через VRRP. При потере узла сервис продолжается на другом узле. UDP-сервисы, будучи чаще всего stateless, восстанавливаются легче, тогда как для TCP-сессий поведение прерывания должно оцениваться по толерантности приложения.
Требования прямой маршрутизации
В режиме прямой маршрутизации backend должен распознавать VIP как loopback alias. Для поведения ARP важна правильная настройка параметров arp_ignore и arp_announce. Если эти требования не выполнены, вместо преимущества обратного пути может возникнуть проблема доступа.
Видимость общего протокола
В режиме общей переадресации протоколов детали per-connection ограничены. Этот режим больше отвечает потребности в специальной L3-переадресации и мониторится базовыми счётчиками байтов. Для сервисов, требующих глубокого анализа соединений, режимы TCP или UDP могут быть более подходящими.
Путь статистики L4
Статистику L4-пулов можно собирать и приводить в соответствие с общим форматом мониторинга платформы. Значения соединений, пакетов и полосы пропускания можно записывать в системы исторических записей. Это упрощает мониторинг L4-сервисов в той же операционной панели, что и L7-сервисы.
Деталь SIP NAT
В SIP UDP-трафике использование NAT может влиять на поведение исходного IP и обратного пути. Если backend хочет производить ответ клиенту напрямую, выбор режима должен делаться внимательно. Опции SIP persistence и прямой маршрутизации могут дать более подходящий проект в таких сценариях.
Мониторинг сервиса systemd
Для каждого L4-пула можно мониторить связанный сервис оркестрации L4. Статус сервиса, время работы и последнее изменение состояния ценны для операционного аудита. Эта информация помогает в изменениях конфигурации L4 и расследованиях failover.
В каких сценариях используется
Кластер DNS-рекурсоров для телекома
Телеком или сервис-провайдер может балансировать несколько backend DNS-рекурсоров на UDP 53. С отключённым persistence обеспечивается низколатентное и сбалансированное распределение DNS.
Корпоративные сервисы аутентификации RADIUS
Организация может направлять трафик UDP 1812 и 1813 алгоритмом source hash, направляя одного и того же клиента на тот же сервис аутентификации. Эта схема обеспечивает консистентный выбор сервиса в потоке аутентификации.
Липкость сессии в трафике SIP-прокси
В телеком-среде трафик UDP 5060 SIP можно балансировать с persistence на основе call-id. Направление одного потока вызова на тот же backend помогает сохранить поведение сессии.
Прямой обратный путь в стриминг-трафике
В сценарии медиа или CDN трафик TCP 80/443 можно запускать в режиме прямой маршрутизации. Поскольку обратный трафик течёт прямо от backend к клиенту, нагрузка обратного хода на балансировщике снижается.
Пул NTP-серверов
В инфраструктурных сервисах трафик UDP 123 NTP можно распределять на backend сбалансированно и с низкой задержкой через round robin. Для этого типа трафика без потребности в persistence достаточно простого определения пула.
Смешанная работа L4 и L7 под одним VIP
На одном VIP порты 80 и 443 можно направлять на движок обработки L7, а порт 53 — на движок L4 IPVS. Под одной лицензией и одной консолью обеспечивается отдельная оптимизация под смешанные типы трафика.
Часто задаваемые вопросы
Какие режимы работы L4 поддерживает TR7?
Как балансируются UDP-сервисы в режиме L4?
Каковы сетевые требования режима прямой маршрутизации?
Могут ли L4- и L7-сервисы работать вместе на одном устройстве?
Как VRRP failover влияет на L4-сервисы?
Как мониторится производительность L4-пула?
Управляйте своим L4-трафиком на уровне пакетов
Низколатентная L4-балансировка нагрузки по режимам для сервисов вроде DNS, SIP, RADIUS, NTP и стриминга. Проведём по живой установке с вашими собственными сервисами.