Dépannage d'ordre général

Cette page décrit les étapes de dépannage qui vous aideront si vous rencontrez des problèmes lors de l'utilisation d'instances Compute Engine.

Résoudre les problèmes généraux des instances

Si l'instance ne démarre pas

Voici quelques conseils pour dépanner votre disque de démarrage persistant s'il ne démarre pas.

  • Vérifiez la sortie du port de série de votre instance de machine virtuelle.

    Le BIOS, le bootloader et le noyau d'une instance impriment leurs messages de débogage sur la sortie du port série de l'instance, ce qui représente une source d'informations précieuse sur les erreurs ou problèmes rencontrés par l'instance. Si vous activez la journalisation des données en sortie du port série sur Stackdriver, vous pouvez accéder à ces informations même lorsque votre instance n'est pas en cours d'exécution. Consultez la page Afficher les données en sortie du port série.

  • Activez l'accès interactif à la console série.

    Vous pouvez activer l'accès interactif à la console série d'une instance afin de pouvoir vous connecter et résoudre les problèmes de démarrage à partir de l'instance sans nécessiter son démarrage complet. Pour plus d'informations, consultez la page Interagir avec la console série.

  • Vérifiez que le disque dispose d'un système de fichiers valide.

    Si le système de fichiers est corrompu ou présente d'autres problèmes, vous ne pourrez pas lancer votre instance. Validez le système de fichiers du disque :

    1. Dissociez le disque en question des instances auxquelles il est associé, le cas échéant :

      gcloud compute instances delete old-instance --keep-disks boot
      
    2. Démarrez une nouvelle instance avec la dernière image fournie par Google :

      gcloud compute instances create debug-instance
      
    3. Associez votre disque en tant que disque non amorçable, mais ne l'installez pas. Remplacez DISK par le nom du disque qui ne démarre pas. Notez que nous fournissons également un nom d'appareil afin que le disque soit facilement identifiable sur l'instance :

      gcloud compute instances attach-disk debug-instance --disk DISK --device-name debug-disk
      
    4. Connectez-vous à l'instance :

      gcloud compute ssh debug-instance
      
    5. Recherchez la partition racine du disque, identifiée par la notation part1. Ici, la partition racine du disque est sur /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. Exécutez une vérification du système de fichiers sur la partition racine :

      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. Installez le système de fichiers :

      user@debug-instance:~$ sudo mkdir /mydisk
      
      user@debug-instance:~$ sudo mount /dev/sdb1 /mydisk
      
    8. Vérifiez que le disque dispose des fichiers du noyau :

      user@debug-instance~:$ ls /mydisk/boot/vmlinuz-*
      /mydisk/boot/vmlinuz-3.2.0-4-amd64
      
  • Vérifiez que le disque dispose d'un MBR (enregistrement de démarrage maître) valide.

    Exécutez la commande suivante sur l'instance de débogage à laquelle est associé le disque de démarrage persistant, tel que /dev/sdb :

    $ sudo parted /dev/sdb print
    

    Si le MBR est valide, les informations relatives au système de fichiers doivent être indiquées :

    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 vous ne pouvez pas créer d'instance

