Informationen zur ExpressRoute-Gateway-Migration

In diesem Artikel wird der ExpressRoute-Gatewaymigrationsprozess beschrieben, mit dem Sie von Ihrer aktuellen SKU zu einer gleichwertigen oder höheren SKU und von Basic-IP zu Standard-IP wechseln können, wodurch Zuverlässigkeit und Verfügbarkeit verbessert werden, während Downgrades nicht unterstützt werden.

Anleitungen zum Upgrade von öffentlichen SKU-Basic-IP-Adressen für andere Netzwerkdienste finden Sie unter Upgrade von Basic zu Standard SKU.

Erfahrung mit Gateway-Migration

Mit der Gatewaymigrationsumgebung können Sie ein zweites virtuelles Netzwerkgateway im selben GatewaySubnet bereitstellen, wobei Azure automatisch eine neue öffentliche IP-Adresse zuweist, ohne dass manuelle IP-Erstellung erforderlich ist, während Konfigurationen vom alten Gateway zum neuen migriert werden; Beide Gateways werden gleichzeitig ausgeführt, um Unterbrechungen zu minimieren, obwohl kurze Verbindungsunterbrechungen weiterhin auftreten können.

Nach der Migration werden das alte Gateway und seine Verbindungen gelöscht, und das neue Gateway wird mit CreatedBy: GatewaySKUMigration markiert, um es als migrierte Ressource zu identifizieren und sollte nicht gelöscht werden.

Unterstützte Migrationsszenarien

Mit dem geführten ExpressRoute-Gatewaymigrationsprozess können Kunden von ihrer aktuellen SKU zu einer gleichwertigen oder höheren SKU wechseln. Die Migration zu einer niedrigeren SKU (Downgrades) wird nicht unterstützt.

Wenn Sie ein ExpressRoute-Gateway im selben virtuellen Netzwerk wie ein VPN-Gateway bereitgestellt haben, können Sie das ExpressRoute-Gateway-Migrationstool verwenden. Während dieses Prozesses gibt es keine erwarteten Auswirkungen auf den VPN-Gatewaydatenverkehr.

Erfahren Sie, wie Sie mithilfe des Azure-Portals migrieren.
Erfahren Sie, wie Sie mithilfe von PowerShell migrieren.

Für eine verbesserte Zuverlässigkeit und hohe Verfügbarkeit empfehlen wir die Migration zu einer azfähigen SKU.

Migrieren zu ErGwScale (skalierbares Gateway)

Das ExpressRoute Scalable Gateway (ErGwScale) ist ein neues Gateway-SKU für virtuelle Netzwerke, das flexible Hochgeschwindigkeits-Bandbreitenkonnektivität für Ihre virtuellen Azure-Netzwerke bereitstellt.

Sie können die Skalierung des Gateways gemäß den Anforderungen konfigurieren, indem Sie die Mindest- und Maximalmaßstabeinheiten festlegen:

• Um ein Gateway mit fester Größe zu konfigurieren, legen Sie sowohl die Mindest - als auch die maximalen Skalierungseinheiten auf denselben Wert fest (z. B. auf 1, beide auf 20 und beide auf 40 festgelegt).
• Um die automatische Skalierung zu aktivieren, legen Sie die Mindestmaßstabeinheit auf 2 oder höher fest, und geben Sie die gewünschte maximale Skalierungseinheit (bis zu 40) an.

Auf diese Weise kann das Gateway basierend auf Ihren Workloadanforderungen automatisch skaliert werden.

Weitere Informationen finden Sie unter "Informationen zum skalierbaren Gateway".

Schritte zum Migrieren zu einem neuen Gateway

1. Überprüfen: Überprüfen Sie, ob alle Ressourcen in einem erfolgreichen Zustand sind. Wenn keine Voraussetzungen erfüllt sind, schlägt die Überprüfung fehl, und die Migration kann nicht fortgesetzt werden.
2. Vorbereiten: Azure erstellt ein neues virtuelles Netzwerkgateway, weist automatisch eine neue öffentliche IP zu – eine neue öffentliche IP und stellt Verbindungen wieder her – dieser Vorgang kann bis zu 45 Minuten dauern. Sie können einen benutzerdefinierten Namen für das neue Gateway angeben, oder Azure fügt standardmäßig _migrated zum ursprünglichen Namen hinzu. Während der Vorbereitung ist das vorhandene Gateway gesperrt, um Änderungen zu verhindern, mit der Option zum Abbrechen und Löschen des neuen Gateways und der neuen Verbindungen.

