VPC-Netzwerke

Ein VPC-Netzwerk (Virtual Private Cloud) ist eine virtuelle Version eines physischen Netzwerks, die mithilfe von Andromeda im Google-Produktionsnetzwerk implementiert wird.

Ein VPC-Netzwerk führt Folgendes aus:

  • Stellt eine Verbindung für Ihre Compute Engine-VM-Instanzen bereit.
  • Ermöglicht native interne Passthrough-Network Load Balancer und Proxysysteme für interne Application Load Balancer.
  • Stellt eine Verbindung zu lokalen Netzwerken über Cloud VPN-Tunnel und VLAN-Anhänge für Cloud Interconnect her.
  • Verteilt den Traffic von externen Google Cloud-Load-Balancern auf Back-Ends.

Projekte können mehrere VPC-Netzwerke enthalten. Sofern Sie keine Organisationsrichtlinie erstellen, die dies verbietet, beginnen neue Projekte mit einem Standardnetzwerk (einem VPC-Netzwerk im automatischen Modus), das in jeder Region ein Subnetzwerk (Subnetz) hat.

Netzwerke und Subnetze

Die Begriffe Subnetz und Subnetzwerk werden synonym verwendet. Sie sind in der Google Cloud Console, in gcloud-Befehlen und in der API-Dokumentation austauschbar.

Ein Subnetz ist nicht dasselbe wie ein (VPC-)Netzwerk. Netzwerke und Subnetze sind unterschiedliche Ressourcentypen in Google Cloud.

Weitere Informationen finden Sie unter Subnetze.

VM-Instanzen

Eine Compute Engine-VM-Instanz ist eine virtuelle Maschine, die in der Infrastruktur von Google gehostet wird. Die Begriffe Compute Engine-Instanz, VM-Instanz und VM werden synonym verwendet. Sie sind in der Google Cloud Console, der Referenz zur Google Cloud CLI und der API-Dokumentation austauschbar.

VM-Instanzen umfassen Google Kubernetes Engine-Cluster (GKE), Instanzen der flexiblen App Engine-Umgebung und andere Google Cloud-Produkte, die auf Compute Engine-VMs basieren.

Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter VM-Instanzen.

Spezifikationen

VPC-Netzwerke haben folgende Eigenschaften:

  • VPC-Netzwerke und die damit verknüpften Routen und Firewallregeln sind globale Ressourcen. Sie sind nicht mit einer bestimmten Region oder Zone verknüpft.

  • Subnetze sind regionale Ressourcen.

  • Von jedem Subnetz wird ein Bereich von IP-Adressen definiert. Subnetze in VPC-Netzwerken im benutzerdefinierten Modus können ebenfalls einen Bereich von IPv6-Adressen haben.

  • Der Traffic zu und von den Instanzen kann mit Firewallregeln für Netzwerke gesteuert werden. Regeln werden auf den VMs selbst umgesetzt, sodass der Traffic nur beim Verlassen oder Erreichen einer VM gesteuert und protokolliert werden kann.

  • Die Ressourcen in einem VPC-Netzwerk können abhängig von den geltenden Firewallregeln über interne IPv4-Adressen, interne IPv6-Adressen oder externe IPv6-Adressen miteinander kommunizieren. Weitere Informationen finden Sie unter Kommunikation im Netzwerk.

  • Instanzen mit internen IPv4- oder IPv6-Adressen können mit APIs und Diensten von Google kommunizieren. Weitere Informationen finden Sie unter Private Zugriffsoptionen für Dienste.

  • Die Netzwerkverwaltung kann über IAM-Rollen (Identity and Access Management) gesichert werden.

  • Eine Organisation kann eine freigegebene VPC verwenden, um ein VPC-Netzwerk als Teil eines gemeinsamen Hostprojekts zu nutzen. Autorisierte IAM-Hauptkonten aus anderen Projekten in derselben Organisation können Ressourcen erstellen, für die Subnetze des freigegebenen VPC-Netzwerks genutzt werden.

  • VPC-Netzwerke können über VPC-Netzwerk-Peering mit anderen VPC-Netzwerken aus anderen Projekten oder Organisationen verbunden werden.

  • VPC-Netzwerke können in Hybridumgebungen über Cloud VPN oder Cloud Interconnect sicher verbunden werden.

  • VPC-Netzwerke unterstützen GRE-Traffic, einschließlich Traffic in Cloud VPN und Cloud Interconnect. VPC-Netzwerke unterstützen GRE für Cloud NAT und Weiterleitungsregeln für Load-Balancing und Protokollweiterleitung nicht. Dank der Unterstützung für GRE können Sie den GRE-Traffic auf einer VM aus dem Internet (externe IP-Adresse) und Cloud VPN oder Cloud Interconnect (interne IP-Adresse) beenden. Der gekapselte Traffic kann dann an ein erreichbares Ziel weitergeleitet werden. GRE ermöglicht es Ihnen, Dienste wie SASE (Secure Access Service Edge) und SD-WAN zu verwenden.

  • VPC-Netzwerke unterstützen IPv4- und IPv6-Unicast-Adressen. VPC-Netzwerke unterstützen keine Broadcast- oder Multicast-Adressen innerhalb des Netzwerks.

    Weitere Informationen zu IPv6-Subnetzbereichen finden Sie unter Subnetze.

