Ripristino di emergenza

Il ripristino di emergenza per Azure Databricks replica le aree di lavoro, i dati e le configurazioni tra aree cloud, in modo che i team continuino a lavorare quando un'interruzione a livello di area porta offline la distribuzione primaria. Un piano di ripristino di emergenza (DR) completo comprende non solo Azure Databricks, ma anche le fonti di dati, gli strumenti di acquisizione dei dati, gli strumenti di business intelligence e gli strumenti di pianificazione a cui è connesso.

Questa pagina illustra i concetti, le strategie, gli strumenti e le procedure di test necessari per progettare ed eseguire una soluzione di ripristino di emergenza tra aree.

Non hai familiarità con la pianificazione DR? Iniziare con la terminologia del settore del ripristino di emergenza per le definizioni di RPO e RTO.

Importante

Usare il ripristino di emergenza gestito. Azure Databricks consiglia il ripristino di emergenza gestito per il ripristino di emergenza tra aree in AWS e Azure. Questo servizio replica i metadati di Unity Catalog, i dati delle tabelle gestite e gli asset dell'area di lavoro secondo una pianificazione continua, fornisce un URL stabile che rimane invariato anche dopo il failover e consente di attivare il failover dalla console dell'account. Nessun script di replica da scrivere o gestire. Usa le istruzioni fai-da-te in questa pagina solo per le risorse che il ripristino di emergenza gestito non replica, oppure se ti servono topologie active-active, replicazione tra cloud o un controllo granulare sulla pipeline di replicazione.

Garanzie di disponibilità elevata all'interno dell'area

Il resto di questa pagina riguarda il ripristino di emergenza tra aree geografiche, ma Azure Databricks offre anche alta disponibilità (HA) all'interno di una singola area geografica. Comprendere prima queste garanzie. Determinano se è necessaria una strategia DR distinta.

HA e DR risolvono problemi diversi:

HA si avvale della ridondanza della zona di disponibilità (AZ) all'interno di un'area geografica. Se una zona si guasta, i servizi continuano a funzionare nelle altre.
DR usa la replicazione tra aree geografiche. Si eseguono aree di lavoro secondarie Azure Databricks in un'altra area e si replicano i dati e le configurazioni, quindi si esegue il failover durante un'interruzione a livello di area.

Se non è necessario il DR multiregione, la funzionalità di disponibilità elevata di Azure Databricks potrebbe essere sufficiente. L'alta disponibilità evita la complessità tra aree geografiche, ma non protegge da un'interruzione dell'intera area geografica. Se fai affidamento solo su HA per il disaster recovery, verifica la separazione e la ridondanza della tua regione cloud.

Le garanzie di alta disponibilità intra-area coprono il piano di controllo e il piano di elaborazione.

Disponibilità del piano di controllo Azure Databricks

Il piano di controllo Azure Databricks è resiliente agli errori della zona e viene ripristinato automaticamente entro circa 15 minuti da un errore di zona. I test regolari dei guasti di zona confermano questo.

Tutti i servizi del piano di controllo senza stato possono tollerare la perdita di singole macchine virtuali o di tutte le macchine virtuali in un'intera zona, senza causare l'interruzione del servizio. I dati dell'area di lavoro vengono archiviati nei database replicati tra zone nell'area. Anche gli account di archiviazione che servono le immagini di Databricks Runtime sono ridondanti all'interno dell'area e in tutte le aree sono presenti account di archiviazione secondari che prendono il controllo quando il database primario è inattivo.

Note

Le garanzie del piano di controllo sopra si applicano all'infrastruttura gestita da Azure Databricks. Sei responsabile della ridondanza del piano di calcolo tra zone di disponibilità, ad esempio scegliendo l'archiviazione con ridondanza tra zone per il bucket radice dell'area di lavoro e utilizzando pool di istanze distribuiti tra più zone di disponibilità.

Alcune aree Azure usano un piano di controllo distribuito in un'area abbinata. Vedere Azure Databricks regions.

La resilienza degli errori di zona supporta al massimo una zona inattiva ed è disponibile solo nelle aree Azure che supportano più zone.

Disponibilità del piano di calcolo

La disponibilità dell'area di lavoro dipende dalla disponibilità del piano di controllo.

I dati nella radice di DBFS non sono interessati se l'account di archiviazione è configurato con l'archiviazione con ridondanza della zona (ZRS) o con l'archiviazione con ridondanza geografica della zona (GZRS). Il valore predefinito è l'archiviazione con ridondanza geografica (GRS).

