Mehrere Netzwerkschnittstellen

Auf dieser Seite erhalten Sie einen Überblick über mehrere Netzwerkschnittstellen für Compute Engine-Instanzen. Instanzen mit mehreren Netzwerkschnittstellen werden als Instanzen mit mehreren NICs bezeichnet.

Eine Instanznetzwerkschnittstelle wird mit einem VPC-Netzwerk (Virtual Private Cloud) verbunden und kann entweder eine virtuelle Netzwerkschnittstelle (vNIC) oder eine dynamische NIC sein. Eine dynamische NIC ist eine untergeordnete Unterschnittstelle einer übergeordneten vNIC. Die virtuellen NICs 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: Instanzen mit mehreren NICs 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 bestimmten Zweck verwenden. Sie können beispielsweise einige Schnittstellen verwenden, um Pakete zwischen VPC-Netzwerken mit Produktions-Traffic weiterzuleiten, und eine andere Schnittstelle für Verwaltungs- oder Konfigurationszwecke.

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

  • Pakete zwischen VPC-Netzwerken weiterleiten: Instanzen mit mehreren NICs 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, empfiehlt es sich, zwei oder mehr Instanzen mit mehreren NICs zu konfigurieren und sie als Back-Ends für einen internen Passthrough Network Load Balancer in jedem VPC-Netzwerk zu 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 sich vNICs eine physische NIC teilen, wird durch das Hinzufügen von vNICs die Netzwerkbandbreite nicht erhöht.

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

Typen von Netzwerkschnittstellen

In den folgenden Abschnitten finden Sie Details zu den Typen von Netzwerkschnittstellen inGoogle Cloud.

Netzwerkschnittstellen von Instanzen

Compute Engine-Instanzen stellen über Netzwerkschnittstellen, die Sie konfigurieren, eine Verbindung zu VPC-Netzwerken her. Dabei kann es sich entweder um vNICs oder um dynamische NICs handeln. Diese Instanznetzwerkschnittstellen entsprechen der Ressource und dem Attribut instances.networkInterfaces[] in der Compute Engine API.

Weitere Informationen zu den einzelnen Typen von Instanznetzwerkschnittstellen finden Sie unter:

  • 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 vNIC haben.

    • Sie können vNICs nur beim Erstellen einer Instanz konfigurieren.

    • 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 unter Vergleich der Maschinenserien.

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

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

    • Der Name einer von Google Cloud zugewiesenen dynamischen 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-Agent verwenden, um dynamische NICs in Ubuntu zu verwalten, 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.

Dynamic NIC Details

Wenn für Ihren Anwendungsfall einer der folgenden Punkte erforderlich ist, verwenden Sie dynamische NICs. Sehen Sie sich auch die Attribute und Einschränkungen dynamischer NICs an.

  • Sie müssen Netzwerkschnittstellen zu vorhandenen Instanzen hinzufügen oder daraus entfernen. Wenn Sie Dynamic NICs hinzufügen oder entfernen, muss die Instanz nicht neu gestartet oder neu erstellt werden.

  • 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 dynamischer Netzwerkkarten

Weitere Informationen zu den Attributen dynamischer NICs:

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

    • 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 dynamischen 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, 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 mithilfe des Gast-Agents.

    • 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 für die Verwendung verschiedener Empfangs- und Übertragungswarteschlangen konfigurieren möchten, verwenden Sie vNICs anstelle von Dynamic NICs.

  • Der Stack-Typ 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 Netzwerkkarten

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

Physische Netzwerkkarten

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. Für eine bestimmte Instanz werden alle vNICs der Instanz der einzelnen physischen NIC zugeordnet.

  • Instanzen mit mehreren physischen NICs: 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 virtuellen NICs 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 zur Gesamtzahl der physischen NICs des Maschinentyps der Instanz.

    • 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. Ein Beispiel finden Sie unter C4N-Maschinentypen.

Außerdem teilen sich Instanzen bei den meisten Maschinentypen einen Hostserver mit anderen Instanzen. Instanzen, die einen Hostserver gemeinsam nutzen, nutzen auch seine physische NIC oder seine physischen NICs gemeinsam. 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.

    • Jeder Schnittstelle ist ein Stack-Typ zugeordnet, der die unterstützten Subnetz-Stack-Typen und IP-Adressversionen bestimmt. Weitere Informationen finden Sie unter Stack-Typ und IP-Adressen.

  • Anforderungen an Netzwerk und Subnetzwerk: 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 der Subnetze: Bei Instanzen mit mehreren NICs in eigenständigen Projekten muss jede Netzwerkschnittstelle ein Subnetz verwenden, das sich im selben Projekt wie die Instanz befindet.

  • IP-Weiterleitung, MTU und Routing: Multi-NIC-Instanzen erfordern eine sorgfältige Planung der folgenden instanz- und schnittstellenspezifischen Konfigurationsoptionen:

    • Die Option zur 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 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 dasselbe VPC-Netzwerk anhängen: nic0, nic2 und nic3. Das Anhängen der vNICs nic2 und nic3 ist erforderlich, 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, erhöht das Anhängen von zwei oder mehr vNICs an dasselbe VPC-Netzwerk die Netzwerkbandbreite nie.

  • Bei Instanzen, die von mehreren physischen NICs unterstützt werden, wird die Netzwerkbandbreite erhöht, wenn Sie zwei oder mehr vNICs an dasselbe VPC-Netzwerk anhängen und 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 zu IPv6-Adressen.

Stacktyp der Netzwerkschnittstelle ändern

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

  • Sie können eine reine IPv4-Schnittstelle in Dual-Stack 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 für die Eindeutigkeit jeder externen IPv4-Adresse.

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 temporäre 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 der Netzwerkschnittstellen, die Sie an eine Instanz anhängen können, mit der Anzahl der vCPUs, wie in den folgenden Tabellen beschrieben.

Die folgenden Ausnahmen gelten für bestimmte Geräte:

  • Bare-Metal-Instanzen der Compute Engine unterstützen eine einzelne vNIC.

  • Die maximale Anzahl von vNICs ist für einige beschleunigungsoptimierte Maschinentypen wie A3, A4 und A4X unterschiedlich. Weitere Informationen finden Sie unter Beschleunigungsoptimierte Maschinenfamilie.

Maximale Schnittstellennummern

Mithilfe 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 dynamischer Netzwerkkarten Maximale Anzahl von Netzwerkschnittstellen
(vNICs + dynamische NICs)
2 oder weniger 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
22 oder mehr 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 dynamischer Netzwerkkarten 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 dynamischer Netzwerkkarten

Sie müssen dynamische NICs nicht gleichmäßig auf vNICs verteilen. Möglicherweise ist aber eine gleichmäßige Verteilung gewünscht, da sich Dynamic NICs die Bandbreite ihrer übergeordneten vNIC teilen.

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, mit 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 dynamischen 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 dynamischen 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 dynamischen 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 dynamischen 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 dynamischen 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 gilt für die Subnetz- und Projektbeziehung einer Instanz mit mehreren NICs in einem freigegebene VPC-Host- oder -Dienstprojekt Folgendes:

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

  • Jede Netzwerkschnittstelle einer Instanz mit mehreren NICs in einem Dienstprojekt einer freigegebene VPC kann Folgendes verwenden:

    • 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 vom Typ A und PTR-Einträge nur für die primäre interne IPv4-Adresse der nic0-Netzwerkschnittstelle 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 einer Instanz ein Netzwerk-Tag hinzufügen oder ein Netzwerk-Tag aus einer Instanz entfernen, kann sich ändern, welche statischen Routen für eine beliebige Netzwerkschnittstelle 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 über eine Adresse (next-hop-address) angeben, können Pakete an eine bestimmte vNIC oder dynamische NIC in derselben VPC gesendet 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 Instanznetzwerkschnittstellen 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 VPC-Netzwerk, das sie verwendet, genau eine Load-Balancer-Zielschnittstelle, auch wenn sie zwei oder mehr Schnittstellen im selben Netzwerk hat.

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

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

  • Wenn mehrere vNICs ein gemeinsames VPC-Netzwerk mit der nic0-vNIC verwenden, kann nur nic0 Load-Balancing-Traffic 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 vNICs angehängt werden:

  • Kann 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 mit einem eindeutigen VPC-Netzwerk ohne andere Netzwerkschnittstellen verbunden sein (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-Back-Ends 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 des NEG muss sich in derselben Region wie die Zone des 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 für das 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 Ziel-Schnittstelle 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 die NEG befinden und:

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

    • Wenn Sie eine IPv6-Adresse angeben, muss es sich um eine einzelne IPv6-Adresse aus dem /96-IPv6-Adressbereich der Load-Balancer-Zielschnittstelle im Subnetz des NEG handeln.

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

GCE_VM_IP Zonale NEG-Back-Ends 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 des NEG muss sich in derselben Region wie die Zone des 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-Endpunkten gelten die folgenden Regeln für das 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.

  • 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 Lastenausgleich entsprechen einer Weiterleitungsregel des Passthrough-Network Load Balancers.

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 in der Instanzvorlage definierten nic0-vNIC festgelegt.

  • Bei nicht verwalteten Instanzgruppen werden das VPC-Netzwerk und das Subnetz der Instanzgruppe auf das Netzwerk und das Subnetz der nic0-vNIC 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 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-Ziel-Schnittstelle einer Instanz, die einer Instanzgruppe hinzugefügt werden soll: Wenn die Load-Balancer-Ziel-Schnittstelle an ein VPC-Netzwerk angehängt ist, an das auch Load-Balancer-Ziel-Schnittstellen vorhandener Instanzen angehängt sind, müssen sowohl neue als auch vorhandene Load-Balancer-Ziel-Schnittstellen dasselbe Subnetz verwenden.

Firewallregeln

Die Firewallregeln aus hierarchischen Firewallrichtlinien, globalen Netzwerk-Firewallrichtlinien, regionalen Netzwerk-Firewallrichtlinien und VPC-Firewallregeln sind für jede Netzwerkschnittstelle eindeutig. Achten Sie darauf, dass 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 bei der Verwendung mehrerer Netzwerkschnittstellen in Google Cloudbeschrieben.

Fehler bei der Erstellung und geringere Leistung bei Verwendung dynamischer NICs mit GPU-Instanzen

Dynamische NICs werden nicht für die Verwendung mit GPU-Instanzen 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 wird erfolgreich ausgeführt, aber die Leistung der Instanz ist geringer, z. B. ist die Netzwerkbandbreite deutlich niedriger.

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 zugehörige IP-Adresse der Weiterleitungsregel.

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

So beheben Sie das Problem:

  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 die Datei in true und starten Sie den Gast-Agenten neu:

      systemctl restart google-guest-agent

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

    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 dynamischer NICs in 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 nicht installiert werden und dynamische NICs im Gastbetriebssystem Ihrer Instanz nicht verwalten.

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

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

Ursache

Ab Version 20250901.00 wurde der Gast-Agent auf eine neue, auf Plug-ins basierende Architektur migriert, um die Modularität zu verbessern. Die automatische Installation und Verwaltung dynamischer NICs wurde von der neuen Architektur anfangs nicht unterstützt.

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 Bestätigen der Gastagent-Version, die 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 die Gast-Agent-Versionen 20250901.00 bis 20251120.01 ausgeführt werden, vorübergehend umgehen, indem Sie der Anleitung 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 mit 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