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