Beispiel für ein VPC-Netzwerk

Das folgende Beispiel zeigt ein VPC-Netzwerk im benutzerdefinierten Modus mit drei Subnetzen in zwei Regionen:

Beispiel für ein VPC-Netzwerk.
Beispiel für ein VPC-Netzwerk (zum Vergrößern klicken)
  • Subnet1 ist als 10.240.0.0/24 in der Region us-west1 definiert.
    • In diesem Subnetz befinden sich zwei VM-Instanzen in der Zone us-west1-a. Die zugehörigen IP-Adressen stammen beide aus dem verfügbaren Adressbereich in subnet1.
  • Subnet2 ist als 192.168.1.0/24 in der Region us-east1 definiert.
    • In diesem Subnetz befinden sich zwei VM-Instanzen in der Zone us-east1-b. Die zugehörigen IP-Adressen stammen beide aus dem verfügbaren Adressbereich in subnet2.
  • Subnet3 ist als 10.2.0.0/16 in der Region us-east1 definiert.
    • In subnet3 befinden sich eine VM-Instanz in der Zone us-east1-b und eine zweite Instanz in der Zone us-east1-c. Beide erhalten jeweils eine IP-Adresse aus dem verfügbaren Bereich. Da es sich bei Subnetzen um regionale Ressourcen handelt, können die Netzwerkschnittstellen von Instanzen mit einem beliebigen Subnetz in der Region mit ihren Zonen verknüpft werden.

Einschränkungen für Organisationsrichtlinien

  • Jedes neue Projekt beginnt mit einem Standard-VPC-Netzwerk. Sie können die Erstellung von Standardnetzwerken deaktivieren. Erstellen Sie dazu eine Organisationsrichtlinie, für die die Einschränkung compute.skipDefaultNetworkCreation gilt. Projekte, die diese Richtlinie übernehmen, haben kein Standardnetzwerk.

  • Sie können die folgenden IPv6-Konfigurationen mithilfe von Organisationsrichtlinien steuern:

    • Externe IPv6-Nutzung deaktivieren: Wenn die Einstellung auf "true" gesetzt ist, verhindert die Einschränkung constraints/compute.disableVpcExternalIpv6 das Konfigurieren von Dual-Stack-Subnetzen mit externen IPv6-Bereichen.

    • Interne IPv6-Nutzung durch VPC deaktivieren: Wenn diese Option auf "true" gesetzt ist, können Sie mit der Einschränkung constraints/compute.disableVpcInternalIpv6 keine Dual-Stack-Subnetze mit internen IPv6-Bereichen konfigurieren.

    • Gesamte IPv6-Nutzung deaktivieren: Wenn diese Option auf "true" gesetzt ist, deaktiviert die Einschränkung constraints/compute.disableAllIpv6 das Erstellen oder Aktualisieren von Ressourcen, die an der IPv6-Nutzung beteiligt sind.

