Aggiornamenti automatici dell'immagine del sistema operativo con i Set di scalabilità di macchine virtuali di Azure

L'abilitazione degli aggiornamenti automatici per l'immagine del sistema operativo nel set di scalabilità è utile per facilitare la gestione degli aggiornamenti, grazie alla possibilità di aggiornare in modo sicuro e automatico il disco del sistema operativo per tutte le istanze nel set di scalabilità.

L'aggiornamento automatico del sistema operativo presenta le caratteristiche seguenti:

• Una volta configurato, l'immagine del sistema operativo più recente pubblicata dagli editori di immagini viene applicata automaticamente al set di scalabilità senza l'intervento dell'utente.
• Aggiorna batch di istanze in sequenza ogni volta che viene pubblicata una nuova immagine dall'editore.
• Si integra con i probe di integrità dell'applicazione e con l'estensione Integrità applicazione.
• È compatibile con tutte le dimensioni delle VM e per le immagini sia Windows che Linux, incluse le immagini personalizzate tramite Raccolta di calcolo di Azure.
• È possibile rifiutare esplicitamente gli aggiornamenti automatici in qualsiasi momento (gli aggiornamenti del sistema operativo possono anche essere avviati manualmente).
• Il disco del sistema operativo di una macchina virtuale viene sostituito con il nuovo disco del sistema operativo creato con una versione più recente dell'immagine. Le estensioni configurate e gli script di dati personalizzati vengono eseguiti, mentre i dischi dati persistenti vengono mantenuti.
• È supportata la sequenziazione delle estensioni.
• Può essere abilitato in un set di scalabilità di qualsiasi dimensione.

Come funziona l'aggiornamento dell'immagine del sistema operativo?

Un aggiornamento consiste nella sostituzione del disco del sistema operativo di una macchina virtuale con un nuovo disco creato usando la versione dell'immagine. Le estensioni configurate e gli script di dati personalizzati vengono eseguiti nel disco del sistema operativo, mentre i dischi dati vengono mantenuti. Per ridurre al minimo il tempo di inattività delle applicazioni, gli aggiornamenti vengono eseguiti in batch, aggiornando ogni volta non più del 20% del set di scalabilità.

È necessario integrare un probe di integrità dell'applicazione di Azure Load Balancer o un'estensione Integrità dell'applicazione per tenere traccia dell'integrità dell'applicazione dopo un aggiornamento. Ciò consente alla piattaforma di convalidare l'integrità della macchina virtuale per garantire che gli aggiornamenti vengano applicati in modo sicuro. È consigliabile incorporare un heartbeat dell'applicazione per convalidare l'esito positivo dell'aggiornamento.

Aggiornamenti basati sulla disponibilità

Il modello basato sulla disponibilità per gli aggiornamenti orchestrati della piattaforma descritto qui di seguito garantisce che le configurazioni di disponibilità in Azure siano rispettate in più livelli di disponibilità.

Tra aree:

• Un aggiornamento si sposterà in Azure a livello globale in modo graduale per evitare errori di distribuzione a livello di Azure.
• Una "fase" può includere una o più aree e un aggiornamento si sposta da una fase all'altra solo se le macchine virtuali idonee nella fase precedente sono state aggiornate correttamente.
• Le aree geografiche abbinate non verranno aggiornate contemporaneamente e non possono trovarsi nella stessa fase a livello di area.
• L'esito positivo di un aggiornamento viene misurato monitorando l'integrità di una macchina virtuale dopo l'aggiornamento.

All'interno di un'area:

• Le VM in zone di disponibilità differenti non vengono aggiornate simultaneamente con lo stesso aggiornamento.

All'interno di un "set":

• Tutte le VM in un set di scalabilità comune non vengono aggiornate contemporaneamente.
• Le VM in un Set di scalabilità di VM comuni vengono raggruppate in batch e aggiornate entro i limiti del dominio di aggiornamento come descritto qui di seguito.

