Disponibilità elevata e ripristino di emergenza
Come per tutti i sistemi cloud, possono verificarsi interruzioni non pianificate che comportano la disattivazione di un'istanza di macchine virtuali (VM), una zona di disponibilità o un'intera area di Azure. È consigliabile che i clienti dispongano di un piano per gestire interruzioni della zona o dell'area.
Questo articolo presenta le informazioni destinate ai clienti e relative alla creazione di un piano di continuità aziendale e ripristino di emergenza per la cache di Azure per Redis o l'implementazione di Cache Redis Enterprise.
Diverse opzioni a disponibilità elevata sono presenti nei livelli Standard, Premium ed Enterprise:
| Opzione | Descrizione | Disponibilità | Standard | Premium | Enterprise |
|---|---|---|---|---|---|
| Replica standard | Configurazione replicata a doppio nodo in un singolo data center con failover automatico | 99,9% (vedi i dettagli) | ✔ | ✔ | ✔ |
| Ridondanza della zona | Configurazione replicata a più nodi tra zone di disponibilità, con failover automatico | 99,9% in Premium; 99,99% in Enterprise (vedere i dettagli) | - | ✔ | ✔ |
| Replica geografica | Istanze della cache collegate in due aree, con failover controllato dall'utente | Premium; Enterprise (vedere i dettagli) | - | Passive | Attive |
| Importazione/Esportazione | Snapshot temporizzato dei dati nella cache. | 99,9% (vedi i dettagli) | - | ✔ | ✔ |
| Persistenza | Salvataggio periodico dei dati nell'account di archiviazione. | 99,9% (vedi i dettagli) | - | ✔ | Anteprima |
Replica standard per disponibilità elevata
Livelli applicabili: Standard, Premium, Enterprise, Enterprise Flash
Consigliato per: disponibilità elevata
Cache di Azure per Redis ha un'architettura a disponibilità elevata che garantisce il funzionamento dell'istanza gestita, anche quando le interruzioni influiscono sulle macchine virtuali sottostanti. Che si tratti di interruzione pianificata o di interruzioni non pianificate, la cache di Azure per Redis offre percentuali di disponibilità maggiori rispetto a quelle raggiungibili ospitando Redis in una singola macchina virtuale.
Una cache di Azure per Redis nei livelli applicabili viene eseguita su una coppia di server Redis per impostazione predefinita. I due server sono ospitati in macchine virtuali dedicate. Redis open source consente a un solo server di gestire le richieste di scrittura dei dati.
Con la cache di Azure per Redis, un server è il nodo primario, mentre l'altro è la replica. Dopo il provisioning dei nodi del server, la cache di Azure per Redis assegna i ruoli primari e di replica a tali nodi. Il nodo primario è in genere responsabile della manutenzione delle richieste di scrittura e lettura dai client. In un'operazione di scrittura, esegue il commit di una nuova chiave e di un aggiornamento della chiave alla memoria interna e risponde immediatamente al client. Inoltra l'operazione alla replica in modo asincrono.
Nota
In genere, un'applicazione client della cache di Azure per Redis comunica con il nodo primario in una cache per tutte le richieste di lettura e scrittura. Alcuni client possono essere configurati per la lettura dal nodo di replica.
Se il nodo primario in una cache non è disponibile, la replica si promuove automaticamente per diventare il nuovo nodo primario. Questo processo viene chiamato failover. Un failover è costituito solo da due nodi, primario/replica, scambio di ruoli, replica/primario, con uno dei nodi che potrebbero andare offline per alcuni minuti. Nella maggior parte dei failover, i nodi primario e di replica coordinano l'handover così che non vi sia praticamente nessun istante senza un nodo primario.
L'ex nodo primario va brevemente offline per ricevere gli aggiornamenti dal nuovo nodo primario. Quindi, quello che è ora il nodo replica torna online e rielabora la cache completamente sincronizzata. La cosa importante è che quando un nodo non è disponibile, si tratta di una condizione temporanea, perché torna online.
Una sequenza di failover tipica è simile a quella seguente, quando un nodo primario deve arrestarsi per manutenzione:
- I nodi primario e di replica negoziano un failover coordinato e si scambiano i ruoli.
- Il nodo replica (in precedenza primario) va offline per un riavvio.
- Pochi secondi o minuti dopo, la replica torna online.
- Il nodo replica sincronizza i dati con il nodo primario.
Un nodo primario può andare offline come parte di un'attività di manutenzione pianificata, ad esempio nel caso di un aggiornamento del software Redis o del sistema operativo. Può anche smettere di funzionare a causa di eventi non pianificati, ad esempio errori nell'hardware, nel software o nella rete sottostanti. Il failover e l'applicazione di patch per la cache di Azure per Redis fornisce una spiegazione dettagliata sui tipi di failover. Una cache di Azure per Redis si trova a dover affrontare molti failover nel corso del suo ciclo di vita. La progettazione dell'architettura a disponibilità elevata rende queste modifiche all'interno di una cache il più trasparente possibile per i client.
Inoltre, la cache di Azure per Redis offre anche più nodi replica nel livello Premium. Una cache con più repliche può essere configurata con un massimo di tre nodi replica. La disponibilità di più repliche in genere migliora la resilienza perché si dispone di nodi di backup del nodo primario. Anche con più repliche, un'istanza di cache di Azure per Redis può comunque essere gravemente influenzata da un data center o da un'interruzione della zona di disponibilità. È possibile aumentare la disponibilità della cache usando più repliche con ridondanza della zona.
Ridondanza della zona
Livelli applicabili: Premium, Enterprise, Enterprise Flash
Consigliato per: disponibilità elevata, ripristino di emergenza - all'interno dell'area
Cache di Azure per Redis supporta le configurazioni con ridondanza della zona nei livelli Premium ed Enterprise. Una cache con ridondanza della zona può inserire i nodi in zone di disponibilità di Azure diverse all’interno della stessa area. Elimina il data center o l'interruzione della zona di disponibilità come singolo punto di errore e aumenta la disponibilità complessiva della cache. Vedere questo articolo per informazioni su come effettuarne la configurazione.
Se una cache è configurata per l'uso di due o più zone come descritto in precedenza nell'articolo, i nodi della cache vengono creati in zone diverse. Quando una zona diventa inattiva, i nodi della cache in altre zone sono disponibili per mantenere la cache funzionante come di consueto.
Cache di Azure per Redis supporta le configurazioni con ridondanza della zona nei livelli Premium ed Enterprise. Una cache con ridondanza della zona può inserire i nodi in zone di disponibilità di Azure diverse all’interno della stessa area. Elimina l'interruzione del data center o della zona di disponibilità come singolo punto di errore e aumenta la disponibilità complessiva della cache.
Livello Premium
Il diagramma seguente illustra la configurazione con ridondanza della zona per il livello Premium:
La cache di Azure per Redis distribuisce i nodi in una cache con ridondanza della zona in modo round robin sulle zone di disponibilità selezionate. Determina anche il nodo che funge inizialmente da primario.
Esperienza di riduzione della zona per il livello Premium
Una cache con ridondanza della zona fornisce un failover automatico. Quando il nodo primario corrente non è disponibile, una delle repliche assume il controllo. L'applicazione potrebbe riscontrare tempi di risposta della cache superiori se il nuovo nodo primario si trova in una zona di disponibilità diversa. Le zone di disponibilità sono geograficamente separate. Il passaggio da una zona di disponibilità a un’altra modifica la distanza fisica tra la posizione in cui sono ospitate l'applicazione e la cache. Questa modifica influisce sulle latenze di rete round trip dall'applicazione alla cache. La latenza aggiuntiva dovrebbe rientrare in un intervallo accettabile per la maggior parte delle applicazioni. È consigliabile testare l'applicazione per assicurarsi che sia efficace con una cache con ridondanza della zona.
Livelli Enterprise ed Enterprise Flash
Una cache in entrambi i livelli Enterprise viene eseguita in un clusterRedis Enterprise. Richiede sempre un numero dispari di nodi del server per formare un quorum. Per impostazione predefinita, ha tre nodi, ciascuno dei quali è ospitato in una macchina virtuale dedicata.
- Una cache Enterprise ha due nodi dati di dimensioni uguali e un nodo quorum più piccolo.
- Una cache Enterprise Flash ha tre nodi dati di dimensioni uguali.
Il cluster Enterprise divide internamente i dati della cache di Azure per Redis in partizioni. Di ogni partizione ne è presente una primaria e almeno una replica. Ogni nodo dati contiene una o più partizioni. Il cluster Enterprise garantisce che partizioni primarie o repliche non vengano mai collocate nello stesso nodo dati. Le partizioni replicano i dati in modo asincrono dalle primarie alle repliche corrispondenti.
Esperienza di riduzione della zona per i livelli Enterprise
Quando un nodo dati diventa non disponibile o si verifica una suddivisione di rete, viene eseguito un failover simile a quello descritto in Replica standard. Il cluster Enterprise usa un modello basato su quorum per determinare quali nodi sopravvissuti fanno parte di un nuovo quorum. Promuove anche le partizioni replica all'interno di tali nodi a partizioni primarie in base alle esigenze.
Disponibilità a livello di area
Le cache del livello Premium con ridondanza della zona sono disponibili nelle aree seguenti:
| Americhe | Europa | Medio Oriente | Africa | Asia Pacifico |
|---|---|---|---|---|
| Brasile meridionale | Francia centrale | Qatar centrale | Sudafrica settentrionale | Australia orientale |
| Canada centrale | Germania centro-occidentale | India centrale | ||
| Stati Uniti centrali | Europa settentrionale | Giappone orientale | ||
| Stati Uniti orientali | Norvegia orientale | Corea centrale | ||
| Stati Uniti orientali 2 | Regno Unito meridionale | Asia sud-orientale | ||
| Stati Uniti centro-meridionali | Europa occidentale | Asia orientale | ||
| US Gov Virginia | Svezia centrale | Cina settentrionale 3 | ||
| West US 2 | Svizzera settentrionale | |||
| Stati Uniti occidentali 3 |
Le cache dei livelli Enterprise ed Enterprise Flash con ridondanza della zona sono disponibili nelle aree seguenti:
| Americhe | Europa | Medio Oriente | Africa | Asia/Pacifico |
|---|---|---|---|---|
| Canada centrale* | Europa settentrionale | Australia orientale | ||
| Stati Uniti centrali* | Regno Unito meridionale | India centrale | ||
| Stati Uniti orientali | Europa occidentale | Asia sud-orientale | ||
| Stati Uniti orientali 2 | Giappone orientale* | |||
| Stati Uniti centro-meridionali | Asia orientale* | |||
| West US 2 | ||||
| Stati Uniti occidentali 3 | ||||
| Brasile meridionale |
* Livello Enterprise Flash non disponibile in questa regione.
Ridistribuzione e migrazione della zona di disponibilità
Attualmente, l'unico modo per convertire la cache da una configurazione senza zone di disponibilità a una configurazione con zone di disponibilità consiste nel ridistribuire la cache. Per informazioni su come ridistribuire la cache corrente, vedere Eseguire la migrazione di un'istanza di cache di Azure per Redis al supporto della zona di disponibilità.
Persistenza
Livelli applicabili: Premium, Enterprise (anteprima), Enterprise Flash (anteprima)
Consigliato per: Durabilità dei dati
Poiché i dati della cache vengono archiviati in memoria, un errore raro e non pianificato di più nodi può causare l'eliminazione di tutti i dati. Per evitare di perdere completamente i dati, la persistenza di Redis consente di acquisire snapshot periodici dei dati in memoria e di archiviarli nell'account di archiviazione. Se si verifica un errore in più nodi che causano la perdita di dati, la cache carica lo snapshot dall'account di archiviazione. Per altre informazioni, vedere Configurare la persistenza dei dati per l’istanza Premium della cache di Azure per Redis.
Account di archiviazione per la persistenza
Valutare la possibilità di scegliere un account di archiviazione con ridondanza geografica per garantire la disponibilità elevata dei dati persistenti. Per altre informazioni, vedere Ridondanza di Archiviazione di Azure.
Importazione/Esportazione
Livelli applicabili: Premium, Enterprise, Enterprise Flash
Consigliato per: Ripristino di emergenza
La cache Redis di Azure supporta l'opzione per importare ed esportare file di database Redis (RDB) per garantire la portabilità dei dati. Consente di importare dati nella cache di Azure per Redis o di esportare dati dalla cache di Azure per Redis usando uno snapshot RDB. Lo snapshot RDB da una cache Premium viene esportato in un BLOB all’interno di un account di archiviazione di Azure. È possibile creare uno script per attivare periodicamente l'esportazione nell'account di archiviazione. Per altre informazioni, vedere Importare ed esportare dati nella cache di Azure per Redis.
Account di archiviazione per l'esportazione
Valutare la possibilità di scegliere un account di archiviazione con ridondanza geografica per garantire la disponibilità elevata dei dati esportati. Per altre informazioni, vedere Ridondanza di Archiviazione di Azure.
Replica geografica passiva
Livelli applicabili: Premium
Consigliato per: Ripristino di emergenza - regione singola
La replica geografica è un meccanismo per collegare due o più istanze di cache di Azure per Redis, che in genere si estendono su due aree di Azure. La replica geografica è progettata principalmente per il ripristino di emergenza inter-area. Due istanze della cache di livello Premium sono connesse tramite la replica geografica in modo da fornire letture e scritture nella cache primaria e che i dati vengano replicati nella cache secondaria.
Per altre informazioni su come effettuare la configurazione, vedere Configurare la replica geografica per le istanze di cache di Azure per Redis Premium.
Se l'area che ospita la cache primaria diventa inattiva, è necessario avviare il failover: prima di tutto, scollegando la cache secondaria, quindi aggiornando l'applicazione in modo che punti alla cache secondaria per letture e scritture.
Replica geografica attiva
Livelli applicabili: Enterprise, Enterprise Flash
Consigliato per: disponibilità elevata, ripristino di emergenza - regioni multiple
I livelli Enterprise supportano una forma più avanzata di replica geografica denominata replica geografica attiva che offre disponibilità più elevata e ripristino di emergenza intra-aree in più aree. Il software Enterprise della cache di Azure per Redis usa tipi di dati replicati privi di conflitti per supportare le scritture in più istanze della cache, unisce le modifiche e risolve i conflitti. È possibile aggiungere fino a cinque istanze della cache di livello Enterprise in diverse aree di Azure per formare un gruppo di replica geografica.
Un'applicazione che utilizza una cache di questo tipo è in grado di leggere e scrivere in una qualsiasi delle istanze della cache con distribuzione geografica tramite gli endpoint corrispondenti. L'applicazione deve usare quella che è più vicina a ciascuna istanza dell'applicazione, offrendo la latenza più bassa. Per ulteriori informazioni, vedere Configurare la replica geografica attiva per le istanze di cache di Azure per Redis Enterprise
Se un'area di una delle cache nel gruppo di replica diventa inattiva, l'applicazione deve passare a un'altra area disponibile.
Quando una cache nel gruppo di replica non è disponibile, è consigliabile monitorare l'utilizzo della memoria per le altre cache nello stesso gruppo di replica. Mentre una delle cache è inattiva, tutte le altre cache del gruppo di replica iniziano a salvare i metadati che non possono condividere con la cache inattiva. Se l'utilizzo della memoria per le cache disponibili inizia a crescere a una frequenza elevata dopo che una delle cache è diventata inattiva, è consigliabile scollegare la cache non disponibile dal gruppo di replica.
Per altre informazioni sullo scollegamento forzato, vedere Forzare lo scollegamento in caso di interruzione dell'area.
Eliminare e ricreare la cache
Livelli applicabili: Standard, Premium, Enterprise, Enterprise Flash
Se si verifica un'interruzione a livello di area, provare a ricreare la cache in un'area diversa e aggiornare l'applicazione per connettersi alla nuova cache. È importante comprendere che i dati andranno persi durante un'interruzione a livello di area. Il codice dell'applicazione deve essere resiliente alla perdita di dati.
Una volta ripristinata l'area interessata, la cache di Azure per Redis non disponibile viene ripristinata automaticamente e resa nuovamente riutilizzabile. Per altre strategie utili a spostare la cache in un'area diversa, vedere Spostare le istanze della cache di Azure per Redis in aree diverse.
Passaggi successivi
Altre informazioni su come configurare le opzioni di disponibilità elevata della cache di Azure per Redis.