3. Migrieren: Wechseln des Datenverkehrs vom alten Gateway zum neuen. Dieser Schritt kann bis zu 15 Minuten dauern und kann zu kurzen Verbindungsunterbrechungen führen. Navigieren Sie nicht von der Migrationsseite ab, während der Datenverkehr verschoben wird. Wenn Sie die Seite verlassen, kann der Vorgang unterbrochen werden.
4. Commit: Schließen Sie die Migration ab, indem Sie das ursprüngliche Gateway und die zugehörigen Verbindungen löschen. Wenn Sie die Migration abbrechen müssen, wechseln Sie zuerst zurück zum ursprünglichen Gateway, indem Sie das Optionsfeld im Abschnitt "Migrieren " auswählen, dann auf "Migrieren" klicken und schließlich " Abbrechen " auswählen, um das neue Gateway und dessen Verbindungen zu löschen.

Limitations

Die Migrationserfahrung für geführte Gateways hat die folgenden Einschränkungen:

• Nur ExpressRoute: Das Migrationstool wurde für ExpressRoute-Gateways für virtuelle Netzwerkgateways entwickelt. Es unterstützt keine VPN-Gateways oder andere Gatewaytypen. - Gleiche Anforderung für virtuelles Netzwerk: Die Migration wird nur innerhalb desselben virtuellen Netzwerks unterstützt. Abonnementübergreifende, regionsübergreifende oder gatewayübergreifende Migrationen (z. B. zu/von VPN-Gateways) werden nicht unterstützt.
• Keine Downgrades: Das Herabstufen von einer azfähigen SKU auf eine nicht azfähige SKU wird nicht unterstützt.
• GatewaySubnet-Größe: Das GatewaySubnet muss über ein /27-Präfix oder länger verfügen, um mit der Migration fortzufahren. Weitere Informationen finden Sie unter Erstellen mehrerer Präfixe für ein Subnetz.
• Private Endpoint Connectivity: Private Endpunkte (PEs), die über expressRoute private Peering verbunden sind, können während der Migration Verbindungsprobleme verursachen. In der Dokumentation zur Privaten Endpunktkonnektivität finden Sie Anleitungen zur Reduzierung dieser Probleme. Private Endpunktkonnektivität.
• Ältere Gateways: ExpressRoute-Gateways, die in 2017 oder früheren Versionen erstellt oder mit Schaltkreisen verbunden sind, werden nicht unterstützt.
• Nicht unterstützte SKUs: Gateways, die die Standard-SKU verwenden, sind nicht für die Migration berechtigt. Um die Migrationsberechtigung Ihres Gateways zu überprüfen, sollte eine Advisor-Benachrichtigung vorhanden sein.
• Inkompatibler dedizierter Schaltkreis: Die Gatewaymigration kann nicht mit einem dedizierten Hardware Security Module (HSM) fortfahren, das mit dem virtuellen Netzwerk verbunden ist. Um mit der Migration fortzufahren, deaktivieren Sie das dedizierte Hardware-Sicherheitsmodul (HSM). Ausführliche Schritte zur Problembehandlung finden Sie unter "Problembehandlung für dedizierte HSM".

Für detaillierte Informationen zur Fehlerbehebung und zu bewährten Methoden, siehe Fehlerbehebung bei der Gateway-Migration.

FAQ

Wie füge ich dem GatewaySubnet ein zweites Präfix hinzu?

Das Hinzufügen mehrerer Präfixe zum GatewaySubnet befindet sich derzeit in der öffentlichen Vorschau und wird nur über PowerShell unterstützt. Wenn Sie ein zusätzliches Präfix hinzufügen, werden beide Präfixe vom migrierten Gateway verwendet, sodass Sie das alte Präfix nicht löschen. Anweisungen finden Sie unter Erstellen mehrerer Präfixe für ein Subnetz.

Wie kann ich den Status des neuen Gateways überwachen?

Die Überwachung für das neue Gateway ist identisch mit dem alten Gateway. Das neue Gateway ist eine separate Ressource mit eigenen Metriken. Während der Migration können Sie auch Datenverkehrsmuster mithilfe des Migrationstools beobachten.

Nach der Migration müssen Sie diese auf dem neu erstellten Gateway neu konfigurieren, wenn Sie über vorhandene Überwachungs-, Warnungs-, kundendefinierte Wartungsfenster oder Diagnoseeinstellungen verfügen.

