Peeringbasierte Dienste zu Private Service Connect migrieren

Viele Anbieter verwalteter Dienste verwenden VPC-Netzwerk-Peering, um Dienstnutzern in einem anderen Virtual Private Cloud-Netzwerk (VPC) eine Konnektivität zu bieten. Eine alternative Lösung ist die Verwendung von Private Service Connect.

In diesem Dokument wird beschrieben, wie Dienstersteller ihre peeringbasierten Dienste zu Private Service Connect migrieren und die IP-Adresse beibehalten können, die für den Zugriff auf den Dienst verwendet wird. Bei diesem Migrationsprozess müssen alle mit einem bestimmten Subnetz verbundenen Ressourcen gleichzeitig migriert werden.

Jeder Dienstersteller entscheidet selbst, ob und wann er zu Private Service Connect migriert. Wenn Sie wissen möchten, ob ein Dienstanbieter von der VPC-Netzwerk-Peering-Technologie zu Private Service Connect migriert, lesen Sie die Dienstdokumentation oder wenden Sie sich an den Dienstanbieter.

Peering-basierte Dienste migrieren

In diesem Beispiel für einen peeringbasierten Dienst sendet der Client vm1 Traffic an den Load Balancer 10.10.10.10 des Dienstes im VPC-Netzwerk des Dienstherstellers. Das Nutzernetzwerk hat eine Peering-Subnetzroute für das Erstellersubnetz, da die Netzwerke über VPC-Netzwerk-Peering verbunden sind.

Abbildung 1. Bei einem Peering-basierten Dienst können das VPC-Netzwerk des Nutzers und das VPC-Netzwerk des Diensterstellers über VPC-Netzwerk-Peering auf die jeweils andere Seite zugreifen (zum Vergrößern klicken).

Während der Migration werden die folgenden Aufgaben ausgeführt:

  • Der Ersteller stellt den Dienst in einem neuen VPC-Netzwerk in einem neuen Subnetz producer-subnet-2 bereit und veröffentlicht ihn über Private Service Connect.
  • Der Produzent erstellt einen internen Bereich, um den CIDR-Bereich des Produzenten-Subnetzes 10.10.10.0/24 zu reservieren.
  • Der Produzent löscht das ursprüngliche Subnetz producer-subnet-1 und alle darin enthaltenen Ressourcen.
  • Im VPC-Netzwerk des Nutzers wird ein Migrationssubnetz consumer-subnet-2 erstellt, das mit demselben CIDR-Bereich wie das Produzentensubnetz konfiguriert ist.
  • Im Migrationssubnetz wird ein Private Service Connect-Endpunkt erstellt, der mit derselben IP-Adresse konfiguriert ist, die zuvor von der Load Balancer-Weiterleitungsregel des Erstellers verwendet wurde.

Nach Abschluss der Migration kann der Client vm1 den Dienst weiterhin unter 10.10.10.10 erreichen. Diese IP-Adresse ist jetzt jedoch mit dem Private Service Connect-Endpunkt im VPC-Netzwerk des Nutzers verknüpft.

Abbildung 2. Nach der Migration senden Clients im VPC-Netzwerk des Nutzers Anfragen an den Private Service Connect-Endpunkt, der den Traffic an das VPC-Netzwerk des Erstellers weiterleitet (zum Vergrößern klicken).

Migrationsaufgaben

Die Migration umfasst Aufgaben, die sowohl im VPC-Netzwerk des Erstellers als auch im VPC-Netzwerk des Nutzers ausgeführt werden. Der Ersteller kann sich mit dem Nutzer abstimmen, um die Migration durchzuführen. Bei von Google verwalteten Diensten kann der Dienstersteller die Aufgaben des Nutzers über einen Dienstagenten automatisieren.

Aufgabe Ersteller Konsumgüter
Private Service Connect-Dienst bereitstellen
Dienst in einem neuen Subnetz in einem neuen VPC-Netzwerk im Erstellerprojekt bereitstellen und mit Private Service Connect veröffentlichen Von Produzent durchgeführt
Peeringbasierten Dienst herunterfahren
CIDR-Bereich des Ersteller-Subnetzes reservieren, indem du einen internen Bereich im Erstellerprojekt erstellst Von Produzent durchgeführt Der Kunde gibt den Namen des Subnetzes an, das für das Migrationsziel verwendet werden soll.
Alle Ressourcen im Produzentensubnetz löschen und dann das Subnetz löschen Von Produzent durchgeführt Der Verbraucher kann nicht mehr auf den Dienst zugreifen
Private Service Connect-Endpunkt im Kundennetzwerk erstellen
Migrationssubnetz im Kundennetzwerk erstellen Wenn der Verbraucher den Subnetznamen nicht ausgewählt hat, stellt der Produzent den Subnetznamen dem Verbraucher zur Verfügung. Wird vom Verbraucher (oder vom Ersteller über einen Kundenservicemitarbeiter) ausgeführt
Private Service Connect-Endpunkt im Kundennetzwerk erstellen Der Ersteller stellt dem Nutzer den URI des Dienstanhangs zur Verfügung

Wird vom Verbraucher (oder vom Ersteller über einen Kundenservicemitarbeiter) ausgeführt