Weitere Informationen zu Einschränkungen finden Sie unter Einschränkungen für Organisationsrichtlinien.

Modus für Subnetzerstellung

Google Cloud bietet zwei Arten von VPC-Netzwerken, die durch ihren Modus für die Subnetzerstellung bestimmt werden:

Sie können ein VPC-Netzwerk vom automatischen Modus in den benutzerdefinierten Modus konvertieren. Diese Konvertierung ist nur in eine Richtung möglich. VPC-Netzwerke im benutzerdefinierten Modus können nicht in VPC-Netzwerke im automatischen Modus umgewandelt werden. Wenn Sie Hilfe bei der Entscheidung benötigen, welcher Netzwerktyp Ihren Anforderungen entspricht, lesen Sie sich den Abschnitt Überlegungen zu VPC-Netzwerken im automatischen Modus durch.

Standardnetzwerk

Sofern Sie diese Option nicht deaktivieren, beginnt jedes neue Projekt mit einem Standardnetzwerk. Das Standardnetzwerk ist ein VPC-Netzwerk im automatischen Modus mit vorkonfigurierten IPv4-Firewallregeln. Das Standardnetzwerk hat keine voreingestellten IPv6-Firewallregeln.

Überlegungen zu VPC-Netzwerken im automatischen Modus

VPC-Netzwerke im automatischen Modus sind einfach einzurichten, zu verwenden und eignen sich gut für Anwendungsfälle mit diesen Anforderungen:

  • Das automatische Erstellen von Subnetzen in jeder Region ist sinnvoll.

  • Die vordefinierten IP-Bereiche der Subnetze überschneiden sich nicht mit IP-Bereichen, die Sie für andere Zwecke verwenden, z. B. für Cloud VPN-Verbindungen zu lokalen Ressourcen.

Netzwerke im benutzerdefinierten Modus sind flexibler und besser für die Produktion geeignet. VPC-Netzwerke im benutzerdefinierten Modus eignen sich gut für Anwendungsfälle mit diesen Anforderungen:

  • Das automatische Erstellen von Subnetzen in jeder Region ist nicht erforderlich.

  • Das automatische Erstellen neuer Subnetze bei Verfügbarkeit neuer Regionen führt zu Überschneidungen mit IP-Adressen, die von manuell erstellten Subnetzen oder statischen Routen verwendet werden. Dieser Vorgang kann auch die gesamte Netzwerkplanung beeinträchtigen.

  • Sie benötigen vollständige Kontrolle über die in Ihrem VPC-Netzwerk erstellten Subnetze, einschließlich der verwendeten Regionen und IP-Adressbereiche.

  • Sie planen, Ihr VPC-Netzwerk mit einem anderen Netzwerk zu verbinden:

    • Da die Subnetze jedes VPC-Netzwerks im automatischen Modus denselben vordefinierten Bereich von IP-Adressen verwenden, können Sie VPC-Netzwerke im automatischen Modus nicht mithilfe von VPC-Netzwerk-Peering oder Cloud VPN miteinander verbinden.

    • Da der CIDR-Bereich 10.128.0.0/9 im automatischen Modus Teil des häufig verwendeten Adressbereichs RFC 1918 ist, können Netzwerke außerhalb von Google Cloud einen sich überschneidenden CIDR-Bereich verwenden.

  • Sie möchten Subnetze mit IPv6-Bereichen erstellen. VPC-Netzwerke im automatischen Modus unterstützen keine Dual-Stack-Subnetze.

IPv4-Subnetzbereiche

Jedes Subnetz hat einen primären IPv4-Adressbereich. Die primären internen Adressen folgender Ressourcen stammen aus dem primären Bereich des Subnetzes: VM-Instanzen, interne Load-Balancer und interne Protokollweiterleitung. Optional können Sie zu einem Subnetz sekundäre IP-Adressbereiche hinzufügen, die nur von Alias-IP-Bereichen verwendet werden. Sie können jedoch Alias-IP-Bereiche für Instanzen aus dem primären oder sekundären Bereich eines Subnetzes konfigurieren.

Für alle Subnetze in einem VPC-Netzwerk muss jeder primäre oder sekundäre IPv4-Bereich ein eindeutiger gültiger CIDR-Block sein. Informationen zur Anzahl der sekundären IP-Bereiche, die Sie definieren können, finden Sie im Abschnitt zu Limits pro Netzwerk.

Ihre IPv4-Subnetze müssen keinen vordefinierten zusammenhängenden CIDR-Block bilden, bei Bedarf können Sie dies aber festlegen. In Netzwerken im automatischen Modus werden z. B. Subnetze erstellt, die sich in einen für den automatischen Modus vordefinierten IP-Bereich einfügen lassen.

Wenn Sie ein Subnetz in einem VPC-Netzwerk im benutzerdefinierten Modus erstellen, wählen Sie den zu verwendenden IPv4-Bereich aus. Weitere Informationen finden Sie unter Gültige Bereiche, Unzulässige Subnetzbereiche und Einschränkungen für IPv4-Subnetzbereiche.

In jedem primären IPv4-Subnetzbereich gibt es vier nicht verwendbare IP-Adressen. Weitere Informationen finden Sie unter Nicht verwendbare Adressen in IPv4-Subnetzbereichen.

VPC-Netzwerke im automatischen Modus werden mit einem Subnetz pro Region erstellt und in neuen Regionen werden ihnen automatisch neue Subnetze hinzugefügt. Die Subnetze haben nur IPv4-Bereiche und alle Subnetzbereiche befinden sich innerhalb des CIDR-Blocks 10.128.0.0/9. Nicht verwendete Teile von 10.128.0.0/9 sind für zukünftige Nutzung durch Google Cloud reserviert. Informationen darüber, welcher IPv4-Bereich in welcher Region verwendet wird, finden Sie unter IPv4-Subnetzbereiche im automatischen Modus.

IPv6-Subnetzbereiche

Wenn Sie ein Dual-Stack-Subnetz in einem VPC-Netzwerk im benutzerdefinierten Modus erstellen, entscheiden Sie, ob das Subnetz mit einem internen IPv6-Subnetzbereich oder mit einem externen IPv6-Subnetzbereich konfiguriert ist.

  • Interne IPv6-Subnetzbereiche verwenden eindeutige lokale Adressen (ULAs).

    • ULAs werden für die VM-zu-VM-Kommunikation in VPC-Netzwerken verwendet. ULAs für IPv6 entsprechen den RFC 1918-Adressen für IPv4. ULAs können nicht über das Internet erreicht werden und sind nicht öffentlich routingfähig.

  • Externe IPv6-Subnetzbereiche verwenden globale Unicast-Adressen (GUAs).

    • GUAs können für die VM-zu-VM-Kommunikation in VPC-Netzwerken verwendet werden und sind auch im Internet routingfähig.

Weitere Informationen zu IPv6-Subnetzbereichen finden Sie unter Subnetze.

Netzwerke, die Dual-Stack-Subnetze unterstützen

In einem VPC-Netzwerk im benutzerdefinierten Modus können Sie Dual-Stack-Subnetze erstellen.

Dual-Stack-Subnetze werden in VPC-Netzwerken im automatischen Modus nicht unterstützt, auch nicht im Standardnetzwerk. Dual-Stack-Subnetze werden in Legacy-Netzwerken nicht unterstützt.

Wenn Sie ein VPC-Netzwerk im automatischen Modus haben, dem Sie Dual-Stack-Subnetze hinzufügen möchten, können Sie so vorgehen:

  1. Versetzen Sie das Netzwerk im automatischen Modus in den benutzerdefinierten Modus.

  2. Erstellen Sie neue Dual-Stack-Subnetze oder konvertieren Sie vorhandene Subnetze in Dual-Stack-Vorgänge.

Routen und Firewallregeln

Routen

Routen definieren Pfade für Pakete, die Instanzen verlassen (ausgehender Traffic). Weitere Informationen zu Google Cloud-Routentypen finden Sie unter Routen.

