Condividi tramite

Failover e applicazione di patch per Redis gestito di Azure (anteprima)

  • Articolo

Per creare applicazioni client resilienti e efficaci, è fondamentale comprendere il failover nel servizio Redis gestito di Azure (anteprima). 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 Redis gestiti di Azure.

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 Azure Managed Redis.

Riepilogo rapido dell'architettura della cache

Diagramma che mostra l'architettura dell'offerta Redis gestita di Azure.

Una cache viene costruita da più macchine virtuali con indirizzi IP separati e privati. Ogni macchina virtuale (o "node") esegue più processi del server Redis (denominati "partizioni") in parallelo. Più partizioni consentono un utilizzo più efficiente delle vCPU in ogni macchina virtuale e prestazioni superiori. Non tutte le partizioni Redis primarie si trovano nello stesso nodo/macchina virtuale. Le partizioni primarie e di replica vengono invece distribuite in entrambi i nodi. Poiché le partizioni primarie usano più risorse della CPU rispetto alle partizioni di replica, questo approccio consente l'esecuzione in parallelo di più partizioni primarie. Ogni nodo ha un processo proxy ad alte prestazioni per gestire le partizioni, gestire la gestione delle connessioni e attivare la riparazione automatica. Una partizione potrebbe essere inattiva mentre le altre rimangono disponibili.

Per informazioni dettagliate sull'architettura redis gestita di Azure, vedere qui.

Spiegazione di un failover

Un failover si verifica quando una o più partizioni di replica si alzano di livello per diventare partizioni primarie e le partizioni primarie precedenti chiudono le connessioni esistenti. 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 in uno o più nodi del cluster. Le partizioni di replica nei nodi rimanenti verranno alzate di livello a primario per mantenere la disponibilità, ma il processo richiede più tempo. Una partizione di replica deve prima rilevare che la partizione primaria non è disponibile prima di poter avviare il processo di failover. La partizione 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 Redis gestito 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 crea nuove macchine virtuali aggiornate per sostituire tutte le macchine virtuali sottoposte a patch.
  2. Promuove quindi una delle nuove macchine virtuali come leader del cluster.
  3. Uno per uno, tutti i nodi a cui viene applicata l'applicazione di patch vengono rimossi dal cluster. Tutte le partizioni in queste macchine virtuali verranno abbassate di livello e ne verrà eseguita la migrazione a una delle nuove macchine virtuali.
  4. Infine, tutte le macchine virtuali sostituite vengono eliminate.

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 per la cache. È 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 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.

In che modo un failover influisce sull'applicazione client?

Le applicazioni client potrebbero ricevere alcuni errori dall'istanza di Redis gestita di Azure. 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.

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 in Integrità dei servizi nel portale o in un'altra posizione.

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 Redis gestito di Azure.

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:

Contenuto correlato