Automatische upgrades van installatiekopieën van virtuele-machineschaalset in Azure
Notitie
Veel van de stappen in dit document zijn van toepassing op virtuele-machineschaalsets met behulp van de modus Uniform Orchestration. We raden u aan Flexibele indeling te gebruiken voor nieuwe workloads. Zie Indelingsmodi voor virtuele-machineschaalsets in Azure voor meer informatie.
Door automatische upgrades van installatiekopieën van het besturingssysteem in te schakelen op uw schaalset, kunt u het updatebeheer vereenvoudigen door de besturingssysteemschijf veilig en automatisch bij te werken voor alle exemplaren in de schaalset.
Automatische upgrade van het besturingssysteem heeft de volgende kenmerken:
- Zodra de installatiekopieën van het besturingssysteem zijn geconfigureerd, die zijn gepubliceerd door uitgevers van installatiekopieën, worden automatisch toegepast op de schaalset zonder tussenkomst van de gebruiker.
- Hiermee worden batches exemplaren op een doorlopende manier bijgewerkt wanneer een nieuwe installatiekopieën worden gepubliceerd door de uitgever.
- Integreert met toepassingsstatustests en Application Health-extensie.
- Werkt voor alle VM-grootten en voor zowel Windows- als Linux-installatiekopieën, inclusief aangepaste installatiekopieën via Azure Compute Gallery.
- U kunt zich op elk gewenst moment afmelden voor automatische upgrades (ook besturingssysteemupgrades kunnen handmatig worden gestart).
- De besturingssysteemschijf van een virtuele machine wordt vervangen door de nieuwe besturingssysteemschijf die is gemaakt met de nieuwste versie van de installatiekopieën. Geconfigureerde extensies en aangepaste gegevensscripts worden uitgevoerd, terwijl persistente gegevensschijven worden bewaard.
- Extensievolgorde wordt ondersteund.
- Kan worden ingeschakeld voor een schaalset van elke grootte.
Notitie
Voordat u automatische upgrades van installatiekopieën van het besturingssysteem inschakelt, raadpleegt u de sectie Vereisten van deze documentatie.
Hoe werkt de automatische upgrade van de installatiekopieën van het besturingssysteem?
Een upgrade werkt door de besturingssysteemschijf van een virtuele machine te vervangen door een nieuwe schijf die is gemaakt met behulp van de installatiekopieënversie. Geconfigureerde extensies en aangepaste gegevensscripts worden uitgevoerd op de besturingssysteemschijf, terwijl gegevensschijven worden bewaard. Om de downtime van de toepassing te minimaliseren, vinden upgrades plaats in batches, met niet meer dan 20% van de upgrade van de schaalset op elk gewenst moment.
U moet een azure Load Balancer-toepassingsstatustest of Application Health-extensie integreren om de status van de toepassing na een upgrade bij te houden. Hierdoor kan het platform de vm-status valideren om ervoor te zorgen dat updates op een veilige manier worden toegepast. We raden u aan een toepassings heartbeat op te nemen om te valideren of de upgrade is geslaagd.
Beschikbaarheid-eerste updates
Het model voor beschikbaarheids-eerste voor platformindelingsupdates die hieronder worden beschreven, zorgt ervoor dat beschikbaarheidsconfiguraties in Azure worden gerespecteerd op meerdere beschikbaarheidsniveaus.
Tussen regio's:
- Een update wordt wereldwijd over Azure verplaatst om gefaseerde implementatiefouten in Azure te voorkomen.
- Een 'fase' kan een of meer regio's hebben en een update wordt alleen over fasen verplaatst als in aanmerking komende VM's in de vorige fase zijn bijgewerkt.
- Geografisch gekoppelde regio's worden niet gelijktijdig bijgewerkt en kunnen zich niet in dezelfde regionale fase bevinden.
- Het succes van een update wordt gemeten door de status van een VM na de update bij te houden.
Binnen een regio:
- VM's in verschillende Beschikbaarheidszones worden niet gelijktijdig bijgewerkt met dezelfde update.
Binnen een 'set':
- Alle VM's in een gemeenschappelijke schaalset worden niet gelijktijdig bijgewerkt.
- VM's in een gemeenschappelijke virtuele-machineschaalset worden gegroepeerd in batches en bijgewerkt binnen de grenzen van het updatedomein, zoals hieronder wordt beschreven.
Het door het platform ingedeelde updatesproces wordt gevolgd voor het implementeren van ondersteunde upgrades van het besturingssysteemplatform elke maand. Voor aangepaste installatiekopieën via Azure Compute Gallery wordt een upgrade van installatiekopieën alleen gestart voor een bepaalde Azure-regio wanneer de nieuwe installatiekopieën worden gepubliceerd en gerepliceerd naar de regio van die schaalset.
Vm's in een schaalset upgraden
De regio van een schaalset komt in aanmerking voor het verkrijgen van installatiekopieënupgrades via het beschikbaarheids-eerste proces voor platforminstallatiekopieën of het repliceren van nieuwe aangepaste installatiekopieën voor Share Image Gallery. De upgrade van de installatiekopieën wordt vervolgens als volgt toegepast op een afzonderlijke schaalset in batch:
- Voordat u begint met het upgradeproces, zorgt de orchestrator ervoor dat niet meer dan 20% van de exemplaren in de hele schaalset beschadigd is (om welke reden dan ook).
- De upgrade-orchestrator identificeert de batch vm-exemplaren die moeten worden bijgewerkt, waarbij elke batch maximaal 20% van het totale aantal exemplaren heeft, afhankelijk van een minimale batchgrootte van één virtuele machine. Er is geen minimale schaalsetgrootte vereist en schaalsets met 5 of minder exemplaren hebben 1 VM per upgradebatch (minimale batchgrootte).
- De besturingssysteemschijf van elke VIRTUELE machine in de geselecteerde upgradebatch wordt vervangen door een nieuwe besturingssysteemschijf die is gemaakt op basis van de installatiekopieën. Alle opgegeven extensies en configuraties in het schaalsetmodel worden toegepast op het bijgewerkte exemplaar.
- Voor schaalsets met geconfigureerde toepassingsstatustests of Application Health-extensie wacht de upgrade tot vijf minuten voordat het exemplaar in orde is, voordat de volgende batch wordt bijgewerkt. Als een exemplaar na een upgrade de status niet binnen 5 minuten herstelt, wordt de vorige besturingssysteemschijf voor het exemplaar standaard hersteld.
- De upgrade-orchestrator houdt ook het percentage exemplaren bij dat na een upgrade niet in orde is. De upgrade wordt gestopt als meer dan 20% van de bijgewerkte exemplaren beschadigd raken tijdens het upgradeproces.
- Het bovenstaande proces wordt voortgezet totdat alle exemplaren in de schaalset zijn bijgewerkt.
De orchestrator voor het upgraden van het besturingssysteem van de schaalset controleert de status van de algehele schaalset voordat elke batch wordt bijgewerkt. Tijdens het upgraden van een batch kunnen er andere gelijktijdig geplande of ongeplande onderhoudsactiviteiten zijn die van invloed kunnen zijn op de status van uw schaalsetexemplaren. Als meer dan 20% van de exemplaren van de schaalset beschadigd raken, stopt de upgrade van de schaalset aan het einde van de huidige batch.
Als u de standaardinstellingen wilt wijzigen die zijn gekoppeld aan Rolling Upgrades, raadpleegt u het rolling upgradebeleid van Azure.
Notitie
Bij een automatische upgrade van het besturingssysteem wordt de SKU van de referentie-installatiekopieën niet bijgewerkt op de schaalset. Als u de SKU (zoals Ubuntu 18.04-LTS wilt wijzigen in 20.04-LTS), moet u het schaalsetmodel rechtstreeks bijwerken met de gewenste installatiekopie-SKU. Afbeeldingsuitgever en aanbieding kunnen niet worden gewijzigd voor een bestaande schaalset.
Upgrade van besturingssysteeminstallatiekopie versus installatiekopie van installatiekopie
Upgrade en installatiekopie van het besturingssysteem zijn methoden voor het bijwerken van VM's binnen een schaalset, maar ze hebben verschillende doeleinden en hebben verschillende gevolgen.
Upgrade van besturingssysteeminstallatiekopieën omvat het bijwerken van de onderliggende installatiekopieën van het besturingssysteem die wordt gebruikt voor het maken van nieuwe exemplaren in een schaalset. Wanneer u een upgrade van de installatiekopieën van het besturingssysteem uitvoert, worden in Azure nieuwe VM-exemplaren gemaakt met de bijgewerkte installatiekopieën van het besturingssysteem en worden de oude VM-exemplaren in de schaalset geleidelijk vervangen door de nieuwe exemplaren. Dit proces wordt doorgaans in fasen uitgevoerd om hoge beschikbaarheid te garanderen. Upgrades van installatiekopieën van het besturingssysteem zijn een niet-verstorende manier om updates of wijzigingen toe te passen op het onderliggende besturingssysteem van de VM's in een schaalset. Bestaande VM-exemplaren worden pas beïnvloed als ze worden vervangen door de nieuwe exemplaren.
Het opnieuw instellen van een VM-exemplaar in een schaalset is een meer onmiddellijke en verstorende actie. Wanneer u ervoor kiest om een VM-exemplaar opnieuw te maken, stopt Azure het geselecteerde VM-exemplaar, voert u de installatiekopiebewerking uit en start u de VM opnieuw op met dezelfde installatiekopie van het besturingssysteem. Hierdoor wordt het besturingssysteem op dat specifieke VM-exemplaar effectief opnieuw geïnstalleerd. Opnieuw opstarten wordt meestal gebruikt wanneer u een specifiek VM-exemplaar moet oplossen of opnieuw moet instellen vanwege problemen met dat exemplaar.
Belangrijkste verschillen:
- Upgrade van besturingssysteeminstallatiekopieën is een geleidelijk en niet-verstorend proces dat de installatiekopieën van het besturingssysteem voor de hele virtuele-machineschaalset na verloop van tijd bijwerkt, waardoor minimale impact op actieve workloads wordt gegarandeerd.
- Een nieuwe installatiekopie is een meer onmiddellijke en verstorende actie die alleen van invloed is op het geselecteerde VM-exemplaar, waardoor het tijdelijk wordt gestopt en het besturingssysteem opnieuw wordt geïnstalleerd.
Wanneer moet u elke methode gebruiken:
- Gebruik upgrade van besturingssysteeminstallatiekopieën wanneer u de installatiekopieën van het besturingssysteem voor de hele schaalset wilt bijwerken terwijl hoge beschikbaarheid behouden blijft.
- Gebruik Reimage wanneer u problemen met een specifiek VM-exemplaar in de virtuele-machineschaalset wilt oplossen of opnieuw wilt instellen.
Het is essentieel om zorgvuldig te plannen en de juiste methode te kiezen op basis van uw specifieke vereisten om eventuele onderbrekingen van uw toepassingen en services die worden uitgevoerd in een virtuele-machineschaalset te minimaliseren.
Ondersteunde installatiekopieën van het besturingssysteem
Alleen bepaalde installatiekopieën van het besturingssysteemplatform worden momenteel ondersteund. Aangepaste installatiekopieën worden ondersteund als de schaalset gebruikmaakt van aangepaste installatiekopieën via azure Compute Gallery.
De volgende platform-SKU's worden momenteel ondersteund (en er worden regelmatig meer toegevoegd):
Publisher | Aanbieding voor besturingssysteem | Sku |
---|---|---|
Canonical | UbuntuServer | 18.04-LTS |
Canonical | UbuntuServer | 18_04-LTS-Gen2 |
Canonical | 0001-com-ubuntu-server-focal | 20_04-LTS |
Canonical | 0001-com-ubuntu-server-focal | 20_04-LTS-Gen2 |
Canonical | 0001-com-ubuntu-server-jammy | 22_04-LTS |
Canonical | 0001-com-ubuntu-server-jammy | 22_04-LTS-Gen2 |
MicrosoftCblMariner | Cbl-Mariner | cbl-mariner-1 |
MicrosoftCblMariner | Cbl-Mariner | 1-Gen2 |
MicrosoftCblMariner | Cbl-Mariner | cbl-mariner-2 |
MicrosoftCblMariner | Cbl-Mariner | cbl-mariner-2-Gen2 |
MicrosoftSqlServer | Sql2017-ws2019 | enterprise |
MicrosoftWindowsServer | WindowsServer | 2012-R2-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-gensecond |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-gs |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-with-Containers |
MicrosoftWindowsServer | WindowsServer | 2016-Datacenter-with-containers-gs |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-Core |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-Core-with-Containers |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-gensecond |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-gs |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-with-Containers |
MicrosoftWindowsServer | WindowsServer | 2019-Datacenter-with-Containers-gs |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-smalldisk-g2 |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-core |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-core-smalldisk |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-g2 |
MicrosoftWindowsServer | WindowsServer | Datacenter-core-20h2-with-containers-smalldisk-gs |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-azure-edition |
MicrosoftWindowsServer | WindowsServer | 2022-Datacenter-azure-edition-smalldisk |
Mirantis | Windows_with_Mirantis_Container_Runtime_2019 | win_2019_mcr_23_0 |
Mirantis | Windows_with_Mirantis_Container_Runtime_2019 | win_2019_mcr_23_0_gen2 |
Vereisten voor het configureren van automatische upgrade van installatiekopieën van het besturingssysteem
- De versie-eigenschap van de installatiekopieën moet zijn ingesteld op de meest recente versie.
- Moet toepassingsstatustests of Application Health-extensie gebruiken voor niet-Service Fabric-schaalsets. Zie Service Fabric-vereisten voor Service Fabric-vereisten.
- Gebruik Compute-API-versie 2018-10-01 of hoger.
- Zorg ervoor dat externe resources die zijn opgegeven in het schaalsetmodel beschikbaar en bijgewerkt zijn. Voorbeelden zijn SAS-URI voor het opstarten van nettolading in eigenschappen van VM-extensies, nettolading in opslagaccount, verwijzing naar geheimen in het model en meer.
- Voor schaalsets die gebruikmaken van virtuele Windows-machines, vanaf compute-API versie 2019-03-01, moet de eigenschap virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates zijn ingesteld op onwaar in de definitie van het schaalsetmodel. De eigenschap enableAutomaticUpdates schakelt patching in-VM in waarbij 'Windows Update' patches van het besturingssysteem toepast zonder de besturingssysteemschijf te vervangen. Als automatische upgrades van installatiekopieën van het besturingssysteem zijn ingeschakeld op uw schaalset, wat u kunt doen door de automaticOSUpgradePolicy.enableAutomaticOSUpgrade in te stellen op true, is een extra patchproces via Windows Update niet vereist.
Notitie
Nadat een besturingssysteemschijf is vervangen door een nieuwe installatiekopie of upgrade, kunnen de gekoppelde gegevensschijven hun stationsletters opnieuw toewijzen. Als u dezelfde stationsletters voor gekoppelde schijven wilt behouden, wordt u aangeraden een aangepast opstartscript te gebruiken.
Service Fabric-vereisten
Als u Service Fabric gebruikt, moet u ervoor zorgen dat aan de volgende voorwaarden wordt voldaan:
- Het duurzaamheidsniveau van Service Fabric is Silver of Gold. Als De duurzaamheid van Service Fabric Brons is, ondersteunen alleen stateless-only knooppunttypen automatische upgrades van de installatiekopieën van het besturingssysteem).
- De Service Fabric-extensie op de definitie van het schaalsetmodel moet TypeHandlerVersion 1.1 of hoger hebben.
- Het duurzaamheidsniveau moet hetzelfde zijn in het Service Fabric-cluster en de Service Fabric-extensie voor de definitie van het schaalsetmodel.
- Een extra statustest of het gebruik van de toepassingsstatusextensie is niet vereist voor duurzaamheid van Silver of Gold. Voor de duurzaamheid van brons met alleen stateless knooppunttypen is een extra statustest vereist.
- De eigenschap virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates moet zijn ingesteld op false in de definitie van het schaalsetmodel. De eigenschap enableAutomaticUpdates schakelt patching in-VM's in met behulp van 'Windows Update' en wordt niet ondersteund op Service Fabric-schaalsets . Gebruik in plaats daarvan de eigenschap automaticOSUpgradePolicy.enableAutomaticOSUpgrade .
Zorg ervoor dat de duurzaamheidsinstellingen niet overeenkomen in het Service Fabric-cluster en de Service Fabric-extensie, omdat een onjuiste overeenkomst tot upgradefouten leidt. Duurzaamheidsniveaus kunnen worden gewijzigd volgens de richtlijnen die op deze pagina worden beschreven.
Automatische upgrade van installatiekopieën van het besturingssysteem voor aangepaste installatiekopieën
Automatische upgrade van installatiekopieën van het besturingssysteem wordt ondersteund voor aangepaste installatiekopieën die zijn geïmplementeerd via Azure Compute Gallery. Andere aangepaste installatiekopieën worden niet ondersteund voor automatische upgrades van installatiekopieën van het besturingssysteem.
Aanvullende vereisten voor aangepaste installatiekopieën
- Het installatie- en configuratieproces voor automatische upgrade van installatiekopieën van het besturingssysteem is hetzelfde voor alle schaalsets, zoals beschreven in de configuratiesectie van deze pagina.
- Schaalsetexemplaren die zijn geconfigureerd voor automatische upgrades van installatiekopieën van het besturingssysteem, worden geüpgraded naar de versie van de azure Compute Gallery-installatiekopieën wanneer een nieuwe versie van de installatiekopieën wordt gepubliceerd en gerepliceerd naar de regio van die schaalset. Als de nieuwe installatiekopie niet wordt gerepliceerd naar de regio waar de schaal is geïmplementeerd, worden de exemplaren van de schaalset niet bijgewerkt naar de versie. Met replicatie van regionale installatiekopieën kunt u de implementatie van de nieuwe installatiekopieën voor uw schaalsets beheren.
- De nieuwe versie van de installatiekopieën mag niet worden uitgesloten van de versie voor die galerie-installatiekopieën. Installatiekopieën die zijn uitgesloten van de versie van de galerie-installatiekopieën, worden niet geïmplementeerd in de schaalset via automatische upgrade van installatiekopieën van het besturingssysteem.
Notitie
Het kan tot drie uur duren voordat een schaalset de eerste implementatie van de installatiekopieënupgrade activeert nadat de schaalset voor het eerst is geconfigureerd voor automatische besturingssysteemupgrades vanwege bepaalde factoren, zoals Onderhoudsvensters of andere beperkingen. Klanten op de meest recente installatiekopieën krijgen mogelijk geen upgrade totdat een nieuwe installatiekopieën beschikbaar zijn.
Automatische upgrade van installatiekopieën van het besturingssysteem configureren
Als u automatische upgrade van de installatiekopie van het besturingssysteem wilt configureren, moet u ervoor zorgen dat de eigenschap automaticOSUpgradePolicy.enableAutomaticOSUpgrade is ingesteld op waar in de definitie van het schaalsetmodel.
Notitie
De upgradebeleidsmodus en het beleid voor automatische upgrade van het besturingssysteem zijn afzonderlijke instellingen en beheren verschillende aspecten van de schaalset. Wanneer er wijzigingen in de schaalsetsjabloon zijn, bepaalt het upgradebeleid mode
wat er gebeurt met bestaande exemplaren in de schaalset. Het beleid enableAutomaticOSUpgrade
voor automatische besturingssysteemupgrade is echter specifiek voor de installatiekopieën van het besturingssysteem en houdt wijzigingen bij die de uitgever van de installatiekopieën heeft aangebracht en bepaalt wat er gebeurt wanneer de installatiekopieën worden bijgewerkt.
Notitie
Als enableAutomaticOSUpgrade
deze optie is ingesteld op waar, enableAutomaticUpdates
wordt deze automatisch ingesteld op onwaar en kan deze niet worden ingesteld op waar.
REST-API
In het volgende voorbeeld wordt beschreven hoe u automatische upgrades van het besturingssysteem instelt op een schaalsetmodel:
PUT or PATCH on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet?api-version=2021-03-01`
{
"properties": {
"upgradePolicy": {
"automaticOSUpgradePolicy": {
"enableAutomaticOSUpgrade": true
}
}
}
}
Azure PowerShell
Gebruik de cmdlet New-AzVmss om tijdens het inrichten automatische upgrades van installatiekopieën van het besturingssysteem voor uw schaalset te configureren. In het volgende voorbeeld worden automatische upgrades geconfigureerd voor de schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
New-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true
Gebruik de cmdlet Update-AzVmss om automatische upgrades van installatiekopieën van het besturingssysteem voor uw bestaande schaalset te configureren. In het volgende voorbeeld worden automatische upgrades geconfigureerd voor de schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true
Azure CLI 2.0
Gebruik az vmss create om automatische upgrades van de installatiekopieën van het besturingssysteem voor uw schaalset te configureren tijdens het inrichten. Gebruik Azure CLI 2.0.47 of hoger. In het volgende voorbeeld worden automatische upgrades geconfigureerd voor de schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
az vmss create --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling
Gebruik az vmss update om automatische upgrades van installatiekopieën van het besturingssysteem voor uw bestaande schaalset te configureren. Gebruik Azure CLI 2.0.47 of hoger. In het volgende voorbeeld worden automatische upgrades geconfigureerd voor de schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
az vmss update --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling
Notitie
Nadat u automatische upgrades van installatiekopieën van het besturingssysteem voor uw schaalset hebt geconfigureerd, moet u de vm's van de schaalset ook naar het meest recente schaalsetmodel brengen als uw schaalset gebruikmaakt van het upgradebeleid 'Handmatig'.
ARM-sjablonen
In het volgende voorbeeld wordt beschreven hoe u automatische upgrades van besturingssystemen instelt op een schaalsetmodel via Azure Resource Manager-sjablonen (ARM-sjablonen):
"properties": {
"upgradePolicy": {
"mode": "Automatic",
"RollingUpgradePolicy": {
"BatchInstancePercent": 20,
"MaxUnhealthyInstancePercent": 25,
"MaxUnhealthyUpgradedInstancePercent": 25,
"PauseTimeBetweenBatches": "PT0S"
},
"automaticOSUpgradePolicy": {
"enableAutomaticOSUpgrade": true,
"useRollingUpgradePolicy": true,
"disableAutomaticRollback": false
}
},
},
"imagePublisher": {
"type": "string",
"defaultValue": "MicrosoftWindowsServer"
},
"imageOffer": {
"type": "string",
"defaultValue": "WindowsServer"
},
"imageSku": {
"type": "string",
"defaultValue": "2022-datacenter"
},
"imageOSVersion": {
"type": "string",
"defaultValue": "latest"
}
Bicep
In het volgende voorbeeld wordt beschreven hoe u automatische upgrades van het besturingssysteem instelt op een schaalsetmodel via Bicep:
properties: {
overprovision: overProvision
upgradePolicy: {
mode: 'Automatic'
automaticOSUpgradePolicy: {
enableAutomaticOSUpgrade: true
}
}
}
Toepassingsstatusextensie gebruiken
Tijdens een upgrade van het besturingssysteem worden VM-exemplaren in een schaalset één batch tegelijk bijgewerkt. De upgrade moet alleen worden voortgezet als de klanttoepassing in orde is op de bijgewerkte VM-exemplaren. Het is raadzaam dat de toepassing statussignalen levert aan de upgrade-engine van het besturingssysteem van de schaalset. Tijdens het upgraden van het besturingssysteem beschouwt het platform standaard de energiestatus van de VM en de inrichtingsstatus van de extensie om te bepalen of een VM-exemplaar in orde is na een upgrade. Tijdens de upgrade van het besturingssysteem van een VM-exemplaar wordt de besturingssysteemschijf op een VM-exemplaar vervangen door een nieuwe schijf op basis van de nieuwste installatiekopieënversie. Nadat de upgrade van het besturingssysteem is voltooid, worden de geconfigureerde extensies uitgevoerd op deze VM's. De toepassing wordt alleen als in orde beschouwd wanneer alle extensies op het exemplaar zijn ingericht.
Een schaalset kan eventueel worden geconfigureerd met Application Health Probes om het platform nauwkeurige informatie te bieden over de doorlopende status van de toepassing. Toepassingsstatustests zijn aangepaste Load Balancer-tests die worden gebruikt als een statussignaal. De toepassing die wordt uitgevoerd op een VM-exemplaar van een schaalset, kan reageren op externe HTTP- of TCP-aanvragen die aangeven of deze in orde is. Zie voor meer informatie over hoe aangepaste load balancer-tests werken, voor meer informatie over de werking van load balancer-tests. Toepassingsstatustests worden niet ondersteund voor Service Fabric-schaalsets. Voor niet-Service Fabric-schaalsets zijn statustests voor Load Balancer-toepassingen of Application Health-extensie vereist.
Als de schaalset is geconfigureerd voor het gebruik van meerdere plaatsingsgroepen, moeten tests worden gebruikt met behulp van een Standard Load Balancer .
Notitie
Er kan slechts één bron van statuscontrole worden gebruikt voor een virtuele-machineschaalset, een toepassingsstatusextensie of een statustest. Als u beide opties hebt ingeschakeld, moet u er een verwijderen voordat u indelingsservices zoals exemplaarreparaties of automatische besturingssysteemupgrades gebruikt.
Een aangepaste load balancer-test configureren als toepassingsstatustest op een schaalset
Maak als best practice expliciet een load balancer-test voor de status van de schaalset. Hetzelfde eindpunt voor een bestaande HTTP-test of TCP-test kan worden gebruikt, maar een statustest kan een ander gedrag vereisen dan een traditionele load balancer-test. Een traditionele load balancer-test kan bijvoorbeeld beschadigd retourneren als de belasting van het exemplaar te hoog is, maar dat is niet geschikt voor het bepalen van de status van het exemplaar tijdens een automatische upgrade van het besturingssysteem. Configureer de test zodanig dat deze een hoge testsnelheid van minder dan twee minuten heeft.
De load balancer-test kan als volgt worden verwezen in het networkProfile van de schaalset en kan als volgt worden gekoppeld aan een interne of openbare load balancer:
"networkProfile": {
"healthProbe" : {
"id": "[concat(variables('lbId'), '/probes/', variables('sshProbeName'))]"
},
"networkInterfaceConfigurations":
...
}
Notitie
Wanneer u automatische besturingssysteemupgrades gebruikt met Service Fabric, wordt de nieuwe installatiekopieën van het besturingssysteem geïmplementeerd door updatedomein om hoge beschikbaarheid te behouden van de services die worden uitgevoerd in Service Fabric. Als u automatische upgrades van het besturingssysteem in Service Fabric wilt gebruiken, moet uw clusterknooppunttype worden geconfigureerd voor het gebruik van de Silver-duurzaamheidslaag of hoger. Voor de Bronze-duurzaamheidslaag wordt automatische upgrade van installatiekopieën van het besturingssysteem alleen ondersteund voor stateless knooppunttypen. Raadpleeg deze documentatie voor meer informatie over de duurzaamheidskenmerken van Service Fabric-clusters.
Application Health-extensie gebruiken
De extensie Application Health wordt geïmplementeerd in een exemplaar van een virtuele-machineschaalset en rapporteert over de vm-status vanuit het exemplaar van de schaalset. U kunt de extensie configureren om te testen op een toepassingseindpunt en de status van de toepassing op dat exemplaar bij te werken. Deze exemplaarstatus wordt gecontroleerd door Azure om te bepalen of een exemplaar in aanmerking komt voor upgradebewerkingen.
Omdat de extensie de status rapporteert vanuit een VIRTUELE machine, kan de extensie worden gebruikt in situaties waarin externe tests zoals Toepassingsstatustests (die gebruikmaken van aangepaste Azure Load Balancer-tests) niet kunnen worden gebruikt.
Er zijn meerdere manieren om de Application Health-extensie te implementeren in uw schaalsets, zoals beschreven in de voorbeelden in dit artikel.
Notitie
Er kan slechts één bron van statuscontrole worden gebruikt voor een virtuele-machineschaalset, een toepassingsstatusextensie of een statustest. Als u beide opties hebt ingeschakeld, moet u er een verwijderen voordat u indelingsservices zoals exemplaarreparaties of automatische besturingssysteemupgrades gebruikt.
De geschiedenis van automatische upgrades van installatiekopieën van het besturingssysteem ophalen
U kunt de geschiedenis controleren van de meest recente upgrade van het besturingssysteem die op uw schaalset is uitgevoerd met Azure PowerShell, Azure CLI 2.0 of de REST API's. U kunt de geschiedenis ophalen voor de laatste vijf upgradepogingen van het besturingssysteem in de afgelopen twee maanden.
Referenties up-to-date houden
Als uw schaalset referenties gebruikt voor toegang tot externe resources, zoals een VM-extensie die is geconfigureerd voor het gebruik van een SAS-token voor het opslagaccount, moet u ervoor zorgen dat de referenties worden bijgewerkt. Als referenties, inclusief certificaten en tokens, zijn verlopen, mislukt de upgrade en blijft de eerste batch virtuele machines in een mislukte status.
De aanbevolen stappen voor het herstellen van VM's en het opnieuw inschakelen van automatische upgrade van het besturingssysteem als er een fout optreedt bij het verifiëren van resources zijn:
- Genereer het token (of andere referenties) die zijn doorgegeven aan uw extensie(s).
- Zorg ervoor dat alle referenties die vanuit de VM worden gebruikt om met externe entiteiten te communiceren, up-to-date zijn.
- Werk extensies bij in het schaalsetmodel met eventuele nieuwe tokens.
- Implementeer de bijgewerkte schaalset, waarmee alle VM-exemplaren worden bijgewerkt, inclusief de mislukte exemplaren.
REST-API
In het volgende voorbeeld wordt REST API gebruikt om de status van de schaalset met de naam myScaleSet te controleren in de resourcegroep met de naam myResourceGroup:
GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osUpgradeHistory?api-version=2021-03-01`
De GET-aanroep retourneert eigenschappen die vergelijkbaar zijn met de volgende voorbeelduitvoer:
{
"value": [
{
"properties": {
"runningStatus": {
"code": "RollingForward",
"startTime": "2018-07-24T17:46:06.1248429+00:00",
"completedTime": "2018-04-21T12:29:25.0511245+00:00"
},
"progress": {
"successfulInstanceCount": 16,
"failedInstanceCount": 0,
"inProgressInstanceCount": 4,
"pendingInstanceCount": 0
},
"startedBy": "Platform",
"targetImageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "2016-Datacenter",
"version": "2016.127.20180613"
},
"rollbackInfo": {
"successfullyRolledbackInstanceCount": 0,
"failedRolledbackInstanceCount": 0
}
},
"type": "Microsoft.Compute/virtualMachineScaleSets/rollingUpgrades",
"location": "westeurope"
}
]
}
Azure PowerShell
Gebruik de cmdlet Get-AzVmss om de upgradegeschiedenis van het besturingssysteem voor uw schaalset te controleren. In het volgende voorbeeld wordt beschreven hoe u de upgradestatus van het besturingssysteem bekijkt voor een schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory
Azure CLI 2.0
Gebruik az vmss get-os-upgrade-history om de upgradegeschiedenis van het besturingssysteem voor uw schaalset te controleren. Gebruik Azure CLI 2.0.47 of hoger. In het volgende voorbeeld wordt beschreven hoe u de upgradestatus van het besturingssysteem bekijkt voor een schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
az vmss get-os-upgrade-history --resource-group myResourceGroup --name myScaleSet
Hoe kan ik de nieuwste versie van een platform-besturingssysteeminstallatiekopieën downloaden?
U kunt de beschikbare installatiekopieversies ophalen voor ondersteunde SKU's voor automatische besturingssysteemupgrades met behulp van de onderstaande voorbeelden:
REST-API
GET on `/subscriptions/subscription_id/providers/Microsoft.Compute/locations/{location}/publishers/{publisherName}/artifacttypes/vmimage/offers/{offer}/skus/{skus}/versions?api-version=2021-03-01`
Azure PowerShell
Get-AzVmImage -Location "westus" -PublisherName "Canonical" -offer "0001-com-ubuntu-server-jammy" -sku "22_04-lts"
Azure CLI 2.0
az vm image list --location "westus" --publisher "Canonical" --offer "0001-com-ubuntu-server-jammy" --sku "22_04-lts" --all
Upgrades van installatiekopieën van het besturingssysteem handmatig activeren
Als automatische upgrade van installatiekopieën van het besturingssysteem is ingeschakeld voor uw schaalset, hoeft u geen installatiekopieën handmatig bij te werken in uw schaalset. De orchestrator voor het upgraden van het besturingssysteem past automatisch de meest recente versie van de installatiekopieën toe op uw schaalsetexemplaren zonder handmatige tussenkomst.
Voor specifieke gevallen waarin u niet wilt wachten totdat de orchestrator de meest recente installatiekopie toepast, kunt u handmatig een upgrade van een besturingssysteeminstallatiekopie activeren met behulp van de onderstaande voorbeelden.
Notitie
Handmatige trigger van upgrades van installatiekopieën van het besturingssysteem biedt geen mogelijkheden voor automatisch terugdraaien. Als een exemplaar de status na een upgradebewerking niet herstelt, kan de vorige besturingssysteemschijf niet worden hersteld.
REST-API
Gebruik de API-aanroep upgrade van het besturingssysteem starten om een rolling upgrade te starten om alle exemplaren van de virtuele-machineschaalset te verplaatsen naar de meest recente versie van het installatiekopieënbesturingssysteem. Exemplaren waarop de meest recente versie van het besturingssysteem al wordt uitgevoerd, worden niet beïnvloed. In het volgende voorbeeld wordt beschreven hoe u een rolling os-upgrade kunt starten op een schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osRollingUpgrade?api-version=2021-03-01`
Azure PowerShell
Gebruik de cmdlet Start-AzVmssRollingOSUpgrade om de upgradegeschiedenis van het besturingssysteem voor uw schaalset te controleren. In het volgende voorbeeld wordt beschreven hoe u een rolling os-upgrade kunt starten op een schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"
Azure CLI 2.0
Gebruik az vmss rolling-upgrade start om de upgradegeschiedenis van het besturingssysteem voor uw schaalset te controleren. Gebruik Azure CLI 2.0.47 of hoger. In het volgende voorbeeld wordt beschreven hoe u een rolling os-upgrade kunt starten op een schaalset met de naam myScaleSet in de resourcegroep met de naam myResourceGroup:
az vmss rolling-upgrade start --resource-group "myResourceGroup" --name "myScaleSet" --subscription "subscriptionId"
Activiteitenlogboeken gebruiken voor upgrademeldingen en inzichten
Activiteitenlogboek is een abonnementslogboek dat inzicht biedt in gebeurtenissen op abonnementsniveau die zijn opgetreden in Azure. Klanten kunnen:
- Gebeurtenissen bekijken die betrekking hebben op bewerkingen die zijn uitgevoerd op hun resources in De Azure-portal
- Actiegroepen maken om meldingsmethoden zoals e-mail, sms, webhooks of ITSM af te stemmen
- Geschikte waarschuwingen instellen met behulp van verschillende criteria met behulp van portal, ARM-resourcesjabloon, PowerShell of CLI die naar actiegroepen moeten worden verzonden
Klanten ontvangen drie typen meldingen met betrekking tot de bewerking automatische besturingssysteemupgrade:
- Indiening van upgradeaanvraag voor een bepaalde resource
- Resultaat van indieningsaanvraag, samen met eventuele foutdetails
- Resultaat van voltooiing van de upgrade, samen met eventuele foutdetails
Actiegroepen instellen voor waarschuwingen voor activiteitenlogboeken
Een actiegroep is een verzameling meldingsvoorkeuren die zijn gedefinieerd door de eigenaar van een Azure-abonnement. Voor Azure Monitor- en Service Health-waarschuwingen gebruikt u actiegroepen om gebruikers te informeren dat er een waarschuwing is geactiveerd.
Actiegroepen kunnen worden gemaakt en beheerd met behulp van:
- ARM Resource Manager
- Portal
- PowerShell:
- CLI
Klanten kunnen het volgende instellen met behulp van actiegroepen:
- Sms- en/of e-mailmeldingen
- Webhooks : klanten kunnen webhooks koppelen aan hun automation-runbooks en hun actiegroepen configureren om de runbooks te activeren. U kunt een runbook starten vanuit een webhook
- ITSM-verbindingen
Fouten bij automatisch upgraden onderzoeken en oplossen
Het platform kan fouten retourneren op VM's tijdens het uitvoeren van automatische upgrade van installatiekopieën met beleid voor rolling upgrades. De weergave Exemplaar ophalen van een VIRTUELE machine bevat het gedetailleerde foutbericht om een fout te onderzoeken en op te lossen. De Rolling Upgrades - Laatste ophalen kan meer informatie geven over de configuratie en status van de rolling upgrade. De upgradegeschiedenis van het besturingssysteem ophalen bevat informatie over de laatste upgradebewerking van de installatiekopieën in de schaalset. Hieronder vindt u de belangrijkste fouten die kunnen leiden tot rolling upgrades.
RollingUpgradeInProgressWithFailedUpgradedVMs
- Er wordt een fout geactiveerd voor een VM-fout.
- In het gedetailleerde foutbericht wordt vermeld of de implementatie wordt voortgezet/onderbroken op basis van de geconfigureerde drempelwaarde.
MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade
- Er wordt een fout geactiveerd wanneer het percentage bijgewerkte VM's de maximumdrempel overschrijdt die is toegestaan voor beschadigde VM's.
- In het gedetailleerde foutbericht wordt de meest voorkomende fout samengevoegd die bijdraagt aan de beschadigde VM's. Zie MaxUnhealthyUpgradedInstancePercent.
MaxUnhealthyInstancePercentExceededInRollingUpgrade
- Er wordt een fout geactiveerd wanneer het percentage beschadigde VM's de maximumdrempel overschrijdt die is toegestaan voor beschadigde VM's tijdens een upgrade.
- In het gedetailleerde foutbericht wordt het huidige beschadigde percentage en het geconfigureerde toegestane VM-percentage weergegeven. Zie maxUnhealthyInstancePercent.
MaxUnhealthyInstancePercentExceedededBeforeRollingUpgrade
- Er wordt een fout geactiveerd wanneer het percentage beschadigde VM's de maximumdrempel overschrijdt die is toegestaan voor beschadigde VM's voordat er een upgrade wordt uitgevoerd.
- In het gedetailleerde foutbericht wordt het huidige beschadigde percentage en het geconfigureerde toegestane VM-percentage weergegeven. Zie maxUnhealthyInstancePercent.
InternalExecutionError
- Er wordt een fout geactiveerd wanneer een niet-verwerkte, niet-opgemaakte of onverwachte fout optreedt tijdens de uitvoering.
- In het gedetailleerde foutbericht wordt de oorzaak van de fout weergegeven.
RollingUpgradeTimeoutError
- Er wordt een fout geactiveerd wanneer er een time-out optreedt voor het rolling upgradeproces.
- In het gedetailleerde foutbericht wordt de tijdsduur weergegeven waarop een time-out optreedt voor het systeem na een poging om bij te werken.