Il processo di aggiornamento orchestrato della piattaforma viene seguito per l'implementazione degli aggiornamenti delle immagini della piattaforma del sistema operativo supportati ogni mese. Per le immagini personalizzate tramite Raccolta di calcolo di Azure, viene avviata un aggiornamento dell'immagine solo per una determinata area di Azure quando la nuova immagine viene pubblicata e replicata nell'area del set di scalabilità.

Aggiornamento di VM in un set di scalabilità

L'area di un set di scalabilità diventa idonea per ottenere gli aggiornamenti delle immagini tramite il processo di disponibilità per le immagini della piattaforma o la replica di nuove versioni di immagini personalizzate per La raccolta immagini di condivisione. L'aggiornamento dell'immagine viene quindi applicato a un singolo set di scalabilità in batch come indicato di seguito:

1. Prima di iniziare il processo di aggiornamento, l'agente di orchestrazione verifica che il numero di istanze non integre (per qualsiasi motivo) non superi il 20% nell'intero set di scalabilità.
2. L'agente di orchestrazione dell'aggiornamento identifica il batch di istanze di VM da aggiornare, con un batch con un massimo del 20% del numero totale di istanze, soggetto a una dimensione minima del batch di una VM. Non sono previsti requisiti minimi per le dimensioni del set di scalabilità e i set di scalabilità con 5 o meno istanze avranno una VM per ogni batch di aggiornamento (dimensioni minime del batch).
3. Il disco del sistema operativo di ogni VM nel batch di aggiornamento selezionato viene sostituito con un nuovo disco del sistema operativo creato dall'immagine. Tutte le estensioni e le configurazioni specificate nel modello del set di scalabilità vengono applicate all'istanza aggiornata.
4. Per i set di scalabilità in cui sono configurati probe di integrità dell'applicazione o l'estensione Integrità applicazione, l'aggiornamento attende fino a 5 minuti che l'istanza risulti integra prima di procedere con l'aggiornamento del batch successivo. Se un'istanza di non recupera l'integrità in 5 minuti dopo un aggiornamento, per impostazione predefinita viene ripristinato il disco del sistema operativo precedente per l'istanza.
5. L'agente di orchestrazione dell'aggiornamento tiene anche traccia della percentuale di istanze che diventano non integre dopo un aggiornamento. L'aggiornamento verrà interrotto se più del 20% delle istanze aggiornate diventa non integro durante il processo di aggiornamento.
6. Questo processo continua fino a completare l'aggiornamento di tutte le istanze nel set di scalabilità.

L'agente di orchestrazione dell'aggiornamento del sistema operativo del set di scalabilità verifica l'integrità complessiva del set di scalabilità prima di aggiornare ogni batch. Durante l'aggiornamento di un batch, possono essere in corso altre attività di manutenzione pianificate o non pianificate che potrebbero influire sull'integrità delle istanze del set di scalabilità. In questi casi, se più del 20% delle istanze del set di scalabilità diventa non integro, l'aggiornamento del set di scalabilità si interrompe alla fine del batch corrente.

Per modificare le impostazioni predefinite associate agli aggiornamenti in sequenza, vedere Criteri di aggiornamento in sequenza di Azure.

Aggiornamento dell'immagine del sistema operativo e ricreazione dell'immagine

Sia Aggiornamento dell'immagine del sistema operativo che Ricreare immagine sono metodi usati per aggiornare le VM all'interno di un set di scalabilità, ma servono scopi differenti e hanno effetti distinti.

L'aggiornamento dell'immagine del sistema operativo comporta l'aggiornamento dell'immagine del sistema operativo sottostante usata per creare nuove istanze in un set di scalabilità. Quando si esegue un aggiornamento dell'immagine del sistema operativo, Azure creerà nuove istanze di VM con l'immagine aggiornata del sistema operativo e sostituirà gradualmente le istanze precedenti della VM nel set di scalabilità con quelle nuove. Questo processo viene in genere eseguito in fasi per garantire la disponibilità elevata. Gli aggiornamenti delle immagini del sistema operativo sono un modo non problematico per applicare aggiornamenti o modifiche al sistema operativo sottostante delle VM in un set di scalabilità. Le istanze di macchina virtuale esistenti non vengono interessate fino a quando non vengono sostituite con le nuove istanze.

