Delen via

Een eenvoudige load balancer upgraden met PowerShell

  • Artikel

Belangrijk

Op 30 september 2025 wordt Basic Load Balancer buiten gebruik gesteld. Zie de officiële aankondiging voor meer informatie. Als u momenteel Basic Load Balancer gebruikt, moet u een upgrade uitvoeren naar Standard Load Balancer vóór de buitengebruikstellingsdatum.

Azure Standard Load Balancer biedt een uitgebreide set functionaliteit en hoge beschikbaarheid via zoneredundantie. Zie de vergelijkingstabel voor meer informatie over de Load Balancer-SKU.

In dit artikel wordt een PowerShell-module geïntroduceerd waarmee een Standard Load Balancer wordt gemaakt met dezelfde configuratie als de Basic Load Balancer. Vervolgens worden de leden van de virtuele-machineschaalset of de back-endpool van de virtuele machine gekoppeld aan de nieuwe Load Balancer.

Zie de volgende video voor een uitgebreid overzicht van de upgrademodule en het proces:

Upgradeoverzicht

De PowerShell-module voert de volgende functies uit:

  • Controleert of het opgegeven Basic Load Balancer-scenario wordt ondersteund voor een upgrade.
  • Hiermee wordt een back-up gemaakt van de basic load balancer en de configuratie van de virtuele-machineschaalset, waardoor opnieuw wordt geprobeerd bij een fout of als er fouten zijn opgetreden.
  • Voor openbare load balancers werkt u de openbare IP-adressen van de front-end bij naar standard-SKU en statische toewijzing
  • Hiermee wordt de Basic Load Balancer-configuratie bijgewerkt naar een nieuwe Standard Load Balancer, waardoor de configuratie en functiepariteit worden gegarandeerd.
  • Migreert de leden van de virtuele-machineschaalset en de back-endpool van de virtuele machine van de Basic Load Balancer naar de Standard Load Balancer.
  • Hiermee maakt en koppelt u een netwerkbeveiligingsgroep aan de virtuele-machineschaalset of virtuele machine om ervoor te zorgen dat verkeer met gelijke taakverdeling leden van de back-endpool bereikt, na de verplaatsing van Standard Load Balancer naar een standaardnetwerkbeleid voor weigeren.
  • Hiermee worden openbare IP-adressen op exemplaarniveau bijgewerkt die zijn gekoppeld aan virtuele-machineschaalset- of virtuele-machine-exemplaren
  • Hiermee worden binnenkomende NAT-pools bijgewerkt naar binnenkomende NAT-regels voor back-ends van virtuele-machineschaalsets. Geef -skipUpgradeNATPoolsToNATRules op om deze upgrade over te slaan.
  • Registreert de upgradebewerking voor eenvoudige controle en herstel van fouten.

Waarschuwing

Voor het migreren van interne Basic Load Balancers waarbij de back-end-VM's of VMSS-exemplaren geen openbare IP-adressen hebben, zijn aanvullende stappen vereist voor back-endconnectiviteit met internet. Bekijk hoe kan ik uitgaand verkeer configureren voor mijn Load Balancer?

Notitie

Als de virtuele-machineschaalset in de back-endpool van de load balancer openbare IP-adressen heeft in de netwerkconfiguratie, worden de openbare IP-adressen die zijn gekoppeld aan elk exemplaar van de virtuele-machineschaalset gewijzigd wanneer ze worden bijgewerkt naar standard-SKU. Dit komt doordat openbare IP-adressen op exemplaarniveau van de schaalset niet kunnen worden bijgewerkt, alleen vervangen door een nieuw openbaar IP-adres van de standard-SKU. Alle andere openbare IP-adressen worden tijdens de migratie bewaard.

Notitie

Als de virtuele-machineschaalset achter de load balancer een Service Fabric-cluster is, duurt de migratie met dit script meer tijd, loopt het hogere risico op uw toepassing en leidt dit tot downtime. Bekijk de upgraderichtlijnen voor Service Fabric-cluster load balancer voor migratieopties.

