Netzwerkbandbreite

Google Cloud berücksichtigt die Bandbreite pro Compute-Instanz, nicht pro virtueller Netzwerkschnittstelle (vNIC) oder IP-Adresse. Der Maschinentyp einer Instanz 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-Instanz betrachtet:
    • Pakete, die von einer Google Cloud-Instanz gesendet werden, stellen ihren ausgehenden Traffic dar.
    • Pakete, die an eine Google Cloud-Instanz gesendet werden, stellen ihren eingehenden Traffic dar.
  • Routing des Pakets: Ein Paket kann von einer sendenden VM oder einer empfangenden Instanz 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 Compute-Instanz. 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-Recheninstanzen als auch für Produkte, die von Compute Engine-Instanzen abhängen. Ein Google Kubernetes Engine-Knoten ist beispielsweise eine Compute Engine-Instanz.

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 Compute-Instanz (eingehender Traffic) empfangen wird.

Egress

Bandbreitenerwartungen
Routing innerhalb eines VPC-Netzwerks

  • Hauptsächlich durch eine maximale Bandbreite für ausgehenden Traffic pro Instanz definiert, basierend auf dem Maschinentyp der sendenden Instanz 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.
    • X4-, A2- und G2-Instanzen unterstützen Bandbreitenlimits für ausgehenden Traffic bis zu 100 Gbit/s.
    • A3-Instanzen unterstützen Bandbreitenlimits für ausgehenden Traffic bis zu 1.800 Gbit/s.
    • C4-, C3-, C3D- und Z3-Instanzen unterstützen Bandbreitenlimits von bis zu 200 Gbit/s für ausgehenden Traffic bei 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 Instanz definiert, basierend auf dem Maschinentyp der sendenden Instanz und der Aktivierung des Tier_1-Netzwerks. Mit Ausnahme von H3-VMs darf der maximal mögliche ausgehende Traffic einer Instanz 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 Compute-Instanz, 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 Instanz 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 Compute-Instanz 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 einer Maschinenserie, die mehrere physische NICs unterstützt, z. B. A3, ist das Limit die erste der folgenden Geschwindigkeiten:

    • 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 Instanz über den maximalen ausgehenden Traffic pro Instanz. Diese Raten basieren auf dem Maschinentyp der Compute-Instanz, die das Paket sendet, und darauf, 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 Instanz ausgegeben werden, und Daten, die an alle Hyperdisk- und Persistent Disk-Volumes übertragen werden, die mit der Instanz verbunden sind.

Maximale Bandbreite für ausgehenden Traffic pro Instanz

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 Instanz ohne Tier_1-Netzwerk Maximales Limit für ausgehenden Traffic pro Instanz ohne Tier_1-Netzwerk
C4 10 Gbit/s 100 Gbit/s
C3 23 Gbit/s 100 Gbit/s
C3D 20 Gbit/s 100 Gbit/s
C2 und C2D 10 Gbit/s 32 Gbit/s
E2 1 Gbit/s 16 Gbit/s
H3 – 200 Gbit/s
N4 10 Gbit/s 50 Gbit/s
N2 und N2D 10 Gbit/s 32 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
T2D 10 Gbit/s 32 Gbit/s
X4 – 100 Gbit/s
Z3 23 Gbit/s 100 Gbit/s

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

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

  • VirtIO anstelle von gVNIC mit Compute-Instanzen verwenden, die beide unterstützen
  • Paketgröße
  • Protokoll-Overhead
  • Anzahl der Flüsse
  • Ethernet-Treibereinstellungen des Gastbetriebssystems der Compute-Instanz, 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 unter Faktoren, die sich auf die Laufwerksleistung auswirken.

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

  • Aktivieren Sie die Netzwerkleistung der VM_Tier_1 mit größeren 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.
  • Verwenden Sie die neueste gVNIC-Treiberversion.
  • Verwenden Sie Maschinen der dritten Generation oder höher, die Titanium verwenden, um die Netzwerkverarbeitung von der Host-CPU auszulagern.

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

