Esporta (0) Stampa
Espandi tutto

Aggiornare un servizio di Azure

Aggiornamento: maggio 2014

Tramite Azure le istanze del ruolo vengono organizzate in raggruppamenti logici chiamati domini di aggiornamento. Il numero predefinito di domini di aggiornamento è 5. È possibile specificare un numero diverso includendo l'attributo upgradeDomainCount nel file di definizione del servizio (.csdef). Per altre informazioni sull'attributo upgradeDomainCount, vedere Schema WebRole o Schema WorkerRole.

Quando si esegue un aggiornamento sul posto di uno o più ruoli del servizio, tramite Azure vengono aggiornati i set di istanze del ruolo in base al dominio di aggiornamento a cui appartengono. Tutte le istanze appartenenti a un dato dominio di aggiornamento vengono aggiornate da Azure (cioè vengono arrestate, aggiornate e riportate online). Il processo viene quindi ripetuto sul dominio seguente. Arrestando solo le istanze in esecuzione nel dominio di aggiornamento corrente, tramite Azure viene garantito che l'impatto di un aggiornamento sul servizio in esecuzione sia minimo. Per altre informazioni, vedere How the update proceeds più avanti in questo articolo.

noteNota
Sebbene il termine aggiornamento possa assumere significati leggermente diversi in Azure a seconda del contesto, è possibile usarlo in modo indifferente per i processi e le descrizioni delle funzionalità in questo documento.

Tramite il servizio devono essere definite almeno due istanze di un ruolo affinché quest'ultimo venga aggiornato sul posto evitando un tempo di inattività. Se il servizio è costituito da una sola istanza di un ruolo, esso non sarà disponibile finché l'aggiornamento sul posto non è stato completato.

In questo argomento vengono illustrate le informazioni seguenti sugli aggiornamenti di Azure:

Nella tabella seguente vengono illustrate le modifiche che è possibile apportare a un servizio durante un aggiornamento:

 

Modifiche consentite a hosting, servizi e ruoli Aggiornamento sul posto Gestione temporanea (scambio VIP) Eliminazione e ridistribuzione

Versione del sistema operativo

Livello di attendibilità .NET

Dimensione della macchina virtuale

WarningAvviso
La modifica della dimensione della macchina virtuale comporterà l'eliminazione permanente dei dati locali.

noteNota
È richiesto Azure SDK 1.5 o versioni successive.

Impostazioni di archiviazione locale

Solo aumento.

noteNota
È richiesto Azure SDK 1.5 o versioni successive.

Aggiunta o rimozione di ruoli in un servizio

Numero di istanze di un particolare ruolo

Numero o tipo di endpoint di un servizio

noteNota
È richiesto Azure SDK 1.5 o versioni successive.

ImportantImportante
Durante l'aggiornamento degli endpoint si potrebbe perdere temporaneamente la disponibilità.

No

Nomi e valori delle impostazioni di configurazione

Valori (ma non i nomi) delle impostazioni di configurazione

Aggiunta di nuovi certificati

Modifica dei certificati esistenti

Distribuzione del nuovo codice

Durante un aggiornamento non sono supportati gli elementi seguenti:

  • Modifica del nome di un ruolo. Rimuovere e, successivamente, aggiungere il ruolo con il nuovo nome.

  • Modifica del numero di domini di aggiornamento.

  • Diminuzione delle dimensioni delle risorse locali.

Se si eseguono altri aggiornamenti alla definizione del servizio, ad esempio la diminuzione delle dimensioni della risorsa locale, è necessario eseguire invece un aggiornamento di scambio VIP. Per altre informazioni, vedere Gestire gli aggiornamenti al sistema operativo guest Azure.

Azure offre flessibilità nella gestione dei servizi durante un aggiornamento consentendo l'avvio di operazioni aggiuntive in un servizio, dopo l'accettazione della richiesta di aggiornamento iniziale da parte del controller di infrastruttura di Azure. Un rollback può essere eseguito solo quando un aggiornamento (modifica alla configurazione o altro tipo di aggiornamento) è nello stato in corso nella distribuzione. Un aggiornamento viene considerato in corso finché esiste almeno un'istanza del servizio di cui non è ancora stato eseguito l'aggiornamento alla nuova versione. Per verificare se un rollback è consentito, controllare che il valore del flag RollbackAllowed, restituito dalle operazioni Ottenere la distribuzione e Recuperare le proprietà del servizio cloud, sia impostato su true.

noteNota
La chiamata del rollback in un aggiornamento sul posto risulta utile unicamente perché gli aggiornamenti di scambio VIP comportano la sostituzione di un'intera istanza in esecuzione del servizio con un'altra.

Il rollback di un aggiornamento in corso presenta gli effetti seguenti sulla distribuzione:

  • Tutte le istanze del ruolo che non sono state ancora aggiornate alla nuova versione non vengono aggiornate, dal momento che nelle istanze in questione è già in esecuzione la versione di destinazione del servizio.

  • In tutte le istanze del ruolo che sono già state aggiornate alla nuova versione del file del pacchetto del servizio (*.cspkg) o del file di configurazione del servizio (*.cscfg), o di entrambi i file, viene ripristinata la versione di pre-aggiornamento di questi file.

La funzionalità viene fornita dai seguenti componenti:

Di seguito sono riportate alcune situazioni in cui il rollback di un aggiornamento non è supportato:

  • Riduzione delle risorse locali. Se l'aggiornamento comporta un aumento delle risorse locali per un ruolo, la piattaforma Azure non consente il rollback. Per altre informazioni sulla configurazione delle risorse locali per un ruolo, vedere Configurare le risorse di archiviazione locale.

  • Limitazioni di quota. Se l'aggiornamento è consistito in un'operazione di ridimensionamento, la quota di calcolo potrebbe non essere più sufficiente per completare l'operazione di rollback. A ogni sottoscrizione Azure è associata una quota mediante la quale viene specificato il numero massimo di core che possono essere usati da tutti i servizi ospitati appartenenti alla sottoscrizione. Se l'esecuzione di un rollback di un aggiornamento specificato comporta il superamento della quota da parte della sottoscrizione, il rollback non sarà abilitato.

  • Race condition. Se l'aggiornamento iniziale è stato completato, il rollback non è possibile.

Un esempio di situazione in cui il rollback di un aggiornamento potrebbe risultare utile è costituito dall'uso dell'operazione Aggiornare la distribuzione in modalità manuale per controllare l'efficacia di implementazione di un aggiornamento sul posto principale al servizio ospitato da Azure.

Durante l'implementazione dell'aggiornamento, è possibile chiamare Aggiornare la distribuzione in modalità manuale e iniziare a esaminare i domini di aggiornamento. Se a un certo punto, durante il monitoraggio dell'aggiornamento, si nota che non si ricevono risposte da alcune istanze del ruolo nei primi domini di aggiornamento analizzati, è possibile chiamare l'operazione Aggiornamento o aggiornamento di rollback nella distribuzione, in modo che le istanze che non erano state ancora aggiornate rimangano invariate e venga eseguito il rollback alla configurazione e al pacchetto del servizio precedenti per le istanze che erano state aggiornate.

In alcuni casi è possibile avviare più operazioni di mutazione simultanee in una distribuzione in corso. Ad esempio, è possibile eseguire un aggiornamento dei servizi e, mentre l'aggiornamento viene implementato nel servizio, si desidera apportare alcune modifiche, come l'esecuzione del rollback dell'aggiornamento, l'applicazione di un altro aggiornamento o anche l'eliminazione della distribuzione. Una situazione in cui ciò potrebbe essere necessario è l'eventuale presenza, in un aggiornamento dei servizi, di codice con errore che causa ripetutamente l'arresto anomalo di un'istanza del ruolo aggiornata. In questo caso, tramite il controller di infrastruttura di Azure non sarà possibile eseguire avanzamenti nell'applicare l'aggiornamento in questione in quanto il numero di istanze integre nel dominio aggiornato non è sufficiente. Questo stato viene definito distribuzione bloccata. È possibile sbloccare la distribuzione eseguendo il rollback dell'aggiornamento o applicando un aggiornamento più recente su quello che ha presentato errori.

Una volta ricevuta la richiesta iniziale di aggiornare il servizio dal controller di infrastruttura di Azure, è possibile avviare le operazioni di mutazione successive. Vale a dire, non è necessario attendere il completamento dell'operazione iniziale prima di poter avviare un'altra operazione di mutazione.

L'esecuzione dell'avvio di una seconda operazione di aggiornamento mentre il primo aggiornamento è in corso sarà simile all'operazione di rollback. Se il secondo aggiornamento è in modalità automatica, il primo dominio di aggiornamento verrà aggiornato immediatamente, possibilmente a partire da istanze di più domini di aggiornamento offline nello stesso momento.

