Come aggiornare un servizio cloud di Azure (versione classica)
Importante
Servizi cloud (versione classica) è ora deprecato per i nuovi clienti e verrà ritirato il 31 agosto 2024 per tutti i clienti. Le nuove distribuzioni devono usare il nuovo modello di distribuzione basato su Azure Resource Manager, Servizi cloud di Azure (supporto "Extended").
L'aggiornamento di un servizio cloud, inclusi i ruoli e il sistema operativo guest, è un processo in tre passaggi. Prima devono essere caricati i file binari e di configurazione per la nuova versione del nuovo servizio cloud o del sistema operativo. Quindi Azure riserva le risorse di calcolo e di rete per il servizio cloud in base ai requisiti della nuova versione del servizio cloud. Infine Azure esegue un aggiornamento in sequenza per aggiornare in modo incrementale il tenant alla nuova versione o al nuovo sistema operativo guest, mantenendo nello stesso tempo la disponibilità. Questo articolo illustra i dettagli dell'ultimo passaggio, l'aggiornamento in sequenza.
Aggiornare un servizio di Azure
Azure organizza le istanze del ruolo in raggruppamenti logici chiamati domini di aggiornamento. I domini di aggiornamento sono set logici di istanze del ruolo aggiornate come gruppo. Azure aggiorna un servizio cloud un dominio di aggiornamento alla volta, per consentire alle istanze negli altri domini di aggiornamento di continuare a gestire il traffico.
Il numero predefinito di domini di aggiornamento è 5. È possibile specificare un numero diverso di domini di aggiornamento includendo l'attributo upgradeDomainCount nel file di definizione del servizio (.csdef). Per altre informazioni sull'attributo upgradeDomainCount, vedere Schema di definizione di Servizi cloud di Azure (file con estensione csdef).
Quando si esegue un aggiornamento sul posto di uno o più ruoli nel servizio, Azure aggiorna i set di istanze del ruolo in base al dominio di aggiornamento a cui appartengono. Azure aggiorna tutte le istanze in un determinato dominio di aggiornamento (arrestandole, aggiornandole, riportandole online), quindi passa al dominio successivo. Arrestando solo le istanze in esecuzione nel dominio di aggiornamento corrente, Azure fa in modo che un aggiornamento venga eseguito con il minor impatto possibile sul servizio in esecuzione. Per altre informazioni, vedere Come avviene un aggiornamento .
Nota
Anche se i termini inglesi update e upgrade hanno un significato leggermente diverso nel contesto di Azure, sono stati entrambi tradotti con il termine italiano "aggiornamento" in relazione ai processi e alle descrizioni delle funzionalità di questo documento.
Il servizio deve definire almeno due istanze di un ruolo per aggiornarlo sul posto senza tempi di inattività. Se il servizio è costituito da una sola istanza di un ruolo, il servizio non sarà disponibile fino al termine dell'aggiornamento sul posto.
Questo argomento contiene le informazioni seguenti sugli aggiornamenti di Azure:
- Modifiche consentite al servizio durante un aggiornamento
- Come avviene un aggiornamento
- Ripristino dello stato precedente di un aggiornamento
- Avvio di più operazioni di mutazione durante una distribuzione
- Distribuzione di ruoli nei domini di aggiornamento
Modifiche consentite al servizio durante un aggiornamento
La tabella seguente mostra le modifiche consentite a un servizio durante un aggiornamento:
| Modifiche consentite a hosting, servizi e ruoli | Aggiornamento sul posto | Gestione temporanea (scambio indirizzi VIP) | Eliminazione e ridistribuzione |
|---|---|---|---|
| Versione del sistema operativo | Sì | Sì | Sì |
| Livello di attendibilità .NET | Sì | Sì | Sì |
| Dimensioni macchina virtuale1 | Sì2 | Sì | Sì |
| Impostazioni di archiviazione locali | Solo aumento2 | Sì | Sì |
| Aggiungere o rimuovere ruoli in un servizio | Sì | Sì | Sì |
| Numero di istanze di un particolare ruolo | Sì | Sì | Sì |
| Numero o tipo di endpoint per un servizio | Sì2 | No | Sì |
| Nomi e i valori delle impostazioni di configurazione | Sì | Sì | Sì |
| Valori (ma non nomi) delle impostazioni di configurazione | Sì | Sì | Sì |
| Aggiungere nuovi certificati | Sì | Sì | Sì |
| Modificare i certificati esistenti | Sì | Sì | Sì |
| Distribuire nuovo codice | Sì | Sì | Sì |
1 Modifica delle dimensioni limitata al sottoinsieme di dimensioni disponibili per il servizio cloud.
2 Richiede Azure SDK 1.5 o versioni successive.
Avviso
La modifica della dimensione di una macchina virtuale eliminerà i dati locali.
Gli elementi seguenti non sono supportati durante un aggiornamento:
- Modifica del nome di un ruolo. Rimuovere e quindi aggiungere il ruolo con il nuovo nome.
- Modifica del conteggio dei domini di aggiornamento.
- Riduzione della dimensione delle risorse locali.
Se intende eseguire altri aggiornamenti alla definizione del servizio, ad esempio la riduzione della dimensione di una risorsa locale, è necessario eseguire invece un aggiornamento dello scambio di indirizzi VIP. Per altre informazioni, vedere Scambiare la distribuzione.
Come avviene un aggiornamento
È possibile decidere se aggiornare tutti i ruoli del servizio oppure uno solo. In entrambi i casi, tutte le istanze di ogni ruolo che verrà aggiornato e appartiene al primo dominio di aggiornamento verranno arrestate, aggiornate e riportate online. Quando sono di nuovo online, vengono arrestate, aggiornate e riportate online le istanze nel secondo dominio di aggiornamento. Un servizio cloud non può avere più di un aggiornamento attivo per volta. L'aggiornamento viene sempre eseguito usando la versione più recente del servizio cloud.
Il diagramma seguente illustra come avviene l'aggiornamento se si aggiornano tutti i ruoli nel servizio:
Il diagramma successivo illustra come avviene l'aggiornamento se si aggiorna un solo ruolo:
Durante un aggiornamento automatico, il controller di infrastruttura di Azure valuta periodicamente l'integrità del servizio cloud per determinare quando è sicuro passare al dominio di aggiornamento successivo. Questa valutazione dell'integrità viene eseguita per ogni singolo ruolo e considera solo le istanze nella versione più recente (ad esempio, le istanze dei domini di aggiornamento già analizzati). Verifica che un numero minimo di istanze del ruolo, per ogni ruolo, abbia raggiunto uno stato finale soddisfacente.
Timeout dell'avvio dell’istanza del ruolo
Il controller di infrastruttura attende 30 minuti affinché ogni istanza del ruolo raggiunga uno stato avviato. Se la durata del timeout scade, il controller di infrastruttura prosegue all'istanza del ruolo successivo.
Impatto sui dati delle unità durante gli aggiornamenti dei servizi cloud
Quando si aggiorna un servizio da una sola istanza a più istanze, il servizio sarà inattivo durante l'esecuzione dell'aggiornamento a causa della modalità di aggiornamento dei servizi in Azure. Il contratto di servizio che garantisce la disponibilità del servizio si applica solo ai servizi distribuiti con più di una istanza. L'elenco seguente descrive come ogni scenario di aggiornamento di un servizio di Azure influisce sui dati di ogni unità:
| Scenario | Unità C | Unità D | Unità E |
|---|---|---|---|
| Riavvio VM | Mantenuta | Mantenuta | Mantenuta |
| Riavvio del portale | Mantenuta | Mantenuta | Eliminata |
| Ricreazione dell'immagine del portale | Mantenuta | Eliminata | Eliminata |
| Aggiornamento sul posto | Mantenuta | Mantenuta | Eliminata |
| Migrazione di un nodo | Eliminata | Eliminata | Eliminata |
Si noti che nell'elenco precedente l'unità E: rappresenta l'unità radice del ruolo e non dovrebbe essere hardcoded. Per rappresentare l'unità, usare invece la variabile di ambiente %RoleRoot%.
Per ridurre al minimo il tempo di inattività durante l'aggiornamento di un servizio a istanza singola, distribuire un nuovo servizio a più istanze nel server di staging ed eseguire uno scambio di indirizzi VIP.
Ripristino dello stato precedente di un aggiornamento
Azure offre flessibilità nella gestione dei servizi durante un aggiornamento perché consente di avviare altre operazioni su un servizio, dopo che la richiesta di aggiornamento iniziale è stata accettata dal controller di infrastruttura di Azure. Un ripristino dello stato precedente può essere eseguito solo quando una modifica della configurazione o un aggiornamento è nello stato in corso durante la distribuzione. Un aggiornamento viene considerato in corso finché almeno un'istanza del servizio non è ancora stata aggiornata alla nuova versione. Per verificare se un ripristino dello stato precedente è consentito, controllare che il valore del flag RollbackAllowed, restituito dalle operazioni Get Deployment e Get Cloud Service Properties, sia impostato su true.
Nota
Chiamare ripristino dello stato precedente è utile solo per un aggiornamento sul posto perché gli aggiornamenti con scambio di indirizzo VIP comportano la sostituzione di un'intera istanza in esecuzione del servizio con un'altra.
Il ripristino dello stato precedente di un aggiornamento in corso ha gli effetti seguenti sulla distribuzione:
- Le istanze del ruolo che non erano ancora state aggiornate alla nuova versione non vengono aggiornate, perché tali istanze stanno già eseguendo la versione di destinazione del servizio.
- Per le istanze del ruolo che erano già state aggiornate alla nuova versione del file del pacchetto del servizio (*.cspkg), del file di configurazione del servizio (*.cscfg) o di entrambi i file viene ripristinata la versione pre-aggiornamento di questi file.
Questa funzionalità viene fornita dalle funzioni seguenti:
Operazione Rollback Update Or Upgrade, che può essere chiamata per un aggiornamento della configurazione (attivato chiamando Change Deployment Configuration) o per un aggiornamento (attivato chiamando Upgrade Deployment) purché sia presente almeno un'istanza nel servizio non ancora aggiornata alla nuova versione.
Elemento Locked ed elemento RollbackAllowed, restituiti come parte del corpo della risposta delle operazioni Get Deployment e Get Cloud Service Properties:
- L'elemento Locked consente di rilevare quando un'operazione di mutazione può essere richiamata in una determinata distribuzione.
- L'elemento RollbackAllowed consente di rilevare quando l'operazione Rollback Update Or Upgrade può essere chiamata in una determinata distribuzione.
Per eseguire un ripristino dello stato precedente, non è necessario controllare entrambi gli elementi Locked e RollbackAllowed. È sufficiente verificare che RollbackAllowed sia impostato su true. Questi elementi vengono restituiti solo se questi metodi vengono richiamati usando l'intestazione della richiesta impostata su "x-ms-version: 2011-10-01" o versione successiva. Per altre informazioni sul controllo delle versioni delle intestazioni, vedere Controllo delle versioni di gestione del servizio.
In alcune situazioni un ripristino dello stato precedente di un aggiornamento non è supportato, come nei casi seguenti:
- Riduzione nelle risorse locali: se l'aggiornamento aumenta le risorse locali per un ruolo, la piattaforma Azure non consente il ripristino dello stato precedente.
- Limitazioni della quota: se l'aggiornamento ha comportato un'operazione di riduzione, è possibile che la quota di calcolo non sia più sufficiente per completare l'operazione di ripristino dello stato precedente. A ogni sottoscrizione di Azure è associata una quota che specifica il numero massimo di memorie centrali che possono essere utilizzate da tutti i servizi ospitati appartenenti a tale sottoscrizione. Se l'esecuzione di un ripristino dello stato precedente di un determinato aggiornamento farà superare la quota prevista per la sottoscrizione, il ripristino dello stato precedente non verrà abilitato.
- Race condition: se l'aggiornamento iniziale è stato completato, un ripristino dello stato precedente non è possibile.
Il ripristino dello stato precedente di un aggiornamento può essere utile, ad esempio, se si usa l'operazione Upgrade Deployment in modalità manuale per controllare la frequenza con cui un aggiornamento sul posto principale del servizio ospitato di Azure viene distribuito.
Durante la distribuzione dell'aggiornamento chiamare Upgrade Deployment in modalità manuale e iniziare ad analizzare i domini di aggiornamento. Se a un certo punto, durante il monitoraggio dell'aggiornamento, si nota che alcune istanze del ruolo nei primi domini di aggiornamento esaminati non rispondono più, chiamare l'operazione Rollback Update Or Upgrade nella distribuzione, che lascerà invariate le istanze non ancora aggiornate e ripristinerà il Service Pack e la configurazione precedenti delle istanze aggiornate.
Avvio di più operazioni di mutazione durante una distribuzione
In alcuni casi potrebbe essere necessario avviare più operazioni di mutazione simultanee in una distribuzione in corso. Ad esempio, eseguendo l'aggiornamento di un servizio, mentre l'aggiornamento viene distribuito nel servizio, potrebbe essere necessario apportare alcune modifiche, come il ripristino dello stato precedente dell'aggiornamento, l'applicazione di un aggiornamento diverso o anche l'eliminazione della distribuzione. Questa necessità, ad esempio, potrebbe presentarsi se l'aggiornamento di un servizio contiene un codice con errori che fa arrestare più volte in modo anomalo un'istanza del ruolo aggiornata. In questo caso, il controller di infrastruttura di Azure non potrà far proseguire l'applicazione di tale aggiornamento perché il numero di istanze integre nel dominio aggiornato non è sufficiente. Questa condizione viene chiamata distribuzione bloccata. Per sbloccare la distribuzione, ripristinare lo stato precedente dell'aggiornamento o applicare un nuovo aggiornamento sopra quello non riuscito.
Dopo che il controller di infrastruttura di Azure ha ricevuto la richiesta iniziale di aggiornare il servizio, è possibile avviare le operazioni di mutazione successive, vale a dire che non è necessario attendere il completamento dell'operazione iniziale prima di poter avviare un'altra operazione di mutazione.
L'avvio di una seconda operazione di aggiornamento mentre il primo aggiornamento è in corso sarà simile all'operazione di ripristino dello stato precedente. Se il secondo aggiornamento è in modalità automatica, il primo dominio di aggiornamento verrà aggiornato immediatamente e le istanze di più domini di aggiornamento potrebbero passare offline nello stesso momento.
Le operazioni di mutazione sono le seguenti: Change Deployment Configuration, Upgrade Deployment, Update Deployment Status, Delete Deployment e Rollback Update Or Upgrade.
Due operazioni, Get Deployment e Get Cloud Service Properties, restituiscono il flag Locked che può essere esaminato per determinare se un'operazione di mutazione può essere richiamata in una determinata distribuzione.
Per chiamare la versione di questi metodi che restituisce il flag Locked, è necessario impostare l'intestazione della richiesta su "x-ms-version: 2011-10-01" o versione successiva. Per altre informazioni sul controllo delle versioni delle intestazioni, vedere Controllo delle versioni di gestione del servizio.
Distribuzione di ruoli nei domini di aggiornamento
Azure distribuisce in tutti i domini di aggiornamento lo stesso numero di istanze di un ruolo, che è possibile configurare come parte del file di definizione del servizio (.csdef). Il numero massimo di domini di aggiornamento è 20 e quello predefinito è 5. Per altre informazioni su come modificare il file csdef, vedere Schema di definizione del servizio di Azure (file .csdef).
Se, ad esempio, il ruolo ha dieci istanze, per impostazione predefinita, ogni dominio di aggiornamento contiene due istanze. Se il ruolo ha 14 istanze, quattro domini di aggiornamento contengono tre istanze e un quinto dominio ne contiene due.
I domini di aggiornamento vengono identificati con un indice in base zero: il primo dominio di aggiornamento ha ID 0, il secondo dominio di aggiornamento ha ID 1 e così via.
Il diagramma seguente illustra come vengono distribuiti due ruoli contenuti in un servizio quando il servizio definisce due domini di aggiornamento. Il servizio esegue otto istanze del ruolo Web e nove istanze del ruolo di lavoro.
Nota
Si noti che Azure controlla come le istanze vengono allocate nei domini di aggiornamento. Non è possibile specificare quali istanze vengono allocate in ogni dominio.
Passaggi successivi
Come gestire i servizi cloud
Come monitorare i servizi cloud
Come configurare i servizi cloud