Condividi tramite

Indicazioni sul ripristino di emergenza specifiche dell'esperienza

  • Articolo

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

Scenario di esempio

Una serie di sezioni di linee guida in questo documento usa 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 è stato attivato il ripristino di emergenza per la capacità C1, i dati di OneLake verranno replicati in un backup nell'area B. Se l'area A si verifica un'interruzione, il servizio Fabric in C1 esegue il failover nell'area B.

Questo scenario è illustrato nell'immagine seguente. La casella a sinistra mostra l'area interrotta. 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.

Diagramma che illustra uno scenario per emergenza, failover e ripristino completo.

Ecco il piano di ripristino generale:

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

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

  3. Copiare i dati dall'elemento C1 interrotto. Da W1 a C2. W2.

  4. Seguire le istruzioni dedicate per ogni componente per ripristinare gli elementi nella funzione completa.

Piani di ripristino specifici dell'esperienza

Le sezioni seguenti forniscono guide dettagliate per ogni esperienza di infrastruttura 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. Include lakehouse, notebook e definizioni di processi Spark.

Lakehouse

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

Approccio 1: Uso di script personalizzati per copiare tabelle e file Delta lakehouse

I clienti possono ricreare lakehouse usando uno script Scala personalizzato.

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

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

  3. Per recuperare le tabelle e i file dal lakehouse originale, è necessario usare il percorso ABFS per accedere ai dati (vedere Connessione ing in Microsoft OneLake). È possibile usare l'esempio di codice seguente (vedere Introduzione alle utilità di Microsoft Spark) nel notebook per ottenere i percorsi ABFS di file e tabelle dalla lakehouse originale. (Sostituisci C1. W1 con il nome effettivo dell'area di lavoro)

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

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

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

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

    %%spark
val source="abfs path to original Lakehouse file or table directory"
val destination="abfs path to new Lakehouse file or table directory"
val timestamp= //timestamp provided by Support

mssparkutils.fs.cp(source, destination, true)

val filesToDelete = mssparkutils.fs.ls(s"$source/_delta_log")
    .filter{sf => sf.isFile && sf.modifyTime > timestamp}

for(fileToDelte <- filesToDelete) {
    val destFileToDelete = s"$destination/_delta_log/${fileToDelte.name}"
    println(s"Deleting file $destFileToDelete")
    mssparkutils.fs.rm(destFileToDelete, false)
}

mssparkutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)

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

Approccio 2: Usare Archiviazione di Azure Explorer per copiare file e tabelle

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

Nota

I due approcci descritti in precedenza recuperano sia i metadati che i dati per le tabelle in formato Delta, perché i metadati si trovano in modalità condivisa e archiviati con i dati in OneLake. Per le tabelle non formattate delta (e.g. CSV, Parquet e così via) create usando script/comandi DDL (Spark Data Definition Language), l'utente è responsabile della gestione e dell'esecuzione di nuovo degli script/comandi DDL Spark per recuperarli.

Notebook

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

Approccio 1: Ridondanza gestita dall'utente con l'integrazione git (in anteprima pubblica)

Il modo migliore per semplificare e rapidità consiste nell'usare l'integrazione git di Fabric, 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 di Git e selezionare Connessione e sincronizzare con il repository ADO.

    Screenshot che mostra come connettersi e sincronizzare il notebook con il repository ADO.

    L'immagine seguente mostra il notebook sincronizzato.

    Screenshot che mostra il notebook sincronizzato con il repository ADO.

  2. Ripristinare il notebook dal repository ADO.

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

      Screenshot che mostra la riconnessione del notebook al repository ADO.

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

      Screenshot che mostra come aggiornare tutti i notebook in un ramo.

      Screenshot che mostra la nota originale ricreata.

    3. Se il notebook originale ha una lakehouse predefinita, gli utenti possono fare riferimento alla sezione Lakehouse per recuperare il lakehouse e quindi connettere la nuova lakehouse ripristinata al notebook appena ripristinato.

      Screenshot che mostra come connettere un lakehouse ripristinato a un notebook ripristinato.

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

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

        1. Assicurarsi di salvare file o cartelle in 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 il notebook originale ha uno snapshot del notebook, salvare anche lo snapshot del notebook nel sistema di controllo della versione o nel disco locale.

        Screenshot che mostra come eseguire il notebook per salvare gli snapshot.

        Screenshot che mostra come salvare gli snapshot del notebook.