La ricreazione di un'istanza di VM in un set di scalabilità è un'azione più immediata e di interruzione. Quando si sceglie di creare nuovamente l'immagine di un'istanza di macchina virtuale, Azure arresterà l'istanza di macchina virtuale selezionata, eseguirà l'operazione di ricreazione dell'immagine e quindi riavvia la macchina virtuale usando la stessa immagine del sistema operativo. In questo modo il sistema operativo viene reinstallato in modo efficace in tale istanza di VM specifica. Il reimaging viene in genere usato quando è necessario risolvere o reimpostare un'istanza di VM specifica a causa di problemi con tale istanza.

Differenze principali:

• L'aggiornamento dell'immagine del sistema operativo è un processo graduale e senza interruzioni che aggiorna l'immagine del sistema operativo per l'intero set di scalabilità di macchine virtuali nel tempo, garantendo un impatto minimo sui carichi di lavoro in esecuzione.
• La ricreazione dell'immagine è un'azione più immediata e di interruzione che influisce solo sull'istanza di macchina virtuale selezionata, arrestandola temporaneamente e reinstallando il sistema operativo.

Quando usare i singoli metodi:

• Usare l'aggiornamento delle immagini del sistema operativo quando si desidera aggiornare l'immagine del sistema operativo per l'intero set di scalabilità mantenendo la disponibilità elevata.
• Usare Reimage quando è necessario risolvere i problemi o reimpostare un'istanza di VM specifica all'interno del Set di scalabilità di macchine virtuali.

È essenziale pianificare attentamente e scegliere il metodo appropriato in base ai requisiti specifici per ridurre al minimo le interruzioni delle applicazioni e dei servizi in esecuzione in un Set di scalabilità di macchine virtuali.

Immagini del sistema operativo supportate

Attualmente sono supportate solo alcune immagini della piattaforma del sistema operativo. Le immagini personalizzate sono supportate se il set di scalabilità usa immagini personalizzate tramite Raccolta di calcolo di Azure.

Sono attualmente supportati gli SKU piattaforma seguenti (e ne vengono aggiunti altri periodicamente):

Publisher	Offerta sistema operativo	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	grande azienda
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

Requisiti per la configurazione dell'aggiornamento automatico dell'immagine del sistema operativo

• La proprietà version dell'immagine deve essere impostata su latest.
• È necessario usare i probe di integrità dell'applicazione o l'estensione Integrità applicazione per i set di scalabilità non di Service Fabric. Per i requisiti di Service Fabric, vedere Requisiti di Service Fabric.
• Usare l'API di calcolo versione 2018-10-01 o successiva.
• Assicurarsi che le risorse esterne specificate nel modello del set di scalabilità siano disponibili e aggiornate. Ad esempio, URI della firma di accesso condiviso per il payload di bootstrap nelle proprietà di estensione della macchina virtuale, payload nell'account di archiviazione, riferimento ai segreti nel modello e altro.
• Per i set di scalabilità che usano macchine virtuali Windows, a partire dalla versione 2019-03-01, la proprietà virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates deve essere impostata su false nella definizione del modello del set di scalabilità. La proprietà enableAutomaticUpdates abilita l'applicazione di patch in-VM in cui "Windows Update" applica le patch del sistema operativo senza sostituire il disco del sistema operativo. Con gli aggiornamenti automatici delle immagini del sistema operativo abilitati nel set di scalabilità, che può essere eseguito impostando automaticOSUpgradePolicy.enableAutomaticOSUpgrade su true, non è necessario un processo di applicazione di patch aggiuntivo tramite Windows Update.
• La modalità di orchestrazione patch non deve essere impostata su AutomaticByPlatform nella definizione del modello del set di scalabilità. Con gli aggiornamenti automatici delle immagini del sistema operativo abilitati nel set di scalabilità, non è necessario un processo di applicazione di patch per l'orchestrazione della piattaforma.

