Esporta (0) Stampa
Espandi tutto

Disponibilità elevata e ripristino di emergenza di SQL Server in Macchine virtuali di Azure

Aggiornamento: giugno 2014

Le macchine virtuali di Microsoft Azure con SQL Server possono consentire agli amministratori di database di ridurre il costo di una soluzione di database a disponibilità elevata e con ripristino di emergenza (HADR). Molte soluzioni HADR di SQL Server sono supportate in Macchine virtuali di Azure, sia come soluzioni solo Azure sia come soluzioni ibride. In una soluzione solo Azure l'intero sistema HADR viene eseguito in Azure. In una configurazione ibrida, parte della soluzione viene eseguita in Azure e l'altra parte viene eseguita localmente nell'organizzazione. La flessibilità dell'ambiente Azure consente di passare a Azure in parte o completamente per rispondere ai requisiti HADR e di budget dei sistemi di database SQL Server.

L'amministratore del database ha il compito di garantire che il sistema di database disponga delle funzionalità HADR richieste dal contratto di servizio (SLA). I meccanismi di disponibilità elevata di Azure, ad esempio la riparazione per i servizi cloud e il rilevamento del ripristino da errore per le Macchine virtuali, non garantiscono di per sé la soddisfazione dei requisiti del contratto di servizio desiderato. Questi meccanismi proteggono la disponibilità elevata delle macchine virtuali, ma non la disponibilità elevata di SQL Server che viene eseguito nelle macchine virtuali. È possibile che l'istanza di SQL Server restituisca un errore mentre la macchina virtuale è online e integra. Inoltre, anche i meccanismi di disponibilità elevata forniti in Azure non evitano tempi di inattività delle macchine virtuali a causa di eventi quali il ripristino da errori software o hardware e gli aggiornamenti del sistema operativo.

Neppure l'archiviazione ridondante a livello geografico (GRS, Geo Redundant Storage) di Azure non costituisce un'adeguata soluzione di ripristino di emergenza per i database. Poiché la replica geografica invia dati in modo asincrono, è possibile che gli aggiornamenti recenti vadano persi in caso di errore grave. Per altre informazioni relative alle limitazioni della replica geografica, consultare la sezione Replica geografica non supportata per i file di dati e di log in dischi separati.

Le tecnologie HADR SQL Server supportate in Azure includono:

È possibile combinare le tecnologie per implementare una soluzione di SQL Server che disponga di funzionalità di disponibilità elevata e di ripristino di emergenza. A seconda della tecnologia da utilizzare, una distribuzione ibrida può richiedere un tunnel VPN con la rete virtuale di Azure. Nelle sezioni seguenti vengono illustrate alcune architetture di distribuzione di esempio.

È possibile disporre di una soluzione a disponibilità elevata per i database di SQL Server in Azure utilizzando i gruppi di disponibilità AlwaysOn o il mirroring del database.

 

Tecnologia Architetture di esempio

Gruppi di disponibilità AlwaysOn

Tutte le repliche di disponibilità sono in esecuzione in Macchine virtuali di Azure per la disponibilità elevata nella stessa area. È necessario configurare un controller di dominio oltre alle macchine virtuali di SQL Server perché Windows Server Failover Clustering (WSFC) richiede un dominio Active Directory.

Per altre informazioni, vedere Esercitazione: gruppi di disponibilità AlwaysOn in Azure (GUI).

Mirroring del database

Tutti i server principali, mirror e di controllo sono in esecuzione nello stesso data center di Azure per la disponibilità elevata. È possibile effettuare la distribuzione utilizzando un controller di dominio.

È inoltre possibile distribuire la stessa configurazione di mirroring del database senza un controller di dominio utilizzando in alternativa i certificati del server.

Per altre informazioni, vedere Esercitazione: mirroring del database per la disponibilità elevata in Azure.

È possibile disporre di una soluzione di ripristino di emergenza per i database SQL Server in Azure utilizzando i gruppi di disponibilità AlwaysOn, il mirroring del database o la funzionalità di backup e ripristino con i BLOB di archiviazione.

 

Tecnologia Architetture di esempio

Gruppi di disponibilità AlwaysOn

Repliche di disponibilità in esecuzione tra più data center in Macchine virtuali di Azure per il ripristino di emergenza. Questa soluzione per più aree protegge dalla completa interruzione dell'alimentazione del sito.

Nell'ambito di un'area, tutte le repliche dovranno risiedere nello stesso servizio cloud e sulla stessa VNet. Poiché ogni area sarà caratterizzata da una VNet separata, queste soluzioni richiedono la connettività da VNet a VNet. Per altre informazioni vedere Configurare la connettività tra reti virtuali.

Mirroring del database

Tutti i server principali, mirror e di controllo sono in esecuzione in diversi data center per il ripristino di emergenza. È necessario eseguire la distribuzione utilizzando certificati del server perché un dominio di Active Directory non può essere esteso a più data center.

Per altre informazioni, vedere Esercitazione: mirroring del database per il ripristino di emergenza in Azure.

Backup e ripristino con il servizio di archiviazione BLOB di Azure

Il backup dei database di produzione viene eseguito direttamente nell'archiviazione BLOB in un data center diverso per il ripristino di emergenza.

Per altre informazioni, vedere Backup e ripristino per SQL Server in Macchine virtuali di Azure.

È possibile disporre di una soluzione di ripristino di emergenza per i database SQL Server in un ambiente IT ibrido tramite gruppi di disponibilità AlwaysOn, mirroring del database, log shipping e backup e ripristino con l'archiviazione BLOB di Azure.

 

Tecnologia Architetture di esempio

Gruppi di disponibilità AlwaysOn

Alcune repliche di disponibilità sono in esecuzione in Macchine virtuali di Azure e altre sono in esecuzione in locale per il ripristino di emergenza tra siti. Il sito di produzione può essere locale o trovarsi in un data center di Azure.

Poiché tutte le repliche di disponibilità devono trovarsi nello stesso cluster WSFC, tale cluster deve essere esteso a entrambe le reti (un cluster WSFC su più subnet). Questa configurazione richiede una connessione VPN tra Azure e la rete locale.

Per il corretto ripristino di emergenza dei database, è inoltre opportuno installare un controller di dominio di replica nel sito di ripristino di emergenza.

Per altre informazioni, vedere Tutorial: AlwaysOn Availability Groups in Hybrid IT.

Mirroring del database

  • Un partner è in esecuzione in una Macchina virtuale di Azure e l'altro è in esecuzione in locale per il ripristino di emergenza tra siti utilizzando certificati del server. I partner non devono essere nello stesso dominio Active Directory e non è richiesta alcuna connessione VPN.



    Per altre informazioni, vedere Esercitazione: mirroring del database per il ripristino di emergenza nell'ambiente IT ibrido.

  • Un partner è in esecuzione in una macchina virtuale di Azure e l'altro è in esecuzione in locale nello stesso dominio Active Directory per il ripristino di emergenza tra siti. È richiesta una connessione VPN tra la rete virtuale di Azure e la rete locale.

    Per il corretto ripristino di emergenza dei database, è inoltre opportuno installare un controller di dominio di replica nel sito di ripristino di emergenza.

Log shipping

Un server è in esecuzione in una macchina virtuale di Azure e l'altro è in esecuzione in locale per il ripristino di emergenza tra siti. Il log shipping dipende dalla condivisione dei file di Windows, pertanto è richiesta una connessione VPN tra la rete virtuale di Azure e la rete locale.

Per il corretto ripristino di emergenza dei database, è inoltre opportuno installare un controller di dominio di replica nel sito di ripristino di emergenza.

Per altre informazioni, vedere Esercitazione: log shipping per il ripristino di emergenza nell'ambiente IT ibrido.

Backup e ripristino con il servizio di archiviazione BLOB di Azure

Il backup dei database di produzione locali viene eseguito direttamente nell'archiviazione BLOB di Azure per il ripristino di emergenza.

Per altre informazioni, vedere Backup e ripristino per SQL Server in Macchine virtuali di Azure.

La macchina virtuale, l'archiviazione e la rete di Azure hanno caratteristiche operative diverse rispetto a un'infrastruttura IT locale non virtualizzata. Per una corretta implementazione di una soluzione HADR SQL Server in Azure è necessario capire queste differenze e progettare una soluzione adeguata.

I set di disponibilità in Azure consentono di collocare i nodi a disponibilità elevata in domini di errore (FD, Fault Domain) e domini di aggiornamento (UD, Update Domain) separati. Per collocare le macchine virtuali di Azure nello stesso set di disponibilità, è necessario distribuirle nello stesso servizio cloud. Solo i nodi dello stesso servizio cloud possono partecipare allo stesso set di disponibilità. Per altre informazioni, vedere la pagina relativa alla gestione della disponibilità delle macchine virtuali (la pagina potrebbe essere in inglese).

Il servizio DHCP non conforme a RFC di Azure può provocare la non riuscita della creazione di determinate configurazioni del cluster WSFC, a causa dell'assegnazione al nome di rete del cluster di un indirizzo IP duplicato (lo stesso indirizzo IP di uno dei nodi del cluster). Ciò costituisce un problema quando si implementano i gruppi di disponibilità AlwaysOn, che dipendono dalla funzionalità WSFC.

