Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server)

Questo argomento descrive le considerazioni per la distribuzione di gruppi di disponibilità AlwaysOn, inclusi prerequisiti, restrizioni e consigli per computer host, cluster WSFC (Windows Server Failover Clustering), istanze del server e gruppi di disponibilità. Per ognuno di questi componenti sono indicate le eventuali considerazioni sulla sicurezza e le autorizzazioni richieste.

Hotfix .NET che supportano i gruppi di disponibilità AlwaysOn

A seconda dei componenti e delle funzionalità di SQL Server 2014 che verranno usati con i gruppi di disponibilità AlwaysOn, potrebbe essere necessario installare aggiornamenti rapidi .NET aggiuntivi identificati nella tabella seguente. Gli hotfix possono essere installati in qualsiasi ordine.

	Funzionalità dipendente	Aggiornamento rapido	Collega
	Reporting Services	L'hotfix per .NET 3.5 SP1 aggiunge il supporto a SQL Client per le funzionalità AlwaysOn di finalità di lettura, readonly e multisubnetfailover. L'hotfix deve essere installato in ogni server di report di Reporting Services.	KB 2654347: hotfix per .NET 3.5 SP1 per aggiungere il supporto per le funzionalità AlwaysOn

Indicazioni e requisiti di sistema di Windows

Elenco di controllo: requisiti (sistema Windows)

Per supportare la funzionalità Gruppi di disponibilità AlwaysOn, assicurarsi che ogni computer che partecipi a uno o più gruppi di disponibilità soddisfi i requisiti fondamentali seguenti:

	Requisito	Collega
	Assicurarsi che il sistema non sia un controller di dominio.	I gruppi di disponibilità non sono supportati nei controller di dominio.
	Assicurarsi che in ogni computer sia eseguita la versione x86 (non WOW64) o x64 di Windows Server 2008 o successive.	WOW64 (Windows 32 bit in Windows 64 bit) non supporta i gruppi di disponibilità AlwaysOn.
	Assicurarsi che ogni computer sia un nodo in un cluster WSCF (Windows Server Failover Clustering).	WSFC (Windows Server Failover Clustering) con SQL Server
	Assicurarsi che nel cluster WSFC siano contenuti nodi sufficienti per supportare le configurazioni dei gruppi di disponibilità.	Un nodo WSFC può ospitare solo una replica di disponibilità per un gruppo di disponibilità specifico. In un determinato nodo WSFC una o più istanze di SQL Server possono ospitare repliche di disponibilità per molti gruppi di disponibilità. Chiedere agli amministratori del database il numero di nodi WSFC necessario per supportare le repliche di disponibilità dei gruppi di disponibilità pianificati. Panoramica dei gruppi di disponibilità AlwaysOn (SQL Server).
	Assicurarsi che tutti gli hotfix di Windows applicabili siano stati installati in ogni nodo nel cluster WSFC.	** Importante ** Sono necessari o consigliati numerosi hotfix per i nodi di un cluster WSFC in cui vengono distribuiti i gruppi di disponibilità AlwaysOn. Per altre informazioni, vedere Hotfix di Windows che supportano i gruppi di disponibilità AlwaysOn (sistema Windows), più avanti in questa sezione.

Hotfix di Windows che supportano i gruppi di disponibilità AlwaysOn (sistema Windows)

A seconda della topologia del cluster, potrebbero essere applicabili diversi hotfix aggiuntivi di Windows Server 2008 Service Pack 2 (SP2) o Windows Server 2008 R2 per supportare i gruppi di disponibilità AlwaysOn. Nella tabella seguente vengono identificati questi hotfix. Gli hotfix possono essere installati in qualsiasi ordine.

	Si applica a Windows 2008 SP2	Si applica a Windows 2008 R2 SP1	Incluso in Windows 2012	Per supportare...	Aggiornamento rapido	Collega
	Sì	Sì	Sì	Configurazione del quorum WSFC ottimale	In ogni nodo WSFC assicurarsi che sia installato l'hotfix descritto nell'articolo della Knowledge Base 2494036. Questo hotfix supporta la configurazione del quorum ottimale con le destinazioni di failover non automatico. Questa funzionalità consente di migliorare i cluster multisito permettendo di selezionare a quali nodi è associata la possibilità di votare.	KB 2494036: articolo relativo alla disponibilità di un hotfix per configurare un nodo del cluster che non presenta voti quorum in Windows Server 2008 e Windows Server 2008 R2 Per informazioni sul voto quorum, vedere Modalità quorum WSFC e configurazione del voto (SQL Server)
	Sì	Sì	Sì	Uso più efficiente della larghezza di banda di rete	In ogni nodo WSFC assicurarsi che sia installato l'hotfix descritto nell'articolo della Knowledge Base 2616514. Senza questo hotfix, il servizio Cluster invia notifiche del Registro di sistema non necessarie tra nodi del cluster. Questo comportamento limita la larghezza di banda di rete, un problema grave per i gruppi di disponibilità AlwaysOn.	KB 2616514: articolo della Knowledge Base relativo al servizio cluster tramite cui si inviano notifiche di modifiche alla chiave del Registro di sistema non necessarie tra nodi del cluster in Windows Server 2008 o in Windows Server 2008 R2
		Sì	Non applicabile	Test di archiviazione VPD su dischi non disponibili per tutti i nodi WSFC	Se in un nodo WSFC è in esecuzione Windows Server 2008 R2 Service Pack 1 (SP1) e si verifica un errore del test di archiviazione Convalida VPD (Vital Product Data) dispositivi SCSI dopo un'esecuzione non corretta nei dischi che sono online e non disponibili a tutti i nodi nel cluster WSFC, installare l'hotfix descritto nell'articolo della Knowledge Base 2531907. Con questo hotfix è possibile evitare avvisi o errori non corretti nel report di convalida quando i dischi sono online.	KB 2531907: articolo relativo all'errore del test Convalida VPD (Vital Product Data) dispositivi SCSI dopo l'installazione di Windows Server 2008 R2 SP1
		Sì	Sì	Failover più rapido nelle repliche locali	Se in un nodo WSFC è in esecuzione Windows Server 2008 R2 Service Pack 1 (SP1), assicurarsi che sia installato l'hotfix descritto nell'articolo della Knowledge Base 2687741. Questo hotfix migliora le prestazioni del failover dei gruppi di disponibilità AlwaysOn nelle repliche locali.	KB 2687741: articolo relativo alla disponibilità di un hotfix che consente di migliorare le prestazioni della funzionalità "Gruppo di disponibilità AlwaysOn" in SQL Server 2012 per Windows Server 2008 R2
	Sì	Sì	Sì	Archiviazione asimmetrica per istanze del cluster di failover	Se un'istanza del cluster di failover verrà abilitata per i gruppi di disponibilità AlwaysOn, installare l'hotfix di Windows Server 2008 976097. Questo hotfix consente allo snap-in Microsoft Management Console (MMC) di gestione del cluster di failover di supportare dischi condivisi con archiviazione asimmetrica disponibili solo in alcuni nodi WSFC.	KB 976097: articolo relativo all'hotfix per aggiungere supporto per archiviazioni asimmetriche allo snap-in MMC di Gestione del cluster di failover per un cluster di failover in cui è in esecuzione Windows Server 2008 o Windows Server 2008 R2 Guida all'architettura AlwaysOn: Creazione di una soluzione di disponibilità elevata e ripristino di emergenza tramite istanze del cluster di failover e gruppi di disponibilità
	Sì	Sì	Non applicabile	Internet Protocol Security (IPsec)	Se nell'ambiente si utilizzano connessioni IPSec, è possibile che si verifichi un ritardo prolungato (circa due o tre minuti) quando viene ristabilita la connessione IPSec da un computer client a un nome di rete virtuale (in questo contesto, per connettersi al listener del gruppo di disponibilità). Se si utilizzano le connessioni IPSec, è consigliabile rivedere gli scenari specifici descritti in dettaglio nell'articolo della Knowledge Base 980915:	KB 980915: articolo della Knowledge Base relativo al ritardo prolungato quando si riconnette una connessione IPSec da un computer in cui è in esecuzione Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 o Windows Server 2008 R2
	Sì	Sì	Sì	IPv6	Se si utilizza IPv6, è consigliabile rivedere gli scenari specifici descritti in dettaglio nell'articolo della Knowledge Base 2578103 o 2578113, a seconda del sistema operativo Windows Server: Se nella topologia Windows Server si utilizza IP versione 6 (IPv6), per il servizio cluster WSFC sono necessari circa 30 secondi per l'esecuzione del failover dell'indirizzo IP IPv6. Di conseguenza i client attenderanno circa 30 secondi per la riconnessione all'indirizzo IP IPv6.	KB 2578103 (Windows Server 2008): articolo relativo al servizio cluster che richiede circa 30 secondi per eseguire il failover degli indirizzi IP IPv6 in Windows Server 2008 KB 2578113 (Windows Server 2008 R2): Windows Server 2008 R2: Il servizio cluster richiede circa 30 secondi per eseguire il failover degli indirizzi IP IPv6 in Windows Server 2008 R2
	Sì	Sì	Sì	Nessun router tra cluster e server applicazioni	Se non esiste alcun router tra il cluster di failover e il server applicazioni, il failover del servizio cluster sulle risorse correlate alla rete avviene lentamente. In questo modo, le connessioni client vengono ritardate dopo il failover di un gruppo di disponibilità. In assenza di un router, è consigliabile rivedere gli scenari specifici descritti in dettaglio nell'articolo della Knowledge Base 2582281 e installare l'hotfix, se applicabile per l'ambiente.	KB 2582281: articolo della Knowledge Base relativo al failover lento se non esiste alcun router tra il cluster e un server applicazioni

Indicazioni per computer in cui sono ospitate repliche di disponibilità (sistema Windows)

• Sistemi simili: per un gruppo di disponibilità specificato, tutte le repliche di disponibilità devono essere eseguite in sistemi simili in grado di gestire carichi di lavoro identici.

• Schede di rete dedicate: per ottenere prestazioni ottimali, usare una scheda di rete dedicata (scheda di interfaccia di rete) per i gruppi di disponibilità AlwaysOn.

• Spazio su disco sufficiente: in ogni computer in cui una replica di disponibilità è ospitata da un'istanza del server deve essere disponibile spazio su disco sufficiente per tutti i database nel gruppo di disponibilità. Tenere presente che, con l'aumentare delle dimensioni dei database primari, i database secondari corrispondenti aumentano di conseguenza.

Autorizzazioni (sistema Windows)

Per amministrare un cluster WSFC, l'utente deve essere un amministratore di sistema in ogni nodo del cluster.

Per altre informazioni sull'account per l'amministrazione del cluster, vedere Appendice A: Requisiti di un cluster di failover.

Attività correlate (sistema Windows)

Modificare HostRecordTTL (tramite Windows PowerShell)

1. Aprire la finestra di PowerShell con Esegui come amministratore.

2. Importare il modulo FailoverClusters.

3. Utilizzare li cmdlet Get-ClusterResource per cercare la risorsa nome di rete, quindi utilizzare il cmdlet Set-ClusterParameter per impostare il valore HostRecordTTL, come segue:

   Get-ClusterResource "<NetworkResourceName>>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

   Nell'esempio di PowerShell seguente impostare HostRecordTTL su 300 secondi per una risorsa nome di rete denominata "SQL Network Name (SQL35)".

   Import-Module FailoverClusters  
   
   $nameResource = "SQL Network Name (SQL35)"  
   Get-ClusterResource $nameResource | Set-ClusterParameter ClusterParameter HostRecordTTL 300  
   

   Suggerimento

   Ogni volta che viene aperta una nuova finestra di PowerShell, è necessario importare il modulo FailoverClusters.

Contenuto correlato (PowerShell)

• Clustering and High-Availability (Failover Clustering and Network Load Balancing Team Blog) (Clustering e disponibilità elevata - Blog del team di clustering di failover e bilanciamento del carico di rete)

• Introduzione a Windows PowerShell in un cluster di failover

• Comandi di risorse cluster e cmdlet di Windows PowerShell equivalenti

Contenuto correlato (sistema Windows)

• Pagina relativa alla configurazione delle impostazioni DNS in un cluster di failover multisito

• Post sulla registrazione DNS con la risorsa del nome di rete

• Clustering multisito di failover di Windows 2008 R2

Prerequisiti e restrizioni dell'istanza di SQL Server

Per ogni gruppo di disponibilità è richiesto un set di partner di failover, noti come repliche di disponibilità, ospitati da istanze di SQL Server. Un'istanza del server specifica può essere un'istanza autonoma o un'istanza del cluster di failover (FCI) di SQL Server.

Elenco di controllo: prerequisiti (istanza del server)

	Prerequisito	Collegamenti
	Il computer host deve essere un nodo WSFC (Windows Server Failover Clustering). Le istanze di SQL Server che ospitano repliche di disponibilità per un determinato gruppo di disponibilità devono risiedere in nodi separati di un singolo cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster WSFC, un gruppo di disponibilità può risiedere temporaneamente in due cluster.	WSFC (Windows Server Failover Clustering) con SQL Server Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)
	Se si desidera che in un gruppo di disponibilità venga utilizzato Kerberos: In tutte le istanze del server in cui è ospitata una replica di disponibilità per il gruppo di disponibilità deve essere utilizzato lo stesso account del servizio SQL Server. L'amministratore di dominio deve registrare manualmente un nome dell'entità servizio (SPN, Service Principal Name) con Active Directory nell'account del servizio SQL Server per il nome di rete virtuale del listener del gruppo di disponibilità. Se il nome SPN è registrato in un account diverso da quello del servizio SQL Server, l'autenticazione non verrà completata. **Importante** Se si modifica l'account del servizio SQL Server, l'amministratore di dominio dovrà registrare di nuovo manualmente il nome SPN.	Registrazione di un nome dell'entità servizio per le connessioni Kerberos Breve spiegazione: A Kerberos e ai nomi SPN viene applicata l'autenticazione reciproca. Tramite il nome SPN viene eseguito il mapping all'account di Windows mediante il quale vengono avviati i servizi SQL Server. Se la registrazione del nome SPN non viene eseguita correttamente o presenta un errore, tramite il livello di sicurezza di Windows non è possibile determinare l'account associato al nome SPN e l'autenticazione Kerberos non può essere utilizzata. Nota: NTLM non presenta questo requisito.
	Se si intende utilizzare un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, assicurarsi di aver compreso le restrizioni su questo tipo di istanza e che vengano soddisfatti i relativi requisiti.	Prerequisiti e requisiti sull'utilizzo di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità , più avanti in questo argomento.
	Ogni istanza del server deve eseguire il edizione Enterprise di SQL Server 2014.	Funzionalità supportate dalle edizioni di SQL Server 2014
	In tutte le istanze del server in cui sono ospitate repliche di disponibilità per un gruppo di disponibilità devono essere utilizzate le stesse regole di confronto di SQL Server.	Impostazione o modifica di regole di confronto del server
	Abilitare la funzionalità Gruppi di disponibilità AlwaysOn in ogni istanza del server che ospiterà una replica di disponibilità per qualsiasi gruppo di disponibilità. In un determinato computer è possibile abilitare il numero di istanze del server per i gruppi di disponibilità AlwaysOn supportati dall'installazione di SQL Server.	Abilitare e disabilitare i gruppi di disponibilità AlwaysOn (SQL Server) ** Importante ** Se si elimina e si ricrea un cluster WSFC, è necessario disabilitare e riabilitare la funzionalità Gruppi di disponibilità AlwaysOn in ogni istanza del server abilitata per i gruppi di disponibilità AlwaysOn nel cluster WSFC originale.
	Per ogni istanza del server è necessario un endpoint del mirroring del database. Si noti che questo endpoint è condiviso da tutte le repliche di disponibilità, dai partner di mirroring di database, nonché dai server di controllo nell'istanza del server. Se un'istanza del server selezionata come host per una replica di disponibilità è in esecuzione in un account utente di dominio e non dispone ancora di un endpoint del mirroring del database, tramite la Creazione guidata Gruppo di disponibilità (o Procedura guidata Aggiungi replica a gruppo di disponibilità) è possibile creare l'endpoint e concedere l'autorizzazione CONNECT all'account del servizio dell'istanza del server. Se, tuttavia, il servizio SQL Server viene eseguito come account predefinito, ad esempio Sistema locale, Servizio locale o Servizio di rete, oppure come account non di dominio, è necessario usare certificati per l'autenticazione degli endpoint e non sarà possibile creare un endpoint di mirroring del database nell'istanza del server tramite la procedura guidata. In tal caso, è consigliabile creare manualmente gli endpoint del mirroring del database prima di avviare la procedura guidata. ** Nota sulla sicurezza ** La sicurezza del trasporto per i gruppi di disponibilità AlwaysOn è identica a quella per il mirroring del database.	Endpoint del mirroring del database (SQL Server) Sicurezza del trasporto per il mirroring del database e gruppi di disponibilità AlwaysOn (SQL Server)
	Se tutti i database in cui è utilizzato FILESTREAM saranno aggiunti a un gruppo di disponibilità, verificare che FILESTREAM sia abilitato in ogni istanza del server in cui sarà ospitata una replica di disponibilità per il gruppo di disponibilità.	Abilitare e configurare FILESTREAM
	Se tutti i database indipendenti saranno aggiunti a un gruppo di disponibilità, verificare che l'opzione del server contained database authentication sia impostata su 1 in ogni istanza del server in cui sarà ospitata una replica di disponibilità per il gruppo di disponibilità.	Opzione di configurazione del server contained database authentication Opzioni di configurazione del server (SQL Server)

Utilizzo del thread da parte dei gruppi di disponibilità

I gruppi di disponibilità AlwaysOn hanno i requisiti seguenti per i thread di lavoro:

• In un'istanza inattiva di SQL Server, i gruppi di disponibilità AlwaysOn usano 0 thread.

• Il numero massimo di thread utilizzato dai gruppi di disponibilità è dato dall'impostazione configurata per il numero massimo di thread del server ("max worker threads") meno 40.

• Nelle repliche di disponibilità ospitate in un'istanza del server specificata viene condiviso un singolo pool di thread.

  I thread vengono condivisi su richiesta, come riportato di seguito:

  • In genere, sono presenti 3-10 thread condivisi, tuttavia questo numero può aumentare a seconda del carico di lavoro della replica primaria.

  • Se un thread specificato è inattivo per un certo periodo di tempo, viene rilasciato nuovamente nel pool di thread generale di SQL Server. In genere, un thread inattivo viene rilasciato dopo ~15 secondi di inattività. Tuttavia, a seconda dell'ultima attività, un thread inattivo potrebbe essere mantenuto più a lungo.

• Inoltre, nei gruppi di disponibilità vengono utilizzati thread non condivisi, come riportato di seguito:

  • In ogni replica primaria viene utilizzato 1 thread di acquisizione del log per ogni database primario. Inoltre, viene utilizzato 1 thread di invio del log per ogni database secondario. I thread di invio del log vengono rilasciati dopo ~15 secondi di inattività.

  • In ogni replica secondaria viene utilizzato 1 thread della fase di rollforward per ogni database secondario. I thread della fase di rollforward vengono rilasciati dopo ~15 secondi di inattività.

  • Tramite un backup di una replica secondaria un thread viene mantenuto nella replica primaria per la durata dell'operazione di backup.

Per altre informazioni, vedere AlwaysON - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (Serie di apprendimento AlwaysON - HADRON: Utilizzo del pool di lavoro per i database abilitati a HADRON) (blog sui tecnici di SQL Server CSS).

Autorizzazioni (istanza del server)

Attività correlate (istanza del server)

Contenuto correlato (istanza del server)

• Serie di apprendimento AlwaysON - HADRON: Utilizzo del pool di lavoro per i database abilitati per HADRON

Consigli sulla connettività di rete

Si consiglia di utilizzare gli stessi collegamenti di rete per le comunicazioni tra membri del cluster WSFC e le comunicazioni tra repliche di disponibilità. L'utilizzo di collegamenti di rete separati può provocare comportamenti imprevisti in caso di errore di alcuni collegamenti (anche in modo intermittente).

Ad esempio, affinché un gruppo di disponibilità supporti il failover automatico, lo stato della replica secondaria che è partner di failover automatico deve essere SYNCHRONIZED. In caso di errore di collegamento di rete a questa replica secondaria (anche in modo intermittente), lo stato della replica diventa UNSYNCHRONIZED e non sarà possibile cominciare la risincronizzazione fino a quando non viene ripristinato il collegamento. Se per il cluster WSFC è richiesto un failover automatico mentre la replica secondaria non è sincronizzata, il failover automatico non si verificherà.

Supporto della connettività client

Per informazioni sul supporto dei gruppi di disponibilità AlwaysOn per la connettività client, vedere Connettività client AlwaysOn (SQL Server).

Prerequisiti e restrizioni per l'utilizzo di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità

Restrizioni (istanze del cluster di failover)

• I nodi del cluster di un'istanza del cluster di failover possono ospitare solo una replica per un gruppo di disponibilità specificato: se si aggiunge una replica di disponibilità in un'istanza del cluster di failover, i nodi del cluster WSFC che sono i possibili proprietari dell'istanza del cluster di failover non possono ospitare un'altra replica per lo stesso gruppo di disponibilità.

  Inoltre, tutte le altre repliche devono essere ospitate da un'istanza di SQL Server 2012 che risiede in un nodo WSFC diverso nello stesso cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster WSFC, un gruppo di disponibilità può risiedere temporaneamente in due cluster.

• Le istanze del cluster di failover non supportano il failover automatico da gruppi di disponibilità: le istanze del cluster di failover non supportano il failover automatico da gruppi di disponibilità, pertanto qualsiasi replica di disponibilità ospitata da un'istanza del cluster di failover può essere configurata solo per il failover manuale.

• Modifica del nome di rete di un'istanza del cluster di failover: se è necessario modificare il nome di rete di un'istanza del cluster di failover che ospita una replica di disponibilità, è necessario rimuovere la replica dal relativo gruppo di disponibilità e riaggiungerla successivamente a questo gruppo. Non è possibile rimuovere la replica primaria, pertanto se si rinomina un'istanza del cluster di failover in cui è ospitata la replica primaria, è consigliabile eseguire il failover in una replica secondaria e successivamente rimuovere e poi riaggiungere la prima replica primaria. Si noti che la ridenominazione di un'istanza del cluster di failover può comportare la modifica dell'URL del relativo endpoint del mirroring del database. Quando si aggiunge la replica assicurarsi di specificare l'URL dell'endpoint corrente.

Elenco di controllo: prerequisiti (istanze del cluster di failover)

	Prerequisito	Collega
	Prima di utilizzare un'istanza del cluster di failover per ospitare una replica di disponibilità, assicurarsi che l'amministratore di sistema abbia installato l'hotfix per Windows Server 2008 descritto nell'articolo della Knowledge Base KB 976097. Questo hotfix consente allo snap-in Microsoft Management Console (MMC) di gestione del cluster di failover di supportare dischi condivisi con archiviazione asimmetrica disponibili solo in alcuni nodi WSFC.	KB 976097: articolo relativo all'hotfix per aggiungere supporto per archiviazioni asimmetriche allo snap-in MMC di Gestione del cluster di failover per un cluster di failover in cui è in esecuzione Windows Server 2008 o Windows Server 2008 R2
	Assicurarsi che in ogni istanza del cluster di failover di SQL Server sia disponibile l'archiviazione condivisa necessaria in base all'installazione dell'istanza del cluster di failover di SQL Server standard.

Attività correlate (istanze del cluster di failover)

Contenuto correlato (istanze del cluster di failover)

• Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)

• Guida all'architettura AlwaysOn: Creazione di una soluzione di disponibilità elevata e ripristino di emergenza tramite istanze del cluster di failover e gruppi di disponibilità

Prerequisiti e restrizioni dei gruppi di disponibilità

Restrizioni (gruppi di disponibilità)

• Le repliche di disponibilità devono essere ospitate da nodi diversi di un cluster WSFC: per un gruppo di disponibilità specificato, le repliche di disponibilità devono essere ospitate da istanze del server in esecuzione in nodi diversi dello stesso cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster WSFC, un gruppo di disponibilità può risiedere temporaneamente in due cluster.

  Nota

  In ogni macchina virtuale presente nello stesso computer fisico può essere ospitata una replica di disponibilità per lo stesso gruppo di disponibilità, in quanto ogni macchina virtuale costituisce un computer distinto.

• Nome univoco del gruppo di disponibilità: ogni nome di gruppo di disponibilità deve essere univoco nel cluster WSFC. La lunghezza massima consentita per il nome del gruppo di disponibilità è 128 caratteri.

• Repliche di disponibilità: ogni gruppo di disponibilità supporta una replica primaria e fino a otto repliche secondarie. È possibile eseguire tutte le repliche in modalità con commit asincrono oppure fino a un massimo di tre in modalità con commit sincrono (una replica primaria con due repliche secondarie sincrone).

• Numero massimo di gruppi di disponibilità e database di disponibilità per computer: il numero effettivo di database e gruppi di disponibilità che è possibile creare in un computer fisico o in una VM dipende dall'hardware e dal carico di lavoro, tuttavia non esiste un limite imposto. Microsoft ha eseguito test estensivi con 10 gruppi di disponibilità e 100 database per computer fisico. I segnali di sistemi di overload possono includere, a titolo esemplificativo, l'esaurimento del thread di lavoro, tempi di risposta lenti per visualizzazioni di sistema AlwaysOn e DMV e/o dump del sistema dispatcher bloccati. Assicurarsi di testare completamente l'ambiente con un carico di lavoro simile a quello di produzione per assicurare che possa gestire capacità di carico di lavoro di picco all'interno del contratto sul livello di servizio dell'applicazione. Per i contratti sul livello di servizio occorre considerare il carico in condizioni di errore e i tempi di risposta previsti.

• Non utilizzare Gestione cluster di failover per modificare i gruppi di disponibilità:

  Ad esempio:

  • Non modificare le proprietà del gruppo di disponibilità, ad esempio i possibili proprietari.

  • Non utilizzare Gestione cluster di failover per eseguire il failover dei gruppi di disponibilità. È necessario usare Transact-SQL o SQL Server Management Studio.

Prerequisiti (gruppi di disponibilità)

Quando si crea o riconfigura una configurazione del gruppo di disponibilità, assicurarsi che si soddisfino i requisiti seguenti.

	Prerequisito	Descrizione
	Se si intende utilizzare un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, assicurarsi di aver compreso le restrizioni su questo tipo di istanza e che vengano soddisfatti i relativi requisiti.	Prerequisiti e restrizioni per l'uso di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità , precedentemente in questo argomento.

Sicurezza (gruppi di disponibilità)

• La sicurezza viene ereditata dal cluster WSCF (Windows Server Failover Clustering). WSFC fornisce due livelli di sicurezza utente con granularità di API del cluster WSFC intere:

  • Accesso di sola lettura

  • Controllo completo

    I gruppi di disponibilità AlwaysOn devono avere il controllo completo e l'abilitazione dei gruppi di disponibilità AlwaysOn in un'istanza di SQL Server offre il controllo completo del cluster WSFC (tramite SID del servizio).

    Non è possibile aggiungere o rimuovere direttamente la sicurezza per un'istanza del server in Gestione cluster di failover di WSFC. Per gestire le sessioni di sicurezza WSFC, usare il Gestione configurazione SQL Server o l'equivalente WMI di SQL Server.

• Ogni istanza di SQL Server deve disporre delle autorizzazioni per accedere al Registro di sistema, al cluster e al soforth.

• È consigliabile usare la crittografia per le connessioni tra istanze del server che ospitano repliche di disponibilità dei gruppi di disponibilità AlwaysOn.

Autorizzazioni (gruppi di disponibilità)

Attività correlate (gruppi di disponibilità)

Prerequisiti e restrizioni dei database di disponibilità

Per essere idoneo a essere aggiunto a un gruppo di disponibilità, un database deve soddisfare i prerequisiti e le restrizioni riportate di seguito.

Elenco di controllo: requisiti (database di disponibilità)

Per essere idoneo a essere aggiunto a un gruppo di disponibilità, un database deve soddisfare i requisiti seguenti:

	Requisiti	Collega
	Deve trattarsi di un database utente. I database di sistema non possono appartenere a un gruppo di disponibilità.
	Deve trovarsi nell'istanza di SQL Server in cui si crea il gruppo di disponibilità e deve essere accessibile all'istanza del server.
	Deve trattarsi di un database di lettura/scrittura. I database di sola lettura non possono essere aggiunti a un gruppo di disponibilità.	sys.databases (is_read_only = 0)
	Deve trattarsi di un database multiutente.	sys.databases (user_access = 0)
	Non deve essere utilizzato AUTO_CLOSE.	sys.databases (is_auto_close_on = 0)
	Utilizzare il modello di recupero con registrazione completa (noto anche come modalità di recupero con registrazione completa).	sys.databases (recovery_model = 1)
	Deve disporre di almeno un backup completo del database. Nota: dopo aver impostato un database sulla modalità di recupero con registrazione completa, è necessario un backup completo per iniziare la catena di log del recupero con registrazione completa.	Creare un backup completo del database (SQL Server)
	Non deve appartenere ad alcun gruppo di disponibilità esistente.	sys.databases (group_database_id = NULL)
	Non deve essere configurato per il mirroring del database.	sys.database_mirroring Se il database non fa parte del mirroring, tutte le colonne con prefisso "mirroring_" sono NULL.
	Prima di aggiungere un database in cui è utilizzato FILESTREAM a un gruppo di disponibilità, verificare che FILESTREAM sia abilitato in ogni istanza del server in cui è o sarà ospitata una replica di disponibilità per il gruppo di disponibilità.	Abilitare e configurare FILESTREAM
	Prima di aggiungere un database indipendente a un gruppo di disponibilità, verificare che l'opzione del server contained database authentication sia impostata su 1 in ogni istanza del server in cui è o sarà ospitata una replica di disponibilità per il gruppo di disponibilità.	Opzione di configurazione del server contained database authentication Opzioni di configurazione del server (SQL Server)

Restrizioni (database di disponibilità)

• Se il percorso del file, inclusa la lettera di unità, di un database secondario differisce da quello del database primario corrispondente, si applicano le restrizioni seguenti:

  • Creazione guidata nuovo gruppo di disponibilità/Aggiunta guidata database al gruppo di disponibilità: L'opzione Full non è supportata (nella paginaSeleziona sincronizzazione dati iniziale).

  • RESTORE WITH MOVE: per creare i database secondari, i file di database devono essere RESTORED WITH MOVE in ogni istanza di SQL Server in cui è ospitata una replica secondaria.

  • Impatto sulle operazioni di aggiunta di file: un'operazione di aggiunta di file successiva nella replica primaria può generare un errore nei database secondari. Questo errore può causare la sospensione dei database secondari. Questa situazione, a sua volta, può causare l'attivazione dello stato NON IN SINCRONIZZAZIONE delle repliche secondarie.

    Nota

    Per informazioni sulla risposta a un'operazione di file pubblicitario non riuscita, vedere Risolvere i problemi relativi a un'operazione di aggiunta file non riuscita (gruppi di disponibilità AlwaysOn).For information about responding to a failed ad-file operation, see Troubleshoot a Failed Add-File Operation (AlwaysOn Availability Groups).

• Non è possibile eliminare un database che attualmente appartiene a un gruppo di disponibilità.

Completamento per database protetti tramite crittografia TDE

Se si utilizza TDE (Transparent Data Encryption), la chiave asimmetrica o il certificato per la creazione e la decrittografia di altre chiavi deve essere identico in ogni istanza del server in cui viene ospitata una replica di disponibilità per il gruppo di disponibilità. Per altre informazioni, vedere Spostare un database protetto da TDE in un'altra istanza di SQL Server.

Autorizzazioni (database di disponibilità)

È richiesta l'autorizzazione ALTER per il database.

Attività correlate (database di disponibilità)

Contenuto correlato

• Guida alle soluzioni AlwaysOn di Microsoft SQL Server per la disponibilità elevata e il ripristino di emergenza

• Blog del team di SQL Server AlwaysOn: blog ufficiale del team di SQL Server AlwaysOn

• Serie di apprendimento AlwaysON - HADRON: Utilizzo del pool di lavoro per i database abilitati per HADRON

Vedi anche

Panoramica dei gruppi di disponibilità AlwaysOn (SQL Server)
Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)
Connettività client AlwaysOn (SQL Server)