Per altre informazioni sull'integrazione con Git, vedere Introduzione all'integrazione di 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.

    Screenshot che mostra come importare il codice del notebook.

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

  3. Se il notebook originale ha una lakehouse predefinita, 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 processo Spark

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

È possibile ripristinare gli elementi SJD copiando il codice dall'area originale usando Archiviazione di Azure 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, lingua, ambiente e così via).

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

    Screenshot che mostra come copiare dalla definizione originale del processo Spark alla nuova definizione del processo Spark.

  3. Il contenuto del codice verrà visualizzato nel SJD appena creato. È necessario aggiungere manualmente il riferimento a 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.

    Screenshot che mostra gli argomenti della riga di comando per ripristinare la definizione del processo Spark.

È ora possibile eseguire o pianificare il nuovo SJD ripristinato.

Per informazioni dettagliate su Esplora Archiviazione di Azure, vedere Integrare OneLake con Archiviazione di Azure Explorer.

Data science

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

Modello e esperimento di Machine Learning

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

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

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

Data warehouse

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

Magazzino

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

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

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

Nota

È consigliabile mantenere il codice warehouse (schema, tabella, vista, stored procedure, definizioni di funzione e codici di sicurezza) con controllo delle versioni e salvato in una posizione sicura (ad esempio Git) in base alle procedure di sviluppo.

Inserimento di dati tramite Lakehouse e codice T-SQL

Nell'area di lavoro appena creata C2. W2:

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

  2. Recuperare le tabelle Delta nel lakehouse provvisorio dal magazzino originale seguendo i passaggi di ripristino di Lakehouse.

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

  4. Connessione il lakehouse provvisorio in warehouse explorer.

    Screenshot di Warehouse Explorer durante il ripristino 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 IN edizione Standard RT INTO, edizione Standard LECT INTO o CREATE TABLE AS edizione Standard LECT per ripristinare le tabelle warehouse da lakehouse. Più avanti nell'esempio si usa il sapore IN edizione Standard RT INTO. Se si usa il codice seguente, sostituire gli esempi con i nomi effettivi di tabella e colonna.

    USE WH1

INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])

SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
GO

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

Nota

Per i clienti che necessitano di ripristino di emergenza tra aree e continuità aziendale completamente automatizzata, è consigliabile mantenere due configurazioni di Fabric Warehouse in aree di infrastruttura separate e mantenere la parità di codice e dati eseguendo distribuzioni regolari e inserimento di dati in entrambi i siti.

Data Factory

Gli elementi di Data Factory dell'area primaria rimangono non disponibili per i clienti e le impostazioni e la configurazione nelle pipeline di dati o negli elementi 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 Integrazione dei dati in un'altra area di lavoro da un'area diversa. Le sezioni seguenti descrivono i dettagli.

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.

    Screenshot che mostra l'editor di Power Query, con l'opzione Esporta modello evidenziata.

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

    Screenshot che mostra come esportare un modello.

  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.

    Screenshot che mostra la visualizzazione corrente con l'opzione Importa da un modello di Power Query evidenziata.

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

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

Pipeline di dati

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

Intelligenza in tempo reale

Questa guida illustra le procedure di ripristino per l'esperienza di intelligence in tempo reale. Vengono illustrati database/queryset KQL e flussi di eventi.

Database KQL/Queryset

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

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

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

  2. Replicare le attività di gestione: qualsiasi azione di gestione eseguita in un database KQL deve essere con mirroring nell'altra. 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 una conservazione dei dati, un 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 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, i flussi di eventi non perderanno i dati. Pertanto, i clienti devono usare le funzionalità di ripristino di emergenza di tali sistemi di destinazione per garantire la disponibilità dei dati.

I clienti possono anche ottenere la ridondanza geografica distribuendo carichi di lavoro Eventstream identici in più aree di Azure come parte di una strategia attiva/attiva multisito. Con un approccio attivo/attivo multisito, i clienti possono accedere al carico di lavoro in una qualsiasi delle aree distribuite. Questo approccio è l'approccio più complesso e costoso al ripristino di emergenza, ma può ridurre il tempo di ripristino a quasi zero nella maggior parte delle situazioni. Per essere completamente con ridondanza geografica, i clienti possono

  1. Creare repliche delle origini dati in aree diverse.

  2. Creare elementi Eventstream nelle aree corrispondenti.

  3. Connessione questi nuovi elementi alle origini dati identiche.

  4. Aggiungere destinazioni identiche per ogni flusso di eventi in aree diverse.