Si consideri uno scenario in cui viene creato e portato online un cluster a due nodi:

  1. Il cluster è online e NODE1 richiede un indirizzo IP assegnato in modo dinamico per il nome di rete del cluster.

  2. Al servizio DHCP non viene assegnato un indirizzo IP diverso da quello dello stesso NODE1, poiché il servizio DHCP riconosce che la richiesta proviene da NODE1.

  3. Windows rileva l'assegnazione di un indirizzo duplicato a NODE1 e al nome di rete del cluster e il gruppo cluster predefinito non può essere portato online.

  4. Il gruppo cluster predefinito passa a NODE2, che tratta l'indirizzo IP di NODE1 come l'indirizzo IP del cluster e porta online il gruppo cluster predefinito.

  5. Quando NODE2 tenta di stabilire la connessione con NODE1, i pacchetti indirizzati a NODE1 non lasciano mai NODE2 perché l'indirizzo IP di NODE1 viene risolto in sé stesso. NODE2 non è in grado di stabilire la connessione con NODE1, quindi perde il quorum e arresta il cluster.

  6. Nel frattempo, NODE1 può inviare i pacchetti a NODE2, ma NODE2 non può rispondere. NODE1 perde il quorum e arresta il cluster.

È possibile evitare questo scenario assegnando un indirizzo IP statico inutilizzato, ad esempio un indirizzo IP locale rispetto al collegamento come 169.254.1.1, al nome di rete del cluster per portarlo online. Per semplificare il processo, vedere la pagina relativa alla configurazione del cluster di failover di Windows in Azure per i gruppi di disponibilità AlwaysOn (la pagina potrebbe essere in inglese).

Le esercitazioni seguenti per i gruppi di disponibilità AlwaysOn illustrano come configurare un gruppo di disponibilità in scenari diversi.

I listener del gruppo di disponibilità sono supportati nelle Macchine virtuali di Azure che eseguono Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2. Questo supporto viene fornito attraverso l'utilizzo di endpoint con carico bilanciato con Direct Server Return (DSR) abilitato nelle VM di Azure che costituiscono nodi del gruppo di disponibilità. È necessario eseguire passaggi di configurazione speciali affinché i listener funzionino sia per le applicazioni client eseguite in Azure sia per quelli eseguiti in locale. Per istruzioni sulla configurazione di un listener, vedere Esercitazione: Configurazione del listener per i gruppi di disponibilità AlwaysOn.

È comunque possibile connettersi separatamente a ogni replica di disponibilità effettuando la connessione direttamente all'istanza del servizio. Inoltre, poiché i gruppi di disponibilità AlwaysOn sono compatibili con le versioni precedenti dei client di mirroring del database, è possibile connettersi alle repliche di disponibilità come partner di mirroring del database purché le repliche siano configurate in modo analogo al mirroring del database:

  • Una replica primaria e una replica secondaria

  • La replica secondaria è configurata come non leggibile (opzioneSecondario leggibile impostata su No)

Di seguito è riportata una stringa di connessione client di esempio corrispondente a questa configurazione simile al mirroring del database utilizzando ADO.NET o SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Per ulteriori informazioni sulla connettività client, vedere:

È opportuno distribuire la soluzione HADR con il presupposto che potrebbero verificarsi lunghi periodi di tempo con latenza di rete elevata tra la rete locale e Azure. Quando si distribuiscono le repliche a Azure, occorre utilizzare il commit asincrono anziché quello sincrono per la modalità di sincronizzazione. Per la distribuzione dei server di mirroring del database in locale e in Azure, utilizzare la modalità a prestazioni elevate anziché la modalità a sicurezza elevata.

La replica geografica nei dischi di Azure non supporta l'archiviazione del file di dati e del file di log dello stesso database in dischi separati. La funzionalità GRS replica le modifiche in ogni disco in modo indipendente e asincrono. Questo meccanismo garantisce l'ordine di scrittura in un disco singolo nella copia replicata geograficamente, ma non in più copie replicate geograficamente di più dischi. Se si configura un database per l'archiviazione del file di dati e del file di log in dischi separati, i dischi recuperati dopo un'emergenza potranno contenere una copia più aggiornata del file di dati che del file di log, creando un'interruzione nel log write-ahead in SQL Server e nelle proprietà ACID delle transazioni. Se non è possibile disabilitare la replica geografica nell'account di archiviazione, è consigliabile mantenere tutti i file di dati e i file di log per un determinato database nello stesso disco. Se è necessario utilizzare più dischi a causa delle dimensioni del database, è necessario distribuire una delle soluzioni di ripristino di emergenza elencate in precedenza per garantire la ridondanza dei dati.

Vedere anche

Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft