Über Hybrid Subnets

Mit Hybrid Subnets können Sie Arbeitslasten aus einem anderen Netzwerk (dem Quellnetzwerk) zu einem VPC-Subnetz (Virtual Private Cloud) migrieren, ohne IP-Adressen ändern zu müssen. Dieser Migrationsprozess wird als „Migrate Motion“ bezeichnet. Wenn Sie ein Subnetz im Quellnetzwerk mit einem VPC-Subnetz kombinieren, erstellen Sie ein einzelnes logisches Subnetz, mit dem Sie einzelne Arbeitslasten und VM-Instanzen (virtuelle Maschinen) im Laufe der Zeit migrieren können. Nachdem alle Arbeitslasten und VMs migriert wurden, können Sie das Quellsubnetz außer Betrieb nehmen.

In einem Hybridsubnetz bieten ein Router in einem Quellnetzwerk und ein Cloud Router in einem VPC-Netzwerk Routen mit dem Border Gateway Protocol (BGP) an (zum Vergrößern klicken).

Migrationsoptionen

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

Hybrid Subnets unterstützen Google Cloud VMware Engine nicht als Migrationsziel. Wenn VMware Engine Ihr Migrationsziel ist, empfehlen wir, VMware-VMs mit VMware HCX zu migrieren. Sie müssen keine Hybrid Subnets konfigurieren, wenn Sie VMware HCX für die Migration zu Google Cloud VMware Engine verwenden.

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.

Weitere Informationen zu Migrationsoptionen finden Sie unter Migrationsressourcen.

Informationen zum Planen einer Migration mit Migrate to VMs finden Sie unter Migrationsprozess mit Migrate to Virtual Machines.

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

Spezifikationen

  • Für Hybrid Subnets ist ein Netzwerkverbindungsprodukt wie Cloud VPN oder Cloud Interconnect erforderlich.
  • Proxy-ARP muss im Quellnetzwerk konfiguriert sein.
  • Das Quellnetzwerk muss so konfiguriert sein, dass der IP-Adressbereich des Hybridsubnetzes angekündigt wird.
  • Der primäre IPv4-Adressbereich des VPC-Subnetzes muss mit dem IP-Adressbereich des Quellsubnetzes ü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, Google Cloud können sich benutzerdefinierte Routen mit den IP-Adressbereichen des Subnetzes überschneiden.
  • Das Flag allow-cidr-routes-overlap gilt für primäre und sekundäre IPv4-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 Quellnetzwerk zu Google Cloudmigrieren, aktualisieren Sie die benutzerdefinierten beworbenen Routen des Cloud Router, um die IP-Adressen der migrierten VMs aufzunehmen.
  • Sie können ein hybrides Subnetz über VPC-Netzwerk-Peering mit einem Peer-VPC-Netzwerk verbinden. Die Peering-Konfiguration für das VPC-Netzwerk, das das hybride Subnetz enthält, muss so konfiguriert sein, dass benutzerdefinierte Routen exportiert werden. Die Peering-Konfiguration für das andere VPC-Netzwerk muss für den Import benutzerdefinierter Routen konfiguriert sein.

Beschränkungen

  • Für VPC-Netzwerke, die Hybrid Subnets verwenden, gelten die folgenden Ressourcenlimits:

    Diese Ressourcenbeschränkungen werden nicht durch Google Cloud -Limits oder ‑Kontingente erzwungen. Das Überschreiten dieser Beschränkungen kann zu Verbindungs- und Stabilitätsproblemen führen.

  • Der Cloud Router eines hybriden Subnetzes 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 können keine Arbeitslasten an den reservierten IP-Adressen in IPv4-Subnetzen hosten.

  • Die eingehende Weiterleitung von Cloud DNS reagiert nicht auf DNS-Anfragen von Arbeitslasten im Quellnetzwerk.

  • Arbeitslasten im Quellnetzwerk können nicht über den privater Google-Zugriff auf Google APIs und Dienste zugreifen.

  • Arbeitslasten im Quellnetzwerk können keine Private Service Connect-Endpunkte für Google APIs erreichen.

  • Arbeitslasten im Quellnetzwerk können keine Endpunkte für Netzwerk-Endpunktgruppen mit Hybridkonnektivität sein, die zentrale Systemdiagnosen verwenden.

  • Hybrid Subnets unterstützen keine Site-to-Site-Datenübertragung.

  • Sie können kein Hybridsubnetz mit einem anderen Hybridsubnetz verbinden.

  • Bei Hybridsubnetzen werden keine IP-Adresskonflikte zwischen dem Quellnetzwerk und den VPC-Teilen eines Hybridsubnetzes erkannt. Achten Sie darauf, dass jede IP-Adresse (mit Ausnahme des Standardgateways) nur einmal verwendet wird.

  • Hybrid Subnets unterstützen Google Cloud VMware Engine nicht als Migrationsziel.

  • Hybrid Subnets unterstützen die Migration von VMs aus einer Azure- oder AWS-Quelle nicht.

  • Mit Hybrid Subnets können keine Arbeitslasten von anderen Cloud-Dienstanbietern migriert werden.

  • Hybrid Subnets unterstützen Network Connectivity Center nicht.

Hinweise zur Verwendung von Hybrid Subnets

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

Proxy-ARP und Hybrid Subnets

Für Hybrid Subnets muss Proxy-ARP auf dem First-Hop-Gerät des Quellnetzwerks konfiguriert sein. Ein First-Hop-Gerät ist der Punkt, an dem ein Host zum ersten Mal Traffic mit einem Ziel außerhalb seines lokalen Netzwerks sendet. Mit Proxy-ARP kann das Gerät mit seiner eigenen MAC-Adresse antworten, wenn es ARP-Anfragen für VMs empfängt, die sich im VPC-Teil eines Hybridsubnetzes befinden. Das Gerät kann dann Pakete mithilfe der CIDR-Blöcke, die es aus den benutzerdefinierten beworbenen Routen der BGP-Sitzung (Border Gateway Protocol) auf dem Cloud Router ermittelt hat, an VMs im VPC-Subnetz weiterleiten.

Das First-Hop-Gerät kann ein Router, eine virtuelle Appliance, eine Firewall oder eine VM sein, auf der eine Softwarelösung wie choparp ausgeführt wird.

Wir empfehlen Folgendes für die Verwendung von Proxy-ARP in Ihrem Quellnetzwerk:

  • Wenden Sie sich an den Anbieter Ihres Quellnetzwerk-Fabrics, um Best Practices zum Aktivieren von Proxy-ARP und zum Sichern Ihrer Netzwerkumgebung zu erhalten.
  • Deaktivieren Sie Proxy-ARP, nachdem Sie die Migration zuGoogle Cloudabgeschlossen haben.

Netzwerkleistung

Hybrid Subnets verwenden das Layer 3 des OSI-Modells, um Pakete zwischen dem Quellnetzwerk 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 Quellnetzwerk vorhanden sind, andere Arbeitslasten jedoch in die Cloud migriert wurden.

Insbesondere wird durch das Vermeiden von Layer 2-Tunneling die Leistungsbeeinträchtigung verhindert, 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 manchmal als Network Tromboning 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.

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, damit Google Cloud -VMs mit Arbeitslasten im Quellnetzwerk kommunizieren können.

Preise

Für die Verwendung von Hybrid Subnets fallen keine zusätzlichen Gebühren an. Sie werden jedoch für Ressourcen und Netzwerk-Traffic im VPC-Teil eines hybriden Subnetzes in Rechnung gestellt.

Weitere Informationen finden Sie unter Virtual Private Cloud – Preise.

Nächste Schritte