Continuità aziendale e ripristino di emergenza

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 le capacità BCDR, identificare i requisiti di ripristino di emergenza (DR) della piattaforma.

Considerazioni sulla 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 i modelli di disponibilità active-active e active-passive.

• 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 il failover nelle distribuzioni in più aree, con la prossimità dei componenti per migliorare le prestazioni.

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

• Idoneità dei carichi di lavoro per zone di disponibilità o set di disponibilità:

  • Condivisione dei dati e dipendenze tra zone.
  • Confronto tra zone di disponibilità e set di disponibilità: impatto sui domini di aggiornamento.
  • Percentuale di carichi di lavoro che possono essere in manutenzione contemporaneamente.
  • Supporto delle zone di disponibilità per SKU specifici di macchine virtuali (VM). 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.
  • Archivi dei Servizi di ripristino di Backup di Azure.
  • Limiti delle sottoscrizioni che restringono il numero di cassaforti di Servizi di ripristino e la dimensione di ciascuna cassaforte.

• 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.
  • DR di Azure Key Vault per chiavi, certificati e segreti dell'applicazione.

• Residenza dei dati:

  • Comprendere le indicazioni per la residenza dei dati all'interno del paese o dell'area geografica che specificano se i dati devono essere conservati all'interno dei confini di un paese o di un'area geografica. Queste indicazioni influiscono sulla progettazione della 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, come i requisiti fiscali e di applicazione della legge. Per altre informazioni, vedere Replica tra aree di Azure.

Consigli per la progettazione

Le seguenti procedure di progettazione supportano la BCDR (continuità aziendale e ripristino di emergenza) per i carichi di lavoro delle applicazioni:

• Usare Azure Site Recovery per scenari di disaster recovery di macchine virtuali da Azure a 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.

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

  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 disaster recovery.

  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 fornisce connettività simultanea a tutti i siti.