Consigli sul ripristino di emergenza per una piattaforma dati di Azure

Questo articolo è il quarto di una serie sul ripristino di emergenza per una piattaforma dati di Azure. Fornisce raccomandazioni e esperienze acquisite per implementare una strategia di ripristino di emergenza, inclusi suggerimenti su come definire gli obiettivi di recupero, testare le procedure di ripristino di emergenza e affrontare le considerazioni operative.

Lezioni apprese

• Assicurarsi che tutte le parti coinvolte comprendano la differenza tra disponibilità elevata (HA) e ripristino di emergenza (DR). Confondere questi concetti può comportare soluzioni non corrispondenti.

• Collaborare con gli stakeholder aziendali per definire gli obiettivi del punto di ripristino (RPO) e gli obiettivi del tempo di ripristino (RTO) in base ai fattori seguenti:

  • Quantità di tempo di inattività che possono tollerare. Il ripristino più rapido comporta in genere costi maggiori.

  • I tipi di eventi imprevisti a cui gli stakeholder hanno bisogno di protezione e la probabilità che si verifichino. Ad esempio, un errore del server è più probabile di una calamità naturale che influisce su tutti i data center in un'area.

  • Gli effetti dell'indisponibilità del sistema sul proprio business.

  • Il budget delle spese operative (OPEX) per la soluzione a lungo termine.

• Considerare quali opzioni di servizio ridotte gli utenti possono accettare, ad esempio:

  • Accesso ai dashboard di visualizzazione, anche se i dati non sono aggiornati. In questo scenario, gli utenti possono visualizzare i dati anche se le pipeline di inserimento hanno esito negativo.

  • Accesso in lettura senza funzionalità di scrittura.

• Gli obiettivi RTO e RPO determinano quale strategia di disaster recovery adottare. Le strategie comuni includono active-active, active-passive e la ridistribuzione in caso di disastro. Considerare anche l'obiettivo del livello di servizio composito (SLO) per tenere conto di tutte le soglie di tempo di inattività tollerabili.

• Assicurarsi di comprendere tutti i componenti che potrebbero influire sulla disponibilità dei sistemi:

  • Gestione delle identità

  • Topologia di rete

  • Gestione dei segreti e gestione delle chiavi

  • Origini dati

  • Automazione e pianificazione dei processi

  • Repository di codice sorgente e pipeline di distribuzione come GitHub e Azure DevOps

• Il rilevamento anticipato delle interruzioni può ridurre i valori RTO e RPO. Applicare le procedure seguenti:

  • Definisci che cos'è un'interruzione e come si collega alla definizione di interruzione secondo Microsoft.

  • Implementare un sistema di monitoraggio e avviso con una proprietà chiara in modo che il team riveda tempestivamente le metriche e gli avvisi.

• Per la progettazione delle sottoscrizioni, un'infrastruttura aggiuntiva per il ripristino di emergenza può risiedere nella sottoscrizione originale. Le offerte PaaS (Platform as a Service) come Azure Data Lake Storage in genere includono funzionalità di failover native. Queste funzionalità supportano istanze secondarie in altre aree mentre rimangono all'interno della sottoscrizione originale. Per ottimizzare i costi, è possibile allocare un gruppo di risorse dedicato esclusivamente per le risorse correlate al ripristino di emergenza.

  • I limiti delle sottoscrizioni possono introdurre vincoli in questo approccio.

  • Questo approccio aggiunge anche complessità di progettazione e richiede controlli di governance per impedire ai team di usare i gruppi di risorse di ripristino di emergenza per i flussi di lavoro di routine.

• Progettare il flusso di lavoro di ripristino di emergenza in base alla criticità e alle dipendenze di una soluzione. Ad esempio, non tentare di ricompilare un'istanza di Azure Analysis Services prima che il data warehouse sia operativo perché attiva un errore. Lasciare prima i lab di sviluppo per un processo successivo e ripristinare le soluzioni aziendali di base.

• Eseguire attività di ripristino in parallelo tra soluzioni per ridurre il totale di RTO.

• Se la tua soluzione utilizza pipeline di Fabric, includere i gateway dati locali nell'ambito. Usare Azure Site Recovery per questi computer.

• Automatizzare le operazioni di ripristino laddove possibile per ridurre l'errore umano, in particolare per situazioni ad alta pressione.

  • Adottare il provisioning delle risorse tramite Bicep, modelli di Azure Resource Manager (modelli ARM), Terraform o script di PowerShell.

  • Adottare il controllo delle versioni del codice sorgente e della configurazione delle risorse.

  • Usare le pipeline di rilascio CI/CD per l'integrazione continua e la distribuzione continua invece di eseguire manualmente le operazioni.

