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.
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.
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:
Dienstersteller: Preise für die Veröffentlichung eines Dienstes
Dienstnutzer: Preise für den Zugriff auf einen veröffentlichten Dienst über einen Endpunkt
Nächste Schritte
- Dienstsubnetz vom Peering zu Private Service Connect migrieren
- Dienst über Private Service Connect veröffentlichen