Continuità aziendale e HADR per SQL Server su macchine virtuali di Azure

Si applica a:SQL Server su VM di Azure

La continuità aziendale significa continuare l'attività in caso di emergenza, pianificare il ripristino e garantire che i dati siano altamente disponibili. SQL Server su macchine virtuali di Azure può consentire 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 nelle macchine virtuali (VM) 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 ad Azure in parte o completamente per rispondere ai requisiti HADR e di budget dei sistemi di database di SQL Server.

Questo articolo confronta e contrasta le soluzioni di continuità aziendale disponibili per SQL Server su VM di Azure.

Panoramica

È compito dell'utente garantire che il sistema di database disponga delle capacità 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. Anche se questi meccanismi consentono di proteggere la disponibilità elevata della macchina virtuale, non proteggono la disponibilità di SQL Server in esecuzione all'interno della VM.

È possibile che l'istanza di SQL Server restituisca un errore mentre la VM è online e integra. 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.

L'archiviazione con ridondanza geografica (GRS) in Azure viene implementata con una funzionalità denominata replica geografica. La GRS potrebbe non essere una soluzione di ripristino di emergenza adeguata per i database. Poiché la replica geografica invia dati in modo asincrono, è possibile che gli aggiornamenti recenti vadano persi dopo un errore grave. Altre informazioni sulle limitazioni della replica geografica sono descritte nella sezione Supporto per la replica geografica.

Nota

È ora possibile trasferire in modalità lift-and-shift la soluzione dell'istanza del cluster di failover e del gruppo di disponibilità a SQL Server su VM di Azure usando Azure Migrate.

Architetture di distribuzione

Azure supporta queste tecnologie di SQL Server per la continuità aziendale:

• Gruppi di disponibilità Always On
• Istanze del cluster di failover Always On (FCI)
• Log shipping
• Backup e ripristino di SQL Server con Archiviazione Blob di Azure
• Mirroring del database - Deprecato in SQL Server 2016
• Azure Site Recovery

È possibile combinare le tecnologie per implementare una soluzione di SQL Server che disponga sia di capacità di disponibilità elevata che di ripristino di emergenza. A seconda della tecnologia che si utilizza, una distribuzione ibrida può richiedere un tunnel VPN con la rete virtuale di Azure. Le sezioni seguenti illustrano alcuni esempi di architetture di distribuzione.

Solo Azure: soluzioni a disponibilità elevata

È possibile avere una soluzione a disponibilità elevata per SQL Server a livello di database con gruppi di disponibilità Always On. È anche possibile creare una soluzione a disponibilità elevata a livello di istanza con istanze del cluster di failover Always On. Per maggiore protezione, è anche possibile creare ridondanza per entrambi i livelli tramite la creazione di gruppi di disponibilità nelle istanze del cluster di failover.

Tecnologia	Architetture di esempio
Gruppi di disponibilità	Le repliche di disponibilità in esecuzione nelle macchine virtuali di Azure nella stessa area assicurano disponibilità elevata. È necessario configurare una macchina virtuale da usare come controller di dominio perché il servizio Clustering di failover di Windows richiede un dominio di Active Directory. Per una maggiore ridondanza e disponibilità, le VM di Azure possono essere distribuite in diverse zone di disponibilità, come illustrato nella panoramica dei gruppi di disponibilità. Per iniziare, consultare l'esercitazione sul gruppo di disponibilità.
Istanze del cluster di failover	Le istanze del cluster di failover sono supportate nelle VM di Azure. Poiché la funzionalità FCI richiede l'archiviazione condivisa, cinque soluzioni funzioneranno con SQL Server su VM di Azure: - Uso di dischi condivisi di Azure per Windows Server 2019. I dischi gestiti condivisi sono un prodotto Azure che consente di collegare un disco gestito a più macchine virtuali contemporaneamente. Le macchine virtuali nel cluster possono leggere o scrivere sul disco collegato in base alla prenotazione scelta dall'applicazione in cluster mediante le prenotazioni permanenti SCSI (SCSI PR). Una prenotazione permanente SCSI è una soluzione di archiviazione standard del settore usata dalle applicazioni in esecuzione in una rete di archiviazione (SAN) locale. L'abilitazione delle prenotazioni permanenti SCSI in un disco gestito consente di eseguire la migrazione di queste applicazioni in Azure così come sono. - Uso di Spazi di archiviazione diretta (S2D) per fornire una SAN virtuale basata su software per Windows Server 2016 e versioni successive. - Uso di una condivisione file Premium per Windows Server 2012 e versioni successive. Le condivisioni file Premium sono supportate da SSD e offrono una latenza costantemente bassa e sono completamente supportate per l'uso con FCI. - Uso dell'archiviazione supportata da una soluzione partner per il clustering. Per un esempio specifico che usa SIOS DataKeeper, vedere la voce di blog Clustering di failover e SIOS DataKeeper. - Uso dell'archiviazione a blocchi condivisa per una destinazione iSCSI remota tramite Azure ExpressRoute. Ad esempio, NetApp Private Storage (NPS) espone una destinazione iSCSI tramite ExpressRoute con Equinix a macchine virtuali di Azure. Per le soluzioni di replica dei dati e archiviazione condivisa dei partner Microsoft, contattare il fornitore in caso di problemi di accesso ai dati durante il failover. Per iniziare, preparare la VM per l'istanza del cluster di failover

Solo Azure: soluzioni di ripristino di emergenza

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

Tecnologia	Architetture di esempio
Gruppi di disponibilità	Repliche di disponibilità in esecuzione tra più data center nelle macchine virtuali di Azure per il ripristino di emergenza. Questa soluzione per più aree aiutano a proteggere dalla completa interruzione dell'alimentazione del sito. Nell'ambito di un'area tutte le repliche dovranno risiedere nello stesso servizio cloud e nella stessa rete virtuale. Poiché ogni area sarà caratterizzata da una rete virtuale separata, queste soluzioni richiedono la connettività da rete a rete. Per altre informazioni, vedere Configurare una connessione da rete a rete con il portale di Azure. Per istruzioni dettagliate, vedere Configurare un gruppo di disponibilità SQL Server Always On in diverse aree di Azure.
Mirroring del database	Tutti i server principali, mirror e di controllo in esecuzione in diversi data center per il ripristino di emergenza. È necessario eseguire l'implementazione tramite certificati del server.
Backup e ripristino con 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 su VM di Azure.
Replica e failover di SQL Server in Azure con Azure Site Recovery	L'istanza di produzione di SQL Server in un data center di Azure viene replicata direttamente in Archiviazione di Azure in un diverso data center di Azure per il ripristino di emergenza. Per altre informazioni, vedere Proteggere SQL Server con il ripristino di emergenza di SQL Server e Azure Site Recovery.

IT ibrido: soluzioni di ripristino di emergenza

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