• Pianificare il failback e il failover. Documentare le procedure per restituire le operazioni alle istanze primarie dopo il ripristino.

• Definire indicatori e metriche chiari per verificare che il failover abbia esito positivo e che le soluzioni siano operative. Verificare che le prestazioni tornino alla normalità, note anche come funzionalità primarie.

• Decidere se i contratti di servizio devono rimanere invariati dopo il failover o se una riduzione temporanea della qualità del servizio è accettabile. La risposta dipende dalla criticità del carico di lavoro. Ad esempio, un sistema di prenotazione sala ha una tolleranza di inattività diversa rispetto a un sistema finanziario o operativo principale.

• Definire gli obiettivi RTO e RPO a livello di scenario utente anziché a livello di infrastruttura. Le destinazioni basate su scenari semplificano l'identificazione dei processi e dei componenti da classificare in ordine di priorità durante il ripristino.

• Eseguire i controlli della capacità nell'area di destinazione prima di procedere con un failover. In un disastro maggiore, molti clienti potrebbero tentare di eseguire il failover nella stessa regione abbinata contemporaneamente. Questo scenario può comportare ritardi o contenziosi nell'approvvigionamento delle risorse. Se questi rischi sono inaccettabili, valuta una strategia di disaster recovery o attiva-attiva o attiva-passiva.

• Creare e mantenere un piano di disaster recovery per documentare il processo di ripristino e i responsabili delle azioni. Assegnare un contatto di backup per ogni ruolo per tenere conto dei membri del team non disponibili.

• Eseguire normali esercitazioni sul ripristino di emergenza per convalidare il flusso di lavoro del piano di ripristino di emergenza, assicurarsi che soddisfi i requisiti RTO e RPO necessari e formare i team responsabili. Testare regolarmente i dati e i backup di configurazione per verificare che possano supportare il ripristino quando necessario.

• Collaborare fin dall'inizio con i team responsabili della rete, dell'identità e del provisioning delle risorse per concordare:

  • Reindirizzamento del traffico al sito secondario. Prendere in considerazione strumenti come il reindirizzamento DNS (Domain Name System) o Gestione traffico di Azure.

  • Come concedere l'accesso al sito secondario in modo rapido e sicuro.

• Durante un'emergenza, comunicare chiaramente con tutte le parti coinvolte per eseguire il piano in modo efficiente. Informare i gruppi seguenti durante il ripristino:

  • Responsabili decisionali
  • Team di risposta agli eventi imprevisti
  • Utenti e team interni interessati
  • Team esterni

• Coordinare il ripristino delle risorse nella sequenza corretta per ottimizzare l'efficienza.

Antipatterns

• Copiare e incollare questa serie di articoli

  Questa serie di articoli fornisce indicazioni per i clienti che desiderano una comprensione più approfondita di un processo di ripristino di emergenza specifico di Azure. Si basa su architetture di riferimento e proprietà intellettuale Microsoft generiche anziché su qualsiasi singola implementazione di Azure specifica del cliente.

  Questo contenuto offre una solida comprensione di base. È tuttavia necessario personalizzare l'approccio considerando il contesto, l'implementazione e i requisiti univoci per sviluppare una strategia e un processo di ripristino di emergenza adatti allo scopo.

• Trattare il DR come un processo esclusivamente tecnico

  La pianificazione del ripristino di emergenza tende a concentrarsi sulle attività tecniche, ma il ripristino dei sistemi senza soddisfare i requisiti aziendali non riesce. Gli stakeholder aziendali definiscono i requisiti di ripristino di emergenza e convalidano che il ripristino del servizio soddisfi le esigenze aziendali.

  Coinvolgere gli stakeholder aziendali in tutte le attività di ripristino di emergenza per produrre un processo che funziona quando necessario e offre valore aziendale reale.

• Creare piani di DR statici

  Azure è in continua evoluzione e quindi sono i modi in cui i clienti usano i propri servizi. Il processo di DR deve tenere il passo con questi cambiamenti.

  Rivaluta regolarmente il piano di ripristino di emergenza come parte del ciclo di vita dello sviluppo software o tramite revisioni periodiche per mantenerlo aggiornato con eventuali modifiche ai componenti, ai servizi o alle soluzioni.

• Valutazioni su carta

  Le organizzazioni spesso valutano la preparazione al disaster recovery tramite revisioni documentali o esercitazioni tabletop senza eseguire test di ripristino reali. Questo approccio può dare un falso senso di sicurezza perché gli errori reali raramente corrispondono a scenari teorici.

  Una simulazione end-to-end completa è difficile in un ecosistema di dati moderno, ma mira a testare la maggior parte dell'ambiente interessato il più possibile. Le esercitazioni regolari creano la fiducia del team e la familiarità con il piano di ripristino di emergenza.

• Fare affidamento su Microsoft per eseguire tutte le operazioni

  Azure servizi definiscono un modello chiaro di responsabilità condivisa per l'affidabilità in base al livello di servizio cloud.

  

  La tabella include 10 righe di responsabilità e quattro colonne di distribuzione: Software as a Service (SaaS), Piattaforma distribuita come servizio (PaaS), infrastruttura distribuita come servizio (IaaS) e locale. Le celle riempite indicano la responsabilità del cliente e le celle non riempite indicano Microsoft responsabilità. Le celle divise diagonalmente indicano la responsabilità condivisa. Tre sezioni etichettate sulla destra raggruppano le righe. La prima sezione, etichettata come "responsabilità sempre mantenuta dal cliente", contiene informazioni e dati, dispositivi (mobili e PC) e account e identità. Tutti gli elementi vengono contrassegnati come responsabilità del cliente in tutti e quattro i tipi di distribuzione. La seconda sezione, denominata «la responsabilità varia in base al tipo di servizio», contiene l'infrastruttura di identità e directory, le applicazioni, i controlli di rete e il sistema operativo. In questa sezione la responsabilità del cliente diminuisce da locale a SaaS, con alcune celle che mostrano la responsabilità condivisa. La terza sezione, i trasferimenti di responsabilità etichettati al provider di servizi cloud, contiene host fisici, rete fisica e data center fisico. Tutti gli elementi sono contrassegnati come responsabilità del cliente solo per l'ambiente locale e come responsabilità Microsoft per SaaS, PaaS e IaaS.

  Anche con uno stack SaaS completo, si rimane responsabili degli account, delle identità e dei dati e dei dispositivi usati dagli utenti per accedere ai servizi Azure.

Ambito e strategia degli eventi

Ambito degli eventi disastrosi

Diversi eventi hanno ambiti di impatto diversi che richiedono risposte diverse. Il diagramma seguente illustra l'ambito dell'impatto e della risposta per un evento di emergenza.

Opzioni di strategia DR

Scegli tra quattro strategie DR di alto livello:

• Attendere Microsoft: la soluzione rimane offline finché Microsoft ripristina i servizi nell'area interessata. Convalidare e aggiornare la soluzione prima di restituirla al servizio.

• Ridistribuire in caso di emergenza: È possibile ridistribuire manualmente la soluzione da zero in un'area disponibile dopo un'emergenza.

• Riserva calda (attivo-passivo): Si distribuisce una soluzione secondaria in un'altra area con capacità minima, ma non riceve traffico di produzione. I servizi secondari vengono eseguiti a prestazioni ridotte o rimangono disattivati fino a quando non si verifica un evento di ripristino di emergenza.

• Riserva a caldo (attivo-attivo): La soluzione viene eseguita in una configurazione attiva-attiva in più aree. Ogni istanza riceve, elabora e fornisce dati come parte del sistema complessivo.

Effetti della strategia DR

Il costo è spesso il fattore decisivo quando si sceglie una strategia di disaster recovery, ma contano anche l’RTO, la complessità del ripristino e l’impatto sui clienti.

La tabella seguente confronta le quattro opzioni per un'interruzione completa Azure a livello di area nell'area primaria che ospita la piattaforma dati Contoso. Verde indica un risultato favorevole per tale fattore. Arancione indica un risultato moderato. Il rosso indica un risultato sfavorevole.

Chiave di classificazione

Per questo scenario di interruzione, i fattori seguenti determinano l'impatto relativo di ogni strategia di ripristino di emergenza:

• RTO: Tempo trascorso previsto dall'evento di emergenza al ripristino del servizio della piattaforma

• Complessità di esecuzione: La complessità per l'organizzazione nello svolgere le attività di ripristino

• Complessità di implementazione: La complessità per l'organizzazione nell'implementare la strategia di disaster recovery

• Impatto sui clienti: L'impatto diretto sui clienti del servizio della piattaforma dati derivante dalla strategia di ripristino di emergenza

• Costo OPEX al di sopra della linea: Il costo aggiuntivo previsto derivante dall'implementazione di questa strategia, ad esempio l'aumento della fatturazione mensile di Azure per componenti aggiuntivi e ulteriori risorse necessarie

Passaggi successivi

• Carico di lavoro cruciale
• Le raccomandazioni del Well-Architected Framework per la progettazione di una strategia di ripristino di emergenza

" output is necessary.)

• DR per una piattaforma dati di Azure - Panoramica
• Ripristino di emergenza per una piattaforma dati Azure - Architettura
• Ripristino di emergenza per una piattaforma dati Azure - Dettagli dello scenario