Mehrere Netzwerkschnittstellen (original) (raw)

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

Eine Instanz hat immer mindestens eine virtuelle Netzwerkschnittstelle (vNIC). Je nach Maschinentyp können Sie zusätzliche Netzwerkschnittstellen konfigurieren.

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

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

Typen von Netzwerkschnittstellen

Google Cloud unterstützt die folgenden Arten von Netzwerkschnittstellen:

• vNICs: Die virtuellen Netzwerkschnittstellen von Compute Engine-Instanzen. Jede Instanz muss mindestens eine vNIC haben. vNICs in regulären VPC-Netzwerken können entweder GVNIC, VIRTIO_NET oder IDPF sein. Sie können vNICs nur beim Erstellen einer Instanz konfigurieren.
• Dynamic NICs: Eine untergeordnete Schnittstelle einer übergeordneten vNIC. Sie können dynamische NICs beim Erstellen einer Instanz konfigurieren oder später hinzufügen. Weitere Informationen finden Sie unter Dynamische NICs.

Sie können auch Multi-NIC-Instanzen mit Maschinentypen konfigurieren, die RDMA-Netzwerkschnittstellen (IRDMA oder MRDMA) enthalten. Diese müssen an ein VPC-Netzwerk mit einem RDMA-Netzwerkprofil angehängt werden. Andere Netzwerkschnittstellentypen, einschließlich dynamischer NICs, werden in VPC-Netzwerken mit einem RDMA-Netzwerkprofil nicht unterstützt.

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 Stacktyp zugeordnet, der die unterstützten Subnetz-Stacktypen 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:
    * Bei regulären VPC-Netzwerken können mehrere Netzwerkschnittstellen dasselbe VPC-Netzwerk wie die nic0-Schnittstelle verwenden. Weitere Informationen finden Sie unter Mehrere Netzwerkschnittstellen im selben VPC-Netzwerk (Vorabversion).
  • Für VPC-Netzwerke, die mit einem RDMA-Netzwerkprofil erstellt wurden, können mehrere RDMA-NICs dasselbe VPC-Netzwerk verwenden. Weitere Informationen finden Sie in der Tabelle für die einzelnen Netzwerkprofile unter Unterstützte und nicht unterstützte Funktionen.
  • 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.
• 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.
  • Informationen zu Instanzen in Host- oder Dienstprojekten einer freigegebenen VPC finden Sie unter Freigegebene VPC.
  • Private Service Connect-Schnittstellen ermöglichen es einer Instanz mit mehreren NICs, Netzwerkschnittstellen in Subnetzen in verschiedenen Projekten zu haben. Weitere Informationen finden Sie unter Netzwerkanhänge.
• IP-Weiterleitung, MTU und Routing: Für Multi-NIC-Instanzen ist eine sorgfältige Planung der folgenden instanz- und schnittstellenspezifischen Konfigurationsoptionen erforderlich:
  • 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.

Mehrere Netzwerkschnittstellen im selben VPC-Netzwerk

Sie können zusätzliche vNICs einer Instanz an dasselbe VPC-Netzwerk wie die nic0-vNIC der Instanz anhängen.

Sie können mehrere vNICs an dasselbe VPC-Netzwerk anhängen, um die Bandbreite einer Instanz im VPC-Netzwerk zu erhöhen:

• Bei einigen Maschinentypen in Google Cloudwerden Instanzen von mehreren physischen NICs auf dem Hostserver unterstützt, z. B. bei einigen GPU-Maschinentypen.
  • Wenn Sie eine Instanz mit mehreren vNICs erstellen, wobei jede vNIC eine andere physische NIC verwendet, erhöht sich die Netzwerkbandbreite der Instanz für das VPC-Netzwerk, an das die vNICs angehängt sind.
  • 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.
• Bei den meisten Maschinentypen in Google Cloudwerden Instanzen von einer physischen NIC unterstützt. Für diese Maschinentypen empfehlen wir, jede vNIC an ein separates VPC-Netzwerk anzuhängen.

Einschränkungen für mehrere Netzwerkschnittstellen im selben VPC-Netzwerk

Beim Anhängen mehrerer Netzwerkschnittstellen einer Instanz an dasselbe VPC-Netzwerk gelten die folgenden Einschränkungen:

