У меня есть группа экземпляров с 2 экземплярами за балансировщиком нагрузки HTTP. Один экземпляр работает и нормально функционирует (возвращает http 200), другой вышел из строя (истек тайм-аут HTTP-запросов). Я не уверен, что я делаю не так, но согласно документации, отказавший экземпляр должен автоматически удаляться из балансировщика нагрузки.
Вот соответствующие документы:https://cloud.google.com/compute/docs/load-balancing/health-checks с соответствующим абзацем:
Чтобы проверка работоспособности считалась успешной, бэкенд должен вернуть допустимый ответ HTTP с кодом 200 и закрыть соединение обычным образом в течение периода timeoutSec. Если экземпляр не проходит проверку работоспособности, он удаляется из группы или пула без отправки какого-либо уведомления. Если позже он проходит проверку работоспособности, он возвращается в группу или пул, снова без какого-либо уведомления.
Вот что я сейчас вижу на своей странице в Google Cloud Console для бэкэнда HTTP Load Balancer.
При посещении моего сайта (http://stage2.phantomjscloud.com) Примерно в половине случаев я получаю
Ошибка: Ошибка сервера Сервер обнаружил временную ошибку и не смог выполнить ваш запрос. Повторите попытку через 30 секунд.
Балансировщик нагрузки HTTP (и проверка работоспособности) четко обнаруживает отказавший экземпляр, но трафик все равно ему поступает.
Как я могу решить эту проблему?
решение1
проверки работоспособности управляемых групп экземпляров VS проверки работоспособности балансировки нагрузки
Проверки работоспособности, используемые управляемыми группами экземпляров, — это те же проверки работоспособности, которые используются балансировкой нагрузки, с некоторыми отличиями в поведении. Проверки работоспособности, которые вы применяете к службам балансировки нагрузки, помогают балансировщику нагрузки определить, куда направить сетевой трафик. Эти проверки работоспособности не заставляют Compute Engine повторно создавать экземпляры. Проверки работоспособности, которые вы применяете к управляемым группам экземпляров, будут заранее сигнализировать управляемой группе экземпляров об удалении и повторном создании экземпляров, если они станут НЕРАБОТОСПОСОБНЫМИ.
Для большинства сценариев используйте отдельные проверки работоспособности для балансировки нагрузки и для мониторинга управляемых групп экземпляров. Проверка работоспособности для балансировки нагрузки может и должна быть более агрессивной, поскольку эти проверки работоспособности определяют, получает ли экземпляр пользовательский трафик. Поскольку клиенты могут полагаться на ваши сервисы, вы хотите быстро отлавливать не отвечающие экземпляры, чтобы иметь возможность перенаправить трафик при необходимости. Напротив, проверка работоспособности для групп экземпляров заставит Compute Engine проактивно заменить неисправные экземпляры, чтобы вы могли создать проверки работоспособности, которые будут более консервативными, чем проверки работоспособности для балансировщика нагрузки.
решение2
Я уже давно не видел подобных ошибок (около 6 месяцев), поэтому думаю, что это ошибка Google Cloud, и они ее исправили.