Upgraden von Load Balancer Basic mit PowerShell

Artikel
10/15/2024

Wichtig

Am 30. September 2025 wird Load Balancer im Tarif „Basic“ eingestellt. Weitere Informationen finden Sie in der offiziellen Ankündigung. Wenn Sie derzeit Load Balancer im Tarif „Basic“ verwenden, führen Sie unbedingt vor dem Ablaufdatum ein Upgrade auf Load Balancer Standard durch.

Azure Load Balancer Standard bietet umfangreiche Funktionen sowie Hochverfügbarkeit durch Zonenredundanz. Weitere Informationen zu Load Balancer-SKUs finden Sie in der Vergleichstabelle.

In diesem Artikel wird ein PowerShell-Modul vorgestellt, das eine Load Balancer Standard-Instanz mit der Konfiguration der Load Balancer Basic-Instanz erstellt und dann die Poolmitglieder des VMSS- oder VM-Back-Ends der neuen Load Balancer-Instanz zuordnet.

Eine ausführliche exemplarische Vorgehensweise für das Upgrademodul und den Upgradevorgang finden Sie im folgenden Video:

Übersicht über das Upgrade

Das PowerShell-Modul umfasst die folgenden Aktionen:

Überprüfen, ob Upgrades für das bereitgestellte Load Balancer Basic-Szenario unterstützt werden
Sichern der Konfigurationen für Load Balancer Basic und die VM-Skalierungsgruppe, um Wiederholungsversuche bei Fehlern zu ermöglichen
Durchführen von Updates für die IP-Adressen für das öffentliche Front-End auf die Standard-SKU für öffentliche Lastenausgleiche und statisches Zuweisen
Durchführen eines Upgrades der Load Balancer Basic-Konfiguration auf Load Balancer Standard, um die Konfiguration und Featureparität sicherzustellen
Migrieren der Poolmitglieder des VMSS- und VM-Back-Ends von Load Balancer Basic zu Load Balancer Standard
Erstellen einer Netzwerksicherheitsgruppe und Zuordnen dieser Gruppe zur VM-Skalierungsgruppe oder zum virtuellen Computer, um sicherzustellen, dass der Datenverkehr, für den ein Lastenausgleich vorgenommen wird, die Back-End-Poolmitglieder erreicht, nachdem für Load Balancer Standard eine Netzwerkrichtlinie zum standardmäßigen Verweigern festgelegt wurde
Upgraden öffentlicher IP-Adressen auf Instanzebene, die VMSS- oder VM-Instanzen zugeordnet sind
Aktualisiert eingehende NAT-Pools auf eingehende NAT-Regeln für VM-Skalierungsgruppen-Back-Ends und erstellt einen neuen Back-End-Pool für jeden migrierten NAT-Pool. Geben Sie -skipUpgradeNATPoolsToNATRules an, um dieses Upgrade zu überspringen und später das eigenständige Modul für die NAT-Poolmigration zu verwenden, das Ihnen zusätzliche Optionen für Back-End-Pools bietet.
Protokollieren des Upgradeprozesses für einfache Überwachung und Wiederherstellung bei Fehlern

Warnung

Das Migrieren interner Basic Load Balancers, bei denen die Backend-VMs oder VMSS-Instanzen keine öffentlichen IP-Adressen haben, erfordert zusätzliche Schritte für die Backend-Konnektivität mit dem Internet. Lesen Sie Wie soll ich ausgehenden Datenverkehr für meinen Load Balancer konfigurieren?

Hinweis

Wenn die Netzwerkkonfiguration der VM-Skalierungsgruppe im Back-End-Pool für den Lastenausgleich öffentliche IP-Adressen enthält, ändern sich die öffentlichen IP-Adressen, die den einzelnen VM-Skalierungsgruppeninstanzen zugeordnet sind, wenn ein Upgrade auf die Standard-SKU durchgeführt wird. Das liegt daran, dass für die öffentlichen IP-Adressen auf Skalierungsgruppeninstanz-Ebene kein Upgrade durchgeführt werden kann. Diese Adressen können nur durch eine neue öffentliche IP-Adresse der Standard-SKU ersetzt werden. Alle anderen öffentlichen IP-Adressen werden migriert und bleiben somit erhalten.

