Ripristino di emergenza gestito

Il ripristino di emergenza gestito replica la distribuzione Azure Databricks in un'area secondaria in modo da poter eseguire il ripristino da un'interruzione a livello di area in pochi minuti. Azure Databricks gestisce la pipeline di replica, lo stato dei cataloghi replicati nel database secondario e il processo di failover. Non scrivi né gestisci gli script di replica.

Per l'approccio manuale al ripristino di emergenza, inclusi i concetti generali sul ripristino di emergenza e le procedure consigliate, vedere Ripristino di emergenza.

Che cos'è il ripristino di emergenza gestito?

Il disaster recovery gestito si basa sui workspace e sui metastore che già gestisci. Si configurano due aree di lavoro di Azure Databricks, una nell'area geografica primaria e una nell'area geografica secondaria, oltre a un metastore in ciascuna area geografica. Disaster recovery gestito in passato:

• Replica le categorie che si accettano dal database primario al secondario in base a una pianificazione continua. Entrambe le categorie sono facoltative in modo indipendente: i metadati di Unity Catalog e i dati delle tabelle gestite; e gli asset dell'area di lavoro, ad esempio notebook, processi, warehouse SQL, cluster e ACL.
• Fornisce un URL stabile opzionale, un'unica stringa di connessione che punta sempre all'istanza primaria corrente, in modo che i client continuino a funzionare dopo il failover senza necessità di riconfigurazione.
• Consente di avviare il failover quando desiderato, per un test di disaster recovery o un'interruzione effettiva.

Gli ID degli asset dell'area di lavoro vengono mantenuti in più aree, quindi gli URL che fanno riferimento a un asset dell'area di lavoro in base all'ID vengono comunque risolti dopo il failover.

Cosa viene replicato

Il disaster recovery gestito può replicare i seguenti elementi a ogni ciclo di replica. Entrambe le categorie sono facoltative, quindi è possibile abilitare o entrambe le categorie:

• Metadati e dati di Unity Catalog: tabelle gestite di Unity Catalog in Delta Lake con dati, tabelle esterne e volumi (solo metadati), viste, funzioni e tutte le autorizzazioni concesse. La modalità di isolamento del catalogo viene replicata. Se il catalogo di origine è aperto, la replica è aperta. Se l'origine è isolata e associata all'area di lavoro primaria, la replica è isolata e associata all'area di lavoro secondaria.
• Risorse dell'area di lavoro: notebook, job, warehouse SQL, cluster, dashboard AI/BI in bozza, file e cartelle, insieme alle relative ACL. I warehouse SQL vengono replicati nello STOPPED stato, i cluster nello TERMINATED stato. Le pianificazioni dei processi nel database secondario vengono sospese.

Gli elementi non elencati nella sezione precedente non vengono replicati. Per informazioni dettagliate, vedere Limitazioni .

Requisiti

• Componente aggiuntivo dell'area di lavoro Mission Critical abilitato in entrambe le aree di lavoro. Vedere Abilitare Mission Critical in entrambe le aree di lavoro.
• Calcolo serverless abilitato in entrambe le aree di lavoro. L'ambiente di calcolo serverless è disponibile per impostazione predefinita nella maggior parte delle aree di lavoro abilitate per il catalogo Unity. Vedi Connettersi al calcolo serverless.
• Ruolo di amministratore account con TUTTI I PRIVILEGI per ogni posizione esterna utilizzata dai cataloghi che intendi replicare.
• SSO a livello di account con tutte le aree di lavoro abilitate e identità sincronizzate con l'account tramite SCIM in modo che gli utenti, i gruppi e le entità servizio esistano in entrambe le aree.
• Per gli URL stabili: un URL personalizzato configurato per il dominio Azure Databricks (contatta il team responsabile dell’account) e OAuth a livello di account.
• Un workspace secondario e un metastore di Unity Catalog nell'area geografica secondaria, nello stesso account Azure Databricks e sullo stesso cloud di quello primario. L'area di lavoro secondaria deve avere la stessa configurazione di rete, di collegamento privato e della chiave gestita dal cliente dell'area di lavoro primaria. Il metastore secondario non deve contenere cataloghi che condividono nomi con cataloghi replicati. Per la replica delle risorse dell'area di lavoro, Azure Databricks elimina tutte le risorse esistenti incluse nell'ambito della replica nell'area di lavoro secondaria al completamento della replica iniziale. Gli asset fuori ambito non sono coinvolti, quindi l'area di lavoro secondaria non deve essere necessariamente vuota.
• Una posizione esterna e una credenziale di archiviazione corrispondenti nella regione secondaria per ciascuna di quelle a cui fanno riferimento i cataloghi principali. Il disaster recovery gestito non replica automaticamente le posizioni esterne né le credenziali di accesso allo storage; è necessario crearle nell’ambiente secondario.

• Un connettore di accesso di Azure Databricks nell'area geografica secondaria con il ruolo Collaboratore dati BLOB di archiviazione per gli account di archiviazione secondari, aggiunto come credenziale di archiviazione nell'area di lavoro secondaria.
• Configurazione della connettività di rete (NCC) nell'area secondaria, assegnata all'area di lavoro secondaria.
• Endpoint privati autorizzati per ogni account di archiviazione di origine e secondario a cui fanno riferimento i cataloghi replicati.

Abilitare Mission Critical in entrambe le aree di lavoro

Abilitare il componente aggiuntivo Mission Critical nelle aree di lavoro primarie e secondarie prima di creare un gruppo di failover. L'utilizzo del calcolo in ogni area di lavoro in cui si abilita il componente aggiuntivo viene fatturato alla tariffa Mission Critical. Per ottenere la tariffa corrente, contattare il team dell'account Azure Databricks.

1. Nella console dell'account fare clic su Aree di lavoro, quindi fare clic sull'area di lavoro.
2. Fare clic sulla scheda Componenti aggiuntivi .
3. Nella scheda Mission Critical, attivare l’interruttore e confermare.

Ripetere per l'area di lavoro secondaria.

Configura la replicazione

Un nuovo gruppo di failover passa attraverso CREATING → INITIAL_REPLICATION → ACTIVE. Il primo ciclo di replicazione copia tutti i dati inclusi nell'ambito nel secondario. Per i workspace di grandi dimensioni, l'inizializzazione iniziale delle risorse del workspace può richiedere fino a due settimane. Questa attesa è una tantum. Al termine del bootstrap iniziale, la replica viene eseguita in modo continuo.

Durante la replicazione, i cataloghi secondari che rientrano nell'ambito di applicazione sono di sola lettura e le risorse di calcolo non sono disponibili nell'area di lavoro secondaria. Per eseguire query di convalida senza scrivere nel database secondario, Azure Databricks consiglia un'area di lavoro di monitoraggio di sola lettura separata nell'area secondaria.

Per creare un gruppo di failover:

1. Nella console dell'account fare clic su Resilienza.
2. Se si prevede di usare un URL stabile, fare clic sulla scheda URL stabili e quindi su Crea URL stabile. Immettere un nome, selezionare l'area di lavoro primaria corrente e creare l'URL stabile. Indirizza i client downstream (JDBC, ODBC, l'interfaccia web di Azure Databricks, richieste API dirette) all'URL stabile anziché all'URL originale dell'area di lavoro.
3. Fare clic sulla scheda Gruppi di failover e quindi su Crea gruppo di failover.
4. Compilare il modulo:
   • Nome del gruppo di failover: nome scelto per il gruppo di failover.
   • Area di lavoro principale: l'area di lavoro principale.
   • Area di lavoro secondaria: area di lavoro nell'area secondaria.
   • Replicare gli asset dell'area di lavoro (facoltativo): disattivato per impostazione predefinita. Attivare per replicare notebook, processi, sql warehouse, cluster, dashboard, file e cartelle (e i relativi elenchi di controllo di accesso) dal database primario al database secondario. Richiede che entrambe le aree di lavoro dispongano del componente aggiuntivo Mission Critical abilitato. Se si attiva la replicazione degli asset dell'area di lavoro, Azure Databricks elimina eventuali asset esistenti inclusi nell'ambito nell'area di lavoro secondaria al completamento della replica iniziale. Gli asset al di fuori dell'ambito non sono interessati.
   • URL stabile (facoltativo): URL stabile creato nel passaggio 2.
   • Ambito di replica: cataloghi da replicare. È necessario selezionare un'area di lavoro primaria prima che questo campo sia disponibile.
   • Mapping di archiviazione: per ogni posizione esterna usata dai cataloghi replicati nell'area primaria, aggiungere una voce che esegue il mapping del percorso di archiviazione alla posizione esterna corrispondente creata nell'area secondaria (vedere Requisiti). È possibile usare * come wildcard per la corrispondenza per prefisso.
5. Fare clic su Crea il gruppo di failover.

Ad esempio, un mapping di archiviazione di Azure potrebbe associare abfss://data@primary.dfs.core.windows.net/* a abfss://data@secondary.dfs.core.windows.net/*.

Creazione del disaster recovery gestito dalle risorse

Quando si crea un gruppo di failover, il DR gestito esegue il provisioning delle risorse ausiliarie di Unity Catalog usate dalla pipeline di replica per copiare i dati tra regioni. Sia nei metastore primari sia in quelli secondari, il disaster recovery gestito crea:

• Una connessione che punta all'area di lavoro nell'altra area geografica.
• Catalogo esterno per ogni catalogo replicato. Il catalogo esterno fa riferimento al catalogo corrispondente nell'altra area.

Queste risorse vengono visualizzate insieme ai propri cataloghi in Esplora cataloghi. È possibile identificarli dal commento, che indica che sono stati creati e sono gestiti dal ripristino di emergenza di Azure Databricks.

Proprietà delle risorse replicate

Quando il DR gestito crea un oggetto proteggibile replicato (catalogo, schema, tabella, vista, funzione o volume) nell'istanza secondaria, il proprietario iniziale è il service principal di Azure Databricks che esegue la replica, perché Unity Catalog assegna la proprietà all'identità che crea l'oggetto. Il DR gestito trasferisce quindi la proprietà della replica in modo che corrisponda a quella del proprietario del corrispondente oggetto a protezione diretta nel database primario.

Se il proprietario di un oggetto a protezione diretta in quello primario è un utente eliminato dall'account, il DR gestito non può trasferire la proprietà a un'entità di sicurezza che non esiste più. In questo caso, l'oggetto a protezione diretta della replica mantiene l'entità servizio di Azure Databricks come proprietario. Per risolvere questo problema, assegnare un proprietario valido all'entità a protezione diretta nel database primario. Il DR gestito replica l'owner aggiornato sulla replica entro la finestra RPO.

Usare l'URL stabile

L'URL stabile punta sempre all'area di lavoro primaria corrente, quindi i client che si connettono tramite tale URL non devono essere riconfigurati dopo un failover. Indirizzare i seguenti client downstream all'URL stabile invece che all'URL originale dell'area di lavoro:

• Interfaccia utente Web Azure Databricks.
• Connessioni JDBC e ODBC ai data warehouse SQL.
• Richieste API REST dirette.

Gli URL stabili sono supportati con collegamento privato front-end (in ingresso), ma il formato dell'URL è diverso dal formato standard.

L'URL dell'area di lavoro originale continua a funzionare, ma non supera il failover. Azure Databricks consiglia di eseguire la migrazione dei client all'URL stabile.

Monitoraggio della replicazione

La scheda Gruppi di failover mostra lo stato corrente, il punto di replica e gli eventuali errori attivi di ogni gruppo di failover. Stati possibili:

Selezionare il nome di un gruppo di failover per aprire la relativa pagina dei dettagli. Il punto di replica indica quando tutte le risorse nell'ambito sono state copiate per l'ultima volta. I dati scritti dopo il punto di replica potrebbero non esistere nel database secondario e possono essere persi durante il failover.

Per le tendenze storiche dell'RPO e gli errori di replica per risorsa, interrogare la tabella di sistema system.replication.states. Vedere Informazioni di riferimento sulla tabella di sistema di replica.

Effettuare il failover e il failback

La stessa procedura riguarda i failover pianificati (test di ripristino di emergenza, manutenzione pianificata) e i failover non pianificati (interruzione a livello di area). Per eseguire il failback, ripetere la procedura con le aree invertite.

Quando si attiva un failover, Azure Databricks:

• Indirizza l'URL stabile, se associato, alla nuova regione primaria.
• Inverte la direzione della replica.
• Sospende le pianificazioni dei processi nel database primario precedente.
• Fa passare il gruppo di failover da FAILING_OVER a INITIAL_REPLICATION.

Per eseguire il failover:

1. Avvisa il team che sta per iniziare un failover.

2. Solo per un failover pianificato:

   1. Nell'area di lavoro primaria terminare tutti i cluster in esecuzione e arrestare tutti i warehouse SQL.
   2. Verificare che le scritture nel database primario siano state arrestate, quindi attendere il recupero della replica. Per verificare, apri la pagina dei dettagli del gruppo di failover e conferma che il punto di replica sia a pochi secondi dall'ora in cui hai interrotto le operazioni di scrittura.

3. Nella console dell'account fare clic su Resilienza → Gruppi di failover, quindi fare clic sul nome del gruppo di failover.

4. Fare clic su Fail over.

5. Selezionare la nuova area primaria e confermare. Il failover si completa in pochi minuti.

6. Nel nuovo primario, avvia l'elaborazione che era in esecuzione prima del failover. I cluster replicati e i warehouse SQL arrivano nel nuovo primario rispettivamente nello stato TERMINATED e STOPPED.

7. Riprendi manualmente le pianificazioni dei processi necessarie nel nuovo nodo primario. Le pianificazioni dell'ex primaria sono già sospese.

I client connessi tramite l'URL stabile continuano a funzionare dopo il failover. Riconfigurare i client che utilizzano ancora l'URL dell'area di lavoro originale in modo che puntino all'URL stabile oppure all'URL dell'area di lavoro della nuova area di lavoro primaria.

Errori di replica comuni

È possibile monitorare lo stato dei gruppi di failover nella tabella di sistema system.replication.states. La tabella contiene un riepilogo degli errori correnti per ogni gruppo di failover. Nella tabella seguente sono elencati gli errori più comuni, più frequenti:

Smantellare il disaster recovery gestito

1. Nella console dell'account fare clic su Resilienza → Gruppi di failover, quindi fare clic sul nome del gruppo di failover ed eliminarlo. Non è possibile disattivare Mission Critical mentre un gruppo di failover è attivo nell'area di lavoro.
2. Per interrompere la fatturazione alla tariffa Mission Critical, disattivare Mission Critical in ogni area di lavoro dalla scheda Componenti aggiuntivi .

Limitations

Il disaster recovery gestito ha le seguenti limitazioni:

• Non replicato: viste materializzate, tabelle di streaming, pipeline dichiarative di Lakeflow Spark, dati del volume gestito (repliche di metadati), segreti del catalogo e dell'area di lavoro di Unity, modelli di Machine Learning, endpoint di gestione dei modelli, indici di ricerca vettoriali, condivisioni Delta, dashboard di intelligenza artificiale/BI pubblicati (repliche di bozze) e Spark Structured Streaming al di fuori delle pipeline dichiarative di Lakeflow Spark. Le tabelle con filtri di riga o maschere di colonna e le risorse con tag ABAC vengono contrassegnate come Replica non riuscita nella tabella di sistema e questi errori impediscono il raggiungimento dell'RPO finché non si rimuove la risorsa dall'ambito del gruppo di failover.
• I cataloghi secondari rientranti nell'ambito sono di sola lettura. La modalità di sola lettura si applica esclusivamente alle entità replicate. Puoi comunque configurare una tua replicazione per gli oggetti proteggibili al di fuori dell'ambito del DR gestito. Tuttavia, non è possibile eseguire carichi di calcolo nell'area di lavoro secondaria mentre il disaster recovery gestito è abilitato, il che limita l'esecuzione di una pipeline di replica fai-da-te in tale area di lavoro.
• La ridenominazione di un oggetto proteggibile in Unity Catalog comporta l'eliminazione e la ricreazione nel secondario. Per le tabelle gestite, la ridenominazione replica i dati della tabella nel ciclo successivo. Evitare di rinominare durante la replicazione in regime stazionario.
• UNDROP non viene propagato al secondario.
• Massimo di 300 cataloghi per account.
• Massimo 100 gruppi di failover per account.
• L'inizializzazione iniziale delle risorse dell'area di lavoro può richiedere fino a 2 settimane per aree di lavoro di grandi dimensioni.

• Il DR gestito non è compatibile con il firewall dello spazio di archiviazione dell'area di lavoro. Non abilitare il supporto firewall sugli account di archiviazione dell'area di lavoro usati con il disaster recovery gestito.

Per i concetti e le procedure consigliate per il ripristino di emergenza, vedere Ripristino di emergenza.