Вопрос или проблема
У меня есть 3 экземпляра (node-0, node-1, node-2), работающих с 2 сервисами – один из них это websocket, а другой API (оба сервиса работают на каждом экземпляре).
Настройка целевой группы:
| Целевая группа | Экземпляр | Путь проверки работоспособности |
|---|---|---|
| api-node-0 | node-0 | /some-path/api/v1/ping |
| api-node-1 | node-1 | /some-path/api/v1/ping |
| api-node-2 | node-2 | /some-path/api/v1/ping |
| websocket-node-0 | node-0 | /some-path/websocket/v1/ping |
| websocket-node-1 | node-1 | /some-path/websocket/v1/ping |
| websocket-node-2 | node-2 | /some-path/websocket/v1/ping |
Слушатель и правила:
Слушатель HTTPS:443
Правила:
api
- Условие: Путь
/some-path/api/* - Действие: Перенаправить на целевую группу:
- api-node-0 (33.33%)
- api-node-1 (33.33%)
- api-node-2 (33.33%)
- Привязка: Выключено
websocket
- Условие: Путь
/some-path/websocket/* - Действие: Перенаправить на целевую группу:
- websocket-node-0 (33.33%)
- websocket-node-1 (33.33%)
- websocket-node-2 (33.33%)
- Привязка: Выключено
по умолчанию
- Условие: Не применяется ни одно другое правило
- Действие: Перенаправить на целевую группу:
- api-node-0 (100%)
Атрибуты проверки работоспособности:
- Интервал: 30 секунд
- Тайм-аут: 5 секунд
- Порог здоровых: 2
- Порог нездоровых: 2
- Порог здоровых: 2 последовательных успешных проверок работоспособности
- Порог нездоровых: 2 последовательных неуспешных проверки работоспособности
- Коды успешности: 200
Атрибуты балансировщика нагрузки:
- Продолжительность хранения клиента HTTP: 3600 секунд
- Тайм-аут бездействия соединения: 60 секунд
- Заголовок X-Forwarded-For: Добавить
- Балансировка нагрузки между зонами: Включена
П.С. Если вам нужна дополнительная информация о настройке, пожалуйста, дайте знать.
Во время нормального тестирования, когда все целевые группы здоровы, ALB работает как и ожидалось. Проблема возникает, когда я хочу смоделировать ситуацию, когда один из сервисов на узле становится нездоровым; я изменил путь проверки работоспособности, например, api-node-1, он отображается как нездоровый (Ошибка 404), но трафик по-прежнему отправляется на него. Подтверждено как через журналы доступа, так и через метрики CloudWatch (RequestCountPerTarget). Я также попытался смоделировать нездоровую группу, заблокировав доступ ALB, удалив соответствующую группу безопасности с экземпляра. (Ошибка 400)
Методы тестирования (с нездоровой целевой группой): Используя curl (10-20 раз) или нагрузочное тестирование Grafana k6 и мониторинг трафика как в журналах доступа, так и в Cloudwatch – трафик все еще перенаправлялся на все экземпляры, и один из них был показан как нездоровый.
Вы можете найти другой вопрос, обсуждающий эту проблему, перейдя по ссылке.
Ответ или решение
Судя по описанному вами сценарию, у вас возникла проблема с тем, что AWS Application Load Balancer (ALB) продолжает отправлять трафик на целевые группы, которые показываются как unhealthy (нездоровые), несмотря на то, что вы изменили путь проверки здоровья. Давайте проанализируем возможные причины этой ситуации и предложим решения.
Возможные причины проблемы:
-
Настройки проверки состояния (health check):
- Убедитесь, что для целевой группы установлены правильные параметры проверки состояния, включая правильный путь запроса, порт и ожидаемые коды состояния. В вашем случае, если вы изменяете путь для
api-node-1и получаете код 404, это может указывать на то, что проверка состояния не проходит и экземпляр должен считаться unhealthy.
- Убедитесь, что для целевой группы установлены правильные параметры проверки состояния, включая правильный путь запроса, порт и ожидаемые коды состояния. В вашем случае, если вы изменяете путь для
-
Параметры баланса нагрузки (load balancing settings):
- По умолчанию, ALB может продолжать отправлять трафик на unhealthy целевые группы в течение некоторого времени после того, как они были помечены как unhealthy. Это может произойти из-за того, что ваш балансировщик нагрузки продолжает хранить информацию о целевых группах, которые были healthy, до тех пор, пока не истечет время проверки.
- В вашем случае healthy threshold и unhealthy threshold установлены на 2, что означает, что ALB должен увидеть два последовательных успешных или неуспешных ответа перед изменением статуса целевой группы.
-
Кэширование и настройки кэширования:
- Не исключено, что существуют внешние механизмы кэширования, либо на вашем приложении, либо в сети, которые могут искажать поведение. Убедитесь, что ваш API и WebSocket службы правильно управляют кэшированием.
-
Безопасные группы (Security Groups):
- Если вы удалили группу безопасности, которая обеспечивает доступ к экземпляру, убедитесь, что у ALB установлен соответствующий разрешающий правило в своих настройках, чтобы предотвратить блокировку доступа.
Рекомендации по решению проблемы:
-
Проверка параметров:
- Вернитесь и убедитесь, что все параметры проверки состояния настроены корректно, особенно путь и коды состояния. Возможно, стоит временно настроить другой (например, 200) путь проверки, чтобы увидеть, приведет ли это к изменению поведения ALB.
-
Мониторинг времени отклика:
- Следите за временем отклика экземпляров через CloudWatch и убедитесь, что они действительно отвечают в пределах таймаута 5 секунд.
-
Обновление конфигураций и правил:
- Если это возможно, настройте правило по умолчанию ALB для определенного целевого экземпляра для управления трафиком более точно или измените распределение веса между целевыми группами.
-
Логи и аудит:
- Проверьте логи доступа и запросов ALB, чтобы детали запросов к unhealthy целевым группам выглядели так, как вы ожидаете. Это может дать вам больше информации о том, как ALB обрабатывает трафик.
-
Проверка обновлений AWS:
- Убедитесь, что нет известных проблем или недоступностей со стороны AWS, которые могут повлиять на функционирование ALB.
Итог:
Эти рекомендации должны помочь вам разобраться с проблемой. Если у вас все еще возникают трудности после выполнения этого анализа, рассмотрите возможность обращения в службу поддержки AWS для более детального изучения проблемы, так как они могут предложить специфическую помощь по вашему конкретному окружению.