У меня есть балансировщик нагрузки, настроенный в общедоступной подсети vpc для маршрутизации трафика с HTTPS (443) на экземпляр в частной подсети vpc через HTTP (8080). Установка работала нормально около 24 часов, пока не завершился сбой java-процесса на экземпляре. На этом этапе проверка работоспособности начала давать сбой, и экземпляр стал отображаться как неисправный.
С тех пор я перезапустил процесс и могу выполнять локальные запросы curl локально в экземпляре EC2, а также из экземпляра NAT, который у меня есть в общедоступной подсети (та же подсеть, что и балансировщик нагрузки). Несмотря на то, что экземпляр находится в работоспособном состоянии, балансировщик нагрузки по-прежнему показывает его как неработоспособный.
Что мне кажется особенно странным, так это то, что в журнале доступа к экземпляру EC2 больше не отображаются попытки Load Balancer получить доступ к URL-адресу проверки работоспособности. Я включил ведение журнала балансировщика нагрузки в корзину S3, но это показал только один запрос GET с кодом ошибки 503. Я попытался отменить регистрацию экземпляра в балансировщике нагрузки и перерегистрировать его, но это не имело значения. Остановка и запуск экземпляра и повторная регистрация его с помощью балансировщика нагрузки также не имели никакого значения.
Есть идеи, почему балансировщик нагрузки даже не пытается получить доступ к экземпляру?
Спасибо за любые предложения!
Это также может быть проблема с .htaccess rules в вашей общедоступной папке HTML. Ваш .htaccess переписывание папки в папку?
Это также было проблемой для меня, когда проверка работоспособности по умолчанию установлена на http:80/index.php Но я переписал в папку на сервере. Таким образом, он получил статус нездорового.
Хотя я бы хотел сохранить свои переписывания с .htacess on, но удаление .htacess правила позволили elb пинговать мою общедоступную html-папку и объявлять экземпляры работоспособными.
Пожалуйста, дайте мне знать, если это поможет. Спасибо