Comprendere il ripristino d'emergenza
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. (DR) il processo di ripristino di uno o più carichi di lavoro in uno stato operativo in una seconda regione IBM Cloud dopo un'interruzione non pianificata. L'alta disponibilità non è la stessa cosa del disaster recovery.
Quando si progettano e realizzano i carichi di lavoro IT, spesso ci si concentra sul mantenimento dell'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). L'HA è il processo di progettazione di singoli punti di guasto in modo che i carichi di lavoro possano sopravvivere ed evitare le interruzioni altrimenti causate da un'infrastruttura non funzionante.
I disastri sono diversi. I disastri causano l'interruzione di un carico di lavoro nonostante i tentativi di renderlo altamente disponibile. I disastri più gravi hanno conseguenze diffuse, il che significa che i carichi di lavoro colpiti potrebbero richiedere il ripristino in una regione completamente diversa.
Cosa significa disaster recovery?
Per illustrare il recupero in una seconda regione, consideriamo uno scenario. In circostanze normali, un cliente esegue i propri carichi di lavoro nella regione multizona IBM Cloud us-south. In seguito, si verifica una grave catastrofe
che colpisce e provoca un'interruzione prolungata per tutta la regione us-south. In questi casi, il ritorno al normale funzionamento di us-south potrebbe richiedere ore, giorni o addirittura mesi, a seconda dell'entità
dell'interruzione. Se i carichi di lavoro cloud interessati sono critici per le operazioni aziendali, lunghi periodi di inattività lasciano poche opzioni se non quella di ripristinare ed eseguire i carichi di lavoro in una seconda regione
IBM Cloud.
Tali circostanze derivano tipicamente da un problema diffuso che interessa una particolare area geografica, compresi i disastri naturali e le emergenze regionali o nazionali. È improbabile che questo tipo di disastri si verifichi. In genere, l'architettura MZR di IBM Cloud fornisce una protezione adeguata contro i guasti zonali e il guasto di un'intera regione è improbabile. i Service Level Agreement (SLA) di IBM Cloud per i servizi distribuiti su un MZR sono in genere del 99.99, il che equivale a poco più di 52.5 minuti di downtime non pianificato all'anno. Per ulteriori informazioni, vedere IBM Cloud Accordi sul livello di servizio.
Tuttavia, rimane la possibilità che un disastro possa mettere fuori uso la regione in cui sono in esecuzione i carichi di lavoro critici. Preparatevi con un piano di disaster recovery se volete evitare lunghi periodi di inattività causati da disastri.
RTO e RPO
L' obiettivo del tempo di recupero(RTONella pianificazione del disaster recovery, la durata del tempo necessario per ripristinare un processo aziendale dopo un disastro. ) e l'obiettivo del punto di recupero(RPONella 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. ) sono spesso i due punti di partenza di un piano di disaster recovery. Il diagramma seguente descrive come RTO e RPO si inseriscono in una timeline semplificata di interruzione.
Quando si verifica un'interruzione, l'azienda deve decidere se e quando dichiarare un disastro e mettere in atto il piano di disaster recovery. Dopo aver dichiarato un disastro, l'orologio inizia a funzionare con l'RTO. L'RTO si riferisce al tempo necessario per ripristinare i servizi in uno stato utilizzabile. Un piano può avere un RTO generale, che copre molti carichi di lavoro, e RTO individuali per ogni carico di lavoro coperto. L'RTO è espresso in unità di tempo, ad esempio minuti, ore o giorni.
L'RPO si riferisce al punto in cui i servizi vengono ripristinati, che di solito è il punto dell'ultimo backup. Quando si esegue il ripristino da un danneggiamento dei dati, è auspicabile un RPO anticipato a un momento precedente all'introduzione del danneggiamento. Quando più carichi di lavoro sono interconnessi, è importante che ogni sistema venga riacquistato allo stesso punto nel tempo. L'RPO è espresso dal punto di guasto o di perdita zero dei dati, dal punto dell'ultimo backup o da una posizione intermedia. I vincoli all'RPO includono la fattibilità tecnica e i costi di implementazione. L'interruzione dura fino al ripristino del servizio all'utente finale.
Molti ambienti presentano un mix di carichi di lavoro, alcuni fondamentalmente critici e altri meno critici. Alcuni ambienti complessi possono anche avere molte dipendenze da altri carichi di lavoro, dove un carico di lavoro ha bisogno di un altro per funzionare. Questi aspetti contribuiscono alla definizione degli obiettivi RTO e RPO per i singoli carichi di lavoro. Creare una timeline del piano di ripristino che tenga conto dell'ordine in cui i carichi di lavoro devono essere ripristinati. La tempistica deve tenere conto dell'importanza di un carico di lavoro per l'azienda, dei requisiti di risorse, della complessità e delle dipendenze.
La tabella seguente fornisce un esempio di RPO/RTO per classificazioni applicative esemplificative come riferimento. L'effettivo RPO/RTO e la classificazione aziendale dipendono da ciascuna organizzazione.
| Classe di applicazione aziendale | RPO | RTO |
|---|---|---|
| Platino (sempre acceso) | Zero | Vicino allo zero |
| Oro (quasi sempre acceso) | <= 15 minuti | <= 1 ora |
| Argento (Alta disponibilità) | <= 1 ora | 4 - 8 ore |
| Bronzo (disponibilità moderata) | <= 8 ore | <= 24 ore |
Il mantenimento di un'offerta di DR ha dei costi associati. Il diagramma seguente mostra una tipica curva di costo della DR. Quanto più vicino allo zero è l'obiettivo RTO e RPO, tanto maggiore è il costo della soluzione necessaria. Quando l'RTO e l'RPO si spostano verso le ore o addirittura i giorni, i costi associati si riducono. I carichi di lavoro con gli obiettivi RTO e RPO più stringenti costano di più per la protezione e sono i più critici per l'azienda.
Pianificazione di un disastro
L'approccio alla definizione della strategia di DR deve essere sistematico e partire dall'applicazione o dal carico di lavoro e dai tipi di servizi cloud utilizzati. Si è tentati di fissare un unico obiettivo RTO/RPO per tutti i carichi di lavoro, ma la realtà è che ogni carico di lavoro aziendale è indipendente e ha i propri requisiti RTO e RPO. Molti clienti utilizzano una serie di classi di carico di lavoro, dove ogni classe ha un RPO/RTO prestabilito.
Ogni carico di lavoro aziendale impiega un insieme di risorse cloud. I requisiti di DR devono essere compresi, documentati e implementati prima del rilascio in produzione. È più difficile "adattare" una soluzione di DR piuttosto che progettare il carico di lavoro pensando a una soluzione di DR.
Strategie di disaster recovery
Esistono molte opzioni per implementare soluzioni di DR. Le diverse opzioni sono raggruppate nelle seguenti quattro categorie principali:
- Impronta zero
- Zero footprint vede l'intero stack applicativo attivo in una sede, con la possibilità di ripristinare lo stack applicativo in un'altra sede, dove però non viene costruito nulla. In pratica, verificare che tutti i backup siano disponibili nella seconda posizione per il ripristino. In caso di catastrofe, tutti i servizi vengono approvvigionati da zero, preferibilmente da modelli Terraform o simili, prima di applicare i backup. L'impronta zero è la strategia meno costosa. Poiché i servizi vengono forniti da zero, è adatto solo quando gli obiettivi RTO e RPO sono di almeno alcune ore.
- Standby di base
- Le opzioni di standby di base mantengono l'intero stack applicativo attivo in una sede, mentre un altro stack applicativo viene distribuito ma mantenuto spento in una sede diversa. Se si verifica un'interruzione prolungata nella sede principale, lo stack applicativo viene attivato nella seconda sede e i backup vengono ripristinati. Per l'istanziazione e il ripristino dei carichi di lavoro che utilizzano questo modello è previsto un tempo di ripristino di diverse ore. Se la disponibilità del carico di lavoro è critica e l'obiettivo RTO è inferiore a poche ore, questo approccio non è ottimale.
- Funzionamento minimo
- Il funzionamento minimo significa che l'intero stack applicativo è attivo sia nella sede primaria che in quella di backup, ma le transazioni degli utenti vengono elaborate solo nella sede primaria. La replica dei dati, come la replica del database o del disco, mantiene sincronizzata la posizione del backup. Nel caso in cui il sito primario non sia disponibile per un periodo prolungato, tutte le transazioni dei clienti vengono indirizzate al sito di backup. Questo approccio fornisce un RPO e un RTO misurabili in minuti. Il funzionamento minimo è più costoso delle opzioni Attivo/Passivo a causa della doppia distribuzione. Ad esempio, le risorse vengono sprecate perché gli asset in standby non possono essere utilizzati per migliorare la scalabilità e il throughput.
- Attivo/Attivo
- Attivo/Attivo significa che entrambe le sedi sono attive e le transazioni dei clienti sono distribuite in entrambe le regioni in base a criteri predefiniti, come "round-robin" o "geograficamente più vicino". Se un sito si guasta, l'altro sito deve essere in grado di servire tutti i clienti. Con questa configurazione è possibile ottenere un RPO e un RTO prossimi allo zero. L'uso dell'autoscaling è fondamentale per garantire la disponibilità di risorse sufficienti in base al carico corrente. Se una regione si guasta, la regione rimanente deve scalare rapidamente per gestire esclusivamente il carico completo. I dati tra i due siti sono continuamente sincronizzati con un meccanismo di replica. Affidarsi esclusivamente a questo approccio è problematico nei casi in cui il danneggiamento o la perdita di dati è la causa principale del disastro, a causa della replica. La soluzione di tali disastri si basa ancora sul ripristino dei backup che includono i dati non danneggiati o persi.
Progettare per vari scenari
Le catastrofi hanno molte forme e richiedono tecniche diverse per contrastarle. I mezzi per recuperare da un'interruzione completa della regione sono diversi da quelli per recuperare da un danneggiamento dei dati. Una buona progettazione non prende in considerazione solo un singolo scenario, ma considera diversi scenari che prevedono il recupero da diversi potenziali guasti.
Considerate attentamente ciò che vi serve per recuperare in caso di disastro. Avete bisogno di tutti i carichi di lavoro o solo di un sottoinsieme di applicazioni principali? Esiste un ordine in cui devono essere ripristinati? È importante la coerenza dei dati tra i vari carichi di lavoro? È possibile lavorare in uno stato degradato e, se sì, per quanto tempo?
Si tratta di considerazioni commerciali e tecniche, poiché in alcune situazioni i costi potrebbero essere proibitivi. È necessario avere una visione chiara di quale sia il recupero minimo accettabile che consente all'azienda di funzionare, accettando i rischi residui e comprendendone le conseguenze. La pianificazione della soluzione tecnica deve andare di pari passo con i requisiti aziendali ed entrambi devono essere inseriti nel piano di disaster recovery. Per ulteriori informazioni, vedere Pianificazione del ripristino di emergenza.
Leggere la documentazione specifica del servizio
Ogni servizio di IBM Cloud è documentato separatamente e comprende una sezione sui requisiti BCDR specifici per quel prodotto. Assicurarsi di esaminare e seguire le indicazioni fornite per ogni servizio utilizzato. Per trovare collegamenti specifici agli argomenti, consultare la documentazione del servizio per l'alta disponibilità e il ripristino d'emergenza.