Continuità aziendale e panoramica di ripristino di emergenza

La continuità aziendale e il ripristino di emergenza in Azure Esplora dati consente all'azienda di continuare a funzionare in caso di interruzione. Questo articolo illustra la disponibilità (all'interno dell'area) e il ripristino di emergenza. Descrive in dettaglio le funzionalità native e le considerazioni sull'architettura per una distribuzione resiliente di Azure Esplora dati. Descrive in dettaglio il ripristino da errori umani, disponibilità elevata, seguito da più configurazioni di ripristino di emergenza. Queste configurazioni dipendono dai requisiti di resilienza, ad esempio l'obiettivo del punto di ripristino (RPO) e l'obiettivo del tempo di ripristino (RTO), il lavoro necessario e i costi.

Attenuare gli eventi di interruzione

• Errore umano
• Disponibilità elevata di Azure Esplora dati
• Interruzione di una zona di disponibilità di Azure
• Interruzione di un data center di Azure
• Interruzione di un'area di Azure

Errore umano

Gli errori umani sono inevitabili. Gli utenti possono eliminare accidentalmente un cluster, un database o una tabella.

Eliminazione accidentale del cluster o del database

L'eliminazione accidentale del cluster o del database è un'azione irreversibile. In qualità di proprietario della risorsa Esplora dati di Azure, è possibile evitare la perdita di dati abilitando la funzionalità di blocco di eliminazione, disponibile a livello di risorsa di Azure.

Eliminazione accidentale della tabella

Gli utenti con autorizzazioni di amministratore tabella o superiori possono eliminare le tabelle. Se uno di questi utenti elimina accidentalmente una tabella, è possibile recuperarla usando il .undo drop table comando . Affinché questo comando venga completato correttamente, è prima necessario abilitare la proprietà di ripristinabilità nei criteri di conservazione.

Eliminazione accidentale di tabelle esterne

Le tabelle esterne sono entità dello schema di query Kusto che fanno riferimento ai dati archiviati all'esterno del database. L'eliminazione di una tabella esterna elimina solo i metadati della tabella. È possibile recuperarli eseguendo di nuovo il comando di creazione della tabella. Usare la funzionalità di eliminazione temporanea per proteggersi dall'eliminazione accidentale o dalla sovrascrittura di un file/BLOB per un periodo di tempo configurato dall'utente.

Disponibilità elevata di Azure Esplora dati

La disponibilità elevata si riferisce alla tolleranza di errore di Azure Esplora dati, ai relativi componenti e alle dipendenze sottostanti all'interno di un'area di Azure. Questa tolleranza di errore evita singoli punti di errore (SPOF) nell'implementazione. In Azure Esplora dati la disponibilità elevata include il livello di persistenza, il livello di calcolo e una configurazione leader-follower.

Livello di persistenza

Azure Esplora dati sfrutta Archiviazione di Azure come livello di persistenza durevole. Archiviazione di Azure fornisce automaticamente la tolleranza di errore, con l'impostazione predefinita che offre archiviazione con ridondanza locale (LRS) all'interno di un data center. Vengono mantenute tre repliche. Se una replica viene persa durante l'uso, un'altra viene distribuita senza interruzioni. Un'ulteriore resilienza è possibile con l'archiviazione con ridondanza della zona che inserisce le repliche in modo intelligente tra le zone di disponibilità a livello di area di Azure per ottenere la massima tolleranza di errore a un costo aggiuntivo. L'archiviazione abilitata per l'archiviazione con ridondanza della zona viene configurata automaticamente quando il cluster Esplora dati di Azure viene distribuito in zone di disponibilità.

Livello di calcolo

Azure Esplora dati è una piattaforma di elaborazione distribuita e può avere due o più nodi a seconda del tipo di ruolo scale e node. In fase di provisioning selezionare le zone di disponibilità per distribuire la distribuzione del nodo, tra zone per la resilienza massima all'interno dell'area. Un errore della zona di disponibilità non comporterà un'interruzione completa, ma una riduzione delle prestazioni fino al ripristino della zona.

Configurazione del cluster leader-follower

Azure Esplora dati offre una funzionalità di follower facoltativa per un cluster leader da seguire da altri cluster follower per l'accesso in sola lettura ai dati e ai metadati del leader. Le modifiche nel leader, ad esempio create, appende drop vengono sincronizzate automaticamente con il follower. Anche se i leader potrebbero estendersi in aree di Azure, i cluster di follower devono essere ospitati nella stessa area o nelle stesse aree del leader. Se il cluster leader è inattivo o i database o le tabelle vengono accidentalmente eliminati, i cluster follower perderanno l'accesso fino a quando l'accesso non viene ripristinato nel leader.

Interruzione di una zona di disponibilità di Azure

Le Zone di disponibilità di Azure sono località fisiche univoche all'interno della stessa area di Azure. Possono proteggere le risorse di calcolo e i dati di un cluster di Azure Esplora dati da un errore parziale dell'area. L'errore di zona è uno scenario di disponibilità in quanto si trova all'interno dell'area.

Aggiungere un cluster Esplora dati di Azure alla stessa zona delle altre risorse di Azure connesse. Per altre informazioni sull'abilitazione delle zone di disponibilità, vedere Creare un cluster.

Interruzione di un data center di Azure

Le zone di disponibilità di Azure hanno un costo e alcuni clienti scelgono di eseguire la distribuzione senza ridondanza di zona. Con una distribuzione di azure Esplora dati di questo tipo, un'interruzione del data center di Azure comporterà un'interruzione del cluster. La gestione di un'interruzione del data center di Azure è quindi identica a quella di un'interruzione dell'area di Azure.

Interruzione di un'area di Azure

