Indicazioni specifiche per l'esperienza sul ripristino di emergenza

Questo articolo fornisce indicazioni specifiche per il ripristino dei dati di Fabric in caso di disastro regionale.

Scenario di esempio

Molte sezioni di guida in questo articolo utilizzano il seguente esempio di scenario a scopo di spiegazione e illustrazione. 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 hai attivato il ripristino di emergenza per la capacità C1, i dati di OneLake vengono replicati in un backup nella regione B. Se la regione A subisce un'interruzione, il servizio Fabric in C1 esegue il failover nella regione 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 regione.

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.

Questo piano di ripristino presuppone che la regione di origine del tenant rimanga operativa. Se la regione di residenza dell'inquilino subisce un'interruzione, i passaggi descritti in questo articolo dipendono dal suo recupero, che deve prima essere avviato e completato da Microsoft.

Piani di ripristino specifici per esperienza

Le sezioni seguenti forniscono guide passo dopo passo per ogni esperienza Fabric per aiutarti durante il processo di recupero.

Ingegneria dei dati

Questa guida illustra le procedure di ripristino per l'esperienza di ingegneria dei dati. Copre i lakehouse, i notebook, le definizioni dei processi Spark, le funzioni dei dati utente e le API GraphQL.

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 i lakehouses 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 utilizzando percorsi di OneLake, come abfss (vedere Connessione a Microsoft OneLake). È possibile usare l'esempio di codice seguente (vedere Introduzione a Microsoft Spark Utilities) nel notebook per ottenere i percorsi ABFS di file e tabelle dal lakehouse originale. (Sostituisci C1.W1 con il nome reale dello spazio di lavoro)

   notebookutils.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. Contatta il team di supporto per ottenere 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
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Dopo aver eseguito lo script, le tabelle vengono visualizzate nella nuova lakehouse.

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

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

Recupero di viste del lago materializzate di Fabric

Dopo il failover, non puoi accedere alle viste materializzate del lago dalla regione originale. Il processo di failover non replica i programmi di aggiornamento o la cronologia di esecuzione nella regione secondaria. Per recuperare questi elementi, completa i seguenti passaggi dopo aver recuperato i dati di Lakehouse:

• Recupera le tabelle di Lakehouse utilizzando l'Approccio 1 o l'Approccio 2 descritti in precedenza in questo articolo. Copiare solo le tabelle di origine.
• Recupera i notebook che contengono le definizioni MLV. Per i passaggi di recupero, consulta la sezione Quaderno .
• Eseguire i notebook ripristinati per ricreare gli MLV nel nuovo Lakehouse. Per informazioni sulla creazione di MLV, vedere Creare una Lake View materializzata. Se hai copiato MLV nel passaggio precedente, esegui CREATE OR REPLACE quando li ricrei.
• Ricrea manualmente le pianificazioni di aggiornamento MLV nella nuova area di lavoro. Non puoi recuperare la cronologia dei programmi o le metriche di esecuzione.
• Se i feed MLV forniscono dati ai modelli semantici o ai report, verificare e aggiornare i riferimenti all'ID Lakehouse e all'ID del set di dati in base alle esigenze. Riconnettere i report al modello semantico aggiornato e convalidare l'aggiornamento dei dati.

Notebook

I notebook della regione primaria restano non disponibili per i clienti e il codice nei notebook non si replica nella regione secondaria. Per recuperare il codice del notebook nella nuova regione, si utilizza uno dei seguenti approcci.

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

Usa l'integrazione Fabric Git per sincronizzare il tuo notebook con il repository Azure DevOps (ADO). Dopo che il servizio passa a un'altra regione, usa il repository per ricostruire il notebook nel nuovo workspace che hai creato.

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 ADO Azure.

      

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

      

      

   3. Se il quaderno originale ha una casa sul lago predefinita, consulta la sezione Lakehouse per recuperarla e poi collega la nuova casa sul lago al quaderno appena recuperato.

      

   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. Salva file o 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 adotti l'approccio di integrazione con Git, salva l'ultima versione del tuo codice, i file nell'esplora risorse e lo snapshot del notebook in un sistema di controllo versione come Git. Recupera manualmente il contenuto del notebook dopo un disastro:

1. Usa la funzione Importa quaderno per importare il codice del quaderno che vuoi recuperare.

   

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 del lavoro Spark

Le definizioni di lavoro Spark (SJD) dalla regione primaria rimangono inaccessibili, e OneLake replica il file principale di definizione e il file di riferimento nel notebook nella regione secondaria. Se vuoi recuperare il SJD nella nuova regione, segui i passaggi manuali descritti in questa sezione. Le esecuzioni precedenti della SJD non vengono recuperate.

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

1. Crea un nuovo elemento SJD (ad esempio, SJD1) nel nuovo workspace C2. W2, con le stesse impostazioni e configurazioni dell'elemento SJD originale (ad esempio, lingua, 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 appare nel nuovo SJD creato. Devi aggiungere manualmente il riferimento al Lakehouse appena recuperato al lavoro (consulta i passaggi di recupero Lakehouse). Gli utenti devono reinserire manualmente gli argomenti originali della riga di comando.

   

È ora possibile eseguire o pianificare il nuovo SJD ripristinato.

Per informazioni dettagliate sulle Azure Storage Explorer, vedere Integrate OneLake con Azure Storage Explorer.

Funzioni dati utente

Per recuperare le funzioni di dati utente in una regione sana, utilizza uno dei seguenti approcci.

Approccio 1: Con integrazione Git (consigliato)

Il meccanismo di recupero preferito è l'integrazione Fabric Git. Sincronizzando i progetti di funzione dati utente con un repository Azure DevOps o GitHub, puoi ricostruirli rapidamente in un nuovo workspace dopo il failover.

Preparati prima di un disastro

1. Configura l'integrazione di Fabric Git per lo spazio di lavoro che ospita la funzione dati utente.
2. Collega lo spazio di lavoro a un repository Azure DevOps o GitHub.
3. Compila tutte le funzioni dati utente nel repository e sincronizza regolarmente le modifiche.
4. Memorizza le impostazioni specifiche dell'ambiente separatamente in librerie variabili se necessario.

Procedura di ripristino

Dopo un disastro regionale:

