Disponibilità tramite ridondanza locale e della zona - Istanza gestita di SQL di Azure

Si applica a: Istanza gestita di SQL di Azure SQL

Questo articolo descrive l'architettura dell’istanza gestita di SQL di Azure che ottiene la disponibilità tramite ridondanza locale e disponibilità elevata tramite ridondanza della zona.

Panoramica

Istanza gestita di SQL viene eseguito nella versione stabile più recente del motore di database di SQL Server nel sistema operativo Windows con tutte le patch applicabili. L’istanza gestita di SQL gestisce automaticamente le attività di manutenzione critiche, quali l'applicazione di patch, i backup, gli aggiornamenti del motore di database Windows e SQL e gli eventi non pianificati come errori di hardware, software o rete sottostanti. Quando a un'istanza viene applicata una patch o quando ne viene effettuato il failover, il tempo di inattività non ha un vero impatto se si usa la logica di ripetizione dei tentativi nell'app. Istanza gestita di SQL può effettuare rapidamente il recupero, anche nei casi più critici, garantendo che i dati siano sempre disponibili. La maggior parte degli utenti non nota che gli aggiornamenti vengono eseguiti continuamente.

Per impostazione predefinita, Istanza gestita di SQL di Azure ottiene la disponibilità tramite ridondanza locale, rendendo disponibile l'istanza durante:

• Operazioni di gestione avviate dal cliente che comportano un breve tempo di inattività
• Operazioni di manutenzione del servizio
• Problemi e interruzioni del data center con:
  • Rack in cui sono in esecuzione i computer che alimentano il servizio.
  • Computer fisico che ospita la macchina virtuale che esegue il motore di database SQL.
  • Macchina virtuale che esegue il motore di database SQL
• Altri problemi relativi al motore di database SQL
• Altre potenziali interruzioni locali non pianificate

La soluzione a disponibilità predefinita è progettata per garantire che i dati di cui è stato eseguito il commit non vadano mai persi a causa di errori, che le operazioni di manutenzione non influiscano sul carico di lavoro e che l’istanza non sia un singolo punto di guasto nell'architettura del software.

Tuttavia, per ridurre al minimo l'impatto sui dati in caso di interruzione di un'intera zona, è possibile ottenere una disponibilità elevata abilitando la ridondanza della zona. Senza ridondanza della zona, i failover vengono eseguiti localmente all'interno dello stesso data center, il che potrebbe causare l'indisponibilità dell'istanza fino alla risoluzione dell'interruzione. L'unico modo per eseguire il ripristino è tramite una soluzione di ripristino di emergenza, ad esempio tramite un gruppo di failover o un ripristino geografico di un backup con ridondanza geografica. Per ulteriori informazioni, si veda Panoramica sulla continuità aziendale.

La disponibilità elevata aumenta l'affidabilità del servizio proteggendo l'utente dall'impatto sui seguenti elementi:

• Zona di disponibilità che costituisce il data center

Esistono due diversi modelli di architettura della disponibilità basati sul livello di servizio:

• Il modello di archiviazione remota si basa su una separazione tra calcolo e archiviazione nel livelli di servizio Utilizzo generico e Utilizzo generico di nuova generazione che si basano sulla disponibilità e sull'affidabilità dell'archiviazione remota e sulla disponibilità dei cluster di calcolo gestiti da Azure Service Fabric. Il modello della disponibilità è destinato alle applicazioni aziendali orientate al budget che possono tollerare una riduzione del livello delle prestazioni durante le attività di manutenzione.
• Il modello di archiviazione locale si basa su un cluster di processi del motore di database che si basano su un quorum di nodi del motore di database disponibili nel livello di servizio Business Critical con archiviazione locale. Questo modello di archiviazione locale è destinato a applicazioni cruciali che hanno una frequenza di transazioni elevata e richiedono prestazioni di I/O elevate. L'architettura a disponibilità elevata garantisce un impatto minimo sulle prestazioni del carico di lavoro durante le attività di manutenzione.

Per altre informazioni sui contratti di servizio specifici per diversi livelli di servizio, si veda Istanza gestita di SQL di Azure.

Disponibilità tramite ridondanza locale

La disponibilità con ridondanza locale si basa sull'archiviazione dei nodi di calcolo e dei dati all'interno di un singolo data center nell'area primaria e protegge i dati in caso di errore locale, ad esempio una rete su scala ridotta o un'interruzione dell'alimentazione. Se si verifica un'emergenza su larga scala, ad esempio incendi o inondazioni all'interno di un'area, tutte le repliche di un account di archiviazione o i dati nei nodi di calcolo potrebbero essere perse o irreversibili. Di conseguenza, per proteggere ulteriormente i dati quando si usa l'opzione di disponibilità con ridondanza locale, è consigliabile usare un'opzione di archiviazione più resiliente per i backup del database.

Livello di servizio Utilizzo generico

Il livello di servizio per Utilizzo generico usa l'architettura di disponibilità dell'archiviazione remota. La figura seguente mostra quattro nodi diversi con i livelli di calcolo e archiviazione separati.

Il modello di disponibilità dell'archiviazione remota include due livelli:

• Un livello di calcolo senza stato che esegue il processo del motore di database e contiene solo dati temporanei e memorizzati nella cache, come ad esempio i database tempdb e model nell'unità SSD collegata e la cache dei piani, il pool di buffer e il pool columnstore in memoria. Il nodo di SQL Server senza stato è gestito da Azure Service Fabric che inizializza il motore di database, controlla l'integrità del nodo e, se necessario, esegue il failover in un'altra posizione.
• Un livello di dati con stato con i file di database (.mdf and .ldf) archiviati in Archiviazione BLOB di Azure. Archiviazione BLOB di Azure include funzionalità predefinite di disponibilità e ridondanza dei dati. La disponibilità con ridondanza locale si basa sull'archiviazione dei dati nell'archiviazione con ridondanza locale (LRS) che copia i dati tre volte all'interno di un singolo data center nell'area primaria. Garantisce che ogni record nel file di log o nella pagina del file di dati venga mantenuto anche se il processo del motore di database si arresta in modo anomalo.

Ogni volta che viene aggiornato il motore di database o il sistema operativo oppure viene rilevato un errore, Service Fabric di Azure sposta il processo del motore di database senza stato in un altro nodo di calcolo senza stato con capacità libera sufficiente. I dati presenti in Archiviazione BLOB di Azure non vengono interessati dallo spostamento e i dati e i file di log vengono associati al processo di motore di database appena inizializzato. Questo processo garantisce la disponibilità elevata, ma un carico di lavoro elevato potrebbe riscontrare una riduzione delle prestazioni durante la transizione perché il nuovo processo del motore di database inizia con la cache a freddo.

Livello di servizio Utilizzo generico di nuova generazione

Lo scopo dell'Utilizzo generico di nuova generazione è un aggiornamento dell'architettura al livello di servizio Utilizzo generico esistente che usa un livello di archiviazione remota aggiornato che archivia i dati dell'istanza e i file di resoconto su dischi gestiti anziché i BLOB di pagine e li mantiene localmente.

Livello di servizio Business Critical

Il livello di servizio Business Critical usa il modello di disponibilità dell'archiviazione locale, che integra le risorse di calcolo (processo del motore di database) e l'archiviazione (unità SSD collegata localmente) in un singolo nodo. La disponibilità elevata viene ottenuta replicando sia il calcolo che l'archiviazione in nodi aggiuntivi.

I file di database sottostanti (.mdf/.ldf) vengono inseriti nell'unità di archiviazione SSD collegata per offrire operazioni di I/O a bassa latenza per il carico di lavoro. La disponibilità elevata è implementata mediante una tecnologia simile a Gruppi di disponibilità Always On di SQL Server. Il cluster include una singola replica primaria accessibile per i carichi di lavoro dei clienti in lettura/scrittura e fino a tre repliche secondarie (calcolo e archiviazione) che contengono copie di dati. La replica primaria esegue costantemente il push delle modifiche alle repliche secondarie in modo sequenziale per garantire che i dati vengano mantenuti in un numero sufficiente di repliche secondarie prima di eseguire il commit di ogni transazione. Questo processo garantisce che, se la replica primaria o una replica secondaria leggibile non è più disponibile per qualsiasi motivo, una replica completamente sincronizzata è sempre disponibile per effettuare il failover. Il failover viene avviato da Azure Service Fabric. Quando una replica secondaria diventa la nuova replica primaria, viene creata un'altra replica secondaria per garantire che il cluster disponga di un numero sufficiente di repliche per mantenere il quorum. Al termine del failover, le connessioni SQL di Azure vengono reindirizzate automaticamente alla nuova replica primaria (o alla replica secondaria leggibile in base al stringa di connessione).

Come vantaggio aggiuntivo, il modello di disponibilità dell'archiviazione locale include la possibilità di reindirizzare le connessioni Azure SQL di sola lettura a una delle repliche secondarie. Questa funzionalità è denominata Scalabilità in lettura. Offre una capacità di calcolo aggiuntiva del 100% senza costi aggiuntivi per le operazioni di sola lettura, ad esempio i carichi di lavoro analitici, dalla replica primaria.

Disponibilità elevata tramite ridondanza della zona

La disponibilità con ridondanza della zona si basa sull'inserimento di repliche in tre zone di disponibilità di Azure nell'area primaria. Ogni zona di disponibilità è una posizione fisica separata con alimentazione, raffreddamento e rete indipendenti.

Per impostazione predefinita, il cluster di nodi per il modello di disponibilità di archiviazione locale viene creato nello stesso data center. Grazie all'introduzione di Zone di disponibilità di Azure, l’istanza gestita di SQL posiziona diverse repliche in zone di disponibilità diverse nella stessa area. Per eliminare un singolo punto di guasto, viene duplicato anche l'anello di controllo in più zone. Il traffico del piano di controllo viene quindi instradato a un servizio di bilanciamento del carico implementato anche tra le zone di disponibilità. Il routing del traffico dal piano di controllo al servizio di bilanciamento del carico è controllato da Gestione traffico di Azure (ATM).

Se si utilizza una configurazione con ridondanza della zona, è possibile le istanze business critical o per utilizzo generico resilienti a un set molto più ampio di errori, incluse interruzioni irreversibili del data center, senza modifiche della logica dell'applicazione. È possibile convertire qualsiasi istanza business critical alla configurazione con ridondanza della zona.

Poiché le istanze con ridondanza della zona dispongono di repliche in diversi data center distanti tra loro, la maggiore latenza di rete può aumentare il tempo di commit della transazione e pertanto compromettere le prestazioni di alcuni carichi di lavoro OLTP. È sempre possibile tornare alla configurazione a singola zona disabilitando l'impostazione di ridondanza della zona. Questo processo è un'operazione online simile al normale aggiornamento dell’obiettivo del livello di servizio. Al termine del processo, viene eseguita la migrazione dell’istanza da un anello con ridondanza della zona a un anello a singola zona o viceversa.

Per iniziare a usare la ridondanza della zona per l'istanza gestita di SQL, vedere Configurare la ridondanza della zona.

Livello di servizio Utilizzo generico

Nel livello di servizio Utilizzo generico, la ridondanza della zona viene ottenuta inserendo nodi di calcolo senza stato in zone di disponibilità diverse e quindi si basa su un'archiviazione con ridondanza della zona (ZRS) con stato collegata al nodo che attualmente contiene il processo attivo del motore di database SQL. In caso di interruzione, il processo del motore di database SQL diventa attivo in uno dei nodi senza stato, che accede quindi ai dati nella risorsa di archiviazione con stato.

Il seguente diagramma mostra l'architettura di ridondanza della zona per il livello di servizio Utilizzo generico:

Livello di servizio Business Critical

Nel livello di servizio Business Critical la ridondanza della zona viene ottenuta inserendo repliche di calcolo e archiviazione in zone di disponibilità diverse e quindi usando la tecnologia del gruppo di disponibilità Always On sottostante per replicare le modifiche dei dati dall'istanza primaria alle repliche di standby in altre zone di disponibilità. In caso di interruzione, è presente un failover automatico che passa facilmente una delle repliche di standby come primaria.

Il seguente diagramma mostra l'architettura di ridondanza della zona per il livello di servizio Business Critical:

Testare la resilienza degli errori dell'applicazione

La disponibilità è una parte fondamentale della piattaforma Istanza gestita di SQL che funziona in modo trasparente per le applicazioni di database. Tuttavia, è possibile che si desideri testare il modo in cui le operazioni di failover automatico avviate durante gli eventi pianificati o non pianificati influiranno su un'applicazione prima di distribuirla nella produzione. È possibile attivare manualmente un failover chiamando un'API speciale per riavviare un'istanza gestita. Poiché l'operazione di riavvio è intrusiva e un numero elevato di essi potrebbe stressare la piattaforma, è consentita una sola chiamata di failover ogni 15 minuti per ogni istanza gestita.

Durante un vero failover, le connessioni all'istanza hanno esito negativo mentre il servizio SQL diventa primario in un nodo diverso. Per simulare un failover, eseguire il comando che riavvia il processo SQL per simulare l'avvio del servizio come se fosse presente un failover. Tuttavia, le connessioni potrebbero non riuscire per un periodo più lungo durante un vero failover rispetto a un failover simulato, poiché durante un vero failover, il processo SQL diventa primario in un'altra macchina virtuale all'interno del cluster (localmente o in un'altra zona se la ridondanza della zona è abilitata) e durante un failover simulato il processo SQL viene riavviato nella macchina virtuale esistente.

Il comando di failover manuale in questa sezione di solito si comporta allo stesso modo nelle configurazioni con ridondanza locale e con ridondanza della zona, ma riavvia solo il processo SQL in locale e non avvia un failover in un altro nodo, anche se si applica qualche eccezione. Questo failover locale è diverso da un failover che si verifica per un gruppo di failover.

È possibile avviare un failover locale usando PowerShell, l'API REST o l'interfaccia della riga di comando di Azure:

Conclusione

Istanza gestita di SQL di Azure offre una soluzione a disponibilità elevata predefinita integrata con la piattaforma Azure. Il servizio dipende da Service Fabric per rilevare errori e ripristino, archiviazione BLOB di Azure per proteggere i dati e su zone di disponibilità per una maggiore tolleranza di errore. Per il livello di servizio Business Critical, Istanza gestita di SQL usa la tecnologia del gruppo di disponibilità Always On di SQL Server per la replica e il failover del database. La combinazione di queste tecnologie consente alle applicazioni di ottenere tutti i vantaggi di un modello di archiviazione mista e supportare i contratti di servizio più esigenti.

Passaggi successivi

• Abilitare la ridondanza della zona per Istanza gestita di SQL di Azure.
• Informazioni su Zone di disponibilità di Azure
• Informazioni su Service Fabric
• Altre informazioni su Gestione traffico di Azure
• Informazioni su come avviare un failover manuale in Istanza gestita di SQL
• Per altre opzioni relative a disponibilità elevata e ripristino di emergenza, vedere Panoramica della continuità aziendale del database SQL di Azure.