Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server)
In questo argomento si illustrano le considerazioni sulla distribuzione di Gruppi di disponibilità AlwaysOn, inclusi prerequisiti, restrizioni e indicazioni su computer host, cluster WSCF (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.
.gif "Nota importante") Importante |
|---|
Prima di distribuire Gruppi di disponibilità AlwaysOn, si consiglia di leggere tutte le sezioni presenti in questo argomento. |
Contenuto dell'argomento:
Hotfix di .Net che supportano i gruppi di disponibilità AlwaysOn
Indicazioni e requisiti di sistema di Windows
Prerequisiti e restrizioni dell'istanza di SQL Server
Consigli sulla connettività di rete
Supporto della connettività client
Prerequisiti e restrizioni per l'utilizzo di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità
Prerequisiti e restrizioni dei gruppi di disponibilità
Prerequisiti e restrizioni dei database di disponibilità
Contenuto correlato
Hotfix di .Net che supportano i gruppi di disponibilità AlwaysOn
A seconda dei componenti e delle funzionalità di SQL Server 2012 che verranno utilizzati con Gruppi di disponibilità AlwaysOn, potrebbe essere necessario aggiungere hotfix di .Net aggiuntivi identificati nella seguente tabella. 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à Read-intent, readonly e multisubnetfailover di AlwaysOn. L'hotfix deve essere installato in ogni server di report di Reporting Services. |
KB 2654347: articolo relativo all'hotfix per .Net 3.5 SP1 per aggiungere supporto alle funzionalità AlwaysOn |
.gif "Casella di controllo")
Indicazioni e requisiti di sistema di Windows
Contenuto della sezione:
Elenco di controllo: requisiti
Hotfix di Windows che supportano i gruppi di disponibilità AlwaysOn (sistema Windows)
Indicazioni per computer in cui sono ospitate repliche di disponibilità (sistema Windows)
Autorizzazioni
Attività correlate
Contenuto correlato
Elenco di controllo: requisiti (sistema Windows)
Per supportare la funzionalità Gruppi di disponibilità AlwaysOn, assicurarsi che ogni computer che fa parte di uno o più gruppi di disponibilità soddisfi i requisiti essenziali 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 Gruppi di disponibilità AlwaysOn. |
||
|
Assicurarsi che ogni computer sia un nodo in un cluster WSCF (Windows Server Failover Clustering). |
|||
|
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 specificato possono essere ospitate repliche di disponibilità per numerosi gruppi di disponibilità da parte di una o più istanze di SQL Server. Chiedere agli amministratori del database il numero di nodi WSFC necessario per supportare le repliche di disponibilità dei gruppi di disponibilità pianificati. Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server). |
||
|
Assicurarsi che tutti gli hotfix di Windows applicabili siano stati installati in ogni nodo nel cluster WSFC. |
|
| Importante |
|---|
Inoltre, assicurarsi che l'ambiente sia configurato correttamente per la connessione a un gruppo di disponibilità. Per ulteriori informazioni, vedere Connettività client AlwaysOn (SQL Server). |
Hotfix di Windows che supportano i gruppi di disponibilità AlwaysOn (sistema Windows)
A seconda della topologia cluster, è possibile che siano applicabili per il supporto di Gruppi di disponibilità AlwaysOn diversi hotfix di Windows Server 2008 Service Pack 2 (SP2) o Windows Server 2008 R2 aggiuntivi. 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ì |
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 sui voti quorum, vedere Modalità quorum WSFC e configurazione del voto (SQL Server) |
|
√ |
√ |
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 della rete, causando seri problemi ad 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 |
|
√ |
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ì |
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. Con questo hotfix è possibile migliorare le prestazioni del failover di 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ì |
Archiviazione asimmetrica per le istanze del cluster di failover (FCI, Failover Cluster Instance) |
Se una qualsiasi istanza del cluster di failover sarà abilitata per Gruppi di disponibilità AlwaysOn, installare l'hotfix 976097 di Windows Server 2008. Con questo hotfix lo snap-in Microsoft Management Console (MMC) di Gestione cluster di failover è in grado di supportare l'archiviazione asimmetrica, cioè i dischi condivisi che sono disponibili solo in alcuni dei 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 |
|
√ |
√ |
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ì |
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. |
|
|
√ |
√ |
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: articolo della Knowledge Base relativo al failover lento se non esiste alcun router tra il cluster e un server applicazioni |
.gif "Icona freccia utilizzata con il collegamento Torna all'inizio")
Torna all'inizio
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 ottimizzare le prestazioni, utilizzare una scheda di rete dedicata (scheda di interfaccia di rete) per 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 ulteriori 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-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.gif "Suggerimento")
SuggerimentoOgni volta che viene aperta una nuova finestra di PowerShell, è necessario importare il modulo FailoverClusters.
Contenuto correlato (PowerShell)
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
[Inizio pagina]
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 specificata può essere un'istanza autonoma o un'istanza del cluster di failover di SQL Server.
Contenuto della sezione
Elenco di controllo: prerequisiti
Restrizioni
Utilizzo del thread da parte dei gruppi di disponibilità
Autorizzazioni
Attività correlate
Contenuto correlato
Elenco di controllo: prerequisiti (istanza del server)
Prerequisiti |
Collegamenti |
|||
|---|---|---|---|---|
|
Il computer host deve essere un nodo WSFC (Windows Server Failover Clustering). Le istanze di SQL Server in cui sono ospitate le repliche di disponibilità di uno specifico gruppo di disponibilità devono risiedere in nodi diversi 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) |
||
In ogni nodo WSFC in cui viene ospitata una replica di disponibilità, assicurarsi che sia installato l'hotfix descritto nell'articolo della Knowledge Base 2897554. Questo hotfix garantisce che lo stato di sincronizzazione di ogni replica di disponibilità è correttamente aggiornato, evitando in questo modo perdite di dati impreviste da un failover automatico. |
KB 2897554: articolo relativo alla correzione qualora lo stato di sincronizzazione di una replica del gruppo di disponibilità AlwaysOn potrebbe non essere aggiornato se la replica primaria non è integra |
|||
|
Se si desidera che in un gruppo di disponibilità venga utilizzato Kerberos:
|
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.
|
||
|
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. |
||
|
In ogni istanza del server deve essere in esecuzione la versione Enterprise Edition di SQL Server 2012. |
|||
|
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. |
|||
|
Abilitare la funzionalità Gruppi di disponibilità AlwaysOn in ogni istanza del server in cui sarà ospitata una replica di disponibilità per qualsiasi gruppo di disponibilità. In un computer specificato è possibile abilitare tante istanze del server per Gruppi di disponibilità AlwaysOn quante sono quelle supportate dall'installazione di SQL Server. |
Abilitare e disabilitare la funzionalità Gruppi di disponibilità AlwaysOn (SQL Server)
|
||
|
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 utilizzare 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.
|
Endpoint del mirroring del database (SQL Server) Sicurezza trasporto per il mirroring del database e i 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à. |
|||
|
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 |
.gif "Nota sulla sicurezza")
Nota sulla sicurezzaUtilizzo del thread da parte dei gruppi di disponibilità
Per i thread di lavoro di Gruppi di disponibilità AlwaysOn devono essere soddisfatti i requisiti seguenti:
In caso di istanza inattiva di SQL Server, in Gruppi di disponibilità AlwaysOn non viene utilizzato alcun 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 ulteriori informazioni, vedere la pagina relativa alla serie di informazioni su HADRON riguardanti l'utilizzo del pool di lavoro per database abilitati HADRON in AlwaysOn (blog del Servizio Supporto Tecnico Clienti per gli ingegneri di SQL Server).
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 ulteriori informazioni, vedere GRANT - autorizzazioni per endpoint (Transact-SQL). |
Abilitazione di Gruppi di disponibilità AlwaysOn |
È 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 |
|
Creazione dell'endpoint del mirroring del database (se non ancora disponibile) |
|
Abilitazione di Gruppi di disponibilità AlwaysOn |
Abilitare e disabilitare la funzionalità Gruppi di disponibilità AlwaysOn (SQL Server) |
Contenuto correlato (istanza del server)
[Torna all'inizio]
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à.
[Torna all'inizio]
Supporto della connettività client
Per informazioni sul supporto di Gruppi di disponibilità AlwaysOn per la connettività client, vedere Connettività client AlwaysOn (SQL Server).
[Inizio pagina]
Prerequisiti e restrizioni per l'utilizzo di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità
Contenuto della sezione:
Restrizioni
Elenco di controllo: prerequisiti
Attività correlate
Contenuto correlato
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 in cui è ospitata una replica di disponibilità, sarà necessario rimuovere la replica dal relativo gruppo di disponibilità e riaggiungerla successivamente in 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)
Prerequisiti |
Collegamento |
|
|---|---|---|
|
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. Con questo hotfix lo snap-in Microsoft Management Console (MMC) di Gestione cluster di failover è in grado di supportare l'archiviazione asimmetrica, cioè i dischi condivisi che sono disponibili solo in alcuni dei 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)
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) |
[Inizio pagina]
Contenuto correlato (istanze del cluster di failover)
Prerequisiti e restrizioni dei gruppi di disponibilità
Contenuto della sezione:
Restrizioni
Requisiti
Sicurezza
Attività correlate
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 quattro repliche secondarie. È possibile eseguire tutte le repliche in modalità con commit asincrono oppure fino a un massimo di tre in modalità con commit sincrono.
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 (VM o 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 utilizzare Gestione cluster di failover per modificare i gruppi di disponibilità:
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 utilizzare 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.
Prerequisiti |
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'utilizzo 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
Per Gruppi di disponibilità AlwaysOn è necessario un controllo completo. Se si abilita questa funzionalità in un'istanza di SQL Server viene fornito a essa il controllo completo del cluster WSFC, tramite il 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 sessioni di sicurezza di WSFC, utilizzare Gestione configurazione SQL Server o l'equivalente WMI da SQL Server.
Ogni istanza di SQL Server deve disporre delle autorizzazioni per l'accesso al Registro di sistema, al cluster e così via.
È consigliabile utilizzare la crittografia per le connessioni tra istanze del server in cui si ospitano repliche di disponibilità di Gruppi di disponibilità AlwaysOn.
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à |
È richiesta l'autorizzazione ALTER AVAILABILITY GROUP per il 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à |
È richiesta l'autorizzazione ALTER AVAILABILITY GROUP per il 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à |
|
Modifica del numero di repliche di disponibilità |
|
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à |
[Torna all'inizio]
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.
Contenuto della sezione:
Requisiti
Restrizioni
Indicazioni per computer in cui sono ospitate repliche di disponibilità (sistema Windows)
Autorizzazioni
Attività correlate
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.
|
|
|
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à. |
|
|
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 |
[!NOTA]
Gruppi di disponibilità AlwaysOn 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 Gruppo di disponibilità/Procedura guidata Aggiungi database a gruppo di disponibilità: **l'opzione Completo nella pagina Seleziona sincronizzazione dati iniziale non è supportata.
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 aggiunta di file errata, vedere Risolvere i problemi relativi a una operazione di aggiunta 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 ulteriori 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à |
[Torna all'inizio]
Contenuto correlato
[Torna all'inizio]
Vedere anche
Concetti
Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)