Condividi tramite

Upgrade e aggiornamento dei cluster di Azure Service Fabric

  • Articolo

Un cluster di Azure Service Fabric è una risorsa di proprietà dell'utente, ma parzialmente gestita da Microsoft. Questo articolo descrive le opzioni per quando e come aggiornare il cluster di Azure Service Fabric.

Aggiornamenti automatici e manuali

È fondamentale assicurarsi che il cluster di Service Fabric esegua sempre una versione di runtime supportata. Ogni volta che Microsoft annuncia il rilascio di una nuova versione di Service Fabric, la versione precedente viene contrassegnata per la fine del supporto dopo almeno 60 giorni da tale data. Le nuove versioni vengono annunciate nel blog del team di Service Fabric.

Quattordici giorni prima della scadenza del rilascio in cui è in esecuzione il cluster, viene generato un evento di integrità che attiva lo stato di integrità del cluster. Il cluster rimane in uno stato di avviso fino a quando non si esegue l'aggiornamento a una versione di runtime supportata.

È possibile impostare il cluster per ricevere gli aggiornamenti automatici di Service Fabric non appena vengono rilasciati da Microsoft oppure è possibile scegliere manualmente da un elenco di versioni attualmente supportate. Queste opzioni sono disponibili nella sezione Aggiornamenti dell'infrastruttura della risorsa cluster di Service Fabric.

Selezionare Aggiornamenti automatici o manuali nella sezione

È anche possibile impostare la modalità di aggiornamento del cluster e selezionare una versione di runtime usando un modello di Resource Manager.

Gli aggiornamenti automatici sono la modalità di aggiornamento consigliata, in quanto questa opzione garantisce che il cluster rimanga in uno stato supportato e trae vantaggio dalle correzioni e dalle funzionalità più recenti, consentendo allo stesso tempo di pianificare gli aggiornamenti in modo che sia meno problematico per i carichi di lavoro usando una strategia di distribuzione wave.

Nota

Se si modifica un cluster esistente in modalità automatica, il cluster verrà registrato per il periodo di aggiornamento successivo a partire da una nuova versione. Le nuove versioni vengono annunciate nel blog del team di Service Fabric. Per periodo di aggiornamento scelto il percorso di aggiornamento più alto possibile, vedere le versioni supportate. La modalità di aggiornamento manuale attiva un aggiornamento immediato.

Distribuzione a onde per gli aggiornamenti automatici

Con la distribuzione wave, è possibile ridurre al minimo l'interruzione di un aggiornamento al cluster selezionando il livello di maturità di un aggiornamento, a seconda del carico di lavoro. Ad esempio, è possibile configurare una pipeline di distribuzione test ->stage-production> per i vari cluster di Service Fabric per testare la compatibilità di un aggiornamento di runtime prima di applicarla ai carichi di lavoro di produzione.

Per acconsentire esplicitamente alla distribuzione wave, specificare uno dei valori wave seguenti per il cluster (nel relativo modello di distribuzione):

  • Onda 0: i cluster vengono aggiornati non appena viene rilasciata una nuova build di Service Fabric. Opzione destinata ai cluster di test/sviluppo.
  • Onda 1: i cluster vengono aggiornati una settimana (sette giorni) dopo il rilascio di una nuova build. Opzione destinata ai cluster pre-produzione/staging.
  • Onda 2: i cluster vengono aggiornati due settimane (14 giorni) dopo il rilascio di una nuova build. Opzione destinata ai cluster di produzione.

È possibile registrarsi per ricevere notifiche tramite posta elettronica con i collegamenti a ulteriore assistenza nel caso in cui un aggiornamento del cluster non riesca. Per iniziare, vedere Distribuzione wave per gli aggiornamenti automatici.

Fasi dell'aggiornamento automatico

Microsoft gestisce il codice e la configurazione del runtime di Service Fabric in esecuzione in un cluster di Azure. Gli aggiornamenti monitorati automaticamente al software vengono eseguiti in base alle esigenze. Gli aggiornamenti possono interessare il codice, la configurazione o entrambi. Per ridurre al minimo l'impatto di questi aggiornamenti sulle applicazioni, vengono eseguite nelle fasi seguenti:

Fase 1: Un aggiornamento viene eseguito usando tutti i criteri di integrità del cluster

In questa fase gli aggiornamenti interessano un dominio di aggiornamento per volta e le applicazioni in esecuzione sul cluster non subiscono tempi di inattività. I criteri di integrità del cluster (per l'integrità dei nodi e l'integrità delle applicazioni) sono conformi durante l'aggiornamento.

Se i criteri di integrità del cluster non vengono soddisfatti, viene eseguito il rollback dell'aggiornamento e viene inviato un messaggio di posta elettronica al proprietario della sottoscrizione. contenente le informazioni seguenti:

  • Notifica che era necessario eseguire il rollback di un aggiornamento del cluster.
  • Eventuali azioni correttive suggerite.
  • Numero di giorni (n) fino a quando non viene eseguita la fase 2.

Si tenta di eseguire più volte lo stesso aggiornamento nel caso in cui non sia riuscito a causa di problemi di infrastruttura. Dopo i n giorni dalla data in cui è stato inviato il messaggio di posta elettronica, continuiamo alla fase 2.

Se i criteri di integrità del cluster sono soddisfatti, l'aggiornamento si considera riuscito e viene contrassegnato come completato. Questa situazione può verificarsi durante l'aggiornamento iniziale o qualsiasi riesecuzione dell'aggiornamento in questa fase. Non c'è alcuna conferma tramite posta elettronica di un'esecuzione riuscita, per evitare di inviare messaggi di posta elettronica eccessivi. La ricezione di un messaggio di posta elettronica indica un'eccezione alle normali operazioni. Si prevede che la maggior parte degli aggiornamenti del cluster abbia esito positivo, senza alcun impatto sulla disponibilità dell'applicazione.

Fase 2: Un aggiornamento viene eseguito usando solo i criteri di integrità predefiniti

I criteri di integrità in questa fase vengono impostati in modo che il numero di applicazioni integre all'inizio dell'aggiornamento rimanga invariato durante il processo di aggiornamento. Come nella fase 1, in questa fase gli aggiornamenti interessano un dominio di aggiornamento per volta e le applicazioni in esecuzione sul cluster non subiscono tempi di inattività. Durante l'aggiornamento vengono rispettati i criteri di integrità del cluster (una combinazione dell'integrità del nodo e dell'integrità di tutte le applicazioni in esecuzione nel cluster).

Se i criteri di integrità del cluster in vigore non vengono soddisfatti, viene eseguito il rollback dell'aggiornamento. Al proprietario della sottoscrizione verrà quindi inviato un messaggio di posta elettronica contenente le informazioni seguenti:

  • Notifica che era necessario eseguire il rollback di un aggiornamento del cluster.
  • Eventuali azioni correttive suggerite.
  • Il numero di giorni (n) prima dell'avvio della fase 3.

Si tenta di eseguire più volte lo stesso aggiornamento nel caso in cui non sia riuscito a causa di problemi di infrastruttura. Viene inviato un messaggio di sollecito alcuni giorni prima della scadenza degli n giorni. Dopo che gli n giorni dalla data di invio del messaggio di posta elettronica sono trascorsi, si passa alla fase 3. I messaggi di posta elettronica inviati nella fase 2 devono essere tenuti in alta considerazione e devono essere intraprese azioni correttive.

Se i criteri di integrità del cluster sono soddisfatti, l'aggiornamento si considera riuscito e viene contrassegnato come completato. Questa situazione può verificarsi durante l'aggiornamento iniziale o in una delle repliche previste in questa fase. Non viene inviato alcun messaggio di posta elettronica di conferma in caso di esecuzione riuscita.

Fase 3: Un aggiornamento viene eseguito usando criteri di integrità aggressivi

Tali criteri di integrità in questa fase sono pensati per il completamento dell'aggiornamento piuttosto che per l'integrità delle applicazioni. In questa fase vengono eseguiti pochi aggiornamenti del cluster. Se il cluster raggiunge questa fase, è possibile che l'applicazione diventi non integra e/o perda la disponibilità.

In modo analogo alle altre due fasi, gli aggiornamenti della fase 3 procedono in base a un dominio di aggiornamento alla volta.

Se i criteri di integrità del cluster non vengono soddisfatti, viene eseguito il rollback dell'aggiornamento. Si tenta di eseguire più volte lo stesso aggiornamento nel caso in cui non sia riuscito a causa di problemi di infrastruttura. A questo punto, il cluster viene bloccato in modo che non riceva più supporto e/o aggiornamenti.

Al proprietario della sottoscrizione viene inviato un messaggio di posta elettronica contenente queste informazioni e le azioni correttive. Se la fase 3 ha esito negativo, si prevede che il cluster non venga impostato su alcun tipo di stato.

Se i criteri di integrità del cluster sono soddisfatti, l'aggiornamento si considera riuscito e viene contrassegnato come completato. Questa situazione può verificarsi durante l'aggiornamento iniziale o in una delle repliche previste in questa fase. Non viene inviato alcun messaggio di posta elettronica di conferma in caso di esecuzione riuscita.

Criteri personalizzati per gli aggiornamenti manuali

È possibile specificare criteri personalizzati per gli aggiornamenti manuali del cluster. Questi criteri vengono applicati ogni volta che si seleziona una nuova versione del runtime, il che attiva il sistema per l'avvio dell'aggiornamento del cluster. Se non si esegue l'override dei criteri, vengono usati quelli predefiniti. Per altre informazioni, vedere Impostare criteri personalizzati per gli aggiornamenti manuali.

Altri aggiornamenti del cluster

Al di fuori dell'aggiornamento del runtime, potrebbe essere necessario eseguire diverse altre azioni per mantenere aggiornato il cluster, tra cui quanto segue:

Gestione dei certificati

Service Fabric usa i certificati server X.509 specificati quando si crea un cluster per proteggere le comunicazioni tra i nodi del cluster ed eseguire l'autenticazione client. È possibile aggiungere, aggiornare o eliminare certificati per il cluster e il client nel portale di Azure o tramite Azure PowerShell o l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Aggiungere o rimuovere certificati

Apertura delle porte dell'applicazione

È possibile modificare le porte dell'applicazione modificando le proprietà della risorsa del servizio di bilanciamento del carico associate al tipo di nodo. È possibile usare il portale di Azure oppure PowerShell o l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Aprire le porte dell'applicazione per un cluster.

Definizione delle proprietà del nodo

È talvolta necessario assicurarsi che carichi di lavoro specifici vengano eseguiti solo in tipi di nodo specifici nel cluster. Ad esempio, è possibile che alcuni carichi di lavoro richiedano GPU o SSD, mentre altri no. Per ogni tipo di nodo in un cluster è possibile aggiungere proprietà personalizzate ai nodi corrispondenti. I vincoli di posizionamento sono le istruzioni collegate ai singoli servizi che selezionano una o più proprietà del nodo. Definiscono la posizione in cui i servizi devono essere eseguiti.

Per informazioni dettagliate sull'uso e sulla definizione dei vincoli di posizionamento e delle proprietà dei nodi, vedere Proprietà dei nodi e vincoli di posizionamento.

Aggiunta di metriche di capacità

Per ogni tipo di nodo è possibile aggiungere metriche di capacità personalizzate da usare nelle applicazioni per creare report sul carico. Per informazioni dettagliate sull'uso di metriche di capacità per la segnalazione del carico, vedere i documenti di Gestione risorse del cluster di Service Fabric relativi a descrizione del cluster e metriche e carico.

Personalizzazione delle impostazioni per il cluster

In un cluster è possibile personalizzare molte impostazioni di configurazione diverse, ad esempio il livello di affidabilità del cluster e le proprietà dei nodi. Per altre informazioni, vedere Impostazioni di un cluster di Service Fabric.

Aggiornamento delle immagini del sistema operativo per i nodi del cluster

L'abilitazione degli aggiornamenti automatici delle immagini del sistema operativo per i nodi del cluster di Service Fabric è una procedura consigliata. A tale scopo, esistono diversi requisiti e passaggi del cluster da eseguire. Un'altra opzione consiste nell'usare Patch Orchestration Application (POA), un'applicazione di Service Fabric che automatizza l'applicazione di patch del sistema operativo in un cluster di Service Fabric senza tempi di inattività. Per altre informazioni su queste opzioni, vedere Applicare patch al sistema operativo Windows nel cluster di Service Fabric.

Passaggi successivi