Modus für dynamisches Routing

Jedem VPC-Netzwerk ist ein Modus für dynamisches Routing zugeordnet, der das Verhalten aller Cloud Router im Netzwerk steuert. Cloud Router verwalten BGP-Sitzungen für Google Cloud-Konnektivitätsprodukte.

Eine Beschreibung der Optionen für den dynamischen Routingmodus finden Sie unter Auswirkungen des dynamischen Routingmodus in der Cloud Router-Dokumentation.

Route Advertisement und interne IP-Adressen

Die folgenden IP-Adressen werden in einem VPC-Netzwerk beworben:

Wenn Sie VPC-Netzwerke über VPC-Netzwerk-Peering verbinden, werden Subnetzbereiche, die private IPv4-Adressen verwenden, immer ausgetauscht. Sie können steuern, ob Subnetzbereiche, die privat verwendete öffentliche IPv4-Adressen verwenden, ausgetauscht werden. Globale interne IPv4-Adressen werden nie über Peering ausgetauscht. Weitere Informationen finden Sie in der Dokumentation zum VPC-Netzwerk-Peering.

Wenn Sie ein VPC-Netzwerk mit einem anderen Netzwerk, z. B. einem lokalen Netzwerk, mithilfe eines Google Cloud-Konnektivitätsprodukts wie Cloud VPN, Cloud Interconnect oder Router-Appliance verbinden:

  • Sie können die internen IP-Adressen des VPC-Netzwerks einem anderen Netzwerk (z. B. einem lokalen Netzwerk) anbieten.
  • Obwohl die Verbindung zwischen einem VPC-Netzwerk und einem anderen Netzwerk (z. B. einem lokalen Netzwerk) privates Routing verwenden kann, das von einem Google Cloud-Konnektivitätsprodukt bereitgestellt wird, sind die IP-Adressen des anderen Netzwerks möglicherweise auch öffentlich routingfähig. Beachten Sie dies, wenn ein lokales Netzwerk öffentlich routingfähige IP-Adressen verwendet.
  • VM-Instanzen in einem VPC-Netzwerk, das Subnetzbereiche mit privat verwendeten öffentlichen IP-Adressen enthält, können keine Verbindung zu externen Ressourcen herstellen, die dieselben öffentlichen IP-Adressen verwenden.
  • Seien Sie besonders vorsichtig, wenn Sie privat genutzte öffentliche IP-Adressen in einem anderen Netzwerk (z. B. einem lokalen Netzwerk) bewerben, insbesondere wenn das andere Netzwerk diese öffentlichen IP-Adressen im Internet anbieten kann.

Firewallregeln

Sowohl hierarchische Firewallrichtlinien als auch VPC-Firewallregeln gelten für Pakete, die an und von VM-Instanzen gesendet werden (und Ressourcen, die von VMs abhängig sind, z. B. Google Kubernetes Engine-Knoten). Beide Arten von Firewalls kontrollieren den Traffic, auch wenn er zwischen VMs im selben VPC-Netzwerk stattfindet.

Wenn Sie überwachen möchten, welche Firewallregel eine bestimmte Verbindung erlaubt oder abgelehnt hat, finden Sie weitere Informationen unter Logging von Firewallregeln.

Kommunikation und Zugriff

Kommunikation im Netzwerk

Die systemgenerierten Subnetzrouten definieren die Pfade zum Senden von Traffic zwischen Instanzen im Netzwerk über interne IP-Adressen. Damit eine Instanz mit einer anderen Instanz kommunizieren kann, müssen auch entsprechende Firewallregeln konfiguriert werden, da jedes Netzwerk über eine implizierte Firewallregel zur Ablehnung von eingehendem Traffic verfügt.

Außer im Standardnetzwerk müssen Sie explizit Firewallregeln für eingehenden Traffic mit einer höheren Priorität erstellen, damit Instanzen miteinander kommunizieren können. Das Standardnetzwerk umfasst verschiedene Firewallregeln zusätzlich zu den implizierten Regeln, z. B. die Regel default-allow-internal, die die Kommunikation zwischen den Instanzen im Netzwerk zulässt. Das Standardnetzwerk enthält auch Eingangsregeln, die Protokolle wie RDP und SSH zulassen.

