Netzwerkübersicht für VMs

In diesem Dokument erhalten Sie eine Übersicht über die Netzwerkfunktionalität Ihrer VM-Instanzen. Darin erhalten Sie einen grundlegenden Einblick in die Interaktion Ihrer VM-Instanzen mit VPC-Netzwerken (Virtual Private Cloud). Weitere Informationen zu VPC-Netzwerken und den zugehörigen Funktionen finden Sie unter Übersicht zu VPC-Netzwerken.

Netzwerke und Subnetze

Jede VM ist Teil eines VPC-Netzwerk. VPC-Netzwerke bieten Konnektivität für Ihre VM-Instanz zu anderen Google Cloud Produkten und zum Internet. VPC-Netzwerke können im automatischen oder benutzerdefinierten Modus ausgeführt werden.

  • VPC-Netzwerke im automatischen Modus haben in jeder Region ein Subnetzwerk (Subnetz). Alle Subnetze sind in diesem IP-Adressbereich enthalten: 10.128.0.0/9. VPC-Netzwerke im automatischen Modus unterstützen nur IPv4-Subnetzbereiche.
  • Netzwerke im benutzerdefinierten Modus haben keine angegebene Subnetzkonfiguration. Sie entscheiden anhand der von Ihnen angegebenen IP-Bereiche, welche Subnetze in den ausgewählten Regionen erstellt werden sollen. Netzwerke im benutzerdefinierten Modus unterstützen auch IPv6-Subnetzbereiche.

Sofern Sie diese Option nicht deaktivieren, hat jedes Projekt ein default-Netzwerk, bei dem es sich um ein VPC-Netzwerk im automatischen Modus handelt. Sie können die Erstellung von Standardnetzwerken deaktivieren, indem Sie eine Organisationsrichtlinie erstellen.

Jedes Subnetz in einem VPC-Netzwerk ist einer Region zugeordnet und enthält einen oder mehrere IP-Adressbereiche. Sie können mehr als ein Subnetz pro Region erstellen. Jede Netzwerkschnittstelle für Ihre VM muss mit einem Subnetz verbunden sein.

Beim Erstellen einer VM können Sie ein VPC-Netzwerk und ein Subnetz angeben. Wenn Sie diese Konfiguration weglassen, werden das default Netzwerk und das Subnetz verwendet. Google Cloud weist der neuen VM eine interne IPv4-Adresse aus dem primären IPv4-Adressbereich des ausgewählten Subnetzes zu. Wenn das Subnetz auch einen IPv6-Adressbereich hat (als Dual-Stack bezeichnet) oder wenn Sie ein reines IPv6-Subnetz erstellt haben, können Sie der VM eine IPv6-Adresse zuweisen.

Weitere Informationen zu VPC-Netzwerken finden Sie in der Übersicht zu VPC-Netzwerken. Ein Beispiel für VMs, die ein VPC-Netzwerk mit drei Subnetzen in zwei Regionen verwenden, finden Sie unter Beispiel für VPC-Netzwerk.

Netzwerkschnittstellen-Controller (NICs)

Jede Compute-Instanz in einem VPC-Netzwerk hat eine virtuelle Standardnetzwerkschnittstelle (vNIC). Wenn Sie eine vNIC konfigurieren, wählen Sie ein VPC-Netzwerk und ein Subnetz in diesem VPC-Netzwerk aus, mit dem die Schnittstelle verbunden werden soll. Sie können zusätzliche Netzwerkschnittstellen für Ihre Instanzen erstellen.

Mit mehreren Netzwerkschnittstellen sind Konfigurationen möglich, bei denen eine Instanz eine direkte Verbindung zu mehreren VPC-Netzwerken herstellt. Mehrere Netzwerkschnittstellen sind nützlich, wenn für Anwendungen, die in einer Instanz ausgeführt werden, eine Traffic-Trennung erforderlich ist, z. B. die Trennung von Traffic auf Datenebene von Traffic auf Verwaltungsebene. Weitere Informationen zur Verwendung mehrerer Netzwerk schnittstellen finden Sie unter Mehrere Netzwerkschnittstellen.

Mehrere vNICs werden für Bare-Metal-Instanzen nicht unterstützt. Außerdem können Sie vNICs nur während der Instanzerstellung zu einer Instanz hinzufügen. Mit Dynamic Network Interfaces können Sie VLAN-basierte Netzwerk-Subinterfaces für jede bereitgestellte vNIC erstellen. So können Sie die Anzahl der Netzwerkschnittstellen und VPC-Netzwerk verbindungen skalieren. Sie können Dynamic Network Interfaces hinzufügen oder entfernen, ohne die Compute-Instanz neu starten oder neu erstellen zu müssen. Weitere Informationen zu dynamischen NICs finden Sie unter VMs mit mehreren Netzwerkschnittstellen erstellen.

Wenn Sie die vNIC für eine Compute-Instanz konfigurieren, können Sie den Typ des Netzwerktreibers angeben, der mit der Schnittstelle verwendet werden soll.

  • Für Maschinenserien der ersten und zweiten Generation, ist der Standardwert VirtIO.
  • Maschinenserien der dritten Generation und höher sind standardmäßig für die Verwendung von gVNIC konfiguriert und unterstützen VirtIO für die Netzwerkschnittstelle nicht.
  • Bare-Metal-Instanzen verwenden IDPF.
  • Bei unterstützten Maschinenserien wie H4D und Z4M können Compute-Instanzen optional Cloud RDMA (IRDMA)verwenden. Der RDMA-Netzwerktreiber (Remote Direct Memory Access) ermöglicht zuverlässige Messaging-Funktionen mit geringer Latenz für Compute Engine-Instanzen. Cloud RDMA überträgt Daten zwischen Remote-Maschinen und lokalem Arbeitsspeicher über die Netzwerkschnittstelle, ohne die Host-CPU oder Zwischenhostpuffer zu verwenden.

Außerdem können Sie die Netzwerkleistung pro VM-Tier_1 mit einer Compute-Instanz verwenden, die gVNIC oder IPDF verwendet. Tier_1-Netzwerke ermöglichen höhere Grenzwerte für den Netzwerkdurchsatz sowohl für eingehende als auch für ausgehende Daten übertragungen.

Netzwerkbandbreite

Google Cloud berücksichtigt die Bandbreite pro VM-Instanz, nicht pro Netzwerkschnittstelle (NIC) oder IP-Adresse. Die Bandbreite wird mithilfe von zwei Dimensionen gemessen: Traffic-Richtung (eingehender und ausgehender Traffic) und Typ der Ziel-IP-Adresse. Die maximal mögliche Rate für ausgehenden Traffic wird durch den Maschinentyp bestimmt, der zum Erstellen der Instanz verwendet wurde. Diese Rate für ausgehenden Traffic können Sie jedoch nur in bestimmten Situationen erreichen. Weitere Informationen finden Sie unter Netzwerkbandbreite.

Für höhere Netzwerkbandbreiten wie 200 Gbit/s für Maschinenserien der dritten Generation und höher ist Google Virtual NIC (gVNIC) erforderlich.

  • Die standardmäßigen Grenzwerte für die maximale Bandbreite für ausgehenden Traffic reichen von 1 Gbit/s bis 100 Gbit/s.
  • Die Netzwerkleistung pro VM-Tier_1 erhöht den Grenzwert für die maximale Bandbreite für ausgehenden Traffic auf 200 Gbit/s, je nach Größe und Maschinentyp Ihrer Compute-Instanz.

Einige Maschinenserien haben unterschiedliche Grenzwerte, wie in der Tabelle Bandbreitenübersicht dokumentiert.

Wenn Sie sowohl gVNIC- als auch IRDMA-Netzwerkschnittstellen für eine Instanz verwenden, wird der Grenzwert für die Netzwerkbandbreite für die Instanz zwischen den beiden Methoden der Netzwerkkommunikation aufgeteilt. Cloud RDMA-Traffic hat Vorrang vor gVNIC-Traffic.

IP-Adressen

Jeder VM wird eine IP-Adresse aus dem Subnetz zugewiesen, das mit der Netzwerkschnittstelle verknüpft ist. Die folgende Liste enthält weitere Informationen zu den Anforderungen für die Konfiguration von IP-Adressen.

  • Für reine IPv4-Subnetze ist die IP-Adresse eine interne IPv4-Adresse. Optional können Sie eine externe IPv4-Adresse für die VM konfigurieren.
  • Wenn die Netzwerkschnittstelle mit einem Dual-Stack-Subnetz mit einem IPv6-Bereich verbunden ist, müssen Sie ein VPC-Netzwerk im benutzerdefinierten Modus verwenden. Die VM hat die folgenden IP-Adressen:
    • Eine interne IPv4-Adresse. Optional können Sie eine externe IPv4-Adresse für die VM konfigurieren.
    • Je nach Zugriffstyp des Subnetzes entweder eine interne oder eine externe IPv6-Adresse.
  • Für reine IPv6-Subnetze müssen Sie ein VPC-Netzwerk im benutzerdefinierten Modus verwenden. Die VM hat je nach Zugriffstyp des Subnetzes entweder eine interne oder eine externe IPv6-Adresse.
  • Wenn Sie eine reine IPv6-Instanz mit einer internen und einer externen IPv6-Adresse erstellen möchten, müssen Sie beim Erstellen der VM zwei Netzwerkschnittstellen angeben. Sie können einer vorhandenen Instanz keine Netzwerkschnittstellen hinzufügen.