Requisiti di Service Fabric

Se si usa Service Fabric, verificare che siano soddisfatte le condizioni seguenti:

• Il livello di durabilità di Service Fabric è Silver o Gold. Se la durabilità di Service Fabric è Bronze, solo i tipi di nodo senza stato supportano gli aggiornamenti automatici delle immagini del sistema operativo.
• L'estensione Service Fabric nella definizione del modello del set di scalabilità deve avere TypeHandlerVersion 1.1 o versione successiva.
• Il livello di durabilità deve corrispondere al cluster di Service Fabric e all'estensione Service Fabric nella definizione del modello del set di scalabilità.
• Un probe di integrità aggiuntivo o l'uso dell'estensione per l'integrità dell'applicazione non è necessario per la durabilità Silver o Gold. La durabilità bronze con tipi di nodo solo senza stato richiede un probe di integrità aggiuntivo.
• La proprietà virtualMachineProfile.osProfile.windowsConfiguration.enableAutomaticUpdates deve essere impostata su false nella definizione del modello del set di scalabilità. La proprietà enableAutomaticUpdates abilita l'applicazione di patch in-VM tramite "Windows Update" e non è supportata nei set di scalabilità di Service Fabric. È consigliabile usare la proprietà automaticOSUpgradePolicy.enableAutomaticOSUpgrade.

Assicurarsi che le impostazioni di durabilità non siano corrispondenti nel cluster di Service Fabric e nell'estensione Service Fabric, perché una mancata corrispondenza genererà errori di aggiornamento. I livelli di durabilità possono essere modificati in base alle linee guida descritte in questa pagina.

Aggiornamento automatico dell'immagine del sistema operativo per immagini personalizzate

L'aggiornamento automatico delle immagini del sistema operativo è supportato per le immagini personalizzate distribuite tramite Raccolta di calcolo di Azure. Altre immagini personalizzate non sono supportate per gli aggiornamenti automatici delle immagini del sistema operativo.

Requisiti aggiuntivi per le immagini personalizzate

• Il processo di installazione e configurazione per l'aggiornamento automatico dell'immagine del sistema operativo è lo stesso per tutti i set di scalabilità, come descritto nella sezione di configurazione di questa pagina.
• Le istanze dei set di scalabilità configurate per gli aggiornamenti automatici delle immagini del sistema operativo verranno aggiornate alla versione dell'immagine della Raccolta di calcolo di Azure quando viene pubblicata una nuova versione dell'immagine e replicata nell'area del set di scalabilità. Se la nuova immagine non viene replicata nell'area in cui viene distribuita la scalabilità, le istanze del set di scalabilità non verranno aggiornate alla versione. La replica di immagini a livello di area consente di controllare l'implementazione della nuova immagine per i set di scalabilità.
• La nuova versione dell'immagine non deve essere esclusa dalla versione per l'immagine della raccolta. Le versioni delle immagini escluse dalla versione dell'immagine della raccolta non vengono implementate nel set di scalabilità tramite l'aggiornamento automatico dell'immagine del sistema operativo.

Configurare l'aggiornamento automatico dell'immagine del sistema operativo

Per configurare l'aggiornamento automatico dell'immagine del sistema operativo, verificare che nella definizione del modello del set di scalabilità la proprietà automaticOSUpgradePolicy.enableAutomaticOSUpgrade sia impostata su true.

REST API

L'esempio seguente descrive come impostare gli aggiornamenti automatici del sistema operativo in un modello del set di scalabilità:

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

Usare il cmdlet New-AzVmss per configurare gli aggiornamenti automatici delle immagini del sistema operativo per il set di scalabilità durante il provisioning. Nell'esempio seguente vengono configurati gli aggiornamenti automatici per il set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

New-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true

Usare il cmdlet Update-AzVmss per configurare gli aggiornamenti automatici delle immagini del sistema operativo per il set di scalabilità esistente. Nell'esempio seguente vengono configurati gli aggiornamenti automatici per il set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -AutomaticOSUpgrade $true

Interfaccia della riga di comando di Azure 2.0

Usare az vmss create per configurare gli aggiornamenti automatici delle immagini del sistema operativo per il set di scalabilità durante il provisioning. Usare l'interfaccia della riga di comando di Azure versione 2.0.47 o successiva. Nell'esempio seguente vengono configurati gli aggiornamenti automatici per il set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

az vmss create --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

Usare az vmss update per configurare gli aggiornamenti automatici delle immagini del sistema operativo per il set di scalabilità esistente. Usare l'interfaccia della riga di comando di Azure versione 2.0.47 o successiva. Nell'esempio seguente vengono configurati gli aggiornamenti automatici per il set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

az vmss update --name myScaleSet --resource-group myResourceGroup --enable-auto-os-upgrade true --upgrade-policy-mode Rolling

Modelli di Gestione risorse di Azure

L'esempio seguente descrive come impostare gli aggiornamenti automatici del sistema operativo in un modello di set di scalabilità tramite i modelli di Azure Resource Manager (modelli di ARM):

"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

L'esempio seguente descrive come impostare gli aggiornamenti automatici del sistema operativo in un modello del set di scalabilità tramite Bicep:

properties: {
    overprovision: overProvision
    upgradePolicy: {
      mode: 'Automatic'
      automaticOSUpgradePolicy: {
        enableAutomaticOSUpgrade: true
      }
    }
}

Uso dell'estensione Integrità applicazione

Durante un aggiornamento del sistema operativo, le istanze di macchina virtuale in un set di scalabilità vengono aggiornate un batch alla volta. L'aggiornamento deve continuare solo se l'applicazione del cliente è integra nelle istanze di macchina virtuale aggiornate. È consigliabile che l'applicazione fornisca segnali di integrità al motore di aggiornamento del sistema operativo del set di scalabilità. Per impostazione predefinita, durante gli aggiornamenti del sistema operativo la piattaforma prende in considerazione lo stato di alimentazione della macchina virtuale e lo stato di provisioning dell'estensione per determinare se un'istanza di macchina virtuale è integra dopo un aggiornamento. Durante l'aggiornamento del sistema operativo di un'istanza di macchina virtuale, il disco del sistema operativo in un'istanza di macchina virtuale viene sostituito con un nuovo disco in base alla versione più recente dell'immagine. Una volta completato l'aggiornamento del sistema operativo, le estensioni configurate vengono eseguite in queste macchine virtuali. L'applicazione viene considerata integra solo dopo che è stato completato correttamente il provisioning di tutte le estensioni nell'istanza.

Un set di scalabilità può facoltativamente essere configurato con probe di integrità dell'applicazione per fornire alla piattaforma informazioni accurate sullo stato dell'applicazione. I probe di integrità delle applicazioni sono probe del servizio di bilanciamento del carico personalizzati usati come un segnale di integrità. L'applicazione in esecuzione in un'istanza di macchina virtuale del set di scalabilità può rispondere a richieste HTTP o TCP esterne per indicare se è integra. Per altre informazioni sul funzionamento dei probe di bilanciamento del carico personalizzati, vedere Informazioni sui probe di bilanciamento del carico. I probe di integrità dell'applicazione non sono supportati per i set di scalabilità di Service Fabric. Per i set di scalabilità non di Service Fabric sono richiesti probe di integrità dell'applicazione Load Balancer oppure l'estensione Integrità applicazione.

Se il set di scalabilità è configurato per l'uso di più gruppi di posizionamento, è necessario usare probe con un servizio di bilanciamento del carico standard.