Hinweis

Wenn die VM-Skalierungsgruppe hinter dem Lastenausgleich ein Service Fabric-Cluster ist, dauert die Migration mit diesem Skript länger, stellt ein höheres Risiko für Ihre Anwendung dar und führt zu Ausfallzeiten. Migrationsoptionen finden Sie unter Upgradeleitfaden für den Lastenausgleich in Service Fabric-Clustern.

Nicht unterstützte Szenarien

Load Balancer Basic-Szenario mit IPV6-IP-Adressenkonfigurationen für das Front-End
Grundlegende Lastenausgleichsgeräte für Azure Kubernetes Services (AKS)-Cluster
Load Balancer Basic-Szenario mit Back-End-Poolmitglied einer VM-Skalierungsgruppe, bei dem für mindestens eine VM-Skalierungsgruppeninstanz die ProtectFromScaleSetActions-Instanzschutzrichtlinien aktiviert sind
Migrieren von Load Balancer Basic zu einer vorhandenen Load Balancer Standard-Instanz

Installieren des Moduls „AzureBasicLoadBalancerUpgrade“

Voraussetzungen

PowerShell: Für die Verwendung des AzureBasicLoadBalancerUpgrade-Moduls wird auf allen Plattformen, einschließlich Windows, Linux und macOS, eine unterstützte Version von PowerShell Version 7 oder höher empfohlen. Allerdings wird PowerShell 5.1 unter Windows unterstützt.

Modulinstallation

Installieren Sie das Modul aus dem PowerShell-Katalog.

Install-Module -Name AzureBasicLoadBalancerUpgrade -Scope CurrentUser -Repository PSGallery -Force

Schritte vor und nach der Migration

Schritte zur Migrationsvorbereitung

Überprüfen, ob Ihr Szenario unterstützt wird
Einplanen von Anwendungsdowntime während der Migration
Entwickeln von eingehenden und ausgehenden Verbindungstests für Ihren Datenverkehr
Einplanen von Änderungen öffentlicher IP-Adressen auf Instanzebene bei VM-Skalierungsgruppeninstanzen (siehe Hinweis)
[Empfohlen] Erstellen Sie Netzwerksicherheitsgruppen oder fügen Sie Sicherheitsregeln zu einer vorhandenen Netzwerksicherheitsgruppe für Ihre Back-End-Poolmitglieder hinzu. Lassen Sie Datenverkehr über den Load Balancer und anderen Datenverkehr zu, der explizit für öffentliche Standard-SKU-Ressourcen zugelassen werden muss
[Empfohlen] Bereiten Sie Ihre ausgehende Konnektivität vor, indem Sie einen der folgenden beschriebenen Ansätze unter Wie sollte ich ausgehenden Datenverkehr für meinen Load Balancer konfigurieren? befolgen.

Schritte nach der Migration

Bestätigen, dass die Migration erfolgreich ausgeführt wurde
Testen der eingehenden Anwendungskonnektivität über Load Balancer
Testen der ausgehenden Konnektivität von Back-End-Poolmitgliedern zum Internet
Erstellen von ausgehenden Regeln für jeden Back-End-Pool für öffentliche Lastenausgleichsmodule mit mehreren Back-End-Pools

Verwenden des Moduls

Stellen Sie sicher, dass Sie die Abonnement-ID von Load Balancer Basic ausgewählt haben, indem Sie Select-AzSubscription ausführen.
```
Select-AzSubscription -Subscription <SubscriptionId>
```
Suchen Sie den Lastenausgleich, für den Sie ein Upgrade durchführen möchten. Notieren Sie sich den Namen und den Namen der Ressourcengruppe.
Untersuchen Sie die grundlegenden Modulparameter:
- BasicLoadBalancerName [Zeichenfolge] (erforderlich): Dieser Parameter entspricht dem Namen der vorhandenen Load Balancer Basic-Instanz, für die Sie ein Upgrade durchführen möchten.
- ResourceGroupName [Zeichenfolge] (erforderlich): Dieser Parameter entspricht dem Namen der Ressourcengruppe, die die Load Balancer Basic-Instanz enthält.
- StandardLoadBalancerName [Zeichenfolge] (optional): Verwenden Sie diesen Parameter, um optional einen neuen Namen für die Load Balancer Standard-Instanz zu konfigurieren. Ohne diese Angabe wird der Name der Load Balancer Basic-Instanz wiederverwendet.
- RecoveryBackupPath [Zeichenfolge] (optional): Mit diesem Parameter können Sie einen alternativen Pfad angeben, in dem die ARM-Vorlagensicherungsdatei für Load Balancer Basic gespeichert werden soll (Standardeinstellung entspricht dem aktuellen Arbeitsverzeichnis).
Tipp