Niet-ondersteunde scenario's

  • Basic Load Balancers met IPv6-front-end-IP-configuraties
  • Basic Load Balancers voor AKS-clusters (Azure Kubernetes Services)
  • Basic Load Balancers met een lid van de back-endpool van een virtuele-machineschaalset waarvoor een of meer exemplaren van een virtuele-machineschaalset protectFromScaleSetActions Instance Protection-beleid hebben ingeschakeld
  • Een basic load balancer migreren naar een bestaande Standard Load Balancer

De module 'AzureBasicLoadBalancerUpgrade' installeren

Vereisten

  • PowerShell: Een ondersteunde versie van PowerShell versie 7 of hoger wordt aanbevolen voor gebruik met de Module AzureBasicLoadBalancerUpgrade op alle platforms, waaronder Windows, Linux en macOS. PowerShell 5.1 in Windows wordt echter ondersteund.
  • Az PowerShell-module: Bepalen of u de meest recente Az PowerShell-module hebt geïnstalleerd
  • Az.ResourceGraph PowerShell-module: de Az.ResourceGraph PowerShell-module wordt gebruikt om tijdens de upgrade een query uit te voeren op de resourceconfiguratie en is een afzonderlijke installatie van de Az PowerShell-module. Deze wordt automatisch toegevoegd als u de AzureBasicLoadBalancerUpgrade module installeert met behulp van de Install-Module opdracht.

Module-installatie

De module installeren vanuit de PowerShell-galerie

PS C:\> Install-Module -Name AzureBasicLoadBalancerUpgrade -Scope CurrentUser -Repository PSGallery -Force

Stappen vóór en na de migratie

Stappen voorafgaand aan de migratie

  • Controleer of uw scenario wordt ondersteund
  • Downtime van toepassingen plannen tijdens de migratie
  • Binnenkomende en uitgaande connectiviteitstests ontwikkelen voor uw verkeer
  • Openbare IP-wijzigingen op exemplaarniveau plannen voor instanties van virtuele-machineschaalsets (zie opmerking)
  • [Aanbevolen] Maak netwerkbeveiligingsgroepen of voeg beveiligingsregels toe aan een bestaande netwerkbeveiligingsgroep voor leden van uw back-endpool. Sta het verkeer toe via de Load Balancer en elk ander verkeer dat expliciet moet worden toegestaan op openbare Standard SKU-resources
  • [Aanbevolen] Bereid uw uitgaande connectiviteit voor, waarbij een van de volgende methoden wordt beschreven in Hoe kan ik uitgaand verkeer configureren voor mijn Load Balancer?

Stappen na migratie

  • Controleer of de migratie is geslaagd
  • Binnenkomende toepassingsconnectiviteit testen via de Load Balancer
  • Uitgaande connectiviteit van leden van back-endpools naar internet testen
  • Voor openbare load balancers met meerdere back-endpools maakt u uitgaande regels voor elke back-endpool

De module gebruiken

  1. Gebruik Connect-AzAccount dit om verbinding te maken met Azure, waarbij u de abonnements-id van de Basic Load Balancer opgeeft als u meer dan één abonnement hebt.

    PS C:\> Connect-AzAccount -Subscription <SubscriptionId>

  2. Zoek de Load Balancer die u wilt upgraden. Noteer de naam en de naam van de resourcegroep.

  3. Bekijk de basismoduleparameters:

    • BasicLoadBalancerName [tekenreeks] Vereist - Deze parameter is de naam van de bestaande Basic Load Balancer die u wilt upgraden
    • ResourceGroupName [tekenreeks] Vereist : deze parameter is de naam van de resourcegroep die de Basic Load Balancer bevat
    • StandardLoadBalancerName [string] Optioneel : gebruik deze parameter om desgewenst een nieuwe naam voor de Standard Load Balancer te configureren. Als dit niet is opgegeven, wordt de naam van de Basic Load Balancer opnieuw gebruikt.
    • RecoveryBackupPath [tekenreeks] Optioneel : met deze parameter kunt u een alternatief pad opgeven waarin het back-upbestand van de Arm-sjabloon basic load balancer moet worden opgeslagen (standaard ingesteld op de huidige werkmap)

    Tip

    Aanvullende parameters voor geavanceerde scenario's en herstelscenario's kunnen worden weergegeven door het uitvoeren van Get-Help Start-AzBasicLoadBalancerUpgrade -Detailed

  4. Voer de opdracht Upgrade uit.