1. Crea una nuova capacità Fabric in una regione sana, come C2.
2. Crea un nuovo spazio di lavoro, come W2, nella nuova funzione.
3. Collega lo spazio di lavoro allo stesso repository Azure DevOps o GitHub.
4. Apri Controllo del codice sorgente e sincronizza il contenuto del repository con lo spazio di lavoro.
5. Ricrea o ripristina tutte le risorse Fabric dipendenti, ad esempio lakehouse, database SQL in Fabric, data warehouse e Business Events.
6. Ridispiegare le funzioni dei dati utente.
7. Valida l'esecuzione delle funzioni e la connettività delle dipendenze.
8. Aggiornare le applicazioni downstream, le pipeline di dati o altri sistemi integrati in modo che facciano riferimento alle funzioni ripristinate.
9. Completa la validazione end-to-end di tutti i tuoi scenari.

Considerazioni importanti

• L'integrazione git recupera solo il codice sorgente e gli asset del progetto.
• I registri storici delle esecuzioni non sono stati recuperati.
• I sistemi a valle potrebbero richiedere il rebinding degli endpoint.

Per ulteriori informazioni, vedi Funzioni dei dati utente, controllo del sistema e distribuzione.

Approccio 2: Recupero manuale

Se l'integrazione con Git non era configurata prima del disastro, puoi ricostruire manualmente le funzioni dati utente dai backup del codice sorgente.

Preparati prima di un disastro

Esegui regolarmente i seguenti compiti e memorizza gli elementi in un repository esterno di controllo del sorgente o in una posizione di backup:

• Esporta il codice sorgente della funzione in un repository GitHub.
• Documenta e conserva le informazioni sulle dipendenze.
• Impostazioni dell'ambiente del documento.

Procedura di ripristino

Dopo un disastro regionale:

1. Crea una nuova capacità Fabric in una regione sana, come C2.
2. Crea un nuovo spazio di lavoro, come W2.
3. Recupera tutte le risorse richieste dalla funzione, inclusi i lakehouse, i database SQL in Fabric, i warehouse, gli eventhouse e i servizi esterni.
4. Crea un nuovo progetto di funzione dati utente.
5. Importa o ricrea il codice sorgente della funzione.
6. Riapplica le impostazioni di configurazione in runtime.
7. Reinstalla tutte le dipendenze di funzione.
8. Ridistribuisci la funzione.
9. Riconfigura autenticazione e autorizzazione.
10. Ricrea gli editori o i consumatori di eventi aziendali, se utilizzati.
11. Completa test di validazione end-to-end per i tuoi scenari e integrazioni.

GraphQL

Gli elementi GraphQL dell'area primaria non sono disponibili dopo un'emergenza a livello di area e le definizioni e le configurazioni GraphQL non vengono replicate nell'area secondaria. Per ripristinare GraphQL in una nuova area, usare uno degli approcci seguenti.

Approccio 1: Ridondanza gestita dagli utenti con integrazione Git

Il modo migliore per rendere questo processo semplice e rapido è usare l'integrazione Git di Fabric e quindi sincronizzare il tuo GraphQL con la repo ADO. Dopo il failover del servizio in un'altra area, è possibile usare il repository per ricompilare GraphQL nella nuova area di lavoro creata.

1. Creare una nuova area di lavoro nella capacità e nell'area di destinazione.

2. Ripristinare tutte le origini dati dipendenti, ad esempio Lakehouse, Warehouse o database SQL, seguendo i rispettivi passaggi di ripristino.

3. Aggiorna la definizione di GraphQL per indicare le risorse appena recuperate modificando riferimenti specifici dell'ambiente come gli ID degli spazi di lavoro sorgente, gli ID degli elementi sorgente e i dettagli delle connessioni. Questo passaggio garantisce la corretta associazione al momento della distribuzione.

4. Ridistribuisci gli elementi GraphQL dal repository Git nel nuovo workspace. Questo passaggio ricrea la struttura e la configurazione dell'API usando le definizioni aggiornate.

5. Riapplica le impostazioni degli elementi, inclusi ruoli, controlli di accesso e configurazione dell'autenticazione.

6. Riapplicare i riferimenti agli endpoint aggiornando tutte le applicazioni o le integrazioni per usare l'endpoint GraphQL appena creato.

7. Aggiornare tutte le pipeline di distribuzione esistenti che puntavano all'area di lavoro precedente per fare riferimento all'area di lavoro appena creata.

8. Convalidare la funzionalità end-to-end dell'API.

Approccio 2: Approccio manuale

Se non si accetta l'approccio di integrazione Git, è possibile usare l'approccio manuale seguente per ripristinare GraphQL.

1. Creare una nuova area di lavoro nella capacità e nell'area di destinazione.

2. Ripristina tutte le origini dati dipendenti, ad esempio Lakehouse, Warehouse o database SQL.

3. Ricreare manualmente l'API GraphQL nella nuova area di lavoro, incluse le definizioni dello schema, le connessioni all'origine dati e le relazioni.

4. Riapplica le impostazioni degli elementi, inclusi ruoli, controlli di accesso e configurazione dell'autenticazione.

5. Riapplicare i riferimenti agli endpoint aggiornando tutte le applicazioni o le integrazioni per usare l'endpoint GraphQL appena creato.

6. Aggiornare tutte le pipeline di distribuzione esistenti che puntavano all'area di lavoro precedente per fare riferimento all'area di lavoro appena creata.

7. Convalidare la funzionalità end-to-end dell'API.

Considerazioni importanti

1. GraphQL si basa su dipendenze esterne(ad esempio Lakehouse, Warehouse e SQL), che è necessario ripristinare prima della distribuzione di GraphQL.

2. Le definizioni dell'API GraphQL includono riferimenti specifici dell'ambiente ( ad esempio sourceWorkspaceId e sourceItemId). Quando si esegue il ripristino in una nuova area, questi riferimenti potrebbero diventare non validi. Aggiornarli in modo che puntino alle risorse appena predisposte.

3. La riassociazione automatica delle origini dati non è garantita negli scenari di ripristino di emergenza, soprattutto quando si usano credenziali salvate o connessioni tra aree di lavoro.

4. Altre impostazioni di elementi come monitoraggio, autorizzazione, RBAC, introspezione e altro non vengono trasferite dopo il failover. È necessario ristabilire queste impostazioni nella nuova area.

References

• Panoramica dell'integrazione di Git Fabric - Microsoft Fabric | Microsoft Learn

• Pipeline di controllo del codice sorgente e distribuzione nell'API per GraphQL - Microsoft Fabric | Microsoft Learn 

App

Il sistema non replica le Fabric App, inclusi il loro codice, configurazione e metadati, nelle regioni secondarie. Se la regione primaria fallisce, l'app rimane non disponibile. Per il ripristino, archivia il codice sorgente dell'app al di fuori del sistema in GitHub, Azure DevOps o in un altro sistema di controllo della versione. Recupera i dati dell'app separatamente seguendo le indicazioni di disaster recovery per ogni archivio dati Fabric sottostante.

