Disponibilità elevata per Istanza gestita di SQL di Azure

Si applica a:Istanza gestita di SQL di Azure

• Database SQL di Azure
• Istanza gestita di database SQL di Azure

Questo articolo descrive la disponibilità elevata in Istanza gestita di SQL di Azure.

Importante

La configurazione con ridondanza della zona è disponibile in anteprima pubblica per il livello di servizio Utilizzo generico e in generale per il livello di servizio Business Critical.

Panoramica

L'obiettivo dell'architettura a disponibilità elevata in Istanza gestita di SQL di Azure è ridurre al minimo l'impatto sui carichi di lavoro dei clienti dalle operazioni di gestione avviate dai clienti, con tempi di inattività brevi, operazioni di manutenzione del servizio e interruzioni non pianificate. Per altre informazioni sui contratti di servizio specifici per diversi livelli di servizio, vedere Istanza gestita di SQL di Azure.

La disponibilità elevata protegge l'utente da ripercussioni su:

• Zona di disponibilità che costituisce il data center (in caso di area multi-area)
• il rack in cui sono in esecuzione i nodi che alimentano il servizio
• il nodo stesso
• Livello applicazione

Per ridurre al minimo l'impatto in caso di interruzioni a livello di area o di interruzioni più grandi, è possibile usare una delle tecniche disponibili descritte nella panoramica della continuità aziendale.

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 di 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.

La soluzione a disponibilità elevata è 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.

Esistono due diversi modelli di architettura a disponibilità elevata 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à elevata e sull'affidabilità dell'archiviazione remota e sulla disponibilità elevata dei cluster di calcolo gestiti da Azure Service Fabric. Il modello a disponibilità elevata è 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.

Disponibilità con 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

Nota

L'aggiornamento del livello di servizio Utilizzo generico di nuova generazione è attualmente in anteprima.

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.

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à con ridondanza della zona

La disponibilità con ridondanza della zona si basa sull'inserimento di repliche di archiviazione e nodi di calcolo 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 può posizionare diverse repliche del database Business critical in zone di disponibilità diverse nella stessa area. Allo stesso modo, i nodi di calcolo senza stato di un livello di servizio per utilizzo generico vengono posizionati in una zona di disponibilità diversa, mentre l'archiviazione con stato usa la configurazione dell'archiviazione con ridondanza della zona (ZRS).

Per eliminare un singolo punto di guasto, viene duplicato anche l'anello di controllo in più zone come tre anelli gateway. Il routing a un anello gateway specifico è controllato da Gestione traffico di Azure. Se si seleziona 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. È anche 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.

La versione con ridondanza della zona dell'architettura a disponibilità elevata è illustrata nel diagramma seguente:

Quando si usa la ridondanza della zona, tenere presente quanto segue:

• La ridondanza della zona non è disponibile per il livello di servizio Utilizzo generico di nuova generazione.
• Per informazioni aggiornate sulle aree che supportano configurazioni con ridondanza della zona, vedere Supporto dei servizi in base all'area.
• Per la disponibilità con ridondanza della zona, la scelta di una finestra di manutenzione diversa da quella predefinita è attualmente disponibile nelle aree selezionate.

Aree supportate per le istanze business critical

La ridondanza della zona per i Istanza gestita di SQL business critical è supportata nelle aree seguenti:

Americhe	Europa	Medio Oriente	Africa	Asia Pacifico
Brasile meridionale	Francia centrale	Qatar centrale	Sudafrica settentrionale	Australia orientale
Canada centrale	Italia settentrionale	Israele centrale		India centrale
Stati Uniti centrali	Germania centro-occidentale			Giappone orientale
Stati Uniti orientali	Norvegia orientale			Corea centrale
Stati Uniti orientali 2	Europa settentrionale			Asia sud-orientale
Stati Uniti centro-meridionali	Regno Unito meridionale			Asia orientale
West US 2	Svezia centrale
Stati Uniti occidentali 3	Svizzera settentrionale
	Polonia Centrale

Aree supportate per le istanze per utilizzo generico

Nota

La configurazione con ridondanza della zona è in anteprima per il livello Utilizzo generico.

Americhe	Europa	Medio Oriente	Africa	Asia Pacifico
Brasile meridionale	Francia centrale	Qatar centrale	Sudafrica settentrionale	Australia orientale
Stati Uniti orientali	Italia settentrionale	Israele centrale		India centrale
Stati Uniti orientali 2	Germania centro-occidentale			Giappone orientale
Stati Uniti centro-meridionali	Norvegia orientale			Corea centrale
West US 2	Europa settentrionale			Asia sud-orientale
Stati Uniti occidentali 3	Regno Unito meridionale			Asia orientale
	Svezia centrale
	Svizzera settentrionale
	Polonia Centrale

Testare la resilienza degli errori dell'applicazione

La disponibilità elevata è 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. Nel caso di un'istanza con ridondanza della zona, la chiamata API comporta il reindirizzamento delle connessioni client al nuovo database primario in una zona di disponibilità diversa dalla zona di disponibilità del database primario precedente. Oltre a testare l'impatto del failover sulle sessioni di database esistenti, è anche possibile verificare se cambia le prestazioni end-to-end a causa di modifiche alla latenza di rete. 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.

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

PowerShell	API REST	Interfaccia della riga di comando di Azure
Invoke-AzSqlInstanceFailover	Istanze gestite di SQL: failover	È possibile utilizzare az sql mi failover per richiamare una chiamata API REST dall'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

• 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.