Condividi tramite

Failover e applicazione di patch per la cache di Azure per Redis

  • Si applica a: ✅ Azure Cache for Redis

Importante

La cache di Azure per Redis ha annunciato la sequenza temporale di ritiro per tutti gli SKU. È consigliabile spostare le istanze di Cache Redis di Azure esistenti in Azure Managed Redis non appena è possibile.

Per altre informazioni sul ritiro:

Per creare applicazioni client resilienti e efficaci, è fondamentale comprendere il failover nel servizio Cache Redis di Azure. Un failover può far parte delle operazioni di gestione pianificate oppure può essere causato da errori hardware o di rete non pianificati. Un uso comune del failover della cache si verifica quando il servizio di gestione applica patch ai file binari di Cache di Azure per Redis.

In questo articolo sono disponibili queste informazioni:

  • Che cos'è un failover?
  • Modalità di esecuzione del failover durante l'applicazione di patch.
  • Come compilare un'applicazione client resiliente.

Che cos'è un failover?

Iniziamo con una panoramica del failover per Azure Cache for Redis.

Riepilogo rapido dell'architettura della cache

Una cache viene costruita da più macchine virtuali con indirizzi IP separati e privati. Ogni macchina virtuale, nota anche come nodo, è connessa a un servizio di bilanciamento del carico condiviso con un singolo indirizzo IP virtuale. Ogni nodo esegue il processo del server Redis ed è accessibile usando il nome host e le porte Redis. Ogni nodo viene considerato un nodo primario o di replica. Quando un'applicazione client si connette a una cache, il traffico passa attraverso questo servizio di bilanciamento del carico e viene indirizzato automaticamente al nodo primario.

In una cache Basic, il singolo nodo è sempre un nodo primario. In una cache Standard o Premium sono presenti due nodi: uno viene scelto come primario e l'altro è la replica. Poiché le cache Standard e Premium hanno più nodi, un nodo potrebbe non essere disponibile mentre l'altro continua a elaborare le richieste. Le cache in cluster sono costituite da molte partizioni, ognuna con nodi primari e di replica distinti. Una partizione potrebbe essere inattiva mentre le altre rimangono disponibili.

Annotazioni

Una cache Basic non ha più nodi multipli e non offre un accordo sul livello di servizio (SLA) per la sua disponibilità. Le cache di base sono consigliate solo a scopo di sviluppo e test. Usare una cache Standard o Premium per una distribuzione multinodo per aumentare la disponibilità.

Spiegazione di un failover

Un failover si verifica quando un nodo di replica si alza di livello per diventare un nodo primario e il nodo primario precedente chiude le connessioni esistenti. Dopo che il nodo primario è tornato operativo, rileva il cambiamento dei ruoli e si degrada per diventare una replica. Si connette quindi al nuovo database primario e sincronizza i dati. Un failover potrebbe essere pianificato o non pianificato.

Un failover pianificato viene eseguito in due momenti diversi:

  • Aggiornamenti di sistema, ad esempio l'applicazione di patch a Redis o gli aggiornamenti del sistema operativo.
  • Operazioni di gestione, ad esempio ridimensionamento e riavvio.

Poiché i nodi ricevono una notifica anticipata dell'aggiornamento, possono scambiare in modo cooperativo i ruoli e aggiornare rapidamente il servizio di bilanciamento del carico della modifica. Un failover pianificato termina in genere in meno di 1 secondo.

Un failover non pianificato può verificarsi a causa di errori hardware, errori di rete o altre interruzioni impreviste nel nodo primario. Il nodo di replica si alza di livello primario, ma il processo richiede più tempo. Un nodo di replica deve prima rilevare che il nodo primario non è disponibile prima di poter avviare il processo di failover. Il nodo di replica deve anche verificare che questo errore non pianificato non sia temporaneo o locale, per evitare un failover non necessario. Questo ritardo nel rilevamento indica che un failover non pianificato termina in genere entro 10-15 secondi.

Come si verifica l'applicazione di patch?

Il servizio Cache Redis di Azure aggiorna regolarmente la cache con le funzionalità e le correzioni più recenti della piattaforma. Per applicare patch a una cache, il servizio segue questa procedura:

  1. Il servizio applica prima patch al nodo di replica.
  2. La replica con patch si promuove in modo cooperativo a nodo primario. Questa promozione è considerata un failover pianificato.
  3. Il nodo primario precedente viene riavviato per applicare le nuove modifiche e ritorna attivo come nodo di replica.
  4. Il nodo di replica si connette al nodo primario e sincronizza i dati.
  5. Al termine della sincronizzazione dei dati, il processo di applicazione di patch viene ripetuto per i nodi rimanenti.

Poiché l'applicazione di patch è un failover pianificato, il nodo di replica si promuove rapidamente per diventare un nodo primario. Il nodo avvia quindi le richieste di manutenzione e le nuove connessioni. Le cache di base non hanno un nodo di replica e non sono disponibili fino al completamento dell'aggiornamento. Ogni partizione di una cache in cluster viene corretta separatamente e non chiude le connessioni a un'altra partizione.

Importante

I nodi vengono patchati uno alla volta per evitare la perdita di dati. Le cache di base avranno una perdita di dati. Le cache in cluster vengono applicate patch a una partizione alla volta.

Vengono applicate anche patch a più cache nello stesso gruppo di risorse e nella stessa regione, una alla volta. Le cache che si trovano in gruppi di risorse o aree diverse possono essere aggiornate contemporaneamente.

Poiché la sincronizzazione completa dei dati avviene prima della ripetizione del processo, è improbabile che si verifichi una perdita di dati quando si usa una cache Standard o Premium. È possibile proteggersi ulteriormente dalla perdita di dati esportando i dati e abilitando la persistenza.