I nodi del cluster vengono estratti da zone di disponibilità diverse richiedendo nodi dal provider di calcolo Azure, presupponendo capacità sufficiente nelle zone rimanenti. Se un nodo viene perso, la gestione dei cluster richiede nodi sostitutivi dal provider di calcolo di Azure, che li estrae dalle zone di disponibilità disponibili. L'eccezione si verifica quando il nodo del driver viene perso. In tal caso, il gestore del cluster riavvia il job e il cluster.

Per confermare il supporto multi-AZ, vedere l'elenco delle aree Azure. Per la resilienza multi-AZ del piano di calcolo, utilizzare Archiviazione con Ridondanza di Zona.

Terminologia

Usate queste definizioni in modo coerente quando parlate di DR con il tuo team.

Terminologia dell'area

Terminologia di regione

Questa pagina usa le definizioni di area seguenti:

Area primaria: area in cui gli utenti eseguono carichi di lavoro di analisi dei dati interattivi e automatizzati giornalieri.
Area secondaria: area in cui i team IT spostano temporaneamente i carichi di lavoro durante un'interruzione dell'area primaria.
Archiviazione con ridondanza geografica: replica asincrona tra aree di archiviazione persistente. Consulta la documentazione del tuo cloud:

Archiviazione con ridondanza geografica tra aree (Azure).

Importante

Non fare affidamento sull'archiviazione con ridondanza geografica per duplicare tra più aree geografiche l'archiviazione radice di Azure Databricks, ad esempio ADLS (per le aree di lavoro create prima del 6 marzo 2023, Archiviazione BLOB di Azure), che Azure Databricks crea per ogni area di lavoro. Per replicare i dati della tabella gestita, usare Delta Deep Clone e per i dati non Delta, convertirli prima in Delta laddove possibile.

Terminologia relativa allo stato della distribuzione

Questa pagina usa le definizioni di stato della distribuzione seguenti:

Distribuzione attiva (talvolta denominata distribuzione ad accesso frequente): gli utenti si connettono ed eseguono carichi di lavoro. I processi e i flussi di dati vengono eseguiti qui in base alla pianificazione.
Distribuzione passiva (talvolta denominata distribuzione a freddo): non vengono eseguiti processi qui. I team IT lo mantengono pronti automatizzando la distribuzione di codice, configurazione e altri oggetti Azure Databricks. Una distribuzione passiva diventa attiva solo quando la distribuzione attiva diventa inattiva.

Importante

Un progetto può includere più distribuzioni passive in aree diverse per una maggiore resilienza.

La maggior parte dei team esegue un solo deployment attivo alla volta, ovvero la strategia active-passive. La strategia meno comune attiva-attiva esegue due distribuzioni attive simultanee.

Terminologia del settore del ripristino di emergenza

Definisci questi due termini del settore con il tuo team:

Obiettivo del punto di ripristino (RPO): periodo massimo di perdita dei dati che il servizio può tollerare durante un evento imprevisto grave. Vedere RPO.

Azure Databricks non archivia i dati primari dei clienti. Che è archiviato in ADLS (per le aree di lavoro create prima del 6 marzo 2023, in Archiviazione BLOB di Azure) o in altri sistemi sotto il tuo controllo. Il piano di controllo Azure Databricks archivia alcuni oggetti, ad esempio processi e notebook, pertanto il valore RPO Azure Databricks è il periodo massimo in cui è possibile perdere le modifiche apportate a tali oggetti. L'utente è responsabile della definizione dell'RPO per i dati dei propri clienti in ADLS (per le aree di lavoro create prima del 6 marzo 2023, Archiviazione BLOB di Azure) e per altre origini dati sotto il suo controllo.
Obiettivo del tempo di ripristino (RTO): tempo massimo entro il quale un processo aziendale deve essere ripristinato dopo un'emergenza. Vedere RTO.

Ripristino di emergenza e danneggiamento dei dati

Una soluzione di ripristino di emergenza non riduce il danneggiamento dei dati. I dati danneggiati nell'area primaria vengono replicati nell'area secondaria e sono danneggiati in entrambe le aree. Per mitigare questo tipo di guasto, usa Delta time travel, strumenti simili o strumenti per il backup dei dati.

Flusso di lavoro di ripristino tipico

Uno scenario di disaster recovery di Azure Databricks in genere si svolge come segue:

Un errore colpisce un servizio critico nell'area primaria: un'origine dati, una rete o un'altra dipendenza da cui si basa la distribuzione Azure Databricks.
Indaghi con il tuo fornitore di servizi cloud.
Se l'attesa è inaccettabile, decidi di eseguire il failover nell'area geografica secondaria.
Verificare che lo stesso problema non influisca sull'area secondaria.
Failover (per i passaggi dettagliati, vedere Failover di test):
1. Arrestare tutte le attività dell'area di lavoro. Gli utenti arrestano i carichi di lavoro ed eseguono il backup delle modifiche recenti, ove possibile. I processi si arrestino (se l'interruzione non è già riuscita).
2. Eseguire la procedura di ripristino dell'area secondaria per aggiornare il routing e reindirizzare le connessioni e il traffico di rete.
3. Reindirizzare i sistemi downstream (strumenti BI, utilità di pianificazione, integrazioni di terze parti) verso l'area di lavoro secondaria e ripristinarne le connessioni.
4. Dopo il test, dichiarare l'area secondaria operativa. Gli utenti accedono alla distribuzione ora attiva e si riattivano i processi pianificati o posticipati.
Dopo che il problema della regione primaria è stato mitigato, confermare la risoluzione.
Failback (per informazioni dettagliate, vedere Test restore (failback)):
1. Interrompere tutte le attività nella regione secondaria.
2. Eseguire la procedura di ripristino della regione primaria per reindirizzare nuovamente l'instradamento.
3. Replicare tutti i nuovi dati nella regione primaria. Ridurre al minimo ciò che deve essere replicato. Ad esempio, i processi di sola lettura eseguiti nella distribuzione secondaria potrebbero non richiedere il writeback.
4. Testa la distribuzione nell'area geografica primaria.
5. Dichiarare l'area primaria attiva e riprendere i carichi di lavoro di produzione.

Importante

Alcune perdite di dati possono verificarsi durante questi passaggi. Definire la quantità di perdita accettabile per l'organizzazione e come attenuarla.

Passaggio 1: Comprendere le esigenze aziendali

Identificare i servizi di dati critici e definire i relativi obiettivi RPO e RTO. Verifica la tolleranza di ogni sistema in condizioni reali.

Il ripristino di emergenza, il failover e il failback comportano costi e rischi reali, tra cui danneggiamento dei dati, duplicazione dei dati (scrittura nella posizione di archiviazione errata) e utenti che apportano modifiche nell'area sbagliata.

Eseguire il mapping di ogni punto di integrazione Azure Databricks che influisce sull'azienda e scegliere gli strumenti e i canali di comunicazione usati dal piano.

Punti di integrazione da mappare

La soluzione di ripristino di emergenza deve supportare processi interattivi, processi automatizzati o entrambi?
Quali servizi dati si usano? Alcuni potrebbero essere in locale.
In che modo i dati di input arrivano al cloud?
Chi utilizza questi dati? Quali processi lo usano downstream?
Esistono integrazioni di terze parti che devono tenere conto delle modifiche al DR?

Strumenti e comunicazioni da pianificare

È possibile predefinito la configurazione e renderla modulare per supportare soluzioni di ripristino di emergenza in modo naturale e gestibile?
Quali strumenti e canali di comunicazione vengono utilizzati per notificare ai team interni e a terze parti (integrazioni, sistemi a valle) le modifiche relative al failover e al failback del disaster recovery? Come confermare il loro riconoscimento?
Quali servizi, se del caso, disattivi fino al completo ripristino?

Passaggio 2: scegliere un processo che soddisfi le esigenze aziendali

Imposta come predefinito il disaster recovery gestito. Gestisce la replica dell'area di lavoro, i metadati del catalogo Unity, i dati della tabella gestita e l'orchestrazione del failover senza script personalizzati. Utilizzare la guida fai da te seguente solo se il proprio scenario non rientra nel relativo ambito, ad esempio per risorse che il DR gestito non replica, topologie attive-attive, replicazione tra cloud o controllo granulare sulla pipeline di replica.

Una soluzione DIY deve replicare i dati corretti nel piano di controllo, nel piano di calcolo e nelle origini dati. Le aree di lavoro ridondanti corrispondono a piani di controllo diversi in regioni diverse, quindi per mantenerle sincronizzate si utilizza una soluzione basata su script, ovvero uno strumento di sincronizzazione o una pipeline CI/CD. Per i dati stessi, la maggior parte dei team usa processi Azure Databricks (spesso pianificati) o Delta Deep Clone per copiare tabelle tra aree. Non è necessario sincronizzare i dati dall'interno del piano di calcolo, ad esempio dai ruoli di lavoro di Databricks Runtime.

Se si usa la funzionalità di inserimento della rete virtuale (non disponibile con tutti i tipi di sottoscrizione e distribuzione), distribuire le reti in modo coerente in entrambe le aree usando strumenti basati su modelli come Terraform.

Replica le fonti di dati tra le regioni secondo necessità.

Le soluzioni di disaster recovery in genere prevedono due (o più) aree di lavoro. Scegliere tra le strategie seguenti in base alla lunghezza dell'interruzione che è necessario tollerare, al lavoro operativo e al costo di eseguire il failback nell'area primaria.

Procedure consigliate generali

Le procedure consigliate generali per un piano di ripristino di emergenza riuscito includono:

Capire quali processi sono critici per l'azienda e devono essere eseguiti in modalità di disaster recovery.
Identificare chiaramente quali servizi sono coinvolti, quali dati vengono elaborati, qual è il flusso di dati e dove vengono archiviati.
Isolare i servizi e i dati il più possibile. Ad esempio, creare un contenitore di archiviazione cloud speciale per i dati di ripristino di emergenza o spostare gli oggetti Azure Databricks necessari durante un'emergenza in un'area di lavoro separata.
L'utente è responsabile del mantenimento dell'integrità tra le distribuzioni primarie e secondarie per gli oggetti non archiviati nel piano di controllo Azure Databricks.
Per le fonti di dati, usare gli strumenti nativi di Azure per replicare i dati nelle regioni di ripristino di emergenza, ove possibile.

Avviso

Non archiviare dati nella radice di ADLS (per le aree di lavoro create prima del 6 marzo 2023, in Archiviazione BLOB di Azure) usata per l'accesso alla radice di DBFS. L'archiviazione radice DBFS non è supportata per i dati dei clienti di produzione. Azure Databricks sconsiglia inoltre di archiviare librerie, file di configurazione o script di inizializzazione in tale posizione.

Strategia della soluzione attiva-passiva

Questa sezione è incentrata sulla strategia attiva-passiva perché è la più comune, la più semplice e la più conveniente. Una soluzione attiva-passiva sincronizza le modifiche dei dati e degli oggetti dalla distribuzione attiva a una distribuzione passiva in un'area secondaria. Durante un evento di disaster recovery, la distribuzione passiva diventa attiva.

Due varianti comuni:

Unificato (a livello aziendale): un unico set di distribuzioni attive e passive supporta l'intera organizzazione.
Per reparto o progetto: ogni dominio gestisce la propria soluzione di ripristino di emergenza con aree primarie e secondarie personalizzate in base alle proprie esigenze.

È anche possibile usare una distribuzione passiva per carichi di lavoro di sola lettura, ad esempio le query utente, che non modificano i dati o gli oggetti Azure Databricks.

Strategia della soluzione attiva-attiva

Strategia di soluzione attiva-attiva

In una soluzione attiva-attiva tutti i processi di dati vengono eseguiti in entrambe le aree in parallelo in qualsiasi momento. Il team operativo deve contrassegnare il completamento di ogni processo solo dopo l'esito positivo in entrambe le aree. Gli oggetti non possono essere modificati nell'ambiente di produzione e devono seguire un rigoroso processo CI/CD di promozione dagli ambienti di sviluppo e staging alla produzione.

Active-active è la strategia più complessa e ha costi più elevati perché i processi vengono eseguiti in entrambe le regioni, ma garantisce i valori di RTO e RPO più bassi.

È possibile implementare active-active a livello aziendale o a livello di reparto. Non è necessaria un'area di lavoro duplicata per ogni carico di lavoro. Ad esempio, le aree di lavoro di sviluppo o di gestione temporanea sono spesso più facili da ricostruire da una pipeline di sviluppo rispetto a quelle da mantenere sincronizzate.

Scegliere gli strumenti

Esistono due approcci principali per mantenere sincronizzati i dati tra le aree di lavoro nelle aree primarie e secondarie:

Client di sincronizzazione che copia da primario a secondario: un client di sincronizzazione esegue il push di dati e delle risorse di produzione dall'area primaria all'area secondaria. In genere, viene eseguita in base a una pianificazione e la frequenza della pianificazione dipende dagli obiettivi RTO e RPO prefissati.
Strumenti CI/CD per la distribuzione parallela: per il codice e le risorse di produzione, usare gli strumenti CI/CD che inseriscono le modifiche nei sistemi di produzione simultaneamente in entrambe le aree. Ad esempio, quando si esegue il push di codice e risorse dalla gestione temporanea/sviluppo alla produzione, un sistema CI/CD lo rende disponibile in entrambe le aree contemporaneamente. L'idea principale consiste nel considerare tutti gli artefatti in un'area di lavoro di Azure Databricks come infrastruttura-come-codice. La maggior parte degli artefatti potrebbe essere condivisa nelle aree di lavoro primarie e secondarie, mentre alcuni artefatti potrebbero essere distribuiti solo dopo un evento di ripristino di emergenza. Per gli strumenti, vedere Script, esempi e prototipi di automazione.

A seconda delle esigenze, è possibile combinare gli approcci. Ad esempio, usare CI/CD per il codice sorgente del notebook, ma usare la sincronizzazione per la configurazione, ad esempio pool e controlli di accesso.

Nella tabella seguente viene descritto come gestire ogni tipo di dati con ogni opzione di strumenti.

Descrizione	Come gestire gli strumenti CI/CD	Come gestire con lo strumento di sincronizzazione
Codice sorgente: esportazioni del codice sorgente del notebook e codice sorgente per le librerie impacchettate	Eseguire il co-deployment sia nel sistema primario che secondario.	Sincronizzare il codice sorgente da primario a secondario.
Utenti e gruppi	Gestire i metadati come configurazione in Git. In alternativa, usare lo stesso provider di identità (IdP) per entrambe le aree di lavoro. Distribuire contemporaneamente i dati di utenti e gruppi nelle distribuzioni primarie e secondarie.	Usare SCIM o un'altra automazione per entrambe le aree. La creazione manuale non è consigliata, ma se usata deve essere eseguita per entrambi allo stesso tempo. Se si usa una configurazione manuale, creare un processo automatizzato pianificato per confrontare l'elenco di utenti e gruppi tra le due distribuzioni.
Configurazioni dei pool	Può essere un modello in Git. Distribuzione congiunta nel primario e nel secondario. Tuttavia, `min_idle_instances` nel secondario deve essere zero fino all'evento di disaster recovery.	I pool creati con qualsiasi elemento `min_idle_instances` quando vengono sincronizzati con un'area di lavoro secondaria usando l'API o la CLI.
Configurazioni di lavoro	Usa Databricks Asset Bundles con target per ambiente (ad esempio, `prod` e `dr`) per distribuire la stessa definizione del job in entrambe le regioni. Per la distribuzione secondaria, impostare la concorrenza su zero in modo che il processo venga gestito a fasi ma non venga eseguito. Modificare il valore di concorrenza dopo che la distribuzione secondaria diventa attiva.	Se, per qualche motivo, i processi vengono eseguiti su cluster esistenti `<interactive>`, il client di sincronizzazione deve effettuare il mapping al corrispondente `cluster_id` nell'area di lavoro secondaria.
Elenchi di controllo di accesso (ACL)	Può essere un modello in Git. Co-distribuzione in distribuzioni primarie e secondarie per notebook, cartelle e cluster. Tuttavia, conservare i dati per i job fino all'evento di disaster recovery.	L'API Autorizzazioni può impostare controlli di accesso per cluster, processi, pool, notebook e cartelle. Un client sincronizzazione deve associare gli ID degli oggetti corrispondenti per ogni oggetto nell'area di lavoro secondaria. Databricks consiglia di creare una mappa di ID oggetto dall'area di lavoro primaria a quella secondaria durante la sincronizzazione di tali oggetti prima di replicare i controlli di accesso.
Librerie	Includere nel codice sorgente e nei modelli di cluster/lavoro.	Sincronizzare librerie personalizzate da repository centralizzati, DBFS o archiviazione cloud (possono essere montate).
Script di avvio del cluster	Se si preferisce, includere nel codice sorgente.	Per una sincronizzazione più semplice, archiviare gli script init nell'area di lavoro primaria in una cartella comune o in un piccolo set di cartelle, se possibile.
Punti di montaggio	Includere nel codice sorgente se creato solo tramite job basati su notebook o API di comando.	Usare i carichi di lavoro, che possono essere eseguiti come attività di Azure Data Factory (ADF). Si noti che gli endpoint di archiviazione potrebbero cambiare, dato che le aree di lavoro si trovano in aree diverse. Questo dipende molto anche dalla strategia di ripristino di emergenza dei dati.
Metadati delle tabelle	Per gli oggetti di Unity Catalog (cataloghi, schemi, tabelle, volumi e autorizzazioni), effettuare la distribuzione congiunta con il provider Terraform di Databricks o Databricks Asset Bundles. Per le tabelle del metastore Hive legacy, includere le istruzioni CREATE TABLE insieme al codice sorgente se create tramite processi eseguiti tramite notebook o l'API Command.	Per gli oggetti di Unity Catalog, leggere i metadati di origine dalle tabelle di sistema o `information_schema` e replicarli nell'area di lavoro secondaria utilizzando l'Databricks SDK. Per le tabelle legacy di Hive Metastore, confrontare le definizioni dei metadati tra i metastore utilizzando l'API Spark Catalog o `SHOW CREATE TABLE` tramite notebook o script. I percorsi di archiviazione sottostanti possono essere basati sull'area e possono variare tra le istanze del metastore.
Segreti	Includere nel codice sorgente se creato solo tramite l'API command. Si noti che potrebbe essere necessario cambiare il contenuto dei segreti tra il database primario e quello secondario.	I segreti vengono creati in entrambe le aree di lavoro tramite l'API. Si noti che potrebbe essere necessario cambiare il contenuto dei segreti tra il database primario e quello secondario.
Configurazioni dei cluster	Può essere un modello in Git. Distribuire congiuntamente nelle distribuzioni primaria e secondaria, anche se le istanze nella distribuzione secondaria devono rimanere terminate fino all'evento di disaster recovery (DR).	I cluster vengono creati dopo la sincronizzazione con l'area di lavoro secondaria usando l'API o la CLI. Questi possono essere terminati in modo esplicito se si desidera, a seconda delle impostazioni di terminazione automatica.
Autorizzazioni per notebook, processi e cartelle	Può essere un modello in Git. Distribuzione congiunta nelle distribuzioni primarie e secondarie.	Eseguire la replica usando l'API Autorizzazioni.

Scegliere regioni e più spazi di lavoro secondari

Controlli quando si attiva il disaster recovery e verso quale area geografica secondaria eseguire il failover. Sei anche responsabile di stabilizzare l'ambiente di ripristino di emergenza prima di riprendere le normali operazioni. Ciò significa in genere creare più aree di lavoro Azure Databricks per la produzione e il ripristino di emergenza, quindi scegliere un'area di failover secondaria.

Prima di selezionare l'area secondaria, verificare che siano disponibili tutte le risorse e i servizi da cui si dipende (tipi di calcolo, prodotti, integrazioni). Alcuni servizi Azure Databricks sono disponibili solo in aree specifiche.

Controllare anche la replica dei dati e la disponibilità del tipo di macchina virtuale.

Passaggio 3: Preparare le aree di lavoro ed eseguire una copia unica

Prima di tutto, è possibile configurare un'area di lavoro secondaria Azure Databricks (o aree di lavoro) e il relativo metastore di supporto nell'area secondaria scelta. L'area di lavoro secondaria deve eseguire il mirroring dell'account, dell'area e della configurazione dell'identità del database primario prima di poter replicare i dati o gli asset.

Se si utilizza il ripristino di emergenza gestito, Azure Databricks gestisce la configurazione iniziale dei cataloghi inclusi nell'ambito e degli asset dell'area di lavoro quando si crea un gruppo di failover. Non è necessario eseguire una copia una tantum per tali risorse. Procedere con il resto di questa sezione per eventuali fonti di dati o risorse che il disaster recovery gestito non replica.

Per un'area di lavoro di produzione che opera al di fuori dell'ambito del DR gestito, eseguire una copia unica per sincronizzare la distribuzione passiva con la distribuzione attiva. Questa copia gestisce:

Replica dei dati: usare una soluzione di replica cloud o Delta Deep Clone.
Generazione di token: automatizzare la replica e i carichi di lavoro futuri con token generati.
Replica dell'area di lavoro: eseguire la replica usando i metodi descritti nel passaggio 4: Preparare le origini dati. Per indicazioni complete sull'esportazione di asset dell'area di lavoro, dati e intelligenza artificiale/Machine Learning, vedere Esportare i dati dell'area di lavoro.
Convalida dell'area di lavoro: testare l'area di lavoro e il processo per verificare che vengano eseguiti correttamente e produrre i risultati previsti.

Le sincronizzazioni successive vengono eseguite più velocemente rispetto alla copia iniziale e i log degli strumenti registrano cosa è cambiato e quando.

Passaggio 4: Preparare le origini dati

Azure Databricks può elaborare un'ampia gamma di origini dati usando l'elaborazione batch o i flussi di dati.

Elaborazione batch da fonti di dati

I dati batch si trovano in genere in un'origine che è possibile replicare o distribuire in un'altra area.

Ad esempio, i dati spesso si caricano nell'archiviazione cloud in base a una pianificazione. In modalità di ripristino di emergenza, indirizzare tali caricamenti verso lo storage della regione secondaria e aggiornare i carichi di lavoro affinché leggano da e scrivano in tale storage.

Flussi di dati

Flussi dei dati

L'elaborazione di un flusso di dati è una sfida più complessa. I dati di streaming possono essere inseriti da varie origini, elaborate e inviate a una soluzione di streaming:

Coda di messaggi, ad esempio Kafka
Flusso di acquisizione delle modifiche del database
Elaborazione continua basata su file
Elaborazione pianificata basata su file, nota anche come attivazione singola

In tutti questi casi, è necessario configurare le origini dati in modo che gestiscano la modalità di disaster recovery e usino la distribuzione secondaria nella regione secondaria.

Uno scrittore di flusso archivia un checkpoint con informazioni sui dati elaborati. Questo checkpoint può contenere una posizione dei dati (in genere archiviazione cloud) che deve essere modificata in una nuova posizione per garantire un riavvio corretto del flusso. Ad esempio, la sottocartella source nel checkpoint potrebbe archiviare la cartella cloud contenente file.

Questo checkpoint deve essere replicato in modo tempestivo. Prendere in considerazione la sincronizzazione dell'intervallo di checkpoint con qualsiasi nuova soluzione di replica cloud.

L'aggiornamento del checkpoint è una funzione del writer e pertanto si applica all'inserimento o all'elaborazione del flusso di dati e all'archiviazione in un'altra origine di streaming.

Per i carichi di lavoro di streaming, assicurarsi che i checkpoint siano configurati nell'archivio gestito dal cliente, in modo che possano essere replicati nell'area secondaria per riprendere il carico di lavoro dal punto dell'ultimo errore. Si può inoltre decidere di eseguire il processo di streaming secondario in parallelo al processo primario.

Passaggio 5: Implementare e testare la soluzione

Se si usa il ripristino di emergenza gestito, è possibile attivare un failover pianificato dalla console dell'account per verificare che la configurazione funzioni end-to-end. La stessa procedura riguarda sia i test di ripristino di emergenza che le interruzioni reali. Vedere Failover e failback.

Testa regolarmente la configurazione di disaster recovery. Un piano di ripristino di emergenza non testato spesso ha esito negativo quando è necessario. Alcuni team alternano le regioni attive ogni pochi mesi secondo una pianificazione prestabilita per verificare le ipotesi, mettere alla prova le procedure e far sì che il team resti familiare con il runbook.

Importante

Testate la vostra soluzione di DR in condizioni reali con regolarità.

Se un test rivela un oggetto o un modello mancante, aggiornare il piano: rimuovere la dipendenza, replicarla nell'area di lavoro secondaria o renderla disponibile in un altro modo.

Testare anche le modifiche dell'organizzazione e della configurazione. Il piano di ripristino di emergenza influisce sulla pipeline di distribuzione, quindi il team deve sapere cosa mantenere sincronizzato. Dopo aver configurato le aree di lavoro di ripristino di emergenza, verificare che l'infrastruttura, i processi, i notebook, le librerie e altri oggetti dell'area di lavoro siano disponibili nell'area secondaria.

Espandere i processi di lavoro standard e le pipeline di configurazione per distribuire le modifiche in tutte le aree di lavoro. Gestire le identità utente tra aree di lavoro e configurare l'automazione e il monitoraggio dei processi per le nuove aree di lavoro.

Pianificare e testare le modifiche apportate agli strumenti di configurazione.

Modifiche alla configurazione per pianificare e testare

Per ognuno dei seguenti, preparare un piano per il failover e testare tutti i presupposti:

Acquisizione: Comprendere dove si trovano le fonti di dati e da dove tali fonti ricavano i dati. Se possibile, parametrizzare l'origine e usare un modello di configurazione separato per la distribuzione e l'area secondaria.
Modifiche all'esecuzione: se si dispone di un'utilità di pianificazione per attivare processi o altre azioni, potrebbe essere necessario un'utilità di pianificazione separata che funzioni con la distribuzione secondaria o le relative origini dati.
Connettività interattiva: valutare il modo in cui la configurazione, l'autenticazione e le connessioni di rete potrebbero essere interessate da interruzioni a livello di area per qualsiasi uso di API REST, strumenti dell'interfaccia della riga di comando o altri servizi, ad esempio JDBC/ODBC.
Modifiche all'automazione: per tutti gli strumenti di automazione.
Output: per tutti gli strumenti che generano dati o log di output.
Modifiche a valle: per gli strumenti di BI, le dashboard, gli strumenti di pianificazione e le integrazioni di terze parti che leggono da o scrivono su Azure Databricks, pianificare come reindirizzarli all'area di lavoro secondaria e informarne i proprietari.

Failover di test

Molti scenari possono attivare il ripristino di emergenza: un'interruzione imprevista nella rete cloud, nell'archiviazione cloud o in un altro servizio principale in cui non è possibile arrestarsi normalmente; un arresto o un'interruzione pianificata; o anche il passaggio periodico tra aree come parte del ciclo di test.

