Affidabilità in Azure Managed Redis

Redis gestito di Azure è un servizio di Azure completamente gestito basato su Redis Enterprise. Offre un'archiviazione dei dati in memoria ad alte prestazioni per le applicazioni ed è progettata per carichi di lavoro aziendali che richiedono una latenza ultra bassa, una velocità effettiva elevata e strutture di dati avanzate.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere Azure Redis gestito resiliente a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità e interruzioni della regione. Descrive anche le strategie di backup e il contratto di servizio.

Raccomandazioni per la distribuzione di produzione

Per garantire un'elevata affidabilità per le istanze redis gestite di Azure di produzione, è consigliabile:

Panoramica dell'architettura di affidabilità

Questa sezione descrive alcuni degli aspetti importanti del funzionamento del servizio più rilevanti dal punto di vista dell'affidabilità. La sezione presenta l'architettura logica, che include alcune delle risorse e delle funzionalità distribuite e usate. Illustra anche l'architettura fisica, che fornisce informazioni dettagliate sul funzionamento del servizio sotto le quinte.

Architettura logica

Redis gestito di Azure è basato su Redis Enterprise e offre affidabilità tramite configurazioni a disponibilità elevata e funzionalità di replica.

Si distribuisce un'istanza di Redis gestita di Azure, nota anche come istanza della cache o cache. Le applicazioni client archiviano e interagiscono con i dati all'interno della cache usando le API Redis.

Architettura fisica

Quando si pianifica la resilienza in Azure Managed Redis, è necessario comprendere i concetti chiave dei nodi e delle partizioni.

• Nodi: Ogni istanza della cache è costituita da nodi, ovvero macchine virtuali. Ogni macchina virtuale funge da unità di calcolo indipendente nel cluster. Le macchine virtuali non vengono visualizzate o gestite direttamente. La piattaforma crea automaticamente istanze, monitora l'integrità dell'istanza e sostituisce tutte le istanze che diventano non integre. Questo set di macchine virtuali costituisce un cluster.

  È possibile configurare l'istanza per la disponibilità elevata. Quando si usa la disponibilità elevata, Azure Managed Redis garantisce che l'istanza di disponga di almeno due nodi e di replica automaticamente i dati tra di essi. Nelle aree con zone di disponibilità, il servizio inserisce i nodi in zone di disponibilità diverse. Per altre informazioni, vedere Resilienza agli errori della zona di disponibilità.

  Il servizio astrae il numero specifico di nodi in ogni configurazione per evitare complessità e garantire configurazioni ottimali.

• Frammenti: Ogni nodo esegue più processi del server Redis noti come partizioni. Ogni partizione gestisce un subset dei dati della cache. Quando si imposta la cache per la disponibilità elevata, le partizioni distribuiscono e replicano automaticamente tra i nodi. È possibile specificare un criterio del cluster, che determina la modalità di distribuzione delle partizioni tra i nodi.

Per altre informazioni, vedere Architettura di Redis gestita di Azure e Failover e applicazione di patch per Redis gestito di Azure.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Seguire queste raccomandazioni per la gestione degli errori temporanei quando si usa Redis gestito di Azure:

• Usare le configurazioni SDK che riprovano automaticamente quando si verificano errori temporanei e applicano periodi di backoff e timeout appropriati. Prendere in considerazione l'uso del modello di riprova e del modello Circuit Breaker nelle applicazioni.

• Progettare modelli cache-aside, in cui l'applicazione può continuare a funzionare con prestazioni ridotte eseguendo il fallback all'archivio dati primario quando Redis diventa temporaneamente non disponibile.

Resilienza ai guasti delle zone di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di un'area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

È possibile rendere le istanze della cache Redis gestite di Azure a ridondanza di zona, che distribuiscono automaticamente i nodi della cache tra più zone di disponibilità all'interno di un'area. La ridondanza della zona riduce il rischio che un data center o un'interruzione della zona di disponibilità renda la cache non disponibile.

Per rendere ridondante una zona della cache, è necessario distribuirla in un'area supportata e impostarla per l'uso della configurazione a disponibilità elevata. Nelle aree senza zone di disponibilità, la configurazione a disponibilità elevata crea ancora almeno due nodi, ma non vengono posizionati in zone separate.

Il diagramma seguente mostra una cache a disponibilità zonale con due nodi, ciascuno in una zona distinta.

Requisiti

• Supporto per l'area: È possibile distribuire cache Redis gestite di Azure con ridondanza della zona in qualsiasi area che supporta le zone di disponibilità e dove è disponibile il servizio. Per l'elenco delle aree che supportano le zone di disponibilità, vedere Aree di Azure con zone di disponibilità. Per l'elenco delle aree che supportano Redis gestito di Azure, vedere Disponibilità del prodotto in base all'area.

• Configurazione a disponibilità elevata: È necessario usare la configurazione a disponibilità elevata nella cache perché sia ridondante a livello di zona.

• Livelli: Tutti i livelli Redis gestiti di Azure supportano le zone di disponibilità.

Costo

La ridondanza zonale richiede di configurare la cache per l'alta disponibilità, che implementa almeno due nodi per la cache. La configurazione a disponibilità elevata costa più di una configurazione non a disponibilità elevata. Per altre informazioni, vedere Prezzi di Redis gestiti di Azure.

Configurare il supporto delle zone di disponibilità

• Creare una nuova istanza con ridondanza della zona. Quando si crea una nuova istanza di Redis gestita di Azure, usare la configurazione a disponibilità elevata e distribuirla in un'area che supporta le zone di disponibilità. L'istanza include la ridondanza della zona per impostazione predefinita, senza alcuna configurazione aggiuntiva necessaria.

  Per altre informazioni, vedere Creare un'istanza di Redis gestita di Azure.

• Rendere ridondante una zona dell'istanza esistente. Per rendere ridondante una zona dell'istanza di Redis gestita di Azure esistente, distribuirla in un'area che supporta le zone di disponibilità e configurare la disponibilità elevata nella cache.

• Disattivare la ridondanza delle zone. Non è possibile disattivare la ridondanza della zona nelle istanze esistenti perché non è possibile invertire la disponibilità elevata dopo l'applicazione a una cache.

Pianificazione e gestione della capacità

Durante un evento di riduzione della zona, l'istanza potrebbe avere meno risorse disponibili per gestire il carico di lavoro. Se l'istanza riscontra spesso pressioni sulle risorse e necessita di prepararsi per un guasto della zona di disponibilità, considerare uno dei seguenti approcci:

• Sovraprovisionare l'istanza. Selezionare un livello di prestazioni superiore a quello necessario per consentire all'istanza di tollerare una perdita di capacità e continuare a funzionare senza prestazioni ridotte. Per altre informazioni, vedere Gestire la capacità tramite overprovisioning e Ridimensionare un'istanza di Redis gestita di Azure.

• Usare la replica geografica attiva. È possibile distribuire più istanze in aree diverse e configurare la replica geografica attiva per distribuire il carico tra tali istanze separate.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando una cache Redis gestita è con ridondanza della zona e tutte le zone di disponibilità funzionano normalmente:

• Routing del traffico tra zone: Redis gestito di Azure distribuisce gli shard tra i nodi secondo la politica del cluster. I criteri del cluster determinano anche il modo in cui il traffico viene instradato a ogni nodo. La ridondanza della zona non cambia il modo in cui il servizio instrada il traffico.

• Replica dei dati tra zone: Redis gestito di Azure replica automaticamente le partizioni tra i nodi usando la replica asincrona. In genere si misura il ritardo di replica tra le partizioni in secondi, ma la durata esatta dipende dal carico di lavoro della cache. Gli scenari con un numero elevato di operazioni di scrittura e di rete in genere riscontrano un ritardo di replica superiore.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando una cache Redis gestita è ridondante nelle zone e una o più zone di disponibilità diventano non disponibili.

• Rilevamento e risposta: Redis gestito di Azure è responsabile del rilevamento di un errore in una zona di disponibilità. Non è necessario eseguire alcuna operazione per avviare un failover di zona.

• Notifica: Microsoft non invia automaticamente una notifica quando una zona è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi eventuali errori di zona, ed è possibile configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

• Richieste attive: Il servizio potrebbe eliminare le richieste in anteprima e le applicazioni devono riprovare. Le applicazioni devono implementare la logica di ripetizione dei tentativi per gestire queste interruzioni temporanee.

• Perdita di dati prevista: Tutti i dati che non sono stati replicati nelle partizioni in un'altra zona potrebbero andare persi durante un errore di zona. In genere si misura la quantità di perdita di dati in secondi, ma dipende dal ritardo di replica.

• Tempo di inattività previsto: Un breve periodo di inattività, in genere da 10 a 15 secondi, può verificarsi mentre le partizioni eseguono il failover ai nodi in zone sane. Per altre informazioni sul processo di failover non pianificato, vedere Spiegazione di un failover. Quando si progettano applicazioni, seguire le procedure per la gestione degli errori temporanei.

• Reindirizzamento del traffico: Redis gestito di Azure reindirizza automaticamente il traffico ai nodi in zone integre.

Ripristino della zona

Quando la zona di disponibilità interessata viene ripristinata, Azure Managed Redis ripristina automaticamente le operazioni in tale zona. La piattaforma Azure gestisce completamente questo processo e non richiede alcun intervento del cliente.

Verifica dei guasti di zona

Azure Managed Redis gestisce completamente l'instradamento del traffico, il failover e il failback per i guasti delle zone, quindi non è necessario verificare i processi di guasto delle zone di disponibilità o fornire ulteriore input.

Resilienza agli errori a livello di area

Redis gestito di Azure offre supporto per più aree native tramite la replica geografica attiva, che consente di collegare più istanze di Redis gestite di Azure in diverse aree di Azure in un singolo gruppo di replica. È quindi possibile configurare un approccio di failover personalizzato tra le istanze.

Replica geografica attiva

Quando si usa la replica geografica attiva, le applicazioni possono leggere e scrivere in qualsiasi istanza della cache nel gruppo, con modifiche sincronizzate automaticamente in tutte le aree. Il servizio supporta modelli di replica attivi-attivi in cui ogni area può gestire simultaneamente operazioni di lettura e scrittura. Quando si verificano conflitti a causa di scritture simultanee in aree diverse, il servizio li risolve automaticamente usando algoritmi di risoluzione dei conflitti predeterminati senza richiedere l'intervento manuale. Questo approccio offre resilienza agli errori dell'area mantenendo al contempo l'accesso a bassa latenza per le applicazioni distribuite a livello globale.

Il diagramma seguente illustra due istanze della cache in aree diverse all'interno dello stesso gruppo di replica geografica attiva, insieme alle applicazioni client che si connettono a ogni istanza della cache.

Sei responsabile della configurazione delle applicazioni client per reindirizzare le richieste a un'istanza funzionante in caso di errore di un'istanza regionale. Il diagramma seguente illustra come un'applicazione può reindirizzare le proprie richieste a un'istanza della cache funzionante quando l'istanza abitualmente utilizzata si guasta.

Requisiti

• Supporto per l'area: È possibile configurare la replica geografica attiva di Redis gestita di Azure tra qualsiasi area di Azure in cui è disponibile il servizio.

• Configurazione dell'istanza: La replica geografica attiva richiede istanze di Redis gestite di Azure che usano lo stesso livello e le stesse dimensioni in ogni area partecipante. Tutte le istanze della cache in un gruppo di replica devono usare impostazioni identiche, incluse le opzioni di persistenza, i moduli e i criteri di clustering.

• Altri requisiti: Le istanze della cache devono soddisfare altri requisiti, inclusi i moduli usati. Questi requisiti influiscono su come ridimensionare le istanze della cache. Per altre informazioni, vedere Prerequisiti per la replica geografica attiva.

Considerazioni

• Responsabilità del failover: Quando si utilizza la replica geografica attiva, si è responsabili del failover tra le istanze della cache. Preparare l'applicazione per gestire il failover. Il failover comporta la preparazione e potrebbe richiedere più passaggi. Per ulteriori informazioni, vedere Force-unlink durante un'interruzione della regione.

• Coerenza finale: Progettare applicazioni per gestire gli scenari di coerenza finale perché le modifiche possono richiedere tempo per propagarsi in tutte le aree, a seconda delle condizioni di rete e della distanza geografica. Durante le interruzioni dell'area, potrebbero verificarsi più incoerenze dei dati fino al termine del ripristino della connettività e della sincronizzazione.

Costo

Quando si configura la replica geografica attiva, si paga per ogni istanza di Redis gestita di Azure in ogni area all'interno del gruppo di replica. È anche possibile che vengano addebitati addebiti per il trasferimento dei dati per il traffico di replica tra aree. Per altre informazioni, vedere Prezzi di Redis gestiti di Azure e Dettagli sui prezzi della larghezza di banda.

Configurare il supporto per più aree

• Creare una nuova istanza della cache con replica geografica. Configurare la replica geografica attiva quando si effettua il provisioning della cache specificando un gruppo di replica e collegando più istanze. Per altre informazioni, vedere Creare o aggiungere un gruppo di replica geografica attivo.

• Aggiungere un'istanza della cache esistente a un gruppo di replica geografica. È possibile aggiungere un'istanza della cache esistente a un gruppo di replica geografica attivo.

  Quando si aggiunge un'istanza esistente a un gruppo di replica geografica attiva, la piattaforma deve cancellare i dati nell'istanza e si verifica un breve tempo di inattività. Qualora possibile, pianificare di impostare la replica geografica attiva quando si impostano istanze della cache.

  Per altre informazioni, vedere Aggiungere un'istanza esistente a un gruppo di replica geografica attivo.

• Disattivare la replica geografica in un'istanza della cache. Rimuovere un'istanza da un gruppo di replica geografica eliminando l'istanza della cache. Le istanze rimanenti regolano automaticamente le impostazioni.

Pianificazione e gestione della capacità

Durante un evento di inattività della regione, le altre istanze potrebbero riscontrare un carico più elevato. Se un'istanza viene spesso eseguita vicino ai limiti delle risorse ed è necessario prepararsi per i requisiti di capacità maggiori durante un guasto della regione, prendere in considerazione overprovisioning dell'istanza. Per altre informazioni, vedere Ridimensionare un'istanza di Redis gestita di Azure.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando si configurano istanze per l'uso della replica geografica attiva e tutte le aree funzionano normalmente.

• Routing del traffico tra aree: L'utente è responsabile della configurazione delle applicazioni per la connessione a un'istanza della cache specifica. Le applicazioni possono connettersi a qualsiasi istanza della cache nel gruppo di replica ed eseguire operazioni di lettura e scrittura. L'applicazione gestisce il routing del traffico, che consente di indirizzare i client all'area più vicina per una latenza minima. Azure Managed Redis non instrada automaticamente il traffico tra aree.

• Replica dei dati tra aree: Il servizio usa la replica asincrona tra aree per mantenere la coerenza finale. Esegue immediatamente il commit delle operazioni di scrittura nell'area locale e quindi le propaga in altre aree in secondo piano. I tipi di dati replicati senza conflitti assicurano che il servizio unisce automaticamente le scritture simultanee in aree diverse.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando si configurano istanze per l'uso della replica geografica attiva e si verifica un'interruzione in un'area.

• Rilevamento e risposta: È responsabilità dell'utente rilevare l'errore di un'istanza della cache e decidere quando eseguire il failover. È possibile monitorare l'integrità di un cluster con replica geografica, che consente di decidere quando iniziare il failover. Per altre informazioni, vedere Metrica di replica geografica.

  Il failover richiede l'esecuzione di più passaggi. Per ulteriori informazioni, vedere Force-unlink durante un'interruzione della regione.

• Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi gli eventuali errori dell'area e configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

  Puoi anche monitorare lo stato di integrità di ogni istanza.

  Per monitorare l'integrità della relazione di replica geografica, usare la metrica stato di salute della replica geografica. La metrica ha sempre un valore ( 1 integro) o 0 (non integro). Configurare gli avvisi di Monitoraggio di Azure in questa metrica per identificare quando le istanze potrebbero non essere sincronizzate.

• Richieste attive: Il servizio termina le richieste all'area non riuscita e la logica di failover dell'applicazione deve gestirle. Le applicazioni devono implementare criteri di ripetizione dei tentativi che possono reindirizzare il traffico alle cache integre.

• Perdita di dati prevista: La replica asincrona tra aree può comportare la perdita di scritture recenti nell'area non riuscita se tali scritture non sono state replicate in altre aree. La quantità di potenziale perdita di dati dipende dal ritardo di replica al momento dell'errore. Per ulteriori informazioni, vedere Active-active geo-distributed Redis e Considerazioni sulla coerenza e la perdita di dati in un errore di area del database replicato senza conflitti (CRDB).

• Tempo di inattività previsto: Le applicazioni riscontrano tempi di inattività solo per la durata necessaria per rilevare l'errore e reindirizzare il traffico alle aree integre. Questo tempo di inattività varia in genere da secondi a pochi minuti e dipende dalla configurazione del controllo integrità e del failover dell'applicazione.

• Reindirizzamento del traffico: L'utente è responsabile dell'implementazione della logica nelle applicazioni per rilevare gli errori dell'area e instradare il traffico alle aree integre. È possibile implementare questa logica tramite controlli di integrità, modelli di interruttore o soluzioni di bilanciamento del carico esterne.

Ripristino della regione

Quando un'area non riuscita viene ripristinata, Azure Managed Redis reintegra automaticamente le istanze in tale area nel gruppo di replica geografica attiva senza l'intervento dell'utente. Il servizio sincronizza automaticamente i dati da istanze integre. Durante questo processo, le istanze ripristinate sincronizzano gradualmente le modifiche che si sono verificate durante l'interruzione. Al termine della sincronizzazione, le istanze ripristinate diventano completamente attive e possono gestire le operazioni di lettura e scrittura.

Sei responsabile della riconfigurazione della tua applicazione per instradare il traffico all'istanza della regione ripristinata.

Testare gli errori dell'area

Testare regolarmente le procedure di failover dell'applicazione. L'applicazione deve essere in grado di eseguire il failover tra istanze e soddisfare i requisiti aziendali per i tempi di inattività durante la transizione. Testare anche i processi di risposta complessivi, inclusi eventuali riconfigurazioni di firewall e altre infrastrutture e il processo di ripristino.

Resilienza alla manutenzione del servizio

Redis gestito di Azure gestisce gli aggiornamenti regolari del servizio e altre attività di manutenzione.

Durante la manutenzione, Azure Managed Redis crea automaticamente nuovi nodi ed esegue il failover. Le applicazioni client potrebbero riscontrare interruzioni della connessione e altri errori temporanei. Le applicazioni devono implementare la logica di ripetizione dei tentativi per gestire queste interruzioni temporanee.

Per ulteriori informazioni sui processi di manutenzione di Redis gestito di Azure, vedere Failover e applicazione di patch per Redis gestito di Azure.

Backup e ripristino

Redis gestito di Azure offre funzionalità di persistenza dei dati e di backup per proteggersi da scenari di perdita di dati che potrebbero non essere affrontate da altre funzionalità di affidabilità. I backup proteggono da scenari come danneggiamento dei dati, eliminazione accidentale o errori di configurazione.

• Persistenza dei dati: Per impostazione predefinita, Azure Managed Redis archivia tutti i dati della cache in memoria. Il servizio può facoltativamente scrivere snapshot dei dati su disco usando la persistenza dei dati. Se un errore hardware influisce sul nodo, Redis gestito di Azure ripristina automaticamente i dati. È possibile scegliere tra diversi tipi di persistenza dei dati, che offrono compromessi diversi tra la frequenza degli snapshot e gli effetti sulle prestazioni nella cache.

  Non è possibile ripristinare i file di dati in un'altra istanza e non è possibile accedere ai file. La persistenza dei dati non protegge l'utente dal danneggiamento o dall'eliminazione accidentale dei dati.

• Importare ed esportare: Azure Managed Redis supporta il backup dei dati quando si usa la funzionalità di importazione ed esportazione, che salva i file di backup in Archiviazione BLOB di Azure. È possibile configurare l'archiviazione con ridondanza geografica nell'account di archiviazione di Azure nelle aree supportate oppure copiare o spostare i BLOB di backup in altre posizioni per una maggiore protezione.

  È possibile ripristinare i file esportati nella stessa istanza della cache o in un'istanza della cache diversa.

  Il servizio non include un'utilità di pianificazione predefinita per l'importazione o l'esportazione, ma è possibile sviluppare processi di automazione personalizzati che usano l'interfaccia della riga di comando di Azure o Azure PowerShell per avviare le operazioni di esportazione.

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per altre informazioni, vedere Contratti di servizio per Servizi online.

Il contratto di servizio per Azure Managed Redis copre la connettività agli endpoint della cache. Non copre la protezione dalla perdita di dati.

Per essere idonei per i contratti di servizio di disponibilità per Azure Managed Redis, è necessario soddisfare i requisiti seguenti:

• È necessario usare una configurazione a disponibilità elevata.

• Non è necessario avviare alcuna funzionalità del prodotto o azioni di gestione documentate per produrre un'indisponibilità temporanea.

Gli accordi sul livello di servizio con disponibilità più elevata si applicano quando l'istanza è ridondante a livello di zona. In alcuni livelli, è possibile diventare idonei per un SLA di disponibilità più elevata quando si distribuiscono istanze con ridondanza zonale in almeno tre regioni usando la replica geografica attiva.

Contenuti correlati

• Affidabilità in Azure