Führt die Migration zu Ausfallzeiten?

Die Migration kann einige Minuten ausfallzeiten verursachen. Planen Sie die Migration während eines Wartungsfensters, um die Auswirkungen zu minimieren.

Wie lange kann ich warten, bevor ich den Commit für das neue Gateway ausführen kann?

Es gibt keine obligatorische Wartezeit, um einen Commit durchführen zu können. Wenn Sie jedoch Zeit benötigen, um die Konnektivität zu überprüfen und sicherzustellen, dass alle Anforderungen erfüllt sind, bevor Sie die Migration abschließen, haben Sie bis zu 15 Tage nach der Migration Zeit, sich zu verpflichten.

Wie kann ich überprüfen, ob meine Gateway-SKU für die Migration berechtigt ist?

Azure Advisor benachrichtigt Sie, wenn Ihr Gateway berechtigt ist oder eine Migration erfordert. Sie können auch Ihre ExpressRoute-Gateway-Ressource im Azure-Portal überprüfen – wenn Ihr Gateway berechtigt ist, wird ein Banner oben auf der Seite die Meldung "Implementierung von zonenredundanten ExpressRoute-Gateways" anzeigen.

Wie kann ich überprüfen, ob mein Gateway nach der Migration zone resilient ist?

So bestätigen Sie, dass Ihr Gateway nach der Migration zonensicher ist:

• Überprüfen Sie Azure Advisor: Wenn Ihr Gateway zonenresilient ist, werden keine Advisor-Warnungen mehr angezeigt, die ein zonenredundantes Gateway empfehlen.
• Überprüfen Sie Ressourcentags: Das migrierte Gateway hat eine Standardtagbezeichnung GatewaySKUMigration, die angibt, dass es in das zonenresiliente Bereitstellungsmodell verschoben wurde.

Diese Überprüfungen bestätigen, dass Ihr Gateway jetzt zonensicher ist.

Kann ich diese Änderung zurücksetzen?

Ja, bis sie zugesichert ist. Die Migration besteht aus vier wichtigen Schritten:

1. Überprüfen – Bestätigt, ob Ihr Gateway für die Migration berechtigt ist. In dieser Phase werden keine Änderungen vorgenommen; nichts ist zurückzusetzen.

2. Vorbereiten – Erstellt ein neues virtuelles Netzwerkgateway mit der gewünschten Konfiguration. Der Vorgang kann nach Schritt 2 abgebrochen werden, und das neue Gateway wird gelöscht.

3. Migrieren – Übertragen Sie die Konfiguration vom vorhandenen Gateway auf das neue. Bei Bedarf kann die Konfiguration nach Schritt 3 auf das vorhandene Gateway zurückgesetzt werden. Navigieren Sie nicht von der Migrationsseite ab, während der Datenverkehr verschoben wird. Wenn Sie die Seite verlassen, kann der Vorgang unterbrochen werden.

4. Commit – Abschließen der Migration durch Außerbetriebnahme des alten Gateways und der zugehörigen Verbindungen. Sobald die Änderung zugesichert wurde, kann sie nicht mehr zurückgesetzt werden.

Welche Auswirkungen hat der Datenverkehr während der Migration? Gibt es Paketverluste oder Routingunterbrechungen?

Während des Migrationsprozesses wird der Datenverkehr nahtlos umgeleitet. Es gibt keine erwarteten Paketverlust- oder Routingunterbrechungen unter normalen Bedingungen.

Was sollte ich tun, wenn der Vorbereitungsschritt aufgrund einer regionsübergreifenden Verbindung auf einer einfachen SKU-Verbindung während der Gatewaymigration fehlschlägt?

Wenn der Schritt "Vorbereiten" fehlschlägt, da der Basis-SKU-Schaltkreis eine regionsübergreifende Verbindung aufweist, beenden Sie die Gatewaymigration, und aktualisieren Sie die Verbindungs-SKU, bevor Sie es erneut versuchen. Diese Konfiguration wird nicht unterstützt, und die Migration schlägt weiterhin fehl, bis die Schaltkreis-SKU aktualisiert wird.

Nächste Schritte

• Beheben von Migrationsproblemen mit der Anleitung unter Problembehandlung bei der Gatewaymigration.
• Erfahren Sie, wie Sie mithilfe des Azure-Portals migrieren.
• Erfahren Sie, wie Sie mithilfe von PowerShell migrieren.