#amazon-web-services #amazon-elastic-beanstalk #aws-application-load-balancer
#amazon-веб-сервисы #amazon-elastic-beanstalk #aws-приложение-балансировщик нагрузки
Вопрос:
У меня есть внутренний сервер, развернутый на aws в одном экземпляре EC2 через elastic beanstalk. Сервер имеет белый список IP-адресов и, следовательно, не отвечает на проверки работоспособности ALB, поэтому все целевые группы всегда остаются неработоспособными.
Согласно официальным документам AWS по проверкам работоспособности,
Если целевая группа содержит только зарегистрированные неработоспособные целевые объекты, узлы балансировки нагрузки перенаправляют запросы по ее неработоспособным целевым объектам.
Это то, что поддерживает работу моего приложения, даже если целевые группы ALB всегда неработоспособны.
Это изменилось прошлой ночью, и я столкнулся с перебоями, когда все запросы начали отклоняться с помощью 503-х по причинам, которые я не могу понять. Я смог заставить вещи снова работать, предоставив еще один экземпляр EC2, увеличив минимальную емкость elastic beanstalk.
Во время перерыва в работе cloudwatch показывает, что нет ни исправных, ни неработоспособных экземпляров, хотя на самом деле ничего не изменилось, поскольку один экземпляр EC2 работал в течение последних нескольких месяцев без изменений.
В этом пробеле я могу найти показатели для TCP-соединений, хотя:
Я не совсем понимаю, что здесь произошло, может кто-нибудь объяснить, что или как это отладить?
Комментарии:
1. Был ли у вас хост в балансировщике нагрузки в течение этого периода времени, если он входил в группу автоматического масштабирования, продолжал ли он удалять экземпляр?
2. Нет, ни один экземпляр не был добавлен или удален, за последние несколько месяцев был запущен только один экземпляр, который никогда не менялся, пока я не вмешался. Редактировать: опечатка
3. В каком регионе? В us-east-1 возникли некоторые проблемы с EC2, из-за которых AWS потребовалось восстановить множество затронутых экземпляров.
4. Это было в ap-south-1