Solución de problemas generales

En esta página, se describen los pasos para solucionar problemas que pueden resultar útiles si tienes inconvenientes cuando usas instancias de Compute Engine.

Soluciona problemas generales con instancias

Si la instancia no se inicia

Aquí hay algunos consejos para solucionar problemas del disco de arranque persistente si no arranca.

  • Examina el resultado del puerto en serie de la instancia de máquina virtual.

    El BIOS, el bootloader y el kernel de una instancia imprimirán sus mensajes de depuración en el resultado del puerto en serie de la instancia y proporcionarán información valiosa sobre los errores o problemas que experimentó la instancia. Si habilitas el registro de resultados del puerto en serie en Stackdriver, puedes acceder a esta información incluso cuando la instancia no esté en ejecución. Consulta la página sobre cómo visualizar los resultados del puerto en serie.

  • Habilita el acceso interactivo a la consola en serie.

    Puedes habilitar el acceso interactivo a la consola en serie de una instancia para poder acceder y depurar problemas de arranque desde la instancia, sin necesidad de que la instancia se inicie por completo. Para obtener más información, lee la página sobre cómo interactuar con la consola en serie.

  • Verifica que el disco tenga un sistema de archivos válido.

    Si el sistema de archivos está dañado o no es válido, no podrás iniciar la instancia. Valida el sistema de archivos del disco:

    1. Separa el disco en cuestión de cualquier instancia a la que esté conectado, si corresponde:

      gcloud compute instances delete old-instance --keep-disks boot
      
    2. Inicia una nueva instancia con la última imagen proporcionada por Google:

      gcloud compute instances create debug-instance
      
    3. Adjunta el disco como un disco que no sea de arranque, pero no lo actives. Reemplaza DISK con el nombre del disco que no arrancará. Ten en cuenta que también se proporciona un nombre de dispositivo para que el disco se identifique con facilidad en la instancia:

      gcloud compute instances attach-disk debug-instance --disk DISK --device-name debug-disk
      
    4. Conéctate a la instancia:

      gcloud compute ssh debug-instance
      
    5. Busca la partición raíz del disco, que se identifica con la notación part1. En este caso, la partición raíz del disco se encuentra en /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. Ejecuta una verificación del sistema de archivos en la partición raíz:

      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. Activa el sistema de archivos:

      user@debug-instance:~$ sudo mkdir /mydisk
      
      user@debug-instance:~$ sudo mount /dev/sdb1 /mydisk
      
    8. Verifica que el disco tenga archivos kernel:

      user@debug-instance~:$ ls /mydisk/boot/vmlinuz-*
      /mydisk/boot/vmlinuz-3.2.0-4-amd64
      
  • Comprueba que el disco tenga un registro de arranque maestro (MBR) válido.

    Ejecuta el siguiente comando en la instancia de depuración que conectó el disco de arranque persistente, como /dev/sdb:

    $ sudo parted /dev/sdb print
    

    Si el MBR es válido, debes incluir información sobre el sistema de archivos:

    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
    

Si no se puede crear una instancia

Aquí hay algunos consejos para solucionar problemas si la instancia no se crea.

  • Las operaciones simultáneas de mutación o creación de recursos pueden causar errores. Por ejemplo, si modificas rangos secundarios en una subred y creas una VM al mismo tiempo, es posible que veas el siguiente error: The resource 'projects/[PROJECT]/regions/[REGION]/subnetworks/default' is not ready. La solución es volver a llevar a cabo la operación con errores.

  • Si recibes un error de recurso (como ZONE_RESOURCE_POOL_EXHAUSTED o ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS) cuando solicitas recursos nuevos, significa que la zona no puede acomodar tu solicitud ahora mismo. Este error se debe a la capacidad de obtener recursos de Compute Engine y no a tu cuota de Compute Engine.

    Estos son algunos consejos que pueden ser de ayuda:

    • Debido a que esta situación es temporal y puede cambiar con frecuencia según la demanda fluctuante, vuelve a intentar la solicitud más tarde.
    • Si es posible, intenta crear los recursos en otra zona de la región o en otra región.
    • Si es posible, cambia la forma de la VM que solicitas. Es más fácil obtener tipos de máquinas más pequeños que más grandes. Un cambio en la solicitud, como reducir la cantidad de GPU o usar una VM personalizada con menos memoria o CPU virtuales, podría permitir que la solicitud continúe.
    • Usa las reservas de Compute Engine para reservar recursos dentro de una zona a fin de asegurarte de que los recursos que necesitas estén disponibles cuando los necesites.
    • Si intentas crear una instancia interrumpible, recuerda que las VM interrumpibles son de capacidad libre y, por lo tanto, es posible que no se puedan obtener durante los períodos de demanda máxima.
    • Si recibes un error notFound o does not exist in zone cuando solicitas recursos nuevos, significa que la zona no ofrece el recurso o tipo de máquina que solicitaste. Consulta la página sobre regiones y zonas para averiguar qué funciones están disponibles en cada zona.

Si se cae el tráfico de red desde/hacia la instancia

Google Compute Engine solo permite que el tráfico de red permitido de manera explícita por las reglas de firewall del proyecto llegue a la instancia. Por defecto, todos los proyectos incluyen de forma automática una red predeterminada que permite ciertos tipos de conexiones. Si niegas todo el tráfico de forma predeterminada, eso también negará las conexiones SSH y todo el tráfico interno. Para obtener más información, consulta la página Reglas de firewall.

Además, es posible que debas ajustar la configuración keep-alive de TCP para evitar el tiempo de espera de conexión inactiva predeterminado de 10 minutos. Para obtener más información, consulta la sección sobre comunicación entre Internet y las instancias.

Soluciona problemas de reglas de firewall o rutas en una instancia