Zusätzliche Parameter für erweiterte Szenarien und für die Wiederherstellung können durch Ausführen von Get-Help Start-AzBasicLoadBalancerUpgrade -Detailed angezeigt werden.
Führen Sie den Befehl Start-AzBasicLoadBalancerUpgrade mit den folgenden Beispielen aus, um Anweisungen zu erhalten.

Beispiel: Überprüfen eines Szenarios

Überprüfen, ob Basic Load Balancer für ein Upgrade unterstützt wird

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -validateScenarioOnly

Beispiel: Upgrade nach Name

Durchführen eines Upgrades von Load Balancer Basic auf Load Balancer Standard mit demselben Namen, wobei der Name und der Ressourcengruppenname für Load Balancer Basic bereitgestellt wird

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName>

Beispiel: Upgrade, Ändern des Namens und Anzeigen von Protokollen

Durchführen eines Upgrades von Load Balancer Basic auf Load Balancer Standard mit dem angegebenen Namen, wobei die protokollierte Ausgabe auf dem Bildschirm angezeigt wird

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -StandardLoadBalancerName <newStandardLBName> -FollowLog

Beispiel: Upgrade mit alternativem Sicherungspfad

Durchführen eines Upgrades von Load Balancer Basic auf Load Balancer Standard mit dem angegebenen Namen und Speichern der Load Balancer Basic-Sicherungsdatei im angegebenen Pfad

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -StandardLoadBalancerName <newStandardLBName> -RecoveryBackupPath C:\BasicLBRecovery

Beispiel: Überprüfen der abgeschlossenen Migration

Überprüfen einer abgeschlossenen Migration durch Übergeben der Sicherung der Zustandsdatei der Load Balancer Basic-Instanz und des Namens der Load Balancer Standard-Instanz

Start-AzBasicLoadBalancerUpgrade -validateCompletedMigration -StandardLoadBalancerName <newStandardLBName> -basicLoadBalancerStatePath C:\RecoveryBackups\State_mybasiclb_rg-basiclbrg_20220912T1740032148.json

Gleichzeitiges Migrieren mehrerer Lastenausgleichsmodule mit freigegebenen Back-End-Mitgliedern, in der Regel wenn eine Anwendung über einen internen und einen externen Lastenausgleich verfügt

# build array of multiple basic load balancers
$multiLBConfig = @(
    @{
        'standardLoadBalancerName' = 'myStandardInternalLB01' # specifying the standard load balancer name is optional
        'basicLoadBalancer' = (Get-AzLoadBalancer -ResourceGroupName myRG -Name myBasicInternalLB01)
    },
        @{
        'standardLoadBalancerName' = 'myStandardExternalLB02'
        'basicLoadBalancer' = (Get-AzLoadBalancer -ResourceGroupName myRG -Name myBasicExternalLB02)
    }
)
# pass the array of load balancer configurations to the -MultiLBConfig parameter
Start-AzBasicLoadBalancerUpgrade -MultiLBConfig $multiLBConfig

Beispiel: Wiederholen einer fehlgeschlagenen Migration einer VM-Skalierungsgruppe

Wiederholen eines (aufgrund eines Fehlers oder einer Skriptbeendigung) nicht erfolgreichen Upgrades für den Lastenausgleich einer VM-Skalierungsgruppe durch Bereitstellen der Sicherungszustandsdatei für die Load Balancer Basic-Instanz und die VM-Skalierungsgruppe