Regeln, die im Standardnetzwerk enthalten sind, können auch auf neue VPC-Netzwerke im automatischen Modus angewendet werden, die Sie über die Google Cloud Console erstellen.

Anforderungen für den Internetzugriff

Damit für eine Instanz ausgehende Internetverbindungen möglich sind, müssen folgende Kriterien erfüllt sein:

  • Das Netzwerk benötigt eine gültige Route für das Standard-Internetgateway oder eine benutzerdefinierte Route mit ganz allgemeinem IP-Zielbereich (0.0.0.0/0). Mit dieser Route wird der Pfad zum Internet definiert. Weitere Informationen finden Sie unter Routen.

  • Firewallregeln müssen ausgehenden Traffic von der Instanz zulassen. Die implizierte Regel zum Zulassen von ausgehendem Traffic gilt für alle Instanzen im Netzwerk, wenn sie nicht von einer Regel mit einer höheren Priorität überschrieben wird.

  • Eine der folgenden Bedingungen muss zutreffen:

    • Die Instanz muss eine externe IP-Adresse haben. Eine externe IP-Adresse kann einer Instanz bei der Erstellung oder nach der Erstellung zugewiesen werden.

    • Die Instanz muss in der Lage sein, Cloud NAT oder einen instanzbasierten Proxy zu verwenden, der das Ziel für eine statische 0.0.0.0/0-Route ist.

Kommunikation und Zugriff für App Engine

VPC-Firewallregeln gelten für Ressourcen, die im VPC-Netzwerk ausgeführt werden, z. B. Compute Engine-VMs. Für App Engine-Instanzen funktionieren Firewallregeln so:

  • App Engine-Standardumgebung: Für eingehenden Traffic gelten nur App Engine-Firewallregeln. Da App Engine-Instanzen der Standardumgebung nicht innerhalb Ihres VPC-Netzwerks ausgeführt werden, gelten VPC-Firewallregeln nicht für sie.

  • Flexible App Engine-Umgebung: Für eingehenden Traffic gelten sowohl App Engine- als auch VPC-Firewallregeln. Eingehender Traffic ist nur zulässig, wenn er von beiden Arten von Firewallregeln erlaubt wird. Für ausgehenden Traffic gelten VPC-Firewallregeln.

Weitere Informationen zur Steuerung des Zugriffs auf App Engine-Instanzen finden Sie unter Anwendungssicherheit.

Traceroute zu externen IP-Adressen

Aus internen Gründen erhöht Google Cloud den TTL-Zähler von Paketen, die nächste Hops im Google-Netzwerk durchlaufen. Tools wie traceroute und mtr liefern dann möglicherweise unvollständige Ergebnisse, da die TTL bei einigen Hops nicht abläuft. Hops innerhalb des Google-Netzwerks sind möglicherweise ausgeblendet, wenn Sie Pakete von Compute Engine-Instanzen an Ziele im Internet senden.

Die Anzahl der ausgeblendeten Hops variiert je nach den Netzwerkdienststufen der Instanz, der Region und anderen Faktoren. Wenn es nur wenige Hops gibt, ist es möglich, dass alle ausgeblendet sind. Wenn im Ergebnis von traceroute oder mtr Hops fehlen, bedeutet dies nicht, dass ausgehender Traffic verworfen wird.

Es gibt für dieses Verhalten keine Problemumgehung. Sie müssen dies berücksichtigen, wenn Sie Monitoring von Drittanbietern einrichten, das eine Verbindung zu einer externen IP-Adresse herstellt, die mit einer VM verbunden ist.

Durchsatzlimits für ausgehenden Traffic

Informationen zum Netzwerkdurchsatz finden Sie auf der Seite Netzwerkbandbreite in der Compute Engine-Dokumentation.

Paketgröße

Informationen zur Paketgröße finden Sie unter Maximale Übertragungseinheit.