Sowohl externe als auch interne IP-Adressen können entweder sitzungsspezifisch oder statisch sein.

Interne IP-Adressen sind lokal in einem der folgenden Netzwerke:

  • VPC-Netzwerk
  • VPC-Netzwerk, das über VPC-Netzwerk-Peering verbunden ist
  • Lokales Netzwerk, das über Cloud VPN, Cloud Interconnect oder eine Router-Appliance mit einem VPC-Netzwerk verbunden ist

Eine Instanz kann über die interne IPv4-Adresse der VM mit Instanzen im selben VPC-Netzwerk oder in einem verbundenen Netzwerk (wie in der vorherigen Liste angegeben) kommunizieren. Wenn die Netzwerkschnittstelle der VM mit einem Dual-Stack-Subnetz oder einem reinen IPv6-Subnetz verbunden ist, können Sie entweder die internen oder die externen IPv6-Adressen der VM verwenden, um mit anderen Instanzen im selben Netzwerk zu kommunizieren. Als Best Practice sollten Sie interne IPv6-Adressen für die interne Kommunikation verwenden. Weitere Informationen zu IP-Adressen finden Sie in der Übersicht zu IP-Adressen für Compute Engine.

Für die Kommunikation mit dem Internet oder externen Systemen verwenden Sie eine externe IPv4- oder externe IPv6-Adresse, die auf der VM-Instanz konfiguriert ist. Externe IP-Adressen sind öffentlich routingfähige IP-Adressen. Wenn eine Instanz keine externe IP Adresse hat, kann Cloud NAT für IPv4-Traffic verwendet werden.

Wenn Sie mehrere Dienste auf einer einzelnen VM-Instanz ausführen, können Sie jedem Dienst mithilfe von Alias-IP-Bereichen eine andere interne IPv4-Adresse zuweisen. Das VPC-Netzwerk leitet Pakete, die für einen bestimmten Dienst bestimmt sind, an die entsprechende VM weiter. Weitere Informationen finden Sie unter Alias-IP-Bereiche.

Netzwerkdienststufen

Mit Netzwerkdienststufen können Sie Verbindungen zwischen Systemen im Internet und Ihren Compute Engine-Instanzen optimieren. In der Premium-Stufe wird der Traffic über das Premium-Backbone von Google geleitet, während die Standardstufe reguläre Netzwerke von Internetanbietern verwendet. Mit der Premiumstufe optimieren Sie die Leistung und mit der Standardstufe die Kosten.

Da Sie eine Netzwerkstufe auf Ressourcenebene auswählen, z. B. die externe IP-Adresse für eine VM, können Sie für einige Ressourcen die Standardstufe und für andere die Premium-Stufe verwenden. Wenn Sie keine Stufe angeben, wird die Premium-Stufe verwendet.

Compute-Instanzen, die für die Kommunikation innerhalb von VPC-Netzwerken interne IP-Adressen verwenden, nutzen immer die Premium-Stufe.

Bei Verwendung der Premium-Stufe oder Standardstufe fallen keine Kosten für eingehende Datenübertragungen an. Die Preise für ausgehende Datenübertragungen werden pro GiB berechnet und sind für die einzelnen Netzwerkdienststufen unterschiedlich. Informationen zu den Preisen finden Sie unter Netzwerkdienststufen – Preise.

Netzwerkdienststufen sind nicht dasselbe wie die Netzwerkleistung pro VM-Tier_1. Das ist eine Konfigurationsoption, die Sie für Ihre Compute-Instanzen auswählen können. Für die Verwendung von Tier_1-Netzwerken fallen zusätzliche Kosten an, wie unter Tier_1 Netzwerkpreise für höhere Bandbreitebeschrieben. Weitere Informationen zu Tier_1-Netzwerken finden Sie unter Netzwerkleistung pro VM-Tier_1 konfigurieren.

