Migration zu Google Cloud mit 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. Durch die Kombination eines Subnetzes im Quellnetzwerk mit einem VPC-Subnetz 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.

Mit Hybrid Subnets können Sie auch VMs von Google Cloudzu einem lokalen Netzwerk oder zwischen zwei VPC-Netzwerken migrieren.

Ein dreistufiges Diagramm veranschaulicht die Migration von Arbeitslasten von On-Premise zu Google Cloud mithilfe von Hybrid-Subnetzen.
Abbildung 1. Während der Migration stellt ein Hybridsubnetz eine Verbindung zwischen Arbeitslasten in einem Quellnetzwerk und einem VPC-Netzwerk her (zum Vergrößern klicken).

Spezifikationen

Für Hybrid-Subnetze gelten die folgenden Spezifikationen.

  • Eigenschaften:
    • Ein Hybridsubnetz ist ein einzelnes logisches Subnetz, das ein Segment eines Quellnetzwerks mit einem Subnetz in einem VPC-Netzwerk kombiniert.
    • Die interne Verbindung wird zwischen allen VMs und Arbeitslasten in einem Hybridsubnetz beibehalten.
    • Das Quellnetzwerk kann ein lokales Netzwerk oder ein anderes VPC-Netzwerk sein. Das Segment kann ein ganzes Subnetz oder ein Teil davon sein.
    • Die beiden Teile eines Hybrid-Subnetzes müssen über ein Netzwerkverbindungsprodukt wie Cloud VPN oder Cloud Interconnect verbunden sein.
    • Der primäre IPv4-Adressbereich des VPC-Subnetzes muss mit dem Bereich des Segments des Quellnetzwerks übereinstimmen, das vom Hybridsubnetz verwendet wird.
  • VPC-Netzwerkkonfiguration:
    • Sie müssen Hybridsubnetzrouting aktivieren, um ein VPC-Subnetz als Teil eines Hybridsubnetzes zu konfigurieren. Wenn das Hybridsubnetz-Routing aktiviert ist, können benutzerdefinierte Routen mit den primären und sekundären IPv4-Adressbereichen von Subnetzen in Konflikt geraten (sich überschneiden).
    • Sie verwenden benutzerdefinierte beworbene Routen von Cloud Router, um die IP-Adressen von VMs selektiv bei der Migration zum VPC-Subnetz anzubieten. Zur Unterstützung von Proxy-ARP und der längsten Präfixübereinstimmung müssen diese Routen spezifischer sein (eine längere Subnetzmaske haben) als der IP-Adressbereich des Hybridsubnetzes. Sie können /32-Routen für einzelne VMs verwenden.
  • Quellnetzwerkkonfiguration:
    • Sie müssen Proxy-ARP im Quellnetzwerk konfigurieren.
    • Sie müssen das Quellnetzwerk so konfigurieren, dass der IP-Adressbereich des Hybridsubnetzes angekündigt wird.
Ein Cloud Router und ein lokaler Router übernehmen das Routing zwischen den beiden Teilen eines hybriden Subnetzes, das einen gemeinsamen, sich überschneidenden IP-Adressbereich verwendet.
Abbildung 2. Dieses Diagramm bietet einen Überblick über die Schritte zum Erstellen eines Hybridsubnetzes und darüber, wie ein Cloud Router und ein lokaler Router Pakete zwischen den beiden Teilen eines Hybridsubnetzes weiterleiten (zum Vergrößern klicken).

Hybridsubnetzrouting

Ein Hybridsubnetz kombiniert ein Subnetz in einem Quellnetzwerk mit einem VPC-Subnetz, um ein einzelnes logisches Subnetz zu erstellen. Arbeitslasten in beiden Teilen des Hybrid-Subnetzes behalten die interne Konnektivität bei. Eine Arbeitslast kann Traffic an ein Ziel in einem der beiden Teile des Hybrid-Subnetzes senden, als wäre es lokal, unabhängig vom Standort des Ziels.

VPC-Netzwerkrouting

Wenn das Ziel eines Pakets im Schritt zum Abgleichen von Subnetzrouten des VPC-Routingmodells mit einer lokalen oder Peering-Subnetzroute übereinstimmt, versucht Google Cloud ,das Paket über die übereinstimmende Subnetzroute zuzustellen. Wenn in einem regulären Subnetz das Ziel nicht mit einer aktiven VM oder einer internen Weiterleitungsregel verknüpft ist, wird das Paket verworfen und alle anderen Routen werden ignoriert.

Wenn das Hybridsubnetz-Routing für das Subnetz aktiviert ist, wird die Subnetzroute jedoch zu einer Hybridsubnetzroute und das Routingverhalten ist anders:

  • Wenn das Paket einer laufenden VM-Instanz oder einer internen Weiterleitungsregel im VPC-Subnetz zugeordnet ist, Google Cloudwird das Paket basierend auf der lokalen Hybrid-Subnetzroute zugestellt.
  • Wenn das Paket nicht mit einer laufenden VM oder einer internen Weiterleitungsregel im VPC-Subnetz verknüpft ist, Google Cloud wird ein spezielles Routingverfahren für nicht übereinstimmende Ressourcen verwendet. Dabei wird geprüft, ob benutzerdefinierte dynamische und statische Routen mit dem Bereich des Hybridsubnetzes überschneiden. In einem richtig konfigurierten hybriden Subnetz werden Pakete über eine lokale dynamische Route, die der Cloud Router für das Quellsubnetz erkennt, an das Quellnetzwerk weitergeleitet.
In einem Hybridsubnetz wird Paket A lokal weitergeleitet und Paket B an ein lokales Ziel.
Abbildung 3. VMs in einem hybriden Subnetz können Ziele in einem lokalen Subnetz und einem VPC-Netzwerk-Subnetz erreichen, obwohl beide Subnetze denselben überlappenden IP-Adressbereich haben (zum Vergrößern klicken).

In Abbildung 3 wird beispielsweise Paket A mithilfe einer lokalen Hybrid-Subnetzroute an eine VM im VPC-Teil eines Hybrid-Subnetzes weitergeleitet. Das Ziel von Paket B ist nicht mit einer ausgeführten VM oder einer internen Weiterleitungsregel im VPC-Teil des Hybrid-Subnetzes verknüpft. Daher sucht Google Cloud nach in Konflikt stehenden benutzerdefinierten Routen. Es wird eine Übereinstimmung gefunden und Google Cloud verwendet die sich überschneidende benutzerdefinierte dynamische Route, um Paket B an das Quellnetzwerk zu senden.

Quellnetzwerk-Routing

Wenn eine Arbeitslast im Quellnetzwerk ein Paket an ein Ziel im IP-Adressbereich des hybriden Subnetzes sendet, führt der Router oder das First-Hop-Gerät des Quellnetzwerks eine Routingtabellensuche durch.

Wenn das Ziel mit einer Arbeitslast im Quellnetzwerk verknüpft ist, greift der Router nicht in Proxy-ARP ein. Das Ziel empfängt die ARP-Anfrage und antwortet mit seiner eigenen MAC-Adresse. Das Paket wird lokal zugestellt.

Wenn sich das Ziel im VPC-Teil des hybriden Subnetzes befindet und der Router eine dynamische Route für das Ziel erkannt hat, die spezifischer als die lokale Subnetzroute ist, wählt der Router die dynamische Route mithilfe des längsten Präfixabgleichs aus. Dadurch wird die Proxy-ARP-Funktion des Routers ausgelöst. Der Router antwortet mit seiner eigenen MAC-Adresse und leitet das Paket an den Cloud Router im VPC-Netzwerk weiter.

Ein lokaler Router verwendet Proxy-ARP, um ein Paket von einer Arbeitslast in einem Quellnetzwerk an eine VM weiterzuleiten, die zu Google Cloudmigriert wurde .
Abbildung 4. Ein lokaler Router verwendet Proxy-ARP, um ein Paket von einer Arbeitslast in einem Quellnetzwerk an eine VM weiterzuleiten, die zu Google Cloudmigriert wurde (zum Vergrößern klicken).

Beschränkungen

Für Hybrid-Subnetze gelten die folgenden Einschränkungen.

  • Ressourcenbeschränkungen:

    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.

  • Nicht unterstützte Verkehrsinformationen und Routen:

    • Pakete werden verworfen, wenn der nächste Hop einer in Konflikt stehenden Route sich in einer anderen Region als das hybride Subnetz befindet.
    • Die folgenden Routentypen werden nicht als in Konflikt stehende Routen unterstützt:
      • Vom System generierte Standardrouten
      • Richtlinienbasierte Routen
      • Statische Routen mit Netzwerk-Tags
      • Routen mit Zielen, die die hybride Subnetzroute enthalten oder breiter als diese sind
    • Network Connectivity Center wird mit Hybridsubnetzen nicht vollständig unterstützt. Sie können ein VPC-Netzwerk, das ein Hybrid-Subnetz enthält, als Spoke eines Network Connectivity Center-Hubs konfigurieren. Der Traffic von verbundenen Spokes zum IP-Adressbereich des Hybrid-Subnetzes hat jedoch ein unvorhersehbares Routingverhalten.
    • Hybrid-NAT wird mit Hybrid Subnets nicht unterstützt. Sie können zwar ein Hybridsubnetz für die Verwendung von Hybrid NAT konfigurieren, die Funktion wird jedoch nicht auf Traffic angewendet, der vom Hybridsubnetz-Routing betroffen ist.
    • Das Routing von Hybridsubnetzen gilt nicht für IPv6-Traffic.
    • 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.
    • Der Cloud Router eines hybriden Subnetzes darf die maximale Anzahl von benutzerdefinierten beworbenen Routen pro BGP-Sitzung nicht überschreiten.
    • 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.

  • Nicht unterstützte Migrationsszenarien:

    • Hybrid Subnets unterstützen keine Migration von Arbeitslasten von anderen Cloud-Anbietern.
    • Hybrid Subnets unterstützen die Migration von VMs aus einer Azure- oder AWS-Quelle nicht.
    • Hybrid Subnets unterstützen keine Site-to-Site-Datenübertragung.
    • 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.

  • Weitere Einschränkungen:

    • Bei Hybrid Subnets 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 können keine Arbeitslasten an den reservierten IP-Adressen in IPv4-Subnetzen hosten.
    • Arbeitslasten im Quellnetzwerk können keine Endpunkte für Netzwerk-Endpunktgruppen mit Hybridkonnektivität sein, die zentrale Systemdiagnosen verwenden.
    • Die eingehende Weiterleitung von Cloud DNS reagiert nicht auf DNS-Anfragen von Arbeitslasten im Quellnetzwerk.

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 zur Planung einer Migration mit Migrate to Virtual Machines finden Sie unter 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 beschrieben.

Proxy-ARP und Hybrid Subnets

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

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.

Einschränkung der Regionalität

Damit ein hybrides Subnetz ordnungsgemäß funktioniert, müssen alle Next Hops von in Konflikt stehenden Routen (benutzerdefinierte Routen, die sich mit dem Adressbereich des hybriden Subnetzes überschneiden) in derselben Region wie das hybride Subnetz sein.

Wenn eine in Konflikt stehende Route Next Hops in einer anderen Region hat:

  • Wenn die Route sowohl lokale als auch Remote-Hops enthält, wird der Traffic verworfen, wenn ECMP einen Hop in einer Remote-Region auswählt. Das Paket wird auch dann verworfen, wenn es auch einer weniger spezifischen Route entspricht, die nächste Hops in derselben Region hat.
  • Wenn die Route keine nächsten Hops in derselben Region wie das hybride Subnetz hat, wird das Paket verworfen.

Die folgenden Ressourcen müssen sich in derselben Region befinden:

  • Das VPC-Subnetz, das als Hybridsubnetz konfiguriert ist
  • Der Cloud Router, der Routen zu Ihrem Quellnetzwerk lernt
  • Die HA VPN-Tunnel oder VLAN-Anhänge, die für die Hybridkonnektivität sorgen

Angenommen, es gibt ein hybrides Subnetz mit dem IP-Adressbereich 192.0.2.0/24. Das VPC-Subnetz befindet sich in der Region us-central1. Der Cloud Router hat zwei in Konflikt stehende Routen erkannt:

  • Eine benutzerdefinierte Route mit dem Zielbereich 192.0.2.0/25 und einem nächsten Hop in der Region us-central1
  • Eine benutzerdefinierte 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 laufenden VM oder einer internen Weiterleitungsregel im VPC-Subnetz verknüpft. Das Routenauswahlmodell wählt daher 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 hybriden Subnetzes, daher wird das Paket verworfen.

Weitere Informationen finden Sie unter Nicht übereinstimmende Ressourcen in Hybrid Subnets.

VPC-Netzwerk-Peering

Sie können ein hybrides Subnetz über VPC-Netzwerk-Peering mit einem Peer-VPC-Netzwerk verbinden. Das VPC-Netzwerk des hybriden Subnetzes muss so konfiguriert sein, dass Subnetz- und benutzerdefinierte Routen exportiert werden. Das Peering-VPC-Netzwerk muss so konfiguriert sein, dass sie importiert werden.

Wenn das Peering-VPC-Netzwerk die Routen programmiert hat, kann es Ziele im IP-Adressbereich des Hybridsubnetzes erreichen, unabhängig davon, ob sie in Google Cloud oder im Quellnetzwerk vorhanden sind.

Die Routen werden in den folgenden Fällen nicht für das Peering-Netzwerk programmiert:

  • Eine lokale Subnetzroute im Peering-Netzwerk hat einen Zielbereich, der mit dem der importierten Route identisch ist.
  • Das Kontingent für dynamische Routen pro Region und Peering-Gruppe wurde überschritten.
  • Die beiden VPC-Netzwerke sind nicht direkt per Peering verbunden. Das VPC-Netzwerk-Peering ist nicht transitiv.

Wenn eine dieser Bedingungen zutrifft, funktioniert das hybride Subnetz aus Sicht des VPC-Netzwerk mit Peering nicht richtig.

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, die 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