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

Si applica a: SQL Server su VM di Azure

Questo articolo mette a confronto le soluzioni di continuità aziendale solo Azure e ibride che è possibile usare per la disponibilità elevata e il ripristino di emergenza (HADR) con SQL Server in Azure Macchine virtuali (VM)

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

Panoramica

SQL Server in macchine virtuali di Azure supporta il tipo di soluzioni seguente:

• Solo Azure: l'intero sistema HADR viene eseguito in Azure.
• 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. È necessario assicurarsi che i sistemi di database dispongano di funzionalità HADR che soddisfano i requisiti aziendali per l'obiettivo del tempo di ripristino (RTO), l'obiettivo del punto di ripristino (RPO) e il contratto di servizio (SLA).

I meccanismi di disponibilità elevata predefiniti 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, RTO o RPO. 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.

Funzionalità per la continuità aziendale

La tabella seguente elenca sia le funzionalità di SQL Server solo Azure che ibride che è possibile usare per la disponibilità elevata, il ripristino di emergenza o entrambi (disponibilità elevata/ripristino di emergenza):

Queste funzionalità di SQL Server sono supportate per la continuità aziendale in una configurazione solo di Azure o ibrida. Alcune delle opzioni sono ideali sia per la disponibilità elevata che per il ripristino di emergenza (HA/DR), la disponibilità elevata (HA), mentre altre vengono usate per il ripristino di emergenza (DR).

È 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. Anche se le tecnologie sono le stesse, potrebbero esserci alcune differenze nel modo in cui vengono configurate in Azure o in una progettazione ibrida.

Gruppi di disponibilità (HADR)

La protezione di SQL Server in macchine virtuali di Azure a livello di database può essere eseguita usando i gruppi di disponibilità come soluzione HADR (High Availability And Disaster Recovery). Le repliche in esecuzione nelle macchine virtuali di Azure nella stessa area assicurano disponibilità elevata. È necessaria una macchina virtuale da usare come controller di dominio perché il servizio Clustering di failover di Windows richiede un dominio di Active Directory.

Per iniziare, consultare l'esercitazione sul gruppo di disponibilità.

Per una maggiore ridondanza, disponibilità e riprino di emergenza, le VM di Azure possono essere distribuite in diverse zone di disponibilità, come illustrato nella panoramica dei gruppi di disponibilità. L’espansione delle repliche di disponibilità per l’esecuzione di più data center nelle macchine virtuali di Azure aggiunge un'ulteriore copertura di ripristino di emergenza. Una soluzione per più aree aiuta 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 è 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.

In una configurazione ibrida, alcune repliche di disponibilità vengono eseguite nelle macchine virtuali di Azure e altre sono 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à.

Istanze con clustering di failover (HA)

SQL Server nelle VM di Azure supporta istanze del cluster di failover e questa soluzione offre disponibilità elevata a livello di istanza. Per maggiore protezione, è anche possibile creare ridondanza per entrambi i livelli di database e istanza tramite la creazione di gruppi di disponibilità in cima alle istanze del cluster di failover. La funzionalità FCI richiede l'archiviazione condivisa, e ci sono cinque soluzioni che funzionano 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.

Log shipping (DR)

Un’altra soluzione di ripristino di emergenza in Azure è il log shipping che invia automaticamente i backup del log delle transazioni da un database primario su un server primario a uno o più database secondari su un server secondario separato. La configurazione del log shipping usa una condivisione file di Azure per archiviare i backup del log delle transazioni.

Se è necessario configurare il log shipping in un ambiente ibrido, un server si trova in una macchina virtuale di Azure e l'altro è 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.

Eseguire il backup e il ripristino (DR)

Il backup dei database di produzione è necessario per il ripristino di emergenza. In Azure, è possibile eseguire il backup dei database di produzione direttamente nell'archiviazione Blob in un data center diverso per il ripristino di emergenza.

In una soluzione ibrida, il backup dei database di produzione locali può essere 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.

Replicare usando Azure Site Recovery (DR)

Ripristino sito Azure può essere usato come soluzione di ripristino di emergenza sia in Azure che in una configurazione ibrida.

All’interno di Azure, 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 ambienti ibridi, 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, poi 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.