Descrizione di alta disponibilità e di ripristino di emergenza per Databases for Redis
L' alta disponibilitàLa capacità di un servizio o di un carico di lavoro di resistere ai guasti e di continuare a fornire capacità di elaborazione secondo un livello di servizio predefinito. (HA) è la capacità di un servizio di rimanere operativo e accessibile in presenza di guasti imprevisti. Il disaster recoveryLa capacità di un servizio o di un carico di lavoro di riprendersi da incidenti rari e gravi e da guasti su larga scala, come l'interruzione del servizio. Ciò include un disastro fisico che colpisce un'intera regione, il danneggiamento di un database o la perdita di un servizio che contribuisce a un carico di lavoro. L'impatto supera la capacità del progetto di alta disponibilità di gestirlo. è il processo di ripristino dell'istanza di servizio in uno stato funzionante.
Databases for Redis è un servizio regionale che soddisfa gli obiettivi di livello di servizio(SLO) definiti con il piano standard.
Per ulteriori informazioni sulle regioni e sui data center IBM Cloud disponibili per Databases for Redis, vedere Disponibilità del servizio e dell'infrastruttura per località.
Architettura ad alta disponibilità
Databases for Redis offre funzioni di replica, failover e alta disponibilità per proteggere i database e i dati dalla manutenzione dell'infrastruttura, dagli aggiornamenti e da alcuni guasti. Le distribuzioni contengono un cluster con due membri di dati in una configurazione primaria più replica. La replica viene mantenuta aggiornata utilizzando la replica asincrona. L'alta disponibilità è monitorata e gestita da tre sentinelle Redis
Per impostazione predefinita, la persistenza dei dati è abilitata su tutte le distribuzioni e i dati vengono scritti su disco. Databases for Redis utilizza una combinazione di snapshot RDB e AOF(Append Only File) per persistere i dati su disco. L'intervallo di scrittura su disco di Databases for Redis (fsync) è impostato su una volta al secondo per bilanciare durata e prestazioni.
È possibile disattivare la persistenza dei dati, utile per configurare Redis come una cache.
Caratteristiche di alta disponibilità
Databases for Redis supporta le seguenti funzioni di alta disponibilità:
| Funzione | Descrizione | Considerazione |
|---|---|---|
| Failover automatico | Standard su tutti i cluster e resiliente contro i guasti di una zona o di un singolo membro | |
| Conteggio membri | Minimo - 2 membri. L'impostazione predefinita è un cluster standard a due membri in una configurazione primaria e di replica. Un cluster di due membri si riprenderà automaticamente da un guasto di una singola istanza o zona (con perdita di dati fino alla soglia di ritardo). | Tre nodi Sentinel per monitorare la salute del cluster e coordinare i failover. |
| Replica asincrona | Consente la replica da primario a replica senza bloccare il percorso di scrittura, garantendo un'elevata disponibilità con una bassa latenza. Fare riferimento a Replica asincrona. | Può causare la perdita di dati durante il failover a causa del ritardo di replica (RPO > 0). Non è adatto quando è richiesta una rigorosa durabilità dei dati. |
Replica asincrona per Databases for Redis
Per impostazione predefinita, Databases for Redis utilizza la replica asincrona, in cui il nodo primario non attende la conferma delle scritture da parte della replica. Questo garantisce una bassa latenza e un elevato throughput, rendendo Databases for Redis ideale per il caching e i carichi di lavoro sensibili alle prestazioni. Tuttavia, in caso di guasto del sistema primario, il ritardo della replica può portare alla perdita di dati, poiché la replica potrebbe non aver ricevuto le scritture più recenti.
Databases for Redis la replica è progettata per un'elevata disponibilità, non per una durabilità rigorosa. Il failover viene attivato automaticamente se il primario diventa irraggiungibile, promuovendo la replica a leader. Poiché la replica è asincrona, alcune scritture impegnate potrebbero andare perse durante questo processo. Questo ritardo di replica definisce il Recovery Point Objective (RPO) delle implementazioni Databases for Redis.
Per ridurre il rischio di perdita dei dati, Databases for Redis supporta meccanismi di persistenza come le istantanee RDB e AOF(Append Only File), che scrivono i dati su disco indipendentemente dal processo di replica. Questi devono essere configurati con attenzione in base ai requisiti del carico di lavoro.
La replica asincrona in Databases for Redis garantisce prestazioni veloci, ma non elimina la possibilità di perdita di dati durante gli eventi di failover. È consigliata per i carichi di lavoro in cui la velocità e la disponibilità prevalgono su una rigorosa coerenza dei dati.
Architettura di disaster recovery
La strategia generale per il ripristino di emergenza consiste nel creare un nuovo database, come il database Restore riportato di seguito. Il contenuto del nuovo database può essere un backup del database di origine creato prima
del disastro.
Funzionalità di disaster recovery
Databases for Redis supporta le seguenti funzioni di disaster recovery:
| Funzione | Descrizione | Considerazione |
|---|---|---|
| Ripristino del backup | Creare il database da un backup precedentemente creato; vedere Gestione dei backup di Cloud Databases. | Le nuove stringhe di connessione per il database ripristinato devono essere referenziate in tutto il carico di lavoro. |
Pianificazione del ripristino in caso di disastro
Le fasi di disaster recovery devono essere praticate regolarmente. Nel costruire il vostro piano, considerate i seguenti scenari di fallimento e le relative soluzioni.
| Operazione non riuscita | Risoluzione |
|---|---|
| Guasto hardware (punto singolo) | (Esempio) IBM fornisce un database resiliente rispetto a un singolo punto di guasto hardware all'interno di una zona. Non è richiesta alcuna configurazione da parte del cliente. |
| malfunzionamento zona | Failover automatico. I membri del database sono distribuiti tra le zone. |
| Dati danneggiati | Ripristino del backup. Utilizzare il database ripristinato in produzione o per i dati di origine per correggere la corruzione nel database ripristinato. |
Alta disponibilità a livello di applicazione
Le applicazioni che comunicano sulle reti e i servizi cloud sono soggette ad errori di connessione temporanei. Le applicazioni devono essere progettate in modo da riprovare le connessioni quando gli errori sono causati da una perdita temporanea di connettività con l'installazione o con IBM Cloud.
Poiché Databases for Redis è un servizio gestito, gli aggiornamenti regolari e la manutenzione del database fanno parte delle normali operazioni. Questo può occasionalmente causare brevi intervalli in cui il database non è disponibile. Può anche far sì che il database attivi un fail-over aggraziato, un tentativo e una riconnessione. Il database impiega un po' di tempo per determinare quale membro è una replica e quale è il leader, quindi potrebbe verificarsi una breve interruzione della connessione. I failover richiedono generalmente meno di 30 secondi.
Le applicazioni devono essere progettate per gestire interruzioni temporanee del database, implementare la gestione degli errori per i comandi del database non riusciti e implementare una logica di retry per recuperare da un interruption.Use temporaneo IOREDIS, NODEREDIS o qualsiasi altro pacchetto di vostra scelta per garantire la continuità del vostro application.For maggiori informazioni, consultate il post del blog Redis sul rilevamento e la gestione degli errori.
Non sono previsti diversi minuti di indisponibilità del database o di interruzione della connessione. Aprire un caso di assistenza con i dettagli se si verificano periodi superiori a un minuto senza connettività, in modo da poter indagare.
Limiti connessioni
Databases for Redis imposta un massimo di 10.000 connessioni simultanee per installazione. Questo limite garantisce la stabilità delle prestazioni e la gestione delle risorse nell'ambiente Redis. Tuttavia, non tutte le 10.000 connessioni sono disponibili per i clienti: una parte è riservata internamente alle operazioni che mantengono lo stato e l'integrità dell'installazione. Dopo aver raggiunto il limite di connessione, qualsiasi tentativo di avviare una nuova connessione provoca un errore. Per ulteriori informazioni, vedere Gestione delle connessioni di Redis.
Le vostre responsabilità per HA e DR
Le seguenti informazioni possono aiutarvi a creare e a mettere in pratica costantemente il vostro piano per l'HA e il DR.
Quando si ripristina un database dai backup o si usa il ripristino point-in-time, viene creato un nuovo database con nuove stringhe di connessione. I carichi di lavoro e i processi esistenti devono essere adattati per utilizzare le nuove stringhe di connessione.
Un database recuperato può anche avere bisogno delle stesse dipendenze create dal cliente del database danneggiato. Assicurarsi che questo e altri servizi esistano nella regione recuperata:
- IBM® Key Protect for IBM Cloud®
Ricordate che l'eliminazione di un database elimina anche i backup ad esso associati. Tuttavia, i database eliminati possono essere recuperati entro un periodo di tempo limitato. Per ulteriori informazioni, consultare le FAQ sui backup.
Non è possibile copiare i backup dal sito IBM Cloud, quindi si consiglia di utilizzare gli strumenti specifici del database per ulteriori backup. Può essere necessario per ripristinare l'eliminazione di un database da parte di un malintenzionato, seguita da una bonifica di un database. Un'attenta gestione dell'accesso IAM ai database può contribuire a ridurre l'esposizione a questo problema.
La seguente lista di controllo associata a ciascuna caratteristica può aiutarvi a creare e mettere in pratica il vostro piano.
- Ripristino del backup
- Verificare che i backup siano disponibili con la frequenza desiderata per soddisfare i requisiti RPO. Gestione dei backup Cloud Databases documenta la frequenza dei backup.
- Esistono alcune restrizioni sulle regioni di ripristino dei database: verificare che gli obiettivi di ripristino possano essere raggiunti leggendo Gestione dei backup di Cloud Databases.
- Verificate che il periodo di conservazione dei backup soddisfi i vostri requisiti.
- Pianificare regolarmente ripristini di prova per verificare che i tempi di ripristino effettivi rispettino l'RTO definito. Ricordate che le dimensioni del database influiscono in modo significativo sui tempi di ripristino. Considerate le strategie per ridurre al minimo i tempi di ripristino, come la suddivisione di database di grandi dimensioni in unità più piccole e gestibili e l'eliminazione dei dati inutilizzati.
- Verificare il servizio Key Protect.
Per saperne di più sulla responsabilità tra il cliente e IBM Cloud per l'utilizzo di Databases for Redis, vedere Responsabilità condivise per Cloud Databases.
Rimanete informati: notifiche su IBM
Gli aggiornamenti che interessano i carichi di lavoro dei clienti sono comunicati attraverso le notifiche di IBM Cloud. Per essere informati sulla manutenzione programmata, sugli annunci e sulle note di rilascio relative a questo servizio, consultate la pagina delle notifiche e dello stato del monitoraggio. Inoltre, consultate regolarmente la pagina della Politica delle versioni per gli ultimi aggiornamenti sulle versioni e sulle date di fine vita.