Aus Sicht einer sendenden Instanz 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 Instanz, die im Abschnitt Bandbreite für ausgehenden Traffic pro Instanz beschrieben wird.
  • Interregionale Bandbreite für ausgehenden Traffic pro Projekt: Wenn sich eine sendende Instanz 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 Instanz 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 Instanz ü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 Instanz (vNIC). (Wenn eine sendende Instanz eine Verbindung zur externen IPv4-Adresse einer vNIC einer anderen Instanz herstellt, werden Pakete über ein Standard-Internetgateway des nächsten Hops weitergeleitet, sodass stattdessen Ausgehender Traffic zu Zielen außerhalb eines VPC-Netzwerks zutrifft.)
    • Eine interne IPv4-Adresse in einem Alias-IP-Bereich der vNIC einer empfangenden Instanz.
    • 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 Instanz 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 Instanz 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 Instanzen an interne Ziele von der höchstmöglichen zur niedrigsten Bandbreite:

Ausgehender Traffic zu Zielen außerhalb eines VPC-Netzwerks

Aus Sicht einer sendenden Instanz 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 Instanz: Die maximale Bandbreite für alle Verbindungen von einer Compute-Instanz zu Zielen außerhalb eines VPC-Netzwerks ist kleiner.Maximale Bandbreite für ausgehenden Traffic pro Instanz und eine der folgenden Raten:

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

    Beispiel: Eine c3-standard-44-Instanz hat eine maximale Bandbreite für ausgehenden Traffic von 32 Gbit/s pro VM. Die Bandbreite pro ausgehendem Traffic von einer c3-standard-44-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 Compute-Instanz 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 Compute-Instanzen 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 Instanz 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 IPv6-Adressen von Dual-Stack-Instanzen, der externen Protokollweiterleitung und externen Passthrough-Network Load Balancern verwendet werden. Das Subnetz muss sich in einem separaten, nicht gekoppelten VPC-Netzwerk befinden. Auf den Ziel-IPv6-Adressbereich muss über eine Route im VPC-Netzwerk der sendenden Instanz zugegriffen werden können, deren 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 Instanz 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 Compute-Instanz weitergeleitet wird.

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

Eine empfangende Instanz 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 Instanz gesendet werden, wenn das eingehende Paket über Routen innerhalb eines VPC-Netzwerks zugestellt wird:

  • Subnetzrouten im VPC-Netzwerk der empfangenden Instanz
  • 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-Instanzen sind, die sich im VPC-Netzwerk der empfangenden Instanz befinden

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

  • Die primäre interne IPv4-Adresse der Netzwerkschnittstelle (NIC) der empfangenden Instanz. 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 NIC der empfangenden Instanz. 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 NIC der Instanz zugewiesen ist. IPv6-Bereiche von Compute-Instanzen können aus den folgenden IPv6-Subnetzbereichen stammen:
  • Eine interne IPv4-Adresse einer Weiterleitungsregel, die von der internen Protokollweiterleitung an die empfangende Instanz oder den internen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende Instanz 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 Instanz oder den internen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende Instanz 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 Instanz oder den externen Passthrough-Network Load Balancer verwendet wird. Die empfangende Instanz ist ein Backend des Load Balancers, wenn das eingehende Paket innerhalb des VPC-Netzwerks 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 Instanz 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 Instanz über Routen außerhalb eines VPC-Netzwerks gesendet werden. Bei Load Balancing werden die Bandbreitenlimits einzeln auf jede Empfängerinstanz angewendet.

Bei Maschinenserien, die keine mehreren physischen NICs unterstützen, gilt die entsprechende Einschränkung der eingehenden Bandbreite für alle virtuellen Netzwerkschnittstellen (vNICs). Die Beschränkung entspricht der ersten der folgenden Raten:

  • 1.800.000 Pakete pro Sekunde
  • 30 Gbit/s

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

  • 1.800.000 Pakete pro Sekunde pro physischer 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 Instanz zugewiesen ist.
  • Eine externe IPv6-Adresse aus dem IPv6-Adressbereich /96, die einer vNIC einer empfangenden Dual-Stack-Instanz zugewiesen ist, wenn das eingehende Paket über eine Route außerhalb des VPC-Netzwerks der empfangenden Instanz weitergeleitet wird.
  • Eine externe IPv4-Adresse einer Weiterleitungsregel, die von der externen Protokollweiterleitung an die empfangende Instanz oder den externen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende Instanz 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 Instanz oder den externen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende Instanz 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 Compute-Instanzen 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.

Sie können Jumbo Frames mit der gVNIC-Treiberversion 1.3 oder höher auf VM-Instanzen oder mit dem IDPF-Treiber auf Bare-Metal-Instanzen verwenden. Nicht alle öffentlichen Google Cloud-Images enthalten diese Treiber. Weitere Informationen zur Betriebssystemunterstützung für Jumbo Frames finden Sie auf dem Tab Netzwerkfeatures auf der Seite Details zu Betriebssystemen.

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

Jedem NIC oder jeder vNIC für eine Compute-Instanz wird eine Reihe von Empfangs- und Übertragungswarteschlangen für die Verarbeitung von Paketen aus dem Netzwerk zugewiesen.

  • Empfangswarteschlange (Receive Queue, RX): Warteschlange zum Empfangen von Paketen. Wenn die NIC ein Paket aus dem Netzwerk empfängt, wählt die NIC den Deskriptor für ein eingehendes Paket aus der Warteschlange aus, verarbeitet es und übergibt das Paket über eine Paketwarteschlange, die an eine vCPU angehängt ist, per Interrupt 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 NIC zuweist. Gehen Sie dazu so vor:

Bare-Metal-Instanzen
Bei Bare-Metal-Instanzen gibt es nur eine NIC, sodass die maximale Anzahl von Warteschlangen 16 beträgt.
VM-Instanzen erstellen, die die gVNIC Netzwerkschnittstelle nutzen

Die Anzahl der Warteschlangen hängt davon ab, ob für die Gerätereihe Titanium verwendet wird oder nicht.

  • Gen3 (außer M3) und neuere Instanzen mit Titanium: Teilen Sie die Anzahl der vCPUs durch die Anzahl der vNICs (num_vcpus/num_vnics).
  • Gen 1- und Gen 2-VMs, die Titanium nicht verwenden: Teilen Sie die Anzahl der vCPUs durch die Anzahl der vNICs und teilen Sie das Ergebnis durch 2 (num_vcpus/num_vnics/2).

Entsorgen Sie den Rest.

  1. Bei C4-Instanzen werden für die folgenden Konfigurationen keine Standardberechnungen verwendet, um die Leistung zu verbessern:

    • Bei Linux-Instanzen mit 2 vCPUs ist die Warteschlangenanzahl 1.
    • Bei Linux-Instanzen mit 4 vCPUs ist die Anzahl der Warteschlangen 2.

  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, also 16. Wenn die berechnete Anzahl größer als 16 ist, ignorieren Sie die berechnete Anzahl und weisen Sie stattdessen jeder vNIC 16 Warteschlangen zu.

VM-Instanzen, die die VirtIO-Netzwerkschnittstelle oder einen benutzerdefinierten Treiber verwenden

Teilen Sie die Anzahl der vCPUs durch die Anzahl der vNICs und ignorieren Sie den Restbetrag: [number of vCPUs/number of vNICs].

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

  2. Ermitteln Sie, ob die berechnete Anzahl größer als die maximale Anzahl von Warteschlangen pro vNIC ist, also 32. Wenn die berechnete Anzahl größer als 32 ist, ignorieren Sie die berechnete Anzahl und weisen Sie stattdessen jeder vNIC 16 Warteschlangen zu.

Die folgenden Beispiele zeigen, wie die Standardanzahl der Warteschlangen für eine VM-Instanz berechnet wird:

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

  • Wenn eine VM-Instanz gVNIC verwendet und 128 vCPUs und zwei vNICs hat, ist 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 für VM-Instanzen

Anstelle der standardmäßigen Warteschlangenzuweisung können Sie jeder vNIC eine benutzerdefinierte Anzahl von Warteschlangen (insgesamt RX und TX) zuweisen, wenn Sie eine neue Compute-Instanz 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 einer VM-Instanz 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. Bei den folgenden Konfigurationen von Confidential VMs beträgt die maximale Anzahl der Warteschlangen 8:

      • AMD SEV auf C2D- und N2D-Maschinentypen
      • AMD SEV-SNP auf N2D-Maschinentypen

  • Wenn Sie allen NICs der Compute-Instanzbenutzerdefinierte 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 Instanz zugewiesen sind.

Sie können die Anzahl der benutzerdefinierten Warteschlangen für Ihre vNICs überbelegen. Mit anderen Worten, Sie können eine Summe der Anzahl von Warteschlangen, die allen NICs für Ihre VM-Instanz zugewiesen sind, haben, die größer als die Anzahl der vCPUs für Ihre Instanz ist. Damit die benutzerdefinierte Anzahl der Warteschlangen überschritten werden kann, muss die VM-Instanz die folgenden Bedingungen erfüllen:

  • Verwenden Sie gVNIC als vNIC-Typ für alle NICs, die für die Instanz konfiguriert sind.
  • Es wird ein Maschinentyp verwendet, der das Tier_1-Netzwerk unterstützt.
  • Das Tier_1-Netzwerk ist aktiviert.
  • Sie haben eine benutzerdefinierte Warteschlangenanzahl für alle NICs angegeben, die für die Instanz konfiguriert sind.

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

Beispiele

  • Wenn eine VM-Instanz 8 vCPUs und 3 NICs hat, ist die maximale Warteschlangenanzahl für die Instanz 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-Instanz 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 oben 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 VM-Instanz 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-Instanz 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 aufgrund der im vorherigen Schritt erläuterten Einschränkung größer als null ist. 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.

Benutzerdefinierte Warteschlangenzahlen konfigurieren

Führen Sie die folgenden Schritte aus, um eine Compute-Instanz zu erstellen, die eine benutzerdefinierte Anzahl von Warteschlangen für eine oder mehrere NICs oder 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 Compute-Instanz zu erstellen. Wiederholen Sie das Flag --network-interface für jede vNIC, die Sie für die Instanz konfigurieren möchten, und fügen Sie die Option queue-count ein.
    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

Ersetzen Sie Folgendes:

  • INSTANCE_NAME: Name der neuen Compute-Instanz
  • ZONE: die Zone, in der die Instanz erstellt wird.
  • MACHINE_TYPE: der Maschinentyp der Instanz. Wenn Sie die Warteschlangenanzahl überbuchen möchten, muss der von Ihnen angegebene Maschinentyp 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 Compute-Instanz mit einer bestimmten Anzahl von Warteschlangen für vNICs. Wiederholen Sie den Parameter --network-interface für jede vNIC, die Sie für die Compute-Instanz 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: Name der neuen Compute-Instanz
  • PROJECT_ID: ID des Projekts, in dem die Instanz erstellt werden soll. Sofern Sie kein freigegebenes VPC-Netzwerk verwenden, muss das angegebene Projekt mit dem Projekt übereinstimmen, 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 GB.
  • DISK_TYPE: der Typ des Laufwerks, der für das Bootlaufwerk verwendet werden soll, z. B. pd-standard.
  • MACHINE_TYPE: der Maschinentyp der Instanz. Wenn Sie die Warteschlangenanzahl überbuchen möchten, muss der von Ihnen angegebene Maschinentyp gVNIC und das Tier_1-Netzwerk unterstützen.
  • ZONE: die Zone, in der die Instanz erstellt wird.
  • 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 mit der Methode instances.insert eine Compute-Instanz mit einer bestimmten Anzahl von Warteschlangen für NICs. Wiederholen Sie die Property 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 Compute-Instanz erstellt werden soll.
    • ZONE: Zone, in der die Compute-Instanz erstellt werden soll
    • VM_NAME: Name der neuen Compute-Instanz
    • MACHINE_TYPE: Vordefinierter oder benutzerdefinierter Maschinentyp für die neue Compute-Instanz. Damit die Warteschlangenanzahl überschritten werden kann, muss der Maschinentyp gVNIC und das Tier_1-Netzwerk unterstützen.
    • 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

Compute-Instanzen werden mit einer standardmäßigen Warteschlangenzuweisung erstellt. Sie können auch jeder virtuellen Netzwerkkarte (vNIC) eine benutzerdefinierte Warteschlangenanzahl zuweisen, wenn Sie eine neue Compute-Instanz mit der Compute Engine API erstellen. Die standardmäßigen oder benutzerdefinierten vNIC-Warteschlangenzuweisungen werden nur beim Erstellen einer Compute-Instanz festgelegt. Wenn Ihre Instanz 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 Instanz anhand des neuen Maschinentyps neu berechnet.

Wenn Ihre Compute-Instanz 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 Compute-Instanz dieselbe Warteschlangenanzahl pro vNIC wie die ursprüngliche Instanz unterstützt. Bei Compute-Instanzen, 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 oder höher ändern, da nur gVNIC verwendet wird. Stattdessen können Sie Ihre Compute-Instanz zu einem Maschinentyp der dritten Generation oder höher migrieren. Folgen Sie dazu der Anleitung unter Arbeitslast auf eine neue Compute-Instanz verschieben.

Nächste Schritte