Premium-Stufe

Mit der Premium-Stufe wird der Traffic von externen Systemen zu Google CloudRessourcen über das zuverlässige, globale Netzwerk von Google mit geringer Latenz weitergeleitet. Dieses Netzwerk ist so konzipiert, dass es mehrere Fehler und Ausfälle tolerieren kann und trotzdem Traffic liefert. Die Premium-Stufe ist ideal für Kunden mit Nutzern an verschiedenen Standorten weltweit, die eine optimale Netzwerkleistung und -zuverlässigkeit benötigen.

Das Netzwerk der Premiumstufe besteht aus einem breiten privaten Glasfasernetz mit mehr als 100 Points of Presence (PoPs) auf der ganzen Welt. Innerhalb des Google-Netzwerks wird der Traffic von diesem PoP an die Compute-Instanz in Ihrem VPC-Netzwerk weitergeleitet. Ausgehender Traffic wird über das Google-Netzwerk gesendet und verlässt es am PoP, der dem Ziel am nächsten ist. Diese Routingmethode minimiert die Überlastung und maximiert die Leistung, weil die Anzahl der Hops zwischen Endnutzern und den PoPs in ihrer Nähe reduziert wird.

Standardstufe

Die Standardstufe leitet Traffic von externen Systemen an Google Cloud Ressourcen über das Internet weiter. Pakete, die das Google-Netzwerk verlassen, werden über das öffentliche Internet zugestellt und unterliegen der Zuverlässigkeit der beteiligten Transit-Anbieter und ISPs. Die Standardstufe bietet eine Netzwerkqualität und Zuverlässigkeit, die mit der anderer Cloud-Anbieter vergleichbar sind.

Die Standardstufe ist günstiger als die Premium-Stufe, da Traffic von Systemen im Internet über Transitnetzwerke (ISP) geleitet werden, bevor er an Compute-Instanzen in Ihrem VPC-Netzwerk gesendet wird. Ausgehender Traffic der Standardstufe verlässt das Netzwerk von Google, unabhängig vom Ziel, normalerweise von derselben Region aus, die von der sendenden Compute-Instanz verwendet wird.

Die Standardstufe bietet 200 GB kostenlose Nutzung pro Monat in jeder Region, die Sie über alle Ihre Projekte hinweg verwenden, mit einer Abrechnung pro Ressource.

DNS-Namen (Domain Name System)

Wenn Sie eine VM-Instanz erstellen, Google Cloud erstellt einen internen DNS-Namen aus dem VM-Namen. Wenn Sie keinen benutzerdefinierten Hostnamenangeben, Google Cloud verwendet den automatisch erstellten internen DNS-Namen als Hostnamen für die VM.

Für die Kommunikation zwischen VMs im selben VPC-Netzwerk können Sie den vollständig qualifizierten DNS-Namen (Fully Qualified DNS Name, FQDN) der Zielinstanz angeben, anstatt seine interne IP-Adresse zu verwenden. Google Cloud löst den FQDN automatisch in die interne IP-Adresse der Instanz auf.

Weitere Informationen zu vollständig qualifizierten Domainnamen (FQDN) finden Sie unter Zonale und globale interne DNS-Namen.

Routen

Google Cloud Routen definieren die Pfade, die der Netzwerkverkehr von einer VM-Instanz zu anderen Zielen zurücklegt. Diese Ziele können sich innerhalb Ihres VPC-Netzwerk (beispielsweise in einer anderen VM) oder außerhalb davon befinden. Die Routingtabelle für ein VPC-Netzwerk wird auf VPC-Netzwerk ebene definiert. Jede VM-Instanz hat einen Controller, der laufend über alle anwendbaren Routen aus der Routingtabelle des Netzwerks informiert wird. Jedes Paket, das eine VM verlässt, wird auf Basis einer Routingreihenfolge an den entsprechenden nächsten Hop einer anwendbaren Route zugestellt.

Subnetzrouten definieren Pfade zu Ressourcen wie VMs und internen Load-Balancern in einem VPC-Netzwerk. Jedes Subnetz hat mindestens eine Subnetzroute, deren Ziel dem primären IP-Bereich des Subnetzes entspricht. Subnetzrouten haben immer die spezifischsten Ziele. Sie können selbst dann nicht durch andere Routen überschrieben werden, wenn eine andere Route eine höhere Priorität hat. Das liegt daran, dass Google Cloud bei der Auswahl einer Route die Zielspezifität berücksichtigt. Weitere Informationen zu Subnetz-IP-Bereichen finden Sie in der Subnetzübersicht.

