Automatiska uppgraderingar av OS-avbildningar för Azure Virtual Machine Scale Set
Kommentar
Många av stegen i det här dokumentet gäller för vm-skalningsuppsättningar med enhetlig orkestreringsläge. Vi rekommenderar att du använder flexibel orkestrering för nya arbetsbelastningar. Mer information finns i Orkestreringslägen för VM-skalningsuppsättningar i Azure.
Genom att aktivera automatiska os-avbildningsuppgraderingar i skalningsuppsättningen kan du underlätta uppdateringshanteringen genom att på ett säkert sätt och automatiskt uppgradera OS-disken för alla instanser i skalningsuppsättningen.
Automatisk operativsystemuppgradering har följande egenskaper:
- När den har konfigurerats tillämpas den senaste OS-avbildningen som publicerats av bildutgivare automatiskt på skalningsuppsättningen utan användarintervention.
- Uppgraderar batchar med instanser på ett löpande sätt varje gång en ny avbildning publiceras av utgivaren.
- Integreras med programhälsoavsökningar och Application Health-tillägget.
- Fungerar för alla VM-storlekar och för både Windows- och Linux-avbildningar, inklusive anpassade avbildningar via Azure Compute Gallery.
- Du kan när som helst välja bort automatiska uppgraderingar (OS-uppgraderingar kan också initieras manuellt).
- OS-disken för en virtuell dator ersätts med den nya OS-disken som skapats med den senaste avbildningsversionen. Konfigurerade tillägg och anpassade dataskript körs, medan bevarade datadiskar behålls.
- Tilläggssekvensering stöds.
- Kan aktiveras på en skalningsuppsättning av valfri storlek.
Kommentar
Innan du aktiverar automatiska os-avbildningsuppgraderingar kontrollerar du avsnittet krav i den här dokumentationen.
Hur fungerar automatisk uppgradering av os-avbildning?
En uppgradering fungerar genom att ersätta OS-disken för en virtuell dator med en ny disk som skapats med hjälp av avbildningsversionen. Alla konfigurerade tillägg och anpassade dataskript körs på OS-disken, medan datadiskar behålls. För att minimera programavbrotten sker uppgraderingar i batchar, och högst 20 % av skalningsuppsättningen uppgraderas när som helst.
Du måste integrera en Azure Load Balancer-programhälsoavsökning eller Application Health-tillägget för att spåra programmets hälsotillstånd efter en uppgradering. Detta gör att plattformen kan verifiera den virtuella datorns hälsa för att säkerställa att uppdateringar tillämpas på ett säkert sätt. Vi rekommenderar att du införlivar ett program pulsslag för att verifiera att uppgraderingen lyckades.
Uppdateringar av tillgänglighet först
Tillgänglighetsmodellen för plattformsorkestrerade uppdateringar som beskrivs nedan säkerställer att tillgänglighetskonfigurationer i Azure respekteras på flera tillgänglighetsnivåer.
Mellan regioner:
- En uppdatering flyttas över Hela Azure globalt stegvis för att förhindra distributionsfel i Hela Azure.
- En "fas" kan ha en eller flera regioner och en uppdatering flyttas endast över faser om berättigade virtuella datorer i föregående fas uppdateras korrekt.
- Geo-kopplade regioner uppdateras inte samtidigt och kan inte vara i samma regionala fas.
- En uppdaterings framgång mäts genom att spåra hälsotillståndet för en virtuell dator efter uppdateringen.
Inom en region:
- Virtuella datorer i olika Tillgänglighetszoner uppdateras inte samtidigt med samma uppdatering.
Inom en "uppsättning":
- Alla virtuella datorer i en gemensam skalningsuppsättning uppdateras inte samtidigt.
- Virtuella datorer i en gemensam VM-skalningsuppsättning grupperas i batchar och uppdateras inom gränserna för uppdateringsdomänen enligt beskrivningen nedan.
Processen för plattformsorkestrerade uppdateringar följs för distribution av operativsystemplattformsavbildningsuppgraderingar som stöds varje månad. För anpassade avbildningar via Azure Compute Gallery startas bara en avbildningsuppgradering för en viss Azure-region när den nya avbildningen publiceras och replikeras till regionen för den skalningsuppsättningen.
Uppgradera virtuella datorer i en skalningsuppsättning
Regionen för en skalningsuppsättning blir berättigad att hämta avbildningsuppgraderingar antingen genom den första tillgänglighetsprocessen för plattformsbilder eller replikering av nya anpassade avbildningsversioner för Share Image Gallery. Avbildningsuppgradering tillämpas sedan på en enskild skalningsuppsättning på ett batchindelade sätt enligt följande:
- Innan du påbörjar uppgraderingsprocessen ser orkestratorn till att högst 20 % av instanserna i hela skalningsuppsättningen inte är felfria (av någon anledning).
- Uppgraderingsorkestratorn identifierar batchen med vm-instanser som ska uppgraderas, där en batch har högst 20 % av det totala antalet instanser, med en minsta batchstorlek på en virtuell dator. Det finns inget minsta storlekskrav för skalningsuppsättningar och skalningsuppsättningar med 5 eller färre instanser har 1 virtuell dator per uppgraderingsbatch (minsta batchstorlek).
- OS-disken för varje virtuell dator i den valda uppgraderingsbatchen ersätts med en ny OS-disk som skapats från avbildningen. Alla angivna tillägg och konfigurationer i skalningsuppsättningsmodellen tillämpas på den uppgraderade instansen.
- För skalningsuppsättningar med konfigurerade programhälsoavsökningar eller Application Health-tillägget väntar uppgraderingen upp till 5 minuter innan instansen blir felfri innan nästa batch uppgraderas. Om en instans inte återställer sin hälsa inom 5 minuter efter en uppgradering återställs som standard den tidigare OS-disken för instansen.
- Uppgraderingsorkestratorn spårar också procentandelen instanser som blir felaktiga efter en uppgradering. Uppgraderingen stoppas om mer än 20 % av de uppgraderade instanserna blir felaktiga under uppgraderingsprocessen.
- Ovanstående process fortsätter tills alla instanser i skalningsuppsättningen har uppgraderats.
Skalningsuppsättningens os-uppgraderingsorkestrerare söker efter den övergripande skalningsuppsättningens hälsotillstånd innan du uppgraderar varje batch. När du uppgraderar en batch kan det finnas andra samtidiga planerade eller oplanerade underhållsaktiviteter som kan påverka hälsotillståndet för dina skalningsuppsättningsinstanser. Om mer än 20 % av skalningsuppsättningens instanser blir felaktiga stoppas uppgraderingen av skalningsuppsättningen i slutet av den aktuella batchen.
Om du vill ändra standardinställningarna som är associerade med löpande uppgraderingar läser du Azures princip för löpande uppgradering.
Kommentar
Automatisk os-uppgradering uppgraderar inte referensavbildningens SKU på skalningsuppsättningen. Om du vill ändra SKU:n (till exempel Ubuntu 18.04-LTS till 20.04-LTS) måste du uppdatera skalningsuppsättningsmodellen direkt med önskad bild-Sku. Det går inte att ändra bildutgivaren och erbjudandet för en befintlig skalningsuppsättning.
Uppgradering av os-avbildning jämfört med omimering
Både uppgradering av operativsystemavbildningar och reimage är metoder som används för att uppdatera virtuella datorer i en skalningsuppsättning, men de har olika syften och har distinkta effekter.
Uppgradering av os-avbildning innebär uppdatering av den underliggande operativsystemavbildningen som används för att skapa nya instanser i en skalningsuppsättning. När du utför en uppgradering av os-avbildningen skapar Azure nya vm-instanser med den uppdaterade OS-avbildningen och ersätter gradvis de gamla VM-instanserna i skalningsuppsättningen med de nya. Den här processen utförs vanligtvis stegvis för att säkerställa hög tillgänglighet. Os-avbildningsuppgraderingar är ett icke-störande sätt att tillämpa uppdateringar eller ändringar på det underliggande operativsystemet för de virtuella datorerna i en skalningsuppsättning. Befintliga VM-instanser påverkas inte förrän de ersätts med de nya instanserna.
Att återskapa en virtuell datorinstans i en skalningsuppsättning är en mer omedelbar och störande åtgärd. När du väljer att återskapa en virtuell datorinstans stoppar Azure den valda vm-instansen, utför åtgärden för att återskapa och startar sedan om den virtuella datorn med samma OS-avbildning. Detta installerar effektivt om operativsystemet på den specifika vm-instansen. Omimering används vanligtvis när du behöver felsöka eller återställa en specifik VM-instans på grund av problem med den instansen.
Viktiga skillnader:
- Uppgradering av OS-avbildning är en gradvis och icke-störande process som uppdaterar OS-avbildningen för hela vm-skalningsuppsättningen över tid, vilket säkerställer minimal påverkan på arbetsbelastningar som körs.
- Reimage är en mer omedelbar och störande åtgärd som endast påverkar den valda vm-instansen, stoppar den tillfälligt och installerar om operativsystemet.
När du ska använda varje metod:
- Använd OS Image Upgrade när du vill uppdatera OS-avbildningen för hela skalningsuppsättningen samtidigt som hög tillgänglighet bibehålls.
- Använd Reimage när du behöver felsöka eller återställa en specifik VM-instans i vm-skalningsuppsättningen.
Det är viktigt att planera noggrant och välja lämplig metod baserat på dina specifika krav för att minimera eventuella störningar i dina program och tjänster som körs i en VM-skalningsuppsättning.
Os-avbildningar som stöds
För närvarande stöds endast vissa os-plattformsavbildningar. Anpassade avbildningar stöds om skalningsuppsättningen använder anpassade avbildningar via Azure Compute Gallery.
Följande plattforms-SKU:er stöds för närvarande (och fler läggs till regelbundet):
Publisher | OS-erbjudande | 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 | organisation |
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 |
Krav för att konfigurera automatisk uppgradering av operativsystemavbildningar
- Versionsegenskapen för avbildningen måste vara inställd på senaste.
- Måste använda programhälsoavsökningar eller Application Health-tillägget för skalningsuppsättningar som inte är Service Fabric. Service Fabric-krav finns i Service Fabric-krav.
- Använd Compute API version 2018-10-01 eller senare.
- Se till att externa resurser som anges i skalningsuppsättningsmodellen är tillgängliga och uppdaterade. Exempel är SAS-URI för bootstrapping-nyttolast i egenskaper för VM-tillägg, nyttolast i lagringskonto, referens till hemligheter i modellen med mera.
- För skalningsuppsättningar med virtuella Windows-datorer måste egenskapen virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates anges till false i skalningsuppsättningens modelldefinition. Egenskapen enableAutomaticUpdates möjliggör uppdatering på virtuell dator där "Windows Update" tillämpar operativsystemkorrigeringar utan att ersätta OS-disken. Med automatiska os-avbildningsuppgraderingar aktiverade på din skalningsuppsättning, vilket kan göras genom att ställa in automaticOSUpgradePolicy.enableAutomaticOSUpgrade till true, krävs ingen extra korrigeringsprocess via Windows Update.
- Korrigeringsorkestreringsläget får inte anges till
AutomaticByPlatform
i skalningsuppsättningsmodelldefinitionen. Med automatiska os-avbildningsuppgraderingar aktiverade på din skalningsuppsättning krävs ingen korrigeringsprocess för plattformsorkestrering.
Kommentar
När en OS-disk har ersatts genom omimering eller uppgradering kan de anslutna datadiskarna få sina enhetsbeteckningar omtilldelade. Om du vill behålla samma enhetsbeteckningar för anslutna diskar bör du använda ett anpassat startskript.
Service Fabric-krav
Om du använder Service Fabric kontrollerar du att följande villkor är uppfyllda:
- Service Fabric-hållbarhetsnivån är silver eller guld. Om Service Fabric-hållbarheten är Brons stöder endast tillståndslösa nodtyper automatiska os-avbildningsuppgraderingar).
- Service Fabric-tillägget för skalningsuppsättningsmodelldefinitionen måste ha TypeHandlerVersion 1.1 eller senare.
- Hållbarhetsnivån bör vara densamma i Service Fabric-klustret och Service Fabric-tillägget i skalningsuppsättningsmodelldefinitionen.
- En ytterligare hälsoavsökning eller användning av programmets hälsotillägg krävs inte för silver- eller guldhållbarhet. Brons hållbarhet med stateless-only nodtyper kräver ytterligare en hälsoavsökning.
- Egenskapen virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates måste anges till false i skalningsuppsättningsmodelldefinitionen. Egenskapen enableAutomaticUpdates möjliggör uppdatering på virtuell dator med hjälp av "Windows Update" och stöds inte i Service Fabric-skalningsuppsättningar. Du bör använda egenskapen automaticOSUpgradePolicy.enableAutomaticOSUpgrade i stället.
Kontrollera att hållbarhetsinställningarna inte är matchningsfel i Service Fabric-klustret och Service Fabric-tillägget, eftersom ett matchningsfel resulterar i uppgraderingsfel. Hållbarhetsnivåer kan ändras enligt riktlinjerna som beskrivs på den här sidan.
Automatisk uppgradering av OS-avbildning för anpassade avbildningar
Automatisk uppgradering av os-avbildningar stöds för anpassade avbildningar som distribueras via Azure Compute Gallery. Andra anpassade avbildningar stöds inte för automatiska os-avbildningsuppgraderingar.
Ytterligare krav för anpassade avbildningar
- Konfigurationsprocessen för automatisk uppgradering av os-avbildningar är densamma för alla skalningsuppsättningar som beskrivs i konfigurationsavsnittet på den här sidan.
- Skalningsuppsättningsinstanser som konfigurerats för automatiska os-avbildningsuppgraderingar uppgraderas till versionen av Azure Compute Gallery-avbildningen när en ny version av avbildningen publiceras och replikeras till regionen för skalningsuppsättningen. Om den nya avbildningen inte replikeras till den region där skalan distribueras uppgraderas inte skalningsuppsättningsinstanserna till versionen. Med regional bildreplikering kan du styra distributionen av den nya avbildningen för dina skalningsuppsättningar.
- Den nya avbildningsversionen bör inte undantas från versionen för den galleribilden. Bildversioner som undantas från galleriavbildningens version distribueras inte till skalningsuppsättningen via automatisk uppgradering av operativsystemavbildningen.
Kommentar
Det kan ta upp till 3 timmar innan en skalningsuppsättning utlöser den första distributionen av avbildningsuppgradering efter att skalningsuppsättningen först har konfigurerats för automatiska OS-uppgraderingar på grund av vissa faktorer som underhållsperioder eller andra begränsningar. Kunder på den senaste avbildningen kanske inte får någon uppgradering förrän en ny avbildning är tillgänglig.
Konfigurera automatisk uppgradering av os-avbildning
Om du vill konfigurera automatisk uppgradering av OS-avbildningen kontrollerar du att egenskapen automaticOSUpgradePolicy.enableAutomaticOSUpgrade är inställd på true i skalningsuppsättningsmodelldefinitionen.
Kommentar
Uppgraderingsprincipläge och Automatisk uppgraderingsprincip för operativsystem är separata inställningar och styr olika aspekter av skalningsuppsättningen. När det finns ändringar i skalningsuppsättningsmallen avgör uppgraderingsprincipen mode
vad som händer med befintliga instanser i skalningsuppsättningen. Principen enableAutomaticOSUpgrade
för automatisk uppgradering av operativsystem är dock specifik för OS-avbildningen och spårar ändringar som bildutgivaren har gjort och avgör vad som händer när det finns en uppdatering av avbildningen.
Kommentar
Om enableAutomaticOSUpgrade
är inställt på santenableAutomaticUpdates
, anges automatiskt till false och kan inte anges till sant.
REST-API
I följande exempel beskrivs hur du ställer in automatiska OS-uppgraderingar på en skalningsuppsättningsmodell:
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
Använd cmdleten New-AzVmss för att konfigurera automatiska os-avbildningsuppgraderingar för skalningsuppsättningen under etableringen. I följande exempel konfigureras automatiska uppgraderingar för skalningsuppsättningen med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
New-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true
Använd cmdleten Update-AzVmss för att konfigurera automatiska os-avbildningsuppgraderingar för din befintliga skalningsuppsättning. I följande exempel konfigureras automatiska uppgraderingar för skalningsuppsättningen med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true
Azure CLI 2.0
Använd az vmss create för att konfigurera automatiska os-avbildningsuppgraderingar för din skalningsuppsättning under etableringen. Använd Azure CLI 2.0.47 eller senare. I följande exempel konfigureras automatiska uppgraderingar för skalningsuppsättningen med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
az vmss create --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling
Använd az vmss update för att konfigurera automatiska os-avbildningsuppgraderingar för din befintliga skalningsuppsättning. Använd Azure CLI 2.0.47 eller senare. I följande exempel konfigureras automatiska uppgraderingar för skalningsuppsättningen med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
az vmss update --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling
Kommentar
När du har konfigurerat automatiska os-avbildningsuppgraderingar för skalningsuppsättningen måste du även ta de virtuella skalningsuppsättningsdatorerna till den senaste skalningsuppsättningsmodellen om skalningsuppsättningen använder uppgraderingsprincipen "Manuell".
ARM-mallar
I följande exempel beskrivs hur du ställer in automatiska OS-uppgraderingar på en skalningsuppsättningsmodell via Azure Resource Manager-mallar (ARM-mallar):
"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
I följande exempel beskrivs hur du ställer in automatiska OS-uppgraderingar på en skalningsuppsättningsmodell via Bicep:
properties: {
overprovision: overProvision
upgradePolicy: {
mode: 'Automatic'
automaticOSUpgradePolicy: {
enableAutomaticOSUpgrade: true
}
}
}
Använda programhälsotillägget
Under en os-uppgradering uppgraderas virtuella datorinstanser i en skalningsuppsättning en batch i taget. Uppgraderingen bör endast fortsätta om kundprogrammet är felfritt på de uppgraderade VM-instanserna. Vi rekommenderar att programmet tillhandahåller hälsosignaler till skalningsuppsättningens operativsystemuppgraderingsmotor. Under OS-uppgraderingar tar plattformen som standard hänsyn till vm-energitillstånd och tilläggsetableringstillstånd för att avgöra om en VM-instans är felfri efter en uppgradering. Under OS-uppgraderingen av en virtuell datorinstans ersätts OS-disken på en virtuell datorinstans med en ny disk baserat på den senaste avbildningsversionen. När os-uppgraderingen har slutförts körs de konfigurerade tilläggen på dessa virtuella datorer. Programmet anses bara vara felfritt när alla tillägg på instansen har etablerats.
En skalningsuppsättning kan eventuellt konfigureras med Programhälsoavsökningar för att ge plattformen korrekt information om programmets pågående tillstånd. Programhälsoavsökningar är anpassade lastbalanserare som används som hälsosignal. Programmet som körs på en vm-instans med skalningsuppsättningar kan svara på externa HTTP- eller TCP-begäranden som anger om det är felfritt. Mer information om hur anpassade lastbalanserares avsökningar fungerar finns i Förstå lastbalanserares avsökningar. Programhälsoavsökningar stöds inte för Service Fabric-skalningsuppsättningar. Icke-Service Fabric-skalningsuppsättningar kräver antingen Load Balancer-programhälsoavsökningar eller Application Health-tillägget.
Om skalningsuppsättningen är konfigurerad för att använda flera placeringsgrupper måste avsökningar med en Standard Load Balancer användas.
Kommentar
Endast en hälsoövervakningskälla kan användas för en VM-skalningsuppsättning, antingen ett programhälsotillägg eller en hälsoavsökning. Om du har båda alternativen aktiverade måste du ta bort ett innan du använder orkestreringstjänster som Instansreparationer eller Automatiska OS-uppgraderingar.
Konfigurera en anpassad lastbalanserareavsökning som programhälsoavsökning i en skalningsuppsättning
Vi rekommenderar att du skapar en lastbalanserares avsökning explicit för skalningsuppsättningens hälsa. Samma slutpunkt för en befintlig HTTP-avsökning eller TCP-avsökning kan användas, men en hälsoavsökning kan kräva ett annat beteende än en traditionell lastbalanserare. En traditionell lastbalanserareavsökning kan till exempel returnera fel om belastningen på instansen är för hög, men det skulle inte vara lämpligt för att fastställa instanshälsan under en automatisk os-uppgradering. Konfigurera avsökningen så att den har en hög avsökningshastighet på mindre än två minuter.
Lastbalanserarens avsökning kan refereras till i networkProfile för skalningsuppsättningen och kan associeras med antingen en intern eller offentlig lastbalanserare enligt följande:
"networkProfile": {
"healthProbe" : {
"id": "[concat(variables('lbId'), '/probes/', variables('sshProbeName'))]"
},
"networkInterfaceConfigurations":
...
}
Kommentar
När du använder automatiska OS-uppgraderingar med Service Fabric distribueras den nya OS-avbildningen uppdateringsdomänen efter uppdateringsdomän för att upprätthålla hög tillgänglighet för de tjänster som körs i Service Fabric. Om du vill använda automatiska OS-uppgraderingar i Service Fabric måste klusternodtypen konfigureras för att använda silverhållbarhetsnivån eller högre. För bronshållbarhetsnivå stöds automatisk uppgradering av os-avbildningar endast för tillståndslösa nodtyper. Mer information om hållbarhetsegenskaperna för Service Fabric-kluster finns i den här dokumentationen.
Använda application health-tillägget
Application Health-tillägget distribueras i en vm-skalningsuppsättningsinstans och rapporterar om den virtuella datorns hälsotillstånd inifrån skalningsuppsättningsinstansen. Du kan konfigurera tillägget så att det avsöker en programslutpunkt och uppdaterar programmets status på den instansen. Den här instansstatusen kontrolleras av Azure för att avgöra om en instans är berättigad till uppgraderingsåtgärder.
Eftersom tillägget rapporterar hälsa inifrån en virtuell dator kan tillägget användas i situationer där externa avsökningar som Application Health Probes (som använder anpassade Azure Load Balancer-avsökningar) inte kan användas.
Det finns flera sätt att distribuera Application Health-tillägget till dina skalningsuppsättningar enligt beskrivningen i exemplen i den här artikeln.
Kommentar
Endast en hälsoövervakningskälla kan användas för en VM-skalningsuppsättning, antingen ett programhälsotillägg eller en hälsoavsökning. Om du har båda alternativen aktiverade måste du ta bort ett innan du använder orkestreringstjänster som Instansreparationer eller Automatiska OS-uppgraderingar.
Hämta historiken för automatiska os-avbildningsuppgraderingar
Du kan kontrollera historiken för den senaste os-uppgraderingen som utförts på din skalningsuppsättning med Azure PowerShell, Azure CLI 2.0 eller REST-API:erna. Du kan hämta historik för de senaste fem os-uppgraderingsförsöken under de senaste två månaderna.
Håll autentiseringsuppgifterna uppdaterade
Om skalningsuppsättningen använder autentiseringsuppgifter för att komma åt externa resurser, till exempel ett VM-tillägg som konfigurerats för att använda en SAS-token för lagringskontot, kontrollerar du att autentiseringsuppgifterna uppdateras. Om några autentiseringsuppgifter, inklusive certifikat och token, har upphört att gälla misslyckas uppgraderingen och den första batchen med virtuella datorer lämnas i ett misslyckat tillstånd.
De rekommenderade stegen för att återställa virtuella datorer och återaktivera automatisk os-uppgradering om det uppstår ett resursautentiseringsfel är:
- Återskapa token (eller andra autentiseringsuppgifter) som skickas till dina tillägg.
- Se till att alla autentiseringsuppgifter som används inifrån den virtuella datorn för att kommunicera med externa entiteter är uppdaterade.
- Uppdatera tillägg i skalningsuppsättningsmodellen med nya token.
- Distribuera den uppdaterade skalningsuppsättningen, som uppdaterar alla vm-instanser, inklusive de misslyckade.
REST-API
I följande exempel används REST API för att kontrollera statusen för skalningsuppsättningen med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osUpgradeHistory?api-version=2021-03-01`
GET-anropet returnerar egenskaper som liknar följande exempelutdata:
{
"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
Använd cmdleten Get-AzVmss för att kontrollera historiken för operativsystemuppgradering för din skalningsuppsättning. I följande exempel beskrivs hur du granskar statusen för operativsystemuppgradering för en skalningsuppsättning med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory
Azure CLI 2.0
Använd az vmss get-os-upgrade-history för att kontrollera historiken för operativsystemuppgradering för din skalningsuppsättning. Använd Azure CLI 2.0.47 eller senare. I följande exempel beskrivs hur du granskar statusen för operativsystemuppgradering för en skalningsuppsättning med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
az vmss get-os-upgrade-history --resource-group myResourceGroup --name myScaleSet
Hur hämtar jag den senaste versionen av en plattforms-OS-avbildning?
Du kan hämta tillgängliga avbildningsversioner för automatisk operativsystemuppgradering som stöds av SKU:er med hjälp av exemplen nedan:
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
Utlösa os-avbildningsuppgraderingar manuellt
När automatisk uppgradering av os-avbildningen är aktiverad i skalningsuppsättningen behöver du inte utlösa avbildningsuppdateringar manuellt på skalningsuppsättningen. Os-uppgraderingsorkestratorn tillämpar automatiskt den senaste tillgängliga avbildningsversionen på dina skalningsuppsättningsinstanser utan manuella åtgärder.
För specifika fall där du inte vill vänta tills orkestratorn tillämpar den senaste avbildningen kan du utlösa en uppgradering av os-avbildningen manuellt med hjälp av exemplen nedan.
Kommentar
Manuell utlösare av os-avbildningsuppgraderingar ger inte automatiska återställningsfunktioner. Om en instans inte återställer sin hälsa efter en uppgraderingsåtgärd kan den tidigare OS-disken inte återställas.
REST-API
Använd API-anropet Starta OS-uppgradering för att starta en löpande uppgradering för att flytta alla vm-skalningsuppsättningsinstanser till den senaste tillgängliga versionen av avbildningsoperativsystemet. Instanser som redan kör den senaste tillgängliga operativsystemversionen påverkas inte. I följande exempel beskrivs hur du kan starta en löpande os-uppgradering på en skalningsuppsättning med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osRollingUpgrade?api-version=2021-03-01`
Azure PowerShell
Använd cmdleten Start-AzVmssRollingOSUpgrade för att kontrollera historiken för operativsystemuppgradering för din skalningsuppsättning. I följande exempel beskrivs hur du kan starta en löpande os-uppgradering på en skalningsuppsättning med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"
Azure CLI 2.0
Använd az vmss rolling-upgrade start för att kontrollera historiken för operativsystemuppgradering för din skalningsuppsättning. Använd Azure CLI 2.0.47 eller senare. I följande exempel beskrivs hur du kan starta en löpande os-uppgradering på en skalningsuppsättning med namnet myScaleSet i resursgruppen med namnet myResourceGroup:
az vmss rolling-upgrade start --resource-group "myResourceGroup" --name "myScaleSet" --subscription "subscriptionId"
Utnyttja aktivitetsloggar för uppgraderingsmeddelanden och insikter
Aktivitetslogg är en prenumerationslogg som ger insikter om händelser på prenumerationsnivå som har inträffat i Azure. Kunder kan:
- Se händelser som rör åtgärder som utförs på deras resurser i Azure Portal
- Skapa åtgärdsgrupper för att finjustera aviseringsmetoder som e-post, sms, webhooks eller ITSM
- Konfigurera lämpliga aviseringar med olika kriterier med hjälp av portalen, ARM-resursmallen, PowerShell eller CLI som ska skickas till åtgärdsgrupper
Kunder får tre typer av meddelanden som rör automatisk operativsystemuppgradering:
- Inlämning av uppgraderingsbegäran för en viss resurs
- Resultat av begäran om insändning tillsammans med eventuell felinformation
- Resultat av uppgraderingens slutförande tillsammans med eventuell felinformation
Konfigurera åtgärdsgrupper för aktivitetsloggaviseringar
En åtgärdsgrupp är en samling aviseringsinställningar som definierats av ägaren av en Azure-prenumeration. Azure Monitor- och Service Health-aviseringar använder åtgärdsgrupper för att meddela användarna att en avisering har utlösts.
Åtgärdsgrupper kan skapas och hanteras med hjälp av:
- ARM Resource Manager
- Portal
- PowerShell:
- CLI
Kunder kan konfigurera följande med hjälp av åtgärdsgrupper:
- SMS- och/eller e-postaviseringar
- Webhooks – Kunder kan koppla webhooks till sina automation-runbooks och konfigurera sina åtgärdsgrupper för att utlösa runbooks. Du kan starta en runbook från en webhook
- ITSM-anslutningar
Undersöka och lösa fel vid automatisk uppgradering
Plattformen kan returnera fel på virtuella datorer när du utför automatisk avbildningsuppgradering med löpande uppgraderingsprincip. Hämta instansvy för en virtuell dator innehåller det detaljerade felmeddelandet för att undersöka och lösa ett fel. De löpande uppgraderingarna – Hämta senaste kan ge mer information om konfiguration och status för löpande uppgradering. Uppgraderingshistoriken för Hämta operativsystem innehåller information om den senaste avbildningsuppgraderingsåtgärden i skalningsuppsättningen. Nedan visas de översta felen som kan resultera i löpande uppgraderingar.
RollingUpgradeInProgressWithFailedUpgradedVMs
- Felet utlöses för ett vm-fel.
- Det detaljerade felmeddelandet anger om distributionen fortsätter/pausar baserat på det konfigurerade tröskelvärdet.
MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade
- Felet utlöses när procentandelen uppgraderade virtuella datorer överskrider det högsta tröskelvärde som tillåts för virtuella datorer med feltillstånd.
- Det detaljerade felmeddelandet aggregerar det vanligaste felet som bidrar till de virtuella datorer som inte är felfria. Se MaxUnhealthyUpgradedInstancePercent.
MaxUnhealthyInstancePercentExceededInRollingUpgrade
- Felet utlöses när procentandelen felaktiga virtuella datorer överskrider det högsta tröskelvärde som tillåts för virtuella datorer med feltillstånd under en uppgradering.
- Det detaljerade felmeddelandet visar den aktuella felprocenten och den konfigurerade tillåtna feltillståndsprocenten för virtuella datorer. Se maxUnhealthyInstancePercent.
MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade
- Felet utlöses när procentandelen felaktiga virtuella datorer överskrider det högsta tröskelvärde som tillåts för virtuella datorer som inte är felfria innan en uppgradering sker.
- Det detaljerade felmeddelandet visar den aktuella felprocenten och den konfigurerade tillåtna feltillståndsprocenten för virtuella datorer. Se maxUnhealthyInstancePercent.
InternalExecutionError
- Felet utlöses när ett ohanterat, oformaterat eller oväntat inträffar under körningen.
- Det detaljerade felmeddelandet visar orsaken till felet.
RollingUpgradeTimeoutError
- Felet utlöses när den löpande uppgraderingsprocessen har överskridit tidsgränsen.
- Det detaljerade felmeddelandet visar hur lång tid systemet överskrider tidsgränsen efter att ha försökt uppdatera.