Netzwerkbandbreite

Google Cloud berücksichtigt die Bandbreite pro VM-Instanz, nicht pro virtueller Netzwerkschnittstelle (vNIC) oder IP-Adresse. Der Maschinentyp einer VM definiert seine maximal mögliche Rate für ausgehenden Traffic. Diese maximal mögliche Rate für ausgehenden Traffic können Sie jedoch nur in bestimmten Situationen erreichen.

Auf dieser Seite werden Aspekte beschrieben, die beim Planen Ihrer Bereitstellungen eine Rolle spielen. Die Bandbreite wird anhand von zwei Dimensionen kategorisiert:

  • Ausgehender oder eingehender Traffic: Wie auf dieser Seite beschrieben, werden ausgehender und eingehender Traffic immer aus der Sicht einer Google Cloud-VM betrachtet:
    • Pakete, die von einer Google Cloud-VM gesendet werden, stellen ihren ausgehenden Traffic dar.
    • Pakete, die an eine Google Cloud-VM gesendet werden, stellen ihren eingehenden Traffic dar.
  • Routing des Pakets: Ein Paket kann von einer sendenden VM oder einer empfangenden VM mit Routen weitergeleitet werden, deren nächste Hops sich innerhalb eines VPC-Netzwerks oder Routen außerhalb eines VPC-Netzwerks befinden.

Weder zusätzliche virtuelle Netzwerkschnittstellen (vNICs) noch zusätzliche IP-Adressen pro vNIC erhöhen die Bandbreite für eingehenden oder ausgehenden Traffic für eine VM. Eine C3-VM mit 22 vCPUs ist beispielsweise auf 23 Gbit/s Gesamtbandbreite für ausgehenden Traffic beschränkt. Wenn Sie die C3-VM mit zwei vNICs konfigurieren, ist die VM weiterhin auf 23 Gbit/s Gesamtbandbreite für ausgehenden Traffic und nicht auf 23 Gbit/s Bandbreite pro vNIC beschränkt.

Alle Informationen auf dieser Seite gelten sowohl für Compute Engine-VMs als auch für Produkte, die von Compute Engine-VMs abhängen. Ein Google Kubernetes Engine-Knoten ist beispielsweise eine Compute Engine-VM.

Zusammenfassung zur Bandbreite

In der folgenden Tabelle werden die zu erwartenden Bandbreiten basierend darauf beschrieben, ob ein Paket von (ausgehender Traffic) gesendet oder von einer VM (eingehender Traffic) empfangen wird.

Ausgehender Traffic

Bandbreitenerwartungen
Routing innerhalb eines VPC-Netzwerks

  • Hauptsächlich durch eine maximale Bandbreite für ausgehenden Traffic pro VM definiert, basierend auf dem Maschinentyp der sendenden VM und der Aktivierung des Tier_1-Netzwerks.

    • N2-, N2D-, C2- und C2D-VMs mit Tier_1-Netzwerk unterstützen Bandbreitenbeschränkungen für ausgehenden Traffic bis zu 100 Gbit/s.
    • H3-VMs unterstützen VM-zu-VM-Bandbreitenlimits für ausgehenden Traffic bis zu 200 Gbit/s.
    • A2- und G2-VMs unterstützen Bandbreitenlimits für ausgehenden Traffic bis zu 100 Gbit/s.
    • A3-VMs unterstützen Bandbreitenlimits für ausgehenden Traffic bis zu 1.000 Gbit/s.
    • C3-, C3D- und Z3-VMs (Vorschau) unterstützen Bandbreitenlimits von bis zu 200 Gbit/s für ausgehenden Traffic mit Tier_1-Netzwerken.
  • Weitere Faktoren, Definitionen und Szenarien finden Sie unter Ausgehender Traffic an Ziele innerhalb eines VPC-Netzwerks.
Routing außerhalb eines VPC-Netzwerks

  • Hauptsächlich durch eine maximale Bandbreite für ausgehenden Traffic pro VM definiert, basierend auf dem Maschinentyp der sendenden VM und der Aktivierung des Tier_1-Netzwerks. Mit Ausnahme von H3-VMs darf der maximal mögliche ausgehende Traffic einer VM an ein Ziel außerhalb ihres VPC-Netzwerks Folgendes nicht überschreiten:

    • 7 Gbit/s insgesamt, wenn das Tier_1-Netzwerk nicht aktiviert ist
    • 25 Gbit/s insgesamt, wenn das Tier_1-Netzwerk aktiviert ist
    • 3 Gbit/s pro Fluss
  • Weitere Faktoren, Definitionen und Vorbehalte finden Sie unter Ausgehender Traffic zu Zielen außerhalb eines VPC-Netzwerks.

Eingehender Traffic

Bandbreitenerwartungen
Routing innerhalb eines VPC-Netzwerks
  • Im Allgemeinen ähneln die Preise für eingehenden Traffic den Preisen für ausgehenden Traffic für einen Maschinentyp.
  • Die Größe Ihrer VM, die Kapazität der Server-NIC, der Traffic, der auf anderen Gast-VMs auf derselben Hosthardware eingeht, die Konfiguration des Gastbetriebssystems und die Anzahl der von Ihrer VM ausgeführten Laufwerk-Lesevorgänge können alle den eingehenden Traffic beeinflussen.
  • Für Google Cloud gelten keine zusätzlichen Einschränkungen für Preise für eingehenden Traffic in einem VPC-Netzwerk.
  • Weitere Faktoren, Definitionen und Szenarien finden Sie unter Eingehender Traffic zu Zielen in einem VPC-Netzwerk.
Routing außerhalb eines VPC-Netzwerks

  • Google Cloud schützt jede VM durch die Beschränkung des eingehenden Traffics, der außerhalb eines VPC-Netzwerks weitergeleitet wird. Die Beschränkung entspricht der ersten der folgenden Raten:

    • 1.800.000 PPS (Pakete pro Sekunde)
    • 30 Gbit/s
  • Bei Maschinenserien, die mehrere physische NICs wie A3 unterstützen, ist das Limit die erste der folgenden Raten:
    • 1.800.000 PPS (Pakete pro Sekunde) pro physischer NIC
    • 30 Gbit/s pro physischer NIC
  • Weitere Faktoren, Definitionen und Szenarien finden Sie unter Eingehender Traffic zu Zielen außerhalb eines VPC-Netzwerks.

Bandbreite des ausgehenden Traffics

Google Cloud begrenzt die Bandbreite für ausgehenden Traffic pro VM über den maximalen ausgehenden Traffic pro VM der VM, die das Paket sendet, und darüber, ob das Ziel des Pakets über Routen in einem VPC-Netzwerk oder Routen außerhalb eines VPC-Netzwerks zugänglich ist. Die Bandbreite für ausgehenden Traffic umfasst Pakete, die von allen NICs der VM ausgegeben werden, und Daten, die an alle nichtflüchtigen Speicher übertragen werden, die mit der VM verbunden sind.

Maximale Bandbreite für ausgehenden Traffic pro VM

Die maximale Bandbreite für ausgehenden Traffic beträgt in der Regel 2 Gbit/s pro vCPU. Je nach Maschinenserie gibt es jedoch einige Unterschiede und Ausnahmen. Die folgende Tabelle zeigt den Bereich für die maximale Bandbreite für ausgehenden Traffic für Traffic, der in einem VPC-Netzwerk für Standardnetzwerke und nicht pro VM-Stufe_1-Netzwerkleistung weitergeleitet wird.

Maschinenserie Niedrigstes Limit für maximalen Traffic pro VM ohne Tier_1-Netzwerk Maximales Limit für ausgehenden Traffic pro VM ohne Tier_1-Netzwerk
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 und C2D 10 Gbit/s 32 Gbit/s
H3 – 200 Gbit/s
Z3 (Vorschau) 23 Gbit/s 100 Gbit/s
N1 (ohne VMs mit 1 vCPU) 10 Gbit/s 32 Gbit/s auf der Intel Skylake-CPU-Plattform
16 Gbit/s auf CPU-Plattformen, die älter als Intel Skylake sind
N1-Maschinentypen mit 1 vCPU, f1-micro und g1-small 2 Gbit/s 2 Gbit/s
A3, A2 und G2 – Basierend auf GPU-Typ

Die maximale Bandbreite für ausgehenden Traffic pro VM ist für jeden Maschinentyp auf der entsprechenden Maschinenfamilienseite vermerkt:

Die maximale Bandbreite für ausgehenden Traffic pro VM ist keine Garantie. Die tatsächliche Bandbreite für ausgehenden Traffic kann aufgrund von Faktoren wie der folgenden, nicht vollständigen Liste verringert werden:

  • Gast-Ethernet-Treiber – gVNIC bietet eine bessere Leistung als die VirtIO-Netzwerkschnittstelle
  • Paketgröße
  • Protokoll-Overhead
  • Anzahl der Flüsse
  • Ethernet-Treibereinstellungen des Gastbetriebssystems der VM, z. B. Prüfsummenabladung und TSO (TCP Segmentation Offload).
  • Netzwerküberlastung
  • Wenn nichtflüchtige Speicher mit dem anderen ausgehenden Netzwerktraffic um Bandbreite konkurrieren, werden 60 % der maximalen Bandbreite für ausgehenden Traffic für Persistent Disk und die verbleibenden 40 % für anderen ausgehenden Netzwerktraffic verwendet. Weitere Informationen finden Sie in der Dokumentation zu nichtflüchtigen Speichern unter Faktoren, die sich auf die Laufwerksleistung auswirken.

So erhalten Sie die maximal mögliche Bandbreite für ausgehenden Traffic pro VM:

  • Aktivieren Sie die Netzwerkleistung der VM_Tier_1 mit größeren allgemeinen und computing-optimierten Maschinentypen.
  • Verwenden Sie die größte maximale Übertragungseinheit (MTU) des VPC-Netzwerks, die von Ihrer Netzwerktopologie unterstützt wird. Größere MTUs können den Paketheader-Overhead reduzieren und den Nutzlastdatendurchsatz erhöhen.

Ausgehender Traffic an Ziele, die innerhalb eines VPC-Netzwerks routingfähig sind

Aus Sicht einer sendenden VM und für Ziel-IP-Adressen, die über Routen innerhalb eines VPC-Netzwerks zugänglich sind, begrenzt Google Cloud den ausgehenden Traffic mit den folgenden Regeln:

  • Maximale Bandbreite für ausgehenden Traffic pro VM: Die maximale Bandbreite für ausgehenden Traffic pro VM, die im Abschnitt Bandbreite für ausgehenden Traffic pro VM beschrieben wird.
  • Interregionale Bandbreite für ausgehenden Traffic pro Projekt: Wenn sich eine sendende VM und ein internes Ziel oder ihr nächster Hop in verschiedenen Regionen befinden, erzwingt Google Cloud eine maximale Bandbreite für interregionalen ausgehenden Traffic. Die meisten Kunden werden dieses Limit wahrscheinlich nicht erreichen. Bei Fragen zu diesem Limit reichen Sie eine Supportanfrage ein.
  • Limits für Cloud VPN und Cloud Interconnect: Wenn Traffic von einer VM an ein internes IP-Adressziel gesendet wird, das über einen Cloud VPN-Tunnel oder einen Cloud Interconnect-VLAN-Anhang als nächstem Hop weitergeleitet werden kann, wird die Bandbreite für ausgehenden Traffic begrenzt durch:

Ziele, die innerhalb eines VPC-Netzwerks weitergeleitet werden können, umfassen alle folgenden Ziele, die jeweils aus Sicht der sendenden VM über eine Route zugänglich sind, deren nächster Hop nicht das Standard-Internetgateway ist:

  • Regionale interne IPv4-Adressen in primären IPv4-Adressbereichen des Subnetzes und sekundären IPv4-Adressbereichen des Subnetzes, einschließlich privater IPv4-Adressbereiche und privat verwendeter öffentlicher IPv4-Adressbereiche, die von diesen Zielressourcen verwendet werden:
    • Die primäre interne IPv4-Adresse der Netzwerkschnittstelle einer empfangenden VM (vNIC). (Wenn eine sendende VM eine Verbindung zur externen IPv4-Adresse einer vNIC einer anderen VM herstellt, werden Pakete über ein Standard-Internetgateway des nächsten Hops weitergeleitet, sodass stattdessen Ausgehender Traffic zu Zielen außerhalb s VPC-Netzwerks zutrifft.)
    • Eine interne IPv4-Adresse in einem Alias-IP-Bereich der vNIC einer empfangenden VM.
    • Eine interne IPv4-Adresse einer internen Weiterleitungsregel für die Protokollweiterleitung oder den internen Passthrough-Network Load Balancer.
  • Globale interne IPv4-Adressen für diese Zielressourcen:
  • Interne IPv6-Subnetzadressbereiche, die von diesen Zielressourcen verwendet werden:
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96, die einem Dual-Stack-Empfang der vNIC der VM zugewiesen ist.
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96 einer internen Weiterleitungsregel für die Protokollweiterleitung oder für einen internen Passthrough-Network Load Balancer.
  • Externe IPv6-Subnetzadressbereiche, die von diesen Zielressourcen verwendet werden, wenn Pakete über Subnetzrouten oder Peering-Subnetzrouten innerhalb des VPC-Netzwerks oder über benutzerdefinierte Routen innerhalb der VPC-Netzwerks weitergeleitet werden, das nicht das nächste Standard-Internetgateway als nächsten Hop verwendet:
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96, die einem Dual-Stack-Empfang der vNIC der VM zugewiesen ist.
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96 einer externen Weiterleitungsregel für die Protokollweiterleitung oder für einen externen Passthrough-Network Load Balancer.
  • Andere Ziele, auf die über die folgenden VPC-Netzwerkrouten zugegriffen werden kann:

Die folgende Liste sortiert den Traffic vom Senden von VMs an interne Ziele von der höchstmöglichen zur niedrigsten Bandbreite:

Ausgehender Traffic zu Zielen außerhalb eines VPC-Netzwerks

Aus Sicht einer sendenden VM und für Ziel-IP-Adressen außerhalb eines VPC-Netzwerks begrenzt Google Cloud den ausgehenden Traffic auf den folgenden Wert, der zuerst erreicht wird:

  • Bandbreite für ausgehenden Traffic pro VM: Die maximale Bandbreite für alle Verbindungen von einer VM zu Zielen außerhalb eines VPC-Netzwerks ist kleiner.Maximale Bandbreite für ausgehenden Traffic pro VM und eine der folgenden Raten:

    • 25 Gbit/s, wenn das Netzwerk "Tier_1" aktiviert ist
    • 7 Gbit/s, wenn das Netzwerk "Tier_1" nicht aktiviert ist
    • 1 Gbit/s für H3-VMs
    • 7 Gbit/s pro physische NIC für Maschinenserien, die mehrere physische NICs wie A3 unterstützen.

    Beispiel: Eine n2-standard-16-Instanz hat eine maximale Bandbreite für ausgehenden Traffic von 32 Gbit/s pro VM. Die Bandbreite pro ausgehendem Traffic von einer n2-standard-16-Instanz pro VM für externe Ziele beträgt entweder 25 Gbit/s oder 7 Gbit/s, je nachdem, ob das Netzwerk "Tier_1" aktiviert ist.

  • Maximale Rate für ausgehenden Traffic: Die maximale Bandbreite für jede eindeutige 5-Tupel-Verbindung von einer VM zu einem Ziel außerhalb eines VPC-Netzwerks beträgt 3 Gbit/s, mit Ausnahme von H3, wobei die Leistung 1 Gbit/s beträgt.

  • Bandbreite für ausgehenden Internettraffic pro Projekt: Die maximale Bandbreite für alle Verbindungen von VMs in jeder Region eines Projekts zu Zielen außerhalb eines VPC-Netzwerks ist durch die Bandbreitenkontingente für ausgehenden Internettraffic des Projekts definiert.

Die Ziele außerhalb eines VPC-Netzwerks umfassen alle folgenden Ziele, auf die jede Route im VPC-Netzwerk der sendenden VM zugreifen kann, deren nächster Hop das Standard-Internetgateway ist:

  • Globale externe IPv4- und IPv6-Adressen für externe Network Load Balancer und externe Application Load Balancer
  • Regionale externe IPv4-Adressen für Google Cloud-Ressourcen, einschließlich externer IPv4-Adressen der VM-vNIC, externe IPv4-Adressen für die externe Protokollweiterleitung, externe Passthrough-Network Load Balancer und Antwortpakete an Cloud NAT-Gateways.
  • Regionale externe IPv6-Adressen in Dual-Stack-Subnetzen mit externen IPv6-Adressbereichen, die von externen Dual-Stack-VM-IPv6-Adressen, externen Protokollweiterleitungen und externen Passthrough-Network Load Balancern verwendet werden, sofern sich das Subnetz in einem separaten Nicht-Peering-VPC-Netzwerk befindet und auf den Ziel-IPv6-Adressbereich über eine Route im VPC-Netzwerk der sendenden VM zugegriffen werden kann, dessen nächster Hop das Standard-Internetgateway ist. Wenn sich ein Dual-Stack-Subnetz mit einem externen IPv6-Adressbereich im selben VPC-Netzwerk oder in einem Peering-VPC-Netzwerk befindet, finden Sie weitere Informationen unter Ausgehender Traffic an Ziele innerhalb eines VPC-Netzwerks.
  • Andere externe Ziele, auf die über eine statische Route im VPC-Netzwerk der sendenden VM zugegriffen werden kann, sofern der nächste Hop für die Route das Standard-Internetgateway ist.

Weitere Informationen dazu, welche Google Cloud-Ressourcen welche Arten von externen IP-Adressen verwenden, finden Sie unter Externe IP-Adressen.

Bandbreite des eingehenden Traffics

Google Cloud verarbeitet eingehende Bandbreite (eingehend), je nachdem, wie das eingehende Paket an eine empfangende VM weitergeleitet wird.

Eingehender Traffic zu Zielen, die innerhalb eines VPC-Netzwerks routingfähig sind

Eine empfangende VM kann so viele eingehende Pakete verarbeiten, wie es der Maschinentyp, das Betriebssystem und andere Netzwerkbedingungen zulassen. Google Cloud implementiert keine zielgerichtete Bandbreitenbeschränkung für eingehende Pakete, die an eine VM gesendet werden, wenn das eingehende Paket über Routen innerhalb eines VPC-Netzwerks zugestellt wird:

  • Subnetzrouten im VPC-Netzwerk der empfangenden VM
  • Peering-Subnetzrouten in einem Peering-VPC-Netzwerk
  • Routen in einem anderen Netzwerk, dessen nächste Hops Cloud VPN-Tunnel, Cloud Interconnect-Anhänge (VLAN) oder Router-Appliance-VMs sind, die sich im VPC-Netzwerk der empfangenden VM befinden

Zu den Zielen für Pakete, die in einem VPC-Netzwerk weitergeleitet werden, gehören:

  • Die primäre interne IPv4-Adresse der Netzwerkschnittstelle (vNIC) der empfangenden VM. Primäre interne IPv4-Adressen sind regionale interne IPv4-Adressen, die aus dem primären IPv4-Adressbereich des Subnetzes stammen.
  • Eine interne IPv4-Adresse aus einem Alias-IP-Bereich der vNIC der empfangenden VM. Alias-IP-Bereiche können entweder aus dem primären IPv4-Adressbereich eines Subnetzes oder aus einem seiner sekundären IPv4-Adressbereiche stammen.
  • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96, die einem Dual-Stack-Empfang der vNIC der VM zugewiesen ist. VM-IPv6-Bereiche können aus den folgenden IPv6-Subnetzbereichen stammen:
  • Eine interne IPv4-Adresse einer Weiterleitungsregel, die von der internen Protokollweiterleitung an die empfangende VM oder den internen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende VM ein Backend des Load Balancers ist. Interne IPv4-Adressen der internen Weiterleitungsregel stammen aus dem primären IPv4-Adressbereich eines Subnetzes.
  • Eine interne IPv6-Adresse aus dem IPv6-Bereich /96 einer Weiterleitungsregel, die von der internen Protokollweiterleitung an die empfangende VM oder den internen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende VM ein Backend des Load Balancers ist. IPv6-Adressen der internen Weiterleitungsregel stammen aus dem internen IPv6-Adressbereich eines Subnetzes.
  • Eine externe IPv6-Adresse aus dem IPv6-Bereich /96 einer Weiterleitungsregel, die von der externen Protokollweiterleitung an die empfangende VM oder den externen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende VM ein Backend des Load Balancers ist, wenn das eingehende Paket im VPC-Netzwerk mit einer der zuvor in diesem Abschnitt aufgeführten Routen weitergeleitet wird. Externe IPv6-Adressen der externen Weiterleitungsregel stammen aus dem externen IPv6-Adressbereich eines Subnetzes.
  • Eine IP-Adresse im Zielbereich einer benutzerdefinierten statischen Route, die die Instanz als VM des nächsten Hops verwendet (next-hop-instance oder next-hop-address).
  • Eine IP-Adresse innerhalb des Zielbereichs einer benutzerdefinierten statischen Route, die einen internen Passthrough-Network Load Balancer (next-hop-ilb) als nächsten Hop verwendet, wenn die empfangende VM ein Backend für diesen Load Balancer ist.

Eingehender Traffic zu Zielen außerhalb eines VPC-Netzwerks

Google Cloud implementiert die folgenden Bandbreiteneinschränkungen für eingehende Pakete, die an eine empfangende VM über Routen außerhalb eines VPC-Netzwerks gesendet werden. Wenn das Load-Balancing beteiligt ist, werden die Bandbreitenlimits für jede empfangende VM einzeln angewendet.

Bei Maschinenserien, die mehrere physische NICs nicht unterstützen, gilt die geltende Bandbreitenbeschränkung für eingehenden Traffic kollektiv für alle virtuellen NICs. Die Beschränkung entspricht der ersten der folgenden Raten:

  • 1.800.000 Pakete pro Sekunde
  • 30 Gbit/s

Für Maschinenserien, die mehrere physische NICs unterstützen, z. B. A3, gilt die entsprechende Beschränkung der eingehenden Bandbreite für jede physische NICs. Die Beschränkung entspricht der ersten der folgenden Raten:

  • 1.800.000 Pakete pro Sekunde und physische NIC
  • 30 Gbit/s pro physischer NIC

Ziele für Pakete, die über Routen außerhalb eines VPC-Netzwerks weitergeleitet werden:

  • Eine externe IPv4-Adresse, die in einer 1:1-NAT-Zugriffskonfiguration auf einer der Netzwerkschnittstellen (NICs) der empfangenden VM zugewiesen ist.
  • Eine externe IPv6-Adresse aus dem IPv6-Adressbereich /96, die einer vNIC einer empfangenden Dual-Stack-VM zugewiesen ist, wenn das eingehende Paket über eine Route außerhalb des VPC-Netzwerks der empfangenden VM weitergeleitet wird.
  • Eine externe IPv4-Adresse einer Weiterleitungsregel, die von der externen Protokollweiterleitung an die empfangende VM oder den externen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende VM ein Backend des Load Balancers ist.
  • Eine externe IPv6-Adresse aus dem IPv6-Bereich /96 einer Weiterleitungsregel, die von der externen Protokollweiterleitung an die empfangende VM oder den externen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende VM ein Backend des Load Balancers ist, wenn das eingehende Paket über eine Route außerhalb eines VPC-Netzwerks weitergeleitet wird.
  • Von Cloud NAT verarbeitete eingehende Antworten

Jumbo Frames

Um Jumbo Frames zu empfangen und zu senden, konfigurieren Sie das von Ihren VMs verwendete VPC-Netzwerk. Setzen Sie die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) auf einen höheren Wert, bis zu 8.896.

Höhere MTU-Werte erhöhen die Paketgröße und reduzieren den Paketheader-Overhead, wodurch der Nutzlastdatendurchsatz erhöht wird.

Zur Verwendung von Jumbo Frames mit dem gVNIC-Treiber müssen Sie den Treiber ab Version 1.3 verwenden. Nicht alle öffentlichen Images von Google Cloud enthalten diese Treiberversion. Weitere Informationen zur Betriebssystemunterstützung für Jumbo Frames finden Sie auf dem Tab Netzwerkfeatures auf der Seite Details zu Betriebssystemen. Die Image-Versionen, die angeben, dass Jumbo Frames vollständig unterstützt werden, enthalten den aktualisierten gVNIC-Treiber, auch wenn das Gastbetriebssystem die gve-Treiberversion als 1.0.0 anzeigt.

Wenn Sie ein Betriebssystem-Image verwenden, das keine vollständige Unterstützung für Jumbo Frames bietet, können Sie die gVNIC-Treiberversion 1.3.0 oder höher manuell installieren. Google empfiehlt, die gVNIC-Treiberversion mit der Markierung Latest zu installieren, um von den zusätzlichen Funktionen und Fehlerkorrekturen zu profitieren. Sie können die gVNIC-Treiber von GitHub herunterladen.

Informationen zum manuellen Aktualisieren der gVNIC-Treiberversion in Ihrem Gastbetriebssystem finden Sie unter Nicht unterstützte Betriebssysteme verwenden.

Empfangs- und Übertragungswarteschlangen

Jeder VM-vNIC wird eine feste Anzahl an Empfangs- und Übertragungswarteschlangen für die Verarbeitung von Paketen aus dem Netzwerk zugewiesen.

  • Empfangswarteschlange (Receive Queue, RX): Warteschlange zum Empfangen von Paketen. Wenn die vNIC ein Paket aus dem Netzwerk empfängt, wählt sie den Deskriptor für ein eingehendes Paket aus der Warteschlange aus, verarbeitet es und übergibt das Paket über eine Paketwarteschlange, die an einen vCPU-Kern angehängt ist, mithilfe eines Interrupts an das Gastbetriebssystem. Wenn die RX-Warteschlange voll und kein Puffer für das Speichern eines Pakets verfügbar ist, wird das Paket gelöscht. Dies kann in der Regel auftreten, wenn eine Anwendung einen vCPU-Kern überlastet, der auch mit der ausgewählten Paketwarteschlange verknüpft ist.
  • Transmit Queue (TX): Warteschlange für die Übertragung von Paketen. Wenn das Gastbetriebssystem ein Paket sendet, wird ein Deskriptor zugewiesen und in die TX-Warteschlange platziert. Die NIC verarbeitet dann den Deskriptor und überträgt das Paket.

Standardmäßige Warteschlangenzuweisung

Sofern Sie nicht explizit eine Anzahl der Warteschlangen für NICs zuweisen, können Sie den Algorithmus modellieren, mit dem Google Cloud eine feste Anzahl von RX- und TX-Warteschlangen pro vNIC zuweist. Gehen Sie dazu so vor:

  1. Verwenden Sie je nach Netzwerkschnittstellentyp eine der folgenden Methoden:

    • VirtIO: Teilen Sie die Anzahl der vCPUs durch die Anzahl der NICs und ignorieren Sie den Restbetrag: [[number of vCPUs/number of NICs]].
    • gVNIC: Teilen Sie die Anzahl der vCPUs durch die Anzahl der NICs und teilen Sie das Ergebnis durch 2 und ignorieren Sie den Restbetrag: [[number of vCPUs/number of NICs/2]].

    Diese Berechnung ergibt immer eine ganze Zahl (keine Bruchzahl).

  2. Wenn die berechnete Anzahl kleiner als 1 ist, weisen Sie stattdessen jeder vNIC eine Warteschlange zu.

  3. Ermitteln Sie, ob die berechnete Anzahl größer als die maximale Anzahl von Warteschlangen pro vNIC ist. Die maximale Anzahl von Warteschlangen pro vNIC hängt vom Treibertyp ab:

    • Mit virtIO oder einem benutzerdefinierten Treiber ist die maximale Anzahl von Warteschlangen pro vNIC 32. Wenn die berechnete Anzahl größer als 32 ist, ignorieren Sie die berechnete Anzahl und weisen Sie stattdessen jeder vNIC 32 Warteschlangen zu.
    • Mit gVNIC beträgt die maximale Anzahl von Warteschlangen pro vNIC 16. Wenn die berechnete Anzahl größer als 16 ist, ignorieren Sie die berechnete Anzahl und weisen Sie stattdessen jeder vNIC 16 Warteschlangen zu.

Die folgenden Beispiele zeigen, wie die Standardanzahl der Warteschlangen berechnet wird:

  • Wenn eine VM VirtIO verwendet und 16 vCPUs und 4 NICs hat, ist die berechnete Anzahl [16/4] = 4. Google Cloud weist jeder vNIC vier Warteschlangen zu.

  • Wenn eine VM mit gVNIC 128 vCPUs und zwei NICs hat, beträgt die berechnete Anzahl [128/2/2] = 32. Google Cloud weist jeder vNIC die maximale Anzahl von Warteschlangen pro vNIC zu. Google Cloud weist 16 Warteschlangen pro vNIC zu.

Auf Linux-Systemen können Sie mit ethtool eine vNIC konfigurieren, die weniger Warteschlangen hat als die Anzahl der Warteschlangen, die Google Cloud pro vNIC zuweist.

Benutzerdefinierte Warteschlangenzuweisung

Anstelle der standardmäßigen Warteschlangenzuweisung können Sie jeder vNIC eine benutzerdefinierte Anzahl von Warteschlangen (insgesamt RX und TX) zuweisen, wenn Sie eine neue VM mit der Compute Engine API erstellen.

Die Anzahl der benutzerdefinierten Warteschlangen, die Sie angeben, muss den folgenden Regeln entsprechen:

  • Die Mindestanzahl der Warteschlangen, die Sie pro vNIC zuweisen können, ist 1.

  • Die maximale Warteschlangenanzahl, die Sie jeder vNIC zuweisen können, ist je nach Treibertyp die niedrigere Anzahl der vCPUs oder die maximale Anzahl von vNIC-Warteschlangen:

    • Mit virtIO oder einem benutzerdefinierten Treiber beträgt die maximale Anzahl der Warteschlangen 32.
    • Mit gVNIC beträgt die maximale Anzahl der Warteschlangen 16.

  • Wenn Sie allen NICs der VM benutzerdefinierte Werte für die Anzahl der Warteschlangen zuweisen, muss die Summe der zugewiesenen Werte für die Anzahl der Warteschlangen kleiner oder gleich der Anzahl der vCPUs sein, die der VM-Instanz zugewiesen sind.

Sie können die Anzahl der benutzerdefinierten Warteschlangen für Ihre NICs überbelegen. Mit anderen Worten, Sie können eine Summe der Anzahl von Warteschlangen, die allen NICs für Ihre VM zugewiesen sind, haben, die größer als die Anzahl der vCPUs für Ihre VM ist. Wenn Sie die Anzahl der benutzerdefinierten Warteschlangen überbelegen möchten, müssen Sie die folgenden Bedingungen erfüllen:

  • Sie verwenden gVNIC als vNIC-Typ für alle für die VM konfigurierten NICs.
  • Ihre VM verwendet einen Maschinentyp aus den Maschinenserien N2, N2D, C2 und C2D.
  • Sie haben das Tier_1-Netzwerk für die VM aktiviert.
  • Sie haben eine benutzerdefinierte Warteschlangenanzahl für alle für die VM konfigurierten NICs angegeben.

Bei einer Warteschlangen-Überbelegung beträgt die maximale Warteschlangenanzahl für die VM das 16-Fache der Anzahl der NICs. Wenn Sie also 6 NICs für eine VM mit 30 vCPUs konfiguriert haben, können Sie maximal (16 * 6) oder 96 benutzerdefinierte Warteschlangen für Ihre VM konfigurieren.

Beispiele

  • Wenn eine VM 8 vCPUs und 3 NICs hat, ist die maximale Warteschlangenanzahl für die VM die Anzahl der vCPUs oder 8. Sie können nic0 eine Warteschlange, nic1 vier Warteschlangen und nic2 drei Warteschlangen zuweisen. In diesem Beispiel können Sie nic2 nicht anschließend vier Warteschlangen zuweisen, während Sie die beiden anderen Zuweisungen der vNIC-Warteschlangen beibehalten, da die Summe der zugewiesenen Warteschlangen die Anzahl der vCPUs (8) nicht überschreiten darf.

  • Wenn eine VM 96 vCPUs und 2 NICs hat, können Sie bei Verwendung des virtIO-Treibers jeweils bis zu 32 Warteschlangen und bei Verwendung des gVNIC-Treibers bis zu 16 Warteschlangen zuweisen. In diesem Beispiel liegt die Summe der zugewiesenen Warteschlangen immer unter der Anzahl der vCPUs.

Es ist auch möglich, die Anzahl benutzerdefinierter Warteschlangen nur für einige NICs zuzuweisen, damit Google Cloud den verbleibenden NICs Warteschlangen zuweisen kann. Die Anzahl der Warteschlangen, die Sie pro vNIC zuweisen können, unterliegt weiterhin den zuvor genannten Regeln. Mit diesem Verfahren können Sie die Machbarkeit Ihrer Konfiguration modellieren und, sofern möglich, die Anzahl der Warteschlangen, die Google Cloud mit diesem Prozess den verbleibenden NICs zuweist:

  1. Berechnen Sie die Summe der Warteschlangen für die NICs mithilfe der benutzerdefinierten Warteschlangenzuweisung. Angenommen, Sie weisen für eine Beispiel-VM mit 20 vCPUs und 6 NICs nic0 fünf Warteschlangen, nic1 sechs Warteschlangen und nic2 vier Warteschlangen zu und lassen Google Cloud Warteschlangen für nic3, nic4 und nic5 zuweisen. In diesem Beispiel beträgt die Summe der benutzerdefinierten Warteschlangen 5+6+4 = 15.

  2. Ziehen Sie die Summe der benutzerdefinierten Warteschlangen von der Anzahl der vCPUs ab. Wenn die Differenz nicht mindestens der Anzahl der verbleibenden NICs entspricht, für die Google Cloud Warteschlangen zuweisen muss, gibt Google Cloud einen Fehler zurück. Ausgehend von der Beispiel-VM mit 20 vCPUs und einer Summe von 15 benutzerdefinierten Warteschlangen sind noch 20-15 = 5 Warteschlangen übrig, die Google Cloud den verbleibenden NICs (nic3, nic4, nic5) zuweisen kann.

  3. Teilen Sie die Differenz aus dem vorherigen Schritt durch die Anzahl der verbleibenden NICs und verwerfen Sie alle verbleibenden Werte: ⌊(number of vCPUs - sum of assigned queues)/(number of remaining NICs)⌋. Diese Berechnung ergibt immer eine ganze Zahl (keine Bruchzahl), die mindestens gleich 1 ist, aufgrund der im vorherigen Schritt erläuterten Einschränkung. Google Cloud weist jeder verbleibenden NIC eine Anzahl der Warteschlangen zu, die der berechneten Anzahl entspricht, solange die berechnete Anzahl nicht größer als die maximale Anzahl von Warteschlangen pro vNIC ist. Die maximale Anzahl von Warteschlangen pro vNIC hängt vom Treibertyp ab:

    • Wenn Sie virtIO oder einen benutzerdefinierten Treiber verwenden und die berechnete Anzahl von Warteschlangen für jede verbleibende vNIC größer als 32 ist, weist Google Cloud allen verbleibenden vNICs 32 Warteschlangen zu.
    • Wenn Sie gVNIC verwenden und die berechnete Anzahl der Warteschlangen für jede verbleibende vNIC größer als 16 ist, weist Google Cloud jeder verbleibenden vNIC 16 Warteschlangen zu.

Anzahl benutzerdefinierter Warteschlangen konfigurieren

Führen Sie die folgenden Schritte aus, um eine VM zu erstellen, die eine benutzerdefinierte Warteschlangenanzahl für eine oder mehrere vNICs verwendet.

gcloud

  1. Wenn Sie noch kein VPC-Netzwerk mit einem Subnetz für jede vNIC-Schnittstelle haben, die Sie konfigurieren möchten, erstellen Sie sie.
  2. Verwenden Sie den Befehl gcloud compute instances create, um die VM zu erstellen. Wiederholen Sie das Flag --network-interface für jede vNIC, die Sie für die VM konfigurieren möchten, und fügen Sie die Option queue-count ein.
    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

Ersetzen Sie Folgendes:

  • VM_NAME: ein Name für die neue VM.
  • ZONE ist die Zone, in der die VM erstellt werden soll.
  • MACHINE_TYPE ist der Maschinentyp der VM. Der von Ihnen angegebene Maschinentyp muss gVNIC und das Tier_1-Netzwerk unterstützen.
  • NETWORK_NAME: der Name des zuvor erstellten Netzwerks
  • SUBNET_*: der Name eines der zuvor erstellten Subnetze
  • QUEUE_SIZE: die Anzahl der Warteschlangen für die vNIC, gemäß den unter Benutzerdefinierte Warteschlangenzuweisung beschriebenen Regeln.

Terraform

  1. Wenn Sie noch kein VPC-Netzwerk mit einem Subnetz für jede vNIC-Schnittstelle haben, die Sie konfigurieren möchten, erstellen Sie sie.

  2. Erstellen Sie mit der Ressource google_compute_instance eine VM mit bestimmten Warteschlangenanzahlen für vNICs. Wiederholen Sie den Parameter --network-interface für jede vNIC, die Sie für die VM konfigurieren möchten, und fügen Sie den Parameter queue-count ein.

    # 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""
}

}

Ersetzen Sie Folgendes:

  • VM_NAME: ein Name für die neue VM.
  • PROJECT_ID: ID des Projekts, in dem die VM erstellt werden soll. Sofern Sie kein freigegebenes VPC-Netzwerk verwenden, muss das von Ihnen angegebene Projekt dasselbe sein, in dem alle Subnetze und Netzwerke erstellt wurden.
  • DEVICE_NAME: Der Name, der dem Bootlaufwerk im Gastbetriebssystem zugeordnet werden soll.
  • IMAGE_NAME: der Name eines Images, z. B. "projects/debian-cloud/global/images/debian-11-bullseye-v20231010".
  • DISK_SIZE: die Größe des Bootlaufwerks in GiB
  • DISK_TYPE: der Typ des Laufwerks, das für das Bootlaufwerk verwendet werden soll, z. B. pd-standard
  • MACHINE_TYPE ist der Maschinentyp der VM. Der von Ihnen angegebene Maschinentyp muss gVNIC und das Tier_1-Netzwerk unterstützen.
  • ZONE ist die Zone, in der die VM erstellt werden soll.
  • QUEUE_COUNT: die Anzahl der Warteschlangen für die vNIC, gemäß den unter Benutzerdefinierte Warteschlangenzuweisung beschriebenen Regeln.
  • SUBNET_*: der Name des Subnetzes, mit dem die Netzwerkschnittstelle eine Verbindung herstellt.

REST

  1. Wenn Sie noch kein VPC-Netzwerk mit einem Subnetz für jede vNIC-Schnittstelle haben, die Sie konfigurieren möchten, erstellen Sie sie.

  2. Erstellen Sie eine VM mit bestimmten Anzahlen von Warteschlangen für NICs mit der Methode instances.insert. Wiederholen Sie das Attribut networkInterfaces, um mehrere Netzwerkschnittstellen zu konfigurieren.

    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"
    } ],
}

    Ersetzen Sie Folgendes:

    • PROJECT_ID: ID des Projekts, in dem die VM erstellt werden soll.
    • ZONE ist die Zone, in der die VM erstellt werden soll.
    • VM_NAME ist der Name der neuen VM.
    • MACHINE_TYPE: vordefinierter oder benutzerdefinierter Maschinentyp für die neue VM.
    • SUBNET_*: der Name des Subnetzes, mit dem die Netzwerkschnittstelle eine Verbindung herstellt
    • QUEUE_COUNT: Anzahl der Warteschlangen für die vNIC, gemäß den unter Benutzerdefinierte Warteschlangenzuweisung erläuterten Regeln.

Warteschlangenzuweisung und Änderungen von Maschinentypen

VMs werden mit einer standardmäßigen Warteschlangenzuweisung erstellt. Sie können auch jeder virtuellen Netzwerkkarte (vNIC) eine benutzerdefinierte Warteschlangenanzahl zuweisen, wenn Sie eine neue VM mit der Compute Engine API erstellen. Die standardmäßigen oder benutzerdefinierten vNIC-Warteschlangenzuweisungen werden nur beim Erstellen einer VM festgelegt. Wenn Ihre VM vNICs hat, die die Standardanzahl von Warteschlangen verwenden, können Sie den Maschinentyp ändern. Wenn der Maschinentyp, zu dem Sie wechseln, eine andere Anzahl von vCPUs hat, wird die Anzahl der Standardwarteschlangen für Ihre VM anhand des neuen Maschinentyps neu berechnet.

Wenn Ihre VM vNICs hat, die die benutzerdefinierte, nicht standardmäßige Anzahlen von Warteschlangen verwenden, können Sie den Maschinentyp über die Google Cloud CLI oder die Compute Engine API ändern, um die Instanzattribute zu aktualisieren. Die Konvertierung ist erfolgreich, wenn die resultierende VM die gleiche Warteschlangenanzahl pro VNIC wie die ursprüngliche VM unterstützt. Für VMs, die die VirtIO-Net-Schnittstelle verwenden und eine benutzerdefinierte Warteschlangenanzahl haben, die höher als 16 pro vNIC ist, können Sie den Maschinentyp nicht in einen Maschinentyp der dritten Generation ändern, der nur gVNIC verwendet. Stattdessen können Sie Ihre VM zu einem Maschinentyp der dritten Generation migrieren. Folgen Sie dazu der Anleitung unter Arbeitslast von einer vorhandenen VM zu einer neuen VM migrieren.

Nächste Schritte