Netzwerkbandbreite

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

Auf dieser Seite werden die Limits für die Netzwerkbandbreite beschrieben, die für die Planung Ihrer Bereitstellungen relevant sind. 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 Instanz von Google Cloud betrachtet:
    • Pakete, die von einer Instanz von Google Cloud gesendet werden, bilden deren ausgehenden Traffic.
    • Pakete, die an eine Instanz von Google Cloud gesendet werden, bilden deren eingehenden Traffic.
  • Routing des Pakets: Ein Paket kann von einer sendenden oder einer empfangenden Instanz mit Routen weitergeleitet werden, deren Next Hops sich innerhalb eines VPC-Netzwerks befinden, oder mit Routen, die sich außerhalb eines VPC-Netzwerks befinden.

Alle Informationen auf dieser Seite gelten sowohl für Compute-Instanzen von Compute Engine als auch für Produkte, die auf Compute Engine-Instanzen basieren. Ein Google Kubernetes Engine-Knoten ist beispielsweise eine Compute Engine-Instanz.

Konfigurationen, die sich auf die Netzwerkbandbreite auswirken

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.

In den folgenden Abschnitten wird gezeigt, wie sich andere Konfigurationen von Compute-Instanzen auf die Netzwerkbandbreite auswirken.

Tier_1-Netzwerkleistung pro VM verwenden

Wenn Sie die maximal mögliche Bandbreite für eingehenden und ausgehenden Traffic erreichen möchten, konfigurieren Sie Tier_1-Netzwerke für Ihre Compute-Instanz.

Dynamic Network Interfaces

Dynamic Network Interfaces verwenden die Bandbreite ihrer übergeordneten vNIC. Innerhalb einer übergeordneten vNIC gibt es keine Traffic-Isolierung. Netzwerktraffic von einer Dynamic NIC kann die anderen Dynamic NICs, die mit derselben übergeordneten vNIC verknüpft sind, beeinträchtigen. Zur Vermeidung dieses Konflikts erstellen Sie mit der Linux-TC-Funktion (Traffic Control) anwendungsspezifische Richtlinien für die Regelung des Traffics. Mit diesen Richtlinien lässt sich entweder Fairness oder eine bestimmte Art von Priorität implementieren. Für die Priorisierung ordnen Sie Traffic (z. B. für Dynamic NICs) einer Traffic-Klasse und diese Traffic-Klasse dann einer Dienstqualität zu. Ein Beispiel für diesen Ansatz finden Sie unter Traffic-Regelung mit Red Hat.

Dynamic NICs werden für Compute Engine-Instanzen, auf denen ein Windows-Betriebssystem ausgeführt wird, nicht unterstützt.

HPC-Computing mit RDMA

Bandbreite ist für alle drei Phasen eines HPC-Jobs (Hochleistungs-Computing) erforderlich: Laden, Computing und Speichern. Während der Lade- und Speicherphasen verwenden Anwendungen in der Regel TCP für die Kommunikation und für die Computing-Phasen RDMA (Remote Direct Memory Address). H4D-Instanzen, die GVNIC für den TCP-Traffic verwenden, bieten bis zu 200 Gbit/s Netzwerkbandbreite. Wenn Sie auch eine H4D-Instanz für die Verwendung von Cloud RDMA konfigurieren, wird die Netzwerkbandbreite auf die konfigurierten RDMA-Netzwerkschnittstellen aufgeteilt.

Die Zuweisung der Netzwerkbandbreite zwischen Cloud RDMA-Traffic und TCP-Traffic erfolgt dynamisch. Anstelle einer Beschränkung von sowohl Cloud RDMA- als auch von TCP-Traffic auf jeweils 100 Gbit/s Bandbreite kann die GVNIC-Netzwerkschnittstelle die gesamte verfügbare Bandbreite nutzen, wenn die RDMA-Netzwerkschnittstelle nicht verwendet wird. Entsprechend kann die RDMA-Netzwerkschnittstelle die gesamte verfügbare Bandbreite nutzen, wenn die GVNIC-Netzwerkschnittstelle nicht verwendet wird. Wenn beide Typen von Netzwerkschnittstellen verwendet werden, hat der RDMA-Traffic Vorrang vor TCP-Traffic, da er leistungsempfindlicher ist.

Zusammenfassung zur Bandbreite

In der folgenden Tabelle wird die maximal mögliche Bandbreite beschrieben, je nachdem, ob ein Paket von einer Compute-Instanz gesendet (ausgehendem Traffic) oder von einer Compute-Instanz empfangen (eingehender Traffic) wird.

Limits für die Bandbreite von ausgehendem Traffic

Routing innerhalb
eines VPC-Netzwerks

  • In erster Linie werden die Limits 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-, C2D-, M3- und C4A-VMs mit Tier_1-Netzwerk unterstützen Bandbreitenlimits für ausgehenden Traffic von bis zu 100 Gbit/s.
    • H3-VMs unterstützen VM-zu-VM-Bandbreitenlimits für ausgehenden Traffic bis zu 200 Gbit/s.
    • H4D-Instanzen (Vorschau) unterstützen eine VM-zu-VM-Bandbreite für ausgehenden Traffic von bis zu 200 Gbit/s für RDMA und gVNIC gemeinsam.
    • X4-, M4-, A2- und G2-Instanzen unterstützen Bandbreitenlimits für ausgehenden Traffic von bis zu 100 Gbit/s.
    • G4-Instanzen unterstützen Bandbreitenlimits für ausgehenden Traffic von bis zu 400 Gbit/s.
    • A4X-Instanzen unterstützen Bandbreitenlimits für ausgehenden Traffic von bis zu 2.000 Gbit/s.
    • A4- und A3-Instanzen unterstützen Bandbreitenlimits für ausgehenden Traffic von bis zu 3.600 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, die innerhalb eines VPC-Netzwerks routingfähig sind.
Routing außerhalb
eines VPC-Netzwerks

  • In erster Linie werden die Limits 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 sind für den maximal möglichen ausgehenden Traffic einer Instanz an ein Ziel außerhalb ihres VPC-Netzwerks folgende Werte die Obergrenze:

    • 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 Vorsichtsmaßnahmen finden Sie unter Ausgehender Traffic zu Zielen außerhalb eines VPC-Netzwerks.

Bandbreitenlimits für eingehenden Traffic

Routing innerhalb
eines VPC-Netzwerks
  • In der Regel entsprechen die Raten für eingehenden Traffic den Raten für ausgehenden Traffic für einen Maschinentyp.
  • Um die maximal mögliche Bandbreite für eingehenden Traffic zu erreichen, aktivieren Sie das Tier_1-Netzwerk.
  • Der eingehende Traffic wird beeinflusst von Faktoren wie die Größe Ihrer Compute-Instanz, die Kapazität der Server-NIC, dem Traffic, der auf anderen Gast-VMs auf derselben Hosthardware eingeht, die Netzwerkkonfiguration des Gastbetriebssystems und die Anzahl der von Ihrer Instanz ausgeführten Laufwerk-Lesevorgänge.
  • FürGoogle Cloud gelten keine zusätzlichen Einschränkungen für Raten des eingehenden Traffics 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 Beschränkung des eingehenden Traffics, der außerhalb eines VPC-Netzwerks weitergeleitet wird. Das Limit entspricht der zuerst ermittelten Rate der folgenden Raten:

    • 1.800.000 PPS (Pakete pro Sekunde)
    • 30 Gbit/s

  • Bei einer Maschinenreihe, die mehrere physische NICs unterstützt, z. B. A3, ist das Limit die zuerst ermittelte Rate 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 für ausgehenden Traffic

Google Cloud begrenzt die Bandbreite für ausgehenden Traffic ü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 über 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, sowie 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 Maschinenreihe gibt es jedoch 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 weitergeleitet wird.

In der folgenden Tabelle ist die maximale Bandbreite für ausgehenden Traffic für jede Maschinenreihe zusammenfassend dargestellt. Die maximale Bandbreite für ausgehenden Traffic pro Instanz ist für jeden Maschinentyp auf der Seite der entsprechenden Maschinenfamilie aufgeführt (über die Links für jede Maschinenreihe in der Tabelle).

Maximales Limit für ausgehenden Traffic pro Instanz
Maschinenreihe Standard Tier_1-Netzwerk
C4, und C4D 100 Gbit/s 200 Gbit/s
C4A 50 Gbit/s 100 Gbit/s
C3 und C3D 100 Gbit/s 200 Gbit/s
C2 und C2D 32 Gbit/s 100 Gbit/s
E2 16 Gbit/s –
E2 mit gemeinsam genutztem Kern 2 Gbit/s –
H4D und H3 200 Gbit/s –
M4 100 Gbit/s –
M3 32 Gbit/s 100 Gbit/s
M2 32 Gbit/s auf Intel Cascade Lake- oder neueren CPUs
16 Gbit/s auf anderen CPU-Plattformen		 –
M1 32 Gbit/s –
N4 50 Gbit/s –
N2 und N2D 32 Gbit/s 100 Gbit/s
N1 (ohne VMs mit 1 vCPU) 32 Gbit/s auf Intel Skylake- und neueren CPUs
16 Gbit/s auf älteren CPU-Plattformen		 –
N1-Maschinentypen mit 1 vCPU 2 Gbit/s –
N1 mit gemeinsam genutztem Kern (f1-micro und g1-small) 1 Gbit/s –
T2A und T2D 32 Gbit/s –
X4 100 Gbit/s –
Z3 100 Gbit/s 200 Gbit/s

Informationen zur Netzwerkbandbreite für beschleunigungsoptimierte Maschinenreihen finden Sie unter Netzwerk und GPU-Maschinen.

Die maximale Bandbreite für ausgehenden Traffic pro Instanz ist nicht garantiert. Die tatsächliche Bandbreite für ausgehenden Traffic kann sich aufgrund von Faktoren wie in der folgenden (nicht vollständigen) Liste aufgeführt verringern:

  • Verwendung VirtIO anstelle von gVNIC mit Compute-Instanzen, die beide unterstützen
  • Paketgröße
  • Protokollaufwand
  • 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 Schreibvorgänge zu 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 Tier_1-Netzwerkleistung pro VM 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-Aufwand reduzieren und den Nutzlastdatendurchsatz erhöhen.
  • Verwenden Sie die neueste gVNIC-Treiberversion.
  • Verwenden Sie Maschinen der dritten Generation oder höher, die Titanium nutzen, um die Netzwerkverarbeitung von der Host-CPU auszulagern.

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

Aus der Sicht einer sendenden Instanz und für Ziel-IP-Adressen, die über Routen innerhalb eines VPC-Netzwerks zugänglich sind, begrenztGoogle 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 Maximale 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 Next Hop in verschiedenen Regionen befinden, erzwingtGoogle Cloud ein Kontingent basierend auf der Region und dem Projekt der sendenden Instanz und der Region des internen Ziels oder des Next Hops. Weitere Informationen zu diesem Kontingent finden Sie in der Dokumentation zu VPC-Kontingenten und ‑Limits unter Bandbreite für interregionalen ausgehenden Netzwerktraffic (Mbit/s) von Compute-Instanzen.
  • 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 Next Hop weitergeleitet werden kann, wird die Bandbreite für ausgehenden Traffic durch folgende Faktoren begrenzt:

Innerhalb eines VPC-Netzwerks routingfähige Ziele sind alle folgenden Ziele, die jeweils aus der Sicht der sendenden Instanz über eine Route zugänglich sind, deren Next 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 als Next Hop weitergeleitet. Sie finden dazu Informationen unter Ausgehender Traffic zu Zielen außerhalb eines VPC-Netzwerks.)
    • 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 der vNIC einer empfangenden Dual-Stack- oder Nur-IPv6-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 des VPC-Netzwerks weitergeleitet werden, die nicht das nächste Standard-Internetgateway als Next Hop verwenden:
    • Eine IPv6-Adresse aus dem IPv6-Adressbereich /96, die der vNIC einer empfangenden Dual-Stack- oder Nur-IPv6-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:

In der folgenden Liste ist der Traffic vom Senden von Instanzen an interne Ziele von der höchstmöglichen zur niedrigsten Bandbreite aufgeführt:

Ausgehender Traffic zu Zielen außerhalb eines VPC-Netzwerks

Aus der Sicht einer sendenden Instanz und für Ziel-IP-Adressen außerhalb eines VPC-Netzwerks begrenzt Google Cloud den ausgehenden Traffic auf die Rate aus den folgenden Raten, die 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 die kleinere der maximalen Bandbreite für ausgehenden Traffic pro Instanz und eine der folgenden Raten:

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

    Beispiel: Auch wenn eine c3-standard-44-Instanz eine maximale Bandbreite für ausgehenden Traffic von 32 Gbit/s pro VM hat, beträgt die Bandbreite für ausgehenden Traffic von einer c3-standard-44-Instanz pro VM für externe Ziele entweder 25 Gbit/s oder 7 Gbit/s, je nachdem, ob das Tier_1-Netzwerk aktiviert ist.

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

  • 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 wird durch die Bandbreitenkontingente für ausgehenden Internettraffic des Projekts definiert.

Zu den Zielen außerhalb eines VPC-Netzwerks gehören alle folgenden Ziele, auf die eine Route im VPC-Netzwerk der sendenden Instanz zugreifen kann, deren Next 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 externe 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- oder Nur-IPv6-Subnetzen mit externen IPv6-Adressbereichen, die von externen IPv6-Adressen von Dual-Stack- oder Nur-IPv6-Instanzen, der externen Protokollweiterleitung und externen Passthrough-Network Load Balancern verwendet werden. Das Subnetz muss sich in einem separaten, nicht gekoppelten VPC-Netzwerk befinden. Der Ziel-IPv6-Adressbereich muss über eine Route im VPC-Netzwerk der sendenden Instanz zugänglich sein, deren Next Hop das Standard-Internetgateway ist. Wenn sich ein Dual-Stack- oder Nut-IPv6-Subnetz mit einem externen IPv6-Adressbereich im selben VPC-Netzwerk oder in einem Peering-VPC-Netzwerk befindet, erhalten Sie weitere Informationen unter Ausgehender Traffic an Ziele, die innerhalb eines VPC-Netzwerks routingfähig sind.
  • Andere externe Ziele, auf die über eine statische Route im VPC-Netzwerk der sendenden Instanz zugegriffen werden kann, sofern der Next Hop für die Route das Standard-Internetgateway ist.

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

Bandbreite des eingehenden Traffics

Google Cloud verarbeitet die Bandbreite von eingehendem Traffic 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 Next 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 dem NIC einer empfangenden Dual-Stack- oder Nur-IPv6-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 an den internen Passthrough-Network Load Balancer verwendet wird, wobei die empfangende Instanz ein Backend des Load Balancers ist. 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 an 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 an den externen Passthrough-Network Load Balancers 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 empfangende Instanz als Instanz des Next Hop (next-hop-instance oder next-hop-address) verwendet.
  • Eine IP-Adresse im Zielbereich einer benutzerdefinierten statischen Route, die einen internen Passthrough-Network Load Balancer (next-hop-ilb) als Next 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 Bandbreitenbeschränkungen für eingehende Pakete, die an eine empfangende Instanz über Routen außerhalb eines VPC-Netzwerks gesendet werden. Bei Verwendung des Load Balancing werden die Bandbreitenlimits einzeln auf jede empfangende Instanz angewendet.

Bei Maschinenreihen, die mehrere physische NICs nicht unterstützen, gilt die entsprechende Einschränkung der Bandbreite für eingehenden Traffic für alle virtuellen Netzwerkschnittstellen (vNICs). Das Limit entspricht der zuerst ermittelten Rate der folgenden Raten:

  • 1.800.000 Pakete pro Sekunde
  • 30 Gbit/s

Bei Maschinenreihen, die mehrere physische NICs unterstützen, z. B. A3, gilt die Einschränkung der Bandbreite für eingehenden Traffic für jede physische NIC einzeln. Das Limit entspricht der zuerst ermittelten Rate 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- oder Nur-IPv6-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 an 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 an 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.

Mit Jumbo Frames die Netzwerkbandbreite maximieren

Um Jumbo Frames zu empfangen und zu senden, konfigurieren Sie das von Ihren Compute-Instanzen verwendete VPC-Netzwerk entsprechend. Legen Sie für die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) einen höheren Wert fest (bis zu 8.896).

Höhere MTU-Werte steigern 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 Images von Google Cloud enthalten diese Treiber. Weitere Informationen zur Betriebssystemunterstützung für Jumbo Frames finden Sie auf dem Tab Netzwerkfunktionen auf der Seite Details zu Betriebssystemen.

Wenn Sie ein Betriebssystem-Image verwenden, das Jumbo Frames nicht vollständig unterstützt, 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 Verwendung auf nicht unterstützten Betriebssystemen.

Jumbo Frames und GPU-Maschinen

Verwenden Sie für GPU-Maschinentypen die empfohlenen MTU-Einstellungen für Jumbo-Frames. Weitere Informationen finden Sie unter Empfohlene MTU-Einstellungen für Jumbo-Frames.

Empfangs- und Übertragungswarteschlangen

Jeder 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.

  • Receive Queue (RX): Warteschlange für das 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 einen vCPU-Kern angehängt ist, per Interrupt an das Gastbetriebssystem. Wenn die RX-Warteschlange voll und kein Zwischenspeicher für das Speichern eines Pakets verfügbar ist, wird das Paket gelöscht. Dies tritt in der Regel auf, wenn eine Anwendung über Gebühr einen vCPU-Kern nutzt, der ebenfalls mit der ausgewählten Paketwarteschlange verknüpft ist.
  • Transmit Queue (TX): Warteschlange für das Übertragen von Paketen. Wenn das Gastbetriebssystem ein Paket sendet, wird ein Deskriptor zugewiesen und in der TX-Warteschlange platziert. Die NIC verarbeitet dann den Deskriptor und überträgt das Paket.

Standardmäßige Warteschlangenzuweisung

Sofern Sie nicht explizit eine Anzahl an Warteschlangen für NICs zuweisen, können Sie den Algorithmus modellieren, mit dem Google Cloud eine feste Anzahl an 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 an Warteschlangen 16 beträgt.
VM-Instanzen, die die gVNIC Netzwerkschnittstelle nutzen

Bei C4-Instanzen wird für die folgenden Konfigurationen eine feste Anzahl an Warteschlangen verwendet, um die Leistung zu verbessern:

  • Bei Linux-Instanzen mit 2 vCPUs beträgt die Anzahl der Warteschlangen 1.
  • Bei Linux-Instanzen mit 4 vCPUs beträgt die Anzahl der Warteschlangen 2.

Bei den anderen Maschinenreihen hängt die Anzahl der Warteschlangen davon ab, ob für die Maschinenreihe Titanium verwendet wird.

  • Für Instanzen der dritten Generation (außer M3) und neuere Instanzen mit Titanium:

    Teilen Sie die Anzahl der vCPUs durch die Anzahl der vNICs (num_vcpus/num_vnics) und ignorieren Sie den Restwert.

  • Für VMs der ersten und zweiten Generation, die Titanium nicht verwenden:

    Teilen Sie die Anzahl der vCPUs durch die Anzahl der vNICs und teilen Sie dann das Ergebnis durch 2 (num_vcpus/num_vnics/2). Ignorieren Sie den Restwert.

So schließen Sie die Berechnung der Standardanzahl an Warteschlangen ab:

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

  2. Prüfen Sie, ob die berechnete Anzahl größer als die maximale Anzahl an Warteschlangen pro vNIC (16) ist. Wenn die berechnete Anzahl größer als 16 ist, ignorieren Sie diesen Wert 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 Restwert ([number of vCPUs/number of vNICs]).

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

  2. Prüfen Sie, ob die berechnete Anzahl größer als die maximale Anzahl an Warteschlangen pro vNIC (32) ist. Wenn die berechnete Anzahl größer als 32 ist, ignorieren Sie diesen Wert und weisen Sie stattdessen jeder vNIC 32 Warteschlangen zu.

H4D-Instanzen mit RDMA

Bei H4D-Instanzen, die Cloud RDMA verwenden, wird aufgrund der begrenzten Maschinentypen, die für H4D verfügbar sind, auf jedem physischen Host eine einzelne VM-Instanz ausgeführt. Diese Instanz erhält also alle verfügbaren Warteschlangenpaare.

Beispiele

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

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

  • Wenn eine VM-Instanz gVNIC verwendet und 128 vCPUs sowie zwei vNICs hat, lautet die berechnete Anzahl [128/2/2] = 32. Google Cloud weist jeder vNIC die maximal mögliche Anzahl an Warteschlangen pro vNIC zu. Google Cloudweist 16 Warteschlangen pro vNIC zu.

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

Anzahl an Warteschlangen bei Verwendung von Dynamic Network Interface

Wenn Sie Dynamic Network Interfaces mit Ihren Netzwerkschnittstellen verwenden, ändert sich die Anzahl der Warteschlangen nicht. Eine Dynamic NIC verfügt nicht über eigene Empfangs- und Übertragungswarteschlangen, sondern verwendet dieselben Warteschlangen wie die übergeordnete vNIC.

Benutzerdefinierte Warteschlangenzuweisung für VM-Instanzen

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

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

  • Die Mindestanzahl an Warteschlangen, die Sie pro vNIC zuweisen können, muss 1 sein.

  • Die maximale Anzahl an Warteschlangen, die Sie jeder vNIC einer VM-Instanz zuweisen können, ist je nach Treibertyp die niedrigere Anzahl an vCPUs oder die maximale Anzahl an Warteschlangen pro vNIC:

    • Mit VirtIO oder einem benutzerdefinierten Treiber beträgt die maximale Anzahl an Warteschlangen 32.
    • Mit gVNIC beträgt die maximale Anzahl an Warteschlangen 16. Für die folgenden Ausnahmen gilt eine maximale Anzahl von 32 Warteschlangen:
      • A2- oder G2-Instanzen
      • TPU-Instanzen
      • C2-, C2D-, N2- oder N2D-Instanzen mit aktiviertem Tier_1-Netzwerk

    • Bei den folgenden Confidential VM-Konfigurationen beträgt die maximale Anzahl an Warteschlangen 8:

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

  • Wenn Sie allen NICs der Compute-Instanz eine benutzerdefinierte Anzahl an 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 an benutzerdefinierten Warteschlangen für Ihre vNICs überbelegen. Es ist also möglich, dass die Summe der Anzahl an Warteschlangen, die allen NICs für Ihre VM-Instanz zugewiesen sind, größer als die Anzahl der vCPUs für Ihre Instanz ist. Damit die benutzerdefinierte Anzahl der Warteschlangen überbelegt werden kann, muss die VM-Instanz folgende Bedingungen erfüllen:

  • gVNIC wird als vNIC-Typ für alle NICs verwendet, 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 Anzahl an Warteschlangen für alle NICs angegeben, die für die Instanz konfiguriert sind.

Bei einer Warteschlangen-Überbelegung beträgt die maximale Anzahl an Warteschlangen 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 96 (16 * 6) benutzerdefinierte Warteschlangen für Ihre Instanz konfigurieren.

Beispiele

  • Wenn eine VM-Instanz 8 vCPUs und 3 NICs hat, beträgt die maximale Anzahl an Warteschlangen 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 anschließend keine vier Warteschlangen zuweisen, wenn Sie die beiden anderen Zuweisungen der vNIC-Warteschlangen beibehalten, da die Summe der zugewiesenen Warteschlangen die Anzahl der vCPUs nicht überschreiten darf.

  • Wenn Sie eine N2-VM mit 96 vCPUs und 2 vNICs haben, können Sie bei Verwendung des VirtIO-Treibers jeweils bis zu 32 Warteschlangen und bei Verwendung des gVNIC-Treibers bis zu 16 Warteschlangen zuweisen. Wenn Sie Tier_1-Netzwerke für die N2-VM aktivieren, können Sie jeder vNIC bis zu 32 Warteschlangen zuweisen. In diesem Beispiel ist die Summe der zugewiesenen Warteschlangen immer kleiner oder gleich der Anzahl der vCPUs.

Es ist auch möglich, die Anzahl an Warteschlangen nur für einige NICs benutzerdefiniert zuzuweisen und den verbleibenden NICs vonGoogle Cloud Warteschlangen zuweisen zu lassen. Die Anzahl an Warteschlangen, die Sie pro vNIC zuweisen können, unterliegt dabei weiterhin den oben genannten Regeln. Mit diesem Verfahren können Sie die Durchführbarkeit Ihrer Konfiguration modellieren sowie, sofern diese möglich ist, die Anzahl an Warteschlangen, die Google Cloud den verbleibenden vNICs 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 vNICs nic0 fünf Warteschlangen, nic1 sechs Warteschlangen und nic2 vier Warteschlangen zu und lassen Google CloudWarteschlangen für nic3, nic4 und nic5 zuweisen. In diesem Beispiel beträgt die Summe der benutzerdefinierten Anzahl an Warteschlangen 5+6+4 = 15.

  2. Ziehen Sie die Summe der benutzerdefinierten Warteschlangen von der Anzahl der vCPUs ab. Wenn die Differenz kleiner als die Anzahl der verbleibenden vNICs ist, für dieGoogle Cloud Warteschlangen zuweisen muss, wird Google Cloud einen Fehler zurückgegeben, da jede vNIC mindestens eine Warteschlange haben muss.

    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 vNICs (nic3, nic4, nic5) zuweisen kann.

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

  • Wenn Sie VirtIO oder einen benutzerdefinierten Treiber verwenden und die berechnete Anzahl an 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 an Warteschlangen für jede verbleibende vNIC größer als das Limit von 16 oder 32 ist (je nach VM-Konfiguration), weist Google Cloud jeder verbleibenden vNIC 16 Warteschlangen zu.

Benutzerdefinierte Anzahl an Warteschlangen konfigurieren

Wenn Sie eine Compute-Instanz erstellen möchten, die eine benutzerdefinierte Anzahl an Warteschlangen für eine oder mehrere NICs oder vNICs verwendet, führen Sie die folgenden Schritte aus.

In den folgenden Codebeispielen wird die VM mit dem auf GVNIC festgelegten Netzwerkschnittstellentyp erstellt und die Tier_1-Netzwerkleistung pro VM aktiviert. Mit diesen Codebeispielen können Sie die maximale Anzahl an Warteschlangen und die Warteschlangen-Überbelegung für die unterstützten Maschinentypen angeben.

gcloud

  1. Wenn Sie noch kein VPC-Netzwerk mit einem Subnetz für jede vNIC-Schnittstelle haben, die Sie konfigurieren möchten, erstellen Sie es.
  2. Erstellen Sie mit dem Befehl gcloud compute instances create die Compute-Instanz. 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: Zone, in der die Instanz erstellt wird.
  • MACHINE_TYPE: Maschinentyp der Instanz. Damit die Anzahl an Warteschlangen überbelegt werden kann, muss der von Ihnen angegebene Maschinentyp gVNIC und das Tier_1-Netzwerk unterstützen.
  • NETWORK_NAME: Name des zuvor erstellten Netzwerks.
  • SUBNET_*: Name eines der zuvor erstellten Subnetze.
  • QUEUE_SIZE: Anzahl an Warteschlangen für die vNIC, gemäß den unter Benutzerdefinierte Warteschlangenzuweisung dargestellten 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 es.

  2. Erstellen Sie mit der Ressource google_compute_instance eine Compute-Instanz mit einer bestimmten Anzahl an 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 gemeinsam genutztes VPC-Netzwerk verwenden, muss das angegebene Projekt mit dem Projekt übereinstimmen, in dem alle Subnetze und Netzwerke erstellt wurden.
  • DEVICE_NAME: Name, der dem Bootlaufwerk im Gastbetriebssystem zugeordnet werden soll.
  • IMAGE_NAME: Name eines Images, z. B. "projects/debian-cloud/global/images/debian-11-bullseye-v20231010".
  • DISK_SIZE: Größe des Bootlaufwerks in GiB.
  • DISK_TYPE: Typ des Laufwerks, der für das Bootlaufwerk verwendet werden soll, z. B. pd-standard.
  • MACHINE_TYPE: Maschinentyp der Instanz. Damit die Anzahl an Warteschlangen überbelegt werden kann, muss der von Ihnen angegebene Maschinentyp gVNIC und das Tier_1-Netzwerk unterstützen.
  • ZONE: Zone, in der die Instanz erstellt wird.
  • QUEUE_COUNT: Anzahl der Warteschlangen für die vNIC, gemäß den unter Benutzerdefinierte Warteschlangenzuweisung dargestellten Regeln.
  • SUBNET_*: 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 es.

  2. Erstellen Sie mit der Methode instances.insert eine Compute-Instanz mit einer bestimmten Anzahl an Warteschlangen für NICs. Wiederholen Sie das Attribut networkInterfaces, wenn Sie mehrere Netzwerkschnittstellen konfigurieren möchten.

    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 Anzahl an Warteschlangen überbelegt werden kann, muss der Maschinentyp gVNIC und das Tier_1-Netzwerk unterstützen.
    • SUBNET_*: Name des Subnetzes, mit dem die Netzwerkschnittstelle eine Verbindung herstellt.
    • QUEUE_COUNT: Anzahl an Warteschlangen für die vNIC, gemäß den unter Benutzerdefinierte Warteschlangenzuweisung erläuterten Regeln.

Warteschlangenzuweisung und Änderung des Maschinentyps

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

Wenn Ihre VM über vNICs verfügt, die eine benutzerdefinierte, nicht standardmäßige Anzahl an 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 Anzahl an Warteschlangen pro VNIC wie die ursprüngliche Instanz unterstützt. Bei VMs, die die VirtIO-Net-Schnittstelle und eine benutzerdefinierte Anzahl an Warteschlangen verwenden, die größer als 16 pro vNIC ist, können Sie den Maschinentyp nicht in einen Maschinentyp der dritten Generation oder höher ändern, da diese nur gVNIC verwenden. Stattdessen können Sie Ihre VM 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