Voorbeeld: een scenario valideren

Valideren dat een Basic Load Balancer wordt ondersteund voor een upgrade

PS C:\> Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -validateScenarioOnly

Voorbeeld: upgraden op naam

Een Basic Load Balancer upgraden naar een Standard Load Balancer met dezelfde naam, waarbij de basic load balancer-naam en resourcegroepnaam worden opgegeven

PS C:\> Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName>

Voorbeeld: upgraden, naam wijzigen en logboeken weergeven

Een Basic Load Balancer upgraden naar een Standard Load Balancer met de opgegeven naam, met de vastgelegde uitvoer op het scherm

PS C:\> Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -StandardLoadBalancerName <newStandardLBName> -FollowLog

Voorbeeld: upgraden met alternatief back-uppad

Een Basic Load Balancer upgraden naar een Standard Load Balancer met de opgegeven naam en het back-upbestand van de Basic Load Balancer opslaan op het opgegeven pad

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

Voorbeeld: voltooide migratie valideren

Een voltooide migratie valideren door de back-up van het statusbestand basic load balancer en de naam van de Standard Load Balancer door te geven

PS C:\> Start-AzBasicLoadBalancerUpgrade -validateCompletedMigration -basicLoadBalancerStatePath C:\RecoveryBackups\State_mybasiclb_rg-basiclbrg_20220912T1740032148.json

Meerdere load balancers tegelijk migreren met gedeelde back-endleden, meestal wanneer een toepassing een interne en een externe Load Balancer heeft

# build array of multiple basic load balancers
PS C:\> $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
PS C:\> Start-AzBasicLoadBalancerUpgrade -MultiLBConfig $multiLBConfig

Voorbeeld: mislukte migratie van virtuele-machineschaalsets opnieuw uitvoeren

Voer een mislukte upgrade opnieuw uit voor de load balancer van een virtuele-machineschaalset (vanwege fout- of scriptafbreking) door het back-upstatusbestand basic load balancer en virtuele-machineschaalset op te geven

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

Voorbeeld: mislukte migratie van virtuele machines opnieuw proberen

Voer een mislukte upgrade opnieuw uit voor een VM-load balancer (vanwege fout- of scriptafbreking) door het back-upstatusbestand basic load balancer op te geven

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

Veelgestelde vragen

Hoe kan ik de Basic Load Balancers vermelden die in mijn omgeving moeten worden gemigreerd?

Een manier om een lijst op te halen met de Basic Load Balancers die moeten worden gemigreerd in uw omgeving, is door een Azure Resource Graph-query te gebruiken. Met een eenvoudige query zoals deze worden alle Basic Load Balancers weergegeven die u kunt zien.

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

'' We hebben ook een complexere query geschreven waarmee de gereedheid van elke Basic Load Balancer voor migratie wordt beoordeeld op de meeste criteria die tijdens de validatie door deze module worden gecontroleerd. De Resource Graph-query vindt u in ons GitHub-project of geopend in Azure Resource Graph Explorer.

Veroorzaakt deze migratie downtime voor mijn toepassing?

Ja, omdat de Basic Load Balancer moet worden verwijderd voordat de nieuwe Standard Load Balancer kan worden gemaakt, is er downtime voor uw toepassing. Zie hoe lang duurt de upgrade?

Migreert de module mijn front-end-IP-adres naar de nieuwe Standard Load Balancer?

Ja, voor zowel openbare als interne load balancers zorgt de module ervoor dat front-end-IP-adressen worden onderhouden. Voor openbare IP-adressen wordt het IP-adres vóór de migratie geconverteerd naar een statisch IP-adres. Voor interne front-ends probeert de module hetzelfde IP-adres opnieuw toe te voegen dat is vrijgemaakt toen de Basic Load Balancer werd verwijderd. Als het privé-IP-adres niet beschikbaar is, mislukt het script (zie Wat gebeurt er als mijn upgrade halverwege de migratie mislukt?).

Hoe lang duurt de upgrade?

Het uitvoeren van de upgrade duurt normaal gesproken enkele minuten voordat het script is voltooid. De volgende factoren kunnen leiden tot langere upgradetijden:

  • Complexiteit van de configuratie van uw load balancer
  • Aantal leden van back-endpool
  • Aantal exemplaren van gekoppelde virtuele-machineschaalsets of virtuele machinesf
  • Service Fabric-cluster: upgrades voor Service Fabric-clusters nemen ongeveer een uur in de testfase in beslag

Houd rekening met de downtime en plan indien nodig een failover.

Migreert het script de leden van mijn back-endpool van mijn Basic Load Balancer naar de zojuist gemaakte Standard Load Balancer?

Ja. Met het Azure PowerShell-script worden de virtuele-machineschaalsets en virtuele machines gemigreerd naar de zojuist gemaakte back-endpools van Standard Load Balancer.

Welke load balancer-onderdelen worden gemigreerd?

Het script migreert het volgende van de Basic Load Balancer naar de Standard Load Balancer:

Openbare en persoonlijke load balancers:

  • Statustests:
    • Alle tests worden gemigreerd naar de nieuwe Standard Load Balancer
  • Taakverdelingsregels:
    • Alle taakverdelingsregels worden gemigreerd naar de nieuwe Standard Load Balancer
  • Binnenkomende NAT-regels:
    • Alle door de gebruiker gemaakte NAT-regels worden gemigreerd naar de nieuwe Standard Load Balancer
  • Binnenkomende NAT-pools:
    • NAT-pools worden standaard bijgewerkt naar NAT-regels
    • Als u in plaats daarvan NAT-pools wilt migreren, geeft u de parameter op bij het -skipUpgradeNATPoolsToNATRules upgraden
  • Back-endpools:
    • Alle back-endpools worden gemigreerd naar de nieuwe Standard Load Balancer
    • Alle virtuele-machineschaalset- en virtuele-machinenetwerkinterfaces en IP-configuraties worden gemigreerd naar de nieuwe Standard Load Balancer
    • Als een virtuele-machineschaalset gebruikmaakt van beleid voor rolling upgrades, werkt het script het upgradebeleid van de virtuele-machineschaalset bij naar 'Handmatig' tijdens het migratieproces en wordt deze teruggezet naar Rolling nadat de migratie is voltooid.
  • Openbare IP-adressen op exemplaarniveau
    • Voor zowel virtuele machines als virtuele-machineschaalsets converteert u gekoppelde openbare IP-adressen van Basic naar Standard-SKU. Let op: openbare IP-adressen van het schaalsetexemplaren worden gewijzigd tijdens de upgrade; IP-adressen van virtuele machines niet.
  • Tags van de Basic Load Balancer naar Standard Load Balancer

Openbare load balancer:

  • Openbare front-end-IP-configuratie
    • Converteert het openbare IP-adres naar een statisch IP-adres, indien dynamisch
    • Hiermee wordt de openbare IP-SKU bijgewerkt naar Standard, indien Basic
    • Alle gekoppelde openbare IP-adressen upgraden naar de nieuwe Standard Load Balancer
  • Regels voor uitgaand verkeer:
  • Netwerkbeveiligingsgroep
    • Basic Load Balancer vereist geen netwerkbeveiligingsgroep om uitgaande connectiviteit toe te staan. Als er geen netwerkbeveiligingsgroep is gekoppeld aan de virtuele-machineschaalset, wordt er een nieuwe netwerkbeveiligingsgroep gemaakt om dezelfde functionaliteit te behouden. Deze nieuwe netwerkbeveiligingsgroep is gekoppeld aan de netwerkinterfaces van de back-endschaalset van de virtuele-machineschaalset. Hiermee worden dezelfde poorten en protocollen voor taakverdeling toegestaan en blijven de uitgaande connectiviteit behouden.

