Dicas, problemas conhecidos e soluções

Nesta página, há dicas úteis sobre problemas conhecidos e resoluções que talvez você encontre ao usar o Google Compute Engine.

Dicas gerais

Ver diferentes formatos de resposta

Na ferramenta de linha de comando gcloud, a maioria das ações é executada por meio de chamadas à REST API. Os resultados com estilo de formatação mostram somente as informações mais importantes retornadas por um comando específico. Para ver os diferentes formatos de resposta, use o sinalizador --format, que exibe a resposta em diferentes formatos de saída, incluindo json, yaml e text. Por exemplo, para ver uma lista de instâncias em JSON, use --format json:

gcloud compute instances list --format json

Como ver registros do gcloud compute

Na ferramenta gcloud, os registros são criados e armazenados em um arquivo. Para consultá-lo, acesse o caminho $HOME/.config/gcloud/logs. Para ver o arquivo de registro mais recente em um sistema operacional baseado em Linux, execute:

$ less $(find ~/.config/gcloud/logs | sort | tail -n 1)

O arquivo de registro inclui informações sobre todas as solicitações e respostas criadas com a ferramenta gcloud compute.

Selecionar nomes de recurso

Ao selecionar os nomes para os seus recursos, lembre-se de que eles aparecem nos painéis de suporte e operacionais do Google Compute Engine. Por esse motivo, não exponha informações confidenciais nesses nomes.

Comunicação entre as suas instâncias e a Internet

Uma instância só tem acesso direto à Internet quando tem um endereço IP externo. Em uma instância com esse IP, as conexões com a Internet são iniciadas a qualquer momento. Também é possível receber conexões quando uma regra de firewall é configurada para possibilitar esse acesso. Você pode adicionar uma regra de firewall personalizado à rede VPC default ou adicionar uma nova rede com firewalls personalizados. Além disso, você pode configurar um proxy de rede dentro do ambiente de rede VPC para fornecer acesso por proxy a partir de uma instância sem um endereço IP externo.

Lembre-se de que conexões TCP inativas são desconectadas após 10 minutos. Se conexões de longa duração com um host externo são iniciadas ou aceitas na sua instância, ajuste as configurações de keep-alive do TCP para evitar que essas conexões caiam após o tempo limite. Configure o keep-alive na instância do Compute Engine, no cliente externo ou em ambos, dependendo do host que normalmente inicia a conexão. Defina os keep-alives com menos de 600 segundos para garantir que as conexões sejam atualizadas antes do tempo limite. Os exemplos a seguir definem os keep-alives com um minuto (60 segundos). Lembre-se que os aplicativos executados em sistemas Linux não ativam o keep-alive automaticamente. Isso significa que é necessário definir explicitamente a opção de soquete SO_KEEPALIVE quando as conexões TCP são abertas. Para mais informações, consulte também Linux TCP Keepalive HOWTO.

Instância do Compute Engine ou cliente Linux


Execute o seguinte comando:

$ sudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5
Adicione as configurações ao arquivo /etc/sysctl.conf para garantir que elas sejam mantidas após a reinicialização.

Cliente Mac OSX


Execute o seguinte comando:

$ sudo sysctl -w net.inet.tcp.always_keepalive=1 net.inet.tcp.keepidle=60000 net.inet.tcp.keepinit=60000 net.inet.tcp.keepintvl=60000

Cliente Windows


No caminho do registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\, adicione estas configurações usando o tipo de dados DWORD ou edite os valores caso elas já existam:

KeepAliveInterval: 1000
KeepAliveTime: 60000
TcpMaxDataRetransmissions: 10

Acessar o Google Compute Engine com um usuário SSH diferente

Por padrão, a variável $USER é utilizada na ferramenta de linha de comando gcloud compute para adicionar usuários ao arquivo /etc/passwd, no caso de conexões de instâncias de máquinas virtuais com o SSH. Especifique um usuário diferente usando a sinalização --ssh-key-file PRIVATE_KEY_FILE ao executar o comando gcloud compute ssh. Por exemplo:

gcloud compute ssh example-instance --ssh-key-file my-private-key-file

Consulte a documentação de referência do gcloud para mais informações.

Interagir com o console serial

Ative o acesso interativo a um console serial de instância para se conectar e resolver problemas de instâncias por meio do console.

Para aprender mais, leia Interagir com o console serial.

Evitar fragmentação de pacote de instâncias criadas a partir de imagens personalizadas

A rede VPC tem uma unidade máxima de transmissão (MTU, na sigla em inglês) de 1460 bytes para imagens Linux e imagens do Windows Server. As imagens do sistema operacional fornecidas pelo Compute Engine são configuradas com essa MTU, ou seja, nada precisa ser feito se você estiver usando uma delas. Para imagens personalizadas, defina a MTU como 1460 para imagens padrão do Linux e do Windows Server para evitar o aumento da latência e a sobrecarga de pacotes causada pela fragmentação.

Ao criar aplicativos cliente que se comunicam com instâncias do Compute Engine sobre soquetes UDP, envie um payload máximo de 1.432 bytes para evitar a fragmentação.

Solução de problemas

Minha instância não inicia. O que posso fazer?

Aqui estão algumas dicas para ajudá-lo a resolver o problema no disco permanente em caso de não inicialização.

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

    Mensagens de depuração de BIOS, carregador de inicialização e kernel da instância são impressos na saída da portal serial da instância, fornecendo informações úteis sobre erros ou problemas. Para receber informações da porta serial, execute:

    gcloud compute instances get-serial-port-output INSTANCE
    

    Além disso, acesse essas informações no Console do Google Cloud Platform:

    1. Acesse a página Instâncias de VMs no Console do Cloud Platform.
    2. Clique na instância que não está inicializando.
    3. Na página da instância, role até o final e clique em Saída da porta serial.
  • Ativar acesso interativo para o console serial.

    Ative o acesso interativo a um console serial de instância para fazer login e depurar os problemas de inicialização da instância, sem precisar concluir a inicialização. Para mais informações, leia Interagir com o console serial.

  • Validar o sistema de arquivos do disco.

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

    1. Se aplicável, separe esse disco de qualquer instância ao qual está 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 seu disco como não inicializável, mas não ative esse disco. 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. Neste caso, a partição 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
      

  • Valide o registro mestre de inicialização (MBR, na sigla em inglês) do disco.

    Execute o seguinte comando na instância de depuração que tem o disco permanente de inicialização como /dev/sdb:

    $ sudo parted /dev/sdb print
    

    Se o MBR for 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
    

O que significa se minha instância está em estado TERMINATED?

TERMINATED significa que a instância foi interrompida e pode ser reiniciada mais tarde. O tempo de atividade de uma instância TERMINATED não é cobrado. Para mais informações, consulte Interromper ou excluir uma instância.

Por que o tráfego de rede da minha instância está caindo?

No Google Compute Engine, o tráfego de rede só ocorre quando o acesso à sua instância é possibilitado pelas regras de firewall do projeto. Por padrão, todos os projetos têm uma rede padrão que permite determinados tipos de conexões. Quando você nega qualquer tráfego por padrão, também nega as conexões do SSH e do tráfego interno. Para mais informações, consulte a página Regras do 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.

Resolver erros do SSH

Sob certas condições, é possível que uma instância do Google Compute Engine não aceite mais conexões do SSH. Há vários motivos para isso ocorrer, desde um disco cheio até uma configuração incorreta. Se esse for o caso, acessar a instância será um grande desafio. Nesta seção, há algumas dicas para resolver problemas comuns do SSH.

Verifique as regras de firewall

Cada projeto do Google Compute Engine é fornecido com um conjunto padrão de regras de firewall que possibilita o tráfego do SSH. Se por algum motivo essas regras são removidas, não é possível acessar a sua instância. Veja a lista de firewalls com a ferramenta de linha de comando gcloud compute e verifique se a regra default-allow-ssh existe. Se você não encontrar essa regra, adicione-a novamente:

gcloud compute firewall-rules list
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 a um console serial da instância para fazer login nele e resolver problemas com a instância. 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 conectar-se a um console serial de instância, leia Interagir com o console serial.

Testar a rede

Use a ferramenta netcat para se conectar à instância pela porta 22 e confira se a conexão de rede está funcionando. Quando você se conecta, se um banner do ssh é exibido (por exemplo, SSH-2.0-OpenSSH_6.0p1 Debian-4), a conexão de rede está funcionando e é possível descartar a possibilidade de problemas no firewall. Primeiro, use a ferramenta gcloud para ver o natIP externo da sua 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

Tentar com um usuário novo

Talvez o problema que impede você de fazer login esteja limitado à sua conta (por exemplo, se as permissões no arquivo ~/.ssh/authorized_keys da instância foram definidos incorretamente).

Tente efetuar o login como novo usuário com a ferramenta gcloud, especificando 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

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

Usar seu disco em uma nova instância

Se a série de etapas acima não funciona e a instância que você precisa é inicializada a partir de um disco permanente, separe e anexe esse disco para usá-lo em uma nova instância. Substitua DISK pelo nome do seu disco no seguinte exemplo:

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 os usuários. Primeiro, faça um instantâneo do disco de inicialização da instância. Depois, crie um novo disco a partir desse instantâneo. Crie uma instância temporária e, por fim, anexe e ative 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 do SSH à rede:

    gcloud compute firewall-rules create debug-network-allow-ssh --allow tcp:22
    
  3. Crie um instantâneo 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 instantâneo:

    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. Após fazer login na instância de depuração, resolva o problema 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 os procedimentos acima não funcionarem, crie um script de inicialização para coletar informações logo após a inicialização. Siga as instruções para executar esse script.

Em seguida, é necessário redefinir a instância com gcloud compute instances reset antes que os metadados sejam aplicados. Como alternativa, também 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 seu 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 para coletar informações de diagnóstico dos problemas mais comuns.

Problemas conhecidos

Problema no sistema de arquivos raiz somente leitura do Red Hat Enterprise Linux 7 e do CentOS 7

As instâncias de VM que executam imagens públicas rhel-7-v20170719 e anteriores ou centos-7-v20170719 e anteriores podem inicializar com o sistema de arquivos raiz ativado no modo somente leitura. Aplicativos, daemons ou scripts que exigem acesso de gravação ao sistema de arquivos raiz apresentarão falha.

Não reinicialize ou reinicie instâncias em execução que usem as imagens públicas afetadas. Caso contrário, elas não sairão do modo somente leitura. Se as instâncias já estiverem travadas no modo somente leitura, restaure remotamente o modo de leitura e gravação para o sistema de arquivos raiz e corrija o problema.

Identificar instâncias afetadas:

Use os comandos gcloud compute disks list para identificar instâncias potencialmente afetadas:

RHEL 7:

gcloud compute disks list --filter="sourceImage ~ rhel-7-v201[4-6].* OR sourceImage ~ rhel-7-v20170[1-7].*" --uri

CentOS 7:

gcloud compute disks list --filter="sourceImage ~ centos-7-v201[4-6].* OR sourceImage ~ centos-7-v20170[1-7].*" --uri

Se esses discos estiverem anexados às instâncias, você poderá corrigir o problema nelas. O processo para corrigir instâncias afetadas depende da versão da imagem usada para criar a instância.

Instâncias criadas usando imagens do RHEL 7 entre rhel-7-v20160418 e rhel-7-v20170719 ou imagens do CentOS 7 entre centos-7-v20160418 e centos-7-v20170719:

Se a instância usar atualizações automáticas, o yum-cron instalará automaticamente o pacote fixo e removerá a opção de ativação inválida do arquivo /etc/fstab. Caso a instância não tenha atualizações automáticas ativadas, corrija a instância com o seguinte processo:

  1. Conecte-se à instância usando SSH. Se a conexão falhar, poder ser que a instância esteja travada no modo somente leitura. No entanto, você pode tentar recuperá-la. Caso você tenha se conectado à instância afetada por SSH antes, suas chaves SSH públicas já estarão no sistema de arquivos raiz e continuarão a funcionar. Execute um comando remoto por ssh para reativar o sistema de arquivos no modo rw. Por exemplo, você pode usar este comando do gcloud para reativar o sistema de arquivos raiz:

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"
    

    Depois que o sistema de arquivos for ativado no modo de leitura e gravação novamente, conecte-se à instância por SSH.

  2. Execute sudo yum -y update para atualizar todos os pacotes instalados, inclusive gce-disk-expand, que contém a correção.