Voici quelques conseils pour vous aider si votre instance n'est pas créée.

  • Des opérations simultanées de mutation ou de création de ressources peuvent provoquer une erreur. Par exemple, si vous modifiez des plages secondaires dans un sous-réseau et que vous créez une VM en même temps, vous pouvez rencontrer l'erreur suivante : The resource 'projects/[PROJECT]/regions/[REGION]/subnetworks/default' is not ready. La solution consiste à réessayer l'opération qui a échoué.

  • Si vous rencontrez une erreur associée à une ressource (telle que ZONE_RESOURCE_POOL_EXHAUSTED ou ZONE_RESOURCE_POOL_EXHAUSTED_WITH_DETAILS) lorsque vous demandez de nouvelles ressources, cela signifie que la zone ne peut pas traiter votre demande pour le moment. Cette erreur est due à l'obtention de ressources Compute Engine, et ne vient pas du quota Compute Engine.

    Voici quelques conseils pour vous aider :

    • Cette situation est temporaire et peut changer fréquemment en fonction des fluctuations des demandes, alors réessayez ultérieurement.
    • Si cela est possible, essayez de créer des ressources dans une autre zone de la région ou dans une autre région.
    • Si cela est possible, modifiez la forme de la VM que vous demandez. Il est plus aisé d'obtenir des petits types de machines que de grands types. Une modification de votre demande, telle que la réduction du nombre de GPU ou l'utilisation d'une VM personnalisée comportant moins de mémoire ou de processeurs virtuels pourrait faire en sorte que votre demande aboutisse.
    • Utilisez les réservations Compute Engine pour réserver des ressources à l'intérieur d'une zone, afin de vous assurer que les ressources dont vous avez besoin sont disponibles lorsqu'elles sont nécessaires.
    • Si vous essayez de créer une instance préemptive, rappelez-vous que les VM préemptives sont des capacités de secours, vous ne pourrez peut-être pas les obtenir en période de fortes demandes.
    • Si vous rencontrez l'erreur notFound ou does not exist in zone lorsque vous demandez de nouvelles ressources, cela signifie que la zone n'offre pas la ressource ou le type de machine que vous souhaitez. Consultez la page Régions et zones pour découvrir les fonctionnalités disponibles pour chaque zone.

Si le trafic réseau au niveau de votre instance est éliminé

Google Compute Engine n'autorise que le trafic réseau explicitement approuvé par les règles de pare-feu de votre projet à accéder à votre instance. Par défaut, tous les projets sont automatiquement dotés d'un réseau par défaut permettant certains types de connexions. Si vous refusez tout trafic par défaut, les connexions SSH et le trafic interne sont bloqués. Pour plus d'informations, consultez la page Règles de pare-feu.

En outre, vous devrez peut-être ajuster les paramètres TCP keep-alive pour contourner le délai d'inactivité de la connexion par défaut de 10 minutes. Pour plus d'informations, consultez la section Communication entre vos instances et Internet.

Résoudre les problèmes de règles de pare-feu ou de routes sur une instance

La console GCP fournit des détails sur le réseau pour chaque interface réseau d'une instance. Vous pouvez afficher toutes les règles de pare-feu ou routes qui s'appliquent à une interface, ou afficher uniquement les règles et les routes utilisées par l'interface. Les deux affichages peuvent vous aider à déterminer les règles de pare-feu et routes qui s'appliquent à l'instance et celles qui sont réellement utilisées (dans les cas où l'ordre de priorité et l'ordre de traitement ignorent les autres règles ou routes).

Pour en savoir plus, consultez les informations de dépannage dans la documentation sur le cloud privé virtuel :

Résoudre les problèmes liés à SSH

Dans certaines conditions, il est possible qu'une instance Linux n'accepte plus les connexions SSH. Plusieurs explications sont possibles, allant d'un disque plein à une mauvaise configuration accidentelle de sshd. Cette section propose des conseils et approches pour résoudre les problèmes courants liés à SSH.

Vérifier les règles de pare-feu

Compute Engine provisionne chaque projet avec des règles de pare-feu par défaut qui autorisent le trafic SSH. Si la règle de pare-feu par défaut autorisant les connexions SSH est supprimée, vous ne pourrez pas accéder à votre instance. Vérifiez votre liste de pare-feu à l'aide de l'outil de ligne de commande gcloud afin de vous assurer que la règle default-allow-ssh est présente.

gcloud compute firewall-rules list

Si elle est absente, ajoutez-la :

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

Résoudre le problème dans la console série

Vous pouvez activer l'accès en lecture/écriture à la console série d'une instance pour vous connecter à la console et résoudre les problèmes liés à l'instance. Ceci est particulièrement utile lorsque vous ne pouvez pas vous connecter avec SSH ou si l'instance ne dispose d'aucune connexion au réseau. La console série reste accessible dans ces deux conditions.

Pour découvrir comment activer l'accès interactif et vous connecter à la console série d'une instance, consultez la page Interagir avec la console série.

