Я вижу проблему во время тестирования производительности нашего приложения. Проблема в том, что LoadBalancer не может сопоставить TCP-соединение между клиентом и LB с TCP-соединением между LB и поддерживаемым экземпляром.
Когда клиент отправляет HTTP-запрос в первый раз, LB открывает новое TCP-соединение с резервным экземпляром, но когда тот же клиент отправляет другой HTTP-запрос, LB также создает новое TCP-соединение с внутренним экземпляром. Когда мы выполняем тот же сценарий, напрямую отправляя запросы от клиента к внутреннему экземпляру, то же TCP-соединение используется повторно.
У нас есть ограничение на количество открытых TCP-соединений для каждого процесса в поддерживаемом экземпляре, поэтому мы хотим знать следующее.
Почему LB использует диапазон IP-адресов при отправке запросов на резервные серверы и где он настроен? Как LB сопоставляет TCP-соединения клиентов с внутренними TCP-соединениями? Если отображения нет, то каков предел открытых TCP-соединений, наложенный LB. Какой код ответа возвращает LB в случае сброса соединения поддерживаемым экземпляром? Какой код ответа возвращает LB в случае, если очередь резервных журналов SYN резервного сервера заполнена.
Кажется, на эти вопросы уже были даны ответы в это обсуждение. Я повторно публикую здесь предоставленные ответы:
«Клиентские запросы обрабатываются набором балансировщиков нагрузки, поэтому вы увидите изменения на напрямую подключенном хосте при обработке потока запросов от клиента.
Трафик с клиентского IP-адреса будет обрабатываться подмножеством глобального пула балансировщика нагрузки, но, судя по звучанию вашего вопроса, даже это подмножество оказывается слишком большим, чтобы привести к многократному использованию бэкэнд-соединения TCP. Есть некоторые скрытые параметры балансировщика нагрузки, которые влияют на количество подключений, созданных к бэкэндам, и обстоятельства, когда балансировщик нагрузки может использовать существующие подключения для обработки новых запросов. Эти внутренние параметры могут измениться в будущем, чтобы уменьшить количество TCP-соединений, необходимых между балансировщиком нагрузки и бэкэндами. А до тех пор, если разрешить больше соединений на сервере и увеличить время ожидания для этих соединений, это должно увеличить повторное использование соединений на сервере.
Включение привязки сеанса с помощью IP-адреса клиента или сгенерированного файла cookie приведет к тому, что LB будет использовать определенный серверный модуль при обработке трафика от клиента, но вы все равно будете видеть трафик, поступающий с нескольких IP-адресов LB. В отсутствие привязки сеанса фактически не существует сопоставления между IP-адресами клиента и серверными виртуальными машинами. Инструкции о том, как включить привязку сеанса, см .: https://cloud.google.com/compute/docs/load-balancing/http/#session_affinity
LB ответит кодом ответа 502, если он не сможет получить ответ от бэкэнда. Балансировщик нагрузки будет рассматривать бэкэнд как неработоспособный и направлять трафик на другие доступные работоспособные серверные ВМ. Если нет исправных серверных ВМ, балансировщик нагрузки ответит 502 после тайм-аута. "