Назад | Перейти на главную страницу

Экземпляр не прошел последовательную проверку работоспособности минимум на пороговое значение нездорового состояния.

Я пытаюсь автомасштабировать свой текущий экземпляр, я использую средний экземпляр прямо сейчас и автоматически масштабируюсь с небольшим экземпляром. Я использовал инструмент командной строки для настройки параметров, это конфигурации, которые я использовал для масштабирования, и я запускаю минимум один экземпляр, кроме моего обычного экземпляра, что означает еще один экземпляр, и я подключился к балансировщику нагрузки.

s-create-auto-scaling-group имя группы --launch-configuration launchconfig --availability-zone ap-southeast-1a --min-size 1 --max-size 5 --load-balancers prod

Но когда я проверил балансировщик нагрузки, он говорит, что причина «Не работает»: «Экземпляр не прошел, по крайней мере, количество проверок работоспособности, превышающее пороговое значение нездоровой работы». Как я могу решить эту проблему, используя свой общедоступный DNS, я не могу получить никакого ответа от экземпляра, а также не могу использовать ssh, поскольку пара значений ключа не привязана к вновь созданному экземпляру.

в чем проблема. как мне это решить.

Пожалуйста, помогите мне немного срочно, так как я нахожусь в этом пункте почти 2 дня.

as-describe-launch-configs --show-long --headers



testLC,ami-e8c4bdba,t1.micro,(nil),(nil),(nil),(nil),default,2012-02-03T07:14:54.461Z,true,arn:aws:autoscaling:ap-southeast-1:346266270015:launchConfiguration:175a16db-1f6a-4514-9233-ac7cb34bca90:launchConfigurationName/testLC

as-describe-auto-scaling-groups --show-long --headers

testASG,testLC,ap-southeast-1a,2012-02-03T07:19:10.706Z,prod,EC2,1,5,1,300,0,(nil),(nil),arn:aws:autoscaling:ap-southeast-1:346266270015:autoScalingGroup:c4b584d0-bac4-4507-b972-4fc2b1bc53ac:autoScalingGroupName/testASG,(nil)

as-describe-auto-scaling-instances
i-43796716  testASG  ap-southeast-1a  InService  HEALTHY  testLC

elb-describe-lbs --headers --show-long

prod,prod-11719395.ap-southeast-1.elb.amazonaws.com,prod-11719395.ap-southeast-1.elb.amazonaws.com,Z1WI8VXHPB1R38,"{interval=120,target=HTTP:80/user/sign_in/,timeout=30,healthy-threshold=5,unhealthy-threshold=3}",ap-southeast-1a,(nil),(nil),"i-495dda1c, i-43796716","{protocol=HTTP,lb-port=80,instance-protocol=HTTP,instance-port=80,policies=AWSConsolePolicy-1}",(nil),"{policy-name=AWSConsolePolicy-1,expiration-period=180}","{owner-alias=amazon-elb,group-name=amazon-elb-sg}",(nil),2012-02-01T10:36:08.810Z

elb-describe-instance-health loadbalancername --headers --show-long

INSTANCE_ID,i-495dda1c,InService,N/A,N/A
INSTANCE_ID,i-43796716,OutOfService,Instance has failed at least the UnhealthyThreshold number of health checks consecutively.,Instance

Здесь необходимо принять во внимание ряд соображений. Во-первых, решить самую ограничивающую проблему - отсутствие доступа по SSH.

Поскольку в вашей предыдущей конфигурации запуска не была указана пара ключей, у вас не будет действительных учетных данных для доступа к экземпляру. К сожалению, начальную пару ключей нельзя добавить после запуска экземпляра.

Чтобы исправить это, вы должны создать новую конфигурацию запуска, передав --key и --group параметры в дополнение ко всем параметрам, которые вы передали ранее. --key берет имя пары ключей, которую вы хотите использовать, а --group принимает имя группы безопасности (если не в VPC) или идентификатор.

В случаях, когда вы не можете получить доступ к своему экземпляру, журнал консоли может помочь вам убедиться, что экземпляр действительно успешно загружен. Распространенной проблемой является сбой загрузки из-за отсутствия томов (особенно при попытке смонтировать временные тома, которые существуют только на более крупных типах экземпляров, при загрузке меньшего типа).

Важно отметить, что AMI не обновляется, если вы меняете работающий экземпляр. Вы должны явно создать новый образ. Таким образом, если вы попытаетесь запустить новый экземпляр, используя тот же AMI, который вы в настоящее время используете в настроенном экземпляре, есть большая вероятность, что вы просто запустите один из AMI по умолчанию, а не тот, который содержит ваши настройки.

Использовать ec2-describe-images чтобы определить сопоставление блочного устройства вашего образа - и моментального снимка, на котором основан том - это подтвердит, что вы будете монтировать том EBS, в который встроены ваши настройки.

Если у вас нет обновленного AMI для автомасштабирования:

  • Создайте снимок вашего тома EBS
  • Создайте AMI с ec2-register -n IMAGE_NAME -s SNAPSHOT_ID
    • Если у вас есть дополнительные тома EBS для подключения, укажите их, добавив --block-device-mapping (-b) параметр (например, -b /dev/xvdf=SNAP_ID)
  • Убедитесь, что у вас есть правильные сопоставления блочных устройств с ec2-describe-images

Если у вас есть обновленный AMI, вам необходимо создать новую конфигурацию запуска, которая будет использовать этот AMI. При желании вы можете передать команде дополнительные сопоставления блочных устройств. Использовать as-create-launch-config, передав ему ваш новый AMI и все параметры, которые вы использовали ранее.

Наконец, вы должны обновить группу автомасштабирования. Эта группа связана с определенной конфигурацией запуска - новая конфигурация запуска не будет автоматически обнаружена и не будет влиять на группу автомасштабирования, пока вы явно не свяжете ее. Использовать as-update-auto-scaling-group GROUP_NAME --launch-configuration CONFIG_NAME сделать это изменение.

После внесения изменений вы можете смоделировать событие автомасштабирования с помощью команды as-execute-policy.

Не забудьте дать вашим инстансам несколько минут для загрузки - если ваш ELB показывает инстансы как нездоровые, вы можете увеличить --grace-period вашей группы автомасштабирования.