Agora a instância pode ser reinicializada sem ativar o sistema de arquivos raiz no modo somente leitura.

Instâncias criadas usando imagens do RHEL 7 criadas antes de rhel-7-v20160418 ou imagens do CentOS 7 criadas antes de centos-7-v20160418:

  1. Conecte-se à instância usando SSH. Se a conexão falhar, poder ser que a instância esteja travada no modo somente leitura. No entanto, você pode tentar recuperá-la. Caso você tenha se conectado à instância afetada por SSH antes, suas chaves SSH públicas já estarão no sistema de arquivos raiz e continuarão a funcionar. Execute um comando remoto por ssh para reativar o sistema de arquivos no modo rw. Por exemplo, você pode usar este comando do gcloud para reativar o sistema de arquivos raiz:

    gcloud compute ssh [INSTANCE_NAME] --command "sudo mount -o remount,rw /dev/sda1 /"
    

    Depois que o sistema de arquivos for ativado no modo de leitura e gravação novamente, conecte-se à instância por SSH.

  2. Edite o arquivo /etc/fstab e remova qualquer opção de ativação barrier=1 desse arquivo. A opção de ativação default precisa ser a única definida para a entrada do sistema de arquivos raiz. Você pode corrigir essa opção de ativação inválida com o seguinte comando:

    sudo sed -i 's/defaults,barrier[^ ,]*/defaults/' /etc/fstab
    

    Depois que você remover a opção de ativação barrier=1, a entrada do sistema de arquivos raiz no /etc/fstab deverá ter uma aparência semelhante à do exemplo abaixo, mas com um valor diferente para o UUID:

    UUID=b5e54172-67e3-4d52-95f4-4314e71b25fd / xfs defaults 0 0
    

Agora a instância pode ser reinicializada sem ativar o sistema de arquivos raiz no modo somente leitura.

Alteração inválida na imagem v20131120 do CentOS quando a opção iptables é ativada por padrão.

A versão v20131120 da imagem do CentOS 6, centos-6-v20131120, apresenta uma alteração inválida quando a opção iptables é ativada por padrão. Isso impede que as instâncias do CentOS que executam centos-6-v20131120 sejam acessadas pelo tráfego externo, mesmo quando há um recurso de regra de firewall relevante que permite a conexão.

Como alternativa, os usuários desativam ou atualizam a opção iptables para possibilitar a conexão, além de concederem acesso ao tráfego com as regras de firewall. Para desativar a iptables, execute:

# Save your iptable settings
user@centos-instance:~$ sudo service iptables save
# Stop the iptables service
user@centos-instance:~$ sudo service iptables stop
# Disable iptables on start up
user@centos-instance:~$ sudo chkconfig iptables off

Para atualizar a iptables, leia a documentação de iptables.

Imagens fornecidas pelo Google têm um bug conhecido com o driver ext4/scsi nos kernels estáveis do Debian e do CentOS

Um bug conhecido de ext4 pode causar vazamento de memória e falha em uma instância de máquina virtual com disco permanente muito carregado. As imagens centos-6-v20131120 e debian-7-wheezy-v20131120 são afetadas por esse problema. Para mais detalhes, consulte esta conversa da lista de discussão do kernel do Linux.

Nomes de instância maiores que 32 caracteres podem causar problemas com várias ferramentas do UNIX.

Reportado em: junho de 2012

Apesar de o limite para nomes de instância ser de até 63 caracteres, nomes maiores que 32 caracteres podem causar instabilidade em algumas ferramentas, inclusive naquelas usadas durante a inicialização. Como alternativa, escolha nomes de instância com menos de 32 caracteres.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine