Disponibilità tramite ridondanza locale e di 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

L'istanza gestita di SQL viene eseguita sull'ultima versione stabile 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 raggiunge la disponibilità attraverso la ridondanza locale, garantendo che la tua istanza gestisca interruzioni quali:

  • 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 funzione le macchine che supportano 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 di disponibilità predefinita è progettata per garantire che i dati di cui è stato eseguito il commit non vengano mai persi a causa di errori, che le operazioni di manutenzione abbiano un impatto minimo sul carico di lavoro e che l'istanza non sia un singolo punto di errore nell'architettura 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 ulteriori informazioni sugli SLA specifici relativi ai diversi livelli di servizio, consulta SLA per 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 per 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.

Diagramma che mostra la separazione tra calcolo e archiviazione.

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 dati con stato, con i file del database (.mdf e .ldf) archiviati in Archiviazione BLOB di Azure. L'archiviazione BLOB di Azure dispone di funzionalità integrate per la disponibilità e la 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 per utilizzo generale di nuova generazione

La nuova generazione del livello di servizio Generale rappresenta un aggiornamento architettonico al livello di servizio esistente, che utilizza un livello di archiviazione remoto aggiornato. Questo archivia i dati dell'istanza e i file di log su Elastic SAN anziché sui BLOB di pagine e li conserva localmente.

La ridondanza della zona non è disponibile per l'aggiornamento del livello di servizio Generale di nuova generazione.

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à viene ottenuta replicando sia il calcolo che l'archiviazione in nodi aggiuntivi.

Diagramma di un cluster di nodi del motore di database.

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à viene implementata usando una tecnologia simile ai gruppi di disponibilità AlwaysOn 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 Read Scale-Out. Fornisce un'ulteriore capacità di calcolo del 100% senza costi aggiuntivi per scaricare dalla replica primaria le operazioni di sola lettura, ad esempio i carichi di lavoro analitici.

Alta disponibilità tramite ridondanza tra zone

La disponibilità con ridondanza di zona si basa sulla distribuzione delle repliche tra tre zone di disponibilità di Azure nell'area geografica 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à dell'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 bilanciatore del carico distribuito anch'esso su più zone di disponibilità. L'instradamento del traffico dal piano di controllo al bilanciatore del carico è gestito da Gestione traffico di Azure (ATM).

Utilizzando una configurazione con ridondanza della zona, è possibile rendere resilienti le istanze Business Critical o General Purpose a una gamma molto più ampia di guasti, inclusi guasti catastrofici del data center, senza apportare alcuna modifica alla logica dell'applicazione. È possibile convertire qualsiasi istanza esistente Business Critical o General Purpose in una configurazione con ridondanza della zona. La ridondanza della zona non è disponibile per il livello di servizio Per utilizzo generico di nuova generazione.

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. Esaminare la disponibilità della zona di ridondanza per regione per Istanza gestita di SQL di Azure.

Livello di servizio per utilizzo generico

Nel livello di servizio General Purpose, la ridondanza di zona viene ottenuta distribuendo nodi di calcolo senza stato in zone di disponibilità diverse e si basa quindi su un'archiviazione con stato con ridondanza di zona (ZRS) collegata al nodo che attualmente contiene il processo attivo del motore di SQL Database. 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:

Diagramma dell'architettura con ridondanza della zona nel livello di servizio per 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 guasto, si attiva un failover automatico che promuove senza interruzioni una delle repliche di standby a replica primaria.

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

Diagramma dell'architettura di ridondanza della zona nel 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 si comporta in genere allo stesso modo sia nelle configurazioni con ridondanza locale che in quelle con ridondanza della zona, ma riavvia solo il processo SQL in locale e non avvia un failover in un altro nodo, anche se si applicano alcune eccezioni. Questo failover locale è diverso dal failover che si verifica in un gruppo di failover.

È possibile avviare un failover locale 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 Istanza gestita di SQL - Failover È possibile utilizzare az sql mi failover per richiamare una chiamata API REST dall'interfaccia della riga di comando di Azure

Test di connettività interni automatici

Per garantire la disponibilità del servizio, Istanza gestita di SQL di Azure esegue test di connettività interni automatici per monitorare l'affidabilità del servizio e accelerare il rilevamento dei problemi. Questi test vengono eseguiti ogni 10 secondi dagli indirizzi IP interni all'interno della subnet dell'istanza gestita di SQL e hanno un impatto trascurabile sulle prestazioni della velocità effettiva e del servizio di rete. Un test verifica la connettività end-to-end tentando un accesso con credenziali note come destinate a non andare a buon fine (AzureSQLConnectivityChecker), che genera le previste voci di accesso non riuscito nei log di audit, in Extended Events e nei log degli errori SQL. Queste voci sono normali e non indicano un problema di sicurezza. Per altre informazioni, tra cui come identificare le firme di test nei log, vedere Test di connettività interni automatici.

Conclusione

Istanza gestita di Azure SQL offre una soluzione ad alta disponibilità integrata, strettamente integrata nella piattaforma Azure. Il servizio dipende da Service Fabric per rilevare gli errori e garantire il ripristino, dall'Archiviazione BLOB di Azure per proteggere i dati e dalle zone di disponibilità per una maggiore tolleranza agli errori. E per il livello di servizio Business Critical, Istanza gestita di SQL usa la tecnologia dei gruppi di disponibilità Always On di SQL Server per la replica e il failover dei 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.

Contenuti correlati

  • Last updated on