Maximale Übertragungseinheit

Weitere Informationen zur Einstellung der maximalen Übertragungseinheit (MTU) für ein VPC-Netzwerk und die zugehörigen VMs finden Sie unter Maximale Übertragungseinheit.

Informationen zum Ändern der MTU eines VPC-Netzwerks oder zum Migrieren von VMs zwischen VPC-Netzwerken mit unterschiedlichen MTU-Einstellungen finden Sie unter MTU-Einstellung eines VPC-Netzwerks ändern.

Unterstützte Protokolle

Google Cloud unterstützt nur die folgenden Protokolle und Erweiterungsheader:

  • IPv4-Datenpakete zwischen VMs: alle IPv4-Protokolle.
  • IPv4-Datenpakete zwischen VMs und dem Internet: die Protokolle ICMP, IPIP, TCP, UDP, GRE, ESP, AH und SCTP.
  • IPv6-Datenpakete zwischen VMs und zwischen VMs und dem Internet: die Protokolle AH, ESP, GRE, ICMP, ICMPv6, IPIP, SCTP, TCP und UDP sowie die Erweiterungsheader „Zieloptionen“ und „Fragmente“. Das Platzieren des Headers „Zieloptionen“ nach dem Header „Fragment“ in einem IPv6-Datenpaket wird jedoch nicht unterstützt.
  • Protokollweiterleitung: die Protokolle AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP und UDP

Damit Datenpakete der unterstützten Protokolle zugelassen werden, müssen Sie Firewallregeln oder Protokollweiterleitungsregeln entsprechend Ihren Anforderungen konfigurieren.

Netzwerkleistung

Latenz

Die gemessene Latenz zwischen den Regionen für Google Cloud-Netzwerke finden Sie in unserem Live-Dashboard. Das Dashboard zeigt Google Clouds durchschnittliche interregionale Leistungsmesswerte zu Latenz und Durchsatz und die Methodik zur Reproduktion dieser Ergebnisse mit PerfKit Benchmarker.

Google Cloud misst normalerweise Umlaufzeitlatenzen von weniger als 55 μs beim 50. Perzentil und Extremwertlatenzen von weniger als 80 μs beim 99. Perzentil zwischen c2-standard-4-VM-Instanzen in derselben Zone.

Google Cloud misst in der Regel Umlaufzeitlatenzen unter 45 μs beim 50. Perzentil und Extremwertlatenzen von weniger als 60 μs beim 99. Perzentil zwischen c2-standard-4-VM-Instanzen im selben Netzwerk mit geringer Latenz (Richtlinie für „kompakte“ Platzierung). Mit einer Richtlinie für kompakte Platzierung verringern Sie die Netzwerklatenz, da damit sichergestellt wird, dass sich die VMs innerhalb desselben Netzwerks mit geringer Latenz befinden.

Methodik: Die zoneninterne Latenz wird über einen Blackbox-Prober überwacht, der in jeder Zone, in der c2-Instanzen verfügbar sind, ständig die TCP_RR-Benchmark netperf zwischen zwei c2-Typ-VMs ausführt. Es werden P50- und P99-Ergebnisse für die Einrichtung mit und ohne Richtlinie für kompakte Platzierung erfasst. Die TCP_RR-Benchmark misst durch Messung der Transaktionsrate die Anfrage/Antwort-Leistung. Wenn Ihre Anwendungen die bestmögliche Latenz erfordern, sind c2-Instanzen zu empfehlen.

Paketverlust

Google Cloud verfolgt den regionenübergreifenden Paketverlust, indem regelmäßig der Umlaufverlust zwischen allen Regionen gemessen wird. Der globale Durchschnitt dieser Messwerte liegt unter 0,01 %.

Methodik: Ein VM-zu-VM-Blackbox-Prober überwacht den Paketverlust für jedes Zonenpaar mithilfe von Pings und fasst die Ergebnisse in einem globalen Verlustmesswert zusammen. Dieser Messwert wird für einen Zeitraum von einem Tag erfasst.

Nächste Schritte

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit von VPC in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

VPC kostenlos testen