Bande passante réseau

Google Cloud tient compte de la bande passante par instance de machine virtuelle (VM), 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 possible. Cependant, vous ne pouvez atteindre ce débit de sortie maximal 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 VM Google Cloud :
    • Les paquets envoyés depuis une VM Google Cloud composent son trafic de sortie (trafic sortant).
    • Les paquets envoyés vers une VM Google Cloud composent son trafic d'entrée (trafic entrant).
  • Mode de routage du paquet : un paquet peut être acheminé à partir d'une VM é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 VM. 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 VM Compute Engine, ainsi qu'aux produits qui dépendent des VM Compute Engine. Par exemple, un nœud Google Kubernetes Engine est une VM 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 VM ou reçu par (entrée) une VM 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 VM en fonction du type de machine de la VM émettrice et si le réseau Tier_1 est activé.

    • Les VM N2, N2D, C2 et C2D 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 VM A2 et G2 acceptent des limites de bande passante de sortie allant jusqu'à 100 Gbit/s.
    • Les VM A3 acceptent des limites de bande passante de sortie allant jusqu'à 1 000 Gbit/s.
    • Les VM C3, C3D et Z3 (preview) acceptent jusqu'à 200 Gbit/s de bande passante de sortie avec le 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 VM en fonction du type de machine de la VM émettrice et selon que le réseau Tier_1 est activé ou non. À l'exception des VM H3, la sortie maximale possible d'une VM é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 VM, 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 VM 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 VM en limitant le trafic entrant acheminé en dehors d'un réseau VPC. La limite est le premier des débits courants suivants :

    • 1 800 000 paquets par seconde (pps)
    • 30 Gbit/s
  • Pour les séries de machines compatibles avec plusieurs cartes d'interface réseau physiques, telles que 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) en utilisant des taux de sortie maximaux par VM en fonction du type de machine de la VM 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 la VM, ainsi que les données transférées vers tous les disques persistants connectés à la VM.

Bande passante de sortie maximale par VM

La bande passante de sortie maximale 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 VM la plus basse sans réseau Tier_1 Limite de sortie maximale par VM la plus élevée sans réseau Tier_1
E2 1 Gbit/s 16 Gbit/s
C3 23 Gbit/s 100 Gbit/s
C3D 20 Gbit/s. 100 Gbit/s
T2D 10 Gbit/s 32 Gbit/s
N2, C2, N2D et C2D 10 Gbit/s 32 Gbit/s
H3 Non disponible 200 Gbit/s
Z3 (preview) 23 Gbit/s 100 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
A3, A2 et G2 N/A En fonction du type de GPU

La bande passante de sortie maximale par VM 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 VM 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 :

  • Un pilote Ethernet au niveau de l'invité (gVNIC) offre de meilleures performances que l'interface réseau VirtIO
  • Taille des paquets
  • Surcharge de protocole
  • Nombre de flux
  • Paramètres du pilote Ethernet du système d'exploitation invité de la VM, 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 disques persistants 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 dans la documentation sur les disques persistants.

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

  • Activez les performances de réseau Tier_1 par VM avec des types de machines à usage général et optimisés pour le calcul.
  • 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.

Sortie vers des destinations routables dans un réseau VPC

Du point de vue d'une VM é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 VM décrite dans la section Bande passante de sortie maximale par VM
  • Bande passante de sortie interrégionale par projet : si une VM é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 sont peu susceptibles d'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 VM 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 la VM é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 VM de réception. (Lorsqu'une VM émettrice se connecte à l'adresse IPv4 externe de carte d'interface réseau virtuelle d'une autre VM, 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 VM 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 la VM 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 la VM 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 de VM émettrice 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 VM é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 VM : la bande passante maximale pour toutes les connexions d'une VM vers des destinations extérieures à un réseau VPC est la plus petite des bandes passantes de sortie maximales par VM 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 VM 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 n2-standard-16 dispose d'une bande passante de sortie maximale de 32 Gbit/s par VM, la bande passante de sortie par VM d'une instance n2-standard-16 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 VM 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 VM 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 la VM é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 à duex piles avecplages d'adresses IPv6 externes utilisées par les adresses IPv6 externes de VM à deux piles, transfert de protocole externe et équilibreurs de charge réseau passthrough externes, à condition que le sous-réseau soit situé dans un réseau VPC distinct non appairé et que la plage d'adresses IPv6 de destination soit accessible via une route du réseau VPC de la VM émettrice dont le prochain saut est 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 la VM é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 VM de réception.

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