Le operazioni di mutazione sono le seguenti: Modificare la configurazione di distribuzione, Aggiornare la distribuzione, Aggiornare lo stato della distribuzione, Elimina distribuzione e Aggiornamento o aggiornamento di rollback.

Tramite due operazioni, Ottenere la distribuzione e Recuperare le proprietà del servizio cloud, viene restituito il flag Locked che può essere esaminato per stabilire se un'operazione di mutazione può essere richiamata in una distribuzione specificata.

Per chiamare la versione di questi metodi che restituisce il flag Locked, è necessario impostare l'intestazione di richiesta su"x-ms-version: 2011-10-01" o una versione successiva. Per altre informazioni sulle intestazioni di controllo delle versioni, vedere Controllo delle versioni di gestione del servizio.

Tramite Azure vengono distribuite le istanze di un ruolo in modo uniforme in un numero specifico di domini di aggiornamento, che può essere configurato come parte del file di definizione del servizio (con estensione csdef). Il numero massimo di domini di aggiornamento è 20 e il valore predefinito è 5. Per altre informazioni su come modificare il file di definizione del servizio, vedere Schema di definizione dei servizi di Azure (file .csdef).

Ad esempio, se il ruolo dispone di dieci istanze, per impostazione predefinita in ogni dominio di aggiornamento sono contenute due istanze. Se il ruolo dispone di 14 istanze, in quattro domini di aggiornamento sono contenute tre istanze e in un quinto dominio ne sono contenute due.

I domini di aggiornamento vengono identificati con un indice in base zero: l'ID del primo dominio di aggiornamento è 0, l'ID del secondo è 1 e così via.

Nel diagramma seguente viene illustrato come i due ruoli contenuti in un servizio vengono distribuiti quando tramite il servizio vengono definiti due domini di aggiornamento. Tramite il servizio vengono eseguite otto istanze del ruolo Web e nove istanze del ruolo di lavoro.

Distribuzione di domini di aggiornamento

noteNota
Si noti che tramite Azure viene controllata la modalità di allocazione delle istanze nei domini di aggiornamento. Non è possibile specificare quali istanze siano allocate a un determinato dominio.

È possibile decidere se aggiornare tutti i ruoli, o uno soltanto, nel servizio. In entrambi i casi, tutte le istanze di ogni ruolo aggiornato e appartenenti al primo dominio di aggiornamento vengono arrestate, aggiornate e riportate online. Una volta riportate online, le istanze nel secondo dominio di aggiornamento vengono arrestate, aggiornate e riportate online.

Nel diagramma seguente viene illustrata la continuazione dell'aggiornamento in caso di aggiornamento di tutti i ruoli nel servizio:

Servizio di aggiornamento

Nel diagramma seguente viene illustrata la continuazione dell'aggiornamento in caso di aggiornamento di un solo ruolo:

Ruolo di aggiornamento
noteNota
Durante l'aggiornamento da una a più istanze, il servizio viene ridotto a causa della modalità di esecuzione dell'aggiornamento dei servizi in Azure. Il contratto di servizio che garantisce la disponibilità del servizio viene applicato solo ai servizi distribuiti con più istanze. Nell'elenco seguente vengono descritti gli effetti di ogni scenario di aggiornamento dei servizi di Azure sui dati di ogni unità:

Riavvio della VM:

  • C: mantenuti

  • D: mantenuti

  • E: mantenuti

Riavvio del portale:

  • C: mantenuti

  • D: mantenuti

  • E: eliminati

Ricreazione dell'immagine del portale:

  • C: mantenuti

  • D: eliminati

  • E: eliminati

Aggiornamento sul posto:

  • C: mantenuti

  • D: mantenuti

  • E: eliminati

Migrazione del nodo:

  • C: eliminati

  • D: eliminati

  • E: eliminati

Si noti che, nell'elenco precedente, l'unità E: rappresenta l'unità radice del ruolo e non deve essere hardcoded. In alternativa, usare la variabile di ambiente %RoleRoot% per rappresentare l'unità.

Per ridurre il tempo di inattività durante l'aggiornamento di un servizio a istanza singola, distribuire un nuovo servizio a più istanze nel server temporaneo ed eseguire uno scambio VIP.

Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft