Prerequisiti, restrizioni e consigli per i gruppi di disponibilità Always On

  • Articolo

Si applica a:SQL Server

Questo articolo illustra considerazioni sulla distribuzione di Gruppi di disponibilità Always On, inclusi prerequisiti, restrizioni e indicazioni su computer host, cluster WSFC (Windows Server Failover Cluster), 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 Gruppi di disponibilità Always On, si consiglia di leggere tutte le sezioni presenti in questo argomento.

Hotfix di .NET che supportano i gruppi di disponibilità

A seconda dei componenti e delle funzionalità di SQL Server che verranno usati con Gruppi di disponibilità Always On, potrebbe essere necessario aggiungere hotfix di .NET aggiuntivi identificati nella seguente tabella. Gli hotfix possono essere installati in qualsiasi ordine.

Funzionalità dipendente Hotfix Collega
Reporting Services L'hotfix per .NET 3.5 SP1 aggiunge il supporto a SQL Client per le funzionalità AlwaysOn di Read-intent, 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 supporto alle funzionalità Always On

Elenco di controllo: requisiti (sistema Windows)

Per supportare la funzionalità Gruppi di disponibilità Always On, assicurarsi che ogni computer che fa parte di uno o più gruppi di disponibilità soddisfi i requisiti essenziali 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 di Windows Server 2019 o una versione successiva. SQL Server 2022: requisiti hardware e software
Assicurarsi che ogni computer sia un nodo in un cluster WSFC. Clustering di failover di Windows Server con SQL Server
Assicurarsi che nel cluster WSFC siano contenuti nodi sufficienti per supportare le configurazioni dei gruppi di disponibilità. Un nodo del cluster può ospitare una sola replica per un gruppo di disponibilità. Lo stesso nodo non può ospitare due repliche dallo stesso gruppo di disponibilità. Il nodo del cluster può partecipare a più gruppi di disponibilità, con una replica da ogni gruppo.

Chiedere agli amministratori del database il numero di nodi del cluster necessario per supportare le repliche di disponibilità dei gruppi di disponibilità pianificati.

Definizione del gruppo di disponibilità Always On

Importante

Inoltre, assicurarsi che l'ambiente sia configurato correttamente per la connessione a un gruppo di disponibilità. Per ulteriori informazioni, vedere Supporto della connettività di driver e client per i gruppi di disponibilità.

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, usare una scheda di rete dedicata (scheda di interfaccia di rete) per Gruppi di disponibilità 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à Collega
Impostare il valore HostRecordTTL. Modificare HostRecordTTL (tramite Windows PowerShell)

Modificare HostRecordTTL (tramite PowerShell)

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

  2. Importare il modulo FailoverClusters.

  3. Usare il cmdlet Get-ClusterResource per cercare la risorsa nome di rete, quindi usare 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 HostRecordTTL 300

    Suggerimento

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

Contenuto correlato (PowerShell)

Contenuto correlato (sistema Windows)

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.

Contenuto della sezione:

Elenco di controllo: prerequisiti (istanza del server)

Prerequisito Collegamenti
Il computer host deve essere un nodo WSFC. Le istanze di SQL Server in cui sono ospitate le repliche di disponibilità di uno specifico gruppo di disponibilità risiedono in nodi diversi del cluster. Quando viene eseguita la migrazione a un cluster diverso, un gruppo di disponibilità può risiedere temporaneamente in due cluster. SQL Server 2016 (13.x) ha introdotto i gruppi di disponibilità distribuita. In un gruppo di disponibilità distribuita, due gruppi di disponibilità risiedono in cluster diversi. Clustering di failover di Windows Server con SQL Server

Clustering di failover e Gruppi di disponibilità Always On (SQL Server)

Gruppi di disponibilità distribuiti
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 viene completata.

Per usare l'autenticazione Kerberos per la comunicazione tra endpoint del gruppo di disponibilità (AG), registrare manualmente nomi dell'entità servizio (SPN) per gli endpoint del mirroring del database usati dal gruppo di disponibilità.

Importante: se si modifica l'account del servizio SQL Server, l'amministratore di dominio deve registrare di nuovo manualmente il nome SPN.		 Registrazione di un nome dell'entità servizio per le connessioni Kerberos

