Failover e applicazione di patch per Cache di Azure per Redis

Per creare applicazioni client resilienti ed efficaci è fondamentale comprendere il failover nel servizio Cache di Azure per Redis. 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?

Si inizierà con una panoramica del failover per Cache di Azure per 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.

Spiegazione di un failover

Un failover si verifica quando un nodo di replica alza il proprio livello per diventare un nodo primario e il nodo primario precedente chiude le connessioni esistenti. Una volta eseguito il backup del nodo primario, si nota la modifica dei ruoli e abbassa il proprio livello per diventare una replica. Si connette quindi al nuovo nodo 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, come l'applicazione di patch a Redis o gli aggiornamenti del sistema operativo.
• Operazioni di gestione, come 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 un 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 eleva a 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 significa che un failover non pianificato termina in genere entro 10-15 secondi.

Come si verifica l'applicazione di patch?

Il servizio Cache di Azure per Redis 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. Tale promozione viene considerata un failover pianificato.
3. Il nodo primario precedente viene riavviato per eseguire le nuove modifiche e viene eseguito il backup 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 applicata tramite patch separatamente e non chiude le connessioni a un'altra partizione.

Anche alle cache multiple facenti parte dello stesso gruppo di risorse e della stessa area vengono applicate patch singolarmente. Alle cache che si trovano in gruppi di risorse o aree diverse possono essere applicate patch 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 esportandoi 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 maxmemory-reserved della cache.

In che modo un failover influisce sull'applicazione client?

Le applicazioni client potrebbero riscontrare alcuni errori dalla cache di Azure per Redis. Il numero di errori rilevati da un’applicazione client dipende dal numero di operazioni in sospeso nella 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 di socket

Il numero e il tipo di eccezioni dipendono da dove si trova la richiesta nel percorso del codice nel momento in cui la cache chiude le relative connessioni. Ad esempio, un'operazione che invia una richiesta ma non ha ricevuto una risposta quando si verifica il failover potrebbe ricevere 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 mettere gli oggetti della libreria in uno stato di irreversibilità. 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 di Azure per Redis 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 canale AzureRedisEvents è in genere un'aggiunta semplice all'applicazione client. Per altre informazioni sugli eventi di manutenzione, vedere AzureRedisEvents.

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 di hosting per aggiornare i componenti di rete o rimuovere le autorizzazioni.

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

No, la manutenzione non viene visualizzata da nessuna parte dell'integrità 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 di rete/configurazione client

Alcune modifiche alla configurazione della rete lato client possono attivare nessun errore di 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 di Azure per Redis.

Creare resilienza integrata

Non è possibile evitare completamente i failover. Invece è bene scrivere 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:

• Modelli di affidabilità - Modelli di progettazione per il cloud
• Linee guida per la ripetizione dei tentativi per i servizi di Azure - Procedure consigliate per le applicazioni cloud
• Implementare nuovi tentativi con backoff esponenziale

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 al fine di applicare le patch di runtime Redis durante specifiche finestre settimanali. Tali 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.

Contenuto correlato

• Aggiornare il canale e pianificare gli aggiornamenti
• Testare la resilienza dell'applicazione usando un riavvio
• Configurare riserve e criteri di memoria