Approccio manuale

Puoi recuperare manualmente un'app Fabric dopo un disastro regionale usando il codice sorgente dell'applicazione e la CLI Rayfin. 

Prerequisiti 

Prima che si verifichi un disastro:

• Memorizza il codice sorgente di Fabric App in GitHub, Azure DevOps o in un altro repository di controllo del modo sorgente. 

• Documenta il processo di recupero.  

Passaggi di recupero 

1. Creare una nuova area di lavoro nella capacità e nell'area di destinazione. 

2. Recuperare risorse dipendenti prima di ridistribuire l'applicazione.  

3. Recupera il codice sorgente più recente di Fabric App dal repository di controllo del codice sorgente o dal backup locale. 

4. Dalla directory sorgente dell'applicazione, distribuisci l'app Fabric nell'area di lavoro di recupero usando Rayfin CLI. Eseguire rayfin up --workspace <new workspace>. 

5. Recupera l'elemento figlio dell'app (database SQL in Fabric) seguendo le rispettive procedure di recupero.  

6. Riapplica le impostazioni a livello di oggetto, inclusi ruoli e controlli di accesso secondo necessità.  

7. Valida la funzionalità dell'applicazione e assicurati che gli utenti abbiano i permessi giusti.  

Importante 

• Mantieni il codice sorgente di Fabric App al di fuori della regione Fabric per consentire il recupero.  

• I dati applicativi nel database non vengono recuperati come parte del processo di distribuzione di Fabric App e devono essere ripristinati separatamente.  Puoi recuperare manualmente un'app Fabric dopo un disastro regionale usando il codice sorgente dell'applicazione e la CLI Rayfin. 

Azure Databricks Storage

Azure Databricks Storage memorizza i dati in OneLake. Per proteggere i tuoi dati da un'interruzione regionale, attiva l'impostazione disaster recovery sulla capacità Fabric che contiene l'elemento Azure Databricks Storage. Quando abiliti questa impostazione, OneLake replica asincronamente i dati nella regione Azure abbinata.

Se OneLake avvia un failover regionale, le applicazioni possono continuare ad accedere ai dati replicati tramite l'endpoint globale OneLake dopo la fine del failover. L'accesso continuo tramite le API pubbliche di OneLake non richiede di creare un altro elemento di Azure Databricks Storage o di copiare i dati in un altro workspace.

Consulta OneLake Disaster Recovery and Data Protection per i comportamenti, le considerazioni e i limiti applicabili.

Per la pianificazione specifica di Azure Databricks in caso di disaster recovery, vedi Disaster recovery - Azure Databricks.

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 e esperimento ML

Gli elementi Data Science della regione primaria rimangono indisponibili per i clienti, e i contenuti e i metadati nei modelli e esperimenti di ML non si replicano nella regione 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. Recuperare il notebook. Fare riferimento ai Passaggi di ripristino del notebook.

2. La configurazione, le metriche eseguite in precedenza e i metadati non vengono replicati nell'area geografica associata. Devi rieseguire ogni versione del tuo codice data science per recuperare completamente modelli e esperimenti ML dopo il disastro.

Data Warehouse

Questa guida ti guida attraverso le procedure di recupero per il carico di lavoro Fabric Data Warehouse. Copre gli articoli del magazzino.

Magazzino

Non puoi accedere ai magazzini della regione originale. Per recuperare i magazzini, eseguire i seguenti due passaggi.

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

2. Popola le tabelle Delta del warehouse utilizzando l'Esploratore del warehouse e le capacità T-SQL (vedi Tabelle in Fabric Data Warehouse).

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 temporaneo dal Data Warehouse originale seguendo i Passaggi di ripristino di Lakehouse.

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

4. Connetti il lakehouse provvisorio nell'Explorer del magazzino.

5. A seconda di come distribuisci le definizioni delle tabelle prima dell'importazione dei dati, il T-SQL effettivo utilizzato per le importazioni può variare. Per recuperare le tabelle del warehouse dai lakehouse, puoi usare l'approccio INSERT INTO, SELECT INTO o CREATE TABLE AS SELECT. Nel seguente esempio, usiamo INSERT INTO. Se usi il seguente codice, sostituisci i campioni con nomi reali di tabelle e colonne.

   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. Cambia la stringa di connessione nelle applicazioni che usano il tuo Fabric warehouse.

Il database con mirroring

I clienti non possono accedere ai database speculari dalla regione primaria e le impostazioni non si replicano nella regione secondaria. Per recuperare un database speculare dopo un guasto regionale, devi ricrearlo in un altro workspace di una regione diversa.

Data Factory

I clienti non possono accedere agli elementi Data Factory dalla regione primaria, e le impostazioni e la configurazione nelle pipeline o negli elementi Dataflow Gen2 non si replicano nella regione secondaria. Per recuperare questi elementi dopo un guasto regionale, devi ricreare i tuoi elementi di Integrazione Dati in un altro workspace di una regione diversa. Nelle sezioni seguenti vengono offerte informazioni dettagliate in proposito.

Flussi di dati Gen2

Per recuperare un elemento Dataflow Gen2 nella nuova regione, esporta un .pqt file in un sistema di controllo versione come Git, e poi recupera manualmente il contenuto Dataflow Gen2 dopo il disastro.

1. Dal tuo elemento Dataflow Gen2, nella scheda Home dell'editor Power Query, seleziona Esporta template.

   

2. Nella finestra di dialogo Esporta modello , inserisci un nome (obbligatorio) e una descrizione (opzionale) 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 Aperti , sfoglia nella cartella dei download predefiniti e seleziona il .pqt file che hai salvato nei passaggi precedenti. Quindi selezionare Apri.

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

La funzione Salva come per Dataflows non è supportata in caso di disaster recovery.

Pipelines

I clienti non possono accedere alle pipeline in caso di emergenza a livello di area e le configurazioni non vengono replicate nell'area abbinata. Costruisci le tue pipeline critiche in più spazi di lavoro in diverse regioni.

Attività 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 semplice e veloce è usare l'integrazione Fabric Git, poi sincronizzare il tuo CopyJob con il repository Azure DevOps. 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 del tuo workspace e seleziona connetti e sincronizza con il repository Azure DevOps.

   

   L'immagine seguente mostra il CopyJob sincronizzato.

   

2. Recupera il CopyJob dal repository Azure DevOps.

   1. Nel nuovo spazio di lavoro creato, connettiti e sincronizza di nuovo con il tuo repository Azure DevOps. Tutti gli elementi Fabric in questo repository vengono scaricati automaticamente nel nuovo spazio 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.

