Indicazioni sul ripristino di emergenza specifiche dell'esperienza

Questo documento fornisce indicazioni specifiche per il ripristino dei dati di Fabric in caso di emergenza a livello di area.

Scenario di esempio

In alcune sezioni delle linee guida contenute nel presente documento viene utilizzato il seguente scenario di esempio a scopo esplicativo e illustrativo. Fare riferimento a questo scenario in base alle esigenze.

Si supponga di avere una capacità C1 nell'area A con un'area di lavoro W1. Se è stato attivato il ripristino di emergenza per la capacità C1, i dati di OneLake verranno replicati in un backup nell'area B. Se nell'area A si verifica un'interruzione, il servizio Fabric in C1 esegue il failover nell'area B.

Questo scenario è illustrato nell'immagine seguente. La casella a sinistra mostra l'area in cui si verifica l'interruzione. La casella al centro rappresenta la disponibilità continua dei dati dopo il failover e la casella a destra mostra la situazione completamente coperta dopo che il cliente agisce per ripristinare il funzionamento completo dei servizi.

Ecco il piano di ripristino generale:

1. Creare una nuova capacità Fabric C2 in una nuova area.

2. Creare una nuova area di lavoro W2 in C2, inclusi gli elementi corrispondenti con gli stessi nomi di C1.W1.

3. Copiare i dati dal C1.W1 interrotto al C2.W2.

4. Per ripristinare la piena funzionalità degli elementi, seguire le istruzioni dedicate per ciascun componente.

Piani di ripristino specifici per esperienza

Le sezioni seguenti forniscono guide dettagliate per ciascuna esperienza Fabric, per aiutare i clienti nel processo di ripristino.

Ingegneria dei dati

Questa guida illustra le procedure di ripristino per l'esperienza di ingegneria dei dati. Include lakehouse, notebook e definizioni di processi Spark.

Lakehouse

I lakehouse dell'area originale rimangono non disponibili per i clienti. Per ripristinare un lakehouse, i clienti possono ricrearlo nell'area di lavoro C2.W2. È consigliabile adottare due approcci per il recupero di lakehouse:

Approccio 1: usare uno script personalizzato per copiare tabelle e file Lakehouse Delta

I clienti possono ricreare lakehouse usando uno script Scala personalizzato.

1. Creare il lakehouse (ad esempio, LH1) nell'area di lavoro appena creata C2.W2.

2. Creare un nuovo notebook nell'area di lavoro C2.W2.

3. Per ripristinare le tabelle e i file dal lakehouse originale, fare riferimento ai dati con percorsi di OneLake, ad esempio abfss (vedere Connessione a Microsoft OneLake). È possibile usare l'esempio di codice seguente (vedere Introduzione alle utilità di Microsoft Spark) nel notebook per ottenere i percorsi ABFS di file e tabelle dal lakehouse originale. (Sostituisci C1. W1 con il nome effettivo dell'area di lavoro)

   mssparkutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. Usare l'esempio di codice seguente per copiare tabelle e file nel lakehouse appena creato.

   1. Per le tabelle Delta, è necessario copiare una tabella alla volta per ripristinarla nel nuovo lakehouse. Nel caso dei file Lakehouse, è possibile copiare la struttura di file completa con tutte le cartelle sottostanti con una singola esecuzione.

   2. Contattare il team di supporto per il timestamp del failover necessario nello script.

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   mssparkutils.fs.cp(source, destination, true)
   
   val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelte <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
       println(s"Deleting file $destFileToDelete")
       mssparkutils.fs.rm(destFileToDelete, false)
   }
   
   mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Dopo aver eseguito lo script, le tabelle verranno visualizzate nel nuovo lakehouse.

Approccio 2: usare Azure Storage Explorer per copiare file e tabelle

Per recuperare solo file o tabelle Lakehouse specifici dal lakehouse originale, usare Azure Storage Explorer. Per informazioni dettagliate, vedere Integrare OneLake con Azure Storage Explorer. Per grandi dimensioni di dati, utilizzare l'approccio 1.

Notebook

I notebook dall'area primaria rimangono non disponibili per i clienti e il codice nei notebook non verrà replicato nell'area secondaria. Per ripristinare il codice notebook nella nuova area, sono disponibili due approcci per ripristinarne il contenuto.

Approccio 1: ridondanza gestita dall'utente con l'integrazione Git (in anteprima pubblica)

Il modo migliore per rendere questa operazione semplice e veloce è utilizzare l'integrazione Fabric Git, quindi sincronizzare il notebook con il repository ADO. Dopo il failover del servizio in un'altra area, è possibile usare il repository per ricompilare il notebook nella nuova area di lavoro creata.

1. Configurare l'integrazione Git per l'area di lavoro e selezionare Connetti e sincronizza con il repository ADO.

   

   L'immagine seguente mostra il notebook sincronizzato.

   

2. Ripristinare il notebook dal repository ADO.

   1. Nell'area di lavoro appena creata connettersi di nuovo al repository Azure ADO.

      

   2. Selezionare il pulsante Controllo del codice sorgente. Selezionare quindi il ramo pertinente del repository. Quindi, selezionare Aggiorna tutto. Verrà visualizzato il notebook originale.

      

      

   3. Se il notebook originale ha un lakehouse predefinito, gli utenti possono fare riferimento alla sezione Lakehouse per recuperarlo e quindi connettere il lakehouse appena ripristinato al notebook appena ripristinato.

      

   4. L'integrazione Git non supporta la sincronizzazione di file, cartelle o snapshot del notebook in Esplora risorse del notebook.

      1. Se il notebook originale contiene file in Esplora risorse del notebook:

         1. Assicurarsi di salvare i file o le cartelle su un disco locale o in un'altra posizione.

         2. Caricare nuovamente il file dal disco locale o dalle unità cloud nel notebook ripristinato.

      2. Se esiste uno snapshot del notebook originale, salvare anche questo nel sistema di controllo della versione o sul disco locale.

         

         

Per maggiori informazioni sull'integrazione Git, vedere Introduzione all'integrazione Git.

Approccio 2: approccio manuale al backup del contenuto del codice

Se non si usa l'approccio di integrazione Git, è possibile salvare la versione più recente del codice, i file in Esplora risorse e lo snapshot del notebook in un sistema di controllo della versione, ad esempio Git, e ripristinare manualmente il contenuto del notebook dopo un'emergenza:

1. Usare la funzionalità "Importa notebook" per importare il codice del notebook da ripristinare.

   

2. Dopo l'importazione, passare all'area di lavoro desiderata (ad esempio "C2.W2") per accedervi.

3. Se il notebook originale ha un lakehouse predefinito, fare riferimento alla sezione Lakehouse. Connettere quindi il lakehouse appena ripristinato (con lo stesso contenuto del lakehouse predefinito originale) al notebook appena ripristinato.

4. Se il notebook originale contiene file o cartelle in Esplora risorse, caricare nuovamente i file o le cartelle salvati nel sistema di controllo della versione dell'utente.

Definizione di processo Spark

Le definizioni dei processi Spark (SJD) dall'area primaria rimangono non disponibili per i clienti e il file di definizione principale e il file di riferimento nel notebook verranno replicati nell'area secondaria tramite OneLake. Se si vuole ripristinare l'SJD nella nuova area, è possibile seguire i passaggi manuali descritti di seguito per ripristinare l'SJD. Si noti che le esecuzioni cronologiche dell'SJD non verranno recuperate.

È possibile ripristinare gli elementi SJD copiando il codice dall'area originale tramite Azure Storage Explorer e riconnettendo manualmente i riferimenti Lakehouse dopo l'emergenza.

1. Creare un nuovo elemento SJD (ad esempio, SJD1) nella nuova area di lavoro C2.W2, con le stesse impostazioni e configurazioni dell'elemento SJD originale (ad esempio, linguaggio, ambiente e così via).

2. Usare Azure Storage Explorer per copiare lib, main e snapshot dall'elemento SJD originale al nuovo elemento SJD.

   

3. Il contenuto del codice verrà visualizzato nell'SJD appena creato. È necessario aggiungere manualmente il riferimento Lakehouse appena ripristinato al processo (vedere i Passaggi di ripristino di Lakehouse). Gli utenti dovranno immettere nuovamente manualmente gli argomenti della riga di comando originali.

   

È ora possibile eseguire o pianificare il nuovo SJD ripristinato.

Per dettagli su Azure Storage Explorer: vedere Integrare OneLake con Azure Storage Explorer.

Data science

Questa guida illustra le procedure di ripristino per l'esperienza di data science. Vengono illustrati i modelli e gli esperimenti di Machine Learning.

Modello ed esperimento di Machine Learning

Gli elementi di data science dell'area primaria rimangono non disponibili per i clienti e il contenuto e i metadati nei modelli di Machine Learning e gli esperimenti non verranno replicati nell'area secondaria. Per ripristinarli completamente nella nuova area, salvare il contenuto del codice in un sistema di controllo della versione (ad esempio Git) ed eseguire manualmente il contenuto del codice dopo l'emergenza.

1. Ripristinare il notebook. Fare riferimento ai Passaggi di ripristino del notebook.

2. La configurazione, le metriche eseguite in passato e i metadati non verranno replicati nell'area abbinata. Sarà necessario rieseguire ogni versione del codice di data science per ripristinare completamente i modelli e gli esperimenti di Machine Learning dopo l'emergenza.

Data warehouse

Questa guida illustra le procedure di ripristino per l'esperienza del data warehouse. Copre i data warehouse.

Magazzino

I data warehouse dell'area originale rimangono non disponibili per i clienti. Per recuperare i data warehouse, eseguire i due passaggi seguenti.

1. Creare un nuovo lakehouse provvisorio nell'area di lavoro C2.W2 per i dati copiati dal data warehouse originale.

2. Popolare le tabelle Delta del data warehouse sfruttando la funzione Esplora del warehouse e le funzionalità T-SQL (vedere Tabelle in Archiviazione dati in Microsoft Fabric).

Inserimento di dati tramite Lakehouse e codice T-SQL

Nell'area di lavoro appena creata C2.W2:

1. Creare un lakehouse provvisorio "LH2" in C2.W2.

2. Recuperare le tabelle Delta nel lakehouse provvisorio dal data warehouse originale seguendo i Passaggi di ripristino di Lakehouse.

3. Creare un nuovo warehouse "WH2" in C2.W2.

4. Connettere il lakehouse provvisorio nell'Explorer del warehouse.

5. A seconda della modalità di distribuzione delle definizioni di tabella prima dell'importazione dei dati, il T-SQL effettivo usato per le importazioni può variare. È possibile usare l'approccio INSERT INTO, SELECT INTO o CREATE TABLE AS SELECT per ripristinare le tabelle warehouse dai lakehouse. Più avanti nell'esempio si usa la versione INSERT INTO. Se si usa il codice seguente, sostituire gli esempi con i nomi effettivi di tabella e colonna.

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. Infine, modificare il stringa di connessione nelle applicazioni usando il warehouse di Fabric.

Database con mirroring

I database con mirroring dall'area primaria rimangono non disponibili per i clienti e le impostazioni non vengono replicate nell'area secondaria. Per ripristinarlo in caso di errore a livello di area, è necessario ricreare il database con mirroring in un'altra area di lavoro da un'area diversa.

Data Factory

Gli elementi di Data Factory dell'area primaria rimangono non disponibili per i clienti e le impostazioni e la configurazione nelle pipeline di dati o negli elementi Dataflow Gen2 non verranno replicati nell'area secondaria. Per ripristinare questi elementi in caso di errore a livello di area, è necessario ricreare gli elementi di integrazione dei dati in un'altra area di lavoro da un'area diversa. Nelle sezioni seguenti vengono offerte informazioni dettagliate in proposito.

Dataflows Gen2

Se si vuole ripristinare un elemento Dataflow Gen2 nella nuova area, è necessario esportare un file PQT in un sistema di controllo della versione, ad esempio Git, e quindi ripristinare manualmente il contenuto di Dataflow Gen2 dopo l'emergenza.

1. Dall'elemento Dataflow Gen2, nella scheda Home dell'editor di Power Query selezionare Esporta modello.

   

2. Nella finestra di dialogo Esporta modello immettere un nome (obbligatorio) e una descrizione (facoltativa) per questo modello. Al termine, seleziona OK.

   

3. Dopo l'emergenza, creare un nuovo elemento Dataflow Gen2 nella nuova area di lavoro "C2.W2".

4. Nel riquadro di visualizzazione corrente dell'editor di Power Query selezionare Importa da un modello di Power Query.

   

5. Nella finestra di dialogo Apri, accedere alla cartella di download predefinita e selezionare il file con estensione pqt salvato nei passaggi precedenti. Quindi selezionare Apri.

6. Il modello viene quindi importato nel nuovo elemento Dataflow Gen2.

Pipeline di dati

I clienti non possono accedere alle pipeline di dati in caso di emergenza a livello di area e le configurazioni non vengono replicate nell'area abbinata. È consigliabile creare pipeline di dati critiche in più aree di lavoro in aree diverse.

Operazione di copia

Gli utenti CopyJob devono intraprendere misure proattive per proteggersi da un'emergenza regionale. L'approccio seguente garantisce che, dopo un disastro regionale, i CopyJobs di un utente rimangano disponibili.

Ridondanza gestita dall'utente con l'integrazione Git (in anteprima pubblica)

Il modo migliore per rendere questo processo facile e veloce consiste nell'usare l'integrazione di Fabric con Git, quindi sincronizzare CopyJob con il repository ADO. Dopo il failover del servizio in un'altra area, è possibile usare il repository per ricompilare CopyJob nella nuova area di lavoro creata.

1. Configura l'integrazione Git dell'area di lavoro e seleziona connetti e sincronizza con il repository ADO.

   

   L'immagine seguente mostra il CopyJob sincronizzato.

   

2. Ripristinare CopyJob dal repository ADO.

   1. Nell'area di lavoro appena creata, connettiti e sincronizza nuovamente il tuo repository Azure ADO. Tutti gli elementi Fabric in questo repository vengono scaricati automaticamente nella tua nuova area di lavoro.

      

   2. Se l'originale CopyJob utilizza una Lakehouse, gli utenti possono fare riferimento alla sezione Lakehouse per recuperare la Lakehouse e quindi connettere il CopyJob appena recuperato alla Lakehouse appena recuperata.

Per maggiori informazioni sull'integrazione Git, vedere Introduzione all'integrazione Git.

Intelligence in tempo reale

Questa guida illustra le procedure di ripristino per l'esperienza di intelligence in tempo reale. Vengono illustrati database/set di query KQL e eventstream.

Database/set di query KQL

Gli utenti di database/set di query KQL devono intraprendere misure proattive per proteggersi da un'emergenza a livello di area. L'approccio seguente garantisce che, in caso di emergenza a livello di area, i dati nei set di query dei database KQL rimangano sicuri e accessibili.

Usare la procedura seguente per garantire una soluzione di ripristino di emergenza efficace per i database e i set di query KQL.

1. Stabilire database KQL indipendenti: configurare due o più database/set di query KQL indipendenti nelle capacità di Fabric dedicate. Questi devono essere configurati in due aree di Azure diverse (preferibilmente aree abbinate ad Azure) per ottimizzare la resilienza.

2. Replicare le attività di gestione: qualsiasi azione di gestione eseguita in un database KQL deve essere replicata nell'altro. In questo modo entrambi i database rimangono sincronizzati. Le attività principali da replicare includono:

   • Tabelle: assicurarsi che le strutture di tabella e le definizioni dello schema siano coerenti tra i database.

   • Mapping: duplicare tutti i mapping necessari. Assicurarsi che le origini dati e le destinazioni siano allineate correttamente.

   • Criteri: assicurarsi che entrambi i database abbiano criteri simili in materia di conservazione dei dati, accesso e altri criteri pertinenti simili.

3. Gestire l'autenticazione e l'autorizzazione: per ogni replica, configurare le autorizzazioni necessarie. Assicurarsi che vengano stabiliti livelli di autorizzazione appropriati, concedendo l'accesso al personale richiesto e mantenendo gli standard di sicurezza.

4. Inserimento di dati parallelo: per mantenere i dati coerenti e pronti in più aree, caricare lo stesso set di dati in ogni database KQL contemporaneamente all'inserimento.

Eventstream

Un eventstream è una posizione centralizzata nella piattaforma Fabric per l'acquisizione, la trasformazione e il routing di eventi in tempo reale verso varie destinazioni (ad esempio, lakehouse, database/set di query KQL) con un'esperienza senza codice. Finché le destinazioni sono supportate dal ripristino di emergenza, gli eventstream non perderanno dati. Pertanto, i clienti devono usare le funzionalità di ripristino di emergenza di tali sistemi di destinazione per garantire la disponibilità dei dati.

I clienti possono anche ottenere la ridondanza geografica distribuendo carichi di lavoro Eventstream identici in più aree di Azure come parte di una strategia attiva/strategia attiva multisito. Grazie all'approccio attivo/attivo multi-sito, i clienti possono accedere al proprio carico di lavoro in una qualsiasi delle aree distribuite. Questo approccio è il più complesso e costoso per il ripristino di emergenza, ma nella maggior parte delle situazioni può ridurre i tempi di ripristino quasi a zero. Per avere una ridondanza geografica completa, i clienti possono

1. Creare repliche delle origini dati in aree diverse.

2. Creare elementi Eventstream nelle aree corrispondenti.

3. Connettere questi nuovi elementi alle origini dati identiche.

4. Aggiungere destinazioni identiche per ogni eventstream in aree diverse.

Informazioni correlate

• Guida al ripristino di emergenza di Microsoft Fabric