Tester le réseau

Utilisez l'outil netcat pour vous connecter à l'instance sur le port 22 et déterminer si la connexion réseau fonctionne. Si vous vous connectez et voyez une bannière SSH (par exemple, SSH-2.0-OpenSSH_6.0p1 Debian-4), la connexion réseau fonctionne et vous pouvez éliminer les problèmes de pare-feu. Utilisez d'abord l'outil gcloud pour obtenir l'adresse IP externe natIP pour votre instance :

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

Utilisez la commande nc pour vous connecter à l'instance :

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

Essayer un nouvel utilisateur

L'erreur que vous rencontrez lors de la connexion est peut-être limitée à votre compte (par exemple, si les autorisations du fichier ~/.ssh/authorized_keys sur l'instance ont été mal configurées).

Essayez d'utiliser l'outil gcloud pour vous connecter en tant que nouvel utilisateur, en spécifiant un autre nom d'utilisateur avec la requête SSH. L'outil gcloud mettra à jour les métadonnées du projet pour ajouter un nouvel utilisateur et autoriser l'accès SSH.

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

[USER] est le nouveau nom d'utilisateur avec lequel se connecter.

Utiliser le disque sur une nouvelle instance

Si l'ensemble des étapes ci-dessus ne donnent pas de résultat et que l'instance désirée est démarrée à partir d'un disque persistant, vous pouvez dissocier le disque persistant et associer ce disque pour l'utiliser avec la nouvelle instance. Remplacez DISK par le nom de disque :

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

Inspecter une instance sans l'arrêter

Il se peut que vous ne puissiez pas vous connecter à une instance qui continue de diffuser correctement le trafic de production. Dans ce cas, vous souhaiterez peut-être inspecter le disque sans interrompre les fonctions de l'instance pour les utilisateurs. Commencez par prendre un instantané du disque de démarrage de l'instance, puis créez un disque à partir de cet instantané, créez une instance temporaire, et enfin associez et installez le nouveau disque persistant sur l'instance temporaire pour résoudre les problèmes liés au disque.

  1. Créez un réseau VPC pour héberger l'instance clonée :

    gcloud compute networks create debug-network
    
  2. Ajoutez une règle de pare-feu pour autoriser les connexions SSH au réseau :

    gcloud compute firewall-rules create debug-network-allow-ssh --allow tcp:22
    
  3. Créez un instantané du disque en question, en remplaçant DISK par le nom du disque :

    gcloud compute disks snapshot DISK --snapshot-name debug-disk-snapshot
    
  4. Créez un disque avec l'instantané que vous venez de générer :

    gcloud compute disks create example-disk-debugging --source-snapshot debug-disk-snapshot
    
  5. Créez une instance de débogage sans adresse IP externe :

    gcloud compute instances create debugger --network debug-network --no-address
    
  6. Associez le disque de débogage à l'instance :

    gcloud compute instances attach-disk debugger --disk example-disk-debugging
    
  7. Suivez les instructions pour vous connecter à une instance sans adresse IP externe.

  8. Une fois connecté à l'instance de débogage, dépannez l'instance. Par exemple, vous pouvez consulter les journaux de l'instance :

    $ 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
    

Utiliser un script de démarrage

Si aucune des suggestions précédentes n'apporte de résultat, vous pouvez créer un script de démarrage pour collecter les informations juste après le démarrage de l'instance. Suivez les instructions pour exécuter un script de démarrage.

Vous devez ensuite réinitialiser votre instance avant que les métadonnées soient affectées en exécutant la commande gcloud compute instances reset. Vous pouvez également recréer l'instance avec un script de démarrage de diagnostic :

  1. Exécutez la commande gcloud compute instances delete avec l'indicateur --keep-disks.

    gcloud compute instances delete INSTANCE --keep-disks boot
    
  2. Ajoutez une nouvelle instance avec le même disque et spécifiez le script de démarrage.

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

Pour commencer, vous pouvez utiliser le script compute-ssh-diagnostic afin de collecter des informations de diagnostic pour les problèmes les plus courants.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine