Насколько мне известно, балансировщик нагрузки L4 поддерживает 2 TCP-соединения:
В HTTP2 / gGPRC клиент-сервер поддерживает одно долгое соединение. Если мы используем L4, это соединение будет первым из упомянутых выше.
В некоторых статьях я читал, что, хотя есть несколько развернутых внутренних серверов, как только один клиент делает первый запрос к одному бэкэнду, эта пара клиент-бэкэнд будет сохраняться для всех последующих запросов. Это означает, что другие серверы не используются.
Вот одна из статей: https://blog.bugsnag.com/envoy/
gRPC использует протокол HTTP / 2 с повышенной производительностью. Одним из многих способов достижения HTTP / 2 более низкой задержки, чем его предшественник, является использование одного долговременного TCP-соединения и мультиплексирование запросов / ответов через него. Это вызывает проблему для балансировщиков нагрузки уровня 4 (L4), поскольку они работают на слишком низком уровне, чтобы иметь возможность принимать решения о маршрутизации на основе типа полученного трафика. Таким образом, балансировщик нагрузки L4, пытаясь сбалансировать нагрузку HTTP / 2-трафика, открывает одно TCP-соединение и направляет весь последующий трафик в это же долгоживущее соединение, фактически отменяя балансировку нагрузки.
Мне действительно неясно этот момент. Кто-нибудь может объяснить более подробную информацию? Многие ценят! Спасибо
Я думаю, у вас есть небольшая путаница относительно уровня 4 (подумайте о LVS и маршрутизации) и уровня 7 (HAProxy). HAProxy в режиме TCP похож на балансировщик нагрузки уровня 4, НО он создает два соединения. Правильные балансировщики нагрузки уровня 4 просто маршрутизируют пакеты (без новых подключений).
Ты можешь использовать любой режим для сквозной передачи HTTP2, и он будет работать очень хорошо. НО HAProxy, очевидно, потеряет прозрачность исходного IP-адреса, потому что это прокси, а не маршрутизатор.
HAProxy теперь также поддерживает HTTP2 во внешнем интерфейсе, но здесь, на Loadbalancer.org, мы обычно рекомендуем придерживаться сквозной передачи L4 большую часть времени, потому что это быстро и надежно.
Если у вас больше клиентов, чем внутренних серверов, это может не быть проблемой. Попробуйте алгоритм наименьшего соединения, например, "минимум соединения" от haproxy. Придумывая пример, возможно, ваши 10 коммутаторов потоковых данных метрик через gRPC в 3 внутренних узла вашей платформы мониторинга. Каждому бэкэнду нужно поработать.
Даже если у вас только одно соединение, это все равно может не быть проблемой, если с ним справится один узел. Фактически это становится активной / пассивной конфигурацией. Вам решать, стоит ли бездействовать этот хост.
Тем не менее, иногда балансировщики нагрузки проверяют приложение на уровне 7. Типичным примером HTTP является привязка файлов cookie. Однако уровень 7 не требуется для долгоживущих соединений.