Configurazione di un probe di bilanciamento del carico personalizzato come probe di integrità dell'applicazione in un set di scalabilità

Come procedura consigliata, creare un probe di bilanciamento del carico in modo esplicito per l'integrità del set di scalabilità. Può essere usato lo stesso endpoint per un probe HTTP o TCP esistente, ma un probe di integrità può richiedere un comportamento diverso da un probe di bilanciamento del carico tradizionale. Ad esempio, un probe di bilanciamento del carico tradizionale può restituire uno stato non integro se il carico sull'istanza è troppo elevato, mentre questo potrebbe non essere appropriato per determinare l'integrità dell'istanza durante un aggiornamento automatico del sistema operativo. Configurare il probe con un tasso di probing elevato, inferiore a due minuti.

È possibile fare riferimento al probe di bilanciamento del carico nell'impostazione networkProfile del set di scalabilità e il probe può essere associato a un servizio di bilanciamento del carico interno o pubblico, come segue:

"networkProfile": {
  "healthProbe" : {
    "id": "[concat(variables('lbId'), '/probes/', variables('sshProbeName'))]"
  },
  "networkInterfaceConfigurations":
  ...
}

Uso dell'estensione Integrità applicazione

L'estensione Integrità applicazione viene distribuita in un'istanza di un Set di scalabilità di macchine virtuali e segnala l'integrità della VM dall'interno dell'istanza di set di scalabilità. È possibile configurare l'estensione per eseguire il probe su un endpoint dell'applicazione e aggiornare lo stato dell'applicazione in tale istanza. Questo stato dell'istanza viene verificato da Azure per determinare se un'istanza è idonea per le operazioni di aggiornamento.

Poiché l'estensione segnala l'integrità dall'interno di una macchina virtuale, può essere usata nelle situazioni in cui non è possibile usare probe esterni, ad esempio i probe di Integrità applicazione (che usano probe personalizzati di Azure Load Balancer).

Esistono diversi modi per distribuire l'estensione Integrità applicazione nei set di scalabilità, come descritto in dettaglio negli esempi in questo articolo.

Ottenere la cronologia degli aggiornamenti automatici dell'immagine del sistema operativo

È possibile controllare la cronologia dell'aggiornamento del sistema operativo più recente eseguito nel set di scalabilità con Azure PowerShell, l'interfaccia della riga di comando di Azure 2.0 o le API REST. È possibile ottenere la cronologia degli ultimi cinque tentativi di aggiornamento del sistema operativo negli ultimi due mesi.

Mantenere aggiornate le credenziali

Se il set di scalabilità usa credenziali per accedere alle risorse esterne, ad esempio un'estensione della VM configurata per usare un token SAS per l'account di archiviazione, assicurarsi che le credenziali siano aggiornate. In caso di scadenza delle credenziali, inclusi i certificati e i token, l'aggiornamento avrà esito negativo e il primo batch di VM verrà lasciato in uno stato di errore.

Le procedure consigliate per recuperare le macchine virtuali e abilitare di nuovo l'aggiornamento automatico del sistema operativo se si verifica un errore di autenticazione delle risorse sono:

• Rigenerare il token (o qualsiasi altra credenziale) passato alle estensioni.
• Verificare che le eventuali credenziali usate all'interno della macchina virtuale per comunicare con le entità esterne siano aggiornate.
• Aggiornare le estensioni nel modello di set di scalabilità con eventuali nuovi token.
• Distribuire il set di scalabilità aggiornato, che aggiornerà tutte le istanze di macchina virtuale, incluse quelle in errore.

REST API

Nell'esempio seguente viene usata l'API REST per controllare lo stato per il set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