Interne load balancer:

  • Privé-front-end-IP-configuratie

Notitie

Netwerkbeveiligingsgroepen worden niet geconfigureerd als onderdeel van de interne load balancer-upgrade. Zie Netwerkbeveiligingsgroepen voor meer informatie over NSG's

Hoe kan ik migreren wanneer leden van mijn back-endpool deel uitmaken van meerdere Load Balancers?

In een scenario waarin de leden van uw back-endpools ook lid zijn van back-endpools op een andere Load Balancer, zoals wanneer u interne en externe Load Balancers voor dezelfde toepassing hebt, moeten de Basic Load Balancers tegelijkertijd worden gemigreerd. Als u de Load Balancers één voor één probeert te migreren, probeert u Basic- en Standard-SKU-resources te combineren. Dit is niet toegestaan. Het migratiescript ondersteunt dit door meerdere Basic Load Balancers door te geven aan dezelfde scriptuitvoering met behulp van de -MultiLBConfig parameter.

Hoe kan ik controleren of een migratie is geslaagd?

Aan het einde van de uitvoering voert de upgrademodule de volgende validaties uit, zodat de Basic Load Balancer wordt vergeleken met de nieuwe Standard Load Balancer. In een mislukte migratie kan dezelfde bewerking worden aangeroepen met behulp van de -validateCompletedMigration en -basicLoadBalancerStatePath parameters om de configuratiestatus van de Standard Load Balancer te bepalen (als er een is gemaakt). Het logboekbestand dat tijdens de migratie is gemaakt, biedt ook uitgebreide informatie over de migratiebewerking en eventuele fouten.

  • De Standard Load Balancer bestaat en de SKU is 'Standard'
  • Het aantal front-end-IP-configuraties komt overeen en de IP-adressen zijn hetzelfde
  • Het aantal back-endpools en hun lidmaatschapsovereenkomsten
  • Het aantal taakverdelingsregels komt overeen
  • Het aantal statustests komt overeen
  • Het aantal binnenkomende NAT-regels komt overeen
  • Het aantal binnenkomende NAT-pools komt overeen
  • Externe Standard Load Balancers hebben een geconfigureerde uitgaande regel
  • Leden van de back-endpool van externe Standard Load Balancer hebben netwerkbeveiligingsgroepen gekoppeld

Hoe moet ik uitgaand verkeer configureren voor mijn Load Balancer?

Standard SKU Load Balancers staan geen standaard uitgaande toegang toe voor hun leden van de back-endpool. Het toestaan van uitgaande toegang tot internet vereist meer stappen.

Voor externe load balancers kunt u uitgaande regels gebruiken om uitgaand verkeer expliciet in te schakelen voor uw groepsleden. Als u één back-endpool hebt, configureren we automatisch een uitgaande regel voor u tijdens de migratie; als u meer dan één back-endpool hebt, moet u handmatig uw uitgaande regels maken om poorttoewijzingen op te geven.

Voor interne load balancers zijn uitgaande regels geen optie omdat er geen openbaar IP-adres naar SNAT via is. Dit laat een aantal opties over om rekening mee te houden:

  • NAT-gateway: NAT-gateways zijn in de meeste gevallen de aanbevolen benadering van Azure voor uitgaand verkeer. Nat-gateways vereisen echter dat het gekoppelde subnet geen basis-SKU-netwerkresources heeft. Dit betekent dat u al uw load balancers en openbare IP-adressen moet hebben gemigreerd voordat u ze kunt gebruiken. Daarom raden we u aan een tweestapsbenadering te gebruiken waarbij u eerst een van de volgende benaderingen voor uitgaande connectiviteit gebruikt en vervolgens overschakelt naar NAT-gateways zodra uw basis-SKU-migraties zijn voltooid.
  • Virtueel netwerkapparaat: routeer uw verkeer via een virtueel netwerkapparaat, zoals een Azure Firewall, waarmee uw verkeer op zijn beurt naar internet wordt gerouteerd. Deze optie is ideaal als u al een virtueel netwerkapparaat hebt geconfigureerd.
  • Secundaire externe load balancer: door een secundaire externe load balancer toe te voegen aan uw back-endbronnen, kunt u de externe load balancer gebruiken voor uitgaand verkeer door uitgaande regels te configureren. Als voor deze externe load balancer geen taakverdelingsregels, NAT-regels of binnenkomende NAT-pools zijn geconfigureerd, blijven uw back-endbronnen geïsoleerd in uw interne netwerk voor de configuratie van de uitgaande load balancer. Met deze optie kan de externe Load Balancer worden geconfigureerd voordat deze wordt gemigreerd van basic naar standaard-SKU en tegelijkertijd als de interne load balancer wordt gemigreerd met behulp van de -MultiLBConfig parameter
  • Openbare IP-adressen: ten slotte kunnen openbare IP-adressen rechtstreeks worden toegevoegd aan uw virtuele machines of instanties van virtuele-machineschaalsets. Deze optie wordt echter niet aanbevolen vanwege het extra beveiligingsoppervlak en de kosten voor het toevoegen van openbare IP-adressen.

Wat gebeurt er als mijn upgrade halverwege de migratie mislukt?

De module is ontworpen om fouten op te lossen, hetzij vanwege niet-verwerkte fouten of onverwachte scriptafbreking. Het foutontwerp is een 'fail forward'-benadering. In plaats van terug te gaan naar de Basic Load Balancer, moet u het probleem oplossen dat de fout veroorzaakt (zie de foutuitvoer of het logboekbestand) en de migratie opnieuw uitvoeren, waarbij u de -FailedMigrationRetryFilePathLB <BasicLoadBalancerBackupFilePath> -FailedMigrationRetryFilePathVMSS <VMSSBackupFile> parameters opgeeft. Voor openbare load balancers, omdat de SKU van het openbare IP-adres is bijgewerkt naar Standard, is het verplaatsen van hetzelfde IP-adres naar een Basic Load Balancer niet mogelijk.

Bekijk een video van het herstelproces:

Als uw mislukte migratie gericht was op meerdere load balancers tegelijk, met behulp van de -MultiLBConfig parameter, herstelt u elke Load Balancer afzonderlijk met hetzelfde proces als hieronder.

De basisprocedure voor foutherstel is:

  1. Los de oorzaak van de migratiefout op. Controleer het logboekbestand Start-AzBasicLoadBalancerUpgrade.log op details
  2. Verwijder de nieuwe Standard Load Balancer (indien gemaakt). Afhankelijk van de fase van de migratie die is mislukt, moet u mogelijk de Standard Load Balancer-verwijzing verwijderen uit de virtuele-machineschaalset of ip-netwerkinterfaces (IP-configuraties) en statustests om de Standard Load Balancer te verwijderen.
  3. Zoek het back-upbestand van de Basic Load Balancer-status. Dit bestand bevindt zich in de map waarin het script is uitgevoerd of op het pad dat is opgegeven met de -RecoveryBackupPath parameter tijdens de mislukte uitvoering. Het bestand heeft de naam: State_<basicLBName>_<basicLBRGName>_<timestamp>.json
  4. Voer het migratiescript opnieuw uit en geef de -FailedMigrationRetryFilePathLB <BasicLoadBalancerbackupFilePath> parameters en -FailedMigrationRetryFilePathVMSS <VMSSBackupFile> (voor back-ends van virtuele-machineschaalsets) op in plaats van -BasicLoadBalancerName of geef de Basic Load Balancer door via de pijplijn

Volgende stappen