I gruppi di disponibilità Always On (AG) di Microsoft SQL Server consentono di replicare i database in più istanze SQL Server Enterprise.

Analogamente alle istanze del cluster di failover di SQL Server, i gruppi di disponibilità Always On utilizzano il clustering di failover di Windows Server (WSFC) per implementare l'alta affidabilità. Tuttavia, le due funzionalità differiscono per vari aspetti, tra cui:

	Gruppi di disponibilità Always On	Istanze del cluster di failover
Ambito del failover	Gruppo di database	Istanza
Archiviazione	Non condiviso	Condiviso

Per un confronto più dettagliato, vedi Confronto tra le istanze del cluster di failover e i gruppi di disponibilità.

I gruppi di disponibilità Always On supportano più modalità di disponibilità. Questo tutorial mostra come eseguire il deployment di gruppi di disponibilità Always On in modalità commit sincrono per implementare l'alta affidabilità per uno o più database.

Durante la configurazione, creerai tre istanze VM. Due istanze VM, node-1 e node-2, fungono da nodi di cluster ed eseguono SQL Server. Una terza istanza VM, witness, viene utilizzata per raggiungere un quorum in uno scenario di failover. Le tre istanze VM sono distribuite su tre zone e condividono una subnet comune.

Utilizzando un gruppo di disponibilità Always On di SQL Server, un database di esempio, bookshelf, viene replicato in modalità sincrona sulle due istanze SQL Server.

In un ambiente di clustering di failover di Windows Server on-premise, gli annunci ARP attivano il failover dell'indirizzo IP. Google Cloud, tuttavia, ignora gli annunci ARP. Di conseguenza, devi implementare una delle due opzioni seguenti: utilizzare un bilanciatore del carico interno e un nome di rete distribuito (DNN). L'articolo presuppone che tu abbia già eseguito il deployment di Active Directory su Google Cloud e che tu abbia conoscenze di base di SQL Server, Active Directory e Compute Engine. Per saperne di più su Active Directory su Google Cloud, consulta la sezione Inizia