GET on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osUpgradeHistory?api-version=2021-03-01`

La chiamata GET restituisce proprietà simili all'output dell'esempio seguente:

{
	"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

Usare il cmdlet Get-AzVmss per controllare la cronologia di aggiornamento del sistema operativo per il set di scalabilità. Nell'esempio seguente viene dimostrato in dettaglio come verificare lo stato di aggiornamento del sistema operativo per un set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet" -OSUpgradeHistory

Interfaccia della riga di comando di Azure 2.0

Usare az vmss get-os-upgrade-history per controllare la cronologia di aggiornamento del sistema operativo per il set di scalabilità. Usare l'interfaccia della riga di comando di Azure versione 2.0.47 o successiva. Nell'esempio seguente viene dimostrato in dettaglio come verificare lo stato di aggiornamento del sistema operativo per un set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

az vmss get-os-upgrade-history --resource-group myResourceGroup --name myScaleSet

Come ottenere la versione più recente di un'immagine del sistema operativo della piattaforma?

È possibile ottenere le versioni dell'immagine disponibile per gli SKU supportati tramite gli aggiornamenti automatici del sistema operativo usando gli esempi seguenti:

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"

Interfaccia della riga di comando di Azure 2.0

az vm image list --location "westus" --publisher "Canonical" --offer "0001-com-ubuntu-server-jammy" --sku "22_04-lts" --all

Attivare manualmente gli aggiornamenti delle immagini del sistema operativo

Con l'aggiornamento automatico delle immagini del sistema operativo abilitato nel set di scalabilità, non è necessario attivare manualmente gli aggiornamenti delle immagini nel set di scalabilità. L'agente di orchestrazione dell'aggiornamento del sistema operativo applicherà automaticamente la versione più recente dell'immagine disponibile alle istanze del set di scalabilità senza alcun intervento manuale.

Per casi specifici in cui non si desidera attendere che l'agente di orchestrazione applichi l'immagine più recente, è possibile attivare manualmente un aggiornamento dell'immagine del sistema operativo usando gli esempi seguenti.

REST API

Usare la chiamata all'API Avvia aggiornamento del sistema operativo per avviare un aggiornamento in sequenza per spostare tutte le istanze del Set di scalabilità di macchine virtuali alla versione più recente del sistema operativo immagine disponibile. Le istanze che eseguono già la versione più recente del sistema operativo disponibile non sono interessate. Nell'esempio seguente viene dimostrato in dettaglio come avviare un aggiornamento del sistema operativo in sequenza per un set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

POST on `/subscriptions/subscription_id/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachineScaleSets/myScaleSet/osRollingUpgrade?api-version=2021-03-01`

Azure PowerShell

Usare il cmdlet Start-AzVmssRollingOSUpgrade per controllare la cronologia di aggiornamento del sistema operativo per il set di scalabilità. Nell'esempio seguente viene dimostrato in dettaglio come avviare un aggiornamento del sistema operativo in sequenza per un set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

Start-AzVmssRollingOSUpgrade -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"

Interfaccia della riga di comando di Azure 2.0

Usare az vmss rolling-upgrade start per controllare la cronologia di aggiornamento del sistema operativo per il set di scalabilità. Usare l'interfaccia della riga di comando di Azure versione 2.0.47 o successiva. Nell'esempio seguente viene dimostrato in dettaglio come avviare un aggiornamento del sistema operativo in sequenza per un set di scalabilità denominato myScaleSet nel gruppo di risorse denominato myResourceGroup:

az vmss rolling-upgrade start --resource-group "myResourceGroup" --name "myScaleSet" --subscription "subscriptionId"

Sfruttare i log attività per le notifiche di aggiornamento e le informazioni dettagliate

Il Log attività è un log delle sottoscrizioni che fornisce informazioni approfondite sugli eventi a livello di sottoscrizione che si sono verificati in Azure. I clienti possono:

• Vedere gli eventi correlati alle operazioni eseguite sulle risorse nel portale di Azure
• Creare gruppi di azioni per ottimizzare metodi di notifica come e-mail, sms, webhook o Gestione dei servizi IT
• Configurare avvisi adatti usando criteri differenti usando il portale, il modello di risorsa ARM, PowerShell o l'interfaccia della riga di comando da inviare ai gruppi di azioni

I clienti riceveranno tre tipi di notifiche correlate all'operazione di aggiornamento automatico del sistema operativo:

• Invio di una richiesta di aggiornamento per una determinata risorsa
• Risultato della richiesta di invio insieme a eventuali dettagli sull'errore
• Risultato del completamento dell'aggiornamento insieme ai dettagli dell'errore

Configurazione di gruppi di azioni per gli avvisi del log attività

Un gruppo di azioni è una raccolta delle preferenze di notifica definite dal proprietario di una sottoscrizione di Azure. Gli avvisi di Monitoraggio di Azure e di integrità dei servizi usano gruppi di azioni per notificare agli utenti l'attivazione di un avviso.

I gruppi di azioni possono essere creati e gestiti usando:

• ARM Resource Manager
• Portale
• PowerShell:
  • New-AzActionGroup
  • Get-AzActionGroup
  • Remove-AzActionGroup
• CLI

I clienti possono configurare gli elementi seguenti usando i gruppi di azioni:

• Sms e/o notifiche tramite e-mail
• Webhook: i clienti possono collegare webhook ai runbook di automazione e configurare i gruppi di azioni per attivare i runbook. È possibile avviare un runbook da un webhook
• Connessioni di Gestione dei servizi IT

Analizzare e risolvere gli errori di aggiornamento automatico

La piattaforma può restituire errori nelle VM durante l'esecuzione dell'aggiornamento automatico delle immagini con i criteri di aggiornamento in sequenza. La vista Get Instance di una VM contiene il messaggio di errore dettagliato per analizzare e risolvere un errore. Aggiornamenti in sequenza - Ottieni i più recenti è in grado di fornire altri dettagli sulla configurazione e sullo stato dell'aggiornamento in sequenza. Ottieni cronologia degli aggiornamenti del sistema operativo fornisce informazioni dettagliate sull'ultima operazione di aggiornamento delle immagini nel set di scalabilità. Di seguito sono riportati gli errori più importanti che possono causare aggiornamenti in sequenza.

RollingUpgradeInProgressWithFailedUpgradedVMs

• L'errore viene attivato per un errore della macchina virtuale.
• Il messaggio di errore dettagliato indica se l'implementazione continuerà/sospendi in base alla soglia configurata.

MaxUnhealthyUpgradedInstancePercentExceededInRollingUpgrade

• L'errore viene attivato quando la percentuale di VM aggiornate supera la soglia massima consentita per le VM non integre.
• Il messaggio di errore dettagliato aggrega l'errore più comune che contribuisce alle VM non integre. Vedere MaxUnhealthyUpgradedInstancePercent.

MaxUnhealthyInstancePercentExceededInRollingUpgrade

• L'errore viene attivato quando la percentuale di VM non integre supera la soglia massima consentita per le VM non integre durante un aggiornamento.
• Il messaggio di errore dettagliato visualizza la percentuale di non integrità corrente e la percentuale di VM non integra configurata. Vedere maxUnhealthyInstancePercent.

MaxUnhealthyInstancePercentExceededBeforeRollingUpgrade

• L'errore viene attivato quando la percentuale di VM non integre supera la soglia massima consentita per le VM non integre prima che venga eseguito un aggiornamento.
• Il messaggio di errore dettagliato visualizza la percentuale di non integrità corrente e la percentuale di VM non integra configurata. Vedere maxUnhealthyInstancePercent.

InternalExecutionError

• L'errore viene attivato quando si verifica un errore non gestito, non formattato o imprevisto durante l'esecuzione.
• Il messaggio di errore dettagliato visualizza la causa dell'errore.

RollingUpgradeTimeoutError

• L'errore viene attivato al timeout del processo di aggiornamento in sequenza.
• Il messaggio di errore dettagliato visualizza il timeout del sistema dopo il tentativo di aggiornamento.

Passaggi successivi