Балансировщик нагрузки Http2 с использованием L4
Насколько мне известно, балансировщик нагрузки L4 поддерживает 2 TCP-соединения:
- Одно - с внешней стороны к балансировщику нагрузки
- LB завершает указанное выше соединение, создает новое TCP-соединение, изменяет IP / порт TCP-пакета для пересылки на бэкэнд.
В HTTP2 / gGPRC клиент-сервер поддерживает одно долгое соединение. If we use L4, this connection will be the first one which is mentioned above.
In some articles, I read that although there are multiple deployed backend servers, once one client makes first request to one backend, this pair client-backend will be kept for all successive requests. That means other backends are unused.
Here is one of articles: https://blog.bugsnag.com/envoy/
gRPC uses the performance boosted HTTP/2 protocol. One of the many ways HTTP/2 achieves lower latency than its predecessor is by leveraging a single long-lived TCP connection and to multiplex request/responses across it. This causes a problem for layer 4 (L4) load balancers as they operate at too low a level to be able to make routing decisions based on the type of traffic received. As such, an Балансировщик нагрузки L4, пытающийся сбалансировать нагрузку HTTP / 2-трафика, откроется одно TCP-соединение и направить весь последующий трафик к этому же долгоживущее соединение, фактически отменяющее балансировку нагрузки.
Я действительно не совсем понимаю это. Кто-нибудь может объяснить более подробную информацию? Многие ценят! Спасибо
Если у вас больше клиентов, чем внутренних серверов, это может не быть проблемой. Попробуйте алгоритм наименьшего соединения, например, "минимум соединения" от haproxy. Придумывая пример, возможно, ваши 10 коммутаторов потоковых данных метрик через gRPC на 3 внутренних узла вашей платформы мониторинга. Каждый бэкэнд получает некоторую работу.
Даже если у вас только одно соединение, это все равно может не быть проблемой, если с ним справится один узел. Фактически это становится активной / пассивной конфигурацией. Стоит ли простаивать этот хост расходов, решать вам.
Тем не менее, иногда балансировщики нагрузки проверяют приложение на уровне 7. Типичным примером HTTP является привязка файлов cookie. Однако уровень 7 не требуется для долгоживущих соединений.
Unë mendoj se keni një konfuzion të lehtë në lidhje me Shtresën 4 (Mendoni LVS dhe rutimi), dhe shtresa 7 (HAProxy). HAProxy në modalitetin TCP është e ngjashme me një ekuilibër të ngarkesës së shtresës 4 POR krijon dy lidhje. Bilancët e ngarkesës së duhur të shtresës 4 thjesht drejtojnë paketat (pa lidhje të reja).
Mund të përdorni ose mënyrën për hyrjen në HTTP2 dhe do të funksionojë shumë mirë. POR HAProxy padyshim që do të humbasë transparencën e burimit IP sepse është një përfaqësues jo një router.
HAProxy gjithashtu ka mbështetje për HTTP2 në pjesën e përparme tani, por këtu në Loadbalancer.org ne priremi të rekomandojmë që të përmbahemi më shumë nga L4 të kohës sepse është i shpejtë dhe i besueshëm.