Affidabilità in Microsoft Fabric

Questo articolo descrive il supporto per l'affidabilità in Microsoft Fabric e la resilienza a livello di area con zone di disponibilità e ripristino tra aree e continuità aziendale. Per una panoramica più dettagliata dell'affidabilità in Azure, vedere Affidabilità di Azure.

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.

Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.

Fabric si impegna commercialmente in modo ragionevole per supportare le zone di disponibilità con ridondanza della zona, in cui le risorse vengono replicate automaticamente tra zone, senza dover configurare o configurare.

Prerequisiti

  • Fabric offre attualmente il supporto parziale della zona di disponibilità in un numero limitato di aree. Questo supporto parziale della zona di disponibilità copre le esperienze (e/o alcune funzionalità all'interno di un'esperienza).
  • Esperienze come Data Factory (pipeline), Ingegneria dei dati, data science ed eventi Flussi non supportano le zone di disponibilità.
  • La disponibilità della zona può essere disponibile o meno per le esperienze o le funzionalità dell'infrastruttura disponibili in anteprima.
  • I gateway locali e i modelli semantici di grandi dimensioni in Power BI non supportano le zone di disponibilità.

Aree geografiche supportate

Fabric effettua sforzi commercialmente ragionevoli per fornire il supporto della zona di disponibilità in varie aree, come indicato di seguito:

Americhe Power BI Datamarts Data Warehouse Analisi in tempo reale
Brasile meridionale
Canada centrale
Stati Uniti centrali
Stati Uniti orientali
Stati Uniti orientali 2
Stati Uniti centro-meridionali
West US 2
Stati Uniti occidentali 3
Europa Power BI Datamarts Data Warehouse Analisi in tempo reale
Francia centrale
Germania centro-occidentale
Europa settentrionale
Regno Unito meridionale
Europa occidentale
Norvegia orientale
Medio Oriente Power BI Datamarts Data Warehouse Analisi in tempo reale
Qatar centrale
Africa Power BI Datamarts Data Warehouse Analisi in tempo reale
Sudafrica settentrionale
Asia/Pacifico Power BI Datamarts Data Warehouse Analisi in tempo reale
Australia orientale
Giappone orientale
Asia sud-orientale

Esperienza di riduzione della zona

Durante un'interruzione a livello di zona non è necessaria alcuna azione durante il ripristino della zona. Funzionalità dell'infrastruttura nelle aree elencate nelle aree supportate auto-guarigione e ribilanciamento automatico per sfruttare la zona integra.

Importante

Sebbene Microsoft si impegna a fornire un supporto uniforme e coerente per la zona di disponibilità, in alcuni casi di errore della zona di disponibilità, le capacità di Fabric che si trovano nelle aree di Azure con fluttuazioni più elevate della domanda dei clienti potrebbero riscontrare una latenza superiore alla normale.

Ripristino di emergenza tra aree e continuità aziendale

Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.

Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.

Questa sezione descrive un piano di ripristino di emergenza per Fabric progettato per aiutare l'organizzazione a mantenere i dati sicuri e accessibili quando si verifica un'emergenza a livello di area non pianificata. Il piano illustra gli argomenti seguenti:

  • Replica tra aree: Fabric offre la replica tra aree per i dati archiviati in OneLake. È possibile acconsentire esplicitamente o rifiutare questa funzionalità in base alle proprie esigenze.

  • Accesso ai dati dopo l'emergenza: in uno scenario di emergenza a livello di area Fabric garantisce l'accesso ai dati, con determinate limitazioni. Mentre la creazione o la modifica di nuovi elementi è limitata dopo il failover, l'obiettivo principale rimane quello di garantire che i dati esistenti rimangano accessibili e intatti.

  • Linee guida per il ripristino: Fabric fornisce un set strutturato di istruzioni che consentono di eseguire il processo di ripristino. Le linee guida strutturate semplificano la transizione alle normali operazioni.

Power BI, ora parte dell'infrastruttura, include un solido sistema di ripristino di emergenza e offre le funzionalità seguenti:

  • BCDR come impostazione predefinita: Power BI include automaticamente le funzionalità di ripristino di emergenza nell'offerta predefinita. Non è necessario acconsentire esplicitamente o attivare questa funzionalità separatamente.

  • Replica tra aree: Power BI usa la replica con ridondanza geografica e la replica con ridondanza geografica di Archiviazione di Azure SQL per garantire che le istanze di backup esistano in altre aree e possano essere usate. Ciò significa che i dati vengono duplicati in aree diverse, migliorandone la disponibilità e riducendo i rischi associati alle interruzioni a livello di area.

  • Servizi e accesso continui dopo l'emergenza: anche durante gli eventi di interruzione, gli elementi di Power BI rimangono accessibili in modalità di sola lettura. Gli elementi includono modelli semantici, report e dashboard, assicurandosi che le aziende possano continuare l'analisi e i processi decisionali senza ostacoli significativi.

Per altre informazioni, vedere Domande frequenti sulla disponibilità elevata, sul failover e sul ripristino di emergenza di Power BI

