Conseils d'ordre général sur l'utilisation de Compute Engine

Cette page présente les conseils qui peuvent vous être utiles si vous rencontrez des problèmes lors de l'utilisation de Compute Engine.

Si vous avez besoin d'aide pour résoudre des problèmes spécifiques, consultez l'une des sections suivantes :

Affichage de différents formats de réponse

Google Cloud CLI effectue la plupart de ses actions en effectuant des appels d'API REST. Les résultats mis en forme ne montrent que les informations les plus importantes renvoyées par une commande spécifique. Pour consulter les différents formats de réponse, utilisez l'option --format qui affiche la réponse dans différents formats de sortie, parmi lesquels json, yaml et text. Par exemple, pour afficher une liste d'instances au format JSON, utilisez --format json :

gcloud compute instances list --format json

Affichage des journaux gcloud compute

gcloud CLI crée et stocke les journaux dans un fichier journal que vous pouvez interroger et qui est disponible à l'emplacement $HOME/.config/gcloud/logs. Pour afficher le dernier fichier journal sur un système d'exploitation basé sur Linux, exécutez ce qui suit :

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

Le fichier journal contient des informations concernant toutes les requêtes et réponses générées à l'aide de l'outil gcloud CLI.

Pour supprimer définitivement et automatiquement les fichiers journaux créés par gcloud CLI, utilisez la propriété max_log_days qui définit le nombre maximal de jours de conservation des fichiers journaux avant leur suppression. La valeur par défaut est de 30 jours. Si vous définissez la valeur de cette propriété sur 0, cela désactive la fonction de récupération de mémoire au niveau des journaux et ne supprime pas les fichiers journaux.

 gcloud config set core/max_log_days DAYS_TO_RETAIN_LOGS

Désactivez la journalisation de fichiers gcloud CLI :

Le fichier $HOME/.config/gcloud/logs consomme de l'espace sur le système de fichiers local. La quantité de journaux générés peut surcharger la quantité d'espace sur le système de fichiers local, ce qui peut entraîner des problèmes tels que les suivants :

  • L'utilisation de l'espace atteint 100 % sur l'instance.
  • Échec de l'exécution des commandes de journalisation de gcloud CLI, car il ne reste plus d'espace pour créer un fichier sur le système de fichiers local.

Pour modifier le comportement de gcloud CLI et désactiver la journalisation des fichiers, utilisez la propriété disable_file_logging :

 gcloud config set core/disable_file_logging True

Sélection des noms de ressources

Lorsque vous sélectionnez des noms pour vos ressources, n'oubliez pas que ces noms conviviaux peuvent s'afficher sur les tableaux de bord de support et tableaux de bord opérationnels de Compute Engine. Pour cette raison, il est recommandé d'exclure toute information sensible de vos noms de ressource.

Connexion à Internet

Une instance ne dispose d'un accès Internet direct que si les deux conditions suivantes sont remplies :

Les instances peuvent également accéder indirectement à Internet en se connectant via Cloud NAT ou un proxy basé sur une instance. Pour plus d'informations, y compris sur la configuration des règles de pare-feu, consultez la section Conditions d'accès à Internet.

Connexions inactives

Les composants réseauGoogle Cloud ne maintiennent pas les connexions inactives ouvertes indéfiniment. Pour éviter les connexions interrompues, examinez comment les composants suivants gèrent les connexions inactives :

Pour éviter que les connexions TCP inactives ne soient abandonnées, vous pouvez configurer TCP keepalive, qui maintient les connexions actives en envoyant des paquets périodiques (sondes) pour réinitialiser les délais d'inactivité :

  • Assurez-vous que les applications client ou serveur créent des sockets avec l'option de socket SO_KEEPALIVE. Consultez la documentation de votre application ou de votre bibliothèque logicielle pour déterminer comment ouvrir des sockets avec l'option SO_KEEPALIVE.

  • Configurez les paramètres TCP keepalive suivants :

    • La période d'inactivité, qui représente le temps qui doit s'écouler entre le dernier paquet non keep-alive et la première requête keep-alive d'une séquence.

    • L'intervalle keepalive, qui représente le temps entre chaque sonde keepalive TCP.

    • Les messages keepalive, représentant le nombre total de messages keepalive TCP non acquittés qui sont envoyés dans une séquence avant que la connexion ne soit considérée comme interrompue.