Start-AzBasicLoadBalancerUpgrade -FailedMigrationRetryFilePathLB C:\RecoveryBackups\State_mybasiclb_rg-basiclbrg_20220912T1740032148.json -FailedMigrationRetryFilePathVMSS C:\RecoveryBackups\VMSS_myVMSS_rg-basiclbrg_20220912T1740032148.json

Beispiel: Wiederholen einer fehlgeschlagenen VM-Migration

Wiederholen eines (aufgrund eines Fehlers oder einer Skriptbeendigung) nicht erfolgreichen Upgrades für einen VM-Lastenausgleich einer VM-Skalierungsgruppe durch Bereitstellen der Sicherungszustandsdatei für die Load Balancer Basic-Instanz

Start-AzBasicLoadBalancerUpgrade -FailedMigrationRetryFilePathLB C:\RecoveryBackups\State_mybasiclb_rg-basiclbrg_20220912T1740032148.json

Häufig gestellte Fragen

Wie kann ich die grundlegenden Lastenausgleichsgeräte auflisten, die in meiner Umgebung migriert werden sollen?

Eine Möglichkeit zum Abrufen einer Liste der grundlegenden Lastenausgleichsgeräte, die in Ihrer Umgebung migriert werden müssen, ist die Verwendung einer Azure Resource Graph-Abfrage. Eine einfache Abfrage wie diese listet alle grundlegenden Lastenausgleichsgeräte auf, auf die Sie Zugriff haben.

Resources
| where type == 'microsoft.network/loadbalancers' and sku.name == 'Basic'

Darüber hinaus haben wir eine komplexere Abfrage geschrieben, die die Bereitschaft jedes einfachen Lastenausgleichsmoduls für die Migration bei den meisten Kriterien bewertet, die dieses Modul während der Validierung überprüft. Die Resource Graph-Abfrage befindet sich in unserem GitHub-Projekt oder wird im Azure Resource Graph-Explorergeöffnet.

Führt diese Migration zu Ausfallzeiten für meine Anwendung?

Ja, da Load Balancer Basic entfernt werden muss, bevor die neue Load Balancer Standard erstellt werden kann, kommt es zu Ausfallzeiten für Ihre Anwendung. Weitere Informationen finden Sie unter Wie lange dauert das Upgrade?

Migriert das Modul meine Front-End-IP-Adresse zur neuen Load Balancer Standard-Instanz?

Ja, für öffentliche und interne Lastenausgleiche stellt das Modul sicher, dass Front-End-IP-Adressen beibehalten werden. Bei öffentlichen IPs wird die IP vor der Migration in eine statische IP konvertiert. Bei internen Front-Ends versucht das Modul, dieselbe IP-Adresse neu zuzuweisen, die beim Löschen des Basic Load Balancers freigegeben wurde. Wenn die private IP nicht verfügbar ist, schlägt das Skript fehl (siehe Was geschieht, wenn mein Upgrade bei der Mid-Migration fehlschlägt?).

Wie lange dauert das Upgrade?

Beim Upgrade dauert es in der Regel einige Minuten, bis das Skript abgeschlossen ist. Die folgenden Faktoren können zu einem längeren Upgradevorgang führen:

Komplexität der Konfiguration für den Lastenausgleich
Anzahl der Back-End-Poolmitglieder
Anzahl der Instanzen der zugeordneten Virtual Machine Scale Sets oder Virtual Machines
Service Fabric-Cluster: Upgrades für Service Fabric-Cluster dauern beim Testen ca. eine Stunde.

Denken Sie an die Ausfallzeiten und planen Sie gegebenenfalls einen Failover ein.

Werden meine Back-End-Poolmitglieder durch das Skript von der Load Balancer Basic-Instanz zur neu erstellten Load Balancer Standard-Instanz migriert?

Ja. Das Azure PowerShell-Skript migriert die VM-Skalierungsgruppen zu den neu erstellten Load Balancer Standard-Back-End-Pools.

Welche Lastenausgleichskomponenten werden migriert?

Das Skript migriert Folgendes von der Load Balancer Basic-Instanz zur Load Balancer Standard-Instanz:

Öffentlicher und privater Lastenausgleich:

Integritätstests:
- Alle Integritätstests werden zur neuen Load Balancer Standard-Instanz migriert.
Lastenausgleichsregeln:
- Alle Lastenausgleichsregeln werden zur neuen Load Balancer Standard-Instanz migriert.
NAT-Regeln für eingehenden Datenverkehr:
- Alle vom Benutzer erstellten NAT-Regeln werden zur neuen Load Balancer Standard-Instanz migriert.
NAT-Eingangspools:
- Nat-Pools werden standardmäßig auf NAT-Regeln aktualisiert.
- Wenn Sie stattdessen NAT-Pools migrieren möchten, geben Sie beim Upgrade den Parameter „-skipUpgradeNATPoolsToNATRules“ an.
Back-End-Pools:
- Alle Back-End-Pools werden zur neuen Load Balancer Standard-Instanz migriert.
- Alle Netzwerkschnittstellen und IP-Konfigurationen der VM-Skalierungsgruppe und des virtuellen Computers werden zur neuen Load Balancer Standard-Instanz migriert.
- Wenn eine VM-Skalierungsgruppe eine Richtlinie für parallele Upgrades verwendet, ändert das Skript die Upgraderichtlinie für die VM-Skalierungsgruppe während des Migrationsvorgangs in „Manuell“ und nach Abschluss der Migration wieder in „Parallel“.
Öffentliche IP-Adressen auf Instanzebene
- Konvertiert angefügte öffentliche IP-Adressen sowohl für virtuelle Computer als auch für VM-Skalierungsgruppen von der Basic- in die Standard-SKU. Hinweis: Öffentliche IP-Adressen der Skalierungsgruppeninstanz ändern sich im Zuge des Upgrades. IP-Adressen von VMs bleiben dagegen bestehen.
Tags von Load Balancer Basic zu Load Balancer Standard

Öffentlicher Lastenausgleich:

Konfiguration der IP-Adresse für das öffentliche Front-End
- Konvertiert die öffentliche IP-Adresse in eine statische IP-Adresse (falls dynamisch)
- Führt ein Update für die SKU der öffentlichen IP-Adresse auf die Standard-SKU durch (falls Basic)
- Führt ein Upgrade für alle zugeordneten öffentlichen IP-Adressen auf die neue Load Balancer Standard-Instanz durch
Ausgangsregeln:
- Load Balancer Basic-Instanzen unterstützen keine konfigurierten Ausgangsregeln. Das Skript erstellt eine Ausgangsregel in der Load Balancer Standard-Instanz, um das Verhalten der Load Balancer Basic-Instanz für ausgehenden Datenverkehr beizubehalten. Weitere Informationen zu Ausgangsregeln finden Sie unter Ausgangsregeln.
Netzwerksicherheitsgruppe
- Load Balancer Basic erfordert keine Netzwerksicherheitsgruppe, um ausgehende Konnektivität zuzulassen. Falls der VM-Skalierungsgruppe keine Netzwerksicherheitsgruppe zugeordnet ist, wird eine neue Netzwerksicherheitsgruppe erstellt, um dieselbe Funktionalität beizubehalten. Diese neue Netzwerksicherheitsgruppe wird den Netzwerkschnittstellen für die Back-End-Poolmitglieder der VM-Skalierungsgruppe zugeordnet. Sie ermöglicht die Verwendung der gleichen Ports und Protokolle für Lastenausgleichsregeln und behält die ausgehende Konnektivität bei.

Interner Lastenausgleich:

Konfiguration der IP-Adresse für das private Front-End

Hinweis

Netzwerksicherheitsgruppen werden nicht als Teil des Upgrades für interne Load Balancer konfiguriert. Weitere Informationen zu Netzwerksicherheitsgruppen finden Sie unter Netzwerksicherheitsgruppen.

Wie führe ich die Migration durch, wenn meine Back-End-Poolmitglieder zu mehreren Load Balancer-Instanzen gehören?

Wenn Ihre Back-End-Poolmitglieder auch Back-End-Pools in einer anderen Load Balancer-Instanz angehören (also wenn Sie beispielsweise über interne und externe Load Balancer-Instanzen für die gleiche Anwendung verfügen), müssen die Load Balancer Basic-Instanzen gleichzeitig migriert werden. Wenn Sie versuchen, die Load Balancer-Instanzen einzeln zu migrieren, käme es zu einer Mischung von Basic- und Standard-SKU-Ressourcen, was nicht zulässig ist. Das Migrationsskript unterstützt dies durch die Übergabe mehrerer Load Balancer Basic-Instanzen an die gleiche Skriptausführung unter Verwendung des Parameters -MultiLBConfig.

Wie kann ich überprüfen, ob eine Migration erfolgreich war?

Am Ende der Ausführung führt das Upgrademodul die folgenden Überprüfungen durch, um die Load Balancer Basic-Instanz mit der neuen Load Balancer Standard-Instanz zu vergleichen. Bei einer nicht erfolgreichen Migration kann dieser Vorgang unter Verwendung der Parameter -validateCompletedMigration und -basicLoadBalancerStatePath aufgerufen werden, um den Konfigurationszustand der Load Balancer Standard-Instanz zu ermitteln (sofern eine erstellt wurde). Die während der Migration erstellte Protokolldatei enthält auch ausführliche Details zum Migrationsvorgang und zu Fehlern.

Die Load Balancer Standard-Instanz ist vorhanden, und die SKU lautet „Standard“.
Die Anzahl von Front-End-IP-Konfigurationen stimmt überein, und die IP-Adressen sind identisch.
Die Anzahl von Back-End-Pools und ihre Mitgliedschaften stimmen überein.
Die Anzahl von Lastenausgleichsregeln stimmt überein.
Die Anzahl von Integritätstests stimmt überein.
Die Anzahl von NAT-Regeln für eingehenden Datenverkehr stimmt überein.
Die Anzahl von NAT-Pools für eingehenden Datenverkehr stimmt überein.
Externe Load Balancer Standard-Instanzen verfügen über eine konfigurierte Ausgangsregel.
Back-End-Poolmitgliedern externer Load Balancer Standard-Instanzen sind Netzwerksicherheitsgruppen zugeordnet.

Wie soll ich ausgehenden Datenverkehr für meinen Load Balancer konfigurieren?

Standard-SKU-Load Balancers ermöglichen keinen standardmäßigen ausgehenden Zugriff für ihre Back-End-Poolmitglieder. Das Zulassen des ausgehenden Zugriffs auf das Internet erfordert weitere Schritte.

Bei externen Load Balancern können Sie Ausgangsregeln verwenden, um ausgehenden Datenverkehr für Ihre Poolmitglieder explizit zu aktivieren. Wenn Sie über einen einzelnen Backend-Pool verfügen, konfigurieren wir während der Migration automatisch eine ausgehende Regel für Sie. Wenn Sie über mehr als einen Backend-Pool verfügen, müssen Sie Ihre Ausgangsregeln manuell erstellen, um Portzuweisungen anzugeben.

Für interne Load Balancer sind Ausgangsregeln keine Option, da es keine öffentliche IP-Adresse für SNAT gibt. Dies lässt einige Optionen, die wir betrachten sollten:

