Indicazioni specifiche per l'esperienza sul ripristino di emergenza

Questo documento fornisce linee guida specifiche per il ripristino dei dati Fabric in caso di disastro regionale.

Scenario di esempio

Molte sezioni di materiale sussidiario in questo documento usano lo scenario di esempio seguente ai fini della spiegazione e dell'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 l'area principale del tenant riscontra un'interruzione, i passaggi descritti in questo documento dipendono dal ripristino, che deve essere avviato e completato per la prima volta da Microsoft.

Piani di ripristino specifici per esperienza

Le sezioni seguenti forniscono guide dettagliate per ogni Fabric esperienza per aiutare i clienti attraverso il processo di ripristino.

Ingegneria dei dati

Questa guida illustra le procedure di ripristino per l'esperienza di ingegneria dei dati. Copre i data lakehouse, i notebook e le definizioni dei 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 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 effettivo dell'area 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

Le viste materializzate di Lake dell'area originale continuano a non essere disponibili per i clienti dopo il failover. Le pianificazioni degli aggiornamenti e la cronologia di esecuzione non vengono replicate nell'area secondaria. Per recuperarli, completare i passaggi seguenti dopo aver recuperato i dati di Lakehouse.

• Ripristinare le tabelle Lakehouse usando l'approccio 1 o l'approccio 2 descritto in precedenza. Copiare solo le tabelle di origine.
• Recupera i notebook che contengono le definizioni MLV. Fare riferimento alla sezione Notebook per i passaggi di ripristino.
• Eseguire i notebook ripristinati per ricreare gli MLV nel nuovo Lakehouse. Per informazioni sulla creazione di MLV, vedere Creare una Lake View materializzata. Se le MLV sono state copiate anche nel passaggio precedente, eseguire CREATE OR REPLACE nel momento in cui li si ricrea.
• Ricreare manualmente le operazioni di aggiornamento MLV nella nuova area di lavoro. La cronologia di pianificazione e le metriche di esecuzione non sono recuperabili.
• 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 dell'area primaria rimangono non disponibili per i clienti e il codice nei notebook non viene 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 renderlo facile e rapido consiste nell'usare l'integrazione di 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 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 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 lavoro 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. Le esecuzioni storiche del SJD non verranno 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. 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 informazioni dettagliate sulle Azure Storage Explorer, vedere Integrate OneLake con Azure Storage Explorer.

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 dall'utente con l'integrazione Git (in anteprima pubblica)

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. Aggiornare la definizione di GraphQL in modo che punti alle risorse appena ripristinate modificando i riferimenti specifici dell'ambiente, ad esempio GLI ID dell'area di lavoro di origine, gli ID degli artefatti di origine e i dettagli della connessione. Questo passaggio garantisce la corretta associazione al momento della distribuzione.

4. Ridistribuire gli artefatti GraphQL dal repository Git alla nuova area di lavoro. Questo passaggio ricrea la struttura e la configurazione dell'API usando le definizioni aggiornate.

5. Riapplicare 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. Riapplicare 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 degli artefatti, ad esempio monitoraggio, autorizzazione, RBAC, introspezione e altro ancora, non vengono mantenute 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 

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. Recuperare 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 di Data Warehouse. Copre i magazzini.

Magazzino

I magazzini della regione originale rimangono non disponibili per i clienti. Per recuperare i magazzini, eseguire i seguenti due passaggi.

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

