Altre opzioni di disponibilità
Il database SQL di Azure e Istanza gestita di SQL di Azure offrono, per impostazione predefinita, straordinarie opzioni di disponibilità nei diversi livelli di servizio. Ci sono alcune opzioni aggiuntive che consentono di aumentare o modificare la disponibilità dei database o delle istanze. L'impatto sarà visibile direttamente sul contratto di servizio. In questa unità verrà illustrato come è possibile usare altre opzioni per la disponibilità in Azure SQL.
Zone di disponibilità
Nel livello business critical del database SQL di Azure è possibile acconsentire esplicitamente, senza alcun costo aggiuntivo, a una configurazione con ridondanza della zona, se l'area la supporta. A livello generale, il gruppo di disponibilità Always On in esecuzione in background per i database e le istanze gestite del livello business critical viene distribuito in tre diverse zone di disponibilità all'interno di un'area. Una zona di disponibilità è fondamentalmente un data center separato all'interno di una determinata area. Le zone di disponibilità sono sempre separate fisicamente. Ciò protegge da errori irreversibili che possono verificarsi in un data center in un'area.
Dal punto di vista delle prestazioni, è possibile che si verifichi un piccolo aumento della latenza di rete, perché il gruppo di disponibilità è ora distribuito tra data center a una certa distanza tra loro. Per questo motivo, le zone di disponibilità non sono attivate per impostazione predefinita. È possibile scegliere di usare una distribuzione con zone di disponibilità multiple o con una singola zona di disponibilità. Per configurare questa opzione, è sufficiente aggiungere un parametro a un comando di PowerShell o dell'interfaccia della riga di comando di Azure oppure selezionare una casella nel portale di Azure.
Le zone di disponibilità sono un concetto relativamente nuovo in Azure SQL, quindi al momento sono disponibili solo in determinate aree e per livelli di servizio specifici. Col tempo, questa capacità verrà supportata in più aree e probabilmente in più livelli di servizio. Di recente, ad esempio, il livello per utilizzo generico relativo al database SQL di Azure ha rilasciato un'anteprima per la distribuzione multi-az.
Contratto di servizio di Azure SQL
Azure SQL offre un contratto di servizio con copertura finanziaria per l'impegno al raggiungimento e al mantenimento dei livelli di servizio. Se il livello di servizio descritto nel contratto di servizio non viene raggiunto o mantenuto, l'utente avrà diritto a un credito per una parte delle tariffe per il servizio mensili.
Attualmente, è possibile ottenere la disponibilità più elevata (99,995%) da una distribuzione business critical del database SQL di Azure con le zone di disponibilità configurate. Il livello business critical è l'unica opzione nel settore che offre contratti di servizio per l'obiettivo del punto di ripristino e l'obiettivo del tempo di ripristino da 5 a 30 secondi rispettivamente.
- L'obiettivo del punto di ripristino, o RPO (Recovery Point Object), rappresenta la quantità di dati che si è disposti a perdere nello scenario peggiore.
- L'obiettivo del tempo di ripristino, o RTO (Recovery TIME Object), rappresenta il tempo necessario per ripristinare il funzionamento in caso di emergenza.
Per le distribuzioni business critical per utilizzo generico o singola zona di Database SQL di Azure o Istanza gestita di SQL di Azure, il contratto di servizio è 99,99%.
Il contratto di servizio del livello Hyperscale dipende dal numero di repliche. Tenere presente che nel livello Hyperscale è possibile scegliere il numero di repliche disponibili. Se non è presente alcuna replica, il comportamento del failover sarà più simile a quello del livello per utilizzo generico. Se sono presenti repliche, il comportamento del failover sarà più simile a quello del livello business critical. Ecco i contratti di servizio, in base al numero di repliche:
- 0 repliche: 99,5%
- 1 replica: 99,9%
- 2 o più repliche: 99,99%
Replica geografica e gruppi di failover automatici
Dopo aver scelto un livello di servizio e, dove applicabile, le zone di disponibilità, ci sono altre opzioni per ottenere la scalabilità in lettura o la possibilità di eseguire il failover in un'altra area: la replica geografica e i gruppi di failover automatico. Nell'istanza locale di SQL Server la configurazione di queste opzioni è un'operazione che richiede una pianificazione approfondita, un coordinamento ottimale e molto tempo.
Con il cloud, e in particolare con Azure SQL, questo processo viene semplificato. Sia per la replica geografica che per i gruppi di failover automatico è possibile eseguire la configurazione con pochi clic nel portale di Azure o con pochi comandi di PowerShell o dell'interfaccia della riga di comando di Azure.
Ecco alcune considerazioni utili per decidere se per lo scenario specifico è preferibile usare la replica geografica o i gruppi di failover automatico:
| Funzionalità | Replica geografica | Gruppi di failover |
|---|---|---|
| Failover automatico | No | Sì |
| Failover di più database contemporaneamente | No | Sì |
| L'utente deve aggiornare la stringa di connessione dopo il failover | Sì | No |
| Supporto per Istanza gestita di SQL | No | Sì |
| Può trovarsi nella stessa area della replica primaria | Sì | No |
| Più repliche | Sì | No |
| Supporta la scalabilità in lettura | Sì | Sì |