Condividi tramite

Continuità aziendale e ripristino di emergenza

  • Articolo

I carichi di lavoro dell'organizzazione e delle applicazioni aziendali hanno requisiti di obiettivo del tempo di ripristino (RTO) e obiettivo del punto di ripristino (RPO). Una progettazione efficace per continuità aziendale e ripristino di emergenza (BCDR) offre funzionalità a livello di piattaforma che soddisfano questi requisiti. Per progettare funzionalità BCDR, acquisire i requisiti di ripristino di emergenza (DR) della piattaforma.

Considerazioni relative alla progettazione

Quando si progetta il BCDR per carichi di lavoro dell'applicazione, considerare i fattori seguenti:

  • Requisiti di disponibilità delle applicazioni e dei dati:

    • Requisiti RTO e RPO per ogni carico di lavoro.
    • Supporto per modelli di disponibilità attivo-attivo e attivo-passivo.

  • BCDR come servizio per servizi PaaS (platform-as-a-service):

    • Supporto nativo per il ripristino di emergenza e la disponibilità elevata (HA).
    • Funzionalità di replica geografica e ripristino di emergenza per i servizi PaaS.

  • Supporto per distribuzioni in più aree per il failover, con prossimità dei componenti per le prestazioni.

  • Operazioni dell'applicazione con funzionalità o prestazioni ridotte durante un'interruzione del servizio.

  • Idoneità del carico di lavoro per le zone di disponibilità o set di disponibilità:

    • Condivisione dei dati e dipendenze tra zone.
    • Impatto sui domini di aggiornamento delle zone di disponibilità rispetto ai set di disponibilità.
    • Percentuale di carichi di lavoro che possono essere in manutenzione contemporaneamente.
    • Supporto delle zone di disponibilità per unità SKU di macchine virtuali (VM) specifiche. Ad esempio, l'Archiviazione su disco Ultra di Azure richiede l'uso di zone di disponibilità.

  • Backup coerenti per applicazioni e dati:

    • Snapshot di macchine virtuali.
    • Insiemi di credenziali di Servizi di ripristino di Backup di Azure.
    • Limiti delle sottoscrizioni che restringono il numero di insiemi di credenziali di Servizi di ripristino e le dimensioni di ogni insieme di credenziali.

  • Connettività di rete in caso di failover:

    • Pianificazione della capacità della larghezza di banda di Azure ExpressRoute.
    • Routing del traffico durante un'interruzione a livello di area, di zona o di rete.

  • Failover pianificati e non pianificati:

    • Requisiti di coerenza degli indirizzi IP e la potenziale necessità di gestire gli indirizzi IP dopo il failover e il failback.
    • Gestione delle funzionalità di ingegneria di DevOps.
    • Ripristino di emergenza di Azure Key Vault per chiavi, certificati e segreti dell'applicazione.

  • Residenza dei dati:

    • Informazioni sulle linee guida in paese/area geografica per la residenza dei dati che specifica se i dati devono essere conservati entro i confini nazionali o regionali. Queste indicazioni influiscono sulla progettazione per la replica tra aree.
    • Le aree di Azure che si trovano nella stessa area geografica del set abilitato possono essere utili per la replica tra aree per soddisfare i requisiti di residenza dei dati, ad esempio i requisiti fiscali e di imposizione della legge. Per altre informazioni, vedere Replica tra aree di Azure.

Suggerimenti per la progettazione

Le seguenti procedure di progettazione supportano continuità aziendale e ripristino di emergenza per i carichi di lavoro dell'applicazione:

  • Usare Azure Site Recovery per scenari di ripristino di emergenza di macchine virtuali da Azure ad Azure.

    Site Recovery usa la replica in tempo reale e l'automazione del ripristino per replicare i carichi di lavoro tra aree. Le funzionalità integrate della piattaforma per i carichi di lavoro delle macchine virtuali soddisfano requisiti RPO e RTO bassi. È possibile usare Site Recovery per eseguire esercitazioni di ripristino senza influire sui carichi di lavoro di produzione. È anche possibile usare Criteri di Azure per abilitare la replica e controllare la protezione delle macchine virtuali.

  • Usare le funzionalità di ripristino di emergenza PaaS native.

    Le funzionalità PaaS integrate semplificano l'automazione della progettazione e della distribuzione per la replica e il failover nelle architetture dei carichi di lavoro. Le organizzazioni che definiscono gli standard di servizio possono anche controllare e applicare la configurazione del servizio mediante Criteri di Azure.

  • Usare le funzionalità di backup native di Azure.

    Backup di Azure e le funzionalità di backup native PaaS eliminano la necessità di software e infrastruttura di backup di terze parti. Come per altre funzionalità native, è possibile impostare, controllare e applicare configurazioni di backup con Criteri di Azure per garantire la conformità ai requisiti dell'organizzazione.

  • Usare più aree e posizioni di peering per la connettività di ExpressRoute.

    Un'architettura di rete ibrida ridondante può garantire una connettività cross-premise senza interruzioni se si verifica un'interruzione che interessa un'area di Azure o una posizione del provider di peering.

  • Evitare di usare intervalli di indirizzi IP sovrapposti nelle reti di produzione e ripristino di emergenza.

    Le reti di produzione e ripristino di emergenza con indirizzi IP sovrapposti richiedono un processo di failover che può complicare e ritardare il failover dell'applicazione. Quando possibile, pianificare un'architettura di rete BCDR che fornisca connettività simultanea a tutti i siti.