Per testare il failover, collegarsi al sistema ed eseguire uno spegnimento. Verificare che tutti i processi siano stati completati e che i cluster terminino.

Un client di sincronizzazione (o strumenti CI/CD) replica gli oggetti e le risorse pertinenti Azure Databricks nell'area di lavoro secondaria. Per attivare l'area di lavoro secondaria, il processo potrebbe includere alcune o tutte le operazioni seguenti:

Eseguire test per verificare che la piattaforma sia aggiornata.
Disabilitare pool e cluster nell'area primaria in modo che, se il servizio non riuscito torna online, l'area primaria non avvia l'elaborazione di nuovi dati.
Eseguire il processo di ripristino per le origini dati (vedere di seguito).
Avvia i pool pertinenti (o aumenta il valore di min_idle_instances a un numero pertinente).
Avvia i cluster pertinenti (se non terminati).
Modificare l'esecuzione simultanea per i processi ed eseguire i processi pertinenti. Può trattarsi di esecuzioni occasionali o di esecuzioni periodiche.
Per qualsiasi strumento esterno che usa un URL o un nome di dominio per l'area di lavoro di Azure Databricks, aggiornare le configurazioni per tenere conto del nuovo piano di controllo. Ad esempio, aggiornare gli URL per le API REST e le connessioni JDBC/ODBC. L'URL dell'applicazione web di Azure Databricks cambia quando cambia il piano di controllo, quindi comunica agli utenti della tua organizzazione il nuovo URL.

Dettagli del processo di ripristino

Controllare la data degli ultimi dati sincronizzati. Vedere terminologia del settore del ripristino di emergenza. I dettagli di questo passaggio variano a seconda della modalità di sincronizzazione dei dati e delle esigenze aziendali specifiche.
Stabilizzare le origini dati e verificare che siano tutte disponibili. Includere tutte le origini di dati esterne, incluse Azure Cloud SQL, i file Delta Lake, Parquet e altri.
Trova il punto di ripristino dello streaming. Configurare il processo per il riavvio da questa posizione e avere un processo pronto per identificare ed eliminare potenziali duplicati (Delta Lake semplifica questa operazione).
Completare il processo del flusso di dati e informare gli utenti.

Ripristino di test (failback)

Il failback è più semplice da controllare e può essere eseguito in una finestra di manutenzione. Pianificare alcuni o tutti i passaggi seguenti:

Accertarsi che l'area primaria sia stata ripristinata.
Disabilitare pool e cluster nell'area secondaria in modo da non avviare l'elaborazione di nuovi dati.
Sincronizzare le risorse nuove o modificate nell'area di lavoro secondaria con la distribuzione primaria. A seconda della progettazione degli script di failover, potrebbe essere possibile eseguire gli stessi script per sincronizzare gli oggetti dall'area secondaria (ripristino di emergenza) all'area primaria (di produzione).
Sincronizzare gli eventuali nuovi aggiornamenti dei dati alla distribuzione primaria. È possibile usare i audit trail dei log e delle tabelle Delta per evitare la perdita di dati.
Arrestare tutti i workload nella regione di DR.
Modificare l'URL dei processi e degli utenti nell'area primaria e ricollegare le connessioni downstream (strumenti bi, utilità di pianificazione, integrazioni di terze parti) a tale area.
Eseguire test per verificare che la piattaforma sia aggiornata.
Avvia i pool pertinenti (o aumenta il valore di min_idle_instances a un numero pertinente).
Avvia i cluster pertinenti (se non terminati).
Modificare l'esecuzione in parallelo per i processi ed eseguire i processi rilevanti. Può trattarsi di esecuzioni occasionali o di esecuzioni periodiche.
Se necessario, configura nuovamente l'area secondaria per il DR futuro.

Script, esempi e prototipi di automazione

Per AWS e Azure, il ripristino di emergenza gestito gestisce l'area di lavoro e la replica di tabelle gestite senza automazione personalizzata. I riferimenti seguenti si applicano solo se si sta creando una soluzione DIY all'esterno dell'ambito del ripristino di emergenza gestito.

Per le pipeline DR fai da te, usa il provider Terraform di Databricks per gestire le risorse del workspace come codice e distribuirle contemporaneamente nelle regioni primaria e secondaria.

Se si orchestra Azure Databricks da Azure Data Factory, replicare le pipeline di Azure Data Factory pertinenti in modo che facciano riferimento a un servizio collegato mappato all'area di lavoro secondaria.

Risorse aggiuntive

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-24