Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server)
Questo argomento descrive le considerazioni per la distribuzione di gruppi di disponibilità Always On, inclusi prerequisiti, restrizioni e raccomandazioni 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.
Importante
Prima di distribuire Always On gruppi di disponibilità, è consigliabile leggere ogni sezione di questo argomento.
Hotfix .NET che supportano gruppi di disponibilità AlwaysOn
A seconda dei componenti e delle funzionalità di SQL Server 2014 che verranno usati con Always On gruppi di disponibilità, potrebbe essere necessario installare altri hotfix .NET identificati nella tabella seguente. Gli hotfix possono essere installati in qualsiasi ordine.
| Funzionalità dipendente | Hotfix | Collegamento | |
|---|---|---|---|
 |
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à Always On, assicurarsi che ogni computer che partecipa a uno o più gruppi di disponibilità soddisfi i requisiti fondamentali seguenti:
| Requisito | Collegamento | |
|---|---|---|
|
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 a 32 bit in Windows a 64 bit) non supporta Always On gruppi di disponibilità. |
|
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 nodo WSFC specifico, 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** Per i nodi di un cluster WSFC in cui viene distribuito Always On gruppi di disponibilità, è necessario o consigliato un numero di hotfix. Per altre informazioni, vedere Hotfix di Windows che supportano i gruppi di disponibilità AlwaysOn (sistema Windows), più avanti in questa sezione. |
Importante
Inoltre, assicurarsi che l'ambiente sia configurato correttamente per la connessione a un gruppo di disponibilità. Per altre informazioni, vedere Connettività client AlwaysOn (SQL Server).For more information, see AlwaysOn Client Connectivity (SQL Server).
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 il supporto di gruppi di disponibilità Always On. 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... | Hotfix | Collegamento | |
|---|---|---|---|---|---|---|
|
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: è disponibile un hotfix per consentire di configurare un nodo del cluster che non dispone di voti quorum in Windows Server 2008 e in Windows Server 2008 R2 Per informazioni sul voto del quorum, vedere Modalità quorum WSFC e configurazione di voto (SQL Server) |
|
Sì | Sì | Sì | Utilizzo più efficiente della larghezza di banda della 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 Always On gruppi di disponibilità. |
KB 2616514: il servizio cluster invia notifiche di modifica della chiave del Registro di sistema non necessarie tra i 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: convalidare l'esito negativo del test dei dati dei prodotti vitali del dispositivo SCSI dopo l'installazione di Windows Server 2008 R2 SP1 | |
|
Sì | Sì | Failover più veloce 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 di Always On failover dei gruppi di disponibilità nelle repliche locali. |
KB 2687741: è disponibile un hotfix che migliora 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à di Always On, installare l'hotfix di Windows Server 2008 976097. Questo hotfix consente allo snap-in MMC (Failover Cluster Management Console) di supportare dischi condivisi di archiviazione asimmetrici disponibili solo in alcuni nodi WSFC. |
KB 976097: hotfix per aggiungere il supporto per le risorse di archiviazione asimmetriche allo snap-in MMC Gestione cluster di failover per un cluster di failover che esegue Windows Server 2008 o Windows Server 2008 R2 Pagina relativa alla guida all'architettura di AlwaysOn in cui viene illustrata la compilazione di una soluzione a disponibilità elevata e di ripristino di emergenza utilizzando istanze del cluster di failover e gruppi di disponibilità |
|
Sì | Sì | Non applicabile | Sicurezza del protocollo Internet (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: un ritardo di tempo lungo si verifica quando si riconnette una connessione IPSec da un computer che esegue Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 o Windows Server 2008 R2 |
| Casella |
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): il servizio cluster 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 |
| Casella |
Sì | Sì | Sì | Nessun router tra il cluster e il 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: operazione di failover lenta 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à di Always On.
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)
| Attività | Collegamento |
|---|---|
| Impostare il valore HostRecordTTL. | Modificare HostRecordTTL (tramite Windows PowerShell) |
Modificare HostRecordTTL (tramite Windows PowerShell)
Aprire la finestra di PowerShell con Esegui come amministratore.
Importare il modulo FailoverClusters.
Utilizzare li cmdlet
Get-ClusterResourceper cercare la risorsa nome di rete, quindi utilizzare il cmdletSet-ClusterParameterper impostare il valoreHostRecordTTL, 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 300Suggerimento
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)
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
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 | |
|---|---|---|
| Casella |
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) |
| Casella |
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. |
| Casella |
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. |
| Casella |
Ogni istanza del server deve essere in esecuzione il edizione Enterprise di SQL Server 2014. | Funzionalità supportate dalle edizioni di SQL Server 2014 |
| Casella |
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 |
| Casella |
Abilitare la funzionalità Always On Gruppi di disponibilità in ogni istanza del server che ospiterà una replica di disponibilità per qualsiasi gruppo di disponibilità. In un determinato computer è possibile abilitare quante istanze del server per i gruppi di disponibilità Always On supporta l'installazione di SQL Server. | Abilitare e disabilitare la funzionalità 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à Always On in ogni istanza del server abilitata per i gruppi di disponibilità Always On nel cluster WSFC originale. |
| Casella |
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 dell'endpoint e non sarà possibile creare un endpoint del 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à Always On è uguale a quella del mirroring del database. |
Endpoint del mirroring del database (SQL Server) Sicurezza trasporto per il mirroring del database e i gruppi di disponibilità AlwaysOn (SQL Server) |
| Casella |
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 |
| Casella |
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à
Always On Gruppi di disponibilità presenta i requisiti seguenti per i thread di lavoro:
In un'istanza inattiva di SQL Server, i gruppi di disponibilità Always On 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: Utilizzo del pool di lavoro per i database abilitati PER HADRON (un blog di ingegneri di SQL Server CSS).
Autorizzazioni (istanza del server)
| Attività | Autorizzazioni necessarie |
|---|---|
| Creazione dell'endpoint del mirroring del database | È richiesta l'autorizzazione CREATE ENDPOINT o l'appartenenza al ruolo predefinito del server sysadmin . È richiesta inoltre l'autorizzazione CONTROL ON ENDPOINT. Per altre informazioni, vedere GRANT - Autorizzazioni per endpoint (Transact-SQL). |
| Abilitazione dei gruppi di disponibilità di Always On | È richiesta l'appartenenza al gruppo degli amministratori nel computer locale, nonché il controllo totale nel cluster WSCF. |
Attività correlate (istanza del server)
| Attività | Argomento |
|---|---|
| Determinazione della presenza di un endpoint del mirroring del database | sys.database_mirroring_endpoints (Transact-SQL) |
| Creazione dell'endpoint del mirroring del database (se non ancora disponibile) | Creare un endpoint del mirroring del database per l'autenticazione Windows (Transact-SQL) Utilizzare certificati per un endpoint del mirroring del database (Transact-SQL) Creare un endpoint del mirroring del database per i gruppi di disponibilità AlwaysOn (SQL Server PowerShell) |
| Abilitazione di Gruppi di disponibilità AlwaysOn | Abilitare e disabilitare la funzionalità Gruppi di disponibilità AlwaysOn (SQL Server) |
Contenuto correlato (istanza del server)
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à Always On 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)
Nota
A partire da SQL Server 2014, le istanze del cluster di failover AlwaysOn supportano volumi condivisi cluster (CSV) in Windows Server 2008 R2 e Windows Server 2012. Per ulteriori informazioni sui volumi condivisi cluster, vedere Informazioni sui volumi condivisi del cluster in un cluster di failover.
I nodi del cluster di un'istanza di cluster possono ospitare una sola replica per un determinato gruppo di disponibilità: Se si aggiunge una replica di disponibilità in un'istanza di cluster cluster WSFC, i nodi del cluster WSFC possibili 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 | Collegamento | |
|---|---|---|
| Casella |
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 Gestione cluster di failover Microsoft Management Console (MMC) di supportare dischi condivisi di archiviazione asimmetrici disponibili solo in alcuni dei nodi WSFC. | KB 976097: hotfix per aggiungere supporto per le risorse di archiviazione asimmetriche allo snap-in MMC gestione cluster di failover per un cluster di failover che esegue Windows Server 2008 o Windows Server 2008 R2 |
| Casella |
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)
| Attività | Argomento |
|---|---|
| Installazione di un cluster di failover di SQL Server | Creare un nuovo cluster di failover di SQL Server (programma di installazione) |
| Aggiornamento sul posto del cluster di failover di SQL Server esistente | Eseguire l'aggiornamento di un'istanza del cluster di failover di SQL Server (installazione) |
| Gestione del cluster di failover di SQL Server esistente | Aggiungere o rimuovere nodi in un cluster di failover di SQL Server (programma di installazione) |
Contenuto correlato (istanze del cluster di failover)
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 determinato gruppo di disponibilità, 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 del gruppo di disponibilità univoco: Ogni nome del 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 (macchina virtuale o computer fisico) 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 usare 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
Always On gruppi di disponibilità richiede il controllo completo e l'abilitazione di gruppi di disponibilità Always On 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 da SQL Server.
Ogni istanza di SQL Server deve avere le autorizzazioni per accedere al Registro di sistema, al cluster e così via.
È consigliabile usare la crittografia per le connessioni tra istanze del server che ospitano Always On repliche di disponibilità dei gruppi di disponibilità.
Autorizzazioni (gruppi di disponibilità)
| Attività | Autorizzazioni necessarie |
|---|---|
| Creazione di un gruppo di disponibilità | Sono necessarie l'appartenenza al ruolo predefinito del server sysadmin e l'autorizzazione server CREATE AVAILABILITY GROUP oppure l'autorizzazione ALTER ANY AVAILABILITY GROUP o CONTROL SERVER. |
| Modifica di un gruppo di disponibilità | È necessaria l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER. Inoltre, per la creazione di un join di un database a un gruppo di disponibilità è richiesta l'appartenenza al ruolo predefinito del database db_owner . |
| Rimozione/eliminazione di un gruppo di disponibilità | È necessaria l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP, l'autorizzazione ALTER ANY AVAILABILITY GROUP o l'autorizzazione CONTROL SERVER. Per rimuovere un gruppo di disponibilità non ospitato nel percorso della replica locale, è necessaria l'autorizzazione CONTROL SERVER o CONTROL per questo gruppo di disponibilità. |
Attività correlate (gruppi di disponibilità)
| Attività | Argomento |
|---|---|
| Creazione di un gruppo di disponibilità | Utilizzare il gruppo di disponibilità (Creazione guidata Gruppo di disponibilità) Creare un gruppo di disponibilità (Transact-SQL) Creare un gruppo di disponibilità (SQL Server PowerShell) Specifica dell'URL dell'endpoint quando si aggiunge o si modifica una replica di disponibilità (SQL Server) |
| Modifica del numero di repliche di disponibilità | Aggiungere una replica secondaria a un gruppo di disponibilità (SQL Server) Creare un join di una replica secondaria a un gruppo di disponibilità (SQL Server) Rimuovere una replica secondaria da un gruppo di disponibilità (SQL Server) |
| Creazione di un listener del gruppo di disponibilità | Creare o configurare un listener del gruppo di disponibilità (SQL Server) |
| Rimozione di un gruppo di disponibilità | Rimuovere un gruppo di disponibilità (SQL Server) |
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 | Collegamento | |
|---|---|---|
|
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) |
Nota
Always On gruppi di disponibilità funziona con qualsiasi livello di compatibilità del database supportato.
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 ad non riuscita, vedere Risolvere i problemi relativi a un'operazione di Add-File non riuscita (Gruppi di disponibilità AlwaysOn).
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à)
| Attività | Argomento |
|---|---|
| Preparazione di un database secondario (manuale) | Preparare manualmente un database secondario per un gruppo di disponibilità (SQL Server) |
| Creazione di un join di un database secondario a un gruppo di disponibilità (manuale) | Creare un join di un database secondario a un gruppo di disponibilità (SQL Server) |
| Modifica del numero di database di disponibilità | Aggiungere un database a un gruppo di disponibilità (SQL Server) Rimuovere un database secondario da un gruppo di disponibilità (SQL Server) Rimuovere un database primario da un gruppo di disponibilità (SQL Server) |
Contenuto correlato
Vedere anche
Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)
Connettività client AlwaysOn (SQL Server)