Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Amazon EC2 per SQL Server
Amazon EC2 supporta un database SQL Server autogestito. In altre parole, ti dà il pieno controllo sulla configurazione dell'infrastruttura e dell'ambiente di database. L'esecuzione del database su Amazon EC2 è molto simile all'esecuzione del database sul proprio server. Hai il pieno controllo del database e dell'accesso a livello di sistema operativo, quindi puoi utilizzare gli strumenti che preferisci per gestire il sistema operativo, il software del database, le patch, la replica dei dati, il backup e il ripristino. Questa opzione di migrazione richiede l'installazione, la configurazione, la gestione e l'ottimizzazione di tutti i componenti, incluse le istanze EC2, i volumi di storage, la scalabilità, il networking e la sicurezza, sulla base delle migliori pratiche di architettura. AWS Sei responsabile della replica e del ripristino dei dati tra le tue istanze nella stessa regione o in regioni diverse. AWS
## Quando scegliere Amazon EC2
Amazon EC2 è una buona opzione di migrazione per il tuo database SQL Server quando:
+ È necessario il pieno controllo del database e l'accesso al sistema operativo sottostante, all'installazione e alla configurazione del database.
+ Si desidera amministrare il database, inclusi backup e ripristino, applicare patch al sistema operativo e al database, ottimizzare i parametri del sistema operativo e del database, gestire la sicurezza e configurare l'alta disponibilità o la replica.
+ Desideri utilizzare funzionalità e opzioni che attualmente non sono supportate da Amazon RDS. Per i dettagli, consulta [Funzionalità non supportate e funzionalità con supporto limitato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.FeatureNonSupport) nella documentazione di Amazon RDS.
+ È necessaria una versione specifica di SQL Server non supportata da Amazon RDS. Per un elenco delle versioni ed edizioni supportate, consulta [le versioni di SQL Server su Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html#SQLServer.Concepts.General.VersionSupport) nella documentazione di Amazon RDS.
+ Le dimensioni e le prestazioni del database superano le attuali offerte di Amazon RDS for SQL Server. Per i dettagli, consulta lo [storage di istanze database di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) nella documentazione di Amazon RDS.
+ Vuoi evitare patch software automatiche che potrebbero non essere conformi alle tue applicazioni.
+ Preferisci portare la tua licenza invece di utilizzare il modello Amazon RDS for SQL Server con licenza inclusa.
+ Desideri ottenere IOPS e capacità di storage più elevati rispetto ai limiti attuali. Per i dettagli, consulta lo [storage di istanze database di Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) nella documentazione di Amazon RDS.
Per un elenco delle funzionalità e delle versioni di SQL Server attualmente supportate su Amazon EC2, consulta [Scelta tra Amazon EC2 e Amazon](comparison.md) RDS più avanti in questa guida.
# Elevata disponibilità
Puoi utilizzare qualsiasi tecnologia di replica supportata da SQL Server con il tuo database SQL Server su Amazon EC2 per ottenere disponibilità elevata, protezione dei dati e disaster recovery. Alcune delle soluzioni più comuni sono la spedizione dei log, il mirroring del database, i gruppi di disponibilità Always On e le istanze di cluster di failover Always On.
Il diagramma seguente mostra come utilizzare SQL Server su Amazon EC2 su più zone di disponibilità all'interno di una AWS singola regione. Il database primario è un database di lettura-scrittura, mentre il database secondario è configurato con log shipping, mirroring del database o gruppi di disponibilità Always On per un'elevata disponibilità. Tutti i dati delle transazioni dal database primario vengono trasferiti e possono essere applicati al database secondario in modo asincrono per la spedizione dei log e in modo asincrono per i gruppi di disponibilità e il mirroring Always On.
![\[SQL Server on Amazon EC2 in a Multi-AZ configuration in one AWS Region\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/migration-sql-server/images/sql-migration-ec2.png)
# Invio dei log
La spedizione dei log consente di inviare automaticamente i backup dei log delle transazioni da un'istanza di database principale a uno o più database secondari (noti anche come *warm standby*) su istanze DB separate. La spedizione dei log utilizza i job di SQL Server Agent per automatizzare il processo di backup, copia e applicazione dei backup dei log delle transazioni. Sebbene la spedizione dei log sia generalmente considerata una funzionalità di disaster recovery, può anche fornire un'elevata disponibilità consentendo la promozione di istanze DB secondarie in caso di guasto dell'istanza DB primaria. Se l'RTO e l'RPO sono flessibili o i database non sono considerati di importanza critica, valuta la possibilità di utilizzare la spedizione dei log per fornire una migliore disponibilità per i database SQL Server.
La spedizione dei log aumenta la disponibilità dei database fornendo l'accesso ai database secondari da utilizzare come copie di sola lettura del database principale quando necessario. È possibile configurare un ritardo (un periodo di ritardo più lungo) durante il quale è possibile recuperare i dati modificati accidentalmente sul database primario prima che tali modifiche vengano inviate al database secondario.
Consigliamo di eseguire le istanze DB primarie e secondarie in zone di disponibilità separate e di implementare un'istanza di monitoraggio per tenere traccia di tutti i dettagli della spedizione dei log. Gli eventi di backup, copia, ripristino e errore per un gruppo di spedizione dei log sono disponibili dall'istanza di monitoraggio. Una configurazione di spedizione dei log non esegue automaticamente il failover dal server primario al server secondario. Tuttavia, qualsiasi database secondario può essere portato online manualmente se il database primario non è più disponibile.
La spedizione dei log viene spesso utilizzata come soluzione di disaster recovery, ma può anche essere utilizzata come soluzione ad alta disponibilità, a seconda dei requisiti dell'applicazione. Utilizza la spedizione in log quando:
+ Hai requisiti RTO e RPO flessibili. La spedizione dei log fornisce un RPO di minuti e un RTO compreso tra minuti e ore.
+ Non è necessario un failover automatico sul database secondario.
+ Si desidera leggere dal database secondario, ma non è richiesta la leggibilità durante un'operazione di ripristino.
Per ulteriori informazioni sulla spedizione dei log, consulta la [documentazione di Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server).
# Mirroring del database
Il mirroring del database utilizza un database che si trova su un'istanza EC2 e ne fornisce una copia completa o quasi completa in sola lettura (mirror) su un'istanza DB separata. Amazon RDS utilizza il mirroring del database per fornire supporto Multi-AZ per Amazon RDS for SQL Server. Questa funzionalità aumenta la disponibilità e la protezione dei database e fornisce un meccanismo per mantenere i database disponibili durante gli aggiornamenti.
**Nota**
Secondo la [documentazione Microsoft](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server), il mirroring del database verrà rimosso in una versione futura di SQL Server. Dovresti invece pianificare di utilizzare i gruppi di disponibilità Always On.
Nel mirroring del database, i server SQL possono assumere uno dei tre ruoli seguenti:
+ Il server principale, che ospita la read/write versione principale del database.
+ Il server mirror, che ospita una copia del database principale.
+ Un server di controllo opzionale. Questo server è disponibile solo in modalità ad alta sicurezza. Monitora lo stato del mirror del database e automatizza il failover dal database primario al database mirror.
Viene stabilita una sessione di mirroring tra il server principale e il server mirror. Durante il mirroring, tutte le modifiche al database eseguite nel database principale vengono eseguite anche sul database mirror. Il mirroring del database può essere un'operazione sincrona o asincrona. Ciò è determinato da due modalità operative di mirroring: modalità ad alta sicurezza e modalità ad alte prestazioni.
+ Modalità **ad alta sicurezza: questa modalità utilizza operazioni** sincrone. In questa modalità, la sessione di mirroring del database sincronizza le operazioni di inserimento, aggiornamento ed eliminazione dal database principale al database mirror il più rapidamente possibile. Non appena il database viene sincronizzato, la transazione viene confermata sia nel database principale che in quello mirror. Si consiglia di utilizzare questa modalità operativa quando i database mirror si trovano nella stessa zona di disponibilità o in zone di disponibilità diverse, ma ospitati nella stessa AWS regione.
+ **Modalità ad alte prestazioni:** questa modalità utilizza operazioni asincrone. In questa modalità, la sessione di mirroring del database sincronizza le operazioni di inserimento, aggiornamento ed eliminazione dal database principale al database mirror, ma può verificarsi un ritardo tra il momento in cui il database principale esegue il commit delle transazioni e il momento in cui il database mirror esegue le transazioni. Si consiglia di utilizzare questa modalità quando i database mirror si trovano in regioni diverse. AWS
Utilizza il mirroring del database quando:
+ Hai requisiti RTO e RPO rigorosi e non puoi avere ritardi tra il database primario e quello secondario. Il mirroring del database fornisce un RPO di zero secondi (con commit sincrono) e un RTO compreso tra secondi e minuti.
+ Non è necessario leggere dal database secondario.
+ Si desidera eseguire il failover automatico quando si dispone di un server di controllo configurato in modalità di sincronizzazione.
+ Non è possibile utilizzare i gruppi di disponibilità Always On, che è l'opzione preferita.
Restrizioni:
+ È supportato solo one-to-one il failover. Non è possibile sincronizzare più destinazioni del database con il database principale.
Per ulteriori informazioni sul mirroring, vedere la [documentazione di Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server).
# Gruppi di disponibilità Always On
I gruppi di disponibilità SQL Server Always On forniscono soluzioni di alta disponibilità e disaster recovery per i database SQL Server. Un gruppo di disponibilità è costituito da un set di database utente che eseguono contemporaneamente il failover. Include un singolo set di read/write database primari e più set (da uno a otto) di database secondari correlati. È possibile rendere i database secondari disponibili a livello di applicazione come copie di sola lettura dei database primari (solo edizione SQL Server Enterprise), per fornire un'architettura scalabile per i carichi di lavoro di lettura. È inoltre possibile utilizzare i database secondari per le operazioni di backup.
I gruppi di disponibilità Always On di SQL Server supportano modalità di commit sia sincrone che asincrone. In modalità sincrona, la replica primaria esegue il commit delle transazioni del database dopo il commit delle modifiche o la scrittura nel registro della replica secondaria. Utilizzando questa modalità, è possibile eseguire il failover manuale pianificato e il failover automatico se le repliche sono sincronizzate. È possibile utilizzare la modalità di commit sincrona tra istanze di SQL Server all'interno dello stesso ambiente (ad esempio, se tutte le istanze sono locali o tutte le istanze sono attive). AWS
In modalità di commit asincrona, la replica primaria esegue il commit delle transazioni del database senza attendere la replica secondaria. È possibile utilizzare la modalità di commit asincrona tra istanze di SQL Server che si trovano in ambienti diversi (ad esempio, se si dispone di istanze locali e interne). AWS
È possibile utilizzare i gruppi di disponibilità Always On per l'alta disponibilità o il disaster recovery. Utilizzate questo metodo quando:
+ Hai requisiti RTO e RPO rigorosi. I gruppi di disponibilità Always On forniscono un RPO in secondi e un RTO compreso tra secondi e minuti.
+ Vuoi gestire ed eseguire il failover di un gruppo di database. I gruppi di disponibilità Always On supportano 0-4 repliche secondarie in modalità di commit sincrona per SQL Server 2019.
+ Si desidera utilizzare il failover automatico in modalità di commit sincrona e non è necessario un server di controllo.
+ Vuoi leggere dal database secondario.
+ Vuoi sincronizzare più destinazioni del database con il tuo database principale.
A partire da SQL Server 2016 SP1, l'edizione SQL Server Standard offre un'elevata disponibilità di base per un singolo database e listener secondari non leggibili per gruppo di disponibilità. Supporta inoltre un massimo di due nodi per gruppo di disponibilità.
# Istanze del cluster di failover Always On
Le istanze SQL Server Always On Failover Cluster (FCIs) utilizzano Windows Server Failover Clustering (WSFC) per fornire un'elevata disponibilità a livello di istanza del server. Una FCI è una singola istanza di SQL Server che viene installata tra i nodi WSFC per fornire un'elevata disponibilità per l'intera installazione di SQL Server. Se nel nodo sottostante si verificano guasti hardware, del sistema operativo, delle applicazioni o dei servizi, tutto all'interno dell'istanza di SQL Server viene spostato in un altro nodo WSFC. Ciò include database di sistema, accessi a SQL Server, job di SQL Server Agent e certificati.
Un FCI è generalmente preferibile rispetto a un gruppo di disponibilità Always On quando:
+ Stai utilizzando l'edizione SQL Server Standard anziché l'edizione Enterprise.
+ Hai un gran numero di database di piccole dimensioni per istanza.
+ Modifichi costantemente oggetti a livello di istanza come i job di SQL Server Agent, gli accessi e così via.
Esistono quattro opzioni per la distribuzione su: FCIs AWS
+ Amazon EBS Multi-Attach con prenotazioni persistenti
+ File server Amazon FSx per Windows
+ Amazon FSx per NetApp ONTAP
+ Soluzioni dei partner AWS
## Utilizzo di Amazon EBS Multi-Attach con prenotazioni persistenti
[Amazon EBS Multi-Attach con NVMe prenotazioni](https://docs.aws.amazon.com/ebs/latest/userguide/nvme-reservations.html) supporta la creazione di SQL Server con `io2` volumi FCIs Amazon EBS come storage condiviso nei cluster di failover di Windows Server. Questa funzionalità semplifica il processo di configurazione del cluster di failover consentendoti di creare un cluster di failover utilizzando i volumi Amazon EBS. `io2` Questi volumi possono essere collegati solo a istanze che si trovano nella stessa zona di disponibilità. Per distribuire i cluster di failover di Windows Server utilizzando i `io2` volumi Amazon EBS, è necessario utilizzare i driver più recenti. AWS NVMe
I volumi Amazon EBS e i volumi dell'instance store sono esposti come dispositivi a NVMe blocchi su istanze [basate su Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances). È necessario che il [AWS NVMe driver](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html) sia installato con la [funzionalità di prenotazione persistente SCSI](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/aws-nvme-drivers.html#configure-scsi-persistent-reservations) configurata quando si utilizzano `io2` volumi Amazon EBS per creare WSFC e SQL Server. FCIs
Per ulteriori informazioni su questa funzionalità, consulta il post del AWS blog [How to deploy a SQL Server failover cluster with Amazon EBS Multi-Attach](https://aws.amazon.com/blogs/modernizing-with-aws/how-to-deploy-a-sql-server-failover-cluster-with-amazon-ebs-multi-attach-on-windows-server/) on Windows Server.
## Utilizzo di Amazon FSx per Windows File Server
[Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html) offre uno storage di file condiviso completamente gestito. Replica automaticamente lo storage in modo sincrono su due zone di disponibilità per fornire un'elevata disponibilità. L'utilizzo di FSx for Windows File Server per lo storage di file aiuta a semplificare e ottimizzare le implementazioni di SQL Server ad alta disponibilità su Amazon EC2.
Con Microsoft SQL Server, l'alta disponibilità viene in genere distribuita su più nodi di database in un WSFC e ogni nodo ha accesso allo storage di file condiviso. È possibile utilizzare FSx Windows File Server come storage condiviso per le distribuzioni ad alta disponibilità di SQL Server in due modi: come storage per file di dati attivi e come testimone della condivisione di file SMB.
Per informazioni su come ridurre la complessità e i costi di esecuzione delle distribuzioni FCI di SQL Server utilizzando FSx per Windows File Server, consulta il post sul blog Semplifica le [distribuzioni ad alta disponibilità di Microsoft SQL Server usando FSx Amazon](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) for Windows File Server. Il post sul blog fornisce anche step-by-step istruzioni per la distribuzione di SQL Server FCIs utilizzando un file system Amazon FSx Multi-AZ come soluzione di storage condiviso. Per ulteriori informazioni, consulta la documentazione di [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html).
## Usare Amazon FSx per NetApp ONTAP
Amazon FSx for NetApp ONTAP è un servizio completamente gestito che fornisce uno storage di file altamente affidabile, scalabile, ad alte prestazioni e ricco di funzionalità basato sul file system ONTAP. NetApp FSx per ONTAP combina le caratteristiche, le prestazioni, le capacità e le operazioni API familiari dei NetApp file system con l'agilità, la scalabilità e la semplicità di un servizio completamente gestito. AWS
FSx for ONTAP fornisce l'accesso multiprotocollo ai dati tramite i protocolli NFS, SMB e iSCSI per sistemi Windows e Linux. Puoi creare un'architettura SQL Server Always On FCI ad alta disponibilità, come spiegato in dettaglio nel post del blog [SQL Server High Availability Deployments Using Amazon FSx ](https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-high-availability-amazon-fsx-for-netapp-ontap/) for ONTAP. NetApp FSx for ONTAP può anche fornire un modo rapido per eseguire il failover dell'ambiente SQL Server Regione AWS in un altro ambiente al fine di soddisfare i requisiti RTO (Recovery Time Objective) e RPO (Recovery Point Objective). Per ulteriori informazioni, consulta il post di blog [Implementazione di HA e DR per un'istanza di cluster di failover di SQL Server Always-On utilizzando](https://aws.amazon.com/blogs/storage/implementing-ha-and-dr-for-sql-server-always-on-failover-cluster-instance-using-amazon-fsx-for-netapp-ontap/) per ONTAP. FSx
È inoltre possibile utilizzare AWS Launch Wizard per distribuire soluzioni SQL Server su AWS, con supporto per gruppi di disponibilità Always On e distribuzioni a nodo singolo. Launch Wizard supporta la distribuzione di SQL Server Always on FCIs su Amazon EC2 con ONTAP come FSx storage condiviso. Questo servizio consente di risparmiare tempo e fatica sostituendo un complesso processo di distribuzione manuale con una procedura guidata basata su console che accelera la migrazione dei carichi di lavoro SQL Server locali che si basano sullo storage condiviso. Per ulteriori informazioni su come Launch Wizard può aiutarti a effettuare il provisioning e configurare SQL Server FCIs in poche ore, consulta il post del blog [Simplify SQL Server Always On deployments with](https://aws.amazon.com/blogs/storage/simplify-sql-server-always-on-deployments-with-the-aws-launch-wizard-and-amazon-fsx/) and Amazon. AWS Launch Wizard FSx Launch Wizard supporta anche la distribuzione per SQL Server Always On FCIs utilizzando [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) come soluzione di storage condiviso.
## Utilizzo di soluzioni offerte dai partner AWS
+ [SIOS DataKeeper](https://us.sios.com/) fornisce supporto per il failover dei cluster ad alta disponibilità in tutte Regioni AWS le zone di disponibilità. SIOS DataKeeper è disponibile in. [Marketplace AWS](https://aws.amazon.com/marketplace/seller-profile?id=3c91e2f7-fc8d-4cce-a8aa-1e37abcb4408)
+ [DxEnterprise](https://dh2i.com/dxenterprise-high-availability/)from DH2i consente il failover completamente automatico dei gruppi di disponibilità di SQL Server in Kubernetes e il failover unificato delle istanze per Windows e Linux. [Marketplace AWS](https://aws.amazon.com/marketplace/seller-profile?id=4e97d4b7-3366-42fd-8be8-732d38c9e24b)D2HI è disponibile in.
# FSx per Windows File Server
FSx per Windows File Server fornisce uno storage di file completamente gestito, altamente affidabile e scalabile, accessibile tramite il protocollo Server Message Block (SMB). È basato su Windows Server e offre un'ampia gamma di funzionalità amministrative come quote utente, ripristino dei file per l'utente finale e integrazione con Microsoft Active Directory (AD). Offre opzioni di implementazione Single-AZ e Multi-AZ, backup completamente gestiti e crittografia dei dati a riposo e in transito. È possibile ottimizzare costi e prestazioni per i carichi di lavoro con le opzioni di archiviazione su unità a stato solido (SSD) e unità disco rigido (HDD), nonché scalare lo storage e modificare le prestazioni di throughput del file system in qualsiasi momento. Lo storage di FSx file Amazon è accessibile da istanze di calcolo Windows e Linux in esecuzione in locale AWS e in locale.
Amazon FSx semplifica la distribuzione di storage Windows condiviso per distribuzioni SQL Server ad alta disponibilità grazie al supporto per condivisioni di file a disponibilità continua (CA) e file system di dimensioni ridotte. Questa opzione è adatta per questi casi d'uso:
+ Come storage condiviso utilizzato dai nodi di SQL Server in un'istanza WSFC.
+ Come testimone della condivisione di file SMB che può essere utilizzato con qualsiasi cluster SQL Server con WSFC.
Amazon FSx offre prestazioni veloci con un throughput di base fino a 2 GB/second per file system, centinaia di migliaia di IOPS e latenze costanti inferiori al millisecondo.
Per fornire le prestazioni giuste per le tue istanze SQL, puoi scegliere un livello di throughput indipendente dalla dimensione del file system. Livelli più elevati di capacità di throughput si accompagnano anche a livelli più elevati di IOPS che il file server può fornire alle istanze di SQL Server che vi accedono.
La capacità di archiviazione determina non solo la quantità di dati che è possibile archiviare, ma anche il numero di IOPS che è possibile eseguire sullo storage. Ogni gigabyte di storage fornisce 3 IOPS. È possibile effettuare il provisioning di ogni file system in modo che abbia una dimensione massima di 64 TB.
Per informazioni sulla configurazione e l'utilizzo di Amazon FSx per ridurre la complessità e i costi delle distribuzioni ad alta disponibilità di SQL Server, consulta Semplifica [le distribuzioni ad alta disponibilità di Microsoft SQL Server utilizzando FSx per Windows File Server sul](https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/) blog Storage. AWS Per ulteriori informazioni sulla creazione di una nuova condivisione CA, consulta la documentazione di Windows File [FSx Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/managing-file-shares.html#create-ca-share).
# Ripristino di emergenza
Molte organizzazioni implementano l'alta disponibilità per i propri database SQL Server, ma ciò non è sufficiente per le organizzazioni che richiedono una vera resilienza IT. Si consiglia di implementare una soluzione di disaster recovery per evitare la perdita di dati e i tempi di inattività dei database mission-critical. L'adozione di un'architettura di disaster recovery multiregionale per le distribuzioni di SQL Server consente di:
+ Raggiungere la continuità aziendale
+ Migliora la latenza per la tua base clienti distribuita geograficamente
+ Soddisfa i requisiti normativi e di revisione
Le opzioni per il disaster recovery includono [log shipping](ec2-log-shipping.md), [gruppi di disponibilità Always On](ec2-always-on.md), [snapshot Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html) archiviati in Amazon S3 e replicati AWS tra regioni[, istanze cluster Always On Failover FCIs (](ec2-fci.md)) combinate con gruppi di disponibilità Always On e gruppi di disponibilità distribuiti.
## Gruppi di disponibilità distribuiti
Un'architettura con gruppi di disponibilità distribuiti è un approccio ottimale per la distribuzione di SQL Server in più regioni. Un gruppo di disponibilità distribuito è un tipo speciale di gruppo di disponibilità che si estende su due gruppi di disponibilità separati. È possibile considerarlo come un gruppo di disponibilità di gruppi di disponibilità. I gruppi di disponibilità sottostanti sono configurati su due diversi cluster WSFC.
I gruppi di disponibilità distribuiti sono liberamente accoppiati, il che significa che non richiedono un singolo cluster WSFC e sono gestiti da SQL Server. Poiché i cluster WSFC vengono gestiti singolarmente e le trasmissioni sono principalmente asincrone tra due gruppi di disponibilità, è più semplice configurare il disaster recovery in un altro sito. Le repliche primarie di ogni gruppo di disponibilità sincronizzano le proprie repliche secondarie.
Al momento, i gruppi di disponibilità distribuiti supportano solo il failover manuale. Per garantire che nessun dato vada perso, interrompi tutte le transazioni sui database primari globali (ovvero sui database del gruppo di disponibilità primario). Quindi imposta il gruppo di disponibilità distribuita sul commit sincrono.