Importante

Per i clienti le cui aree di origine non hanno un'area di coppia di Azure e sono interessate da un'emergenza, la possibilità di usare le capacità di Fabric può essere compromessa, anche se i dati all'interno di tali capacità vengono replicati. Questa limitazione è legata all'infrastruttura dell'area principale, essenziale per il funzionamento delle capacità.

Area principale e funzionalità di capacità

Per una pianificazione efficace del ripristino di emergenza, è fondamentale comprendere la relazione tra l'area principale e le località di capacità. Comprendere l'area principale e le posizioni di capacità consente di effettuare selezioni strategiche delle aree di capacità, nonché i processi di replica e ripristino corrispondenti.

L'area principale per la tenancy e l'archiviazione dei dati dell'organizzazione è impostata sulla posizione dell'indirizzo di fatturazione del primo utente che effettua l'iscrizione. Per altri dettagli sulla configurazione della tenancy, vedere Pianificazione dell'implementazione di Power BI: Configurazione del tenant. Quando si creano nuove capacità, l'archiviazione dei dati viene impostata sull'area principale per impostazione predefinita. Se si vuole modificare l'area di archiviazione dei dati in un'altra area, è necessario abilitare multi-geo, una funzionalità Fabric Premium.

Importante

La scelta di un'area diversa per la capacità non riloca completamente tutti i dati in tale area. Alcuni elementi dati rimangono ancora archiviati nell'area principale. Per vedere quali dati rimangono nell'area principale e quali dati vengono archiviati nell'area abilitata per più aree geografiche, vedere Configurare il supporto multi-geo per Fabric Premium.

Nel caso di un'area domestica che non dispone di un'area abbinata, le capacità in qualsiasi area abilitata per più aree geografiche possono riscontrare problemi operativi se l'area principale riscontra un'emergenza, perché la funzionalità del servizio principale viene associata all'area principale.

Se si seleziona un'area abilitata per più aree geografiche all'interno dell'UE, è garantito che i dati vengano archiviati entro il limite dei dati dell'UE.

Per informazioni su come identificare l'area principale, vedere Trovare l'area principale di Fabric.

Impostazione della capacità di ripristino di emergenza

Fabric fornisce un commutatore di ripristino di emergenza nella pagina delle impostazioni della capacità. È disponibile in cui le associazioni a livello di area di Azure sono allineate alla presenza del servizio di Fabric. Ecco le specifiche di questa opzione:

  • Accesso ai ruoli: solo gli utenti con il ruolo di amministratore della capacità o versione successiva possono usare questa opzione.

  • Granularità: la granularità del commutatore è il livello di capacità. È disponibile per le capacità Premium e Fabric.

  • Ambito dati: l'interruttore di ripristino di emergenza indirizza in modo specifico i dati di OneLake, che includono i dati di Lakehouse e Warehouse. L'opzione non influenza i dati archiviati all'esterno di OneLake.

  • Continuità BCDR per Power BI: mentre il ripristino di emergenza per i dati OneLake può essere attivato e disattivato, BCDR per Power BI è sempre supportato, indipendentemente dal fatto che l'opzione sia attivata o disattivata.

  • Frequenza: dopo aver modificato l'impostazione della capacità di ripristino di emergenza, è necessario attendere 30 giorni prima di poterla modificare di nuovo. Il periodo di attesa è impostato per mantenere la stabilità e impedire l'attivazione o disattivazione costante.

Screenshot of the disaster recovery tenant setting.

Nota

Dopo aver attivato l'impostazione della capacità di ripristino di emergenza, possono essere necessarie fino a 72 ore prima che i dati inizino la replica.

Replica dei dati

Quando si attiva l'impostazione della capacità di ripristino di emergenza, la replica tra aree è abilitata come funzionalità di ripristino di emergenza per i dati di OneLake. La piattaforma Fabric è allineata alle aree di Azure per effettuare il provisioning delle coppie di ridondanza geografica. Tuttavia, alcune aree non hanno un'area di coppia di Azure o l'area della coppia non supporta Fabric. Per queste aree, la replica dei dati non è disponibile. Per altre informazioni, vedere Aree con zone di disponibilità e nessuna coppia di aree e disponibilità dell'area infrastruttura.

Nota

Sebbene Fabric offra una soluzione di replica dei dati in OneLake per supportare il ripristino di emergenza, esistono limitazioni rilevanti. Ad esempio, i dati dei database KQL e dei set di query vengono archiviati esternamente a OneLake, il che significa che è necessario un approccio di ripristino di emergenza separato. Per informazioni dettagliate sull'approccio al ripristino di emergenza per ogni elemento di Infrastruttura, vedere il resto di questo documento.

Fatturazione

La funzionalità di ripristino di emergenza in Fabric consente la replica geografica dei dati per una maggiore sicurezza e affidabilità. Questa funzionalità utilizza più risorse di archiviazione e transazioni, fatturate rispettivamente come operazioni BCDR Archiviazione e BCDR. È possibile monitorare e gestire questi costi nell'app Microsoft Fabric Capacity Metrics, in cui vengono visualizzati come voci separate.

Per una suddivisione completa di tutti i costi di ripristino di emergenza associati per pianificare e budget di conseguenza, vedere Utilizzo di risorse di calcolo e archiviazione di OneLake.

Configurare il ripristino di emergenza

Sebbene Fabric fornisca funzionalità di ripristino di emergenza per supportare la resilienza dei dati, è necessario seguire alcuni passaggi manuali per ripristinare il servizio durante le interruzioni. Questa sezione descrive in dettaglio le azioni da eseguire per prepararsi a potenziali interruzioni.

Fase 1: Preparare

  • Attivare le impostazioni della capacità di ripristino di emergenza: esaminare e impostare regolarmente le impostazioni di capacità di ripristino di emergenza per assicurarsi che soddisfino le esigenze di protezione e prestazioni.

  • Creare backup dei dati: copiare i dati critici archiviati all'esterno di OneLake in un'altra area in modo da allinearsi al piano di ripristino di emergenza.

Fase 2: Failover di emergenza

Quando un'emergenza grave rende irreversibile l'area primaria, Microsoft Fabric avvia un failover a livello di area. L'accesso al portale di Infrastruttura non è disponibile fino al completamento del failover e viene inviata una notifica nella pagina del supporto di Microsoft Fabric.

Il tempo necessario per il completamento del failover può variare, anche se in genere richiede meno di un'ora. Al termine del failover, ecco quanto previsto:

  • Portale di Infrastruttura: è possibile accedere al portale e leggere operazioni come l'esplorazione delle aree di lavoro e gli elementi esistenti continuano a funzionare. Tutte le operazioni di scrittura, ad esempio la creazione o la modifica di un'area di lavoro, vengono sospese.

  • Power BI: è possibile eseguire operazioni di lettura, ad esempio la visualizzazione di dashboard e report. Gli aggiornamenti, le operazioni di pubblicazione dei report, il dashboard e le modifiche dei report e altre operazioni che richiedono modifiche ai metadati non sono supportate.

  • Lakehouse/Warehouse: non è possibile aprire questi elementi, ma è possibile accedere ai file tramite le API o gli strumenti di OneLake.

  • Definizione processo Spark: non è possibile aprire le definizioni dei processi Spark, ma è possibile accedere ai file di codice tramite le API o gli strumenti di OneLake. Tutti i metadati o la configurazione verranno salvati dopo il failover.

  • Notebook: non è possibile aprire i notebook e il contenuto del codice non verrà salvato dopo l'emergenza.

  • Modello/esperimento ml: non è possibile aprire modelli o esperimenti di Machine Learning. Il contenuto del codice e i metadati, ad esempio le metriche di esecuzione e le configurazioni, non verranno salvati dopo l'emergenza.

  • Dataflow Gen2/Pipeline/Eventstream: non è possibile aprire questi elementi, ma è possibile usare destinazioni di ripristino di emergenza supportate (lakehouse o warehouse) per proteggere i dati.

  • KQL Database/Queryset: non sarà possibile accedere ai database KQL e ai set di query dopo il failover. Sono necessari altri passaggi prerequisiti per proteggere i dati nei database KQL e nei set di query.

In uno scenario di emergenza, il portale dell'infrastruttura e Power BI sono in modalità di sola lettura e altri elementi di Fabric non sono disponibili, è possibile accedere ai dati archiviati in OneLake usando API o strumenti di terze parti. Sia il portale che Power BI mantengono la possibilità di eseguire operazioni di lettura/scrittura su tali dati. Questa capacità garantisce che i dati critici rimangano accessibili e modificabili e mitigano potenziali interruzioni delle operazioni aziendali.

I dati di OneLake rimangono accessibili tramite più canali:

Fase 3: Piano di ripristino

Anche se Fabric garantisce che i dati rimangano accessibili dopo un'emergenza, è anche possibile agire per ripristinare completamente i servizi nello stato prima dell'evento imprevisto. Questa sezione fornisce una guida dettagliata che consente di eseguire il processo di ripristino.

Procedura di ripristino

  1. Creare una nuova capacità infrastruttura in qualsiasi area dopo un'emergenza. Data la domanda elevata durante tali eventi, è consigliabile selezionare un'area esterna all'area geografica primaria per aumentare la probabilità di disponibilità del servizio di calcolo. Per informazioni sulla creazione di una capacità, vedere Acquistare una sottoscrizione di Microsoft Fabric.

  2. Creare aree di lavoro nella capacità appena creata. Se necessario, usare gli stessi nomi delle aree di lavoro precedenti.

  3. Creare elementi con gli stessi nomi di quelli che si desidera ripristinare. Questo passaggio è importante se si usa lo script personalizzato per recuperare lakehouse e magazzini.

  4. Ripristinare gli elementi. Per ogni elemento, seguire la sezione pertinente nel materiale sussidiario relativo al ripristino di emergenza specifico dell'esperienza per ripristinare l'elemento.

Passaggi successivi