Continuità aziendale e ripristino di emergenza per l'analisi su scala cloud

  • Articolo

Quando si progetta l'architettura per un servizio cloud, considerare i requisiti di disponibilità e come rispondere alle potenziali interruzioni del servizio. Un problema potrebbe essere localizzato nell'istanza specifica o a livello di area. È importante disporre di strategie per entrambi i contesti. In base agli obiettivi del punto di ripristino e del tempo di ripristino, è possibile scegliere una strategia aggressiva per la disponibilità elevata e il ripristino di emergenza.

La disponibilità elevata e il ripristino di emergenza possono talvolta essere combinati. Le due aree hanno strategie leggermente diverse, soprattutto per quanto riguarda i dati. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework e i relativi principi di affidabilità.

Invece di tentare di evitare gli errori, accettare in anticipo che possano verificarsi e che si verificheranno. Ridurre al minimo gli effetti di un singolo componente in errore nel ciclo di vita. La tolleranza per il costo, l'obiettivo del punto di ripristino e del tempo di ripristino determinano il tipo di soluzione da implementare.

Strategie di backup

Sono disponibili molte strategie alternative per implementare il calcolo distribuito in aree diverse. Le strategie devono essere adattate ai requisiti aziendali e ai casi dell'applicazione. Gli approcci possono in generale ricadere nelle categorie seguenti:

  • Backup e ripristino: ripristinare l'applicazione di database dall'ultima copia di backup prima dell'emergenza. Questo approccio viene comunemente usato in seguito al danneggiamento o all'eliminazione accidentale dei dati.

  • Ridistribuzione in caso di emergenza: ridistribuire l'applicazione da zero al momento dell'emergenza. Questo approccio è adatto per applicazioni non critiche che non richiedono un tempo di ripristino garantito.

  • Warm Spare (attiva/passiva): creare un servizio ospitato secondario in un'area alternativa. Distribuire i ruoli per garantire una capacità minima. I ruoli non ricevono il traffico di produzione. Questo approccio è utile per le applicazioni che non sono state progettate per distribuire il traffico tra le aree.

  • Hot Spare (attiva/attiva): progettare l'applicazione per ricevere il carico di produzione in più aree. Può essere necessario configurare i servizi cloud di ogni area per una capacità superiore a quella richiesta per scopi di ripristino di emergenza. In alternativa, è possibile aumentare il numero di istanze dei servizi cloud in base alle esigenze in caso di emergenza e failover.

    Questo approccio richiede investimenti nella progettazione dell'applicazione, ma offre alcuni vantaggi. Offre tempi di ripristino ridotti e garantiti. Sono disponibili test continui di tutte le posizioni di ripristino e un utilizzo efficiente della capacità. Per le applicazioni di database, questo approccio include un servizio di bilanciamento del carico per due database sincronizzati con un singolo punto di connessione.

Ripristino di emergenza e disponibilità elevata per i servizi di Azure

Le sezioni seguenti illustrano diversi servizi di Azure.

Azure Cosmos DB

Per una panoramica della disponibilità elevata con Azure Cosmos DB, vedere Ottenere la disponibilità elevata con Azure Cosmos DB.

Azure Data Factory

È probabile che nelle integrazioni dei dati e nei prodotti dati i repository di Azure DevOps siano collegati ad Azure Data Factory. È possibile distribuire pipeline in un'altra istanza di Data Factory con tempi di inattività minimi. Per usare il software di controllo della versione del codice oltre ai repository GitHub e Azure DevOps, usare Azure Data Factory SDK per creare pipeline e altri oggetti di Azure Data Factory.

Azure Data Lake

Azure Data Lake Storage Gen2 dispone già del supporto per la replica 3 volte per garantire protezione in caso di errori hardware localizzati. Altre opzioni di replica, ad esempio l'archiviazione con ridondanza della zona (ZRS) o l'archiviazione con ridondanza geografica della zona (GZRS), consentono di ottimizzare la disponibilità elevata. L'archiviazione con ridondanza geografica e l'archiviazione con ridondanza geografica e accesso in lettura consentono di ottimizzare il ripristino di emergenza. Per la disponibilità elevata, in caso di interruzione del servizio, il carico di lavoro deve accedere ai dati più recenti il più rapidamente possibile. Il carico di lavoro può passare a un'istanza replicata in locale o in una nuova area.

Un account di archiviazione configurato come RA-GRS o GRS può essere parte di un piano di ripristino di emergenza, ma richiede la due diligence analizzando l'obiettivo del punto di ripristino (RPO) e l'obiettivo del tempo di ripristino (RTO) e esaminando altre opzioni, ad esempio uno scenario di doppio caricamento che copia i dati in due aree di Azure diverse.

Ogni zona di destinazione dei dati deve avere un obiettivo del punto di ripristino per i propri prodotti dati. Ogni zona di destinazione dei dati deve avere una strategia di replica definita per i relativi casi d'uso.

Nota

Il failover dell'account gestito dal cliente non è ancora supportato negli account con uno spazio dei nomi gerarchico (Azure Data Lake Storage Gen2).

In caso di un'emergenza che influisce sull'area primaria, Microsoft gestirà il failover per gli account con uno spazio dei nomi gerarchico.

Per altre informazioni, vedere Ripristino di emergenza e failover dell'account di archiviazione.

Azure Databricks

Per una panoramica di un'architettura di ripristino di emergenza per i cluster di Azure Databricks, vedere Ripristino di emergenza a livello di area per i cluster di Azure Databricks.

Azure Machine Learning

Per una panoramica della disponibilità elevata con Azure Machine Learning, vedere Failover per la continuità aziendale e il ripristino di emergenza.

Insieme di credenziali chiave di Azure

Azure Key Vault fornisce diverse funzionalità che aiutano a mantenere la disponibilità ed evitare la perdita di dati. Il backup dei segreti deve essere eseguito solo in presenza di una motivazione aziendale critica. Il backup dei segreti nell'insieme di credenziali delle chiavi può infatti comportare una serie di problemi operativi, come la gestione di più set di log, autorizzazioni e backup quando i segreti scadono o ruotano. Per altre informazioni, vedere Backup di Azure Key Vault.

Key Vault mantiene la disponibilità in scenari di emergenza. Viene effettuato il failover delle richieste a un'area abbinata senza alcun intervento da parte dell'utente. Per altre informazioni, vedere Disponibilità e ridondanza in Azure Key Vault. In alternativa, è possibile archiviare segreti e altri artefatti di Key Vault in un insieme di credenziali secondario con le autorizzazioni appropriate. Questo modello può essere adatto per le applicazioni che richiedono che l'insieme di credenziali si presenti nella stessa area dell'applicazione.

Database SQL di Azure

Per una panoramica della continuità aziendale con database SQL di Azure, vedere Panoramica della continuità aziendale con database SQL di Azure.

Azure Synapse Analytics

Per una panoramica della continuità aziendale con Azure Synapse Analytics, vedere Disponibilità elevata per Azure Synapse Analytics.

Passaggi successivi