Über Hybrid Subnets

Mit Hybrid Subnets können Sie ein lokales Subnetz mit einem VPC-Subnetz (Virtual Private Cloud) kombinieren, um ein einzelnes logisches Subnetz zu erstellen. Sie können einzelne Arbeitslasten und VM-Instanzen im Laufe der Zeit vom lokalen Subnetz zum VPC-Subnetz migrieren, ohne die IP-Adressen ändern zu müssen. Nachdem alle Arbeitslasten und VMs migriert wurden, können Sie das lokale Subnetz außer Betrieb nehmen.

In einem Hybridsubnetz bieten lokale Router und Cloud Router Routen mit dem Border Gateway Protocol (BGP) an. ) (zum Vergrößern klicken).

Hybrid Subnets und Migrate to Virtual Machines

Wir empfehlen die Verwendung von Migrate to Virtual Machines mit Hybrid Subnets, um den Prozess der Migration von VMs aus einer VMware-Quelle zu automatisieren. Migrate to Virtual Machines wird von Google unterstützt.

Weitere Informationen zu Migrationsoptionen finden Sie unter Migrationsressourcen.

Alternativ können Sie Migrationstools von Drittanbietern mit Hybrid Subnets verwenden, solange die in diesem Dokument beschriebenen Anforderungen für Hybrid Subnets erfüllt sind.

Wenn Sie Unterstützung bei der Planung einer Migration zu Google Cloud mithilfe von Hybrid Subnets benötigen, reichen Sie eine Supportanfrage ein.

Informationen zur Planung einer Migration mit Migrate to VMs finden Sie unter Migrationsprozess mit Migrate to VMs.

Spezifikationen

  • Für Hybrid Subnets ist ein Netzwerkverbindungsprodukt wie Cloud VPN oder Cloud Interconnect erforderlich.
  • Ein lokaler Router verwendet Proxy-ARP, um Traffic von lokalen Computern an Google Cloud-VMs mithilfe von Routen weiterzuleiten, die von benutzerdefinierten beworbenen Routen auf dem Cloud Router ermittelt wurden.
  • Der primäre IPv4-Adressbereich des Google Cloud-Subnetzes muss mit dem IP-Adressbereich des lokalen Subnetzes übereinstimmen.
  • Sie müssen das Feld allow-cidr-routes-overlap eines VPC-Subnetzes aktivieren, um das Subnetz als Hybridsubnetz zu konfigurieren. Wenn allow-cidr-routes-overlap aktiviert ist, können sich benutzerdefinierte Routen in Google Cloud mit den IP-Adressbereichen des Subnetzes überschneiden.
  • Das Flag allow-cidr-routes-overlap gilt für primäre IPv4-Subnetzbereiche und sekundäre IPv4-Subnetzbereiche sowie für IPv6-Subnetzbereiche.
  • Die interne Verbindung wird zwischen allen VMs und Arbeitslasten in einem Hybridsubnetz beibehalten.
  • Sie verwenden benutzerdefinierte beworbene Routen von Cloud Router, um die IP-Adressen von VMs selektiv bei der Migration zum VPC-Subnetz anzubieten.
  • Wenn Sie Arbeitslasten von einem lokalen Netzwerk zu Google Cloud migrieren, aktualisieren Sie die benutzerdefinierten beworbenen Routen von Cloud Router so, dass sie die IP-Adressen der migrierten VMs enthalten.
  • Sie können ein Hybridsubnetz mit einem Peer-VPC-Netzwerk mithilfe von VPC-Netzwerk-Peering verbinden. Die Peering-Konfiguration für das VPC-Netzwerk, das das Hybridsubnetz enthält, muss so konfiguriert sein, dass benutzerdefinierte Routen exportiert werden. Die Peering-Konfiguration für das andere VPC-Netzwerk muss so konfiguriert sein, dass benutzerdefinierte Routen importiert werden.