2. Popolare le tabelle Delta del magazzino utilizzando Esplora magazzino e le funzionalità T-SQL (vedere Tables in data warehousing 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 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 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, devi modificare la stringa di connessione nelle applicazioni usando il data warehouse di Fabric.

Il database con mirroring

I database specchiati dall'area primaria continuano a non essere disponibili per i clienti e le impostazioni del database 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 o negli elementi di 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.

Flussi di dati 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.

La funzionalità Salva con nome dei flussi di dati non è supportata in caso di ripristino di emergenza.

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. È consigliabile creare pipeline 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 semplificare e velocizzare questo processo consiste nell'usare l'integrazione Git di Fabric, quindi sincronizzare CopyJob con il repo 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, collegarsi e sincronizzare nuovamente il repo Azure ADO. Tutti gli elementi Fabric in questo repository vengono scaricati automaticamente nella 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.

Attività Apache Airflow

Gli utenti di Apache Airflow Job in Fabric devono intraprendere misure proattive per proteggersi da un disastro regionale.

Si consiglia di gestire la ridondanza con l'integrazione di Fabric con Git. Prima di tutto, sincronizzare il processo Airflow con il repository ADO. Se il servizio esegue il failover in un'altra area, è possibile usare il repository per ricompilare il processo Airflow nella nuova area di lavoro creata.

Ecco i passaggi per ottenere questo risultato:

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

2. Successivamente, si noterà che il processo Airflow è stato 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 verranno scaricati automaticamente nella tua nuova area di lavoro.

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.

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

Gli elementi Graph Model e Graph Queryset dall'area primaria rimangono non disponibili per i clienti e questi elementi non vengono replicati nell'area secondaria. Per procedere al recupero, creazione o utilizzo di una capacità in una regione differente, è necessario ricreare gli elementi Graph Model e Graph Queryset in quella posizione.

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. Ricreare l'elemento Modello grafico nell'area di lavoro secondaria (a cui si fa riferimento nel passaggio 2). Riconfigurare la definizione del modello, inclusi nodi, archi e così via, in modo che corrisponda al modello grafico originale.

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

5. Connettere una Lakehouse come origine dati OneLake per il nuovo 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. Riconfigurare le pianificazioni o le connessioni di caricamento dei dati per il modello Graph nella nuova area di lavoro.

7. Ricreare l'elemento Graph Queryset nell'area di lavoro secondaria. Immettere manualmente le query e le eventuali configurazioni di query salvate dall'insieme di query Graph originale.

Database/set di query KQL

Gli utenti del database/queryset KQL devono intraprendere misure proattive per proteggersi da un disastro regionale. 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 su capacità dedicate di Fabric. Devono essere configurati in due aree Azure diverse (preferibilmente aree abbinate di 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 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 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 Azure come parte di una strategia attiva/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.

Eventi aziendali, eventi Fabric ed eventi di Azure

Anche se gli eventi aziendali, gli eventi Fabric e gli eventi Azure condividono la stessa infrastruttura hub Real-Time in Microsoft Fabric, hanno origini, comportamenti e requisiti di ripristino distinti che devono essere compresi prima di pianificare il ripristino di emergenza:

• Eventi di Fabric sono sottoscrizioni di eventi che reagiscono all'attività generata dalle stesse risorse di Fabric, incluse le modifiche del ciclo di vita degli elementi dell'area di lavoro (quali la creazione, l'aggiornamento o l'eliminazione di lakehouse, notebook o warehouse), le esecuzioni di processi (ad esempio esecuzioni di pipeline o notebook) e le operazioni su file e cartelle di OneLake. Queste sottoscrizioni sono di tipo push ed effimere. Le sottoscrizioni non vengono replicate nell'area geografica 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. Anche se la risorsa Archiviazione BLOB di Azure stessa può rimanere disponibile durante un'interruzione a livello di area Fabric, le sottoscrizioni configurate nell'hub Real-Time non vengono replicate nell'area secondaria e devono essere ricreate.

• 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.

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 nell'hub Real-Time che puntano agli elementi dell'area di lavoro, ai processi o ai percorsi di OneLake ripristinati nell'area di ripristino seguendo l'articolo Esplorare gli eventi Fabric nell'hub Fabric 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.

Per gli eventi Azure:

1. Gli account di 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.

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.

Pianificazione

Questo articolo descrive le procedure di ripristino per l'esperienza Plan in IQ. Descrive i passaggi necessari per ripristinare i componenti chiave, tra cui Planning, PowerTable, Intelligence, InfoBridge e asset di dati correlati.

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 il piano

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 usate in PowerTable: tutte le tabelle create tramite PowerTable vengono archiviate in un database SQL di 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.

Database transazionale

In questa guida vengono descritte le procedure di ripristino per l'esperienza del database transazionale.

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.

A tale scopo, è possibile usare lo strumento dell'interfaccia della riga di comando di SqlPackage che fornisce la portabilità del database e facilita le distribuzioni 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. Archiviare il .bacpac file in un percorso sicuro che si trova in un'area diversa rispetto al database. Gli esempi includono l'archiviazione del file .bacpac in un lakehouse che si trova in un'area diversa, usando un account Archiviazione di Azure con ridondanza geografica o usando un altro supporto di archiviazione sicuro che si trova in un'area 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 vengono riflessi nel database originale. Se si prevede di eseguire il failback nel database originale quando l'area principale diventa disponibile, sarà necessario prendere in considerazione la riconciliazione manuale dei dati dal database ricreato al database originale.

Platform

La piattaforma fa riferimento ai servizi condivisi e all'architettura sottostanti applicabili a tutti i carichi di lavoro. Questa sezione illustra le procedure di ripristino per le esperienze condivise. Copre le librerie di variabili.

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 operazione può essere eseguita tramite l'integrazione di Fabric Git, che garantisce che dopo un'emergenza a livello di area rimanga disponibile la libreria delle variabili di un utente. Per ripristinare una libreria di variabili, è consigliabile:

• 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.

Chiavi gestite dal cliente per aree di lavoro Fabric

È possibile usare chiavi gestite dal cliente (CMK) archiviate in Azure Key Vault per aggiungere un ulteriore livello di crittografia su chiavi gestite da Microsoft per i dati inattivi. Nel caso in cui Fabric diventi inaccessibile o inoperabile in un'area, i relativi componenti eseguiranno il failover in un'istanza di backup. Durante il failover, la funzionalità CMK supporta operazioni di sola lettura. Finché il servizio Azure Key Vault rimane integro e le autorizzazioni per il vault sono intatte, Fabric continuerà a connettersi alla tua chiave e permetterà di leggere normalmente i dati. 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.

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

Nel caso in cui Fabric diventi inaccessibile o inoperabile in un'area, i criteri del ciclo di vita di OneLake possono comunque essere letti e aggiornati durante il failover. I dati spostati nel livello cool o cold resteranno in quel livello. È possibile seguire questa procedura per applicare i criteri esistenti alla nuova area di lavoro di ripristino:

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.

Informazioni collegate

• Microsoft Fabric guida al ripristino di emergenza