Ripristino di emergenza per la piattaforma dati di Azure - Raccomandazioni

Lezioni apprese

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

• Per definire gli obiettivi del punto di ripristino (RPO) e gli obiettivi del tempo di ripristino (RTO), discutere con gli stakeholder aziendali delle loro aspettative relative ai fattori seguenti:

  • Quantità di tempo di inattività che possono tollerare. Tenere presente che il ripristino più veloce comporta in genere un costo più elevato.

  • I tipi di eventi imprevisti a cui gli stakeholder hanno bisogno di protezione e la probabilità che si verifichino. Ad esempio, è più probabile che si verifichi un errore del server rispetto a un'emergenza naturale che interessa 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 danneggiate gli utenti finali possono accettare. Queste opzioni possono includere:

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

  • Accesso in lettura senza funzionalità di scrittura.

• Le metriche RTO e RPO di destinazione determinano la strategia di ripristino di emergenza che si sceglie di implementare. Queste strategie includono attivo/attivo, attivo/passivo e attivo/ridistribuire in caso di emergenza. Prendere in considerazione il proprio obiettivo a livello di servizio composito per tenere conto dei tempi di inattività tollerabili.

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

  • Gestione delle identità.

  • Topologia di rete.

  • Gestione dei segreti e gestione delle chiavi.

  • Origini dati.

  • Automazione e pianificazione dei processi.

  • Repository di origine e pipeline di distribuzione come GitHub e Azure DevOps.

• Il rilevamento anticipato delle interruzioni è anche un modo per ridurre significativamente i valori RTO e RPO. Includere i fattori chiave seguenti:

  • Definire che cos'è un'interruzione e come esegue il mapping alla definizione di un'interruzione in base a Microsoft. La definizione Microsoft è disponibile nella pagina Contratto di servizio di Azure a livello di prodotto o servizio.

  • Implementare un sistema efficiente di monitoraggio e avvisi con team responsabili che esaminano tempestivamente le metriche e gli avvisi per supportare l'obiettivo.

• Per la progettazione delle sottoscrizioni, l'infrastruttura aggiuntiva per il ripristino di emergenza può essere archiviata nella sottoscrizione originale. I servizi platform-as-a-service come Azure Data Lake Storage e Azure Data Factory includono in genere funzionalità di failover native. Queste funzionalità consentono istanze secondarie in altre aree mentre rimangono all'interno della sottoscrizione originale. Per ottimizzare i costi, alcune organizzazioni potrebbero scegliere di 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.

  • Altri vincoli possono includere la complessità di progettazione e i controlli di gestione per assicurarsi che i gruppi di risorse di ripristino di emergenza non vengano usati per i flussi di lavoro normali dell'azienda.

• 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.

• Identificare le attività di ripristino che possono essere parallelizzate tra le soluzioni. Questo approccio riduce il valore RTO totale.

• Se Azure Data Factory viene usato in una soluzione, non dimenticare di includere i runtime di integrazione self-hosted nell'ambito. Azure Site Recovery è ideale per questi computer.

• Automatizzare le operazioni manuali il più possibile per evitare errori umani, soprattutto quando sono sotto pressione. Ti consigliamo di:

  • Adottare il provisioning delle risorse tramite bicep, modelli di Azure Resource Manager o script di PowerShell.

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

  • Usare pipeline di rilascio continuo e integrazione continua anziché select-ops.

• Poiché si dispone di un piano per il failover, è consigliabile prendere in considerazione le procedure per eseguire il fallback alle istanze primarie.

• Definire indicatori e metriche chiari per verificare che il failover sia riuscito e che le soluzioni siano operative. Verificare che le prestazioni siano tornate normali, note anche come funzionalità primarie.

• Decidere se i contratti di servizio devono rimanere invariati dopo un failover o se si consente una riduzione temporanea della qualità del servizio. Questa decisione dipende notevolmente dal processo di servizio aziendale supportato. Ad esempio, il failover per un sistema di prenotazione sala è molto diverso da un sistema operativo principale.

• Basare una definizione RTO o RPO su scenari utente specifici anziché a livello di infrastruttura. Questo approccio offre una maggiore granularità per determinare quali processi e componenti è necessario classificare in ordine di priorità per il ripristino durante un'interruzione o un'emergenza.

• Assicurarsi di eseguire controlli della capacità nell'area di destinazione prima di procedere con un failover. In un'emergenza grave, molti clienti potrebbero tentare di eseguire il failover nella stessa area abbinata contemporaneamente. Questo scenario può comportare ritardi o conflitti nel provisioning delle risorse. Se questi rischi sono inaccettabili, prendere in considerazione una strategia di ripristino di emergenza attiva/attiva o attiva/passiva.

• È necessario creare e gestire un piano di ripristino di emergenza per documentare il processo di ripristino e i proprietari delle azioni. Tenere presente che alcuni membri del team potrebbero essere in congedo e assicurarsi che siano inclusi i contatti secondari.

• 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 backup di dati e configurazioni per assicurarsi che siano adatti allo scopo, il che significa che sono adatti ed efficaci per l'uso previsto. Questo processo garantisce che possano supportare le attività di ripristino.

