Résoudre les problèmes de latence du réseau
Pour en savoir plus sur les façons d'améliorer la latence de connexion entre les processus dans Google Cloud et de réduire la latence des connexions TCP, consultez la page Optimiser TCP pour améliorer les performances réseau dans les scénarios Google Cloud et hybrides.
Résoudre les problèmes de trafic réseau interrompu
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
Google Cloud Console 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 n'afficher que 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 de transfert de protocole pour les règles de transfert privées
Utilisez les sections suivantes pour résoudre les problèmes courants liés au transfert de protocole pour règles de transfert privées.
Restriction régionale
Le transfert de protocole pour règles de transfert privées est une fonctionnalité régionale. Tous les clients et les instances de VM cibles doivent être dans la même région.
Message d'erreur : "An internal target instance can only be the target of one forwarding rule" (Une instance cible interne ne peut être la cible que d'une règle de transfert)
Si le message d'erreur An internal target instance can only be the target
of one forwarding rule s'affiche, vous essayez peut-être de configurer deux règles de transfert pointant vers la même instance cible. Il est impossible que plusieurs règles de transfert ciblent la même instance.
Résoudre les problèmes de latence sur les VM Compute Engine lors du traitement de taux de paquets élevés
Si votre VM subit une latence, une perte de paquets ou des retransmissions de paquets lors du traitement de taux de paquets élevés, il se peut que le nombre de files d'attente de réception (RX) ou de files d'attente de transmission (TX) dont elle dispose sur l'interface réseau (NIC) soit insuffisant pour le traitement de ces paquets.
Pour résoudre ces problèmes, consultez la page Files d'attente de réception et de transmission pour en savoir plus sur la manière dont Compute Engine alloue les files d'attente RX et TX.
Résoudre les problèmes de sursouscription des files d'attente de cartes d'interface réseau personnalisées
Avec une sursouscription de files d'attente, le nombre maximal de files d'attente pour la VM est le suivant:
[maximum queue count per VM] * [number of NICs]
Cependant, vous devez remplir les conditions spécifiées dans la section Allocation de files d'attente personnalisées. Par exemple, si vous n'avez pas spécifié de nombre de files d'attente personnalisées pour l'une des cartes d'interface réseau configurées pour la VM, vous obtenez une erreur semblable à celle-ci:
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Invalid value for field 'resource.networkInterfaces': ''. The total networking queue number is more than the number of vCPUs. Please specify the queue count for all of the interfaces.
Les projets sont migrés vers le DNS zonal, mais les VM du nouveau projet utilisent le DNS global
Si vous avez terminé la migration de vos projets existants du DNS global vers le DNS zonal, mais que vous découvrez que les VM d'un nouveau projet ont des noms DNS globaux, vous n'avez pas appliqué la règle d'administration booléenne constraints/compute.setNewProjectDefaultToZonalDNSOnly au niveau de l'organisation ou du dossier. Cette règle remplace le paramètre DNS par défaut, de sorte que les nouveaux projets utilisent le DNS zonal interne par défaut.
Pour obtenir des instructions sur l'application de cette règle, consultez la page Appliquer uniquement le DNS zonal par défaut pour les nouveaux projets.
Si vous n'utilisez pas de règle d'administration, mais utilisez plutôt l'entrée de métadonnées VmDnsSetting=ZonalOnly pour les projets ou les VM, vérifiez la valeur de métadonnées de la VM. Si VmDnsSetting=GlobalDefault est configuré dans les métadonnées de la VM, cette valeur remplace la valeur de métadonnées définie au niveau du projet.
Pour en savoir plus sur la définition des valeurs de métadonnées d'un projet ou d'une VM, consultez la section Définir des métadonnées personnalisées.