Solução de problemas gerais

Nesta página, você verá etapas de solução de problemas que podem ser úteis se tiver problemas ao usar instâncias do Compute Engine.

Solução de problemas gerais com instâncias

Se a instância não iniciar

Se você receber um erro de cota ao tentar iniciar uma instância, será necessário solicitar mais cota de CPU. Para mais informações, consulte a seção Instâncias de VM do documento Cotas de recursos.

Aqui estão algumas dicas para resolver o problema no disco permanente em caso de não inicialização.

  • O disco de inicialização está cheio. Se o disco de inicialização estiver completamente cheio e o sistema operacional não for compatível com o redimensionamento automático, não será possível usar o SSH na instância. Crie uma nova instância e recrie o disco de inicialização. Consulte Como recuperar uma instância inacessível ou um disco de inicialização completo.

  • Examine a saída da porta serial da instância de máquina virtual.

    As mensagens de depuração do BIOS, do carregador de inicialização e do kernel de uma instância são exibidas na saída da porta serial da instância, fornecendo informações úteis sobre erros ou problemas. Se você ativar a geração de registros da saída de porta serial para o Cloud Logging, será possível acessar essas informações mesmo quando a instância não estiver em execução. Consulte Como visualizar a saída da porta serial.

  • Ative o acesso interativo ao console serial.

    Ative o acesso interativo ao console serial de uma instância para fazer login e depurar problemas de inicialização a partir da instância sem precisar que a inicialização seja concluída. Para mais informações, consulte Como interagir com o console serial.

  • Verifique se o disco tem um sistema de arquivos válido.

    Quando o sistema de arquivos está corrompido ou inválido, não é possível iniciar a instância. Valide o sistema de arquivos do disco:

    1. Se aplicável, separe esse disco de qualquer instância a que ele esteja anexado:

      gcloud compute instances delete old-instance --keep-disks boot
      
    2. Inicie uma nova instância com a imagem mais recente fornecida pelo Google:

      gcloud compute instances create debug-instance
      
    3. Anexe o disco como não inicializável, mas não o monte. Substitua DISK pelo nome do disco que não será inicializado. Observe que também incluímos um nome de dispositivo para que ele seja facilmente identificável na instância:

      gcloud compute instances attach-disk debug-instance --disk DISK --device-name debug-disk
      
    4. Conecte-se à instância:

      gcloud compute ssh debug-instance
      
    5. Encontre a partição raiz do disco, identificada pela notação part1. Nesse caso, a partição raiz do disco está em /dev/sdb1:

      user@debug-instance:~$ ls -l /dev/disk/by-id
      total 0
      lrwxrwxrwx 1 root root  9 Jan 22 17:09 google-debug-disk -> ../../sdb
      lrwxrwxrwx 1 root root 10 Jan 22 17:09 google-debug-disk-part1 -> ../../sdb1
      lrwxrwxrwx 1 root root  9 Jan 22 17:02 google-persistent-disk-0 -> ../../sda
      lrwxrwxrwx 1 root root 10 Jan 22 17:02 google-persistent-disk-0-part1 -> ../../sda1
      lrwxrwxrwx 1 root root  9 Jan 22 17:09 scsi-0Google_PersistentDisk_debug-disk -> ../../sdb
      lrwxrwxrwx 1 root root 10 Jan 22 17:09 scsi-0Google_PersistentDisk_debug-disk-part1 -> ../../sdb1
      lrwxrwxrwx 1 root root  9 Jan 22 17:02 scsi-0Google_PersistentDisk_persistent-disk-0 -> ../../sda
      lrwxrwxrwx 1 root root 10 Jan 22 17:02 scsi-0Google_PersistentDisk_persistent-disk-0-part1 -> ../../sda1
      
    6. Execute uma verificação de sistema de arquivos na partição raiz:

      user@debug-instance:~$ sudo fsck /dev/sdb1
      fsck from util-linux 2.20.1
      e2fsck 1.42.5 (29-Jul-2012)
      /dev/sdb1: clean, 19829/655360 files, 208111/2621184 blocks
      
    7. Monte seu sistema de arquivos:

      user@debug-instance:~$ sudo mkdir /mydisk
      
      user@debug-instance:~$ sudo mount /dev/sdb1 /mydisk
      
    8. Verifique se o disco tem arquivos de kernel:

      user@debug-instance~:$ ls /mydisk/boot/vmlinuz-*
      /mydisk/boot/vmlinuz-3.2.0-4-amd64
      
  • Verifique se o disco tem um registro mestre de inicialização (MBR, na sigla em inglês) válido.

    Execute o comando a seguir na instância de depuração que conectou o disco de inicialização permanente, como /dev/sdb:

    $ sudo parted /dev/sdb print
    

    Se o MBR é válido, as informações sobre o sistema de arquivos são listadas:

    Disk /dev/sdb: 10.7GB
    Sector size (logical/physical): 512B/4096B
    Partition Table: msdos
    Disk Flags:
    
    Number  Start   End     Size    Type     File system  Flags
     1      2097kB  10.7GB  10.7GB  primary  ext4         boot
    