Les applications client ou serveur peuvent définir les paramètres keep-alive TCP à l'aide d'options de socket telles que TCP_KEEPIDLE, TCP_KEEPINTVL et TCP_KEEPCNT, ou vous pouvez définir les paramètres keep-alive TCP pour votre système d'exploitation.

Les exemples suivants montrent comment définir une période d'inactivité de 60 secondes pour votre système d'exploitation :

Linux


Exécutez la commande suivante :

$ sudo /sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5

Pour vous assurer que les paramètres persistent après un redémarrage, ajoutez-les à votre fichier /etc/sysctl.conf. Ces paramètres du noyau s'appliquent à IPv4 et IPv6, même s'ils contiennent ipv4 dans leur nom.

Pour obtenir des informations supplémentaires, consultez le guide Linux TCP Keepalive.

macOS


Exécutez la commande suivante :

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

Windows


Sous le chemin de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\, ajoutez les paramètres suivants à l'aide du type de données DWORD ou modifiez les valeurs si les paramètres existent déjà :

KeepAliveInterval: 1000
KeepAliveTime: 60000
TcpMaxDataRetransmissions: 10

Accéder à Compute Engine avec un utilisateur SSH différent

Par défaut, l'outil de ligne de commande gcloud compute utilise la variable $USER pour ajouter des utilisateurs au fichier /etc/passwd afin de se connecter aux instances à l'aide de SSH. Vous pouvez spécifier un autre utilisateur à l'aide de l'indicateur --ssh-key-file PRIVATE_KEY_FILE lorsque vous exécutez la commande gcloud compute ssh. Exemple :

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

Pour plus d'informations, consultez la documentation de référence de gcloud.

Interagir avec la console série

Activez l'accès interactif à la console série d'une instance pour pouvoir connecter des instances et résoudre des problèmes liés à celles-ci via la console série.

Pour en savoir plus, consultez Dépannage à l'aide de la console série.

Éviter la fragmentation des paquets pour les instances construites à partir d'images personnalisées

Le réseau VPC possède une unité de transmission maximale (MTU, Maximum Transmission Unit) par défaut de 1460 octets pour les images Linux et les images Windows Server. Cependant, la MTU du réseau peut être modifiée. Pour en savoir plus, consultez la présentation de l'unité de transmission maximale dans la documentation sur les VPC.

Lorsque vous créez des applications clientes qui communiquent avec des instances Compute Engine sur des sockets UDP, vous pouvez éviter la fragmentation si vous définissez la taille maximale des données du datagramme UDP sur 28 octets de moins que la MTU du réseau. Par exemple, si la taille de la MTU du réseau est de 1 460 octets, vous pouvez envoyer jusqu'à 1 432 octets de données UDP par paquet sans fragmentation. Si la MTU du réseau est de 1 500 octets, vous pouvez envoyer jusqu'à 1 472 octets de données UDP sans fragmentation. Les 28 octets sont utilisés pour un en-tête de paquet IPv4 (20 octets) et un en-tête de datagramme UDP (8 octets). Vous pouvez définir la MTU du réseau sur un maximum de 8 896 octets.

Diagnostics des performances et du processeur

Des pics de latence ou des plantages inattendus dans votre application sur les plates-formes de processeurs modernes peuvent indiquer des blocages de bus de processeur. Ces problèmes se produisent lorsque des opérations atomiques sont effectuées sur une mémoire non alignée.

Pour identifier le problème, examinez la sortie du port série et recherchez l'entrée de journal suivante : x86/split lock detection: #DB: <process_name>/<pid> took a bus_lock trap at address: 0x<address>.

La sortie de la console série permet de détecter les événements au niveau matériel, tels que les traps de verrouillage du bus du processeur, qui indiquent des opérations de mémoire non alignées pouvant dégrader les performances du système.

Pour en savoir plus, consultez Résoudre les problèmes de blocage du bus du processeur.