Le emergenze possono essere errori hardware, calamità naturali o errori software. Il processo di preparazione e ripristino da un'emergenza è denominato ripristino di emergenza. Questo articolo illustra le procedure consigliate per ottenere la continuità aziendale e il ripristino di emergenza (BCDR) per le pipeline di Azure Data Factory e Azure Synapse Analytics.
Le strategie BCDR includono la ridondanza della zona di disponibilità, il ripristino automatizzato fornito dal ripristino di emergenza di Azure e il ripristino gestito dall'utente usando l'integrazione continua e il recapito continuo (CI/CD).
Architettura
Scaricare un file di Visio di questa architettura.
Workflow
Le pipeline di Data Factory e Azure Synapse ottengono resilienza usando aree di Azure e zone di disponibilità di Azure.
- Ogni area di Azure dispone di un set di data center distribuiti all'interno di un perimetro definito dalla latenza.
- le zone di disponibilità di Azure sono posizioni fisicamente separate all'interno di ogni area di Azure, con tolleranza per gli errori locali.
- Tutte le aree e le zone di disponibilità di Azure sono connesse tramite una rete a bassa latenza dedicata a livello di area e da una rete ad alte prestazioni.
- Tutte le aree abilitate dalla zona di disponibilità hanno almeno tre zone di disponibilità separate per garantire la resilienza.
Quando un data center, parte di un data center o una zona di disponibilità in un'area diventa inattivo, il failover si verifica con tempi di inattività zero per data factory resilienti alla zona e alle pipeline di Azure Synapse.
Componenti
Dettagli dello scenario
Data Factory e pipeline di Azure Synapse archivia gli artefatti che includono i dati seguenti:
Metadati UFX
- Pipeline
- Set di dati
- Servizi collegati
- Runtime di integrazione
- Trigger
Dati di monitoraggio
- Pipeline
- Trigger
- Esecuzioni attività
I disastri possono colpire in modi diversi, ad esempio errori hardware, calamità naturali o errori software che derivano da errori umani o cyberattacchi. A seconda dei tipi di errori, l'impatto geografico può essere regionale o globale. Quando si pianifica una strategia di ripristino di emergenza, prendere in considerazione sia la natura dell'emergenza che l'impatto geografico.
BCDR in Azure funziona su un modello di responsabilità condivisa. Molti servizi di Azure richiedono ai clienti di configurare in modo esplicito la strategia di ripristino di emergenza, mentre Azure fornisce l'infrastruttura di base e i servizi della piattaforma in base alle esigenze.
È possibile usare le procedure consigliate seguenti per ottenere BCDR per Data Factory e pipeline di Azure Synapse in diversi scenari di errore. Per l'implementazione, consultare la sezione Distribuzione di questo scenario.
Ripristino automatico con ripristino di emergenza di Azure
Con il ripristino automatico fornito Backup di Azure e ripristino di emergenza, quando si verifica un'interruzione completa a livello di area per un'area di Azure con un'area abbinata, le pipeline di Data Factory o Azure Synapse e il failover automatico nell'area abbinata quando si configura il ripristino automatico. Le eccezioni sono le aree Asia sud-orientale e Brasile, in cui i requisiti di residenza dei dati richiedono che i dati rimangano in tali aree.
Nel failover di ripristino di emergenza, Data Factory recupera le pipeline di produzione. Se è necessario convalidare le pipeline ripristinate, è possibile eseguire il backup dei modelli di Azure Resource Manager per le pipeline di produzione nell'archiviazione privata e confrontare le pipeline ripristinate con i backup.
Il team globale di Azure esegue regolari esercitazioni BCDR e Azure Data Factory e Azure Synapse Analytics partecipano a queste esercitazioni. L'esercitazione BCDR simula un errore di area e esegue il failover dei servizi di Azure in un'area abbinata senza alcun coinvolgimento dei clienti. Per maggiori informazioni sulle esercitazioni BCDR, consultare la sezione Test dei servizi.
Ridondanza gestita dall'utente con CI/CD
Per ottenere BCDR in caso di errore di un'intera area, è necessaria una data factory o un'area di lavoro di Azure Synapse nell'area secondaria. In caso di eliminazione accidentale di data factory o di pipeline di Azure Synapse, interruzioni o eventi di manutenzione interni, è possibile usare Git e CI/CD per ripristinare manualmente le pipeline.
Facoltativamente, è possibile usare un'implementazione attiva/passiva. L'area primaria gestisce le normali operazioni e rimane attiva, mentre l'area di ripristino di emergenza secondaria richiede passaggi pre-pianificati, a seconda dell'implementazione specifica, da promuovere come primario. In questo caso, tutte le configurazioni necessarie per l'infrastruttura sono disponibili nell'area secondaria, ma non vengono sottoposte a provisioning.
Potenziali casi d'uso
La ridondanza gestita dall'utente è utile in scenari come:
- Eliminazione accidentale degli artefatti della pipeline tramite l'errore umano.
- Interruzioni estese o eventi di manutenzione che non attivano BCDR perché non sono state segnalate emergenze.
È possibile spostare rapidamente i carichi di lavoro di produzione in altre aree e non essere interessati.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Affidabilità
L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.
Le pipeline di Data Factory e Azure Synapse sono servizi di Azure mainstream che supportano le zone di disponibilità e sono progettati per offrire il giusto livello di resilienza e flessibilità, oltre a una latenza ultra bassa.
L'approccio di ripristino gestito dall'utente consente di continuare a funzionare se sono presenti eventi di manutenzione, interruzioni o errori umani nell'area primaria. Usando CI/CD, la data factory e le pipeline di Azure Synapse possono integrarsi in un repository Git e distribuirli in un'area secondaria per il ripristino immediato.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
Il ripristino gestito dall'utente integra Data Factory con Git usando CI/CD e, facoltativamente, usa un'area di ripristino di emergenza secondaria con tutte le configurazioni dell'infrastruttura necessarie come backup. Questo scenario potrebbe comportare costi aggiuntivi. Per una stima dei costi, usare il calcolatore dei prezzi di Azure.
Per esempi di prezzi di Data Factory e Azure Synapse Analytics, vedere:
Eccellenza operativa
L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.
Usando l'approccio di ripristino CI/CD gestito dall'utente, è possibile eseguire l'integrazione in Azure Repos o GitHub. Per maggiori informazioni sulle procedure CI/CD, consultare la sezione Pratiche consigliate per CI/CD.
Distribuire lo scenario
Eseguire le azioni seguenti per configurare il ripristino di emergenza automatizzato o gestito dall'utente per data factory e le pipeline di Azure Synapse.
Configurare il ripristino automatico
In Data Factory è possibile impostare l'area del runtime di integrazione di Azure per l'esecuzione o l'invio dell'attività nella configurazione del runtime di integrazione. Per abilitare il failover automatico in caso di interruzione completa a livello di area, impostare l'Area su Risoluzione automatica.
Nel contesto dei runtime di integrazione, il runtime di integrazione esegue automaticamente il failover nell'area associata quando si seleziona Risoluzione automatica come area del runtime di integrazione. Per altre aree geografiche specifiche, è possibile creare una data factory secondaria in un'altra area e usare CI/CD per effettuare il provisioning della data factory dal repository Git.
Per le reti virtuali gestite, Data Factory passa automaticamente anche al runtime di integrazione gestito.
Il failover automatico gestito di Azure non si applica al runtime di integrazione self-hosted (SHIR), perché l'infrastruttura è gestita dal cliente. Per indicazioni sulla configurazione di più nodi per una maggiore disponibilità con SHIR, consultare la sezione Creazione e configurazione di un runtime di integrazione self-hosted.
Per configurare BCDR per Azure-SSIS IR, consultare la sezione Configurazione del runtime di integrazione Azure-SSIS per la continuità aziendale e il ripristino di emergenza (BCDR).
I servizi collegati non sono completamente abilitati dopo il failover, a causa di endpoint privati in sospeso nella rete più recente dell'area. È necessario configurare gli endpoint privati nell'area ripristinata. È possibile automatizzare la creazione di endpoint privati usando l'API di approvazione.
Configurare il ripristino gestito dall'utente tramite CI/CD
È possibile usare Git e CI/CD per ripristinare manualmente le pipeline in caso di eliminazione o interruzione della pipeline di Azure Synapse.
Per usare la pipeline di Data Factory, consultare la sezione Integrazione continua e recapito in Azure Data Factory e Controllo del codice sorgente in Azure Data Factory.
Per usare CI/CD della pipeline di Azure Synapse, consultare la sezione Integrazione e recapito continui per un'area di lavoro di Azure Synapse Analytics. Assicurarsi di inizializzare prima l'area di lavoro di Azure Synapse. Per altre informazioni, vedere Controllo del codice sorgente in Synapse Studio.
Quando si distribuisce la ridondanza gestita dall'utente usando CI/CD, eseguire le azioni seguenti:
Disabilitare i trigger
Disabilitare i trigger nella data factory primaria originale quando torna online. È possibile disabilitare i trigger manualmente o implementare l'automazione per controllare periodicamente la disponibilità del database primario originale. Disabilitare tutti i trigger nella data factory primaria originale immediatamente dopo il ripristino della factory.
Per usare Azure PowerShell per disattivare o attivare i trigger di Data Factory, consultare la sezione Esempi di script di pre-distribuzione e miglioramenti di CI/CD correlati alla distribuzione dei trigger della pipeline.
Gestire le scritture duplicate
La maggior parte delle pipeline di estrazione, trasformazione, caricamento (ETL) è progettata per gestire le scritture duplicate, perché il backfill e il ripristino ne richiedono il riempimento. I sink di dati che supportano il failover trasparente possono gestire scritture duplicate con record merge o eliminando e inserendo tutti i record nell'intervallo di tempo specifico.
Per i sink di dati che modificano gli endpoint dopo il failover, l'archiviazione primaria e secondaria potrebbe avere dati duplicati o parziali. Sarà necessario unire i dati manualmente.
Controllare il server di controllo del mirroring e controllare il flusso della pipeline (facoltativo)
In generale, è necessario progettare le pipeline per includere attività, ad esempio attività di fail e ricerca, per il riavvio delle pipeline non riuscite dal punto di interesse.
Aggiungere un parametro globale nella data factory per indicare l'area, ad esempio
region='EastUS'nella data factory primaria eregion='CentralUS'nella data factory secondaria.Creare un server di controllo del mirroring in una terza area. Il server di controllo del mirroring può essere una chiamata REST o qualsiasi tipo di archiviazione. Per impostazione predefinita, il server di controllo del mirroring restituisce l'area primaria corrente, ad esempio
'EastUS'.Quando si verifica un'emergenza, aggiornare manualmente il server di controllo del mirroring per restituire la nuova area primaria, ad esempio
'CentralUS'.Aggiungere un'attività nella pipeline per cercare il server di controllo del mirroring e confrontare il valore primario corrente con il parametro globale.
- Se i parametri corrispondono, questa pipeline viene eseguita nell'area primaria. Procedere con il lavoro reale.
- Se i parametri non corrispondono, questa pipeline viene eseguita nell'area secondaria. Restituire il risultato.
Nota
Questo approccio introduce una dipendenza dalla ricerca del server di controllo del mirroring nella pipeline. Impossibile leggere, il server di controllo del mirroring interrompe tutte le esecuzioni della pipeline.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
Krishnakumar Rukmangathan | Senior Program Manager - Team di Azure Data Factory
Sunil Sabat | Principal Program Manager - Team di Azure Data Factory
Altri contributori:
Mario Zimmermann | Principal Software Engineering Manager - Team di Azure Data Factory
Wee Hyong Tok | Direttore principale di PM - Team di Azure Data Factory
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Gestione della continuità aziendale in Azure
- Resilienza in Azure
- Terminologia relativa alla resilienza di Azure
- Aree e zone di disponibilità
- Replica tra più aree in Azure
- Guida alle decisioni sulle aree di Azure
- Servizi di Azure che supportano le zone di disponibilità
- Responsabilità condivisa nel cloud
- Ridondanza dei dati di Azure Data Factory
- Runtime di integrazione in Azure Data Factory
- Pipeline e attività in Azure Data Factory e Azure Synapse Analytics
- Integrazione dei dati in Azure Synapse Analytics e Azure Data Factory
Risorse correlate
- Ripristino di emergenza di livello aziendale
- Ripristino di emergenza per piccole e medie imprese con Azure Site Recovery
- Introdurre la disponibilità elevata nella strategia di continuità aziendale e ripristino di emergenza
- Scegliere una tecnologia di orchestrazione della pipeline di dati in Azure
- Continuità aziendale e ripristino di emergenza per App per la logica di Azure