GCP Console proporciona detalles de red para cada interfaz de red de una instancia. Puedes ver todas las reglas o rutas de firewall que se aplican a una interfaz, o puedes ver solo las reglas y rutas que usa la interfaz. Cualquiera de las vistas puede ayudarte a solucionar qué reglas de firewall y rutas se aplican a la instancia y cuáles se usan realmente (en los casos en que la prioridad y el orden de procesamiento anulan otras reglas o rutas).

Para obtener más información, consulta la información de solución de problemas en la documentación de nube privada virtual:

Soluciona problemas con SSH

Bajo ciertas condiciones, es posible que una instancia de Linux deje de aceptar conexiones SSH. Hay muchas razones por las que esto puede suceder, desde un disco lleno hasta una configuración accidental de sshd. En esta sección, se describe una serie de consejos y enfoques para solucionar y resolver problemas comunes de SSH.

Verifica las reglas de firewall

Compute Engine aprovisiona cada proyecto con un conjunto predeterminado de reglas de firewall que permiten el tráfico SSH. Si la regla de firewall predeterminada que permite conexiones SSH se quita de alguna manera, no podrás acceder a la instancia. Verifica la lista de firewalls con la herramienta de línea de comandos de gcloud y asegúrate de que la regla default-allow-ssh esté presente.

gcloud compute firewall-rules list

Si falta, agrégala de nuevo:

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

Depura el problema en la consola en serie

Puedes habilitar el acceso de lectura y escritura a la consola en serie de una instancia para poder acceder a la consola y solucionar problemas de la instancia. Esto es muy útil cuando no puedes acceder con SSH o si la instancia no tiene conexión a la red. La consola en serie permanece accesible en ambas situaciones.

Para saber cómo habilitar el acceso interactivo y conectarte a la consola en serie de una instancia, lee la página sobre cómo interactuar con la consola en serie.

Prueba la red

Puedes usar la herramienta netcat para conectarte a la instancia en el puerto 22 y determinar si la conexión de red funciona. Si se conecta y ves un banner ssh (p. ej., SSH-2.0-OpenSSH_6.0p1 Debian-4), la conexión de red funciona y puedes descartar que haya problemas de firewall. Primero, usa la herramienta de gcloud a fin de obtener la natIP externa de la instancia:

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

Usa el comando nc para conectarte a la instancia:

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

Prueba un usuario nuevo

El problema que impide el acceso puede estar limitado a tu cuenta (p. ej., si los permisos en el archivo ~/.ssh/authorized_keys de la instancia no se configuraron bien).

Intenta usar la herramienta de gcloud y especifica otro nombre de usuario con la solicitud SSH para acceder como un usuario nuevo. La herramienta de gcloud actualizará los metadatos del proyecto para agregar al usuario nuevo y permitir el acceso SSH.

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

en el que [USER] es un nombre de usuario nuevo para acceder.

Usa el disco en una instancia nueva

Si el conjunto de pasos anterior no funcionó y la instancia que te interesa se inicia desde un disco persistente, puedes desconectar el disco persistente y adjuntar este disco para usarlo en la instancia nueva. Reemplaza DISK por tu nombre de 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

Inspecciona una instancia sin cerrarla

Es posible que tengas una instancia a la que no puedas conectarte y siga entregando tráfico de producción de forma correcta. En este caso, es posible que desees inspeccionar el disco sin interrumpir la capacidad de la instancia para entregar a los usuarios. Primero, toma una instantánea del disco de arranque de la instancia, crea un disco nuevo a partir de esa instantánea, crea una instancia temporal y, por último, conecta y activa el disco persistente nuevo en la instancia temporal para solucionar los problemas del disco.

  1. Crea una nueva red de VPC para alojar la instancia clonada:

    gcloud compute networks create debug-network
    
  2. Agrega una regla de firewall para permitir conexiones SSH a la red:

    gcloud compute firewall-rules create debug-network-allow-ssh --allow tcp:22
    
  3. Crea una instantánea del disco en cuestión y reemplaza DISK con el nombre del disco:

    gcloud compute disks snapshot DISK --snapshot-name debug-disk-snapshot
    
  4. Crea un disco nuevo con la instantánea que acabas de crear:

    gcloud compute disks create example-disk-debugging --source-snapshot debug-disk-snapshot
    
  5. Crea una instancia de depuración nueva sin una dirección IP externa:

    gcloud compute instances create debugger --network debug-network --no-address
    
  6. Adjunta el disco de depuración a la instancia:

    gcloud compute instances attach-disk debugger --disk example-disk-debugging
    
  7. Sigue las instrucciones para conectarte a una instancia sin una dirección IP externa.

  8. Después de acceder a la instancia del depurador, soluciona los problemas de la instancia. Por ejemplo, puedes ver los registros de instancias:

    $ 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
    

Usa una secuencia de comandos de inicio

Si ninguna de las sugerencias anteriores te ayudó, puedes crear una secuencia de comandos de inicio para recopilar información justo después de que comience la instancia. Sigue las instrucciones para ejecutar una secuencia de comandos de inicio.

Luego, también deberás restablecer la instancia antes de que los metadatos surtan efecto; para eso, ejecuta el comando gcloud compute instances reset. Si no, también puedes recrear la instancia con una secuencia de comandos de inicio de diagnóstico:

  1. Ejecuta gcloud compute instances delete con la marca --keep-disks.

    gcloud compute instances delete INSTANCE --keep-disks boot
    
  2. Agrega una instancia nueva con el mismo disco y especifica la secuencia de comandos de inicio.

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

Como punto de partida, puedes usar la secuencia de comandos compute-ssh-diagnostic para recopilar información de diagnóstico de los problemas más comunes.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Compute Engine