Я пытаюсь настроить балансировку эластичной нагрузки (ELB) в AWS для разделения запросов между несколькими экземплярами. Я создал несколько изображений своего веб-сервера на основе одного и того же AMI, и я могу использовать ssh в каждом отдельно и доступ к сайту через каждый отдельный публичный DNS.
Я добавил каждый из моих экземпляров в балансировщик нагрузки, но все они возвращаются с помощью Status: Out of Service, потому что они не прошли проверку работоспособности. Я в основном смущен, потому что я могу получить доступ к каждому экземпляру из своего общего DNS, но я получаю таймаут, когда я посещаю DNS-имя балансира нагрузки.
Я пытаюсь прочитать все документы и поработать с ним, но я застрял. Любые указатели или ссылки в правильном направлении были бы с благодарностью.
Я связался с поддержкой AWS по этой же проблеме. По-видимому, их система не знает, как обращаться с делами, все экземпляры, стоящие за ELB, останавливаются в течение длительного времени. Поддержка AWS может вручную обновлять статусы, если они вам нужны немедленно.
Предлагается исправить это, чтобы отменить регистрацию экземпляров ec2 из ELB, а не просто остановить их и перерегистрировать их при повторном запуске.
Проверка работоспособности (по умолчанию) осуществляется путем обращения к index.html для каждого экземпляра, включенного в балансировщик нагрузки. Если у вас нет index.html в корневом каталоге экземпляра экземпляра - проверка работоспособности по умолчанию завершится неудачно. Вы можете настроить пользовательский протокол, порт и путь для проверки работоспособности при создании балансировки нагрузки.
Я проверил его с помощью tail -f /var/log/apache2/access.log в моем экземпляре, чтобы проверить, пытался ли балансировщик нагрузки получить доступ к моему серверу, и чтобы увидеть ответ, который сервер передает балансировщику нагрузки.
Надеюсь, что это поможет.
Если ваш веб-сервер работает нормально, значит, проверка работоспособности идет по URL-адресу, который не возвращает 200.
Трюк, который работает для меня: продолжайте экземпляр, введите curl localhost: 80/pathofyourhealthcheckurl
После того, как вы сможете настроить свой URL-адрес проверки работоспособности, всегда иметь ответ 200.
В моем случае правила групп безопасности, назначенные экземпляру и балансировщику нагрузки, не позволяли трафику проходить между ними. Это привело к сбою проверки работоспособности.
Я столкнулся с такой же проблемой, я изменил протокол Ping с https на ssl.. он сработает!
Go to Health Check --> click on Edit Health Check -- > change Ping protocol from HTTPS to SSL
Ping Target SSL:443 Timeout 5 seconds Interval 30 seconds Unhealthy Threshold 5 Healthy Threshold 10
Я хотел бы предоставить вам общий способ решения этой проблемы. Когда вы настроили свой веб-сервер, например apache или nginx, попробуйте прочитать файл журнала доступа, чтобы узнать, что произошло. По моему поводу, он сообщает 401 error, потому что я добавляю базовый auth в nginx. Конечно, точно так же, как @ivankoni напомнить, это может быть из-за документа, который вы проверяете, не существует.
Я работал над учебником AWS по размещению веб-приложения и столкнулся с этой проблемой. Шаг 7b утверждает следующее:
"Установите Ping Path в /. Это отправляет запросы на вашу страницу по умолчанию, независимо от того, он называется index.html или что-то еще."
Они могли бы поставить косую черту в котировках вроде этого "/". Удостоверьтесь, что у вас есть это в ваших проверках здоровья, а не на этом "/"..
Добавление этого, потому что я потратил часы, пытаясь понять это...
Если вы настроили конечную точку проверки работоспособности, но она все еще говорит Out of Service, это может быть потому, что ваш сервер перенаправляет запрос (т.е. возвращает ответ 301 или 302).
Например, если ваша конечная точка должна быть /app/health/, но вы вводите /app/health (без конечной косой черты) в поле конечной точки проверки работоспособности вашего ELB, вы не получите ответ 200, поэтому проверка работоспособности не удастся.
У меня была похожая проблема. Проблема, по-видимому, была вызвана тем, что я использовал проверку работоспособности HTTP, а также .htaccess для защиты паролем сайта.
Я получил ту же ошибку, в моем случае пришлось скопировать определенный HTML файл из корзины s3 в папку "/var/www/html". Тот же HTML-код, указанный в пути балансировки нагрузки.
Проблема устранена после копирования html файла.
Для всех, кто видит эту тему, поскольку ее нет в списке:
Убедитесь, что проверка работоспособности проверяет порт, который прослушивает отвечающий сервер.
Например. node.js, работающий на порте 3000 → Укажите проверку здоровья на порт 3000;
Не порт 80 или 443. Это то, что ваш ALB будет использовать.
Я провел утро на этом. Да.