Attività Apache Airflow

Devi adottare misure proattive per proteggere i posti di lavoro di Apache Airflow a Fabric da un disastro regionale.

Gestisci la ridondanza utilizzando l'integrazione Fabric Git. Innanzitutto, sincronizza il lavoro Airflow con il repository ADO. Se il servizio esegue il failover in un'altra regione, puoi usare il repository per ricreare il processo Airflow nella nuova area di lavoro che hai creato.

Segui questi passaggi per raggiungere questo obiettivo:

1. Configura l'integrazione Git del tuo workspace e seleziona Collega e sincronizza con il repository ADO.

2. Dopo di ciò, vedi il lavoro Airflow sincronizzato con il repository ADO.

3. Se è necessario ripristinare il processo Airflow dal repository ADO, creare una nuova area di lavoro, connettersi e sincronizzare nuovamente il repository ADO Azure. Tutti gli elementi Fabric, incluso Airflow, in questo repository vengono scaricati automaticamente sul nuovo spazio di lavoro.

Intelligence in tempo reale

Questa guida illustra le procedure di ripristino per l'esperienza di intelligence in tempo reale. Include i database KQL, i set di query e gli elementi Eventstream.

Activator

Gli elementi attivatori dell'area primaria rimangono non disponibili per i clienti e le definizioni di trigger Activator non vengono replicate nell'area secondaria. Gli utenti dell'attivatore devono adottare misure proattive per prepararsi al ripristino di emergenza a livello di area.

Per assicurarti di poter ripristinare gli elementi di Activator in caso di disastro regionale, configura l'integrazione Git di Fabric per eseguire il backup delle definizioni dei trigger e ripristinare gli elementi in un'area di lavoro in un'altra regione.

1. Configura l'integrazione Git di Fabric nell'area di lavoro che contiene l'elemento Activator e sincronizza le definizioni dei trigger nel repository Git.
2. Mantenere le definizioni di trigger Activator sottoposte a commit e sincronizzate regolarmente.
3. Durante il ripristino, creare una nuova area di lavoro nell'area di destinazione (C2. W2), connetterlo allo stesso repository e sincronizzarlo per ripristinare le definizioni dei trigger.
4. Riconfigurare e convalidare tutte le origini dati e le dipendenze di Activator nella nuova area di lavoro.

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

Modello grafico/Set di query

I clienti non possono accedere agli elementi del modello Graph e del query set Graph dalla regione primaria, e Fabric non replica questi elementi nella regione secondaria. Per ripristinare, crea o usa una capacità in un'altra area geografica e ricrea in tale regione il modello Graph e gli elementi del queryset Graph.

1. Creare o usare una capacità di Fabric esistente in un'area diversa che non è interessata dall'emergenza.

2. Creare una nuova area di lavoro o usare un'area di lavoro esistente in tale capacità.

3. Ricrea l'elemento del modello Graph nello spazio di lavoro secondario (consultato nel passo 2). Riconfigura la definizione del modello, inclusi nodi, archi e altri, per corrispondere al modello originale del Graph.

4. Se la lakehouse originale si trova nell'area di errore, recuperarla prima seguendo la sezione Lakehouse.

5. Collega una casa al lago come sorgente dati OneLake per l'elemento del modello Graph appena creato. Utilizzare il lakehouse recuperato se si trovava nell'area in panne, oppure riconnettersi al lakehouse esistente, se ancora disponibile.

6. Riconfigura eventuali programmi di caricamento dati o connessioni per il modello Graph nel nuovo workspace.

7. Ricrea l'oggetto Graph queryset nell'area di lavoro secondaria. Reinserisci manualmente le query e le eventuali configurazioni di query salvate dal queryset Graph originale.

Database/set di query KQL

Gli utenti di database KQL e set di query devono adottare misure proattive per proteggersi da un disastro regionale. Il seguente approccio garantisce che, in caso di disastro regionale, i dati nei tuoi database e query 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. Configura database KQL indipendenti: Configura due o più database KQL indipendenti e set di query nelle capacità Fabric dedicate. Configura questi database in due aree di Azure diverse (preferibilmente aree abbinate di Azure) per massimizzare la resilienza.

2. Replica le attività di gestione: Rispecchia qualsiasi azione gestionale intrapresa in un database KQL nell'altro. Questo approccio mantiene entrambi i database sincronizzati. Le attività chiave da replicare includono:

   • Tabelle: Assicurati che le strutture delle tabelle e le definizioni degli schemi siano coerenti tra i database.

   • Mapping: duplicare tutti i mapping necessari. Assicurati che fonti e destinazioni dei dati siano correttamente allineate.

   • Politiche: Assicurarsi che entrambi i database abbiano politiche simili di conservazione, accesso e altre relative dei dati.

3. Gestire l'autenticazione e l'autorizzazione: Imposta i permessi necessari per ogni replica. Assicurati di stabilire livelli di autorizzazione adeguati, garantendo l'accesso al personale richiesto 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 flusso di eventi è una posizione centralizzata nella piattaforma Fabric per l'acquisizione, la trasformazione e il routing di eventi in tempo reale a varie destinazioni (ad esempio, lakehouse, database KQL/queryset) con un'esperienza senza codice. Finché le destinazioni supportano il disaster recovery, gli eventstream non perdono dati. Pertanto, utilizzare le capacità di disaster recovery di quei sistemi di destinazione per garantire la disponibilità dei dati.

Puoi anche ottenere la geo-ridondanza distribuendo carichi di lavoro di flussi di eventi identici in più aree di Azure nell'ambito di una strategia active/active multisito. Con un approccio multisito attivo/attivo, puoi accedere al tuo carico di lavoro in una qualsiasi delle regioni in cui è stato distribuito. 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 essere completamente georidondanti:

1. Crea repliche delle tue fonti di dati in diverse regioni.

2. Crea oggetti eventstream nelle regioni corrispondenti.

3. Connettere questi nuovi elementi alle origini dati identiche.

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

Eventi aziendali, eventi Fabric ed eventi di Azure

Sebbene Business Events, Fabric Events e Azure Events condividano la stessa infrastruttura Real-Time hub in Microsoft Fabric, hanno origini, comportamenti e requisiti di recupero distinti. Comprendi queste differenze prima di pianificare il recupero in caso di disastri:

• Gli eventi Fabric sono abbonamenti agli eventi che reagiscono alle attività prodotte dalle risorse Fabric stesse. Questi eventi includono modifiche al ciclo di vita degli elementi dello spazio di lavoro (come la creazione, l'aggiornamento o l'eliminazione di lakehouse, notebook o warehouse), l'esecuzione di processi (come l'esecuzione di pipeline o notebook) e le operazioni su file e cartelle in OneLake. Queste sottoscrizioni sono di tipo push ed effimere. Gli abbonamenti non vengono replicati nella regione secondaria.

• Azure Eventi sono sottoscrizioni di eventi all'attività prodotta da account Archiviazione BLOB di Azure. Queste risorse Azure esistono indipendentemente da qualsiasi capacità o area Fabric. Sebbene la risorsa Archiviazione BLOB di Azure stessa possa rimanere disponibile durante un'interruzione regionale Fabric, gli abbonamenti configurati nellReal-Time hub non vengono replicati nella regione secondaria e devono essere ricreati.

• Gli eventi aziendali sono una funzionalità distinta in Fabric Real-Time intelligence che consente ai team di definire, pubblicare e agire su segnali aziendali significativi. Gli eventi aziendali vengono generati dall'interno di Fabric tramite Activator, notebook Spark o Funzioni dati utente, quindi pubblicati nell'hub Real-Time in cui i consumer downstream, ad esempio Activator, Eventhouse o Power Automate possono reagire a tali eventi. Gli schemi di eventi vengono regolati centralmente tramite il Registro schemi. Eventhouse archivia automaticamente ogni evento aziendale pubblicato, quindi il relativo ripristino influisce direttamente sulla disponibilità della cronologia degli eventi aziendali. Nessuna delle configurazioni del publisher o del consumer, delle definizioni di schema o delle sottoscrizioni viene replicata nella regione secondaria.

Usa i passaggi seguenti per ripristinare Business Events, Fabric Events e Azure Events nella nuova area di lavoro nell'area geografica di ripristino.

Per gli eventi aziendali:

1. Ricrea l'evento di business usato da editori e utilizzatori seguendo l'articolo Creare eventi di business in Fabric Real-Time Hub. Durante la creazione dell'evento aziendale, si crea la risorsa Set di schemi eventi. La risorsa Eventhouse è facoltativa a seconda dello scenario. Se hai fatto il backup del tuo event schema set con l'integrazione di Git, ripristinalo prima seguendo la sezione Event schema set, poi punta l'evento business verso il set di schema restaurato.

2. Ricrea nella nuova area di lavoro tutti gli elementi di pubblicazione che generano Business Events, ad esempio i notebook Spark o le Funzioni dati utente, seguendo gli articoli relativi ai publisher: Usare la Funzione dati utente come publisher di Business Events, Usare Activator come publisher di Business Events, Usare Notebook come publisher di Business Events e Usare Eventstream come publisher di Business Events.

3. Ricrea le sottoscrizioni dei consumer nell'hub Real-Time (ad esempio regole di Activator, trigger di notebook o flussi di Power Automate) che in origine reagivano agli eventi aziendali nell'area interessata seguendo gli articoli Eventhouse e integrazione del dashboard Real-Time con gli eventi aziendali e Utilizzare gli eventi aziendali da Activator.

4. Verificare che gli eventi vengano trasmessi end-to-end verificando che le sottoscrizioni siano attive e che i dati arrivino alle destinazioni previste nell'area di ripristino.

Per gli eventi Fabric:

1. Ricrea le sottoscrizioni nel Real-Time hub che fanno riferimento agli elementi dell'area di lavoro, ai processi o ai percorsi OneLake ripristinati nell'area di ripristino seguendo l'articolo Esplorare gli eventi di Fabric in Fabric Real-Time hub.

2. Verificare che gli eventi vengano trasmessi end-to-end verificando che le sottoscrizioni siano attive e che i dati arrivino alle destinazioni previste nell'area di ripristino.

Per gli eventi Azure:

1. Gli account Archiviazione BLOB di Azure non sono interessati da un'interruzione regionale di Fabric. Ricreare le sottoscrizioni di eventi nell'hub Real-Time che puntano agli stessi account Archiviazione BLOB di Azure seguendo l'articolo Impostare avvisi sugli eventi Archiviazione BLOB di Azure nell'hub Real-Time.

2. Verificare che gli eventi vengano trasmessi end-to-end verificando che le sottoscrizioni siano attive e che i dati arrivino alle destinazioni previste nell'area di ripristino.

Set di modelli evento

Un insieme di schema eventi è l'elemento Fabric che contiene le definizioni di tipo di evento e schema in Real-Time Intelligence. Altre capacità si basano su di esso: gli editori scrivono eventi che conformano ai loro schemi, e i consumatori leggono secondo le stesse definizioni.

I set di schemi eventi della regione primaria rimangono indisponibili per i clienti e non vengono replicati nella regione secondaria. Tuttavia, poiché un set di schema eventi è una definizione scritta duratura e non un abbonamento effimero, puoi fare un backup in anticipo e ripristinarlo invece di riscriverlo manualmente.

Consigliato: fare un backup con l'integrazione di Fabric Git

Per recuperare uno schema evento impostato dopo un disastro regionale, configura l'integrazione di Fabric Git prima che si verifichi un disastro e sincronizza lo spazio di lavoro contenente i tuoi set di schema eventi con il repository Git.

1. Configura l'integrazione di Fabric Git per lo spazio di lavoro che contiene il set di schema degli eventi e sincronizzalo con il repository Git.

2. Mantieni regolarmente il set di schema degli eventi validato e sincronizzato, soprattutto dopo aver aggiunto tipi di evento o pubblicato nuove versioni dello schema.

3. Durante il recupero, crea un nuovo spazio di lavoro nella regione target (C2. W2), collegarlo allo stesso repository e sincronizzarlo per ripristinare lo schema degli eventi. Poiché il nuovo workspace è vuoto, Git Sync porta i contenuti dal repository all'interno dello workspace.

4. Ricrea tutti gli editori e i consumatori che utilizzano il set di schema, seguendo le indicazioni per quei tipi di articoli.

5. Verifica che gli editori possano pubblicare in base ai tipi di evento ripristinati e che i consumatori ricevano gli eventi come previsto.

La definizione sincronizzata include i tipi di eventi nel set di schema, gli schemi e le versioni degli schemi. Non include le registrazioni degli editori, gli abbonamenti dei consumatori o la cronologia degli eventi. Recupera questi separatamente, seguendo le indicazioni per i tipi di elementi che utilizzano il set di schema.

Alternativa: ricreare manualmente

Se non hai configurato l'integrazione con Git prima del disastro, ricrea il set di schema evento nella regione di recupero seguendo Crea e gestisci i set di schema degli eventi, poi aggiungi i tipi di eventi e gli schemi che il set originale conteneva seguendo Crea e gestisci gli schemi degli eventi nei set di schema.

Map

Gli elementi mappati dall'area primaria rimangono non disponibili per i clienti e gli elementi della mappa non vengono replicati nell'area secondaria.

Se si desidera ripristinare un elemento della Mappa in caso di emergenza, configurare l'integrazione Fabric Git e sincronizzare l'elemento Mappa con il repository Git.

Durante il ripristino, dopo aver configurato la nuova area o la nuova capacità in Fabric, è possibile usare il repository per ricompilare l'elemento mappa nella nuova area di lavoro creata. Poiché la nuova area di lavoro è vuota, Git sync ottiene il contenuto dal repository nell'area di lavoro vuota. Questo passaggio riporta l'elemento Map in vita.

Ontologia

Gli utenti di ontologia devono adottare misure proattive per prepararsi al recupero dai disastri regionali. L'approccio descritto di seguito garantisce che, in seguito a un disastro regionale, la tua Ontologia rimanga recuperabile e possa essere ripristinata rapidamente.

Il modo più semplice e rapido per abilitare il ripristino consiste nell'usare l'integrazione Fabric Git e sincronizzare l'ontologia con un repository di Azure DevOps (ADO). Se il servizio esegue il failover in un'altra area, è possibile usare questo repository per ricompilare l'ontologia in un'area di lavoro appena creata.

Gli elementi di ontologia nell'area primaria non sono disponibili per i clienti dopo un'emergenza a livello di area e gli elementi di ontologia non vengono replicati nell'area secondaria.

Per ripristinare un elemento Ontologia durante un'emergenza, configurare l'integrazione Git di Fabric e sincronizzare l'elemento Ontologia con il repository ADO in anticipo.

Durante il ripristino, dopo aver configurato la nuova area e la nuova capacità in Fabric, è possibile usare il repository per ricompilare l'elemento Ontology in una nuova area di lavoro. Poiché la nuova area di lavoro è vuota, Git sync esegue il pull del contenuto dal repository nell'area di lavoro, ripristinando in modo efficace l'elemento Ontology.

Agente di ontologia

Gli utenti di Ontology Agent devono adottare misure proattive per prepararsi al ripristino di emergenza regionale. L'approccio descritto in questa sezione garantisce che, dopo un disastro regionale, la tua esperienza con l'Ontology Agent possa essere ripristinata in uno spazio di lavoro appena creato.

L'Ontology Agent dipende dall'oggetto Ontology e da qualsiasi fonte di dati collegata all'Ontology, come i lakehouse. I clienti non possono accedere alle sessioni dell'Ontology Agent nella regione primaria dopo un disastro regionale, e le sessioni dell'Ontology Agent non vengono replicate nella regione secondaria. Le sessioni di chat attive, le azioni in corso e la cronologia delle conversazioni dalla regione interessata non possono essere ripristinate.

Per recuperare l'esperienza dell'Ontology Agent durante un disastro, configura l'integrazione con Fabric Git e sincronizza l'elemento Ontology con il repository Azure DevOps (ADO) in anticipo.

Durante il recupero, una volta che la nuova regione e la nuova capacità in Fabric sono state attivate, completate i seguenti passaggi:

1. Crea un nuovo spazio di lavoro nella nuova capacità.
2. Collega il nuovo workspace allo stesso repository ADO che contiene l'oggetto Ontologia.
3. Usa Git Sync per ripristinare l'elemento Ontologia nel nuovo workspace.
4. Recupera eventuali elementi di dati dipendenti, come i lakehouse, seguendo le indicazioni relative a questi tipi di elementi.
5. Conferma che i dati recuperati siano disponibili nella regione accoppiata. Per i dati supportati da OneLake, presumi che i dati vengano replicati nella regione accoppiata, ma non presumere l'ordine dei dati replicati durante il recupero.
6. Collega l'oggetto Ontologia appena recuperato alle fonti di dati recuperate.
7. Avvia una nuova sessione dell'Ontology Agent e verifica che l'agente possa connettersi all'elemento Ontology ripristinato e alle origini dati.

Planning

Questo articolo descrive le procedure di recupero per la funzionalità di pianificazione in IQ. Descrive i passaggi necessari per ripristinare componenti chiave, inclusi fogli di pianificazione, fogli PowerTable, fogli di intelligence, InfoBridge e risorse dati correlate.

Integrazione con Git per ripristinare gli elementi del piano

L'approccio preferito consiste nel sincronizzare tutti gli elementi del piano con un repository di Azure DevOps (ADO) o GitHub tramite integrazione Git di Fabric. Dopo un failover, usare il repository per ripristinare gli elementi nella nuova area di lavoro.

Prima del disastro (misure proattive):

1. Nell'area di lavoro W1 passare a Impostazioni area di lavoro e configurare l'integrazione di Git.

2. Seleziona Connetti e sincronizza nel tuo repository ADO o GitHub.

3. Selezionare gli elementi del piano da caricare nel repository e selezionare Commit.

   

4. Confermare che lo stato di Git degli elementi del piano sia Sincronizzato.

5. Stabilire una disciplina di commit: eseguire il commit dopo ogni modifica significativa a una definizione di piano in modo che il repository rifletta sempre lo stato più recente.

Passaggi per il ripristino:

1. Creare una nuova area di lavoro W2 all'interno della capacità C2 nell'area integra.

2. Nell'area di lavoro W2 passare a Impostazioni area di lavoro e riconnettersi allo stesso repository ADO/GitHub.

3. Selezionare Controllo del codice sorgente. Selezionare il ramo del repository pertinente e selezionare Aggiorna tutto. Tutti gli elementi del piano vengono scaricati su W2.

I componenti seguenti vengono ripristinati dopo il ripristino:

• Fogli PowerTable: Impostazioni della tabella di origine, configurazione delle colonne, accesso alle righe, proprietà visive (layout, formati e altro), identificazione delle righe, impostazioni dei commenti, dimensioni a variazione lenta (SCD), approvazioni, automazioni e moduli.
• Fogli di pianificazione: Proprietà foglio (formattazione, formattazione condizionale e altro ancora), impostazioni di commento, impostazioni di writeback, colonne di input dei dati, righe di input di dati, scenari e segnalibri.
• InfoBridge: origini dati di InfoBridge, query di InfoBridge, passaggi di trasformazione, destinazioni di writeback, impostazioni di writeback, mappature delle query collegate, gruppi di query, proprietà visive (blend). Questi elementi non possono essere recuperati: origini basate su file (CSV, Excel), fogli tra carichi di lavoro che usano origini basate su file.
• Intelligence: Tutti i grafici e le matrici.

Ripristino SQL di Fabric per la pianificazione

I dati immessi nei fogli di pianificazione, nelle tabelle usate in PowerTable e nei dati di writeback vengono archiviati nei database SQL e devono essere considerati come parte della strategia di ripristino di emergenza. Per ripristinare i database SQL, vedere la sezione Database SQL .

• Metadati del piano di ripristino: ogni elemento del piano è associato a un database __fabric_plan_sys che archivia i metadati per le funzionalità di pianificazione, inclusi commenti, scenari, input di dati e configurazione writeback. Il database __fabric_plan_sys non viene ripristinato automaticamente e deve essere ripristinato in modo esplicito.

• Ripristinare i database di writeback: se il piano usa destinazioni di writeback SQL, è necessario ripristinare manualmente i database associati. Le destinazioni di writeback SQL configurate non vengono ripristinate automaticamente.

• Ripristinare le tabelle utilizzate in PowerTable: Tutte le tabelle create tramite PowerTable sono memorizzate in un database SQL in Fabric. È anche necessario recuperare queste tabelle durante il DR.

Agenti operativi

Gli utenti dell'agente operativo devono adottare misure proattive per prepararsi al ripristino di emergenza a livello di area. Seguendo l'approccio descritto in questa sezione, è possibile assicurarsi che gli agenti possano essere ripristinati rapidamente dopo un'interruzione a livello di area.

Usa l'integrazione Git di Fabric per sincronizzare l'area di lavoro con un repository. Questo approccio consente di ricostruire le configurazioni dell'agente in una nuova area di lavoro se il servizio passa, in caso di failover, a un'altra area geografica.

Gli elementi dell'agente operativo nell'area primaria non sono disponibili durante un'emergenza a livello di area. Le configurazioni dell'agente, i modelli di comportamento e i log attività non vengono replicati nell'area secondaria. Anche le operazioni in corso, le sessioni di chat attive e gli eventi inseriti in precedenza al momento dell'emergenza vengono perse.

Per prepararsi al ripristino, configurare l'integrazione Git di Fabric e sincronizzare gli elementi dell'agente con il repository ADO prima che si verifichi un disastro.

Durante il ripristino, configura la nuova area geografica e la capacità in Fabric, quindi usa il repository sincronizzato per ripristinare le configurazioni dell'agente in una nuova area di lavoro. La sincronizzazione Git recupera i contenuti archiviati dal repository nell'area di lavoro vuota, ricreando così gli elementi dell'agent.

Una volta ripristinate le configurazioni, confermare che i database Eventhouse (KQL) a cui si fa riferimento o le origini dati specifiche dell'area geografica siano accessibili nella nuova regione. Aggiornare i riferimenti agli endpoint nelle configurazioni dell'agente in base alle esigenze. Infine, riavviare gli agenti e fare in modo che gli utenti avviino nuove sessioni di chat. Non è possibile riprendere le conversazioni precedenti.

Databases

Questa guida descrive le procedure di recupero per l'esperienza del database.

SQL database

Per proteggersi da un errore a livello di area, gli utenti dei database SQL possono adottare misure proattive per esportare periodicamente i dati e usare i dati esportati per ricreare il database in una nuova area di lavoro quando necessario.

Utilizza lo strumento CLI SqlPackage che offre portabilità del database e facilita le implementazioni di database.

1. Usare lo strumento SqlPackage per esportare il database in un .bacpac file. Per altri dettagli, vedere Esportare un database con SqlPackage .
2. Conserva il .bacpac file in una posizione sicura che si trova in una regione diversa dal database. Tra gli esempi rientrano l'archiviazione del file .bacpac in un lakehouse situato in un'area geografica diversa, l'utilizzo di un account Archiviazione di Azure con ridondanza geografica oppure l'uso di un altro supporto di archiviazione sicuro situato in un'area geografica diversa.
3. Se il database SQL e l'area non sono disponibili, è possibile usare il .bacpac file con SqlPackage per ricreare il database in un'area di lavoro in una nuova area - Area di lavoro C2. W2 nell'area B come descritto nello scenario precedente. Seguire i passaggi descritti in Importare un database con SqlPackage per ricreare il database con il .bacpac file.

Il database ricreato è un database indipendente dal database originale e riflette lo stato dei dati al momento dell'operazione di esportazione.

Considerazioni sul failback

Il database ricreato è un database indipendente. I dati aggiunti al database ricreato non sarebbero stati riflessi nel database originale. Se prevedi di fare un failback al database originale quando la regione di origine sarà disponibile, devi considerare di riconciliare manualmente i dati dal database ricreato con quello originale.

Platform

La piattaforma fa riferimento ai servizi condivisi e all'architettura sottostanti applicabili a tutti i carichi di lavoro. Questa sezione descrive le procedure di recupero per le capacità condivise di Fabric.

Monitoraggio dell'area di lavoro

Il monitoraggio dello spazio di lavoro raccoglie i log sull'attività nello spazio dove lo abiliti. Dopo aver recuperato il tuo spazio di lavoro come C2. W2, attiva il monitoraggio dello spazio di lavoro su W2. Inizia a raccogliere dati di monitoraggio per lo spazio di lavoro recuperato.

I dati di monitoraggio dell'area di lavoro originale (C1.W1) non vengono trasferiti, perché il monitoraggio riflette l'attività dell'area di lavoro in cui viene eseguito.

Libreria di variabili

Microsoft Fabric librerie variabili consentono agli sviluppatori di personalizzare e condividere le configurazioni degli elementi all'interno di un'area di lavoro, semplificando la gestione del ciclo di vita del contenuto. Dal punto di vista del ripristino di emergenza, gli utenti della libreria delle variabili devono proteggere in modo proattivo contro un disastro regionale. Questa protezione può essere effettuata tramite l'integrazione di Fabric Git, che garantisce che, dopo un disastro regionale, la libreria Variabile dell'utente rimanga disponibile. Per recuperare una libreria variabile, segui questi passaggi:

• Usare l'integrazione Git di Fabric per sincronizzare la libreria delle variabili con il repository ADO. In caso di emergenza, è possibile usare il repository per ricompilare la libreria delle variabili nella nuova area di lavoro creata. Seguire questa procedura:

  1. Connettere l'area di lavoro al repository Git come descritto qui.
  2. Assicurarsi di mantenere WS e il repository sincronizzato con commit e aggiornamento.
  3. Ripristino: in caso di emergenza, usare il repository per ricompilare la libreria di variabili in una nuova area di lavoro:

• Nell'area di lavoro appena creata, collegarsi e sincronizzare nuovamente il repo Azure ADO.

