Instância falhou ao menos o número Limite Insalubre de verificações de saúde consecutivamente

Question

Estou tentando fazer o escalonamento automático de minha instância atual, estou executando uma instância média agora e dimensionando automaticamente com instâncias pequenas. Eu usei a ferramenta de linha de comando para definir as configurações, essas são as configurações que usei para dimensionar e estou executando no mínimo uma instância além da minha instância regular, o que significa mais uma instância e eu conectei ao balanceador de carga.

s-create-auto-scaling-group groupname --launch -configuração launchconfig --availability-zones ap-southeast-1a --min-size 1 --máx-size 5 - load-balancers prod

Mas quando eu verifiquei o balanceador de carga, ele diz "Fora de Serviço", motivo "Instância falhou, pelo menos, o número Limite Insalubre de verificações de integridade consecutivamente". Como posso resolver isso, usando seu DNS público, não consigo obter nenhuma resposta da instância e também não consigo o ssh, pois o par de valores-chave não está anexado à instância recém-criada.

qual é o problema.Como resolvo isso?

Por favor, ajude-me seu pouco urgente, já que eu sou atingido neste ponto por quase 2 dias.

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

    

Answer 1

Há várias considerações a serem levadas em consideração aqui. Em primeiro lugar, para resolver o problema mais limitante - a falta de acesso SSH.

Como sua configuração anterior de lançamento não especificou um par de chaves, você não terá credenciais válidas para acessar a instância. Infelizmente, o par de chaves inicial não pode ser adicionado após o lançamento da instância.

Para corrigir isso, você deve criar uma nova configuração de ativação, passando os parâmetros --key e --group , além de todos os parâmetros que você passou anteriormente. --key usa o nome do par de chaves que você deseja usar, enquanto --group usa o nome do grupo de segurança (se não estiver no VPC) ou ID.

Nos casos em que você não pode acessar sua instância, o log do console pode ajudá-lo a verificar se a instância foi inicializada com êxito. Um problema comum é a falha de inicialização devido a volumes ausentes (especialmente tentando montar volumes efêmeros que existem apenas nos tipos de instância maiores, ao inicializar um tipo de instância menor).

Um ponto importante de menção é que uma AMI não é atualizada se você alterar uma instância em execução. Você deve criar explicitamente a nova imagem. Dessa forma, se você tentar iniciar uma nova instância usando a mesma AMI que estiver usando atualmente em uma instância personalizada, há uma boa chance de que você simplesmente execute uma das AMIs padrão e não uma com suas personalizações.

Use ec2-describe-images para determinar o mapeamento de dispositivo de bloco de sua imagem - e o instantâneo em que o volume é baseado - isso verificará que você montará um volume de EBS que tenha suas personalizações incorporadas.

Se você não tiver uma AMI atualizada para usar no escalonamento automático:

• Crie um instantâneo do seu volume do EBS
• Crie uma AMI com ec2-register -n IMAGE_NAME -s SNAPSHOT_ID
  • Se você tiver volumes adicionais de EBS para anexar, especifique-os adicionando o parâmetro --block-device-mapping ( -b ) (por exemplo, -b /dev/xvdf=SNAP_ID )
• Verifique se você tem os mapeamentos de dispositivos de bloco corretos com ec2-describe-images

Depois de ter uma AMI atualizada, você precisará criar uma nova configuração de inicialização que usará essa AMI. Se desejar, você pode passar mapeamentos adicionais de dispositivos de bloco ao comando. Use as-create-launch-config , passando sua nova AMI e todos os parâmetros usados anteriormente.

Por fim, você deve atualizar seu grupo de escalonamento automático. Este grupo está associado a uma determinada configuração de ativação - a nova configuração de ativação não será detectada automaticamente e não terá efeito no grupo de escalonamento automático até que você a associe explicitamente. Use as-update-auto-scaling-group GROUP_NAME --launch-configuration CONFIG_NAME para fazer essa alteração.

Após as alterações terem sido feitas, você pode simular um evento de escalonamento automático usando o comando as-execute-policy.

Lembre-se de dar a suas instâncias alguns minutos para inicializar - se seu ELB estiver mostrando instâncias como não íntegras, talvez você queira aumentar o --grace-period de seu grupo de escalonamento automático.