• La collaborazione anticipata con i team responsabili del provisioning di rete, identità e risorse facilita l'accordo sulla soluzione più ottimale per:

  • Reindirizzare utenti e traffico dal sito primario al sito secondario. È possibile valutare concetti come il reindirizzamento di Domain Name System o l'uso di strumenti specifici come Gestione traffico di Azure .

  • Fornire l'accesso e i diritti al sito secondario in modo tempestivo e sicuro.

• In caso di emergenza, una comunicazione efficace tra le molte parti coinvolte è fondamentale per l'attuazione efficiente e rapida del piano. Teams potrebbe includere:

  • Decision maker.
  • Team di risposta agli eventi imprevisti.
  • Utenti interni e team interessati.
  • Team esterni.

• L'orchestrazione delle diverse risorse al momento giusto garantisce l'efficienza nell'implementazione del piano di ripristino di emergenza.

Considerazioni

Antipattern

• Copiare/incollare questa serie di articoli

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

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

• Considerare il ripristino di emergenza come processo di sola tecnologia

  Gli stakeholder aziendali sono fondamentali per definire i requisiti per il ripristino di emergenza e completare i passaggi di convalida aziendali necessari per confermare un ripristino del servizio.

  Garantire che gli stakeholder aziendali siano coinvolti in tutte le attività di ripristino di emergenza forniscano un processo di ripristino di emergenza adatto allo scopo, rappresenti il valore aziendale ed è implementabile.

• Piani di ripristino di emergenza "Impostare e dimenticare"

  Azure è in continua evoluzione, così come i singoli clienti usano vari componenti e servizi. Un processo di ripristino di emergenza adatto per scopi deve evolversi con loro.

  I clienti devono rivalutare regolarmente il piano di ripristino di emergenza tramite il ciclo di vita dello sviluppo software o revisioni periodiche. Questa strategia mantiene il piano di ripristino del servizio valido e risolve correttamente eventuali modifiche tra componenti, servizi o soluzioni.

• Valutazioni basate su carta

  La simulazione end-to-end di un evento di ripristino di emergenza è difficile da eseguire in un ecosistema di dati moderno. Tuttavia, gli sforzi devono essere effettuati per ottenere il più vicino possibile a una simulazione completa tra i componenti interessati.

  Le esercitazioni pianificate regolarmente aiutano un'organizzazione a sviluppare la capacità istintiva di implementare in modo sicuro il piano di ripristino di emergenza.

• Affidarsi a Microsoft per eseguire tutte le operazioni

  All'interno dei servizi di Microsoft Azure esiste una chiara divisione delle responsabilità, ancorata dal livello di servizio cloud usato.

  

  Anche se viene usato uno stack completo di software come servizio , il cliente mantiene la responsabilità di garantire che gli account, le identità e i dati siano corretti e up-to-date, insieme ai dispositivi usati per interagire con i servizi di Azure.

Ambito e strategia degli eventi

Ambito eventi di emergenza

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 di emergenza

Esistono quattro opzioni generali per una strategia di ripristino di emergenza:

• Attendere Microsoft

  Come suggerisce il nome, la soluzione è offline fino al ripristino completo dei servizi nell'area interessata da Microsoft. Dopo il ripristino, il cliente convalida la soluzione e viene quindi aggiornata per garantire il ripristino del servizio.

• Ridistribuire in caso di emergenza

  La soluzione viene ridistribuito manualmente come nuova distribuzione in un'area disponibile dopo un evento di emergenza.

• Riserva calda (attiva/passiva)

  Una soluzione ospitata secondaria viene creata in un'area alternativa e i componenti vengono distribuiti per garantire una capacità minima. Tuttavia, i componenti non ricevono traffico di produzione.

  I servizi secondari nell'area alternativa potrebbero essere disattivati o eseguiti a un livello di prestazioni inferiore fino a quando non si verifica un evento di ripristino di emergenza.

• Riserva a caldo (attiva/attiva)

  La soluzione è ospitata in una configurazione attiva/attiva in più aree. La soluzione ospitata secondaria riceve, elabora e gestisce i dati come parte del sistema più ampio.

Effetti della strategia di ripristino di emergenza

Il costo operativo attribuito ai livelli più elevati di resilienza del servizio spesso svolge un ruolo importante nella decisione di progettazione chiave per una strategia di ripristino di emergenza, ma è necessario considerare anche altri fattori importanti.

Lo scenario di ripristino di emergenza per questo esempio ha funzionato è un'interruzione completa dell'area di Azure che influisce direttamente sull'area primaria che ospita contoso Data Platform.

La tabella seguente è un confronto tra le opzioni. Una strategia con un indicatore verde è migliore per tale classificazione rispetto a una strategia con un indicatore arancione o rosso.

Chiave di classificazione

Per questo scenario di interruzione, l'impatto relativo sulle quattro strategie di ripristino di emergenza di alto livello si basa sui fattori seguenti:

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

• Complessità da eseguire: Complessità per l'organizzazione di eseguire le attività di ripristino.

• Complessità da implementare: complessità per l'organizzazione per implementare la strategia di ripristino di emergenza.

• Impatto del cliente: Impatto diretto sui clienti del servizio piattaforma dati dalla strategia di ripristino di emergenza.

• Costo OPEX sopra la riga: Il costo aggiuntivo previsto dall'implementazione di questa strategia, ad esempio l'aumento della fatturazione mensile per Azure per componenti aggiuntivi e risorse aggiuntive necessarie per supportare.

Passaggi successivi

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

Risorse correlate

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