Подтвердить что ты не робот

Около 502 ошибок в GCP HTTP Load Balancing

Наш баланс нагрузки возвращает 502 ошибки для некоторых запросов. Это всего лишь очень низкий процент от общего количества запросов, у нас около 36000 запросов в час и около 40 ошибок в час, поэтому только 0,01% запросов возвращает ошибку.

При возникновении ошибки экземпляры здоровы, и мы добавили это правило пересылки в брандмауэр для балансировщика нагрузки: 130.211.0.0/22 ​​tcp: 1-5000 Применить ко всем целям

Это не очень серьезная проблема, потому что приложение допускает такие ошибки, но я хотел бы знать, почему они даются.

Любая помощь будет оценена.

4b9b3361

Ответ 1

Кажется, что для этого нет простого решения.

Как объясняет Майк Фотинакис в этот блог (спасибо за эту информацию JasonG:)):

Оказывается, что существует условие гонки между облачным балансировщиком нагрузки Google Cloud (S) и временем ожидания keep-alive по умолчанию для NGINX, равным 65 секундам. Тайм-аут NGINX может быть достигнут в то же время, когда балансировщик нагрузки пытается повторно использовать соединение для другого HTTP-запроса, что нарушает соединение и приводит к ответу 502 Bad Gateway от балансировщика нагрузки.

В моем случае я использую Apache с модулем mpm_prefork. Предлагаемое решение заключается в увеличении тайм-аута keepalive соединения до 650 с, но это невозможно, поскольку каждое соединение открывает один новый процесс (поэтому это будет представлять собой огромную трату ресурсов).

UPDATE:
Кажется, что есть некоторая новая документация об этой проблеме на официальной странице документации балансировки нагрузки (поиск "Тайм-ауты и повторы" ): https://cloud.google.com/compute/docs/load-balancing/http/

Они рекомендуют установить значение KeepAliveTimeout равным 620 в обоих случаях (Apache и Nginx).

Ответ 2

У меня была проблема w/502s, которая была необъяснимой после воссоздания балансировки нагрузки и конфигурации бэкэнд. Я воссоздал свою бэкэнд и группу экземпляров для неуправляемых экземпляров, и это, похоже, исправить проблему для меня. Я не смог идентифицировать какие-либо проблемы в моей конфигурации в GCP: (

Но у меня было намного больше ошибок - 1/10. Существуют журналы балансировки нагрузки, которые расскажут вам, что является причиной, и объясняет причины причин.

Например, мои были: jsonPayload: {statusDetails: "failed_to_pick_backend" @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBal ancerLogEntry" }

Если вы используете nginx и его на POSTS, и ошибка сообщается как "backend_connection_closed_before_data_sent_to_client", это может быть исправлено путем изменения тайм-аутов nginx. Смотрите это отличное сообщение в блоге:

https://blog.percy.io/tuning-nginx-behind-google-cloud-platform-http-s-load-balancer-305982ddb340#.btzyusgi6

Ответ 3

проверка, блокирует ли ваш брандмауэр брандмауэр IP-адрес cdn облака Google (не только 130.211.0.0/22), все эти адреса можно найти здесь: https://cloud.google.com/compute/docs/faq#find_ip_range