Freigeben über

Informationen zum Migrieren zu einem ExpressRoute-Gateway für virtuelle Netzwerke mit aktivierter Verfügbarkeitszone

  • Artikel

Wenn Sie ein ExpressRoute-Gateway für virtuelle Netzwerke erstellen, müssen Sie die Gateway-SKU auswählen. Wenn Sie eine SKU einer höheren Ebene auswählen, werden dem Gateway mehr CPUs und Netzwerkbandbreite zugewiesen. Dadurch kann das Gateway einen höheren Netzwerkdurchsatz und zuverlässigere Netzwerkverbindungen mit dem virtuellen Netzwerk unterstützen.

Die folgenden SKUs sind für virtuelle ExpressRoute-Netzwerk-Gateways verfügbar:

  • Standard
  • HighPerformance
  • UltraPerformance
  • ErGw1Az
  • ErGw2Az
  • ErGw3Az
  • ErGwScale (Vorschau)

Verfügbarkeitszone aktivierte SKUs

Die SKUs „ErGw1Az“, „ErGw2Az“, „ErGw3Az“ und „ErGwScale (Vorschau)“, auch Az-fähige SKUs genannt, unterstützen Bereitstellungen von Verfügbarkeitszonen. Dieses Feature bietet hohe Verfügbarkeit und Ausfallsicherheit für das Gateway, indem es das Gateway über mehrere Verfügbarkeitszonen verteilt.

Die Standard-, HighPerformance- und UltraPerformance-SKUs, die auch als SKUs ohne Aktivierung von Verfügbarkeitszonen bezeichnet werden, werden historisch mit Basic-IPs verknüpft und unterstützen die Verteilung des Gateways nicht über mehrere Verfügbarkeitszonen hinweg.

Um die Zuverlässigkeit zu erhöhen, empfiehlt es sich, eine SKU mit aktivierter Verfügbarkeitszone für virtuelles Netzwerk zu verwenden. Diese SKUs unterstützen eine zonenredundante Einrichtung und sind standardmäßig mit Standard-IPs verbunden. Dieses Setup stellt sicher, dass die Infrastruktur des VNET-Gateways dank der Verteilung auf mehrere Zonen auch dann betriebsbereit bleibt, wenn in einer Zone ein Problem auftritt. Für ein tieferes Verständnis der zonenredundanten Gateways lesen Sie bitte Verfügbarkeitszonen-Bereitstellungen.

Erfahrung mit Gateway-Migration

Bisher mussten Benutzer den PowerShell-Befehl „Resize-AzVirtualNetworkGateway“ verwenden oder das virtuelle Netzwerkgateway löschen und neu erstellen, um zwischen SKUs zu migrieren.

Mit der geführten Gateway-Migration können Sie ein zweites virtuelles Netzwerk-Gateway im selben GatewaySubnetz einrichten. Azure überträgt automatisch die Konfiguration der Steuerebene und des Datenpfads vom alten Gateway auf das neue. Während des Migrationsprozesses werden zwei virtuelle Netzwerkgateways innerhalb desselben GatewaySubnets ausgeführt. Dieses Feature wurde entwickelt, um Migrationen ohne Ausfallzeiten zu unterstützen. Benutzer können jedoch während des Migrationsprozesses kurze Verbindungsprobleme oder Unterbrechungen feststellen.

Hinweis

Der Abschluss der Migration kann bis zu einer Stunde in Anspruch nehmen. Während dieses Zeitraums bleibt das Gateway gesperrt, und es werden keine Änderungen erlaubt.

Die Gatewaymigration wird empfohlen, wenn Sie über eine nicht Az-fähige Gateway-SKU oder eine nicht Az-fähige Gateway-SKU mit Basic-IP verfügen.

Migrieren von einer nicht Az-fähigen Gateway-SKU Migrieren zu einer Az-fähigen Gateway-SKU
Standard, HighPerformance, UltraPerformance ErGw1Az, ErGw2Az, ErGw3Az, ErGwScale (Vorschau)
Basic-IP Standard-IP

Unterstützte Migrationsszenarien

Azure Portal & Azure PowerShell

Die geführte Gatewaymigrationserfahrung unterstützt Folgendes:

  • Nicht Az-fähige SKU mit Basic-IP zu nicht Az-fähiger SKU mit Standard-IP
  • Nicht Az-fähige SKU mit Basic-IP zu Az-fähiger SKU mit Standard-IP.
  • Nicht Az-fähige SKU mit Standard-IP zu Az-fähiger SKU mit Standard-IP.

Es wird empfohlen, zu einer Az-fähigen SKU zu migrieren, um die Zuverlässigkeit und Hochverfügbarkeit zu optimieren. Weitere Informationen finden Sie unter Migrieren zu einem ExpressRoute-Gateway für virtuelle Netzwerke mit aktivierter Verfügbarkeitszone mithilfe von PowerShell.

Begrenzungen

Die geführte Gatewaymigrationsumgebung unterstützt keine Downgradeszenarien, Az-fähige Gateway-SKU zu nicht Az-fähiger Gateway-SKU.

Um mit der Migration fortzufahren, ist im GatewaySubnet ein Präfix /27 oder länger erforderlich.

Private Endpunkte (PEs) im virtuellen Netzwerk, die über ExpressRoute Private Peering verbunden sind, können während der Migration Konnektivitätsprobleme haben. Um dieses Problem zu verstehen und zu verringern, siehe Private Endpunktkonnektivität.

Häufige Überprüfungsfehler

In der Gatewaymigrationsumgebung müssen Sie überprüfen, ob Ihre Ressource migriert werden kann. Nachfolgend finden Sie einige häufige Migrationsfehler:

Virtuelles Netzwerk

MaxGatewayCountInVnetReached – Erreicht die maximale Anzahl von Gateways, die in einem virtuellen Netzwerk erstellt werden können.

Nächste Schritte