Informationen zur Migration zu Google Cloud mit Hybrid Subnets

Auf dieser Seite wird beschrieben, wie Sie das Hybridsubnetz-Routing verwenden können, um Arbeitslasten zu Google Cloudmigrieren.

Mit dem Hybridsubnetz-Routing kann ein VPC-Netzwerk einen CIDR-Block mit einem verbundenen lokalen Netzwerk gemeinsam nutzen. Wenn ein Paket mit einer Hybridsubnetz-Route übereinstimmt, die Ziel-IP-Adresse jedoch nicht mit einer Ressource in diesem Subnetz verknüpft ist, kann das Paket mithilfe dynamischer oder statischer Routen an das lokale Netzwerk weitergeleitet werden.Google Cloud

Mit dieser Konfiguration können Sie Arbeitslasten zu Google Cloud inkrementell zu migrieren, ohne ihre IP-Adressen ändern zu müssen. Während der Migration können Arbeitslasten, die zu Ihrem VPC-Netzwerk migriert wurden, über interne IP-Adressen mit Arbeitslasten kommunizieren, die sich noch im lokalen Netzwerk befinden. Nachdem alle Arbeitslasten migriert wurden, können Sie das Hybridsubnetz-Routing deaktivieren, um das normale Routingverhalten wiederherzustellen.

Für die Migration zu Google Cloud mit Hybrid Subnets sind drei verschiedene Komponenten erforderlich, die zusammenarbeiten:

• Verbindung: Ihre lokalen und VPC-Netzwerke müssen über ein Netzwerkverbindungsprodukt wie Cloud VPN oder Cloud Interconnect verbunden sein. Hybrid Subnets bietet diese Verbindung nicht von selbst.
• Hybridsubnetz-Routing: Sie müssen das Hybridsubnetz-Routing aktivieren, indem Sie das Flag allow-cidr-routes-overlap auf eine Subnetzressource anwenden.
• Migrationstool: Sie benötigen ein Migrationstool wie Migrate to Virtual Machines, um Arbeitslasten zu Google Cloudmigrieren.

Abbildung 1. Während der Migration können Arbeitslasten in einem lokalen Netzwerk über das Hybridsubnetz-Routing mit Arbeitslasten in einem verbundenen VPC-Netzwerk kommunizieren, auch wenn Subnetze in beiden Netzwerken denselben CIDR-Block verwenden (zum Vergrößern klicken).

Spezifikationen

Damit Hybrid Subnets die Migration von Arbeitslasten zu Google Cloud aus einem lokalen Netzwerk unterstützen kann, muss Ihre Umgebung die folgenden Anforderungen erfüllen.

• Verbindungsanforderungen:
  • Ihre lokalen und VPC-Netzwerke müssen über ein Netzwerkverbindungsprodukt wie Cloud VPN oder Cloud Interconnect verbunden sein.
  • Die HA VPN-Tunnel oder VLAN-Anhänge, Cloud Router und Subnetze, für die das Hybridsubnetz-Routing aktiviert ist, müssen sich alle in derselben Region befinden.
• VPC-Netzwerkkonfiguration:
  • Ein IPv4-Adressbereich des Subnetzes, für das das Hybridsubnetz-Routing aktiviert ist, muss mit einem CIDR-Block im lokalen Netzwerk übereinstimmen, in dem die zu migrierenden Arbeitslasten gehostet werden. In den meisten Anwendungsfällen stimmt der primäre IPv4-Adressbereich des Subnetzes mit einem CIDR-Block im lokalen Netzwerk überein.
  • Sie müssen das Hybridsubnetz-Routing aktivieren. Wenn das Hybridsubnetz-Routing aktiviert ist, werden die Regeln für Interaktionen zwischen Subnetzrouten und statischen Routen sowie die Regeln für Interaktionen zwischen Subnetzrouten und dynamischen Routen nicht erzwungen. Lokale und Peering-statische oder dynamische Routen können auch dann vorhanden sein, wenn ihre Ziele mit dem primären IPv4-Adressbereich des Subnetzes oder einem seiner sekundären IPv4-Adressbereiche übereinstimmen oder in diese passen.
  • Sie müssen benutzerdefinierte beworbene Routen für Cloud Router konfigurieren, um die IP-Adressen von VMs selektiv zu bewerben, wenn Sie sie zu Ihrem VPC-Netzwerk migrieren. Zur Unterstützung von Proxy-ARP und der längsten Präfixübereinstimmung müssen diese benutzerdefinierten beworbenen Routen spezifischer sein (eine längere Subnetzmaske haben) als der IPv4-Adressbereich des Subnetzes, für das das Subnetz-Routing aktiviert ist. Sie können eine benutzerdefinierte beworbene /32-Route für jede IP-Adresse einer migrierten VM verwenden.
• Lokale Netzwerkkonfiguration:
  • Sie müssen Proxy-ARP für den lokalen Router konfigurieren.
  • Sie müssen den lokalen Router so konfigurieren, dass er den IP-Adressbereich des freigegebenen CIDR-Blocks bewirbt.

Abbildung 2. Dieses Diagramm fasst zusammen, wie Sie ein VPC-Netzwerk und ein lokales Netzwerk konfigurieren, um die interne Verbindung über einen freigegebenen CIDR-Block aufrechtzuerhalten (zum Vergrößern klicken).

Hybridsubnetz-Routing

Nachdem Sie die Konfiguration abgeschlossen haben, die in den Hybrid Subnets-Spezifikationen beschrieben ist, können VMs in beiden Netzwerken über interne IP-Adressen kommunizieren.

In den folgenden Abschnitten wird das Routingverhalten im VPC-Netzwerk, das ein Subnetz mit aktiviertem Hybridsubnetz-Routing enthält, und in einem lokalen Netzwerk beschrieben, sobald diese Konfiguration eingerichtet ist.

Routing im VPC-Netzwerk

Wenn im Schritt „Subnetzrouten abgleichen“ des VPC-Routing Modells das Ziel eines Pakets mit einer lokalen oder Peering-Subnetzroute übereinstimmt, Google Cloud versucht,das Paket über die übereinstimmende Subnetzroute zu senden. Wenn das Ziel in einem regulären Subnetz nicht mit einer ausgeführten VM oder einer internen Weiterleitungsregel verknüpft ist, wird das Paket verworfen und alle anderen Routen werden ignoriert.

Wenn jedoch das Hybridsubnetz-Routing für das Subnetz aktiviert ist, wird die Subnetzroute zu einer Hybridsubnetz-Route und das Routingverhalten ändert sich:

• Übereinstimmende Ressourcen: Wenn das Ziel des Pakets mit der Netzwerkschnittstelle einer ausgeführten VM-Instanz oder einer internen Weiterleitungsregel im Subnetz übereinstimmt,sendet das Paket an die Schnittstelle oder Weiterleitungsregel. Google Cloud Dieses Verhalten ist dasselbe wie in einem regulären Subnetz.
• Nicht übereinstimmende Ressourcen: Wenn das Ziel des Pakets nicht mit einer Ressource im Subnetz übereinstimmt, Google Cloud folgt dem Prozess für nicht übereinstimmende Ressourcen in Hybridsubnetzen. Bei diesem Prozess werden Pakete an die nächsten Hops lokaler oder Peering-statischer oder dynamischer Routen weitergeleitet, sofern diese nächsten Hops sich in derselben Region wie das Hybridsubnetz befinden. Die lokalen oder Peering-statischen oder dynamischen Routen bieten einen Pfad, um das Paket an das lokale Netzwerk zu senden.

Abbildung 3. Wenn das Ziel eines Pakets in einem Subnetz, das das Hybridsubnetz-Routing verwendet,mit einer Ressource im Subnetz übereinstimmt, Google Cloud leitet den Traffic an diese Ressource weiter. Für nicht übereinstimmende Ressourcen Google Cloud verwendet den Prozess für nicht übereinstimmende Ressourcen in Hybridsubnetzen (zum Vergrößern klicken).

In Abbildung 3 wird beispielsweise Paket A über eine lokale Hybridsubnetz-Route an eine VM im lokalen Subnetz weitergeleitet. Das Ziel von Paket B ist nicht mit einer ausgeführten VM oder einer internen Weiterleitungsregel im Subnetz verknüpft, das das Hybridsubnetz-Routing verwendet. sucht daher nach dynamischen oder statischen Routen, die in den Zielbereich der Hybridsubnetz-Route passen. Google Cloud Es wird eine Übereinstimmung gefunden und Google Cloud verwendet die dynamische Route, um Paket B an das lokale Netzwerk zu senden.

Routing im lokalen Netzwerk

In diesem Abschnitt wird das Routingverhalten in einem lokalen Netzwerk beschrieben. In diesem Beispiel ist das lokale Netzwerk über Cloud VPN-Tunnel mit einem VPC-Netzwerk verbunden.

Wenn eine Client-VM im lokalen Netzwerk ein Paket an eine Server-VM sendet, die sich im CIDR-Block befindet, der von den beiden Netzwerken gemeinsam genutzt wird, führt der Router oder das First-Hop-Gerät des lokalen Netzwerks eine Routentabellensuche durch:

• Wenn die Server-VM mit einer IP-Adresse im lokalen Netzwerk verknüpft ist, greift der lokale Router nicht mit Proxy-ARP ein. Die Server-VM antwortet auf ARP-who-has-Pakete von der Client-VM mit Antworten, die die MAC-Adresse des Servers enthalten. Die Client-VM sendet einen Ethernet-Frame an die Server-VM.

• Wenn die Server-VM nicht mit einer IP-Adresse im lokalen Netzwerk verknüpft ist und der lokale Router ein spezifisches benutzerdefiniertes Route Advertisement von den Cloud Router-BGP-Sitzungen der Cloud VPN-Tunnel im VPC-Netzwerk erhalten hat, greift der lokale Router mit Proxy-ARP ein. Der lokale Router antwortet auf ARP-who-has-Pakete von der Client-VM mit Antworten, die die MAC-Adresse des Routers enthalten. Die Client-VM sendet einen Ethernet-Frame an den lokalen Router. Der lokale Router extrahiert das IP-Paket und leitet es an einen der Cloud VPN-Tunnel weiter. Dadurch wird das Paket an die VM im Subnetz gesendet, für das das Hybridsubnetz-Routing aktiviert ist.

Abbildung 4. Ein lokaler Router verwendet Proxy-ARP, um ein Paket von einer Arbeitslast im lokalen Netzwerk an eine VM weiterzuleiten, die zu Google Cloud migriert wurde(zum Vergrößern klicken).

Beschränkungen

Für Hybrid Subnets gelten die folgenden Einschränkungen.

• IP-Adressverwaltung und unterstützter Traffic:

  • IPv6: Hybrid Subnets unterstützt keinen IPv6-Traffic.

  • Broadcast und Multicast: Hybrid Subnets unterstützt keinen Broadcast- und Multicast-Traffic.

  • IP-Adresskonflikte: Hybrid Subnets erkennt keine IP Adresskonflikte zwischen Ressourcen im lokalen Netzwerk und im VPC-Netzwerk, das das Subnetz mit aktiviertem Hybrid subnetz-Routing enthält. Achten Sie darauf, dass jede IP-Adresse, mit Ausnahme des Standardgateways, nur einmal verwendet wird.

  • Nicht verwendbare Adressen: Die ersten beiden und die letzten beiden IPv4-Adressen im primären IPv4-Adressbereich eines Subnetzes können von keiner Google Cloud Ressource verwendet werden. Diese Regel bleibt auch dann gültig, wenn Sie das Hybridsubnetz-Routing aktivieren. Weitere Informationen finden Sie unter Nicht verwendbare Adressen in IPv4-Subnetz bereichen.

• Nicht übereinstimmende Regionen: Pakete werden verworfen, wenn sich der nächste Hop einer übereinstimmenden statischen oder dynamischen Route innerhalb des Zielbereichs der übereinstimmenden Hybrid subnetz-Route in einer anderen Region als der Region des Subnetzes befindet. Weitere Informationen finden Sie unter Einschränkung der Regionalität.

• Statische Routen mit Netzwerk-Tags: Achten Sie darauf, dass für keine übereinstimmende statische Route innerhalb des Zielbereichs der übereinstimmenden Hybridsubnetz-Route Netzwerk-Tags verwendet werden. Übereinstimmende statische Routen, die Netzwerk-Tags verwenden, führen bei hohen Paketraten zu Paketverlusten.

• Nicht unterstützte Produktinteraktionen: Verwenden Sie Hybrid Subnets nicht mit den folgenden Produkten.

  • Network Connectivity Center (NCC): NCC wird mit Hybrid Subnets nicht unterstützt. Google Cloud verhindert nicht, dass Sie Subnetze mit aktiviertem Hybridsubnetz-Routing in einen NCC-Hub exportieren. Dies kann jedoch zu unvorhersehbarem Routingverhalten führen.

  • Hybride Konnektivitäts-NEGs: Die Systemdiagnose-Probesysteme von Google für zentrale Systemdiagnosen können nicht mit Endpunkten in einem hybriden NEG kommunizieren, wenn die Endpunkte in eine Hybridsubnetz-Route passen.

  • Hybrid NAT: Hybrid NAT wird mit Hybrid Subnets nicht unterstützt. Hybrid NAT führt kein Quell-NAT (SNAT) für Pakete aus, die von VMs an Ziele in einer statischen oder dynamischen Route gesendet werden, wenn zuerst eine Hybridsubnetz-Route übereinstimmt.

Beachten Sie auch die folgenden praktischen Einschränkungen.

• Das lokale Netzwerk muss Proxy-ARP unterstützen: Hybrid Subnets unterstützt die Migration von Arbeitslasten aus Remote-Netzwerken anderer Cloud-Anbieter wie Azure oder AWS nicht, da diese Remote-Netzwerke kein Proxy-ARP unterstützen.

• Das lokale Netzwerk muss /32 Route Advertisements akzeptieren: Wenn Sie Layer 3 Partner Interconnect verwenden, fragen Sie den Partner, ob er den Empfang von /32 Präfixen unterstützt.

Migrationsoptionen

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

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.

Informationen zum Planen einer Migration mit Migrate to Virtual Machines, siehe Migrationsprozess mit Migrate to VMs.

Weitere Informationen zu Migrationsoptionen finden Sie unter Migrationsressourcen.

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

Hinweise zur Verwendung von Hybrid Subnets

In den folgenden Abschnitten werden Überlegungen zur Verwendung von Hybrid Subnets für die Migration von Arbeitslasten zu Google Cloudbeschrieben.

Proxy-ARP und Hybrid Subnets

Bei Hybrid Subnets muss Proxy-ARP auf dem Router oder dem First-Hop-Gerät des lokalen Netzwerks konfiguriert sein. Das First-Hop-Gerät ist der Punkt, an dem ein Host zum ersten Mal Traffic sendet, der ein Ziel außerhalb des lokalen Netzwerks hat.

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

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

• Wenden Sie sich an Ihren Anbieter von Netzwerkkomponenten, um Best Practices zum Aktivieren von Proxy-ARP und zum Sichern Ihrer Netzwerkumgebung zu erhalten.
• Deaktivieren Sie Proxy-ARP, nachdem Sie die Migration zu Google Cloudabgeschlossen haben.

Einschränkung der Regionalität

**Achtung** :Damit das Hybridsubnetz-Routing ordnungsgemäß funktioniert, müssen alle nächsten Hops von statischen und dynamischen Routen mit Zielbereichen, die in Hybridsubnetz-Routen passen, sich in derselben Region wie das Subnetz befinden, das das Hybridsubnetz Routing verwendet.

Diese Einschränkung gilt, wenn Traffic mit einer Hybridsubnetz-Route übereinstimmt, die Ziel-IP-Adresse jedoch nicht mit einer ausgeführten VM oder einer internen Weiterleitungsregel verknüpft ist. Während des Schritts „Nicht übereinstimmende Ressourcen in Hybridsubnetzen“ des Routenauswahlmodells von Google Cloud werden Routen so ausgewertet, als ob sich die Quelle eines Pakets im selben VPC-Netzwerk wie die Hybridsubnetz-Route befindet.

Wenn eine statische oder dynamische Route mit einem Zielbereich, der in eine Hybridsubnetz-Route passt, nächste Hops in einer anderen Region hat:

• Wenn die Route eine Mischung aus nächsten Hops hat, von denen sich einige in derselben Region wie die Hybridsubnetz-Route und einige in anderen Regionen befinden, wird der Traffic verworfen, wenn ECMP einen nächsten Hop in einer anderen Region als dem Subnetz auswählt. Dieser Paketverlust tritt auch dann auf, wenn das Paket auch mit einer weniger spezifischen Route übereinstimmt, die nächste Hops in der Region des Subnetzes hat.
• Wenn die Route keine nächsten Hops in derselben Region wie das Subnetz hat, das das Hybridsubnetz-Routing verwendet, wird das Paket verworfen.

Achten Sie darauf, dass sich die folgenden Ressourcen in derselben Region befinden:

• Das Subnetz, für das das Hybridsubnetz-Routing aktiviert ist
• Der Cloud Router, der Routen zu Ihrem lokalen Netzwerk lernt
• Die HA VPN-Tunnel oder VLAN-Anhänge, die die Hybridverbindung bereitstellen

Angenommen, es gibt ein Subnetz mit dem IP-Adressbereich 192.0.2.0/24, für das das Hybridsubnetz-Routing aktiviert ist. Das Subnetz befindet sich in der Region us-central1. Der Cloud Router hat zwei Routen mit Zielbereichen gelernt, die in die Hybridsubnetz-Route passen:

• Eine dynamische Route mit dem Zielbereich 192.0.2.0/25 und einem nächsten Hop in der Region us-central1
• Eine dynamische Route mit dem Zielbereich 192.0.2.0/30 und einem nächsten Hop in der Region us-west1.

Ein Paket wird an das Ziel 192.0.2.2 gesendet. Diese IP-Adresse ist nicht mit einer ausgeführten VM oder einer internen Weiterleitungsregel im lokalen Subnetz verknüpft. Daher wählt das Routenauswahlmodell die benutzerdefinierte Route mit dem spezifischsten Ziel aus, nämlich 192.0.2.0/30. Diese Route hat keinen nächsten Hop in der Region des Subnetzes, daher wird das Paket verworfen.

Weitere Informationen finden Sie unter Nicht übereinstimmende Ressourcen in Hybridsubnetzen.

VPC-Netzwerk-Peering

Sie können ein VPC-Netzwerk, das ein Subnetz mit Hybridsubnetz-Routing enthält, über VPC-Netzwerk-Peering mit einem Peering-VPC-Netzwerk verbinden.

Traffic von Clients in einem Peering-Netzwerk kann Ziele innerhalb des freigegebenen CIDR-Blocks erreichen, unabhängig davon, ob es sich bei den Zielen um Google Cloud Ressourcen oder um das lokale Netzwerk handelt. Wenn das Ziel eines Pakets von einem Client im Peering-Netzwerk mit einer Peering-Hybridsubnetz-Route übereinstimmt und das Ziel nicht mit einer ausgeführten VM oder einer internen Weiterleitungsregel übereinstimmt, kann das Paket über eine statische oder dynamische Route im Peering-VPC-Netzwerk weitergeleitet werden.

Das Routing über eine statische oder dynamische Route im Peering-VPC-Netzwerk hängt nicht vom Austausch benutzerdefinierter Routen mit dem VPC-Netzwerk ab, das den Client enthält. Folgendes ist jedoch weiterhin relevant:

• Achten Sie darauf, dass die Nutzung des Kontingents für dynamische Routen pro Region und Peering-Gruppe im VPC-Netzwerk, das den Client enthält, unter dem Limit des Kontingents liegt.

• Achten Sie darauf, dass im VPC-Netzwerk des Clients keine anderen Routen für die Zielbereiche vorhanden sind, die mit den statischen oder dynamischen Routen im Peering-Netzwerk übereinstimmen, die in die Peering-Hybridsubnetz-Route passen.

Netzwerkleistung

Hybrid Subnets verwendet das Layer 3 des OSI-Modells, um Pakete zwischen den lokalen und den VPC-Netzwerken 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 das Vermeiden von Layer-2-Tunneling trägt dazu bei, die Leistungsbeeinträchtigung 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 manchmal als Netzwerk Tromboning bezeichnet.

Da Hybrid Subnets diesen Routingansatz verwendet, können Sie eine Leistung erwarten, die einem Netzwerk ohne Hybrid Subnets ähnlich ist oder mit diesem identisch ist.

Firewalls und Hybrid Subnets

Hybrid Subnets vermeidet 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. Sie müssen jedoch Firewallregeln konfigurieren, damit VMs mit Arbeitslasten im lokalen Netzwerk kommunizieren können. Google Cloud

Preise

Informationen zu den Preisen für Hybrid Subnets finden Sie unter Virtual Private Cloud-Preise.

Nächste Schritte

• Informationen zum Vorbereiten eines VPC-Netzwerk für die Konnektivität von Hybrid Subnets finden Sie unter Verbindung für Hybrid Subnets vorbereiten.