Mehrere Netzwerkschnittstellen

Auf dieser Seite finden Sie eine Übersicht über mehrere Netzwerkschnittstellen für Compute Engine-Instanzen. Instanzen mit mehreren Netzwerkschnittstellen werden als Instanzen mit mehreren NICs bezeichnet.

Eine Instanznetzwerkschnittstelle stellt eine Verbindung zu einem VPC-Netzwerk (Virtual Private Cloud) her und kann entweder eine virtuelle Netzwerkschnittstelle (vNIC) oder eine dynamische NIC sein. Eine dynamische NIC ist eine untergeordnete Schnittstelle einer übergeordneten vNIC. Die vNICs einer Instanz werden von einer oder mehreren physischen NICs auf dem Hostserver unterstützt, auf dem die Instanz ausgeführt wird. Weitere Informationen finden Sie unter Netzwerkschnittstellentypen.

Anwendungsfälle

Instanzen mit mehreren NICs sind in folgenden Szenarien nützlich:

  • Verbindung zu Ressourcen in separaten VPC-Netzwerken herstellen: Multi-NIC-Instanzen können eine Verbindung zu Ressourcen in verschiedenen VPC-Netzwerken herstellen, die nicht über VPC-Netzwerk-Peering oder NCC miteinander verbunden sind.

    • Da sich jede Schnittstelle einer Instanz mit mehreren NICs in einem separaten VPC-Netzwerk befindet, können Sie jede Schnittstelle für einen eindeutigen Zweck verwenden. Sie können beispielsweise einige Schnittstellen verwenden, um Pakete zwischen VPC-Netzwerken mit Produktionstraffic weiterzuleiten, und eine andere Schnittstelle für Verwaltungs- oder Konfigurationszwecke.

    • Im Gastbetriebssystem jeder Instanz mit mehreren NICs müssen Sie Routenrichtlinien und lokale Routentabellen konfigurieren.

  • Pakete zwischen VPC-Netzwerken weiterleiten: Multi-NIC-Instanzen können als nächste Hops für Routen verwendet werden, um zwei oder mehr VPC-Netzwerke zu verbinden.

    • Software, die im Gastbetriebssystem einer Multi-NIC-Instanz ausgeführt wird, kann Paketprüfung, NAT (Network Address Translation) oder eine andere Netzwerksicherheitsfunktion ausführen.

    • Wenn Sie VPC-Netzwerke über Instanzen mit mehreren NICs verbinden, sollten Sie zwei oder mehr Instanzen mit mehreren NICs konfigurieren und diese als Backends für einen internen Passthrough-Network-Load-Balancer in jedem VPC-Netzwerk verwenden. Weitere Informationen finden Sie in der Dokumentation zu internen Passthrough Network Load Balancern als nächste Hops unter Anwendungsfälle.

  • Gesamtnetzwerkbandbreite einer Instanz erhöhen: Multi-NIC-Instanzen unterstützen eine erhöhte Bandbreite so:

    • Bei einigen Maschinentypen in Google Cloudwerden Instanzen von mehreren physischen NICs auf dem Hostserver unterstützt. Wenn Sie eine Instanz mit mehreren vNICs erstellen, wobei jede vNIC eine andere physische NIC verwendet, erhöht sich die gesamte Netzwerkbandbreite der Instanz. Weitere Informationen finden Sie unter Bandbreite für mehrere Netzwerkschnittstellen im selben VPC-Netzwerk.

    • Bei den meisten Maschinentypen in Google Cloudwerden Instanzen von einer einzelnen physischen NIC auf dem Hostserver unterstützt und jede vNIC verwendet dieselbe physische NIC. Wenn vNICs eine physische NIC gemeinsam nutzen, wird die Netzwerkbandbreite durch das Hinzufügen von vNICs nicht erhöht.

Sie können auch Multi-NIC-Instanzen mit Private Service Connect-Schnittstellen verwenden, um Dienstersteller- und Dienstnutzernetzwerke in verschiedenen Projekten zu verbinden.

Netzwerkschnittstellentypen

Weitere Informationen zu den Netzwerkschnittstellentypen inGoogle Cloudfinden Sie in den folgenden Abschnitten.

Instanznetzwerkschnittstellen

Compute Engine-Instanzen stellen über von Ihnen konfigurierte Netzwerkschnittstellen eine Verbindung zu VPC-Netzwerken her. Diese können entweder vNICs oder dynamische NICs sein. Diese Instanz-Netzwerkschnittstellen entsprechen der Ressource und dem Attribut instances.networkInterfaces[] in der Compute Engine API.

Weitere Informationen zu den einzelnen Typen von Instanz-Netzwerkschnittstellen finden Sie hier:

  • Virtuelle Netzwerkschnittstelle (vNIC): Eine softwaredefinierte Netzwerkschnittstelle, die für das Gastbetriebssystem Ihrer Instanz verfügbar gemacht wird und mit der Ihre Instanz eine Verbindung zu VPC-Netzwerken herstellen kann. Jede Instanz muss mindestens eine virtuelle Netzwerkkarte haben.

    • vNICs können nur beim Erstellen einer Instanz konfiguriert werden.

    • Der Name einer von Google Cloud zugewiesenen vNIC hat das folgende Format: nicN, z. B. nic0. Der entsprechende vom Gastbetriebssystem zugewiesene Name hängt vom Betriebssystem ab, z. B. ens4 für Ubuntu.

    • Eine vNIC kann je nach zugehörigem VPC-Netzwerk einen der folgenden Typen haben. Jeder Typ entspricht einem bestimmten Netzwerktreiber im Gastbetriebssystem:

      Informationen dazu, welche Maschinentypen welche vNIC-Typen unterstützen, finden Sie im Vergleich der Maschinenserien.

  • Dynamic NIC: Ein untergeordnetes Element einer übergeordneten vNIC, das als Subschnittstelle im Gastbetriebssystem Ihrer Instanz implementiert ist.

    • Sie können dynamische NICs beim Erstellen einer Instanz konfigurieren oder später hinzufügen.

    • Der Name einer von Google Cloud zugewiesenen Dynamic NIC hat das folgende Format: nicN.VLAN_ID, z. B. nic0.2. Der entsprechende vom Gastbetriebssystem zugewiesene Name hängt vom Betriebssystem ab. Wenn Sie beispielsweise den Gast-Agenten zum Verwalten dynamischer NICs in Ubuntu verwenden, lautet der Name möglicherweise a-gcp.ens4.2.

    • Dynamische NICs werden in VPC-Netzwerken mit einem RDMA-Netzwerkprofil nicht unterstützt.

    Weitere Informationen finden Sie unter Dynamische NICs.

Details zur Dynamic NIC

Wenn Ihr Anwendungsfall eine der folgenden Anforderungen hat, verwenden Sie dynamische NICs. Sehen Sie sich auch die Attribute und Einschränkungen von dynamischen NICs an.

  • Sie müssen Netzwerkschnittstellen zu vorhandenen Instanzen hinzufügen oder daraus entfernen. Wenn Sie dynamische NICs hinzufügen oder entfernen, müssen Sie die Instanz nicht neu starten oder neu erstellen.

  • Sie benötigen mehr Netzwerkschnittstellen als die maximale Anzahl von vNICs. Bei den meisten Maschinentypen in Google Cloudbeträgt die maximale Anzahl 10. Mit dynamischen NICs können Sie jedoch bis zu 16 Schnittstellen konfigurieren. Weitere Informationen finden Sie unter Maximale Anzahl von Netzwerkschnittstellen.

  • Sie müssen Compute Engine-Bare-Metal-Instanzen mit mehreren NICs konfigurieren, die nur eine vNIC haben.

Eigenschaften von Dynamic NICs

Im Folgenden finden Sie Informationen zu den Attributen dynamischer NICs:

  • Dynamische NICs sind VLAN-Schnittstellen, die das Paketformat des IEEE 802.1Q-Standards verwenden. Beachten Sie Folgendes:

    • Die VLAN-ID einer Dynamic NIC muss eine Ganzzahl zwischen 2 und 255 sein.
    • Die VLAN-ID einer Dynamic NIC muss innerhalb einer übergeordneten vNIC eindeutig sein. Dynamic NICs, die zu verschiedenen übergeordneten vNICs gehören, können jedoch dieselbe VLAN-ID verwenden.

  • Google Cloud verwendet das folgende Format für den Namen einer Dynamic NIC: nicNUMBER.VLAN_ID, wobei

    • nicNUMBER ist der Name der übergeordneten vNIC, z. B. nic0.
    • VLAN_ID ist die von Ihnen festgelegte VLAN-ID, z. B. 4.

    Ein Beispiel für einen dynamischen NIC-Namen ist nic0.4.

  • Wenn Sie eine Instanz mit Dynamic NICs erstellen oder einer vorhandenen Instanz Dynamic NICs hinzufügen möchten, sind zusätzliche Schritte erforderlich, um die entsprechenden VLAN-Schnittstellen im Gastbetriebssystem zu installieren und zu verwalten. Sie haben dazu folgende Möglichkeiten:

    • Konfigurieren Sie die automatische Verwaltung dynamischer NICs mit dem Gast-Agent.

    • Konfigurieren Sie das Gastbetriebssystem manuell.

    Weitere Informationen finden Sie unter Gastbetriebssystem für dynamische NICs konfigurieren.

  • Dynamic NICs teilen sich die Bandbreite ihrer übergeordneten vNIC. Damit keine der Netzwerkschnittstellen die gesamte Bandbreite beansprucht, müssen Sie im Gastbetriebssystem eine anwendungsspezifische Traffic-Richtlinie erstellen, um den Traffic zu priorisieren oder zu verteilen, z. B. mit Linux Traffic Control (TC).

  • Dynamic NICs verwenden dieselben Empfangs- und Übertragungswarteschlangen wie ihre übergeordnete vNIC. Wenn Sie eine Netzwerkschnittstelle so konfigurieren möchten, dass sie unterschiedliche Empfangs- und Übertragungswarteschlangen verwendet, verwenden Sie vNICs anstelle von dynamischen NICs.

  • Der Stacktyp einer Dynamic NIC kann mit dem der übergeordneten vNIC identisch sein oder sich davon unterscheiden. Sie können beispielsweise reine IPv6- und Dual-Stack-Dynamic-NICs unter einer übergeordneten reinen IPv4-vNIC erstellen.

Einschränkungen von dynamischen NICs

Beachten Sie die folgenden Einschränkungen für dynamische NICs:

Physische NICs

Eine physische NIC ist die Hardwarekomponente, die direkt auf dem Hostserver installiert ist, auf dem eine Instanz ausgeführt wird. Je nach Maschinentyp Ihrer Instanz werden die vNICs der Instanz wie folgt einer oder mehreren physischen NICs auf einem Hostserver zugeordnet:

  • Instanzen, die von einer physischen NIC unterstützt werden: Bei den meisten Maschinentypen werden Instanzen auf einem Hostserver mit einer einzelnen physischen NIC ausgeführt. Bei einer bestimmten Instanz werden alle vNICs der Instanz der einzelnen physischen NIC zugeordnet.

  • Instanzen, die von mehreren physischen NICs unterstützt werden: Bei einer begrenzten Anzahl von Maschinentypen, z. B. C4N-Maschinentypen und GPU-Maschinentypen, werden Instanzen auf einem Hostserver mit mehreren physischen NICs ausgeführt. Für eine bestimmte Instanz ordnet Compute Engine die vNICs der Instanz verschiedenen physischen NICs zu.

    • Instanzen, die von mehreren physischen NICs unterstützt werden, eignen sich für Anwendungsfälle wie eine höhere Netzwerkbandbreite und die GPU-zu-GPU-Kommunikation über ein RoCE-VPC-Netzwerk. Weitere Informationen finden Sie unter Netzwerkunterstützung für C4N-Instanzen und Netzwerk und GPU-Maschinen.

    • Wenn Sie die Instanz erstellen, ordnet Compute Engine jede vNIC einer eindeutigen physischen NIC zu, bis die Gesamtzahl der physischen NICs des Maschinentyps der Instanz erreicht ist.

    • Informationen zur Unterstützung mehrerer physischer NICs finden Sie in der Dokumentation für die jeweilige Maschinenreihe. Falls zutreffend, enthält die Tabelle der Maschinentypen eine Spalte mit dem Titel Anzahl der physischen NICs. Beispiel: C4N-Maschinentypen.

Außerdem teilen sich Instanzen bei den meisten Maschinentypen einen Hostserver mit anderen Instanzen. Instanzen, die einen Hostserver gemeinsam nutzen, teilen sich auch dessen physische NIC oder physische NICs. Bei einigen Maschinentypen, z. B. Bare-Metal-Maschinentypen oder H3- und H4D-Maschinentypen, belegt eine einzelne Instanz jedoch einen gesamten Hostserver.

Spezifikationen

Für Instanzen mit mehreren Netzwerkschnittstellen gelten die folgenden Spezifikationen:

  • Instanzen und Netzwerkschnittstellen: Jede Instanz hat eine nic0-Schnittstelle. Die maximale Anzahl von Netzwerkschnittstellen variiert je nach Maschinentyp der Instanz.

    • Jede Schnittstelle hat einen zugehörigen Stack-Typ, der die unterstützten Subnetz-Stack-Typen und IP-Adressversionen bestimmt. Weitere Informationen finden Sie unter Stacktyp und IP-Adressen.

  • Netzwerk- und Subnetzanforderungen: Jede Netzwerkschnittstelle muss ein eindeutiges Subnetz in einem VPC-Netzwerk verwenden.

    • Das Anhängen von Netzwerkschnittstellen an Subnetze in verschiedenen VPC-Netzwerken wird unterstützt.

    • Das Anhängen von Netzwerkschnittstellen an verschiedene Subnetze im selben VPC-Netzwerk wird in den folgenden Szenarien unterstützt:

    • Ein VPC-Netzwerk und ein Subnetz müssen vorhanden sein, bevor Sie eine Instanz erstellen können, deren Netzwerkschnittstelle das Netzwerk und das Subnetz verwendet. Weitere Informationen zum Erstellen von Netzwerken und Subnetzen finden Sie unter VPC-Netzwerke erstellen und verwalten.

    • Die Zusammenfassung von Netzwerkschnittstellen mit Link Aggregation wird nicht unterstützt. Weitere Informationen dazu, wie sich mehrere Netzwerkschnittstellen im selben VPC-Netzwerk auf die Bandbreite auswirken, finden Sie unter Bandbreite für mehrere Netzwerkschnittstellen im selben VPC-Netzwerk.

  • Projekt der Instanz und Subnetze: Bei Instanzen mit mehreren NICs in eigenständigen Projekten muss für jede Netzwerkschnittstelle ein Subnetz verwendet werden, das sich im selben Projekt wie die Instanz befindet.

  • IP-Weiterleitung, MTU und Routing: Für Multi-NIC-Instanzen ist eine sorgfältige Planung der folgenden instanz- und schnittstellenspezifischen Konfigurationsoptionen erforderlich:

    • Die Option für die IP-Weiterleitung kann für jede Instanz konfiguriert werden und gilt für alle Netzwerkschnittstellen. Weitere Informationen finden Sie unter IP-Weiterleitung für Instanzen aktivieren.

    • Jede Netzwerkschnittstelle kann eine eindeutige maximale Übertragungseinheit (MTU) verwenden, die der MTU des zugehörigen VPC-Netzwerk entspricht. Weitere Informationen finden Sie unter Maximale Übertragungseinheit.

    • Jede Instanz erhält eine Standardroute über die DHCP-Option 121, wie in RFC 3442 definiert. Die Standardroute ist mit nic0 verknüpft. Sofern nicht manuell anders konfiguriert, wird sämtlicher Traffic, der von der Instanz zu beliebigen Zielen mit Ausnahme eines direkt verbundenen Subnetzes verläuft, über die Standardroute auf nic0 geleitet.

      Auf Linux-Systemen können Sie benutzerdefinierte Regeln und Routen im Gastbetriebssystem mit der Datei /etc/iproute2/rt_tables und den Befehlen ip rule und ip route konfigurieren. Weitere Informationen finden Sie in der Dokumentation zum Gastbetriebssystem. Ein Beispiel dafür finden Sie in der folgenden Anleitung: Routing für eine zusätzliche Schnittstelle konfigurieren.

Regeln für mehrere Netzwerkschnittstellen im selben VPC-Netzwerk

Compute Engine erzwingt alle der folgenden Regeln, wenn zwei oder mehr Netzwerkschnittstellen einer einzelnen Instanz dasselbe VPC-Netzwerk verwenden:

  • Eindeutiges Subnetz: Jede Netzwerkschnittstelle muss an ein eindeutiges Subnetz angehängt werden.

  • Zusätzliche vNICs müssen an das Netzwerk angehängt werden, das nic0 enthält: Zwei oder mehr vNICs können nur dann an dasselbe VPC-Netzwerk angehängt werden, wenn dieses Netzwerk auch die vNIC nic0 enthält. Beispiel: nic0, nic1 und nic2 können an eindeutige Subnetze im selben VPC-Netzwerk angehängt werden. nic1 und nic2 können jedoch nicht an dasselbe VPC-Netzwerk angehängt werden, wenn nic0 nicht an dieses Netzwerk angehängt ist.

  • Ein Netzwerk, das eine Dynamic NIC und mindestens eine andere NIC enthält, muss die übergeordnete vNIC jeder Dynamic NIC enthalten. Beispiel:

    • Wenn Sie die dynamischen NICs nic1.6 und nic1.7 an dasselbe VPC-Netzwerk anhängen möchten, müssen Sie auch die übergeordnete vNIC nic1 an dieses VPC-Netzwerk anhängen.

    • Wenn Sie die dynamische NIC nic1.6 und die virtuelle NIC nic2 an dasselbe VPC-Netzwerk anhängen möchten, müssen Sie auch die virtuellen NICs nic1 und nic0 an dieses VPC-Netzwerk anhängen. Das Anhängen von nic1 ist erforderlich, da nic1 die übergeordnete vNIC der Dynamic NIC nic1.6 ist. Das Anhängen von nic0 ist erforderlich, da das Netzwerk mehrere vNICs enthält.

    • Wenn Sie die dynamischen NICs nic2.5 und nic3.6 an dasselbe VPC-Netzwerk anhängen möchten, müssen Sie auch alle folgenden vNICs an dieses VPC-Netzwerk anhängen: nic0, nic2 und nic3. Die vNICs nic2 und nic3 müssen angehängt werden, da sie die übergeordneten vNICs der dynamischen NICs nic2.5 und nic3.6 sind. Das Anhängen von nic0 ist erforderlich, da das Netzwerk mehrere vNICs enthält.

  • Eindeutiges Netzwerk für jede Private Service Connect-Schnittstelle: Zwei oder mehr Netzwerkschnittstellen können nicht an dasselbe VPC-Netzwerk angehängt werden, wenn eine der Netzwerkschnittstellen einen Netzwerkanhang in diesem Netzwerk verwendet.

Bandbreite für mehrere Netzwerkschnittstellen im selben VPC-Netzwerk

Mehrere vNICs im selben VPC-Netzwerk wirken sich gemäß den folgenden Regeln auf die Netzwerkbandbreite aus:

  • Bei Instanzen, die von einer physischen NIC unterstützt werden, wird die Netzwerkbandbreite durch das Anhängen von zwei oder mehr vNICs an dasselbe VPC-Netzwerk nie erhöht.

  • Bei Instanzen, die von mehreren physischen NICs unterstützt werden, erhöht das Anhängen von zwei oder mehr vNICs an dasselbe VPC-Netzwerk die Netzwerkbandbreite, wenn Compute Engine die vNICs verschiedenen physischen NICs zuordnet.

Unabhängig vom Maschinentyp erhöht das Hinzufügen von Dynamic NICs zu einer Instanz die Bandbreite nicht, da eine Dynamic NIC die Bandbreite ihrer übergeordneten vNIC verwendet.

Stacktypen und IP-Adressen

Wenn Sie eine Netzwerkschnittstelle erstellen, geben Sie einen der folgenden Schnittstellen-Stack-Typen an:

  • Nur IPv4
  • Dual-Stack
  • Nur IPv6

Eine VM-Instanz kann Netzwerkschnittstellen mit unterschiedlichen Stacktypen haben.

In der folgenden Tabelle werden die unterstützten Subnetz-Stack-Typen und IP-Adressdetails für jeden Schnittstellen-Stack-Typ beschrieben:

Schnittstelle Nur-IPv4-Subnetz Dual-Stack-Subnetz Nur-IPv6-Subnetz Details zu IP-Adressen
Nur IPv4 (Single-Stack) Nur IPv4-Adressen. Weitere Informationen finden Sie unter Details zur IPv4-Adresse.
IPv4 und IPv6 (Dual-Stack) Sowohl IPv4- als auch IPv6-Adressen. Weitere Informationen finden Sie unter Details zur IPv4-Adresse und Details zur IPv6-Adresse.
Nur IPv6 (Einzelstack) Nur IPv6-Adressen. Weitere Informationen finden Sie unter Details zur IPv6-Adresse.

Stacktyp der Netzwerkschnittstelle ändern

Sie können den Stacktyp einer Netzwerkschnittstelle so ändern:

  • Sie können eine reine IPv4-Schnittstelle in eine Dual-Stack-Schnittstelle umwandeln, wenn das Subnetz der Schnittstelle ein Dual-Stack-Subnetz ist oder wenn Sie die Instanz beenden und die Schnittstelle einem Dual-Stack-Subnetz zuweisen.

  • Sie können eine Dual-Stack-Schnittstelle in eine reine IPv4-Schnittstelle umwandeln.

Sie können den Stacktyp einer reinen IPv6-Schnittstelle nicht ändern. Reine IPv6-Schnittstellen werden nur beim Erstellen von Instanzen unterstützt.

Details zur IPv4-Adresse

Jede reine IPv4- oder Dual-Stack-Netzwerkschnittstelle erhält eine primäre interne IPv4-Adresse. Jede Schnittstelle unterstützt optional Alias-IP-Bereiche und eine externe IPv4-Adresse. Im Folgenden finden Sie die IPv4-Spezifikationen und ‑Anforderungen:

  • Primäre interne IPv4-Adresse: Compute Engine weist der Netzwerkschnittstelle eine primäre interne IPv4-Adresse aus dem primären IPv4-Adressbereich des Subnetzes der Schnittstelle zu. Die primäre interne IPv4-Adresse wird über DHCP zugewiesen.

    • Sie können steuern, welche primäre interne IPv4-Adresse zugewiesen wird, indem Sie eine statische interne IPv4-Adresse konfigurieren oder eine benutzerdefinierte sitzungsspezifische interne IPv4-Adresse angeben.

    • Innerhalb eines VPC-Netzwerk ist die primäre interne IPv4-Adresse jeder VM-Netzwerkschnittstelle eindeutig.

  • Alias-IP-Bereiche: Optional können Sie der Schnittstelle einen oder mehrere Alias-IP-Bereiche zuweisen. Jeder Alias-IP-Bereich kann entweder aus dem primären IPv4-Adressbereich oder einem sekundären IPv4-Adressbereich des Subnetzes der Schnittstelle stammen.

    • In einem VPC-Netzwerk muss der Alias-IP-Bereich jeder Schnittstelle eindeutig sein.

  • Externe IPv4-Adresse: Optional können Sie der Schnittstelle eine sitzungsspezifische oder reservierte externe IPv4-Adresse zuweisen. Google Cloud sorgt dafür, dass jede externe IPv4-Adresse eindeutig ist.

Details zur IPv6-Adresse

Compute Engine weist jeder Dual-Stack- oder Nur-IPv6-Netzwerkschnittstelle einen /96-IPv6-Adressbereich aus dem /64-IPv6-Adressbereich des Subnetzes der Schnittstelle zu:

  • Ob der IPv6-Adressbereich /96 intern oder extern ist, hängt vom IPv6-Zugriffstyp des Subnetzes der Schnittstelle ab. Google Cloud sorgt für die Eindeutigkeit jedes internen und externen IPv6-Adressbereichs. Weitere Informationen finden Sie unter IPv6-Spezifikationen.

    • Wenn eine Instanz sowohl einen internen als auch einen externen IPv6-Adressbereich benötigt, müssen Sie zwei Dual-Stack-Schnittstellen, zwei Nur-IPv6-Schnittstellen oder eine Dual-Stack-Schnittstelle und eine Nur-IPv6-Schnittstelle konfigurieren. Das von einer Schnittstelle verwendete Subnetz muss einen externen IPv6-Adressbereich haben und das von der anderen Schnittstelle verwendete Subnetz muss einen internen IPv6-Adressbereich haben.

  • Die erste IPv6-Adresse (/128) wird auf der Schnittstelle per DHCP konfiguriert. Weitere Informationen finden Sie unter IPv6-Adresszuweisung.

  • Sie können steuern, welcher /96-IPv6-Adressbereich zugewiesen wird, indem Sie einen statischen internen oder externen IPv6-Adressbereich konfigurieren. Für interne IPv6-Adressen können Sie eine benutzerdefinierte sitzungsspezifische interne IPv6-Adresse angeben.

Wenn Sie eine Instanz mit mehreren Netzwerken über IPv6-Adressen verbinden, installieren Sie die google-guest-agent-Version 20220603.00 oder höher. Weitere Informationen finden Sie unter Ich kann keine Verbindung zur IPv6-Adresse einer sekundären Schnittstelle herstellen.

Maximale Anzahl von Netzwerkschnittstellen

Bei den meisten Maschinentypen skaliert die maximale Anzahl von Netzwerkschnittstellen, die Sie an eine Instanz anhängen können, mit der Anzahl der vCPUs, wie in den folgenden Tabellen beschrieben.

Folgende Ausnahmen gelten für bestimmte Maschinen:

  • Die meisten Bare-Metal-Instanzen von Compute Engine unterstützen nur eine einzelne vNIC. Bei Bare-Metal-Maschinentypen wie Z4M werden jedoch mehrere vNICs unterstützt. Informationen zur Anzahl der unterstützten Netzwerkschnittstellen für Z4M-Instanzen finden Sie unter Cloud RDMA-fähige Instanz erstellen.

  • Die maximale Anzahl von vNICs ist bei einigen beschleunigungsoptimierten Maschinentypen wie A3, A4 und A4X unterschiedlich. Weitere Informationen finden Sie unter Beschleunigungsoptimierte Maschinenfamilie.

Maximale Anzahl von Schnittstellen

Anhand der folgenden Tabelle können Sie ermitteln, wie viele Netzwerkschnittstellen an eine Instanz angehängt werden können.

Anzahl von vCPUs Maximale Anzahl von vNICs Maximale Anzahl von dynamischen NICs Maximale Anzahl von Netzwerkschnittstellen
(vNICs + dynamische NICs)
Maximal 2 2 1 2
4 4 3 4
6 6 5 6
8 8 7 8
10 10 9 10
12 10 10 11
14 10 11 12
16 10 12 13
18 10 13 14
20 10 14 15
Mindestens 22 10 15 16

Referenzformeln

In der folgenden Tabelle finden Sie die Formeln, mit denen die maximale Anzahl von Netzwerkschnittstellen für eine Instanz berechnet wird. Die Formel hängt von der Anzahl der vCPUs ab.

Anzahl der vCPUs (X) Maximale Anzahl von vNICs Maximale Anzahl von dynamischen NICs Maximale Anzahl von Netzwerkschnittstellen
(vNICs + dynamische NICs)
X=1 2 1 2
2 ≤ X ≤ 10 X (X-1) X
X ≥ 12 10 min(15, (X-10)/2 + 9) min(16, (X-10)/2 + 10)

Beispielverteilungen von dynamischen NICs

Sie müssen dynamische NICs nicht gleichmäßig auf vNICs verteilen. Möglicherweise möchten Sie jedoch eine gleichmäßige Verteilung, da Dynamic NICs die Bandbreite ihrer übergeordneten vNIC gemeinsam nutzen.

Eine Instanz muss mindestens eine vNIC haben. Eine Instanz mit 2 vCPUs kann beispielsweise eine der folgenden Konfigurationen haben:

  • 1 vNIC
  • 2 vNICs
  • 1 vNIC und 1 Dynamic NIC

Die folgenden Tabellen enthalten Beispielkonfigurationen, bei denen dynamische NICs gleichmäßig auf vNICs verteilt werden, während die maximale Anzahl von Netzwerkschnittstellen für eine bestimmte Anzahl von vCPUs verwendet wird.

2 vCPUs, 2 NICs

Die folgende Tabelle enthält Beispiele für eine Instanz mit 2 vCPUs, die zeigen, wie viele dynamische NICs Sie für eine bestimmte Anzahl von vNICs haben können.

Anzahl von vCPUs Anzahl der vNICs Anzahl der Dynamic NICs pro vNIC Gesamtzahl der Netzwerkschnittstellen (vNICs + dynamische NICs)
2 1 1 2
2 0

4 vCPUs, 4 NICs

Die folgende Tabelle enthält Beispiele für eine Instanz mit 4 vCPUs, die zeigen, wie viele dynamische NICs Sie für eine bestimmte Anzahl von vNICs haben können.

Anzahl von vCPUs Anzahl der vNICs Anzahl der Dynamic NICs pro vNIC Gesamtzahl der Netzwerkschnittstellen (vNICs + dynamische NICs)
4 1 3 4
2 1
4 0

8 vCPUs, 8 NICs

Die folgende Tabelle enthält Beispiele für eine Instanz mit 8 vCPUs, die zeigen, wie viele dynamische NICs Sie für eine bestimmte Anzahl von vNICs haben können.

Anzahl von vCPUs Anzahl der vNICs Anzahl der Dynamic NICs pro vNIC Gesamtzahl der Netzwerkschnittstellen (vNICs + dynamische NICs)
8 1 7 8
2 3
4 1
8 0

14 vCPUs, 12 NICs

Die folgende Tabelle enthält Beispiele für eine Instanz mit 12 vCPUs, die zeigen, wie viele dynamische NICs Sie für eine bestimmte Anzahl von vNICs haben können.

Anzahl von vCPUs Anzahl der vNICs Anzahl der Dynamic NICs pro vNIC Gesamtzahl der Netzwerkschnittstellen (vNICs + dynamische NICs)
14 1 11 12
2 5
4 2
6 1

22 vCPUs, 16 NICs

Die folgende Tabelle enthält Beispiele für eine Instanz mit 22 vCPUs, die zeigen, wie viele dynamische NICs Sie für eine bestimmte Anzahl von vNICs haben können.

Anzahl von vCPUs Anzahl der vNICs Anzahl der Dynamic NICs pro vNIC Gesamtzahl der Netzwerkschnittstellen (vNICs + dynamische NICs)
22 1 15 16
2 7
4 3
8 1

Produktinteraktionen

In diesem Abschnitt werden Interaktionen zwischen Multi-NIC-Instanzen und anderen Produkten und Funktionen in Google Cloudbeschrieben.

Gemeinsam genutzte VPC

Mit Ausnahme von Private Service Connect-Schnittstellen ist die Subnetz- und Projektbeziehung einer Instanz mit mehreren NICs in einem Host- oder Dienstprojekt einer freigegebene VPC so:

  • Jede Netzwerkschnittstelle einer Multi-NIC-Instanz in einem Hostprojekt mit freigegebene VPC muss ein Subnetz eines freigegebene VPC-Netzwerks im Hostprojekt verwenden.

  • Für jede Netzwerkschnittstelle einer Instanz mit mehreren NICs in einem Dienstprojekt einer freigegebene VPC kann eine der folgenden Optionen verwendet werden:

    • Ein Subnetz eines VPC-Netzwerk im Dienstprojekt.
    • Ein Subnetz eines freigegebene VPC-Netzwerks im Hostprojekt.

Weitere Informationen zur freigegebene VPC finden Sie unter:

Internes DNS von Compute Engine

Compute Engine erstellt interne DNS-Namen-A- und PTR-Einträge nur für die primäre interne IPv4-Adresse der Netzwerkschnittstelle nic0 einer Instanz. Compute Engine erstellt keine internen DNS-Einträge für IPv4- oder IPv6-Adressen, die einer Netzwerkschnittstelle zugewiesen sind, die sich von nic0 unterscheidet.

Weitere Informationen finden Sie unter Internes DNS von Compute Engine.

Statische Routen

Statische Routen können mithilfe von Netzwerk-Tags auf bestimmte Instanzen beschränkt werden. Wenn ein Netzwerk-Tag mit einer Instanz verknüpft ist, gilt das Tag für alle Netzwerkschnittstellen der Instanz. Wenn Sie also ein Netzwerk-Tag zu einer Instanz hinzufügen oder daraus entfernen, kann sich dadurch ändern, welche statischen Routen für alle Netzwerkschnittstellen der Instanz gelten.

Wenn Sie eine statische Route erstellen, deren nächster Hop eine Instanz ist, gilt Folgendes:

  • Wenn Sie eine Next-Hop-Instanz nach Name und Zone angeben (next-hop-instance), werden Pakete nur an die nic0-vNIC der Instanz gesendet. Die nic0-vNIC muss an dasselbe VPC-Netzwerk angehängt sein, in dem die statische Route erstellt wird.

  • Wenn Sie eine Next-Hop-Instanz nach Adresse (next-hop-address) angeben, können Pakete an eine bestimmte vNIC oder dynamische NIC in derselben VPC zugestellt werden, in der die statische Route erstellt wird.

Weitere Informationen finden Sie unter Next-Hops und Funktionen.

Load Balancer

In der folgenden Tabelle wird beschrieben, welche Netzwerkschnittstellen von Instanzen die erforderlichen Bedingungen für den Empfang von Load-Balancing-Traffic erfüllen. Dies umfasst auch Situationen, in denen mehrere Schnittstellen gemäß den Regeln für mehrere Netzwerkschnittstellen im selben VPC-Netzwerk an dasselbe VPC-Netzwerk angehängt sind. Eine Netzwerkschnittstelle, die die erforderlichen Load-Balancer-Bedingungen erfüllt, ist eine Load-Balancer-Zielschnittstelle. Eine Instanz hat in jedem verwendeten VPC-Netzwerk genau eine Load-Balancer-Zielschnittstelle, auch wenn sie zwei oder mehr Schnittstellen im selben Netzwerk hat.

Schnittstelle Bedingungen für den Empfang von Load-Balancing-Traffic
nic0 vNIC

Kann mit oder ohne andere Netzwerkschnittstellen an ein VPC-Netzwerk angehängt werden:

  • Wenn mehrere vNICs ein gemeinsames VPC-Netzwerk mit der vNIC nic0 teilen, kann nur nic0 Traffic mit Load Balancing empfangen.
  • Wenn sich eine oder mehrere Dynamic NICs ein gemeinsames VPC-Netzwerk mit der nic0-vNIC teilen, kann nur nic0 Load-Balancing-Traffic empfangen.
Nicht-nic0-vNIC

Muss an ein VPC-Netzwerk ohne andere virtuelle Netzwerkkarten angehängt werden:

  • Kann eigenständig an ein VPC-Netzwerk angehängt werden.
  • Wenn sich eine oder mehrere Dynamic NICs ein gemeinsames VPC-Netzwerk mit einer übergeordneten vNIC teilen, kann nur die übergeordnete vNIC Load-Balancing-Traffic empfangen.
Dynamic NIC

Muss an ein eindeutiges VPC-Netzwerk ohne andere Netzwerkschnittstellen angehängt werden (keine anderen vNICs und keine anderen dynamischen NICs).

In den folgenden Tabellen werden die Load-Balancer- und Backend-Gruppenkonfigurationen beschrieben, mit denen Sie Traffic an eine Load-Balancer-Zielschnittstelle senden können.

Load-Balancer-Zielschnittstellen für Application Load Balancer und Proxy-Network Load Balancer

Typ der Backend-Gruppe
für einen Backend-Dienst eines Application Load Balancers
oder Proxy-Network Load Balancers		 Load-Balancer-Zielschnittstelle
nic0 vNIC Nicht-nic0-vNIC Dynamic NIC
Instanzgruppe
GCE_VM_IP_PORT NEG

Load-Balancer-Zielschnittstellen für Passthrough-Network-Load-Balancer

Für interne Passthrough-Network Load Balancer:

Typ der Backend-Gruppe
für einen Backend-Dienst eines internen Passthrough-Network Load Balancers		 Load-Balancer-Zielschnittstelle
nic0 vNIC Nicht-nic0-vNIC Dynamic NIC
Instanzgruppe
GCE_VM_IP NEG

Für externe Passthrough-Network Load Balancer:

Typ des Backends
eines externen Passthrough-Network Load Balancers		 Load-Balancer-Zielschnittstelle
nic0 vNIC Nicht-nic0-vNIC Dynamic NIC
Instanzgruppe
in einem Backend-Dienst eines Backend-Dienst-basierten regionalen externen Passthrough-Network Load Balancers oder globalen externen Passthrough-Network Load Balancers
GCE_VM_IP NEG
in einem Backend-Dienst eines Backend-Dienst-basierten regionalen externen Passthrough-Network-Load-Balancers oder globalen externen Passthrough-Network-Load-Balancers
Zielpool
eines zielpoolbasierten regionalen externen Passthrough-Network Load Balancers

GCE_VM_IP_PORT zonale NEG-Backends und Netzwerkschnittstellen

Wenn Sie eine neue zonale NEG mit GCE_VM_IP_PORT-Endpunkten erstellen, geben Sie eine Zone, einen Standardport, ein VPC-Netzwerk und ein Subnetz in diesem Netzwerk an. Keines dieser Attribute kann nach dem Erstellen der zonalen NEG geändert werden.

Das Subnetz der NEG muss sich in derselben Region wie die Zone der NEG befinden. Wenn das Netzwerk der NEG ein VPC-Netzwerk im automatischen Modus ist, können Sie das Subnetz der NEG weglassen. Wenn Sie kein Subnetz angeben, Google Cloud wird das Subnetz der NEG auf das automatisch erstellte Subnetz in der Region festgelegt, die die Zone der NEG enthält.

Für zonale NEGs mit GCE_VM_IP_PORT-Endpunkten gelten die folgenden Regeln zum Hinzufügen von Endpunkten:

  • Wenn Sie für den Endpunkt nur einen Instanznamen angeben, muss sich die Instanz in derselben Zone wie die NEG befinden und eine Load-Balancer-Zielschnittstelle im Subnetz der NEG haben. Die IP-Adresse des Endpunkts wird auf die primäre interne IPv4-Adresse der Zielschnittstelle des Load Balancers und der Port des Endpunkts auf den Standardport der NEG festgelegt.

  • Wenn Sie einen Instanznamen und eine IP-Adresse oder einen Instanznamen, eine IP-Adresse und Portinformationen für den Endpunkt angeben, muss sich die Instanz in derselben Zone wie das NEG befinden und:

    • Wenn Sie eine IPv4-Adresse angeben, muss es sich um eine primäre interne IPv4-Adresse oder eine IPv4-Adresse aus einem Alias-IP-Bereich handeln, die mit einer Load-Balancer-Zielschnittstelle im Subnetz des NEG verknüpft ist.

    • Wenn Sie eine IPv6-Adresse angeben: Die IPv6-Adresse muss eine einzelne IPv6-Adresse aus dem IPv6-Adressbereich /96 der Zieloberfläche des Load Balancers im Subnetz der NEG sein.

    • Der Port des Endpunkts ist der von Ihnen angegebene Port. Wenn Sie keinen Port angeben, wird der Port des Endpunkts auf den Standardport der NEG festgelegt.

GCE_VM_IP zonale NEG-Backends und Netzwerkschnittstellen

Wenn Sie eine neue zonale NEG mit GCE_VM_IP-Endpunkten erstellen, geben Sie eine Zone, ein VPC-Netzwerk und ein Subnetz in diesem Netzwerk an. Keines dieser Attribute kann nach dem Erstellen der zonalen NEG geändert werden.

Das Subnetz der NEG muss sich in derselben Region wie die Zone der NEG befinden. Wenn das Netzwerk der NEG ein VPC-Netzwerk im automatischen Modus ist, können Sie das Subnetz der NEG weglassen. Wenn Sie kein Subnetz angeben, legt Google Cloud das Subnetz der NEG auf das automatisch erstellte Subnetz in der Region fest, die die Zone der NEG enthält.

Für zonale NEGs mit GCE_VM_IP-Endpunkten gelten die folgenden Regeln zum Hinzufügen von Endpunkten:

  • Wenn Sie nur einen Instanznamen für den Endpunkt angeben, muss sich die Instanz in derselben Zone wie die NEG befinden und eine Load-Balancer-Zielschnittstelle im Subnetz der NEG haben.

  • Wenn Sie beim Hinzufügen eines Endpunkts sowohl einen Instanznamen als auch eine IP-Adresse angeben, muss sich die Instanz in derselben Zone wie die NEG befinden und die IP-Adresse muss die primäre interne IPv4-Adresse einer Load-Balancer-Zielschnittstelle im Subnetz der NEG sein.

Da eine Instanz nur eine NIC im Subnetz der NEG haben kann, kann sie nur einen GCE_VM_IP-Endpunkt pro zonaler NEG haben. Der Endpunkt wird immer mit der primären internen IPv4-Adresse der Load-Balancer-Zielschnittstelle identifiziert. Die tatsächlichen Ziel-IP-Adressen von Paketen mit Load Balancing entsprechen einer Weiterleitungsregel für Passthrough-Network Load Balancer.

Instanzgruppen-Back-Ends und Netzwerkschnittstellen

Das VPC-Netzwerk und das Subnetz, die mit einer Instanzgruppe verknüpft sind, werden implizit durch eine der folgenden Aktionen festgelegt:

  • Bei verwalteten Instanzgruppen (MIGs) werden das VPC-Netzwerk und das Subnetz der Instanzgruppe auf das Netzwerk und das Subnetz der vNIC nic0 festgelegt, die in der Instanzvorlage definiert ist.

  • Bei nicht verwalteten Instanzgruppen werden das VPC-Netzwerk und das Subnetz der Instanzgruppe auf das Netzwerk und das Subnetz der vNIC nic0 der ersten Instanz festgelegt, die Sie der nicht verwalteten Instanzgruppe hinzufügen. Sie können das VPC-Netzwerk oder das Subnetz der Instanzgruppe später nicht mehr ändern, auch wenn Sie die erste Instanz entfernen, die Sie der Gruppe hinzugefügt haben.

Google Cloud erzwingt die folgenden Regeln, wenn Instanzen zu einer nicht verwalteten Instanzgruppe hinzugefügt werden, nachdem das VPC-Netzwerk und das Subnetz der Instanzgruppe festgelegt wurden:

  • Die nic0-vNIC einer Instanz, die einer Instanzgruppe hinzugefügt werden soll, muss mit dem Netzwerk und Subnetz der Instanzgruppe übereinstimmen. Diese Regel wird erzwungen, da die nic0-vNIC immer eine Load-Balancer-Zielschnittstelle ist.

  • Für jede Load-Balancer-Zielschnittstelle einer Instanz, die einer Instanzgruppe hinzugefügt werden soll: Wenn die Load-Balancer-Zielschnittstelle an ein VPC-Netzwerk angehängt ist, an das Load-Balancer-Zielschnittstellen vorhandener Instanzen angehängt sind, müssen sowohl neue als auch vorhandene Load-Balancer-Zielschnittstellen dasselbe Subnetz verwenden.

Firewallregeln

Die Firewallregeln aus hierarchischen Firewallrichtlinien, globalen Netzwerk-Firewallrichtlinien, regionalen Netzwerk-Firewallrichtlinien und VPC-Firewallregeln sind für jede Netzwerkschnittstelle eindeutig. Prüfen Sie, ob jedes Netzwerk über geeignete Firewallregeln verfügt, um den Traffic zuzulassen, den Sie von und zu einer Multi-NIC-Instanz zulassen möchten. Informationen dazu, welche Firewallregeln für eine Netzwerkschnittstelle gelten und woher die einzelnen Regeln stammen, finden Sie unter Für eine VM-Schnittstelle geltende Firewallregeln abrufen.

Firewallregeln können mithilfe von Netzwerk-Tags oder sicheren Tags auf bestimmte VM-Instanzen beschränkt werden. Beide gelten für alle Netzwerkschnittstellen einer Instanz. Weitere Informationen finden Sie unter Vergleich von sicheren Tags und Netzwerktags.

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme im Zusammenhang mit der Verwendung mehrerer Netzwerkschnittstellen in Google Cloudbeschrieben.

Fehler bei der Erstellung und Leistungseinbußen bei der Verwendung von dynamischen NICs mit GPU-Instanzen

Dynamische NICs werden für die Verwendung mit GPU-Instanzen nicht unterstützt. Wenn Sie eine GPU-Instanz mit dynamischen NICs erstellen oder einer vorhandenen GPU-Instanz dynamische NICs hinzufügen, können die folgenden Probleme auftreten:

  • Der Vorgang schlägt mit einem Fehler wie dem folgenden fehl:

    Internal error. Please try again or contact Google Support. (Code: 'CODE')

  • Der Vorgang ist erfolgreich, aber die Leistung der Instanz ist beeinträchtigt, z. B. durch eine deutlich geringere Netzwerkbandbreite.

Diese Probleme treten auf, weil die dynamische NIC-Konfiguration zu Fehlern führt, wenn Compute Engine versucht, die virtuellen NICs der Instanz auf physische NICs auf dem Hostserver zu verteilen.

Verworfene Pakete bei Verwendung dynamischer NICs mit Alias-IP-Bereichen, Protokollweiterleitung oder Passthrough-Network-Load-Balancern

Der Gast-Agent fügt in den folgenden Szenarien automatisch lokale Routen für vNICs, aber nicht für dynamische NICs hinzu:

  • Wenn Sie einen Alias-IP-Bereich konfigurieren, erstellt der Gast-Agent eine lokale Route für den Alias-IP-Bereich.
  • Wenn Sie eine Zielinstanz erstellen, die auf eine Compute-Instanz für die Protokollweiterleitung verweist, erstellt der Gast-Agent eine lokale Route für die zugehörige IP-Adresse der Weiterleitungsregel.
  • Wenn Sie einem Passthrough-Network-Load-Balancer ein Backend hinzufügen, erstellt der Gast-Agent eine lokale Route für die IP-Adresse der zugehörigen Weiterleitungsregel.

Da die lokalen Routen für dynamische NICs nicht hinzugefügt werden, kann es bei der dynamischen NIC zu Paketverlusten kommen.

So beheben Sie das Problem: Fügen Sie die IP-Adressen manuell hinzu:

  1. Stellen Sie eine SSH-Verbindung zur Instanz her.

  2. Wenn Sie einen Alias-IP-Bereich konfigurieren, gehen Sie so vor. Ansonsten können Sie diesen Schritt überspringen.

    1. Achten Sie in /etc/default/instance_configs.cfg darauf, dass die Einstellung ip_aliases auf true festgelegt ist.

    2. Wenn die Einstellung „ip_aliases“ auf false festgelegt ist, ändern Sie sie in der Datei in true und starten Sie dann den Gast-Agent neu:

      systemctl restart google-guest-agent

  3. Konfigurieren Sie mit dem folgenden Befehl eine lokale Route für den Alias-IP-Bereich oder die IP-Adresse der Weiterleitungsregel:

    ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66

    Ersetzen Sie Folgendes:

    • IP_ADDRESS: Der Alias-IP-Bereich oder die IP-Adresse der Weiterleitungsregel, für die Sie eine lokale Route hinzufügen möchten.
    • DYNAMIC_NIC_DEVICE_NAME: der Gerätename der dynamischen NIC, für die Sie eine lokale Route hinzufügen möchten. Beispiel: a-gcp.ens4.3.

Probleme bei der Installation und Verwaltung von dynamischen NICs in den Gast-Agent-Versionen 20250901.00 bis 20251120.01

Wenn Sie die automatische Verwaltung dynamischer NICs konfigurieren und auf Ihrer Instanz der Gast-Agent in einer Version zwischen 20250901.00 und 20251120.01 ausgeführt wird, können die folgenden Probleme auftreten:

  • Der Gast-Agent kann dynamische NICs im Gastbetriebssystem Ihrer Instanz nicht installieren und verwalten.

    Möglicherweise erhalten Sie einen Fehler, der Cannot find device enthält, wenn Sie im Gastbetriebssystem Befehle ausführen, die auf dynamische NICs verweisen.

  • Wenn Sie mehrere dynamische NICs löschen, ist der Metadatenserver nicht mehr erreichbar.

Ursache

Ab Version 20250901.00 wurde der Gast-Agent auf eine neue Plug-in-basierte Architektur migriert, um die Modularität zu verbessern. Die neue Architektur unterstützte anfangs nicht die automatische Installation und Verwaltung von dynamischen NICs.

Lösung

Aktualisieren Sie Ihre Instanz auf die Gast-Agent-Version 20251205.00 oder höher, um diese Probleme zu beheben:

  1. Informationen zum Aktualisieren des Gast-Agents auf die neueste Version finden Sie unter Gastumgebung aktualisieren.
  2. Informationen zum Prüfen der Version des Gast-Agents, der auf Ihrer Instanz ausgeführt wird, finden Sie unter Installierte Pakete nach Betriebssystemversion aufrufen.

Falls erforderlich, können Sie diese Probleme für Instanzen, auf denen Gast-Agent-Versionen 20250901.00 bis 20251120.01 ausgeführt werden, vorübergehend umgehen, indem Sie den Anweisungen unter Abwärtskompatibilität folgen, um zur vorherigen Gast-Agent-Architektur zurückzukehren.

Dynamische NIC-Vorgänge schlagen fehl, wenn sich eine Compute-Instanz in mehreren Instanzgruppen befindet

Wenn Sie eine dynamische NIC hinzufügen oder löschen und der Vorgang im Status RUNNING bei 0% Fortschritt hängen bleibt und schließlich mit einem INTERNAL_ERROR fehlschlägt, kann das daran liegen, dass sich die Compute-Instanz in mehreren Instanzgruppen (verwaltet oder nicht verwaltet) befindet.

Damit der Vorgang abgeschlossen werden kann, entfernen Sie die Instanz aus allen Instanzgruppen bis auf eine. Sie können eine Instanz aus einer verwalteten Instanzgruppe entfernen oder eine Instanz aus einer nicht verwalteten Instanzgruppe entfernen.

Nächste Schritte