Tecnologia	Architetture di esempio
Gruppi di disponibilità	Alcune repliche di disponibilità in esecuzione nelle macchine virtuali di Azure e altre 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 di failover, tale cluster deve essere esteso a entrambe le reti (un cluster di failover 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 iniziare, consultare l'esercitazione sul gruppo di disponibilità.
Mirroring del database	Un partner in esecuzione in una VM di Azure e l'altro in esecuzione in locale per il ripristino di emergenza tra siti usando certificati del server. I partner non devono essere nello stesso dominio di Active Directory e non è richiesta alcuna connessione VPN. Un altro scenario di mirroring del database include un partner in esecuzione in una VM di Azure e l'altro in esecuzione in locale nello stesso dominio di Active Directory per il ripristino di emergenza tra siti. È necessaria 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.
Backup e ripristino con 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 su macchine virtuali di Azure.
Replica e failover di SQL Server in Azure con Azure Site Recovery	La replica dell'istanza di produzione locale di SQL Server viene eseguita direttamente in Archiviazione di Azure per il ripristino di emergenza. Per altre informazioni, vedere Proteggere SQL Server con il ripristino di emergenza di SQL Server e Azure Site Recovery.

Replica di ripristino di emergenza gratuita in Azure

Se si ha Software Assurance, è possibile implementare piani di ripristino di emergenza (DR) ibridi con SQL Server senza sostenere costi di licenza aggiuntivi per l'istanza di ripristino di emergenza passiva. L'utente è anche idoneo per le repliche di ripristino di emergenza gratuite con licenza con pagamento in base al consumo se tutte le repliche sono ospitate in Azure.

Ad esempio, è possibile avere due database secondari passivi gratuiti quando tutte e tre le repliche sono ospitate in Azure:

In alternativa, è possibile configurare un ambiente di failover ibrido con una licenza primaria locale, una passiva gratuita per la disponibilità elevata, una passiva gratuita per il ripristino di emergenza locale e una passiva gratuita per il ripristino di emergenza in Azure:

Per ulteriori informazioni, vedere le condizioni di licenza del prodotto.

Per abilitare questo vantaggio, passare alla propria risorsa di macchina virtuale di SQL Server. Selezionare Configura in Impostazioni, quindi scegliere l'opzione disponibilità elevata/ripristino di emergenza in Licenza SQL Server. Selezionare la casella di controllo per confermare che la VM di SQL Server verrà usata come replica passiva, quindi selezionare Applica per salvare le impostazioni. Quando tutte e tre le repliche sono ospitate in Azure, anche i clienti con pagamento in base al consumo hanno diritto a usare il tipo di licenza disponibilità elevata/ripristino di emergenza.

Considerazioni importanti per HADR di SQL Server in 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 di SQL Server in Azure è necessario capire queste differenze e progettare una soluzione adeguata.

Nodi a disponibilità elevata in un set di disponibilità

I set di disponibilità in Azure consentono di collocare i nodi a disponibilità elevata in domini di errore e domini di aggiornamento separati. A ogni macchina virtuale nel set di disponibilità vengono assegnati un dominio di aggiornamento e un dominio di errore dalla piattaforma Azure. Questa configurazione in un data center assicura infatti che, nel corso di un evento di manutenzione pianificata o non pianificata, almeno una delle macchine virtuali sia sempre disponibile e soddisfi per almeno il 99,95% i requisiti del contratto di servizio di Azure.

Per impostare la configurazione a disponibilità elevata, inserire tutte le macchine virtuali di SQL Server interessate nello stesso set di disponibilità per evitare perdite di dati o applicazioni durante un evento di manutenzione. Solo i nodi dello stesso servizio cloud possono partecipare allo stesso set di disponibilità. Per altre informazioni, vedere Gestire la disponibilità delle macchine virtuali.

Nodi a disponibilità elevata in una zona di disponibilità

Le zone di disponibilità sono località fisiche esclusive all'interno di un'area di Azure. Ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l'alimentazione, il raffreddamento e la connettività di rete. La separazione fisica delle zone di disponibilità all'interno di un'area consente di proteggere le applicazioni e i dati da eventuali guasti del data center, assicurando che almeno una macchina virtuale sia disponibile e soddisfi il 99,99% del contratto di servizio di Azure.

Per configurare la disponibilità elevata, inserire le macchine virtuali di SQL Server interessate distribuendole tra le zone di disponibilità presenti nell'area. Verranno addebitati costi aggiuntivi per i trasferimenti da rete a rete tra le zone di disponibilità. Per altre informazioni, vedere Zone di disponibilità.

Latenza di rete in ambiente IT ibrido

Implementare la soluzione HADR con il presupposto che potrebbero verificarsi lunghi periodi con latenza di rete elevata tra la rete locale e Azure. Quando si implementano le repliche in Azure, usare il commit asincrono anziché quello sincrono per la modalità di sincronizzazione. Per l'implementazione dei server di mirroring del database in locale e in Azure, usare la modalità a prestazioni elevate anziché la modalità a protezione elevata.

Vedere le procedure consigliate per la configurazione HADR per le impostazioni cluster e HADR che consentono di gestire l'ambiente cloud.

Supporto della replica geografica

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. L'archiviazione con ridondanza geografica 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 (atomicità, coerenza, isolamento e durabilità) delle transazioni.

Se non è possibile disabilitare la replica geografica nell'account di archiviazione, mantenere tutti i file di dati e i file di log per un database nello stesso disco. Se è necessario usare più dischi a causa delle dimensioni del database, implementare una delle soluzioni di ripristino di emergenza elencate in precedenza per garantire la ridondanza dei dati.

Passaggi successivi

Decidere se un gruppo di disponibilità o un'istanza del cluster di failover è la soluzione di continuità aziendale migliore per l'azienda. Esaminare quindi le procedure consigliate per configurare l'ambiente per la disponibilità elevata e il ripristino di emergenza.