Descrizione di alta disponibilità e di ripristino di emergenza per Databases for MongoDB
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. Per i servizi, la disponibilità è definita nell'Accordo sul livello dei servizi. La disponibilità comprende sia gli eventi pianificati che quelli non pianificati, come manutenzione, guasti e disastri. (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 MongoDB è un servizio regionale che soddisfa gli obiettivi di livello di servizio(SLO) definiti con i piani Standard ed Enterprise. Per ulteriori informazioni, vedere Accordo sul livello di servizio(SLA). Per ulteriori informazioni sulle regioni e sui data center IBM Cloud disponibili per Databases for MongoDB, vedere Disponibilità del servizio e dell'infrastruttura per località.
Architettura ad alta disponibilità
Databases for MongoDB 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 tre membri dati, uno primario e due secondari. Il set di replica a due membri viene mantenuto aggiornato utilizzando la replica asincrona. Un meccanismo di consenso distribuito viene utilizzato per mantenere lo stato del cluster e gestire i failover. Se il primario non è disponibile, il set di replica sceglie un secondario come primario e continua a funzionare normalmente. Il vecchio primario rientra nel set quando è disponibile. I membri primari e secondari si troveranno sempre in zone diverse di un MZR. Se il guasto di una zona comporta il fallimento di un membro, la nuova replica verrà creata in una zona superstite.
Caratteristiche di alta disponibilità
Databases for MongoDB supporta le seguenti funzioni di alta disponibilità.
| Funzione | Descrizione |
|---|---|
| Failover automatico | Standard su tutti i cluster e resiliente contro i guasti di una zona o di un singolo membro. |
| Conteggio membri | Minimo 3 membri. L'impostazione predefinita è una distribuzione standard a tre membri. Un cluster di tre membri si riprenderà automaticamente da un guasto di una singola istanza o zona (con perdita di dati fino alla soglia di ritardo). |
| Replica asincrona | I secondari replicano le operazioni del primario e applicano le operazioni ai loro set di dati in modo asincrono. Se i set di dati secondari riflettono il set di dati primario, il set di replica può continuare a funzionare nonostante il guasto di uno o più membri. |
Architettura di disaster recovery
La strategia generale per il ripristino di emergenza consiste nel creare un nuovo database, come il seguente database MongoDB Restore. Il contenuto del nuovo database può essere un backup del database di origine creato prima del
disastro. È possibile creare un nuovo database utilizzando la funzione point-in-time per il piano Enterprise, se il database di produzione è disponibile.
Funzionalità di disaster recovery
Databases for MongoDB 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. |
| Ripristino del punto temporale | Creare il database dalla produzione live utilizzando il ripristino point-in-time. | Questo è possibile solo per il piano Enterprise e se il database attivo è disponibile e l'RPO (disastro) rientra nella finestra supportata. Non è utile se il cluster di produzione non è disponibile. 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) | IBM fornisce un database resistente a un singolo punto di guasto hardware all'interno di una zona, senza necessità di configurazione. |
| malfunzionamento zona | Failover automatico. I membri del database sono distribuiti tra le zone. La configurazione di tre membri fornirà una maggiore resilienza in caso di guasti multipli della zona. |
| Dati danneggiati | Ripristino del backup. Utilizzare il database ripristinato in produzione o per i dati di origine per correggere la corruzione nel database ripristinato.
Ripristino point-in-time. Utilizzare il database ripristinato in produzione o per i dati di origine per correggere la corruzione nel database ripristinato. |
| Fallimento regionale | Ripristino del backup. Utilizzare il database ripristinato in produzione. |
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.
Le applicazioni devono essere progettate per gestire le interruzioni temporanee del database, implementare la gestione degli errori per i comandi del database non riusciti e implementare la logica di retry per recuperare da un'interruzione temporanea.
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.
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. La promozione di una replica di lettura in un cluster avrà un impatto simile, anche se le porzioni esistenti di sola lettura del carico di lavoro non saranno interessate.
Un database recuperato potrebbe anche avere bisogno delle stesse dipendenze create dal cliente del database danneggiato: assicuratevi che i servizi seguenti e altri 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 informazioni specifiche sulle procedure di ripristino del database, fare riferimento alla documentazione relativa ai backup delle FAQ.
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. Considerare uno script utilizzando IBM Cloud® Code Engine- Lavorare con il produttore di eventi Periodic timer(cron) per creare backup aggiuntivi su richiesta per migliorare l'RPO se la criticità e le dimensioni del database lo consentono.
- 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.
- Ripristino del punto temporale
- Verificare le procedure descritte in precedenza.
- Verificare che il backup desiderato sia presente nella finestra.
Per ulteriori informazioni sulla responsabilità tra il cliente e IBM Cloud per l'utilizzo di Databases for MongoDB, 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, consultare la sezione Monitoraggio delle notifiche e dello stato. Inoltre, è necessario rivedere regolarmente la politica delle versioni per ottenere gli ultimi aggiornamenti sulle versioni e sulle date di fine vita.