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

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.

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.

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:

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.

• Layout del disco identico: ogni computer in cui un'istanza del server ospita una replica di disponibilità deve avere un layout del disco identico (con lettere e dimensioni esatte dell'unità disco) per garantire che i percorsi dei file di database (mdf, ldf) siano speculari, impedendo complicazioni durante il seeding e la sincronizzazione. Vedere Restrizioni (database di disponibilità) per i layout dei dischi diversi.

Autorizzazioni (sistema Windows)

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

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

Attività correlate (sistema Windows)

Modificare HostRecordTTL (tramite 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)

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

• Introduzione a Windows PowerShell in un cluster di failover

• Comandi di risorse cluster e cmdlet di Windows PowerShell equivalenti

Contenuto correlato (sistema Windows)

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

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

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
• Utilizzo del thread da parte dei gruppi di disponibilità
• Autorizzazioni
• Attività correlate
• Contenuto correlato

Elenco di controllo: prerequisiti (istanza del server)

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

• Edizioni e funzionalità supportate di SQL Server 2022
• Edizioni e funzionalità supportate di SQL Server 2019
• Edizioni e funzionalità supportate di SQL Server 2017
• Edizioni e le funzionalità supportate di SQL Server 2016

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à correlate (istanza del server)

Contenuto correlato (istanza del server)

• serie di informazioni su HADRON riguardanti l'uso del pool di lavoro per database abilitati HADRON in AlwaysOn

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

Attività correlate (istanze del cluster di failover)

Contenuto correlato (istanze del cluster di failover)

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

• Pagina relativa alla guida all'architettura di Always On in cui viene illustrata la compilazione di una soluzione a disponibilità elevata e di ripristino di emergenza usando istanze del cluster di failover e gruppi di disponibilità

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, 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.

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à correlate (gruppi di disponibilità)

Prerequisiti e restrizioni dei database di disponibilità

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

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:

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:

  • Procedura guidata Nuovo gruppo di disponibilità/Procedura guidata Aggiunta database al gruppo di disponibilità: l'opzione Full non è supportata (nella pagina Seleziona sincronizzazione dei dati iniziale della procedura guidata del gruppo di disponibilità Always On).

  • 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à Always On).

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

Completamento per database protetti tramite crittografia TDE

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

Autorizzazioni (database di disponibilità)

È richiesta l'autorizzazione ALTER per il database.

Attività correlate (database di disponibilità)

Contenuto correlato

• Microsoft SQL Server Always On Solutions Guide for High Availability and Disaster Recovery (Guida alle soluzioni AlwaysOn di Microsoft SQL Server per la disponibilità elevata e il ripristino di emergenza)
• SQL Server AlwaysOn Team Blog: blog ufficiale del team di SQL Server AlwaysOn
• serie di informazioni su HADRON riguardanti l'uso del pool di lavoro per database abilitati HADRON in AlwaysOn
• Definizione del gruppo di disponibilità Always On
• Clustering di failover e Gruppi di disponibilità Always On (SQL Server)
• Supporto della connettività di driver e client per i gruppi di disponibilità