Início / server / Perguntas / 1093513
Accepted
Vojtěch
Asked: 2022-02-13 23:48:32 +0800 CST

Instância com falha no mecanismo de computação do Google

  • 772

Eu tenho uma instância do GCE que está em execução há vários anos. Durante a noite, a instância foi reiniciada com os seguintes registros:

2022-02-13 04:46:36.370 CET compute.instances.hostError Instance terminated by Compute Engine.
2022-02-13 04:47:08.279 CET compute.instances.automaticRestart Instance automatically restarted by Compute Engine.

No entanto, a instância não foi reiniciada.

Eu posso me conectar ao console serial onde vejo isso:

serialport: Connected to ***.europe-west1-b.*** port 1 (
[ TIME ] Timed out waiting for device ***
[DEPEND] Dependency failed for File… ***.
[DEPEND] Dependency failed for /data.
[DEPEND] Dependency failed for Local File Systems.
[  OK  ] Stopped Dispatch Password …ts to Console Directory Watch.
[  OK  ] Stopped Forward Password R…uests to Wall Directory Watch.
[  OK  ] Reached target Timers.
         Starting Raise network interfaces...
[  OK  ] Closed Syslog Socket.
[  OK  ] Reached target Login Prompts.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Sockets.
[  OK  ] Started Emergency Shell.
[  OK  ] Reached target Emergency Mode.
         Starting Create Volatile Files and Directories...
[  OK  ] Finished Create Volatile Files and Directories.
         Starting Network Time Synchronization...
         Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Finished Update UTMP about System Boot/Shutdown.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Finished Update UTMP about System Runlevel Changes.
[  OK  ] Started Network Time Synchronization.
[  OK  ] Reached target System Time Set.
[  OK  ] Reached target System Time Synchronized.
         Stopping Network Time Synchronization...
[  OK  ] Stopped Network Time Synchronization.
         Starting Network Time Synchronization...
[  OK  ] Started Network Time Synchronization.
[  OK  ] Finished Raise network interfaces.
[  OK  ] Reached target Network.
[  OK  ] Reached target Network is Online.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to r
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Press Enter to continue.

Parece que um dos discos não pode ser conectado – mas o que posso fazer agora? O disco parece estar normalmente disponível no mecanismo de computação.

linux google-cloud-platform google-compute-engine

2 respostas

  1. Best Answer

    Receio que você não possa fazer nada com essa VM afetada.

    Na documentação do Host Events ou FAQ , você pode encontrar informações:

    Um erro de host ( compute.instances.hostError) significa que houve um problema de hardware ou software na máquina física que hospeda sua VM que causou a falha da VM. Um erro de host que envolve falha total de hardware ou outros problemas de hardware pode impedir a migração ao vivo de sua VM.

    Instância de VM que está na "nuvem", ainda é uma máquina física que está executando sua carga de trabalho. Infelizmente, esta instância teve uma falha de hardware ou software e não há nada que você possa fazer.

    O GCP introduziu algo chamado migração ao vivo que evita esse tipo de situação.

    O Compute Engine oferece migração ao vivo para manter suas instâncias de máquina virtual em execução mesmo quando ocorre um evento do sistema host, como uma atualização de software ou hardware, mas acho que é tarde demais para configurar este.

    ...

    A migração ao vivo mantém suas instâncias em execução durante:

    • Manutenção e atualizações regulares da infraestrutura.
    • Manutenção de rede e rede elétrica nos data centers.
    • Hardware com falha, como memória, CPU, placas de interface de rede, discos, energia e assim por diante. Isso é feito com base no melhor esforço; se um hardware falhar completamente ou impedir a migração ao vivo, a VM trava e reinicia automaticamente e um hostError é registrado.

    ...

    A migração ao vivo não altera nenhum atributo ou propriedade da própria VM. O processo de migração ao vivo apenas transfere uma VM em execução de uma máquina host para outra máquina host dentro da mesma zona.

    Possível solução alternativa

    Como você menciona que os discos são persistentes e ainda visíveis no GCP, você pode tentar reanexá-los a outra VM. Como guiar pode ser encontrado em Criando e anexando uma documentação de disco .

    • 2

  2. Finalmente encontrei a estranha razão para este erro - veja o original /etc/fstab:

    /dev/disk/by-id/google-***-data /data ext4 discard,defaults 0 2

    Mas não existe tal dispositivo neste caminho. Resolvi isso anexando /dev/sdb, mas acho que essa não é a melhor solução. Eu me pergunto como isso acontece que o dispositivo de repente desaparece completamente e no final mata a máquina.

    • 1

relate perguntas