NAT-Gateway: NAT-Gateways sind in den meisten Fällen die empfohlene Vorgehensweise von Azure für ausgehenden Datenverkehr. NAT-Gateways erfordern jedoch, dass das angefügte Subnetz keine grundlegenden SKU-Netzwerkressourcen enthält. Dies bedeutet, dass Sie alle Ihre Load Balancer und öffentliche IP-Adressen migriert haben müssen, bevor Sie sie verwenden können. Aus diesem Grund empfehlen wir die Verwendung eines zweistufigen Ansatzes, bei dem Sie zuerst einen der folgenden Ansätze für ausgehende Konnektivität verwenden, und dann nach Abschluss der grundlegenden SKU-Migrationen zu NAT-Gateways wechseln.
Virtuelle Netzwerk-Appliance: Leiten Sie Ihren Datenverkehr über eine virtuelle Netzwerk-Appliance (z. B. eine Azure-Firewall) weiter, die wiederum Ihren Datenverkehr an das Internet weiterleitet. Diese Option ist ideal, wenn Sie bereits eine Network Virtual Appliance konfiguriert haben.
Secondary External Load Balancer: Durch Hinzufügen eines sekundären externen Lastenausgleichs zu Ihren Backend-Ressourcen können Sie den externen Lastenausgleich für ausgehenden Datenverkehr verwenden, indem Sie Ausgangsregeln konfigurieren. Wenn dieser externe Load Balancer keine Lastenausgleichsregeln, NAT-Regeln oder eingehende NAT-Pools konfiguriert hat, bleiben Ihre Backend-Ressourcen für eingehenden Datenverkehr isoliert – siehe Konfiguration des reinen ausgehenden Load Balancers. Mit dieser Option kann der externe Load Balancer vor der Migration von der einfachen zu Standard-SKU konfiguriert und gleichzeitig mit dem internen Lastenausgleich mithilfe des -MultiLBConfig-Parameters migriert werden.
Öffentliche IP-Adressen: Schließlich können öffentliche IP-Adressen direkt zu Ihren VMs oder Instanzen des Virtual Machine Scale Set hinzugefügt werden. Diese Option wird jedoch aufgrund des zusätzlichen Sicherheitsbereichs und der Kosten für das Hinzufügen öffentlicher IP-Adressen nicht empfohlen.

Was geschieht, wenn beim Upgrade während der Migration ein Fehler auftritt?

Das Modul wurde so entworfen, dass Fehler enthalten sind, die entweder aufgrund von nicht behandelten Fehlern oder einer unerwarteten Skriptbeendigung auftreten. Beim Fehlerdesign wird ein Fail-Forward-Ansatz verfolgt, bei dem Sie anstatt der erneuten Verwendung von Load Balancer Basic versuchen sollten, das Problem zu beheben, das den Fehler verursacht (siehe Fehlerausgabe oder Protokolldatei). Führen Sie die Migration anschließend unter Angabe der Parameter -FailedMigrationRetryFilePathLB <BasicLoadBalancerBackupFilePath> -FailedMigrationRetryFilePathVMSS <VMSSBackupFile> erneut durch. Da für die SKU für die öffentliche IP-Adresse ein Update auf „Standard“ durchgeführt wurde, ist das Verschieben derselben IP-Adresse zurück in eine Load Balancer Basic-Instanz bei öffentlichen Lastenausgleichen nicht möglich.

Sehen Sie sich ein Video des Wiederherstellungsvorgangs an:

Falls die nicht erfolgreiche Migration auf mehrere Load Balancer-Instanzen ausgerichtet war, verwenden Sie den Parameter -MultiLBConfig, um die einzelnen Load Balancer-Instanzen nacheinander mithilfe des weiter unten beschriebenen Prozesses wiederherzustellen.

Der grundlegende Fehlerwiederherstellungsvorgang lautet wie folgt:

Beheben Sie die Ursache des Migrationsfehlers. Überprüfen Sie die Protokolldatei Start-AzBasicLoadBalancerUpgrade.log auf Details.
Entfernen Sie die neu erstellte Load Balancer Standard-Instanz (falls erstellt). Je nachdem, in welcher Migrationsphase der Fehler aufgetreten ist, müssen Sie möglicherweise den Verweis auf Load Balancer Standard aus den Netzwerkschnittstellen (IP-Konfigurationen) und Integritätstests der VM-Skalierungsgruppen und virtuellen Computer entfernen, um die Load Balancer Standard-Instanz zu entfernen.
Suchen Sie die Statussicherungsdatei für die Load Balancer Basic-Instanz. Diese befindet sich entweder in dem Verzeichnis, in dem das Skript ausgeführt wurde, oder im Pfad, der bei der fehlgeschlagenen Ausführung mit dem Parameter -RecoveryBackupPath angegeben wurde. Die Datei heißt State_<basicLBName>_<basicLBRGName>_<timestamp>.json.
Führen Sie das Migrationsskript erneut aus, und geben Sie dabei anstelle von „-BasicLoadBalancerName“ die Parameter „-FailedMigrationRetryFilePathLB <BasicLoadBalancerbackupFilePath>“ und „-FailedMigrationRetryFilePathVMSS <VMSSBackupFile>“ (für Virtual Machine-Skalierungssatz-Back-Ends) an, oder übergeben Sie die Load Balancer Basic-Instanz über die Pipeline.

Freigeben über

Upgraden von Load Balancer Basic mit PowerShell

Übersicht über das Upgrade

Nicht unterstützte Szenarien

Installieren des Moduls „AzureBasicLoadBalancerUpgrade“

Voraussetzungen

Modulinstallation

Schritte vor und nach der Migration

Schritte zur Migrationsvorbereitung

Schritte nach der Migration

Verwenden des Moduls

Beispiel: Überprüfen eines Szenarios

Beispiel: Upgrade nach Name

Beispiel: Upgrade, Ändern des Namens und Anzeigen von Protokollen

Beispiel: Upgrade mit alternativem Sicherungspfad

Beispiel: Überprüfen der abgeschlossenen Migration

Beispiel: Wiederholen einer fehlgeschlagenen Migration einer VM-Skalierungsgruppe

Beispiel: Wiederholen einer fehlgeschlagenen VM-Migration

Häufig gestellte Fragen

Wie kann ich die grundlegenden Lastenausgleichsgeräte auflisten, die in meiner Umgebung migriert werden sollen?

Führt diese Migration zu Ausfallzeiten für meine Anwendung?

Migriert das Modul meine Front-End-IP-Adresse zur neuen Load Balancer Standard-Instanz?

Wie lange dauert das Upgrade?

Werden meine Back-End-Poolmitglieder durch das Skript von der Load Balancer Basic-Instanz zur neu erstellten Load Balancer Standard-Instanz migriert?

Welche Lastenausgleichskomponenten werden migriert?

Wie führe ich die Migration durch, wenn meine Back-End-Poolmitglieder zu mehreren Load Balancer-Instanzen gehören?

Wie kann ich überprüfen, ob eine Migration erfolgreich war?

Wie soll ich ausgehenden Datenverkehr für meinen Load Balancer konfigurieren?

Was geschieht, wenn beim Upgrade während der Migration ein Fehler auftritt?

Nächste Schritte

Feedback

Zusätzliche Ressourcen

Freigeben über

Upgraden von Load Balancer Basic mit PowerShell

Übersicht über das Upgrade

Nicht unterstützte Szenarien

Installieren des Moduls „AzureBasicLoadBalancerUpgrade“

Voraussetzungen

Modulinstallation

Schritte vor und nach der Migration

Schritte zur Migrationsvorbereitung

Schritte nach der Migration

Verwenden des Moduls

Beispiel: Überprüfen eines Szenarios

Beispiel: Upgrade nach Name

Beispiel: Upgrade, Ändern des Namens und Anzeigen von Protokollen

Beispiel: Upgrade mit alternativem Sicherungspfad

Beispiel: Überprüfen der abgeschlossenen Migration

Beispiel: Migrieren mehrerer verwandter Lastenausgleichsmodule

Beispiel: Wiederholen einer fehlgeschlagenen Migration einer VM-Skalierungsgruppe

Beispiel: Wiederholen einer fehlgeschlagenen VM-Migration

Häufig gestellte Fragen

Wie kann ich die grundlegenden Lastenausgleichsgeräte auflisten, die in meiner Umgebung migriert werden sollen?

Führt diese Migration zu Ausfallzeiten für meine Anwendung?

Migriert das Modul meine Front-End-IP-Adresse zur neuen Load Balancer Standard-Instanz?

Wie lange dauert das Upgrade?

Werden meine Back-End-Poolmitglieder durch das Skript von der Load Balancer Basic-Instanz zur neu erstellten Load Balancer Standard-Instanz migriert?

Welche Lastenausgleichskomponenten werden migriert?

Wie führe ich die Migration durch, wenn meine Back-End-Poolmitglieder zu mehreren Load Balancer-Instanzen gehören?

Wie kann ich überprüfen, ob eine Migration erfolgreich war?

Wie soll ich ausgehenden Datenverkehr für meinen Load Balancer konfigurieren?

Was geschieht, wenn beim Upgrade während der Migration ein Fehler auftritt?

Nächste Schritte

Feedback

Zusätzliche Ressourcen