Se você não conseguir criar uma instância

Veja algumas dicas para ajudar na solução de problemas, caso sua instância não seja criada.

  • Operações simultâneas de mutação ou criação de recursos podem causar um erro. Por exemplo, se você estiver modificando intervalos secundários em uma sub-rede e criando uma VM ao mesmo tempo, poderá ver o erro a seguir: The resource 'projects/[PROJECT]/regions/[REGION]/subnetworks/default' is not ready. A solução é tentar novamente a operação com falha.

  • Se você receber um erro de recurso, como ZONE_RESOURCE_POOL_EXHAUSTED ou ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS, ao solicitar novos recursos, significa que a zona não pode atender sua solicitação no momento. Esse erro ocorre devido à disponibilidade de recursos do Compute Engine na zona e não por causa da sua cota no Compute Engine.

    Confira abaixo algumas dicas para reduzir o impacto:

    • Como essa situação é temporária e pode mudar frequentemente com base na demanda flutuante, faça sua solicitação novamente mais tarde.
    • Tente criar os recursos em outra zona da região ou em outra região.
    • Tente alterar o formato da VM que está sendo solicitada. É mais fácil conseguir tipos de máquinas menores do que os maiores. Uma alteração na solicitação, como reduzir o número de GPUs ou usar uma VM personalizada com menos memória ou vCPUs, pode permitir que sua solicitação continue.
    • Use as reservas do Compute Engine para reservar recursos dentro de uma zona e garantir que os recursos necessários estejam disponíveis quando for preciso usá-los.
    • Se você estiver tentando criar uma instância preemptiva, lembre-se de que as VMs preemptivas têm capacidade disponível e, portanto, talvez não seja possível recebê-las nos períodos de pico de demanda.
    • Se você receber um erro notFound ou does not exist in zone ao solicitar novos recursos, isso significará que a zona não oferece o recurso ou o tipo de máquina que você solicitou. Consulte Regiões e zonas para descobrir quais recursos estão disponíveis em cada zona.

Se o tráfego de rede de ou para a instância estiver caindo

No Compute Engine, o tráfego de rede ocorre apenas quando o acesso à instância é possibilitado pelas regras de firewall do projeto. Por padrão, todos os projetos têm uma rede padrão que possibilita determinados tipos de conexões. Quando você nega qualquer tráfego por padrão, também nega as conexões do SSH e todo o tráfego interno. Para mais informações, consulte a página Regras de firewall.

Além disso, talvez seja necessário ajustar as configurações de keep-alive do TCP para trabalhar com o tempo limite padrão de inatividade de 10 minutos. Para mais informações, consulte Comunicação entre as suas instâncias e a Internet.

Solução de problemas relacionados a regras de firewall ou rotas em uma instância

O Console do Google Cloud fornece detalhes da rede para cada interface de rede de uma instância. É possível visualizar todas as regras de firewall ou rotas que se aplicam a uma interface ou apenas as regras e rotas usadas pela interface. Qualquer uma dessas visualizações pode ajudar a resolver problemas sobre quais regras e rotas de firewall se aplicam à instância e quais estão sendo realmente usadas (quando a prioridade e a ordem de processamento tiverem precedência sobre outras regras ou rotas).

Para mais informações, consulte a solução de problemas na documentação da nuvem privada virtual:

Solução de problemas com o SSH

Em determinadas condições, uma instância do Linux pode recusar as conexões SSH. Há vários motivos para isso ocorrer, desde um disco cheio até uma configuração incorreta de sshd. Nesta seção, há algumas dicas e abordagens para resolver problemas comuns do SSH.

Verificar as regras de firewall

O Compute Engine provisiona a cada projeto um conjunto padrão de regras de firewall que permitem o tráfego SSH. Se por algum motivo essas regras forem removidas, não será possível acessar a instância. Verifique sua lista de firewalls com a ferramenta de linha de comando gcloud e se a regra default-allow-ssh está presente.

gcloud compute firewall-rules list

Se você não encontrar essa regra, adicione-a novamente:

gcloud compute firewall-rules create default-allow-ssh --allow tcp:22

Depurar o problema no console serial