• Die zusätzlichen Netzwerkschnittstellen müssen mit demselben Netzwerk verbunden sein wie die nic0-Schnittstelle.
• Wenn Sie zusätzliche Netzwerkbandbreite für die Nicht-nic0-Schnittstellen benötigen, müssen Sie einen Maschinentyp verwenden, der von mehreren physischen NICs unterstützt wird.
• Folgendes wird nicht unterstützt:
  • Dynamische NICs.
  • Private Service Connect-Schnittstellen.
  • Für Cloud Load Balancing können Instanzen mit mehreren vNICs, die mit demselben VPC-Netzwerk verbunden sind, Instanzgruppen- oder zonalen NEG-Back-Ends hinzugefügt werden. Von den vNICs, die an dasselbe VPC-Netzwerk angehängt sind, kann der Traffic jedoch nur an nic0 verteilt werden.
  • Bei statischen Routen können Sie keine Pakete an die Nicht-nic0-Schnittstellen senden, indem Sie eine Next-Hop-Instanz angeben, die durch Name und Zone (next-hop-instance) definiert ist. Verwenden Sie stattdessen eine Next-Hop-Instanz, die durch Adresse (next-hop-address) definiert ist. Weitere Informationen finden Sie unter Nächste Hops und Funktionen.
  • Netzwerkschnittstellen-Bonding mit Link-Aggregation.

Dynamische NICs

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 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. Die maximale Anzahl von vNICs für die meisten Maschinentypen in Google Cloud beträgt 10. Sie können jedoch bis zu 16 Schnittstellen insgesamt konfigurieren, indem Sie dynamische NICs verwenden. 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 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 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 dynamischen NICs erstellen oder einer vorhandenen Instanz dynamische 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 reinen IPv4-übergeordneten vNIC erstellen.

Einschränkungen von Dynamic NICs

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

• Die folgenden Attribute einer dynamischen NIC können nach dem Erstellen nicht mehr geändert werden:
  • Die übergeordnete vNIC, zu der die Dynamic NIC gehört.
  • Die VLAN-ID der Dynamic NIC.
• Das Anhängen mehrerer Netzwerkschnittstellen einer Instanz an dasselbe VPC-Netzwerk wird für dynamische NICs nicht unterstützt.
• Eine Dynamic NIC kann nicht gelöscht werden, wenn sie eine Load-Balancing-Netzwerkschnittstelle ist.
• Dynamic NICs unterstützen Folgendes nicht:
  • Erweiterter DDoS-Schutz für Netzwerke und Sicherheitsrichtlinien für Netzwerk-Edge für Google Cloud Armor
  • Konfigurieren von IP-Adressen mithilfe von instanzspezifischen Konfigurationen für MIGs.
  • Funktionen, die auf das Abfangen von Paketen angewiesen sind, z. B. Firewall-Endpunkte
  • Compute Engine-Windows-Treiber
• Dynamic NICs werden für die Verwendung mit GPU-Instanzen nicht unterstützt. Weitere Informationen finden Sie unter Erstellungsfehler und verringerte Leistung bei Verwendung dynamischer NICs mit GPU-Instanzen.
• Für dynamische NICs müssen Sie in bestimmten Szenarien lokale Routen manuell erstellen. Weitere Informationen finden Sie unter Verworfene Pakete bei Verwendung dynamischer NICs mit Alias-IP-Bereichen, Protokollweiterleitung oder Passthrough-Network-Load-Balancern.

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:

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 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 über 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.

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.

Beispielverteilungen dynamischer NICs

Sie müssen dynamische NICs nicht gleichmäßig auf vNICs verteilen. Möglicherweise ist aber eine gleichmäßige Verteilung sinnvoll, 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.

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.

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.

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.

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.

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:

• Übersicht über gemeinsam genutzte VPCs
• Gemeinsam genutzte VPC bereitstellen

Internes DNS von Compute Engine

Compute Engine erstellt interne DNS-Namens-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 der Netzwerkschnittstellen der Instanz gelten.

Load-Balancer

Instanzgruppen-Back-Ends und zonale NEG-Back-Ends sind jeweils mit einem VPC-Netzwerk verknüpft:

• Bei verwalteten Instanzgruppen ist das VPC-Netzwerk für die Instanzgruppe das VPC-Netzwerk, das der nic0-Schnittstelle in der Instanzvorlage zugewiesen ist.
• Bei nicht verwalteten Instanzgruppen ist das VPC-Netzwerk für die Instanzgruppe das VPC-Netzwerk, das von der Netzwerkschnittstelle nic0 der ersten Instanz verwendet wird, die Sie der nicht verwalteten Instanzgruppe hinzufügen.

In der folgenden Tabelle sehen Sie, welche Back-Ends die Verteilung von Verbindungen oder Anfragen auf eine beliebige Netzwerkschnittstelle unterstützen.

1 In der gesamten Tabelle gilt Beliebige NIC nicht, wenn sich mehrere Netzwerkschnittstellen einer Instanz im selben VPC-Netzwerk befinden (Vorschau). Weitere Informationen finden Sie unter Einschränkungen für mehrere Netzwerkschnittstellen im selben VPC-Netzwerk.

Zielpoolbasierte externe Passthrough-Network Load Balancer verwenden keine Instanzgruppen oder NEGs und unterstützen nur das Load Balancing für nic0-Netzwerkschnittstellen.

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 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 in 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 Gast-Agent-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.

Nächste Schritte

• VMs mit mehreren Netzwerkschnittstellen erstellen