Weiterleitungsregeln

Während Routen den Traffic regeln, der eine Instanz verlässt, leiten Weiterleitungsregeln den Traffic an eine Google Cloud Ressource in einem VPC-Netzwerk anhand von IP Adresse, Protokoll und Port weiter. Einige Weiterleitungsregeln leiten Traffic von außerhalb von Google Cloud zu einem Ziel im Netzwerk, andere Regeln leiten Traffic innerhalb des Netzwerks weiter.

Sie können Weiterleitungsregeln für Ihre Instanzen konfigurieren, um virtuelles Hosting nach IP-Adressen, Cloud VPN, private virtuelle IP-Adressen (VIPs) und Load-Balancing zu implementieren. Weitere Informationen zu Weiterleitungsregeln finden Sie unter Protokollweiterleitung verwenden.

Firewallregeln

Mit Firewallregeln können Sie den Traffic zu und von Ihrer VM basierend auf einer von Ihnen festgelegten Konfiguration zulassen oder ablehnen. Google Cloud erzwingt immer aktivierte VPC-Firewallregeln, um Ihre VMs unabhängig von ihrer Konfiguration und ihrem Betriebssystem zu schützen, auch wenn die VM noch nicht gestartet wurde.

Standardmäßig verfügt jedes VPC-Netzwerk über eingehende (eingehender Traffic) und ausgehende (ausgehender Traffic) Firewall-Regeln die alle eingehenden Verbindungen blockieren und alle ausgehenden Verbindungen zulassen. Das default Netzwerk hat zusätzliche Firewallregeln, darunter die Regel default-allow-internal, die die Kommunikation zwischen Instanzen im Netzwerk zulässt. Wenn Sie das default-Netzwerk nicht verwenden, müssen Sie explizit Firewallregeln für eingehenden Traffic mit einer höheren Priorität erstellen, damit Instanzen miteinander kommunizieren können.

Jedes VPC-Netzwerk wirkt wie eine verteilte Firewall. Firewallregeln werden auf VPC-Ebene definiert und können auf alle Instanzen im Netzwerk angewendet werden. Sie können auch Zieltags oder Zieldienstkonten verwenden, um Regeln auf bestimmte Instanzen anzuwenden. Die VPC-Firewallregeln werden dabei nicht nur zwischen Ihren Instanzen und anderen Netzwerken angewendet, sondern auch zwischen einzelnen Instanzen innerhalb eines VPC-Netzwerks.

Mit hierarchischen Firewallrichtlinien können Sie eine konsistente Firewallrichtlinie für Ihre gesamte Organisation erstellen und erzwingen. Sie können der Organisation hierarchische Firewallrichtlinien als Ganzes oder für einzelne Ordner zuweisen. Diese Richtlinien enthalten Regeln, die Verbindungen explizit ablehnen oder zulassen, wie VPC-Firewallregeln. Darüber hinaus können die Regeln einer hierarchischen Firewallrichtlinie die Auswertung an Richtlinien auf einer niedrigeren Ebene oder VPC-Firewallregeln mit der Aktion goto_next delegieren. Regeln auf niedrigerer Ebene können keine Regeln von einer höheren Ebene in der Ressourcenhierarchie überschreiben. Auf diese Weise können organisationsweite Administratoren kritische Firewallregeln an einem Ort verwalten.

Beschleunigungsoptimierte Maschinen und Netzwerkkonfigurationen

Wenn Sie beschleunigungsoptimierte Maschinentypen (GPUs oder TPUs) verwenden, finden Sie weitere Informationen auf den folgenden Seiten:

Verwaltete Instanzgruppen und Netzwerkkonfigurationen

Wenn Sie verwaltete Instanzgruppen (MIGs), die in der Instanzvorlage angegebene Netzwerkkonfiguration für alle VMs gilt, die mit der Vorlage erstellt wurden. Wenn Sie eine Instanzvorlage in einem VPC-Netzwerk im Auto modus erstellen, Google Cloud wählt automatisch das Subnetz für die Region aus, in der Sie die verwaltete Instanzgruppe erstellt haben.

Weitere Informationen finden Sie unter Netzwerke und Subnetze und unter Instanzvorlagen erstellen.

Nächste Schritte