Une VM 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 VM 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 la VM 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 VM d'appliance de routeur situées dans le réseau VPC de la VM 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 virtuelle de la VM 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 virtuelle de la VM 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 virtuelle de la VM de réception à deux piles. Les plages IPv6 de VM 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 la VM de réception ou l'équilibreur de charge réseau passthrough interne, où la VM 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 la VM de réception ou l'équilibreur de charge réseau passthrough interne, où la VM 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 la VM de réception ou l'équilibreur de charge réseau passthrough externe, où la VM 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'une des routes répertoriées 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 la VM de réception comme VM 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 la VM 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 VM 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 VM 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 cartes d'interface réseau virtuelles. 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 VM 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 VM de réception à deux piles lorsque le paquet entrant est acheminé à l'aide d'une route externe au réseau VPC de la VM de réception.
  • Une adresse IPv4 externe d'une règle de transfert utilisée par le transfert de protocole externe vers la VM de réception ou l'équilibreur de charge réseau passthrough externe, où la VM 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 la VM de réception ou l'équilibreur de charge réseau passthrough externe, où la VM 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 VM 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.

Pour utiliser des trames géantes avec le pilote gVNIC, vous devez utiliser la version 1.3 ou ultérieure. Les images publiques Google Cloud n'incluent pas toutes cette version de pilote. 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. Les versions d'image indiquant la compatibilité complète des trames géantes incluent le pilote gVNIC mis à jour, même si le système d'exploitation invité affiche la version du pilote gve comme étant 1.0.0.

Si vous utilisez une image d'OS qui n'est pas entièrement compatible avec les trames géantes, vous pouvez installer manuellement le pilote gVNIC version 1.3.0 ou ultérieure. 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 virtuelle de VM 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 virtuelle 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 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 virtuelle 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 virtuelle de la manière suivante :

  1. Utilisez l'une des méthodes suivantes, en fonction du type d'interface réseau :

    • VirtIO : divisez le nombre de vCPU par le nombre de cartes d'interface réseau et supprimez le reste : [number of vCPUs/number of NICs].
    • gVNIC : divisez le nombre de vCPU par le nombre de cartes d'interface réseau, puis divisez le résultat par 2 et supprimez le reste : [number of vCPUs/number of NICs/2].

    Ce calcul donne toujours un nombre entier (et non une fraction).

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

  3. Déterminez si le nombre calculé est supérieur au 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 :

    • Avec virtIO ou un pilote personnalisé, le nombre maximal de files d'attente par carte d'interface réseau virtuelle est de 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.
    • Avec gvNIC, le nombre maximal de files d'attente par carte d'interface réseau virtuelle est de 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.

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

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

  • Si une VM utilisant gVNIC dispose de 128 vCPU et de deux cartes d'interface réseau, 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

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 VM à 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 carte d'interface réseau virtuelle 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.

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

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 VM au-delà du nombre de processeurs virtuels de votre VM. Pour surabonner le nombre de files d'attente personnalisées, vous devez remplir les conditions suivantes :

  • Vous utilisez gVNIC comme type de carte d'interface réseau virtuelle pour toutes les cartes d'interface réseau configurées pour la VM.
  • Votre VM utilise un type de machine des séries de machines N2, N2D, C2 et C2D.
  • Vous avez activé la mise en réseau Tier_1 pour la VM.
  • Vous avez spécifié un nombre de files d'attente personnalisé pour toutes les cartes d'interface réseau configurées pour la VM.

Avec la sursouscription, le nombre maximal de files d'attente pour la 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 VM comportant 30 processeurs virtuels, vous pouvez configurer jusqu'à 96 files d'attente (6) ou 96 files d'attente personnalisées pour votre VM.

Exemples

  • Si une VM comporte 8 processeurs virtuels et 3 cartes d'interface réseau, le nombre maximal de files d'attente pour la VM correspond au nombre de processeurs virtuels, 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 processeurs virtuels (huit).

  • Si une VM comporte 96 vCPU et deux cartes d'interface réseau, vous pouvez attribuer jusqu'à 32 files d'attente à chaque carte d'interface réseau lorsque vous utilisez le pilote virtIO, ou jusqu'à 16 files d'attente lorsque vous utilisez le pilote gVNIC. Dans cet exemple, la somme des files d'attente attribuées est toujours inférieure 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 cartes d'interface réseau restantes avec ce processus :

  1. Calculez la somme des files d'attente pour les cartes d'interface réseau à l'aide de l'attribution de files d'attente personnalisée. Pour un exemple de VM avec 20 processeurs virtuels et 6 cartes d'interface réseau, 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 n'est pas au moins égale au nombre de cartes d'interface réseau restantes auxquelles Google Cloud doit attribuer des files d'attente, Google Cloud renvoie une erreur. En reprenant l'exemple de VM de 20 processeurs virtuels et une somme de 15 files d'attente personnalisées, Google Cloud dispose de 20-15 = 5 files d'attente restantes à attribuer aux cartes d'interface réseau restantes (nic3, nic4, nic5).

  3. Divisez la différence de l'étape précédente par le nombre de cartes d'interface réseau restantes et supprimez le reste : ⌊(number of vCPUs - sum of assigned queues)/(number of remaining NICs)⌋. 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 réseau 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 à 16, 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 VM qui utilise un nombre de files d'attente personnalisé pour une ou plusieurs cartes d'interface réseau virtuelles, procédez comme suit :

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. Exécutez la commande gcloud compute instances create pour créer la VM. Répétez l'option --network-interface pour chaque carte d'interface réseau virtuelle que vous souhaitez configurer pour la VM et incluez l'option queue-count.
    gcloud compute instances create VM_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 :

  • VM_NAME : nom de la nouvelle VM
  • ZONE : zone dans laquelle créer la VM
  • MACHINE_TYPE : type de machine de la VM. 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 VM avec un nombre de files d'attente spécifique pour les cartes d'interface réseau à l'aide de la ressource google_compute_instance. Répétez le paramètre --network-interface pour chaque carte d'interface réseau virtuelle que vous souhaitez configurer pour la VM 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 VM
  • PROJECT_ID : ID du projet dans lequel créer la VM. À 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 : type de machine de la VM. Le type de machine que vous spécifiez doit être compatible avec les réseaux gVNIC et Tier_1.
  • ZONE : zone dans laquelle créer la VM
  • 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 VM 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 la VM
    • ZONE : zone dans laquelle créer la VM
    • VM_NAME : nom de la nouvelle VM.
    • MACHINE_TYPE : type de machine prédéfini ou personnalisé pour la nouvelle VM
    • 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 VM 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 VM à l'aide de l'API Compute Engine. Les allocations de file d'attente de vNIC par défaut ou personnalisées ne sont définies que lors de la création d'une VM. Si votre VM 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 VM 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 la VM d'origine. Pour les VM qui utilisent l'interface VirtIO-Net et dont le nombre de files d'attente personnalisé est supérieur à 16 files par vNIC, vous ne pouvez pas remplacer le type de machine par un type de machine de troisième génération, car celui-ci n'utilise que gVNIC. Vous pouvez par contre migrer votre VM vers un type de machine de troisième génération en suivant les instructions de la page Migrer une charge de travail d'une VM existante vers une nouvelle VM.

Étapes suivantes