Der Verbraucher kann auf den Dienst zugreifen
Zugriff über den Private Service Connect-Endpunkt prüfen Von Verbraucher ausgeführt
Migration abschließen
Internen Bereich löschen Von Produzent durchgeführt
Migrationssubnetz des Kunden aktualisieren, um es in ein reguläres Subnetz umzuwandeln Wird vom Verbraucher (oder vom Ersteller über einen Kundenservicemitarbeiter) ausgeführt
Wenn sie für andere Dienste nicht erforderlich ist, löschen Sie die Peering-Verbindung in den Producer- und Consumer-Netzwerken. Von Produzent durchgeführt Wird vom Verbraucher (oder vom Ersteller über einen Kundenservicemitarbeiter) ausgeführt

Hinweise

Wenn Sie als Dienstanbieter Ihren peeringbasierten Dienst zu Private Service Connect migrieren möchten, beachten Sie Folgendes:

  • Die Private Service Connect-Implementierung des Dienstes muss dieselben Funktionen wie der Peering-basierte Dienst bieten.
  • Sie müssen während der Migration alle Ressourcen im Subnetz löschen können, das die Dienstinstanz enthält. Wenn mehrere Dienstinstanzen dasselbe Subnetz verwenden, müssen alle Instanzen gleichzeitig migriert werden.

  • Der Private Service Connect-Endpunkt des Nutzers sowie der Dienstanhang und die Weiterleitungsregel des Erstellers müssen sich in derselben Region befinden.

    Wenn Sie den Zugriff auf den Endpunkt von jeder Region aus ermöglichen möchten, können Sie den globalen Zugriff auf den Endpunkt aktivieren.

  • Wenn der Dienst den Status speichert, müssen Sie eine Methode haben, den Status in die neuen Dienstinstanzen zu migrieren.

  • Sie können die Peering-Verbindung erst löschen, wenn alle Dienstinstanzen im VPC-Netzwerk des Diensterstellers migriert wurden.

  • Der Dienst ist während der Migration nicht verfügbar.

  • Die Migration zu Private Service Connect hat Auswirkungen auf die Preise für Ersteller und Nutzer. Informieren Sie Ihre Kunden über diese Änderung, bevor Sie sie migrieren.

  • Private Service Connect übersetzt die Quell-IP-Adresse des Clients in eine IP-Adresse in einem NAT-Subnetz. Wenn der Dienst IP-Adressinformationen zum Client benötigt, müssen Sie das PROXY-Protokoll verwenden, um die Client-IP-Adresse abzurufen, und die Pakete zwischen den Back-End-VMs und Ihrer Anwendung ordnungsgemäß verarbeiten.

Interne Bereiche für die Migration

Mit dem internen Bereich wird der CIDR-Bereich reserviert, der im Producer-Subnetz verwendet wird. Wenn das Producer-Subnetz gelöscht wird, kann der CIDR-Bereich nicht für andere Zwecke verwendet werden.

Wenn Sie einen internen Bereich für die Peer-Migration erstellen, legen Sie die Verwendung auf FOR_MIGRATION fest und geben Sie die Quell- und Zielsubnetze an. Das Quellsubnetz ist das Produzentensubnetz und das Zielsubnetz ist das neue Peer-Migrationssubnetz, das später im Verbrauchernetzwerk erstellt wird.

Wenn Sie den internen Bereich erstellen, wird verhindert, dass ein Subnetz erstellt wird, das sowohl dem Namen des Zielsubnetzes als auch dem CIDR-Bereich entspricht. Im Kundennetzwerk kann jedoch ein weiteres Subnetz mit demselben Namen erstellt werden, wenn es einen anderen CIDR-Bereich verwendet. In diesem Fall kann die Migration erst fortgesetzt werden, wenn entweder das Kundensubnetz mit dem übereinstimmenden Namen oder der interne Bereich gelöscht wurde.

Peer-Migrationssubnetze

Das im Kundennetzwerk für die Migration erstellte Subnetz hat den Zweck PEER_MIGRATION. Subnetze für die Peermigration dürfen nur IP-Adressen und Private Service Connect-Endpunkte enthalten.

Nachdem die Migration abgeschlossen und überprüft wurde, wird das Subnetz in ein reguläres Subnetz umgewandelt, indem der Zweck auf PRIVATE festgelegt wird. Anschließend können im Subnetz weitere Ressourcen erstellt werden. Ein reguläres Subnetz kann nicht wieder in ein Peer-Migrationssubnetz umgewandelt werden.

Sie benötigen die IAM-Berechtigung compute.subnetworks.usePeerMigration (Identity and Access Management), um ein Peer-Migrationssubnetz zu erstellen oder zu verwenden. Die Berechtigung ist in keiner vordefinierten Rolle enthalten. Sie müssen eine benutzerdefinierte Rolle erstellen, um sie zu verwenden.

Nur Hauptkonten mit der Berechtigung compute.subnetworks.usePeerMigration können Folgendes tun:

  • Erstellen und löschen Sie IP-Adressressourcen in Subnetzen für die Peer-Migration.
  • Private Service Connect-Endpunkte (Weiterleitungsregeln) in Peer-Migrationssubnetzen erstellen und löschen

Hauptkonten mit der Rolle „Compute-Netzwerkadministrator“ (roles/compute.networkAdmin), aber ohne die Berechtigung compute.subnetworks.usePeerMigration können die oben genannten Aufgaben nicht ausführen. Sie haben jedoch folgende Möglichkeiten:

  • Erstellen Sie ein Subnetz mit dem Zweck PEER_MIGRATION.
  • Aktualisieren Sie das Subnetz, z. B. um den CIDR-Bereich zu erweitern oder den privaten Google-Zugriff zu aktivieren.
  • Aktualisieren Sie den Zweck des Subnetzes auf PRIVATE.
  • Löschen Sie das Subnetz.

Preise

Preisinformationen finden Sie hier:

Nächste Schritte