Nota:

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'uso di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità, più avanti in questo articolo
Per partecipare a un gruppo di disponibilità, ogni istanza del server deve eseguire la stessa versione di SQL Server. Per altre informazioni, vedere l’elenco delle versioni e delle funzionalità supportate al termine di questa sezione.
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. Impostare o cambiare le regole di confronto del server
Abilitare la funzionalità Gruppi di disponibilità Always On 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à Always On quante sono quelle supportate dall'installazione di SQL Server. Abilitare o disabilitare la funzionalità dei gruppi di disponibilità Always On

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 Gruppi di disponibilità Always On nel cluster originale.
Per ogni istanza del server è necessario un endpoint del mirroring del database. 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 del gruppo di disponibilità (SQL Server Server Management Studio) (o Aggiungi replica a gruppo di disponibilità Always On con la procedura guidata del gruppo di disponibilità in SQL Server Management) è 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 è 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 di sicurezza: la sicurezza del trasporto per Gruppi di disponibilità Always On corrisponde a quella per il mirroring del database.		 Endpoint del mirroring del database (SQL Server)

Disponibilità Always On per il mirroring dei database con sicurezza del trasporto
Se tutti i database in cui è utilizzato FILESTREAM vengono 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 sono aggiunti a un gruppo di disponibilità, verificare che contained database authentication (opzione di configurazione del server) sia impostata su 1 in ogni istanza del server in cui è 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)

Per un elenco delle funzionalità supportate dalle edizioni di SQL Server su Windows, vedere:

Utilizzo del thread da parte dei gruppi di disponibilità

Gruppi di disponibilità Always On 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 usato dai gruppi di disponibilità è dato dall'impostazione configurata per il numero massimo di thread del server ('max worker threads') meno 40.

  • Le repliche di disponibilità ospitate in una determinata istanza del server condividono un pool a thread singolo in SQL Server 2019 (15.x) e versioni precedenti.

    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.

    • Un'istanza di SQL Server usa fino a 100 thread per la fase di rollforward parallelo per le repliche secondarie. Ogni database usa fino a metà del numero totale di core CPU, ma non più di 16 thread per ogni database. Se il numero totale di thread necessari per una singola istanza supera 100, SQL Server usa un unico thread di fase di rollforward per tutti i database rimanenti. I thread di rollforward seriale vengono rilasciati dopo circa 15 secondi di inattività.

  • 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à.

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

  • SQL Server 2022 (16.x) ha introdotto il pool di thread di rollforward parallelo, ovvero un pool di thread a livello di istanza condiviso con tutti i database che hanno il lavoro di rollforward. Con questo pool, lo stesso set di thread può elaborare i record di log per database diversi contemporaneamente (in parallelo). In SQL Server 2019 (15.x) e versioni precedenti il numero di thread disponibili per il rollforward è limitato a 100.

  • SQL Server 2019 (15.x) ha introdotto la fase di rollforward parallela per i database di gruppi di disponibilità ottimizzati per la memoria. In SQL Server 2016 (13.x) e SQL Server 2017 (14.x) le tabelle basate su disco non usano la fase di rollforward parallela se un database in un gruppo di disponibilità è anche ottimizzato per la memoria.

Per altre informazioni, vedere la pagina relativa alla serie di informazioni su HADRON riguardanti l'uso 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 altre informazioni, vedere GRANT - Autorizzazioni per endpoint (Transact-SQL).
Abilitazione dei gruppi di disponibilità Always On È richiesta l'appartenenza al gruppo Administrator nel computer locale, nonché il controllo totale nel cluster WSFC.

Attività correlate (istanza del server)

Attività Articolo
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 un gruppo di disponibilità usando PowerShell
Abilitazione dei gruppi disponibilità Abilitare o disabilitare la funzionalità dei gruppi di disponibilità Always On

Contenuto correlato (istanza del server)

Consigli sulla connettività di rete

Si consiglia di usare gli stessi collegamenti di rete per le comunicazioni tra nodi 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 verrà ripristinato il collegamento. Se per il cluster WSFC è richiesto un failover automatico mentre la replica secondaria non è sincronizzata, il failover automatico non si verifica.

Supporto della connettività client

Per informazioni sul supporto dei gruppi di disponibilità Always On per la connettività client, vedere Supporto della connettività di driver e client per i gruppi di disponibilità.

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 (istanze del cluster di failover)

Nota

Le istanze del cluster di failover supportano i volumi condivisi cluster (CSV). Per ulteriori informazioni su CSV, vedere Informazioni sui volumi condivisi cluster in un cluster di failover (Understanding Cluster Shared Volumes in a Failover Cluster).

  • 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 WSFC che sono i possibili proprietari dell'istanza del cluster di failover non possono ospitare un'altra replica per lo stesso gruppo di disponibilità. Per evitare possibili conflitti è consigliabile configurare i proprietari possibili per l'istanza del cluster di failover. In tal modo si evita la possibilità che un singolo WSFC tenti l'hosting di due repliche di disponibilità per lo stesso gruppo di disponibilità.

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

    Avviso

    L'uso di Gestione cluster di failover per lo spostamento di un'istanza FCI che ospita un gruppo di disponibilità in un nodo che ospita già una replica dello stesso gruppo di disponibilità potrebbe causare la perdita della replica del gruppo di disponibilità, impedendo che venga portato online sul nodo di destinazione. Un singolo nodo di un cluster di failover non può ospitare più di una replica dello stesso gruppo di disponibilità. Per altre informazioni su come si verifica questa situazione e sulle misure da adottare, vedere il blog Replica rimossa in modo imprevisto nel gruppo di disponibilità.

  • 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. 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
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à Articolo
Installazione di un'istanza del cluster di failover di SQL Server Creare una nuova istanza del cluster di failover Always On (programma di installazione)
Aggiornamento sul posto del cluster di failover di SQL Server esistente Aggiornare un'istanza del cluster di failover
Gestione del cluster di failover di SQL Server esistente Aggiungere o rimuovere nodi in un'istanza del cluster di failover (programma di installazione)

Contenuto correlato (istanze del cluster di failover)

Prerequisiti e restrizioni dei gruppi di disponibilità

Contenuto della sezione:

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, 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 cinque in modalità con commit sincrono (una replica primaria con due repliche secondarie sincrone). Ogni replica deve avere un nome server univoco sia in Windows che in SQL Server. I nomi dei server Windows e SQL Server devono corrispondere.

  • 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 testato un massimo di 10 gruppi di disponibilità e 100 database per computer fisico, ma non si tratta di un limite vincolante. A seconda delle specifiche hardware del server e del carico di lavoro, è possibile inserire un numero maggiore di database e di gruppi di disponibilità in un'istanza di SQL Server. 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 del gruppo di disponibilità 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à. Lo stato di un'istanza del cluster di failover di SQL Server viene condiviso tra SQL Server e il cluster di failover di Windows (WSFC), con SQL Server che mantiene più informazioni dettagliate sullo stato delle istanze rispetto a quelle richieste dal cluster. Il modello di gestione prevede che SQL Server guidi le transazioni e sia responsabile di mantenere la visualizzazione dello stato del cluster sincronizzata con la visualizzazione dello stato di SQL Server. Se lo stato del cluster viene modificato all'esterno di SQL Server è possibile che lo stato non sia più sincronizzato tra WSFC e SQL Server e ciò potrebbe causare un comportamento imprevedibile.

    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.

  • Non aggiungere risorse o modificare le dipendenze associate al ruolo del gruppo di disponibilità. Non è consigliabile inserire risorse aggiuntive (incluso l'utente o la terza parte) nel ruolo del gruppo di disponibilità o modificare le dipendenze del ruolo perché queste modifiche possono influire negativamente sulle prestazioni del failover.

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 articolo)

Sicurezza (gruppi di disponibilità)

  • La sicurezza viene ereditata dal cluster WSFC. Windows Server Failover Clustering fornisce due livelli di sicurezza utente a livello di granularità dell'intero cluster:

    • Accesso di sola lettura

    • Controllo completo

      I gruppi di disponibilità AlwaysOn necessitano di controllo completo e l'abilitazione di gruppi di disponibilità Always On in un'istanza di SQL Server fornisce il controllo completo del cluster (tramite il SID del servizio).

      Non è possibile aggiungere o rimuovere direttamente la sicurezza per un'istanza del server in Gestione cluster. Per gestire sessioni di sicurezza del cluster, usare 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à Always On.

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à Sono necessarie l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP permission, 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à Sono necessarie l'autorizzazione ALTER AVAILABILITY GROUP nel gruppo di disponibilità, l'autorizzazione CONTROL AVAILABILITY GROUP permission, 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à Articolo
Creazione di un gruppo di disponibilità Usare la Creazione guidata Gruppo di disponibilità (SQL Server Management Studio)

Creare un gruppo di disponibilità Always On con Transact-SQL (T-SQL)

Creare un gruppo di disponibilità Always On con PowerShell

Specificare l'URL dell'endpoint quando si aggiunge o si modifica una replica di disponibilità
Modifica del numero di repliche di disponibilità Aggiungere una replica secondaria a un gruppo di disponibilità Always On

Creare un join di una replica secondaria a un gruppo di disponibilità Always On

Rimuovere una replica secondaria da un gruppo di disponibilità (SQL Server)
Creazione di un listener del gruppo di disponibilità Configurare un listener per un gruppo di disponibilità Always On
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.

Contenuto della sezione:

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)
Usare il modello 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 sul modello 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
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

Gruppi di disponibilità Always On 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:

  • 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à Articolo
Preparazione di un database secondario (manuale) Preparare un database secondario per un gruppo di disponibilità Always On
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à Always On
Modifica del numero di database di disponibilità Aggiungere un database a un gruppo di disponibilità Always On

Rimuovere un database secondario da un gruppo di disponibilità (SQL Server)

Rimuovere un database primario da un gruppo di disponibilità Always On

Contenuto correlato