Freigeben über

Informationen zur ExpressRoute-Gateway-Migration

In diesem Artikel wird der Migrationsprozess des ExpressRoute-Gateways erläutert, mit dem Sie von nicht Verfügbarkeitszonen ("nicht Az")-fähigen SKUs zu "Az"-fähigen SKUs und von Basic-IP zu Standard-IP wechseln können. Die Migration zu Az-fähigen SKUs und Standard-IPs verbessert die hohe Verfügbarkeit und Zuverlässigkeit Ihrer virtuellen ExpressRoute-Netzwerkgateways.

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

Von Bedeutung

Am 30. September 2025 werden öffentliche IP-Adressen für Basic-SKU eingestellt. Weitere Informationen finden Sie in der offiziellen Ankündigung. Wenn Sie derzeit öffentliche Basic SKU-IPs verwenden, sollten Sie vor dem Deaktivierungsdatum ein Upgrade auf die öffentlichen Standard-SKU-IPs durchführen.

Gateway-SKUs

Die SKUs ErGw1Az, ErGw2Az, ErGw3Az und ErGwScale (Preview) werden als Verfügbarkeitszone (Az)-fähige SKUs bezeichnet. Diese SKUs ermöglichen die Bereitstellung über mehrere Verfügbarkeitszonen hinweg und erhöhen die Resilienz und hohe Verfügbarkeit, indem Gatewayressourcen über Zonen verteilt werden.

Im Vergleich dazu sind die Standard-, HighPerformance- und UltraPerformance-SKUs nicht Az-fähig. Sie werden in der Regel mit öffentlichen Standard-IP-Adressen verwendet und unterstützen keine Verfügbarkeitszonenverteilung.

Erfahrung mit Gateway-Migration

Mit der Gatewaymigration können Sie ein zweites virtuelles Netzwerkgateway im selben GatewaySubnet bereitstellen. Azure migriert Ihre Konfigurationen vom alten Gateway zum neuen. Beide Gateways werden während der Migration gleichzeitig ausgeführt, wodurch Unterbrechungen minimiert werden– 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

Die geführte Gateway-Migration unterstützt die folgenden Szenarien:

  • Migrieren von einer SKU ohne Azure-Verfügbarkeitszone mit einer Basis-IP zu einer SKU ohne Azure-Verfügbarkeitszone mit einer Standard-IP.
  • Migrieren von einer nicht azfähigen SKU mit einer Einfachen IP zu einer Az-fähigen SKU mit einer Standard-IP.

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.

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, eine öffentliche IP und Verbindungen. Dieser Schritt kann bis zu 45 Minuten dauern. Sie können einen 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. Wenn Sie die Migration beenden müssen, können Sie in dieser Phase abbrechen , wodurch das neue Gateway und die neuen Verbindungen gelöscht werden.

Hinweis

Das neue Gateway wird in derselben Region wie die vorhandene erstellt. Um Regionen zu ändern, müssen Sie das aktuelle Gateway löschen und ein neues Gateway in der gewünschten Region erstellen.

  1. Migrieren: Wechseln des Datenverkehrs vom alten Gateway zum neuen. Dieser Schritt kann bis zu 15 Minuten dauern und kann zu kurzen Verbindungsunterbrechungen führen.
  2. Commit: Schließen Sie die Migration ab, indem Sie das alte Gateway und die zugehörigen Verbindungen löschen. Bei Bedarf können Sie das alte Gateway abbrechen und wiederherstellen, bevor Sie committen.

Von Bedeutung

Überprüfen Sie nach der Migration Ihre Konnektivität, um sicherzustellen, dass alles wie erwartet funktioniert. Sie können zum alten Gateway zurückkehren, indem Sie "Abbrechen " nach dem Vorbereitungsschritt auswählen, wodurch das neue Gateway und die neuen Verbindungen gelöscht werden.

Begrenzungen

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.

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

Häufig gestellte Fragen

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. 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?

Sie haben bis zu 15 Tage nach der Migrationsvorbereitung Zeit, sich zu entscheiden. Verwenden Sie diese Zeit, um die Konnektivität zu überprüfen und sicherzustellen, dass alle Anforderungen erfüllt sind, bevor Sie die Migration abschließen.

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

Azure Advisor-Benachrichtigungen benachrichtigen Sie, wenn Ihr Gateway eine Migration erfordert. Der Versuch, ein nicht berechtigtes Gateway zu migrieren, führt zu einem Fehler. Weitere Informationen finden Sie unter Problembehandlung bei Gateway-Migrationen.

Nächste Schritte