Caricamento della cache aggiuntivo

Ogni volta che si verifica un failover, le cache Standard e Premium devono replicare i dati da un nodo all'altro. Questa replica causa un aumento del carico sia nella memoria del server che nella CPU. Se l'istanza della cache è già caricata pesantemente, le applicazioni client potrebbero riscontrare un aumento della latenza. In casi estremi, le applicazioni client potrebbero ricevere eccezioni di timeout. Per ridurre l'effetto di un carico maggiore, configurare l'impostazione della maxmemory-reserved cache.

In che modo un failover influisce sull'applicazione client?

Le applicazioni client potrebbero ricevere alcuni errori dalla cache di Azure per Redis. Il numero di errori rilevati da un'applicazione client dipende dal numero di operazioni in sospeso per tale connessione al momento del failover. Qualsiasi connessione indirizzata attraverso il nodo che ha chiuso le connessioni rileva errori.

Molte librerie client possono generare diversi tipi di errori in caso di interruzione delle connessioni, tra cui:

  • Eccezioni di timeout
  • Eccezioni di connessione
  • Eccezioni socket

Il numero e il tipo di eccezioni dipendono dalla posizione in cui la richiesta si trova nel percorso del codice quando la cache chiude le connessioni. Ad esempio, un'operazione che invia una richiesta ma non ha ricevuto una risposta quando si verifica il failover potrebbe ottenere un'eccezione di timeout. Le nuove richieste sull'oggetto connessione chiusa ricevono eccezioni di connessione fino a quando la riconnessione non viene eseguita correttamente.

La maggior parte delle librerie client tenta di riconnettersi alla cache, se configurate per farlo. Tuttavia, i bug imprevisti possono occasionalmente inserire gli oggetti della libreria in uno stato irreversibile. Se gli errori vengono mantenuti per più tempo rispetto a un periodo di tempo preconfigurato, l'oggetto connessione deve essere ricreato. In Microsoft.NET e in altri linguaggi orientati agli oggetti, è possibile ricreare la connessione senza riavviare l'applicazione usando un modello ForceReconnect.

È possibile ricevere una notifica in anticipo sulla manutenzione?

Cache Redis di Azure pubblica le notifiche di manutenzione del runtime in un canale di pubblicazione/sottoscrizione (pub/sub) denominato AzureRedisEvents. Molte librerie client Redis più diffuse supportano la sottoscrizione a canali pub/sub. La ricezione di notifiche dal AzureRedisEvents canale è in genere un'aggiunta semplice all'applicazione client. Per altre informazioni sugli eventi di manutenzione, vedere AzureRedisEvents.

Annotazioni

Il canale AzureRedisEvents non è un meccanismo in grado di notificarti con giorni o ore di anticipo. Il canale può notificare ai client qualsiasi evento di manutenzione server imminente che potrebbe influire sulla disponibilità del server. AzureRedisEvents è disponibile solo per i livelli Basic, Standard e Premium.

Quali sono gli aggiornamenti inclusi nella manutenzione?

La manutenzione include questi aggiornamenti:

  • Aggiornamenti del server Redis: qualsiasi aggiornamento o patch dei file binari del server Redis.
  • Aggiornamenti delle macchine virtuali: tutti gli aggiornamenti della macchina virtuale che ospitano il servizio Redis. Gli aggiornamenti delle macchine virtuali includono l'applicazione di patch ai componenti software nell'ambiente host, l'aggiornamento dei componenti di rete o la rimozione delle autorizzazioni.

La manutenzione viene visualizzata nell'integrità dei servizi nel portale di Azure prima di una patch?

No, la manutenzione non compare affatto sotto stato del servizio nel portale o in qualsiasi altra posizione.

Quanto tempo è possibile ricevere la notifica prima della manutenzione pianificata?

Quando si usa il AzureRedisEvents canale, si riceve una notifica di 15 minuti prima della manutenzione.

Modifiche alla configurazione della rete client

Alcune modifiche alla configurazione della rete lato client possono causare l'errore Nessuna connessione disponibile. Tali modifiche possono includere:

  • Scambio dell'indirizzo IP virtuale di un'applicazione client tra slot di staging e di produzione.
  • Ridimensionamento delle dimensioni o del numero di istanze dell'applicazione.

Tali modifiche possono causare un problema di connettività che in genere dura meno di un minuto. L'applicazione client probabilmente perde la connessione ad altre risorse di rete esterne, ma anche al servizio Cache Redis di Azure.

Creare resilienza

Non è possibile evitare completamente i failover. Scrivere invece le applicazioni client in modo che siano resilienti alle interruzioni di connessione e alle richieste non riuscite. La maggior parte delle librerie client si riconnette automaticamente all'endpoint della cache, ma alcuni di essi tentano di ripetere le richieste non riuscite. A seconda dello scenario dell'applicazione, potrebbe essere opportuno usare la logica di ripetizione dei tentativi con il backoff.

Come si rende resiliente l'applicazione?

Fare riferimento a questi modelli di progettazione per creare client resilienti, in particolare l'interruttore e i modelli di ripetizione dei tentativi:

Per testare la resilienza di un'applicazione client, usare un riavvio come trigger manuale per le interruzioni di connessione.

È inoltre consigliabile usare gli aggiornamenti pianificati per scegliere un canale di aggiornamento e una finestra di manutenzione per la cache per applicare le patch di runtime Redis durante specifiche finestre settimanali. Queste finestre sono in genere periodi in cui il traffico dell'applicazione client è basso, per evitare potenziali eventi imprevisti. Per altre informazioni, vedere Canale di aggiornamento e Pianificazione degli aggiornamenti.

Per altre informazioni, vedere Resilienza delle connessioni.

Contenuti correlati

  • Last updated on