Bande passante réseau

Google Cloud tient compte de la bande passante par instance de calcul, et non par interface réseau virtuelle (vNIC) ou adresse IP. Le type de machine d'une VM définit son débit de sortie maximal, que vous ne pouvez atteindre que dans des situations spécifiques.

Cette page décrit les attentes possibles en termes de bande passante, ce qui s'avère utile lors de la planification des déploiements. La bande passante est catégorisée selon deux dimensions :

  • Sortie ou entrée : tel qu'utilisées sur cette page, la sortie et l'entrée sont toujours du point de vue d'une instance Google Cloud :
    • Les paquets envoyés depuis une instance Google Cloud composent son trafic de sortie (trafic sortant).
    • Les paquets envoyés vers une instance Google Cloud composent son trafic d'entrée (trafic entrant).
  • Mode de routage du paquet : un paquet peut être acheminé à partir d'une instance émettrice ou de réception à l'aide de routes dont les sauts suivants se trouvent au sein d'un réseau VPC ou en dehors d'un réseau VPC.

Ni les interfaces réseau virtuelles (vNIC) supplémentaires, ni les adresses IP supplémentaires par vNIC n'augmentent la bande passante d'entrée ou de sortie pour une instance de calcul. Par exemple, une VM C3 dotée de 22 processeurs virtuels est limitée à 23 Gbit/s de bande passante totale de sortie. Si vous configurez la VM C3 avec deux cartes d'interface réseau virtuelles, la VM est toujours limitée à 23 Gbit/s de bande passante totale de sortie, et non à 23 Gbit/s de bande passante par carte d'interface réseau virtuelle.

Toutes les informations sur cette page s'appliquent aux instances Compute Engine, ainsi qu'aux produits qui dépendent des instances Compute Engine. Par exemple, un nœud Google Kubernetes Engine est une instance Compute Engine.

Récapitulatif sur la bande passante

Le tableau suivant illustre les attentes en termes de bande passante selon qu'un paquet est envoyé depuis (sortie) une instance de calcul ou reçu par (entrée) une instance de calcul et selon la méthode de routage des paquets.

Sortie

Attentes en termes de bande passante
Routage au sein d'un réseau VPC

  • Principalement défini par une bande passante de sortie maximale par instance en fonction du type de machine de l'instance émettrice et si le réseau Tier_1 est activé.

    • Les VM N2, N2D, C2, C2D et C4A avec un réseau Tier_1 acceptent des limites de bande passante de sortie allant jusqu'à 100 Gbit/s.
    • Les VM H3 acceptent des limites de bande passante de sortie de VM à VM jusqu'à 200 Gbit/s.
    • Les instances X4, A2 et G2 acceptent des limites de bande passante de sortie allant jusqu'à 100 Gbit/s.
    • Les instances A3 acceptent des limites de bande passante de sortie allant jusqu'à 1 800 Gbit/s.
    • Les instances C4, C3, C3D et Z3 acceptent jusqu'à 200 Gbit/s de limites de bande passante de sortie avec la mise en réseau Tier_1.
  • Pour connaître d'autres facteurs, définitions et scénarios, consultez la section Sortie vers des destinations routables dans un réseau VPC.
Routage en dehors d'un réseau VPC

  • Principalement défini par une bande passante de sortie maximale par instance en fonction du type de machine de l'instance émettrice et selon que le réseau Tier_1 est activé ou non. À l'exception des VM H3, la sortie maximale possible d'une instance émettrice vers une destination située en dehors de son réseau VPC ne peut pas dépasser la valeur suivante :

    • Au total : 7 Gbit/s lorsque le réseau Tier_1 n'est pas activé
    • 25 Gbit/s au total lorsque le réseau Tier_1 est activé
    • 3 Gbit/s par flux
  • Pour connaître les autres facteurs, définitions et mises en garde, consultez la section Sortie vers des destinations en dehors d'un réseau VPC.

Entrée

Attentes en termes de bande passante
Routage au sein d'un réseau VPC
  • En règle générale, les taux d'entrée sont semblables aux taux de sortie d'un type de machine.
  • La taille de votre instance de calcul, la capacité de la carte d'interface réseau du serveur, le trafic entrant dans les autres VM invitées s'exécutant sur le même matériel hôte, la configuration réseau de votre OS invité et le nombre de lectures de disque effectuées par votre instance peuvent tous avoir un impact sur le taux d'entrée.
  • Google Cloud n'impose aucune limite supplémentaire concernant les taux d'entrée au sein d'un réseau VPC.
  • Pour connaître d'autres facteurs, définitions et scénarios, consultez la section Sortie vers des destinations routables dans un réseau VPC.
Routage en dehors d'un réseau VPC

  • Google Cloud protège chaque instance de calcul en limitant le trafic entrant acheminé en dehors d'un réseau VPC. La limite fixée par la restriction correspond au premier débit atteint parmi les deux suivants :

    • 1 800 000 paquets par seconde (pps)
    • 30 Gbit/s

  • Pour une série de machines compatible avec plusieurs cartes d'interface réseau physiques, comme la série A3, la limite est le premier des débits courants suivants:

    • 1 800 000 paquets par seconde et par carte d'interface réseau
    • 30 Gbit/s par carte d'interface réseau physique
  • Pour découvrir d'autres facteurs, définitions et scénarios, consultez la section Entrée vers des destinations en dehors d'un réseau VPC.

Bande passante de sortie

Google Cloud limite la bande passante sortante (sortie) à l'aide de taux de sortie maximaux par instance. Ces taux sont basés sur le type de machine de l'instance de calcul qui envoie le paquet et selon que la destination du paquet est accessible ou non à l'aide de routes au sein d'un réseau VPC ou de routes en dehors d'un réseau VPC. La bande passante sortante inclut les paquets émis par toutes les cartes d'interface réseau de l'instance, ainsi que les données transférées vers tous les volumes Hyperdisk et Persistent Disk connectés à l'instance.

Bande passante de sortie maximale par instance

La bande passante de sortie maximale par instance est généralement de 2 Gbit/s par processeur virtuel, mais il existe quelques différences et exceptions, en fonction de la série de machines. Le tableau suivant présente la plage des limites maximales de bande passante de sortie pour le trafic acheminé au sein d'un réseau VPC pour le niveau de réseau standard uniquement, et non pour les performances de réseaux Tier_1 par VM.

Série de machines Limite de sortie maximale par instance la plus basse pour les instances standards Limite de sortie maximale par instance la plus élevée pour la norme
C4 et C4A 10 Gbit/s 100 Gbit/s
C3 23 Gbit/s 100 Gbit/s
C3D 20 Gbit/s. 100 Gbit/s
C2 et C2D 10 Gbit/s 32 Gbit/s
E2 1 Gbit/s 16 Gbit/s
H3 N/A 200 Gbit/s
M3 et M1 32 Gbit/s 32 Gbit/s
M2 32 Gbit/s 32 Gbit/s sur la plate-forme de processeur Intel Cascade Lake
16 Gbit/s sur les autres plates-formes de processeur
N4 10 Gbit/s 50 Gbit/s
N2 et N2D 10 Gbit/s 32 Gbit/s
N1 (à l'exception des VM comportant un processeur virtuel) 10 Gbit/s 32 Gbit/s sur la plate-forme de processeur Intel Skylake
16 Gbit/s sur les plates-formes de processeur antérieures à Intel Skylake
Types de machines N1 comportant un processeur virtuel, f1-micro et g1-small 2 Gbit/s 2 Gbit/s
T2D 10 Gbit/s 32 Gbit/s
X4 N/A 100 Gbit/s
Z3 23 Gbit/s 100 Gbit/s

La bande passante de sortie maximale par instance pour chaque type de machine est listée sur la page de sa famille de machines spécifique :

La bande passante de sortie maximale par instance n'est pas une garantie. La bande passante de sortie réelle peut être réduite en fonction de facteurs tels que ceux de la liste non exhaustive suivante :

  • Utiliser VirtIO au lieu de gVNIC avec des instances de calcul compatibles avec les deux
  • Taille des paquets
  • Surcharge de protocole
  • Nombre de flux
  • Paramètres du pilote Ethernet du système d'exploitation invité de l'instance de calcul, tels que le déchargement de somme de contrôle et le déchargement de la segmentation par TCP (TSO)
  • Congestion du réseau
  • Dans une situation où les E/S des disques persistents sont en concurrence avec un autre trafic de sortie réseau, 60 % de la bande passante réseau maximale est alloué aux écritures sur disques persistants, ce qui laisse 40 % pour le reste du trafic de sortie réseau. Pour en savoir plus, consultez la section Facteurs ayant une incidence sur les performances du disque.

Pour obtenir la bande passante de sortie maximale par instance la plus élevée possible, procédez comme suit :

  • Activez les performances réseau Tier_1 par VM avec des types de machines plus importants.
  • Utilisez l'unité de transmission maximale (MTU) du réseau VPC la plus compatible avec votre topologie de réseau. Les MTU plus importantes peuvent réduire la surcharge des en-têtes de paquets et augmenter le débit des données de charge utile.
  • Utilisez la dernière version du pilote gVNIC.
  • Utilisez une série de machines de troisième génération ou ultérieure qui utilise Titanium pour décharger le traitement réseau du processeur hôte.

Sortie vers des destinations routables dans un réseau VPC

Du point de vue d'une instance émettrice et pour des adresses IP de destination accessibles via des routes au sein d'un réseau VPC, Google Cloud limite le trafic sortant à l'aide des règles suivantes :

  • Bande passante de sortie maximale par VM : bande passante de sortie maximale par instance décrite dans la section Bande passante de sortie maximale par instance
  • Bande passante de sortie interrégionale par projet : si une instance émettrice et une destination interne ou son prochain saut se trouvent dans des régions différentes, Google Cloud applique une limite de bande passante de sortie interrégionale maximale. La plupart des clients ne devraient pas atteindre cette limite. Pour toute question concernant cette limite, envoyez une demande d'assistance.
  • Limites de Cloud VPN et Cloud Interconnect : lors de l'envoi de trafic depuis une instance vers une destination d'adresse IP interne routable par un tunnel Cloud VPN de prochain saut ou un rattachement de VLAN Cloud Interconnect, la bande passante de sortie est limitée par :

Les destinations routables au sein d'un réseau VPC incluent toutes les destinations suivantes, chacune étant accessible du point de vue de l'instance émettrice par une route dont le prochain saut ne correspond pas à la passerelle Internet par défaut :

  • Adresses IPv4 internes régionales dans les plages d'adresses IPv4 principales et IPv4 secondaires du sous-réseau, y compris les plages d'adresses IPv4 privées et les plages d'adresses IPv4 publiques utilisées en mode privé, utilisées par les ressources de destination suivantes :
    • L'adresse IPv4 interne principale de la carte d'interface réseau virtuelle d'une instance de réception. (Lorsqu'une instance émettrice se connecte à l'adresse IPv4 externe de carte d'interface réseau virtuelle d'une autre instance, les paquets sont acheminés à l'aide d'une passerelle Internet par défaut de prochain saut, et donc la sortie vers des destinations en dehors d'un réseau VPC s'applique à la place.)
    • Une adresse IPv4 interne dans une plage d'adresses IP d'alias de la carte d'interface réseau virtuelle d'une instance de réception.
    • Une adresse IPv4 interne d'une règle de transfert interne pour le transfert de protocole ou pour un équilibreur de charge réseau passthrough interne.
  • Adresses IPv4 internes globales pour ces ressources de destination :
  • Plages d'adresses de sous-réseau IPv6 internes utilisées par ces ressources de destination :
    • Une adresse IPv6 de la plage d'adresses IPv6 /96 attribuée à une carte d'interface réseau virtuelle de l'instance de réception à deux piles.
    • Une adresse IPv6 de la plage d'adresses IPv6 /96 d'une règle de transfert interne pour le transfert de protocole ou pour un équilibreur de charge réseau passthrough interne.
  • Plages d'adresses de sous-réseau IPv6 externes utilisées par ces ressources de destination lorsque les paquets sont acheminés à l'aide de routes de sous-réseau ou de routes de sous-réseau d'appairage au sein du réseau VPC ou par des routes personnalisées au sein du réseau Réseau VPC qui n'utilisent pas le prochain saut de la passerelle Internet par défaut :
    • Une adresse IPv6 de la plage d'adresses IPv6 /96 attribuée à une carte d'interface réseau virtuelle de l'instance de réception à deux piles.
    • Une adresse IPv6 de la plage d'adresses IPv6 /96 d'une règle de transfert externe pour le transfert de protocole ou pour un équilibreur de charge réseau passthrough externe.
  • Autres destinations accessibles à l'aide des routes de réseau VPC suivantes :

La liste suivante classe le trafic provenant d'instances émettrices vers des destinations internes, de la bande passante la plus élevée possible à la plus basse :

Sortie vers des destinations en dehors d'un réseau VPC

Du point de vue d'une instance émettrice et pour des adresses IP de destination en dehors d'un réseau VPC, Google Cloud limite le trafic sortant à l'un des taux suivants dès qu'il est atteint :

  • Bande passante de sortie par instance:la bande passante maximale pour toutes les connexions d'une instance de calcul vers des destinations extérieures à un réseau VPC est la plus petite des bandes passantes de sortie maximales par instance et l'un des taux suivants:

    • 25 Gbit/s si le réseau Tier_1 est activé
    • 7 Gbit/s si le réseau Tier_1 n'est pas activé
    • 1 Gbit/s pour les instances H3
    • 7 Gbit/s par carte d'interface réseau physique pour les séries de machines compatibles avec plusieurs cartes d'interface réseau physiques, telles que A3.

    Par exemple, même si une instance c3-standard-44 dispose d'une bande passante de sortie maximale de 32 Gbit/s par instance, la bande passante de sortie par VM d'une instance c3-standard-44 vers des destinations externes est de 25 Gbit/s ou de 7 Gbit/s, selon que le réseau Tier_1 est activé ou non.

  • Taux de sortie maximal par flux : la bande passante maximale pour chaque connexion à cinq tuples unique, depuis une instance de calcul vers une destination en dehors d'un réseau VPC est de 3 Gbit/s, sauf sur H3, où elle est de 1 Gbit/s.

  • Bande passante de sortie Internet par projet : la bande passante maximale pour toutes les connexions depuis les instances de calcul de chaque région d'un projet vers des destinations situées en dehors d'un réseau VPC est définie par les quotas de bande passante de sortie Internet du projet.

Les destinations situées en dehors d'un réseau VPC incluent toutes les destinations suivantes, chacune étant accessible par une route du réseau VPC de l'instance émettrice dont le prochain saut correspond à la passerelle Internet par défaut :

  • Adresses IPv4 et IPv6 externes globales pour les équilibreurs de charge réseau de proxy externes et les équilibreurs de charge d'application externes
  • Adresses IPv4 externes régionales pour les ressources Google Cloud, y compris les adresses IPv4 externes de carte d'interface réseau virtuelle de VM, les adresses IPv4 externes pour le transfert de protocole externe, les équilibreurs de charge réseau passthrough externes et les paquets de réponses aux passerelles Cloud NAT.
  • Adresses IPv6 externes régionales dans les sous-réseaux à double pile avec des plages d'adresses IPv6 externes utilisées par les adresses IPv6 externes des instances à double pile, le transfert de protocole externe et les équilibreurs de charge réseau passthrough externes. Le sous-réseau doit se trouver dans un réseau VPC distinct et non appairé. La plage d'adresses IPv6 de destination doit être accessible à l'aide d'un routage dans le réseau VPC de l'instance émettrice dont le saut suivant correspond à la passerelle Internet par défaut. Si un sous-réseau à deux piles avec une plage d'adresses IPv6 externe se trouve dans le même réseau VPC ou dans un réseau VPC appairé, consultez la section Sortie vers des destinations routables au sein d'un réseau VPC.
  • Autres destinations externes accessibles à l'aide d'une route statique dans le réseau VPC de l'instance émettrice à condition que le prochain saut pour la route est la passerelle Internet par défaut.

Pour savoir quelles ressources Google Cloud utilisent quels types d'adresses IP externes, consultez la section Adresses IP externes.

Bande passante d'entrée

Google Cloud gère la bande passante entrante (entrée) en fonction de la manière dont le paquet entrant est acheminé vers une instance de calcul de réception.

Entrée vers des destinations routables dans un réseau VPC

Une instance de réception peut gérer autant de paquets entrants que le permettent son type de machine, son système d'exploitation et d'autres conditions réseau. Google Cloud n'applique aucune restriction de bande passante intentionnelle sur les paquets entrants transmis à une instance si le paquet entrant est acheminé à l'aide de routes au sein d'un réseau VPC :

  • Routes de sous-réseau dans le réseau VPC de l'instance de réception
  • Routes de sous-réseau d'appairage dans un réseau VPC appairé
  • Routes d'un autre réseau dont les prochains sauts correspondent à des tunnels Cloud VPN, des rattachements Cloud Interconnect (VLAN) ou des instances d'appareil de routeur situées dans le réseau VPC de l'instance de réception

Les destinations des paquets acheminés au sein d'un réseau VPC incluent :

  • Adresse IPv4 interne principale de la carte d'interface réseau de l'instance de réception. Les adresses IPv4 internes principales sont des adresses IPv4 internes régionales provenant de la plage d'adresses IPv4 principales d'un sous-réseau.
  • Une adresse IPv4 interne d'une plage d'adresses IP d'alias de la carte d'interface réseau de l'instance de réception. Les plages d'adresses IP d'alias peuvent provenir de la plage d'adresses IPv4 principales d'un sous-réseau ou de l'une de ses plages d'adresses IPv4 secondaires.
  • Une adresse IPv6 de la plage d'adresses IPv6 /96 attribuée à une carte d'interface réseau de l'instance de réception à deux piles. Les plages IPv6 d'instance de calcul peuvent provenir des plages IPv6 de sous-réseau suivantes :
  • Une adresse IPv4 interne d'une règle de transfert utilisée par le transfert de protocole interne vers l'instance de réception ou l'équilibreur de charge réseau passthrough interne, où l'instance de réception est un backend de l'équilibreur de charge. Les adresses IPv4 de règle de transfert internes proviennent de la plage d'adresses IPv4 principales d'un sous-réseau.
  • Une adresse IPv6 interne de la plage IPv6 /96 d'une règle de transfert utilisée par le transfert de protocole interne vers l'instance de réception ou l'équilibreur de charge réseau passthrough interne, où l'instance de réception est un backend de l'équilibreur de charge. Les adresses IPv6 de règle de transfert internes proviennent de la plage d'adresses IPv6 internes d'un sous-réseau.
  • Une adresse IPv6 externe de la plage IPv6 /96 d'une règle de transfert utilisée par le transfert de protocole externe vers l'instance de réception ou l'équilibreur de charge réseau passthrough externe. L'instance de réception est un backend de l'équilibreur de charge lorsque le paquet entrant est acheminé au sein du réseau VPC à l'aide de l'un des routages répertoriés précédemment dans cette section. Les adresses IPv6 de règle de transfert externes proviennent de la plage d'adresses IPv6 externes d'un sous-réseau.
  • Une adresse IP dans la plage de destination d'une route statique personnalisée utilisant l'instance de réception comme instance de prochain saut (next-hop-instance ou next-hop-address).
  • Une adresse IP dans la plage de destination d'une route statique personnalisée utilisant un équilibreur de charge réseau passthrough interne (next-hop-ilb) comme prochain saut, si l'instance de réception est un backend pour cet équilibreur de charge.

Entrée vers des destinations en dehors d'un réseau VPC

Google Cloud met en œuvre les restrictions de bande passante suivantes pour les paquets entrants distribués à une instance de réception à l'aide de routes en dehors d'un réseau VPC. En cas d'équilibrage de charge, les restrictions de bande passante sont appliquées individuellement à chaque instance de réception.

Pour les séries de machines qui ne sont pas compatibles avec plusieurs cartes d'interface réseau physiques, la restriction de bande passante entrante applicable concerne collectivement l'ensemble des interfaces réseau virtuelles (vNIC). La limite fixée par la restriction correspond au premier débit atteint parmi les deux suivants :

  • 1 800 000 paquets par seconde
  • 30 Gbit/s

Pour les séries de machines compatibles avec plusieurs cartes d'interface réseau physiques, telles que la série A3, la restriction de bande passante entrante applicable concerne individuellement chaque carte d'interface réseau physique. La limite fixée par la restriction correspond au premier débit atteint parmi les deux suivants :

  • 1 800 000 paquets par seconde et par carte d'interface réseau physique
  • 30 Gbit/s par carte d'interface réseau physique

Les destinations des paquets acheminés à l'aide de routes en dehors d'un réseau VPC incluent :

  • Une adresse IPv4 externe attribuée dans une configuration d'accès NAT de type un à un sur l'une des cartes d'interface réseau des instances de réception.
  • Une adresse IPv6 externe de la plage d'adresses IPv6 /96 attribuée à une carte d'interface réseau virtuelle d'une instance de réception à deux piles lorsque le paquet entrant est acheminé à l'aide d'une route externe au réseau VPC de l'instance de réception.
  • Une adresse IPv4 externe d'une règle de transfert utilisée par le transfert de protocole externe vers l'instance de réception ou l'équilibreur de charge réseau passthrough externe, où l'instance de réception est un backend de l'équilibreur de charge.
  • Une adresse IPv6 externe de la plage IPv6 /96 d'une règle de transfert utilisée par le transfert de protocole externe vers l'instance de réception ou l'équilibreur de charge réseau passthrough externe, où l'instance de réception est un backend de l'équilibreur de charge lorsque le paquet entrant est acheminé à l'aide d'une route en dehors d'un réseau VPC.
  • Des réponses entrantes établies traitées par Cloud NAT.

Trames géantes

Pour recevoir et envoyer des trames géantes, configurez le réseau VPC utilisé par vos instances de calcul en définissant l'unité de transmission maximale (MTU) sur une valeur plus élevée, jusqu'à 8 896.

Des valeurs de MTU plus élevées augmentent la taille des paquets et réduisent la surcharge de l'en-tête du paquet, ce qui augmente le débit des données de charge utile.

Vous pouvez utiliser des trames géantes avec la version 1.3 ou ultérieure du pilote gVNIC sur les instances de VM ou avec le pilote IDPF sur les instances bare metal. Les images publiques Google Cloud n'incluent pas toutes ces pilotes. Pour en savoir plus sur la compatibilité des systèmes d'exploitation avec les trames géantes, consultez l'onglet Fonctionnalités de mise en réseau de la page Détails des systèmes d'exploitation.

Si vous utilisez une image d'OS qui n'est pas entièrement compatible avec les trames géantes, vous pouvez installer manuellement la version 1.3.0 ou ultérieure du pilote gVNIC. Google recommande d'installer la version du pilote gVNIC marquée comme Latest pour bénéficier de fonctionnalités et de corrections de bugs supplémentaires. Vous pouvez télécharger les pilotes gVNIC sur GitHub.

Pour mettre à jour manuellement la version du pilote gVNIC dans votre système d'exploitation invité, consultez la section Utilisation sur des systèmes d'exploitation non compatibles.

Files d'attente de réception et de transmission

Chaque carte d'interface réseau ou vNIC d'une instance de calcul se voit attribuer un nombre de files d'attente de réception et de transmission pour le traitement des paquets à partir du réseau.

  • File d'attente de réception (RX) : file d'attente pour recevoir les paquets. Lorsque la carte d'interface réseau reçoit un paquet du réseau, elle sélectionne le descripteur d'un paquet entrant dans la file d'attente, le traite et le transmet au système d'exploitation invité par le biais d'une file d'attente de paquets associée à un cœur de processeur virtuel à l'aide d'une interruption. Si la file d'attente RX est pleine et qu'aucun tampon n'est disponible pour placer un paquet, le paquet est supprimé. Cela peut généralement se produire si une application surutilise un cœur de processeur virtuel également associé à la file d'attente de paquets sélectionnée.
  • File d'attente de transmission (TX) : file d'attente pour transmettre des paquets. Lorsque le système d'exploitation invité envoie un paquet, un descripteur est alloué et placé dans la file d'attente TX. La carte d'interface réseau traite ensuite le descripteur et transmet le paquet.

Allocation de file d'attente par défaut

Sauf si vous attribuez explicitement un nombre de files d'attente aux cartes d'interface réseau, vous pouvez modéliser l'algorithme utilisé par Google Cloud pour attribuer un nombre fixe de files d'attente RX et TX par carte d'interface réseau de la manière suivante :

Instances Bare Metal
Pour les instances Bare Metal, il n'y a qu'une seule carte d'interface réseau. Le nombre maximal de files d'attente est donc de 16.
Instances de VM qui utilisent l'interface réseau gVNIC

Pour les instances C4, afin d'améliorer les performances, les configurations suivantes utilisent un nombre fixe de files d'attente:

  • Pour les instances Linux avec deux vCPU, le nombre de files d'attente est de 1.
  • Pour les instances Linux avec quatre vCPU, le nombre de files d'attente est de 2.

Pour les autres séries de machines, le nombre de files d'attente dépend de l'utilisation ou non de Titanium.

  • Pour les instances de troisième génération (à l'exception de M3) et ultérieures qui utilisent Titanium:

    Divisez le nombre de vCPU par le nombre de vNIC (num_vcpus/num_vnics) et supprimez le reste.

  • Pour les VM de première et deuxième génération qui n'utilisent pas Titanium:

    Divisez le nombre de vCPU par le nombre de vNIC, puis divisez le résultat par 2 (num_vcpus/num_vnics/2). Supprimez le reste.

Pour terminer le calcul du nombre de requêtes dans la file d'attente par défaut:

  1. Si le nombre calculé est inférieur à 1, attribuez plutôt une file d'attente à chaque carte d'interface réseau virtuelle.

  2. Déterminez si le nombre calculé est supérieur au nombre maximal de files d'attente par vNIC, qui est 16. Si le nombre calculé est supérieur à 16, ignorez le nombre calculé et attribuez 16 files d'attente à chaque carte d'interface réseau virtuelle.

Instances de VM utilisant l'interface réseau VirtIO ou un pilote personnalisé

Divisez le nombre de vCPU par le nombre de vNIC, puis supprimez le reste : [number of vCPUs/number of vNICs].

  1. Si le nombre calculé est inférieur à 1, attribuez plutôt une file d'attente à chaque carte d'interface réseau virtuelle.

  2. Déterminez si le nombre calculé est supérieur au nombre maximal de files d'attente par vNIC, qui est 32. Si le nombre calculé est supérieur à 32, ignorez le nombre calculé et attribuez 32 files d'attente à chaque carte d'interface réseau virtuelle.

Examples

Les exemples suivants montrent comment calculer le nombre de files d'attente par défaut pour une instance de VM:

  • Si une instance de VM utilise VirtIO et comporte 16 vCPU et 4 cartes d'interface réseau virtuelles, le nombre calculé est [16/4] = 4. Google Cloud attribue quatre files d'attente à chaque carte d'interface réseau virtuelle.

  • Si une instance de VM utilise gVNIC et comporte 128 vCPU et deux vNIC, le nombre calculé est [128/2/2] = 32. Google Cloud attribue à chaque carte d'interface réseau virtuelle le nombre maximal de files d'attente possible par carte. Google Cloud attribue 16 files d'attente par carte d'interface réseau virtuelle.

Sur les systèmes Linux, vous pouvez utiliser ethtool pour configurer une carte d'interface réseau virtuelle avec moins de files d'attente que le nombre de files d'attente par carte d'interface réseau virtuelle attribué par Google Cloud.

Allocation de file d'attente personnalisée pour les instances de VM

Au lieu de l'allocation de file d'attente par défaut, vous pouvez attribuer un nombre personnalisé de files d'attente (à la fois RX et TX) à chaque carte d'interface réseau virtuelle lorsque vous créez une isntance de calcul à l'aide de l'API Compute Engine.

Le nombre de files d'attente personnalisées que vous spécifiez doit respecter les règles suivantes :

  • Le nombre minimal de files d'attente que vous pouvez attribuer par carte d'interface réseau virtuelle est de 1.

  • Le nombre maximal de files d'attente que vous pouvez attribuer à chaque vNIC d'une instance de VM est le nombre inférieur du nombre de vCPU ou du nombre maximal de files d'attente par carte d'interface réseau virtuelle, en fonction du type de pilote:

    • Avec virtIO ou un pilote personnalisé, le nombre maximal de files d'attente est de 32.
    • Avec gVNIC, le nombre maximal de files d'attente est de 16, sauf dans les cas suivants, où le nombre maximal de files d'attente est de 32 :
      • Instances A2 ou G2
      • Instances TPU
      • Instances C2, C2D, N2 ou N2D avec la mise en réseau Tier_1 activée

    • Pour les configurations de VM confidentielles suivantes, le nombre maximal de files d'attente est 8:

      • AMD SEV sur les types de machines C2D et N2D
      • AMD SEV-SNP sur les types de machines N2D

  • Si vous attribuez des nombres de files d'attente personnalisés à toutes les cartes d'interface réseau de l'instance de calcul, la somme de vos attributions de files d'attente doit être inférieure ou égale au nombre de processeurs virtuels attribués à l'instance.

Vous pouvez sursouscrire le nombre de files d'attente personnalisées pour vos cartes d'interface réseau. En d'autres termes, vous pouvez attribuer la somme des files d'attente attribuées à toutes les cartes d'interface réseau de votre instance de VM au-delà du nombre de vCPU de votre instance. Pour surabonner le nombre de files d'attente personnalisées, l'instance de VM doit remplir les conditions suivantes:

  • Utilise gVNIC comme type de carte d'interface réseau virtuelle pour toutes les cartes d'interface réseau configurées pour l'instance.
  • Utilise un type de machine compatible avec la mise en réseau Tier_1.
  • La mise en réseau Tier_1 est activée.
  • Vous avez spécifié un nombre de files d'attente personnalisé pour toutes les cartes d'interface réseau configurées pour l'instance.

Avec la sursouscription, le nombre maximal de files d'attente pour l'instance de VM est de 16 fois le nombre de cartes d'interface réseau. Ainsi, si vous avez six cartes d'interface réseau configurées pour une instance comportant 30 vCPU, vous pouvez configurer jusqu'à (16 * 6) ou 96 files d'attente personnalisées pour votre instance.

Exemples

  • Si une instance de VM comporte 8 vCPU et 3 vNIC, le nombre maximal de files d'attente pour l'instance correspond au nombre de vCPU, soit 8. Vous pouvez attribuer 1 file d'attente à nic0, 4 files d'attente à nic1 et 3 files d'attente à nic2. Dans cet exemple, vous ne pouvez pas attribuer ensuite quatre files d'attente à nic2 tout en conservant les deux autres files d'attente de vNIC, car la somme des files d'attente attribuées ne peut pas dépasser le nombre de vCPU.

  • Si vous disposez d'une VM N2 avec 96 vCPU et deux vNIC, vous pouvez attribuer jusqu'à 32 files d'attente à chaque vNIC lorsque vous utilisez le pilote virtIO, ou jusqu'à 16 files d'attente lorsque vous utilisez le pilote gVNIC. Si vous activez la mise en réseau Tier_1 pour la VM N2, vous pouvez attribuer jusqu'à 32 files d'attente à chaque vNIC. Dans cet exemple, la somme des files d'attente attribuées est toujours inférieure ou égale au nombre de processeurs virtuels.

Il est également possible d'attribuer un nombre de files d'attente personnalisé à certaines cartes d'interface réseau uniquement, ce qui permet à Google Cloud d'attribuer des files d'attente aux cartes d'interface réseau restantes. Le nombre de files d'attente que vous pouvez attribuer par carte d'interface réseau est toujours soumis aux règles mentionnées précédemment. Vous pouvez modéliser la faisabilité de votre configuration et, si votre configuration est possible, le nombre de files d'attente attribuées par Google Cloud aux vNIC restantes avec ce processus:

  1. Calculez la somme des files d'attente pour les vNIC à l'aide de l'attribution de files d'attente personnalisée. Pour un exemple de VM avec 20 processeurs virtuels et 6 vNIC, supposons que vous souhaitez attribuer 5 files d'attente à nic0, 6 files d'attente à nic1, 4 files d'attente à nic2, puis laisser Google Cloud attribuer les files d'attente pour nic3, nic4 et nic5. Dans cet exemple, la somme des files d'attente attribuées de manière personnalisée est 5+6+4 = 15.

  2. Soustrayez la somme des files d'attente personnalisées aux nombres de processeurs virtuels. Si la différence est inférieure au nombre de vNIC restantes auxquelles Google Cloud doit attribuer des files d'attente, Google Cloud renvoie une erreur, car chaque vNIC doit avoir au moins une file d'attente.

    Poursuivant l'exemple avec une VM dotée de 20 vCPU et d'une somme de 15 files d'attente personnalisées, Google Cloud dispose de 20-15 = 5 files d'attente restantes à attribuer aux vNIC restantes (nic3, nic4, nic5).

  3. Divisez la différence de l'étape précédente par le nombre de vNIC restantes et supprimez le reste : ⌊(number of vCPUs - sum of assigned queues)/(number of remaining vNICs)⌋. Ce calcul donne toujours un nombre entier (et non une fraction) au moins égal à un en raison de la contrainte expliquée à l'étape précédente. Google Cloud attribue à chaque carte d'interface réseau virtuelle restante un nombre de files d'attente correspondant au nombre calculé, à condition que le nombre calculé ne dépasse pas le nombre maximal de files d'attente par carte d'interface réseau virtuelle. Le nombre maximal de files d'attente par carte d'interface réseau virtuelle dépend du type de pilote :

  • En utilisant virtIO ou un pilote personnalisé, si le nombre de files d'attente calculé pour chaque carte d'interface réseau virtuelle restante est supérieur à 32, Google Cloud attribue 32 files d'attente à chaque carte d'interface réseau virtuelle restante.
  • En utilisant gVNIC, si le nombre de files d'attente calculé pour chaque carte d'interface réseau virtuelle restante est supérieur à la limite de 16 ou 32 (selon la configuration de la VM), Google Cloud attribue 16 files d'attente à chaque carte d'interface réseau virtuelle restante.

Configurer le nombre de files d'attente personnalisées

Pour créer une instance de calcul qui utilise un nombre de files d'attente personnalisé pour une ou plusieurs cartes d'interface réseau ou cartes d'interface réseau virtuelles, procédez comme suit :

Dans les exemples de code suivants, la VM est créée avec le type d'interface réseau défini sur GVNIC et les performances réseau Tier_1 par VM activées. Vous pouvez utiliser ces exemples de code pour spécifier le nombre maximal de files d'attente et la sursouscription de files d'attente disponibles pour les types de machines compatibles.

gcloud

  1. Si vous ne disposez pas encore d'un réseau VPC avec un sous-réseau pour chaque interface vNIC que vous prévoyez de configurer, créez-les.
  2. Utilisez la commande gcloud compute instances create pour créer l'instance Compute Engine. Répétez l'option --network-interface pour chaque carte d'interface réseau virtuelle que vous souhaitez configurer pour l'instance et incluez l'option queue-count.
    gcloud compute instances create INSTANCE_NAME \
        --zone=ZONE \
        --machine-type=MACHINE_TYPE \
        --network-performance-configs=total-egress-bandwidth-tier=TIER_1  \
        --network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1 \
        --network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2

Remplacez les éléments suivants :

  • INSTANCE_NAME: nom de la nouvelle instance de calcul
  • ZONE: zone dans laquelle créer l'instance.
  • MACHINE_TYPE : le type de machine de l'instance. Pour souscrire un nombre de files d'attente supérieur, le type de machine que vous spécifiez doit être compatible avec les réseaux gVNIC et Tier_1.
  • NETWORK_NAME : nom du réseau créé précédemment
  • SUBNET_* : nom de l'un des sous-réseaux créés précédemment
  • QUEUE_SIZE : nombre de files d'attente pour la carte d'interface réseau virtuelle, sous réserve des règles décrites dans la section Allocation de file d'attente personnalisée.

Terraform

  1. Si vous ne disposez pas encore d'un réseau VPC avec un sous-réseau pour chaque interface vNIC que vous prévoyez de configurer, créez-les.

  2. Créez une instance de calcul avec un nombre de files d'attente spécifique pour les vNIC à l'aide de la ressource google_compute_instance. Répétez le paramètre --network-interface pour chaque vNIC que vous souhaitez configurer pour l'instance de calcul et incluez le paramètre queue-count.

    # Queue oversubscription instance
resource "google_compute_instance" "VM_NAME" {
project      = "PROJECT_ID"
boot_disk {
  auto_delete = true
  device_name = "DEVICE_NAME"
  initialize_params {
     image="IMAGE_NAME"
     size = DISK_SIZE
     type = "DISK_TYPE"
  }
}
machine_type = "MACHINE_TYPE"
name         = "VM_NAME"
zone = "ZONE"

network_performance_config {
    total_egress_bandwidth_tier = "TIER_1"
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_1
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_1"
 }

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_2
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_2"
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_3
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_3""
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_4
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_4""
}

}

Remplacez les éléments suivants :

  • VM_NAME: nom de la nouvelle instance de calcul
  • PROJECT_ID: ID du projet dans lequel créer l'instance. À moins que vous n'utilisiez un réseau VPC partagé, le projet que vous spécifiez doit être le même que celui dans lequel tous les sous-réseaux et réseaux ont été créés.
  • DEVICE_NAME : nom à associer au disque de démarrage dans le système d'exploitation invité
  • IMAGE_NAME : nom d'une image, par exemple, "projects/debian-cloud/global/images/debian-11-bullseye-v20231010".
  • DISK_SIZE : taille du disque de démarrage, en Gio
  • DISK_TYPE : type de disque à utiliser pour le disque de démarrage, par exemple pd-standard
  • MACHINE_TYPE : le type de machine de l'instance. Pour souscrire un nombre de files d'attente supérieur, le type de machine que vous spécifiez doit être compatible avec les réseaux gVNIC et Tier_1.
  • ZONE est la zone dans laquelle créer l'instance.
  • QUEUE_COUNT : nombre de files d'attente pour la carte d'interface réseau virtuelle, sous réserve des règles décrites dans la section Allocation de file d'attente personnalisée.
  • SUBNET_* : nom du sous-réseau auquel l'interface réseau se connecte

REST

  1. Si vous ne disposez pas encore d'un réseau VPC avec un sous-réseau pour chaque interface vNIC que vous prévoyez de configurer, créez-les.

  2. Créez une instance de calcul avec un nombre de files d'attente spécifique pour les cartes d'interface réseau à l'aide de la méthode instances.insert. Répétez la propriété networkInterfaces pour configurer plusieurs interfaces réseau.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
{
"name": "VM_NAME",
"machineType": "machineTypes/MACHINE_TYPE",
"networkPerformanceConfig": {
    "totalEgressBandwidthTier": TIER_1
},
"networkInterfaces": [
    {
      "nicType": gVNIC,
      "subnetwork":"regions/region/subnetworks/SUBNET_1",
      "queueCount": "QUEUE_COUNT_1"
    } ],
"networkInterfaces": [
    {
      "nicType": gVNIC,
      "subnetwork":"regions/region/subnetworks/SUBNET_2",
      "queueCount": "QUEUE_COUNT_2"
    } ],
}

    Remplacez les éléments suivants :

    • PROJECT_ID: ID du projet dans lequel créer l'instance de calcul
    • ZONE: zone dans laquelle créer l'instance de calcul
    • VM_NAME : nom de la nouvelle instance de calcul
    • MACHINE_TYPE: type de machine prédéfini ou personnalisé pour la nouvelle instance de calcul. Pour sursouscrire le nombre de files d'attente, le type de machine doit être compatible avec les réseaux gVNIC et Tier_1.
    • SUBNET_* : nom du sous-réseau auquel l'interface réseau se connecte
    • QUEUE_COUNT : nombre de files d'attente pour la carte d'interface réseau virtuelle, sous réserve des règles décrites dans la section Allocation de file d'attente personnalisée.

Allocations de file d'attente et modification du type de machine

Les instances de calcul sont créées avec une allocation de file d'attente par défaut, ou vous pouvez attribuer un nombre de files d'attente personnalisé à chaque carte d'interface réseau virtuelle (vNIC) lorsque vous créez une instance de calcul à l'aide de l'API Compute Engine. Les attributions de file d'attente de vNIC par défaut ou personnalisées ne sont définies que lors de la création d'une instance de calcul. Si votre instance comporte des vNIC qui utilisent le nombre de files d'attente par défaut, vous pouvez modifier son type de machine. Si le type de machine que vous définissez comporte un nombre différent de vCPU, le nombre de files d'attente par défaut pour votre instance est recalculé en fonction du nouveau type de machine.

Si votre VM dispose de vNIC qui utilisent un nombre de files d'attente personnalisé autre que celui par défaut, vous pouvez modifier le type de machine en utilisant Google Cloud CLI ou l'API Compute Engine, afin de mettre à jour les propriétés de l'instance. La conversion réussit si la VM obtenue est compatible avec le même nombre de files d'attente par vNIC que l'instance d'origine. Pour les VM qui utilisent l'interface VirtIO-Net et dont le nombre de files d'attente personnalisé est supérieur à 16 par vNIC, vous ne pouvez pas remplacer le type de machine par un type de machine de troisième génération ou ultérieure, car elles n'utilisent que gVNIC. Vous pouvez par contre migrer votre VM vers un type de machine de troisième génération ou ultérieure en suivant les instructions de la page Déplacer votre charge de travail vers une nouvelle instance de calcul.

Étape suivante