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à sono gruppi di data center separati fisicamente all'interno di ogni area di Azure. In caso di errore di una zona, i servizi possono eseguire il failover in una delle zone rimanenti.
Per altre informazioni sulle zone di disponibilità in Azure, vedere Che cosa sono le zone 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).
- Le esperienze come Flussi di eventi non supportano le zone di disponibilità.
- La progettazione dei dati supporta le zone di disponibilità se si usa OneLake. Se si usano altre origini dati, ad esempio ADLS Gen2, è necessario assicurarsi che l'archiviazione con ridondanza della zona sia abilitata.
- La disponibilità della zona può essere disponibile o meno per le esperienze dell'infrastruttura e/o le funzionalità/funzionalità disponibili in anteprima.
- I gateway locali e i modelli semantici di grandi dimensioni in Power BI non supportano le zone di disponibilità.
- Data Factory (pipeline) supporta le zone di disponibilità in Europa occidentale, ma le esecuzioni di pipeline nuove o in ingresso potrebbero non riuscire in caso di interruzione della zona.
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 | Pipeline di Data Factory di Azure | Ingegneria dei dati | Database SQL |
---|---|---|---|---|---|---|---|
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 | Pipeline di Data Factory di Azure | Ingegneria dei dati | Database SQL |
Francia centrale | |||||||
Germania centro-occidentale | |||||||
Italia settentrionale | |||||||
Europa settentrionale | |||||||
Norvegia orientale | |||||||
Polonia Centrale | |||||||
Regno Unito meridionale | |||||||
Europa occidentale | |||||||
Medio Oriente | Power BI | Datamarts | Data warehouse | Analisi in tempo reale | Pipeline di Data Factory di Azure | Ingegneria dei dati | Database SQL |
Qatar centrale | |||||||
Israele centrale | |||||||
Africa | Power BI | Datamarts | Data warehouse | Analisi in tempo reale | Pipeline di Data Factory di Azure | Ingegneria dei dati | Database SQL |
Sudafrica settentrionale | |||||||
Asia/Pacifico | Power BI | Datamarts | Data warehouse | Analisi in tempo reale | Pipeline di Data Factory di Azure | Ingegneria dei dati | Database SQL |
Australia orientale | |||||||
Giappone orientale | |||||||
Asia sud-orientale |
Esperienza di inattività della zona
Durante un'interruzione a livello di zona non è necessaria alcuna azione durante il ripristino della zona. Le funzionalità di Fabric nelle aree elencate in aree supportate si auto-ripristinano e si ribilanciano automaticamente per sfruttare la zona integra. L'esecuzione di processi Spark potrebbe non riuscire se il nodo master si trova nella zona non riuscita. In questo caso, i processi dovranno essere inviati di nuovo.
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 a quella normale.
Ripristino di emergenza e continuità aziendale tra aree
Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri 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 a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per questi servizi, si è responsabili 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 (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il 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 replica con ridondanza geografica di Archiviazione di Azure e replica con ridondanza geografica 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 dati in un'altra area, è necessario abilitare Multi-Geo, una funzionalità Fabric Premium.
Importante
La scelta di un'area diversa per la capacità non rialloca 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 dell'infrastruttura.
Impostazione della capacità di ripristino di emergenza
Fabric fornisce un commutatore di ripristino di emergenza nella pagina delle impostazioni della capacità. È disponibile dove 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, inclusi 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,
Nota
Dopo aver attivato l'impostazione della capacità di ripristino di emergenza, l'avvio della replica dei dati può richiedere fino a una settimana.
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 di con zone di disponibilità e nessuna coppia di aree e disponibilità dell'area di Fabric.
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à usa più spazio di archiviazione e transazioni, che vengono fatturate rispettivamente come operazioni BCDR Storage e BCDR. È possibile monitorare e gestire questi costi nell'app Microsoft Fabric Capacity Metrics, dove 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 di 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 Fabric: è possibile accedere al portale e leggere operazioni come l'esplorazione di aree di lavoro e 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 di 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:
API OneLake ADLS Gen2: vedere Connessione a Microsoft OneLake
Esempi di strumenti che possono connettersi ai dati di OneLake:
Azure Storage Explorer: vedere Integrare OneLake con Azure Storage Explorer
OneLake File Explorer: vedere Usare OneLake File Explorer per accedere ai dati di Fabric
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
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.
Creare aree di lavoro nella capacità appena creata. Se necessario, usare gli stessi nomi delle aree di lavoro precedenti.
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.
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.