Ative o acesso de leitura e gravação para um console serial da instância a fim de fazer login nele e resolver problemas com ela. Isso é especialmente útil quando você não consegue fazer login com o SSH ou se a instância não tem conexão com a rede. O console serial permanece acessível nessas duas condições.

Para aprender a ativar o acesso interativo e se conectar a um console serial de instância, consulte Como interagir com o console serial.

Testar a rede

É possível usar a ferramenta netcat para se conectar à instância na porta 22 e determinar se a conexão de rede está funcionando. Após a conexão, se um banner do ssh for exibido (por exemplo, SSH-2.0-OpenSSH_6.0p1 Debian-4), significa que a conexão de rede está funcionando e é possível descartar a possibilidade de problemas no firewall. Primeiro, use a ferramenta gcloud para descobrir o natIP externo da instância:

gcloud compute instances describe example-instance --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
198.51.100.8

Use o comando nc para se conectar à instância:

# Check for SSH banner
user@local:~$ nc [EXTERNAL_IP] 22
SSH-2.0-OpenSSH_6.0p1 Debian-4

Testar um novo usuário

Talvez o problema que impeça você de fazer login esteja limitado à sua conta, por exemplo, se as permissões no arquivo ~/.ssh/authorized_keys da instância não foram definidas corretamente.

Tente usar a ferramenta gcloud para fazer login como um novo usuário. Basta especificar outro nome de usuário com a solicitação SSH. A ferramenta gcloud atualizará os metadados do projeto para adicionar o novo usuário e permitir o acesso SSH.

user@local:~$ gcloud compute ssh [USER]@example-instance

[USER] é um novo nome de usuário para fazer login.

Usar seu disco em uma nova instância

Se o conjunto de etapas acima não funcionar para você e a instância em que você estiver interessado for inicializada a partir de um disco permanente, será possível desanexar esse disco e anexá-lo para ser usado na nova instância. Substitua DISK pelo nome do seu disco:

gcloud compute instances delete old-instance --keep-disks=boot
gcloud compute instances create new-instance --disk name=DISK boot=yes auto-delete=no
gcloud compute ssh new-instance

Inspecionar uma instância sem desligá-la

Talvez você não consiga se conectar a uma instância que continua atendendo ao tráfego de produção. Nesse caso, inspecione o disco sem interromper a capacidade da instância de atender aos usuários. Primeiro, faça um snapshot do disco de inicialização da instância. Depois, crie um novo disco a partir desse snapshot. Crie uma instância temporária e, por fim, anexe e monte o novo disco permanente nessa instância para resolver o problema no disco.

  1. Crie uma nova rede VPC para hospedar a instância clonada:

    gcloud compute networks create debug-network
    
  2. Adicione uma regra de firewall para possibilitar conexões SSH à rede:

    gcloud compute firewall-rules create debug-network-allow-ssh --allow tcp:22
    
  3. Crie um snapshot do disco analisado, substituindo DISK pelo nome do disco:

    gcloud compute disks snapshot DISK --snapshot-name debug-disk-snapshot
    
  4. Crie um novo disco com esse snapshot:

    gcloud compute disks create example-disk-debugging --source-snapshot debug-disk-snapshot
    
  5. Crie uma instância de depuração sem um endereço IP externo:

    gcloud compute instances create debugger --network debug-network --no-address
    
  6. Anexe o disco de depuração à instância:

    gcloud compute instances attach-disk debugger --disk example-disk-debugging
    
  7. Siga as instruções para conectar-se a uma instância sem um endereço IP externo.

  8. Depois de fazer login na instância do depurador, resolva os problemas da instância. Por exemplo, procure nos registros da instância:

    $ sudo su -
    
    $ mkdir /mnt/myinstance
    
    $ mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/myinstance
    
    $ cd /mnt/myinstance/var/log
    
    # Identify the issue preventing ssh from working
    $ ls
    

Usar um script de inicialização

Se nenhuma das sugestões anteriores ajudou, crie um script de inicialização para coletar informações logo após a instância ser iniciada. Siga as instruções para executar esse script.

Em seguida, será preciso executar gcloud compute instances reset para redefinir sua instância antes que os metadados sejam afetados. Como alternativa, recrie a instância com um script de inicialização de diagnóstico:

  1. Execute gcloud compute instances delete com a sinalização --keep-disks.

    gcloud compute instances delete INSTANCE --keep-disks boot
    
  2. Adicione uma nova instância com o mesmo disco e especifique o script de inicialização.

    gcloud compute instances create example-instance --disk name=DISK,boot=yes --startup-script-url URL
    

Como ponto de partida, use o script compute-ssh-diagnostic (em inglês) para coletar informações de diagnóstico dos problemas mais comuns.