Ao usar o AWS re:Post, você concorda com os AWS re:Post Termos de uso
AWS re:Postre:Post

Por que minha instância Linux do EC2 está inacessível e falhando em suas verificações de status?

9 minuto de leitura
0

Minha instância Linux do Amazon Elastic Compute Cloud (Amazon EC2) está inacessível e falha em uma ou em ambas as verificações de status.

Breve descrição

O Amazon EC2 usa duas verificações de status para monitorar a integridade das instâncias do EC2:

Verificação do status do sistema

A verificação do status do sistema detecta problemas com o hardware subjacente de uma instância. Se o hardware subjacente não responder ou estiver inacessível devido a problemas de rede, hardware ou software, a verificação do status do sistema falhará.

Verificação do status da instância

Uma falha na verificação do status da instância indica que a instância está inalcançável. Os seguintes problemas comuns causam uma falha na verificação do status da instância:

  • Falha ao inicializar o sistema operacional (OS)
  • Falha na montagem correta dos volumes
  • CPU e memória esgotadas
  • Pânico de Kernel
  • Falha na rede

Aviso: Algumas das resoluções a seguir exigem a parada e o início da instância. Antes de parar e iniciar sua instância, observe estas condições:

  • Os dados armazenados em volumes de armazenamento de instâncias são perdidos quando a instância é interrompida. Antes de interromper a instância, certifique-se de fazer backup dos dados. Diferentemente dos volumes baseados no Amazon Elastic Block Store (Amazon EBS), os volumes de armazenamento de instâncias são efêmeros e não oferecem suporte à persistência de dados.
  • O endereço público IPv4 estático que o Amazon EC2 atribuiu automaticamente à instância na inicialização ou no início muda após a interrupção e o início. Para manter um endereço IPv4 público que não muda quando a instância é interrompida, use um Endereço IP elástico.

Para obter mais informações, consulte Pré-requisitos para interromper uma instância.

Resolução

Para determinar se a verificação do status da instância ou do sistema falhou, veja as métricas da verificação de status da instância.

Se a verificação do status do sistema falhar, consulte Minha instância Linux do EC2 falhou na verificação do status do sistema. Como faço para solucionar isso?

Se a verificação do status da instância falhar, verifique os registros do sistema da instância para determinar a causa da falha. Em seguida, use uma das seguintes resoluções para resolver o problema.

Falha ao inicializar o sistema operacional

Se os registros do sistema contiverem erros de inicialização, consulte Como solucionar problemas de uma instância Linux do EC2 que falhou na verificação do status da instância devido a problemas no sistema operacional?

Falha na montagem correta dos volumes

Uma falha no ponto de montagem pode fazer com que a verificação do status da instância falhe.

Exemplo de falha no ponto de montagem:

[FAILED] Failed to mount /
See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

Para obter mais informações, consulte os seguintes artigos do Centro de Conhecimentos da AWS:

Quando você altera um tipo de instância de Xen para Nitro, a montagem do volume pode falhar. A falha de montagem ocorre porque os volumes do Amazon EBS ficam expostos como dispositivos de bloco NVMe em instâncias baseadas em Nitro. Os nomes dos dispositivos são /dev/nvme0n1, /dev/nvme1n1 e assim por diante. Os nomes de dispositivos que você especifica em um mapeamento de dispositivos de blocos são renomeados para nomes de dispositivos NVMe (/dev/nvme[0-26]n1). O driver do dispositivo de blocos pode atribuir os nomes dos dispositivos NVMe em uma ordem diferente da ordem original que você especificou no mapeamento de dispositivos de blocos. Para evitar falhas de montagem em instâncias baseadas no Nitro, é uma prática recomendada usar um rótulo ou um UUID para nomes de dispositivos. Para obter mais informações, consulte Disponibilizar um volume do Amazon EBS para uso no Linux.

CPU e memória esgotadas

Alta utilização da CPU

Se a métrica CPUUtilization estiver em ou perto de 100%, a instância pode não ter capacidade computacional suficiente para executar o kernel.

Para instâncias T2 ou T3, verifique as Métricas de crédito de CPU do Amazon CloudWatch para determinar se os créditos de UPC estão em ou perto de zero. Se os créditos de CPU estiverem em zero, a métrica CPUUtilization mostrará um platô de saturação na performance de linha de base da instância. A performance da linha de base pode ser de 20%, 40% e assim por diante, dependendo do tipo de instância.

A utilização da CPU em ou perto de 100%, ou em um patamar de saturação para instâncias T2 ou T3, indica que a verificação de status falhou devido à utilização excessiva de recursos. Para solucionar esse problema, consulte Minha instância Linux do EC2 falhou na verificação de status devido à utilização excessiva de seus recursos. Como faço para solucionar isso?

Erros de dispositivos de blocos, bugs de software ou pânico no kernel podem causar um pico incomum de uso da CPU. Se a utilização da CPU estiver em 100%, verifique os registros do sistema em busca de erros no dispositivo de blocos ou problemas de memória ou outros erros incomuns do sistema. Em seguida, reinicie ou pare e inicie a instância.

Sem memória

A alta pressão da memória pode causar uma falha na verificação do status da instância. No exemplo de entrada de registro a seguir, o sistema operacional está sem memória. Para resolver esse erro, interrompa o processo que está consumindo mais memória.

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB

Por padrão, a memória da instância do EC2 e as métricas de disco não são enviadas ao Amazon CloudWatch. No entanto, você pode usar o agente do CloudWatch para coletar e monitorar métricas adicionais.

Para solucionar o problema de falta de memória, atualize a instância para um tipo de instância maior. Ou adicione armazenamento de troca à instância para aliviar a pressão da memória. Para obter mais informações, consulte os seguintes artigos do Centro de Conhecimentos da AWS:

Erros de disco cheio

Se os logs do sistema contiverem erros de disco cheio, a instância estará no modo de emergência devido ao dispositivo raiz cheio.

Exemplo de log do sistema:

$: service apache2 restart
Error: No space left on device

$: /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl): mysql.serviceError: No space left on device


root@example:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

Para obter instruções detalhadas sobre como solucionar problemas e resolver erros de disco cheio, consulte os seguintes artigos do Centro de Conhecimentos da AWS:

Pânico de Kernel

O pânico no kernel ocorre quando o kernel detecta um erro fatal interno durante a operação. Se o erro ocorrer durante a inicialização do sistema operacional, o kernel pode não ser carregado corretamente. Isso causa uma falha na inicialização do sistema operacional.

Exemplo de mensagem de erro de pânico no kernel:

Linux version
2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Para obter informações sobre como solucionar problemas e resolver um erro de pânico no kernel, consulte os seguintes artigos do Centro de Conhecimentos da AWS:

Falha na rede

Os seguintes motivos comuns podem fazer com que sua rede falhe.

O pacote cloud-init não está instalado na instância

O pacote cloud-init é usado para atualizar as configurações de rede no lançamento.

Para corrigir esse erro, execute o comando a seguir para instalar o pacote cloud-init na sua instância:

$ sudo yum install cloud-init

O endereço MAC é codificado em um arquivo de configuração

Endereços MAC codificados estão nos arquivos de configuração do Linux e nos arquivos de configuração udev. Esses arquivos geralmente estão nos seguintes locais:

  • /etc/udev/rules.d/
  • /etc/udev/rules.d/70-persistent-net.rules
  • /etc/udev/rules.d/80-net-name-slot.rules

Para resolver problemas de rede causados por um endereço MAC codificado, remova as entradas ou os arquivos de configuração. Por exemplo, execute o seguinte comando:

mv /etc/udev/rules.d/70-persistent-net.rules/root/

O endereço IP está codificado em um arquivo de configuração

Quando você cria uma imagem de máquina da Amazon (AMI) a partir de uma instância com um endereço IP configurado estaticamente, o arquivo de configuração pode conter um endereço IP codificado. 

Para corrigir esse erro, defina sua interface de rede para usar DHCP.

Observação: você não pode atualizar AMIs existentes. Você deve definir a interface de rede para usar o DHCP antes de criar uma nova AMI.

Faltam drivers de rede ENA ou Intel aprimorados

Para obter mais informações sobre adaptadores de rede elástica (ENAs) ausentes ou drivers de rede aprimorados da Intel, consulte Redes aprimoradas no Linux.

A interface de rede é renomeada na inicialização

Para corrigir esse problema, adicione net.ifnames=0 à linha de comando do kernel para desativar nomes previsíveis de interfaces de rede. Para fazer a variável, você deve ativar redes aprimoradas com o ENA.

Para obter mais informações sobre problemas de rede, consulte Práticas recomendadas para configurar interfaces de rede.

Informações relacionadas

Solucionar problemas de instâncias com falhas nas verificações de status

Por que minha instância do Windows no EC2 está inativa com uma falha na verificação de status do sistema ou na verificação de status 0/2?

Por que minha instância do Windows no EC2 está inativa com uma falha na verificação da instância?

Tipos de verificações de status

Tópicos
Computação
Tags
Amazon EC2Linux
Idioma
Português
AWS OFICIAL
AWS OFICIALAtualizada há 10 meses

Conteúdo relevante