Comprendere l'alta disponibilità e il disaster recovery per DNS Services
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. Lo scopo principale dell'alta disponibilità è eliminare i potenziali punti di errore in un'infrastruttura IT. 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. Include procedure per copiare e conservare i dati essenziali di un sistema installato in un luogo sicuro e per recuperare tali dati per ripristinare il normale funzionamento.
DNS Services è stato progettato per soddisfare gli obiettivi del livello di servizio(SLO) con il piano standard. DNS Services è un servizio globale altamente disponibile, architettato con domini di guasto separati per migliorare la resilienza. Il piano di controllo è resiliente ai guasti sia zonali che regionali e il suo guasto non influisce sul piano dati. Il piano dati è resiliente almeno ai guasti zonali e il suo guasto non influisce sul piano di controllo.
Per ulteriori informazioni sulle regioni di distribuzione e sulle sedi dei data center di DNS Services, vedere Disponibilità del servizio e dell'infrastruttura per località.
Architettura ad alta disponibilità
Piano di controllo
IBM Cloud® DNS Services è un servizio globalmente disponibile (GA). I suoi endpoint API pubblici per la configurazione del DNS sono disponibili attraverso un bilanciatore di carico globale distribuito in due regioni multizonaUna regione distribuita in più zone fisiche per aumentare la tolleranza ai guasti. (MZR) di IBM Cloud, che garantisce un'elevata disponibilità. Queste regioni sono Dallas e Washington, DC. Se una regione subisce un'interruzione, il bilanciatore di carico globale instrada automaticamente il traffico API verso l'altra regione. Ad esempio, se la regione di Dallas non è disponibile, le richieste vengono reindirizzate verso altre regioni geografiche disponibili, in questo caso Washington, DC.
In caso di guasto globale, il piano di controllo viene ripristinato con l'obiettivo di ridurre la perdita di dati per le risorse. Pertanto, i clienti devono pianificare anche il disaster recovery.
Un piano di controllo gestisce le richieste di configurazione DNS avviate dall'utente, mentre un piano dati gestisce le richieste di risoluzione dei nomi dal Virtual Private Cloud (VPC).
Server DNS del piano dati
I server DNS sono distribuiti a livello globale su più MZR e utilizzano indirizzi IP anycast per ottimizzare la latenza e garantire un'elevata disponibilità. Se una zona di disponibilità o un'intera regione subisce un'interruzione, le query DNS vengono automaticamente indirizzate alla zona di disponibilità o alla regione più vicina. I dati DNS sono replicati nelle seguenti regioni per supportare sia l'ottimizzazione della latenza che l'alta disponibilità:
- Dallas (us-south)
- Washington, D.C. (us-est)
- Londra (eu-gb)
- Madrid (eu-es)
- Francoforte (eu-de)
- Osaka (jp-osa)
- Tokyo (jp-tok)
- Toronto (ca-tor)
- Sydney (au-syd)
- San Paolo (br-sao)
Risolutori personalizzati del piano dati
Un resolver personalizzato è un oggetto regionale composto da oggetti zonali (posizioni di resolver personalizzati) configurati sulle sottoreti delle varie zone. Una procedura ottimale è quella di distribuire i resolver personalizzati a più di una sottorete per assicurare l'alta disponibilità. Si consiglia di distribuire in tutte e tre le zone di disponibilità.
In caso di guasto regionale, questo aspetto del piano dati viene ripristinato allo stato delle risorse rappresentato e conservato nel piano di controllo.
Caratteristiche di alta disponibilità
DNS Services supporta le seguenti funzioni di alta disponibilità:
| Funzione | Descrizione | Considerazione |
|---|---|---|
| Posizioni personalizzate del resolver | Gestire la posizione del resolver personalizzato. | Aggiunge solo la resilienza ai guasti zonali. |
È possibile ottenere l'alta disponibilità a vari livelli dell'infrastruttura IT e tra i diversi componenti del cluster DNS. Il livello di disponibilità più adatto dipende da diversi fattori, tra cui i requisiti aziendali, gli accordi sul livello di servizio (SLA) stipulati con i clienti e le risorse che si è disposti a spendere.
Il livello di disponibilità impostato per il cluster influisce sulla copertura dei termini dello SLA di alta disponibilità IBM Cloud.
Gli obiettivi dei livelli di servizio (SLO) definiscono i punti di progetto che i servizi di IBM Cloud sono progettati per soddisfare. IBM Cloud® DNS Services è progettato per soddisfare il seguente obiettivo di disponibilità.
| Obiettivo di disponibilità | Valore obiettivo |
|---|---|
| Disponibilità % | 99.999% |
Lo SLO non è una garanzia e IBM non rilascerà crediti per il mancato raggiungimento di un obiettivo. Fare riferimento agli SLA per gli impegni e i crediti che vengono emessi in caso di mancato rispetto degli SLA impegnati. Per un riepilogo di tutti gli SLO, vedere IBM Cloud service level objectives.
Per ulteriori informazioni sulla disponibilità dei servizi all'interno delle regioni e dei data center, vedere Disponibilità dei servizi e dell'infrastruttura per località.
Vedere Come IBM Cloud garantisce l'alta disponibilità e il disaster recovery per saperne di più sugli standard di alta disponibilità e di disaster recovery in IBM Cloud.
Architettura di disaster recovery
Il mantenimento di un record esterno della configurazione DNS è importante per recuperare DNS Services in caso di disastro. Sia il processo di backup che quello di ripristino possono essere automatizzati utilizzando lo scripting e i processi di esportazione e importazione nella tabella delle funzioni di ripristino di emergenza. DNS Services supporta Terraform e può essere usato per definire carichi di lavoro con posizioni e prestazioni parametrizzate. I clienti possono utilizzare IBM Cloud Schematics per creare e gestire gli script Terraform, che a loro volta possono essere utilizzati per recuperare le risorse in una posizione disponibile durante un disastro.
Funzionalità di disaster recovery
IBM Cloud® DNS Services supporta le seguenti funzioni di disaster recovery:
| Funzione | Descrizione | Considerazione |
|---|---|---|
| Esportazione dei record di risorse DNS | Esportare i record DNS di una zona in un file di testo attraverso la dashboard. | Esporta solo i record DNS di una zona alla volta. Non esporta il bilanciatore di carico o altri dati diversi dai record DNS. |
| Importare i record di risorse DNS | Importare i record DNS su un file di testo in una zona attraverso il dashboard. | È necessario ricreare la zona prima di importare i record DNS. |
| Fonte esterna di verità | Zone DNS, reti consentite, record di risorse DNS, resolver personalizzati, regole di inoltro dei resolver personalizzati e altro ancora, catturati in file di configurazione gestiti dal cliente come script Terraform, script di shell o programmi. | Il cliente deve creare lo script o il programma e conservare la configurazione in modo che possa essere utilizzata in caso di disastro. |
| Backup e ripristino | Eseguire il backup di un'istanza di servizio utilizzando uno script scritto dal cliente. | Il cliente deve creare lo script e conservare la copia di backup in modo che possa essere utilizzata durante il ripristino. |
Pianificazione della DR
Il cliente è responsabile del recupero dei dati di configurazione del server DNS in caso di disastro. Dovete assicurarvi di creare un piano di ripristino di emergenza e considerare i seguenti scenari di guasto e le relative soluzioni:
| Operazione non riuscita | Risoluzione |
|---|---|
| Fallimento zonale | Mitigato per i resolver personalizzati grazie alla distribuzione in più sedi Mitigato per i server DNS grazie alle query risposte dalla zona di disponibilità più vicina. |
| Fallimento regionale | Interruzione per i resolver personalizzati fino al ripristino di una zona di disponibilità. Mitigato per i server DNS dalle query a cui risponde la regione disponibile più vicina. |
| Dati danneggiati | Ripristinare le configurazioni del servizio da una fonte di verità esterna. |
Le vostre responsabilità per HA e DR
È vostra responsabilità testare continuamente il vostro piano per HA e DR.
Potrebbero verificarsi interruzioni della connettività di rete e brevi periodi di indisponibilità di un servizio. È responsabilità dell'utente assicurarsi che il codice sorgente dell'applicazione includa la logica di riprova della disponibilità del client per mantenere l'alta disponibilità dell'applicazione.
Utilizzate le seguenti liste di controllo associate a ciascuna caratteristica per aiutarvi a creare e mettere in pratica il vostro piano.
- Resolver personalizzato
Per ulteriori informazioni sulla proprietà delle responsabilità tra l'utente e IBM Cloud per IBM Cloud DNS Services, vedere Comprendere le proprie responsabilità quando si utilizza IBM Cloud DNS Services.
Gestione delle modifiche
La gestione delle modifiche comprende attività quali la modifica e la cancellazione della configurazione.
Assegnare agli utenti e ai processi i ruoli e le azioni di Identity and Access Management (IAM) con il minimo privilegio richiesto per il loro lavoro. Per ulteriori informazioni, vedere Come posso evitare la cancellazione accidentale dei servizi?
Le migliori pratiche per la gestione del cambiamento includono anche:
- Pianificare e documentare le modifiche mantenendo un registro delle modifiche apportate alla configurazione di DNS Services.
- Creare un backup delle configurazioni critiche prima di eseguire modifiche importanti.
- Programmare le modifiche ad alto impatto durante le finestre a basso traffico e informare i team interessati.
- Monitorate lo stato di salute e le metriche di DNS Services per assicurarvi che tutto funzioni come previsto.
Come IBM aiuta a garantire il ripristino di emergenza
IBM® intraprende azioni di ripristino specifiche per IBM Cloud® DNS Services, se si verifica un disastro.
Come IBM si riprende dai fallimenti regionali
IBM Cloud dispone di piani di continuità operativaLa capacità di un'azienda di resistere alle interruzioni e di gestire i servizi mission-critical normalmente e senza interruzioni in conformità con gli SLA (service - level agreement) predefiniti. che prevedono il ripristino dei servizi entro poche ore, in caso di disastro. L'utente è responsabile del backup dei dati e del relativo recupero dei contenuti.
DNS Services fornire meccanismi per proteggere i dati e ripristinare le funzioni del servizio. Sono stati predisposti piani di continuità operativa per raggiungere l'obiettivo del punto di ripristinoNella pianificazione del disaster recovery, il momento in cui i dati vengono ripristinati, misurato in termini di tempo (secondi, minuti, ore) a partire dall'istanza recuperata fino al punto in cui si è verificato il disastro. (RPO) e del tempo di ripristino(RTONella pianificazione del disaster recovery, la durata del tempo necessario per ripristinare un processo aziendale dopo un disastro. ) per il servizio. La seguente tabella illustra gli obiettivi di DNS Services.
| Elemento di servizio | RPO | RTO |
|---|---|---|
| Piano di controllo | 0 | < 60 secondi |
| Piano dati | 0 | < 60 secondi |
| Resolver personalizzato | 0 | < 60 secondi |
| Ripristino database | 24 ore | 8 ore |
Se IBM non è in grado di ripristinare l'istanza del servizio, è necessario ripristinare il servizio come descritto nell'architettura del disaster recovery.
Per ulteriori informazioni sulla disponibilità dei servizi all'interno delle regioni e dei data center, vedere Disponibilità dei servizi e dell'infrastruttura per località.
Come IBM mantiene i servizi
Tutti gli aggiornamenti seguono le best practice del servizio IBM, compresi i piani di ripristino e i processi di rollback. La manutenzione regolare potrebbe causare brevi interruzioni, mitigate dalla logica di riprova della disponibilità del client. Le modifiche vengono distribuite in modo sequenziale, regione per regione e zona per zona all'interno di una regione. IBM ripristina gli aggiornamenti al primo segno di difetto.
IBM fornisce un preavviso per tutte le attività di manutenzione programmate. Se si prevede che un cambiamento influisca sui vostri carichi di lavoro, IBM lo comunica attraverso notifiche ufficiali. Per rimanere aggiornati su manutenzione, annunci di servizio e altri aggiornamenti, consultate la pagina Notifiche e stato del monitoraggio.