Azure Esplora dati non offre protezione automatica contro l'interruzione di un'intera area di Azure. Per ridurre al minimo l'impatto aziendale in caso di interruzione di questo tipo, più cluster di Azure Esplora dati tra aree abbinate di Azure. In base all'obiettivo del tempo di ripristino (RTO), all'obiettivo del punto di ripristino (RPO), nonché alle considerazioni relative ai costi e alle attività, sono disponibili più configurazioni di ripristino di emergenza. Le ottimizzazioni dei costi e delle prestazioni sono possibili con le raccomandazioni di Azure Advisor e la configurazione della scalabilità automatica.

Configurazioni di ripristino di emergenza

Questa sezione descrive in dettaglio più configurazioni di ripristino di emergenza a seconda dei requisiti di resilienza (RPO e RTO), delle operazioni necessarie e dei costi.

L'obiettivo del tempo di ripristino (RTO) si riferisce al tempo necessario per il ripristino da un'interruzione. Ad esempio, L'obiettivo RTO di 2 ore indica che l'applicazione deve essere operativa entro due ore da un'interruzione. L'obiettivo del punto di ripristino (RPO) si riferisce all'intervallo di tempo che può trascorrere durante un'interruzione prima che la quantità di dati persi durante tale periodo sia maggiore della soglia consentita. Ad esempio, se l'RPO è di 24 ore e un'applicazione ha dati che iniziano da 15 anni fa, sono ancora all'interno dei parametri dell'RPO concordato.

I processi di inserimento, elaborazione e cura hanno bisogno di progettare diligentemente in anticipo durante la pianificazione del ripristino di emergenza. L'inserimento fa riferimento ai dati integrati in Azure Esplora dati da varie origini; l'elaborazione si riferisce a trasformazioni e attività simili; la cura si riferisce a viste materializzate, esportazioni nel data lake e così via.

Di seguito sono riportate le configurazioni di ripristino di emergenza più diffuse e ognuna è descritta in dettaglio di seguito.

• Configurazione di Active-Active-Active (always-on)
• Configurazione attiva-attiva
• Configurazione di Active-Hot Standby
• Configurazione del cluster di ripristino dei dati su richiesta

Configurazione active-active-active

Questa configurazione è detta anche "always-on". Per le distribuzioni di applicazioni critiche senza tolleranza per le interruzioni, è consigliabile usare più cluster di Azure Esplora dati tra aree abbinate di Azure. Configurare l'inserimento, l'elaborazione e la cura in parallelo a tutti i cluster. Lo SKU del cluster deve essere lo stesso in tutte le aree. Azure garantisce che gli aggiornamenti vengano distribuiti e sfalsati tra aree abbinate di Azure. Un'interruzione dell'area di Azure non causerà un'interruzione dell'applicazione. È possibile che si verifichi una latenza o una riduzione delle prestazioni.

Configurazione attiva-attiva

Questa configurazione è identica alla configurazione active-active-active-active, ma include solo due aree abbinate di Azure. Configurare l'inserimento, l'elaborazione e la cura duali. Gli utenti vengono indirizzati all'area più vicina. Lo SKU del cluster deve essere lo stesso in tutte le aree.

Configurazione di Active-Hot Standby

La configurazione Active-Hot è simile alla configurazione Active-Active in doppia inserimento, elaborazione e cura. Mentre il cluster standby è online per l'inserimento, il processo e la cura, non è disponibile per la query. Il cluster di standby non deve trovarsi nello stesso SKU del cluster primario. Può essere di uno SKU e una scalabilità più piccoli, il che può comportare una riduzione delle prestazioni. In uno scenario di emergenza, gli utenti vengono reindirizzati al cluster di standby, che facoltativamente può essere ridimensionato per aumentare le prestazioni.

Configurazione del ripristino dei dati su richiesta

Questa soluzione offre la resilienza minima (RPO e RTO più elevata), è il costo più basso e il massimo sforzo. In questa configurazione non è presente alcun cluster di ripristino dei dati. Configurare l'esportazione continua di dati curati (a meno che non siano necessari anche dati non elaborati e intermedi) in un account di archiviazione configurato con ridondanza geografica (archiviazione con ridondanza geografica). Se si verifica uno scenario di ripristino di emergenza, viene avviato un cluster di ripristino di dati. In quel momento, vengono applicati DDLS, configurazione, criteri e processi. I dati vengono inseriti dall'archiviazione con la proprietà di inserimento kustoCreationTime per superare il tempo di inserimento predefinito per l'ora di sistema.

Riepilogo delle opzioni di configurazione del ripristino di emergenza

Procedure consigliate

Indipendentemente dalla configurazione del ripristino di emergenza scelta, seguire queste procedure consigliate:

• Tutti gli oggetti di database, i criteri e le configurazioni devono essere mantenuti nel controllo del codice sorgente in modo che possano essere rilasciati al cluster dallo strumento di automazione delle versioni. Per altre informazioni, vedere Supporto di Azure DevOps per Azure Esplora dati.
• Progettare, sviluppare e implementare routine di convalida per garantire che tutti i cluster siano sincronizzati dal punto di vista dei dati. Azure Esplora dati supporta join tra cluster. Un conteggio semplice o righe tra tabelle può essere utile per la convalida.
• Le procedure di rilascio devono includere controlli e saldi di governance che garantiscono il mirroring dei cluster.
• Essere pienamente consapevoli di ciò che serve per creare un cluster da zero.
• Creare un elenco di controllo delle unità di distribuzione. L'elenco sarà univoco per le proprie esigenze, ma deve includere: script di distribuzione, connessioni di inserimento, strumenti di business intelligence e altre configurazioni importanti.

Passaggio successivo