Creare soluzioni di continuità aziendale e ripristino di emergenza con Esplora dati di Azure
Questo articolo illustra in dettaglio come prepararsi per un'interruzione a livello di area di Azure replicando le risorse, la gestione e l'inserimento di azure Esplora dati in aree di Azure diverse. Viene fornito un esempio di inserimento dati con Hub eventi di Azure. L'ottimizzazione dei costi viene illustrata anche per diverse configurazioni di architettura. Per un'analisi più approfondita delle considerazioni sull'architettura e sulle soluzioni di ripristino, vedere la panoramica della continuità aziendale.
Preparare l'interruzione a livello di area di Azure per proteggere i dati
Azure Esplora dati non supporta la protezione automatica contro l'interruzione di un'intera area di Azure. Questa interruzione può verificarsi durante una calamità naturale, ad esempio un terremoto. Se è necessaria una soluzione per una situazione di ripristino di emergenza, seguire questa procedura per garantire la continuità aziendale. In questi passaggi si eseguirà la replica dei cluster, della gestione e dell'inserimento dei dati in due aree abbinate di Azure.
- Creare due o più cluster indipendenti in due aree abbinate di Azure.
- Replicare tutte le attività di gestione, ad esempio la creazione di nuove tabelle o la gestione dei ruoli utente in ogni cluster.
- Inserire i dati in ogni cluster in parallelo.
Creare più cluster indipendenti
Creare più cluster Esplora dati di Azure in più aree. Assicurarsi che almeno due di questi cluster vengano creati nelle aree abbinate di Azure.
L'immagine seguente mostra le repliche, tre cluster in tre aree diverse.
Replicare le attività di gestione
Replicare le attività di gestione in modo che abbiano la stessa configurazione del cluster in ogni replica.
Creare in ogni replica la stessa:
- Database: è possibile usare il portale di Azure o uno degli SDK per creare un nuovo database.
- Tabelle
- Mappings
- Criteri
Gestire l'autenticazione e l'autorizzazione in ogni replica.
Soluzione di ripristino di emergenza con l'inserimento dell'hub eventi
Dopo aver completato Preparare l'interruzione a livello di area di Azure per proteggere i dati, i dati e la gestione vengono distribuiti in più aree. Se si verifica un'interruzione in un'area, Azure Esplora dati sarà in grado di usare le altre repliche.
Configurare l'inserimento usando un hub eventi
Per inserire dati da Hub eventi di Azure nel cluster di Azure Esplora dati di ogni area, replicare prima di tutto la configurazione di Hub eventi di Azure in ogni area. Configurare quindi la replica di Azure Esplora dati di ogni area per inserire i dati dai corrispondenti Hub eventi.
Nota
L'inserimento tramite Hub eventi di Azure/hub IoT/archiviazione è affidabile. Se un cluster non è disponibile per un periodo di tempo, verrà aggiornato in un secondo momento e inserirà eventuali messaggi o BLOB in sospeso. Questo processo si basa sul checkpoint.
Come illustrato nel diagramma seguente, le origini dati producono eventi agli hub eventi in tutte le aree e ogni replica di Azure Esplora dati usa gli eventi. I componenti di visualizzazione dei dati come Power BI, Grafana o App Web basate su SDK possono eseguire query su una delle repliche.
Ottimizzazione dei costi
A questo momento è possibile ottimizzare le repliche usando alcuni dei metodi seguenti:
- Creare una configurazione di ripristino dei dati su richiesta
- Avviare e arrestare le repliche
- Implementare un servizio applicazioni a disponibilità elevata
- Ottimizzare i costi in una configurazione attiva-attiva
Creare una configurazione di ripristino dei dati su richiesta
La replica e l'aggiornamento della configurazione di Azure Esplora dati aumentano in modo lineare il costo con il numero di repliche. Per ottimizzare i costi, è possibile implementare una variante dell'architettura per bilanciare il tempo, il failover e i costi. In una configurazione di ripristino dei dati su richiesta, l'ottimizzazione dei costi è stata implementata introducendo repliche di Azure Esplora dati passive. Queste repliche vengono attivate solo se si verifica un'emergenza nell'area primaria, ad esempio l'area A. Le repliche nelle aree B e C non devono essere attive 24/7, riducendo significativamente il costo. Nella maggior parte dei casi, tuttavia, le prestazioni di queste repliche non saranno ottimali come il cluster primario. Per altre informazioni, vedere Configurazione del ripristino dei dati su richiesta.
Nell'immagine seguente un solo cluster inserisce i dati dall'hub eventi. Il cluster primario nell'area A esegue l'esportazione continua dei dati di tutti i dati in un account di archiviazione. Le repliche secondarie hanno accesso ai dati usando tabelle esterne.
Avviare e arrestare le repliche
È possibile avviare e arrestare le repliche secondarie usando uno dei metodi seguenti:
Connettore di Azure Esplora dati a Power Automate (anteprima)
Pulsante Arresta nella scheda Panoramica della portale di Azure. Per altre informazioni, vedere Arrestare e riavviare il cluster.
Interfaccia della riga di comando di Azure:
az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>"
Implementare un servizio applicazioni a disponibilità elevata
Creare il client BCDR del servizio app Azure
Questa sezione illustra come creare un servizio app Azure che supporta una connessione a un singolo cluster di Azure Esplora dati primario e secondario. L'immagine seguente illustra la configurazione del servizio app Azure.
Suggerimento
La presenza di più connessioni tra repliche nello stesso servizio offre una maggiore disponibilità. Questa configurazione non è utile solo in caso di interruzioni a livello di area.
Usare questo codice boilerplate per un servizio app. Per implementare un client multi-cluster, è stata creata la classe AdxBcdrClient . Ogni query eseguita usando questo client verrà inviata prima al cluster primario. In caso di errore, la query verrà inviata alle repliche secondarie.
Usare le metriche personalizzate di Application Insights per misurare le prestazioni e richiedere la distribuzione ai cluster primari e secondari.
Testare il client BCDR del servizio app Azure
È stato eseguito un test usando più repliche di Azure Esplora dati. Dopo un'interruzione simulata dei cluster primari e secondari, è possibile notare che il client BCDR del servizio app si comporta come previsto.
I cluster di Azure Esplora dati vengono distribuiti in Europa occidentale (2xD14v2 primario), Asia sud-orientale e Stati Uniti orientali (2xD11v2).
Nota
I tempi di risposta più lenti sono dovuti a SKU diversi e query su più pianeti.
Eseguire il routing dinamico o statico
Usare Gestione traffico di Azure metodi di routing per il routing dinamico o statico delle richieste. Gestione traffico di Azure è un servizio di bilanciamento del carico del traffico basato su DNS che consente di distribuire il traffico del servizio app. Questo traffico è ottimizzato per i servizi tra aree di Azure globali, offrendo al tempo stesso disponibilità elevata e velocità di risposta.
È anche possibile usare il routing basato su Frontdoor di Azure. Per un confronto tra questi due metodi, vedere Bilanciamento del carico con la suite di distribuzione di applicazioni di Azure.
Ottimizzare i costi in una configurazione attiva-attiva
L'uso di una configurazione attiva-attiva per il ripristino di emergenza aumenta il costo in modo lineare. Il costo include nodi, archiviazione, markup e costi di rete maggiori per la larghezza di banda.
Usare la scalabilità automatica ottimizzata per ottimizzare i costi
Usare la funzionalità di scalabilità automatica ottimizzata per configurare la scalabilità orizzontale per i cluster secondari. Devono essere dimensionati in modo che possano gestire il carico di inserimento. Una volta che il cluster primario non è raggiungibile, i cluster secondari otterranno più traffico e scalabilità in base alla configurazione.
L'uso della scalabilità automatica ottimizzata in questo esempio ha salvato circa il 50% del costo rispetto alla stessa scala orizzontale e verticale su tutte le repliche.