Beschränkungen

  • Die maximale Anzahl von VMs in einem VPC-Netzwerk mit Hybrid Subnets beträgt 130. Das Überschreiten dieser Beschränkung kann zu Verbindungs- und Stabilitätsproblemen führen.
  • Der Cloud Router eines Hybridsubnetzes darf die maximale Anzahl von benutzerdefinierten beworbenen Routen pro BGP-Sitzung nicht überschreiten.
  • Broadcast- und Multicast-Traffic innerhalb eines Hybridsubnetzes werden nicht unterstützt.
  • Sie können keine Layer-3-Partner Interconnect-Verbindungen verwenden, die die Ankündigung von /32-Routen mit Hybrid Subnets nicht unterstützen.
  • Hybrid Subnets unterstützen IPv6 nicht.
  • Hybrid Subnets unterstützen Google Cloud VMware Engine nicht. Wir empfehlen die Migration von VMware-VMs mit VMware HCX.
  • Wenn eine lokale Arbeitslast dieselbe IP-Adresse wie der Cloud Router hat, können Arbeitslasten im VPC-Teil eines Hybridsubnetzes keine Pakete an diese IP-Adresse senden. Wenn der IP-Adressbereich des Hybridsubnetzes beispielsweise 192.168.1.0/24 ist, können Arbeitslasten im VPC-Subnetz 192.168.1.1 nicht erreichen.
  • Hybrid Subnets können keine Arbeitslasten an den reservierten IP-Adressen in IPv4-Subnetzen hosten.
  • Die eingehende Cloud DNS-Weiterleitung antwortet nicht auf DNS-Anfragen von Arbeitslasten im lokalen Teil eines Hybridsubnetzes.
  • Arbeitslasten im lokalen Teil eines Hybridsubnetzes können Google APIs und Google-Dienste nicht über den privaten Google-Zugriff erreichen.
  • Arbeitslasten im lokalen Teil eines Hybridsubnetzes können keine Private Service Connect-Endpunkte für Google APIs erreichen.
  • Hybrid Subnets unterstützen keine Site-to-Site-Datenübertragung.
  • Hybrid Subnets unterstützen keine Migration von Arbeitslasten von anderen Cloud-Dienstanbietern oder die Migration von Arbeitslasten innerhalb von Google Cloud, da diese Umgebungen kein Proxy-ARP unterstützen.
  • Hybridsubnetze können über Network Connectivity Center keine Verbindung zu Peer-Netzwerken herstellen.

Hinweise zur Verwendung von Hybrid Subnets

In den folgenden Abschnitten werden Überlegungen zur Verwendung von Hybrid Subnets beschrieben.

Netzwerkleistung

Hybrid Subnets verwenden das Layer 3 des OSI-Modells, um Pakete zwischen den lokalen und den VPC-Teilen eines Hybridsubnetzes weiterzuleiten. Mit diesem Ansatz können Hybrid Subnets Probleme mit Latenz, Jitter und Durchsatz vermeiden, die während Migrationen auftreten können, wenn einige Arbeitslasten in einem lokalen Netzwerk vorhanden sind, andere Arbeitslasten jedoch in die Cloud migriert wurden.

Insbesondere die Vermeidung von Layer-2-Tunneling trägt dazu bei, die Leistungsverschlechterung zu verhindern, die mit der Kapselung und Verschlüsselung eines zusätzlichen Layer-2-Overlays verbunden ist. Darüber hinaus können Hybrid Subnets mit Layer-3-Routing ein häufiges Problem mit Layer-2-Tunneling vermeiden, bei dem der Traffic an einen zentralen Knoten gesendet wird, bevor Ziele in der Nähe des Ursprungspunkts des Traffics erreicht werden. Dieses Problem wird mitunter als Netzwerktromboning bezeichnet.

Der Ansatz von Hybrid Subnets in Bezug auf das Routing bedeutet, dass Sie eine Leistung von einem Hybridsubnetz erwarten können, das einem Netzwerk ohne Hybrid Subnets ähnlich ist oder mit diesem identisch ist.

Proxy-ARP und Hybrid Subnets

Proxy-ARP ist für Hybrid Subnets erforderlich. Wir empfehlen Folgendes für die Verwendung von Proxy-ARP im lokalen Teil eines Hybridsubnetzes:

  • Wenden Sie sich an den Anbieter Ihrer lokalen Netzwerkstruktur, um die Best Practices für die Aktivierung des Proxy-ARP und die Sicherung Ihrer Netzwerkumgebung zu erhalten.
  • Deaktivieren Sie den Proxy-ARP nach Abschluss der Migration zu Google Cloud.

Firewalls und Hybrid Subnets

Hybrid Subnets vermeiden Probleme im Zusammenhang mit der Verwendung von Firewalls mit Traffic, der in Layer-2-Overlays gekapselt ist. Bei Layer-2-Traffic können Firewalls nur Pakete an oder außerhalb der Overlay-Endpunkte prüfen, es sei denn, Sie ergreifen spezifische Maßnahmen wie eine transparente Entschlüsselung oder eine umfassende Prüfung des Overlay-Traffics.

Für die Verwendung vorhandener Firewalls und Firewallregeln mit Hybrid Subnets sind keine besonderen Überlegungen erforderlich. Möglicherweise müssen Sie jedoch Firewallregeln konfigurieren, um zu gewährleisten, dass Google Cloud-VMs mit lokalen Arbeitslasten kommunizieren können.

Preise

Für die Verwendung von Hybrid Subnets fallen keine zusätzlichen Gebühren an. Ihnen werden jedoch Ressourcen und Netzwerktraffic im Google Cloud-Teil eines Hybridsubnetzes in Rechnung gestellt.

Weitere Informationen finden Sie unter Virtual Private Cloud – Preise.

Nächste Schritte