• Tutti gli elementi Fabric in questo repository vengono scaricati automaticamente nella nuova area di lavoro.

• Dopo aver sincronizzato gli elementi da Git, aprire le librerie di variabili nella nuova area di lavoro e selezionare manualmente il valore attivo desiderato.

Piano di distribuzione

Un piano di distribuzione è un elemento presente in uno spazio di lavoro Fabric. Raggruppa gli elementi e stabilisce l'ordine per distribuirli. Può eseguire azioni prima o dopo il dispiegamento di ogni oggetto. La definizione dell'articolo memorizza queste impostazioni, input e riferimenti agli elementi. Il piano non prevede uno store separato per i valori utilizzati in tempo reale.

Preparati al recupero utilizzando l'integrazione di Fabric Git:

1. Collega lo spazio di lavoro che contiene il piano a un repository Azure DevOps o GitHub.
2. Compila il piano e tutti gli elementi dello spazio di lavoro che utilizza.
3. Effettua il commit di ogni modifica così Git ha le definizioni più recenti.

Dopo un disastro regionale:

1. Crea uno spazio di lavoro nella zona sana.
2. Collega lo spazio di lavoro allo stesso repository e al stesso ramo.
3. Aggiorna lo spazio di lavoro da Git. Questo passaggio ripristina il piano e i suoi elementi.

Git ripristina la definizione completa del piano. Non ripristina i dati né lo stato di esecuzione degli elementi collegati. Usa le sezioni di questo articolo per recuperare quegli oggetti.

Chiavi gestite dal cliente per aree di lavoro Fabric

Puoi utilizzare le chiavi gestite dal cliente (CMK) memorizzate in Azure Key Vault per aggiungere un ulteriore livello di crittografia sopra le chiavi gestite da Microsoft per i dati a riposo. Se Fabric diventa inaccessibile o inutilizzabile in una regione, i suoi componenti passano a un'istanza di backup. Durante il failover, la funzionalità CMK supporta operazioni di sola lettura. Finché il servizio Azure Key Vault rimane in stato di salute e i permessi per il vault sono intatti, Fabric continua a connettersi alla tua chiave e ti permette di leggere i dati normalmente. Ciò significa che le operazioni seguenti non sono supportate durante il failover: l'abilitazione e la disabilitazione dell'impostazione cmk dell'area di lavoro e l'aggiornamento della chiave.

Assistente alla migrazione di Fabric per database SQL in Fabric

Il Fabric Migration Assistant può spostare un database SQL Server in un database SQL in Fabric in tre fasi: il wizard di migrazione crea il database di destinazione e avvia la migrazione, il monitor di migrazione monitora i progressi mentre lo schema viene distribuito da un DACPAC, il Migration Assistant aiuta a rivedere e correggere gli errori di script, preparare il database, copiare i dati con un lavoro di copia e finalizzare la copia.

Il progresso della migrazione non è replicato in un'altra regione e una distribuzione interrotta non può essere ripresa. Questi guasti non influenzano il database sorgente di SQL Server, quindi puoi eseguire di nuovo l'assistente di migrazione. Se la regione originale non è disponibile, segui prima il piano generale di recupero in questo articolo per creare capacità C2 e spazio di lavoro W2 nella regione accoppiata, poi esegui la migrazione in W2. Se la regione originale si riprende, puoi riprovare la migrazione nello spazio di lavoro originale.

Una perturbazione regionale può causare il fallimento di una migrazione in tre modi:

• Il database target non viene creato

  Se Fabric non riesce a creare il database di destinazione, la procedura guidata di migrazione visualizza un errore e la migrazione non viene avviata. Seleziona Avvia migrazione per riprovare, oppure riprova più tardi.

  Il wizard tenta di rimuovere un database incompleto, ma la pulizia può fallire durante un'interruzione. Prima di riprovare, controlla nel workspace se c'è un database con il nome target. Conferma che sia il database incompleto del tentativo fallito prima di cancellarlo.

• Il dispiegamento fallisce

  Se il deployment viene interrotto, il monitor della migrazione interrompe la segnalazione dei progressi, apre il database target e mostra un dialogo che indica il fallimento del deployment. Non puoi riprendere un deployment fallito, e il database creato dal tentativo rimane nello spazio di lavoro.

  Per ripristinare:

  1. Conferma che Fabric sia disponibile e che hai usato il DACPAC per la migrazione originale.
  2. Identifica il database creato dal tentativo fallito. Cancella se non contiene nulla che devi conservare. Altrimenti, tienilo e usa un nome diverso per il nuovo database.
  3. Esegui una nuova migrazione dal DACPAC sorgente. La migrazione crea un nuovo database.

  I dati vengono copiati tramite un lavoro di copia in Data Factory. Se hai sincronizzato il job di copia con Git prima dell'interruzione, consulta Copy Job nella guida Data Factory. Altrimenti, crea un nuovo lavoro di copia come parte della nuova migrazione.

• La cronologia della migrazione non si carica

  Se l'Migration Assistant non riesce a recuperare la cronologia delle migrazioni, segnala che le informazioni sulla migrazione non sono più disponibili. I progressi salvati nel browser attuale vengono preservati e il database di destinazione non è influenzato. Aggiorna la pagina per caricare di nuovo la cronologia della migrazione.

OneLake

Questa sezione illustra le procedure di ripristino per le funzionalità di OneLake. Per altre informazioni sul ripristino di emergenza per i dati di OneLake, vedere Ripristino di emergenza di OneLake.

Criteri di gestione del ciclo di vita

Se Fabric diventa inaccessibile o inutilizzabile in una regione, puoi comunque leggere e aggiornare la tua politica di ciclo di vita OneLake durante il failover. Qualsiasi dato spostato al livello freddo o freddo resta in quel livello. Per applicare la tua politica esistente al nuovo spazio di lavoro di recupero, segui questi passaggi:

1. Richiama Criterio di esportazione nell'area di lavoro di origine e salva il criterio dell'intero ciclo di vita.
2. Richiamare Import Policy nell'area di lavoro ripristinata, usando il criterio del ciclo di vita esportato come corpo della richiesta.

Regole delle istanze di risorse

Le regole dell'istanza delle risorse consentono di controllare in modo sicuro l'accesso ai dati in OneLake usando identità di risorse attendibili Azure. Durante il failover regionale, il sistema continua ad applicare le regole esistenti per l'accesso in lettura. Tuttavia, non è possibile creare, aggiornare o eliminare le regole dell'istanza di risorsa fino a quando l'area di lavoro non torna a uno stato scrivibile.

Informazioni collegate

• Microsoft Fabric guida al ripristino di emergenza