Informationen zur Live-Migration
Mit der Live-Migration können Sie die BGP-Ankündigung von regionalen öffentlich delegierten v1-Präfixen steuern. Live-Migration ist nicht standardmäßig verfügbar. Wenden Sie sich an Ihren Google Cloud-Customer Engineer, um Zugriff zu erhalten.
Für neue Konfigurationen empfehlen wir, ein öffentlich beworbenes v2-Präfix zu erstellen, mit dem Sie regionale öffentlich delegierte Präfixe erstellen können, die schneller bereitstellen und bessere Kontrolle über die BGP-Ankündigung.
Weitere Informationen zum Unterschied zwischen öffentlich delegierten v1- und v2-Präfixen finden Sie unter Eigene IP verwenden: Konfiguration.
Live-Migration
Die Live-Migration ist ein leistungsstarkes Feature, das eine detaillierte Planung und Ausführung erfordert.
Verwenden Sie die Live-Migration, um ein BYOIP-Präfix zu importieren, wenn ein Teil des Präfix bereits öffentlich beworben wird. Das Importieren eines beworbenen Präfixes ohne Verwendung der Live-Migration kann zu unerwartetem Routing und Paketverlust führen.
Die Live-Migration ist nur eingeschränkt verfügbar. Wenden Sie sich an Ihren Google Cloud Customer Engineer, um Zugriff zu erhalten, bevor Sie ein öffentlich delegiertes Präfix mit aktivierter Live-Migration erstellen.
Sie aktivieren die Live-Migration, wenn Sie ein öffentlich delegiertes Präfix erstellen. Indem Sie Folgendes sicherstellen verhindern Sie, dass Google das öffentlich beworbene Präfix gegenüber Kollegen bewirbt:
Alle öffentlich delegierten Präfixe innerhalb des öffentlich beworbenen Präfixes werden auf regionaler Ebene und nicht auf globaler Ebene konfiguriert. Weitere Informationen finden Sie in den Empfehlungen zur Live-Migration.
Keine IP-Adressen im Bereich des öffentlich beworbenen Präfixes sind Ressourcen zugewiesen.
Abbildung 2 zeigt dasselbe Projekt mit verschiedenen Konfigurationen, von denen eine verhindert, dass das Präfix beworben wird, und zwei, die bewirken, dass das öffentlich beworbene Präfix beworben wird.
Abbildung 2 veranschaulicht die folgenden Szenarien:
Im ersten Projektbeispiel werden alle öffentlich delegierten Präfixe im öffentlich beworbenen Präfix mit aktivierter Live-Migration konfiguriert. Es werden keine VMs mit IP-Adressen aus diesem Präfix konfiguriert.
Ergebnis: Das öffentlich beworbene Präfix wird nicht beworben.
Im zweiten Projektbeispiel werden alle öffentlich delegierten Präfixe im öffentlich beworbenen Präfix mit aktivierter Live-Migration konfiguriert. Eine VM wird mit einer IP-Adresse aus diesem Präfix konfiguriert.
Ergebnis: Das öffentlich beworbene Präfix wird beworben.
Im dritten Projektbeispiel wird ein öffentliches delegiertes Präfix innerhalb des öffentlich beworbenen Präfixes nicht mit aktivierter Live-Migration konfiguriert. Es werden keine VMs mit IP-Adressen aus diesem Präfix konfiguriert.
Ergebnis: Das öffentlich beworbene Präfix wird beworben.
Sie steuern, wann die Bewerbung beginnt. Weisen Sie dazu IP-Adressen aus Ihrem öffentlichen delegierten Präfix den Google Cloud-Ressourcen zu. Weitere Informationen finden Sie unter Live-Migration.
Wenden Sie sich nach Abschluss der Live-Migration an Ihren Google Cloud Customer Engineer, damit er die Live-Migration für Ihr Präfix deaktivieren kann. Standardmäßig wird die Live-Migration 30 Tage nach Beginn der Bewerbung für das öffentlich beworbene Präfix deaktiviert. Wenn Sie die Live-Migrationsoption länger als 30 Tage benötigen, wenden Sie sich an Ihren Customer Engineer.
Einschränkungen der Live-Migration
Bei der Planung einer Live-Migration ist es wichtig, dass Sie die folgenden Anforderungen und Einschränkungen verstehen:
Das Erstellen eines öffentlichen delegierten Präfixes mit aktivierter Live-Migration wird nicht unterstützt, wenn der Bereich auf „Global“ festgelegt ist. Informationen zur Verwaltung der Live-Migration für globale Ressourcen finden Sie in den Empfehlungen zur Live-Migration.
Das längste Präfix, das migriert werden kann, ist ein
/24, da/24die maximal weiterleitbare Präfixlänge im Internet ist.Es wird nicht davon ausgegangen, dass alle Kollegen von Google das längste Präfix zwischen zwei Websites respektieren. Einige Kollegen haben möglicherweise keine vollständigen Routingtabellen. Daher ist ein kürzeres Präfix beworben von Google gegenüber diesen Kollegen das einzige (und damit auch das längste Präfix) Präfix, das der Kollege sieht. Deshalb hat das Existenz jedes Präfixes von Google Vorrang, auch wenn Sie eine spezifischere Route von Ihrem lokalen Standort aus bewerben.
Beispiel:
Ein Kunde hat eine
/23, die aktiv von seinem lokalen Standort aus weitergeleitet wird. Der Kunde plant, die/23in zwei/24-Präfixe aufzuteilen und die spezifischeren Routen von ihrem lokalen Standort aus anzukündigen. Nach der Aufteilung möchten sie das öffentlich beworbene Präfix/23für BYOIP konfigurieren. Sie gehen davon aus, dass die spezifischeren Routen von ihrem lokalen Standort Vorrang vor dem kürzeren BYOIP-Präfix haben und der Traffic weiterhin an die spezifischeren lokalen Präfixe weitergeleitet wird.Dieser Plan funktioniert leider nur teilweise:
Google-Kollegen, die vollständige Routingtabellen haben, bevorzugen die spezifischeren lokalen
/24-Präfixe.Google-Kollegen, die keine vollständigen Routingtabellen haben, bevorzugen das von Google angekündigte öffentlich beworbene Präfix, da die spezifischeren Präfixe in deren Routing-Tabellen nicht enthalten sind.
Ihr Traffic wird nicht zugestellt, wenn Google Traffic für ein gültiges öffentlich beworbenes Präfix erhält, für das Sie keine Dienste bereitgestellt haben, auch wenn es ein aktives lokales Bewerbung für das Präfix gibt.
Beispiel:
Ein Kunde hat ein lokales Netzwerk, das zwei
/24-Präfixe umfasst. Das öffentlich beworbene Präfix ist das aggregierte/23.Der Kunde migriert einen einzelnen
/24zu Google und entfernt das lokale Präfix, lässt aber die andere/24aktiv am lokalen Standort.Diese Konfiguration führt zu einem Teil der Trafficweiterleitung an Google für das gesamte
/23-Präfix, obwohl dennoch ein spezifischeres/24-Präfix vom lokalen Standort angekündigt wird. Dieses Szenario lässt sich nur schwer diagnostizieren, da verschiedene Autonome Systeme Traffic an Ihren lokalen Standort liefern, andere aber an Google liefern, in welchem Fall der Traffic verworfen wird.
Empfehlungen für die Live-Migration
Befolgen Sie bei der Live-Migration am besten die folgenden Empfehlungen.
Trennen Sie alle Live-Migrationspräfixe in die längsten Präfixe auf, die angeben, wie diese Präfixe während der Migration beworben werden sollen. In den vorherigen Beispielen sollte
/23in zwei/24-Präfixe zerlegt und als solche an deren lokalen Standort angekündigt werden, bevor Sie das öffentliche beworbene Präfix erstellen.Sie erstellen ROA-Anfragen mit exakter Präfixlänge und verlassen sich nicht darauf, dass der maximale Länge Parameter berücksichtigt wird.
Prüfen Sie, ob für die lokale Ursprungs-ASN und die Ursprungs-ASN von Google RPKI-ROA-Anfragen vorhanden sind. Wenn kein ROA für das lokale Präfix vorhanden ist, kann die Erstellung eines Google-Ursprungs-ROAs dazu führen, dass Drittanbieter-ISPs diese lokalen Präfixe herausfiltern, wenn sie die automatische RPKI-Filterung verwenden.
Erstellen Sie separate öffentlich beworbene Präfixe für globale Ressourcen und regionale Ressourcen, wenn Sie eine Live-Migration verwenden müssen. Wenn Sie die Live-Migration für ein öffentlich delegiertes Präfix aktivieren, müssen Sie eine Region für den Bereich angeben. Die Angabe des globalen Bereichs für ein öffentlich delegiertes Präfix, für das Live-Migration aktiviert ist, wird nicht unterstützt. Wenn Sie ein öffentlich delegiertes Präfix mit globalem Geltungsbereich und aktivierter Live-Migration erstellen, wird das Präfix sofort beworben.
Wenn Sie regionale Präfixe in einem öffentlich beworbenen Präfix und globale Präfixe in einem anderen öffentlich beworbenen Präfix haben, können Sie sie separat verwalten. Sie können die Live-Migration der regionalen Ressourcen verwalten, und wenden Sie sich an Ihren Google Cloud Customer Engineer, um die Live-Migration der globalen Ressourcen zu verwalten.