Continuità aziendale e ripristino di emergenza per le Istanza gestita di SQL abilitate per Azure Arc

Le Istanza gestita di SQL abilitate per Azure Arc offrono funzionalità per la continuità aziendale e il ripristino di emergenza (BCDR) che consentono alle aziende di eseguire il ripristino da interruzioni e continuare a funzionare con tempi di inattività minimi.

Questo articolo fornisce considerazioni di progettazione e consigli chiave per la configurazione e la gestione delle funzionalità di continuità aziendale, ad esempio ripristino temporizzato, disponibilità elevata e ripristino di emergenza.

Architettura

I diagrammi di architettura seguenti illustrano le funzionalità a disponibilità elevata del Istanza gestita di SQL abilitato per Arc nel livello di servizio Business Critical, che supporta il failover con tempi di inattività quasi zero. Se l'istanza primaria ha esito negativo, il servizio di bilanciamento del carico interrompe l'invio del traffico a tale istanza. Una delle istanze secondarie viene quindi promossa a primaria e l'istanza appena promossa inizia a ricevere traffico di lettura/scrittura dal servizio di bilanciamento del carico. Dopo che l'istanza non riuscita torna online, viene aggiunta come istanza secondaria.

Il diagramma dell'architettura seguente illustra come è possibile distribuire Istanza gestita di SQL con abilitazione di Arc in due cluster Kubernetes separati in due siti diversi per il ripristino di emergenza.

Il diagramma dell'architettura seguente mostra in che modo l'Istanza gestita di SQL abilitata per Arc risponde quando viene avviato un failover di ripristino di emergenza.

Considerazioni relative alla progettazione

Per valutare l'effetto delle Istanza gestita di SQL abilitate per Azure Arc nel modello BCDR complessivo, esaminare le raccomandazioni BCDR per le zone di destinazione in Continuità aziendale e ripristino di emergenza. Si noti che l'obiettivo della continuità aziendale e del ripristino di emergenza riguarda solo le raccomandazioni di progettazione per la continuità aziendale, ma la disponibilità elevata e la resilienza dell'istanza dipendono anche dalla disponibilità dell'infrastruttura Kubernetes sottostante.

Ripristino temporizzato

• Definire le destinazioni per l'obiettivo del punto di ripristino (RPO) e l'obiettivo del tempo di ripristino (RTO).

• Determinare per quanto tempo si desidera conservare e ripristinare i backup entro i limiti di conservazione supportati.

• Prendere in considerazione le implicazioni per l'archiviazione e il costo dell'aumento del periodo di conservazione dei backup. La conservazione predefinita è sette giorni. Con questa durata, è possibile eseguire il ripristino per un massimo di sette giorni e si ottiene un backup completo, un differenziale giornaliero e i backup dei log transazionali ogni cinque minuti.

• Considerare la classe di archiviazione da usare per il volume permanente per i backup. Per indicazioni, vedere Discipline di archiviazione per le Istanza gestita di SQL abilitate per Azure Arc.

• Prendere in considerazione le dimensioni del volume permanente per i backup nel contesto delle dimensioni dei dati previste e del periodo di conservazione configurato.

• Per le procedure consigliate per l'archiviazione, vedere Le discipline di archiviazione per le Istanza gestita di SQL abilitate per Azure Arc.

• I backup vengono sempre eseguiti nella replica primaria. Prendere in considerazione gli effetti sulle prestazioni dei processi di backup e ripristino durante l'identificazione delle risorse allocate all'istanza.

• Tenere presente che i ripristini temporizzato di un database non possono sovrascrivere un database esistente. Tuttavia, possono ripristinare i dati in un nuovo database nella stessa istanza.

• Prendere in considerazione i passaggi aggiuntivi necessari per ripristinare completamente il database se l'applicazione è online durante il processo di ripristino.

• Prendere in considerazione i passaggi aggiuntivi necessari per ripristinare un database in un'istanza con più repliche, come descritto in Ripristino di un database in un'istanza con più repliche.

• Determinare gli strumenti usati dagli amministratori di database per configurare e ripristinare i backup. Per altre informazioni, vedere Connettersi alle Istanza gestita di SQL abilitate per Azure Arc.

Disponibilità elevata

• Esaminare i requisiti di disponibilità del carico di lavoro e decidere il livello di servizio più adatto per la distribuzione di Istanza gestita di SQL con abilitazione di Arc:

  • Nel livello di servizio Per utilizzo generico è disponibile una singola replica e la disponibilità elevata viene ottenuta tramite l'orchestrazione kubernetes.
  • Nel livello di servizio Business Critical, l'Istanza gestita di SQL abilitata per Azure Arc fornisce un gruppo di disponibilità indipendente, oltre a ciò che viene fornito in modo nativo dall'orchestrazione kubernetes.

• Prendere in considerazione i potenziali effetti aziendali del tempo di inattività nel livello di servizio per utilizzo generico che potrebbe causare l'esistenza di una sola replica.

• Considerare il numero di repliche da uno a tre per la distribuzione nel livello di servizio Business Critical.

• Quando si distribuisce un'istanza in un livello di servizio Business Critical con due o più repliche, è possibile configurare le repliche secondarie come leggibili. Decidere il numero di repliche secondarie da distribuire nel livello di servizio Business Critical. Per informazioni sulla modifica del numero, vedere Configurare repliche secondarie leggibili.

• Stabilire la priorità della coerenza rispetto alla disponibilità tramite il numero di repliche secondarie necessarie per eseguire il commit di una transazione nel livello di servizio Business Critical usando il parametro facoltativo --sync-secondary-to-commit. In caso di problemi di connettività tra le repliche, il database primario potrebbe non eseguire il commit di alcuna transazione:

  • In una configurazione a due repliche, è necessario eseguire il commit di una transazione in entrambe le repliche affinché il database primario riceva un messaggio di esito positivo.
  • In una configurazione di tre repliche, almeno due delle tre repliche devono eseguire il commit di una transazione per restituire un messaggio di operazione riuscita.

• Decidere se è necessario designare una replica specifica come primaria. Per informazioni sulla specifica di una replica primaria, vedere Replica primaria preferita.

• Decidere quale tipo di servizio Kubernetes si userà, LoadBalancer o NodePort. Se si usa il servizio di bilanciamento del carico, le applicazioni possono riconnettersi allo stesso endpoint primario e Kubernetes reindirizzerà la connessione al nuovo database primario. Se si usa la porta del nodo, le applicazioni devono riconnettersi al nuovo indirizzo IP.

Ripristino di emergenza

• Le istanze di Istanza gestita di SQL abilitate per Azure Arc in entrambi i siti geografici primari e secondari geografici devono essere identiche nel calcolo e nella capacità, nonché distribuite negli stessi livelli di servizio.

• Decidere in un percorso in cui archiviare i certificati di mirroring quando si crea la configurazione di ripristino di emergenza accessibile da entrambi i cluster che ospitano l'istanza.

• Si consideri come monitorare il tempo di inattività dell'istanza primaria per decidere quando eseguire un failover nell'istanza secondaria.

• Ogni istanza ha endpoint propri. Valutare il modo in cui le applicazioni accederanno all'endpoint primario con interruzioni minime in caso di failover.

Suggerimenti per la progettazione

Le sezioni seguenti elencano le raccomandazioni di progettazione per il ripristino temporizzato, la disponibilità elevata e il ripristino di emergenza.

Ripristino temporizzato

• Quando si distribuisce una nuova istanza di Istanza gestita di SQL abilitata per Arc, definire sempre la classe di archiviazione per i backup per evitare di usare per impostazione predefinita la classe di archiviazione dei dati.

• Usare una classe di archiviazione che supporta ReadWriteMany (RWX) per il volume di backup. Per indicazioni, vedere Le discipline di archiviazione per le Istanza gestita di SQL abilitate per Azure Arc.

• Prima di avviare un'operazione di ripristino, usare il parametro facoltativo --dry-run per verificare se l'operazione ha esito positivo. Per altre informazioni, vedere Creare un database da un punto in tempo usando l'interfaccia della riga di comando az.

• Creare un processo per inviare backup che richiedono periodi di conservazione più lunghi ad Azure o ad altre risorse di archiviazione ad accesso sporadico locale.

• Monitorare lo spazio di archiviazione utilizzato dai backup per determinare se è possibile gestire una conservazione più lunga, se necessario.

Disponibilità elevata

• Eseguire esercitazioni regolari per convalidare la disponibilità elevata dell'istanza di Istanza gestita di SQL abilitata per Arc. Esempi di esercitazioni includono l'eliminazione di un pod in un'istanza per utilizzo generico e l'errore di una replica in un'istanza business critical.

• Nel livello Business Critical distribuire un'istanza in una configurazione a tre repliche anziché una configurazione a due repliche per ottenere una perdita di dati quasi zero.

• Per una migliore disponibilità, usare LoadBalancer come tipo di servizio durante la distribuzione di un'istanza.

• Esaminare le limitazioni di disponibilità elevata delle Istanza gestita di SQL abilitate per Azure Arc.

• Esaminare le modalità di disponibilità supportate per decidere quale modalità usare in base alle esigenze di disponibilità elevata.

• Quando si distribuisce un'istanza business critical con più repliche, usare una delle repliche secondarie per i carichi di lavoro di lettura. L'applicazione stringa di connessione deve specificare l'endpoint secondario come listener del servizio per il reindirizzamento alle repliche secondarie. Per informazioni sugli endpoint, vedere Ottenere gli endpoint primari e secondari e lo stato del gruppo di disponibilità.

• Per comprendere le procedure consigliate per il monitoraggio della disponibilità delle istanze, vedere Gestione e monitoraggio per le Istanza gestita di SQL abilitate per Azure Arc.

Ripristino di emergenza

• Assicurarsi che le istanze di Arc abilitato Istanza gestita di SQL abbiano nomi diversi per i siti primari e secondari e che il valore di nome condiviso per i siti sia identico.

• Eseguire esercitazioni regolari sul ripristino di emergenza per convalidare il processo di failover.

• Creare un processo per avviare failover manuali e forzati.

• Per comprendere le procedure consigliate per monitorare l'integrità dei cluster e per comprendere quando è necessario un failover, vedere Gestione e monitoraggio per le Istanza gestita di SQL abilitate per Azure Arc.

• Definire il record DNS per il nome condiviso del gruppo di disponibilità distribuito nei server DNS per evitare di dover creare manualmente record DNS durante il failover.

Passaggi successivi

Per altre informazioni sul percorso cloud ibrido e multicloud, vedere gli articoli seguenti:

• Che cosa sono i servizi dati abilitati per Azure Arc?
• Panoramica: Continuità aziendale Istanza gestita di SQL abilitata per Azure Arc
• Convalida kubernetes dei servizi dati abilitati per Azure Arc
• Gestire il portfolio tra operazioni ibride e multicloud
• Servizi dati abilitati per Azure Arc per scenari automatizzati con Jumpstart di Azure Arc
• Portare l'innovazione di Azure agli ambienti ibridi con Azure Arc, un percorso di apprendimento di Microsoft Learn