Cos'è un gruppo di disponibilità indipendente?

Si applica a: SQL Server 2022 (16.x)

Un gruppo di disponibilità indipendente è un gruppo di disponibilità Always On che supporta gli elementi seguenti:

• gestione degli oggetti di metadati (utenti, account di accesso, autorizzazioni, processi di SQL Agent e così via) a livello di gruppo di disponibilità oltre che a livello di istanza.

• database di sistema indipendenti specializzati all'interno del gruppo di disponibilità.

Questo articolo illustra in dettaglio le analogie, le differenze e le funzionalità dei gruppi di disponibilità indipendenti.

Panoramica

I gruppi di disponibilità sono in genere costituiti da uno o più database utente destinati a funzionare come gruppo coordinato e replicati in un certo numero di nodi in un cluster. Quando si verifica un errore nel nodo o nello stato di SQL Server nel nodo che ospita la copia primaria, il gruppo di database viene spostato come unità in un altro nodo di replica nel gruppo di disponibilità. Tutti i database utente vengono mantenuti sincronizzati in tutte le repliche del gruppo di disponibilità, in modalità sincrona o asincrona.

Questo approccio funziona bene per le applicazioni che interagiscono solo con tale set di database utente, ma si verificano problemi quando le applicazioni si basano anche su oggetti quali utenti, account di accesso, autorizzazioni, processi agente e così via, archiviati in uno dei database di sistema (master o msdb). Affinché le applicazioni funzionino in modo uniforme e prevedibile, l'amministratore deve assicurarsi manualmente che qualsiasi modifica a tali oggetti venga duplicata in tutte le istanze di replica nel gruppo di disponibilità. Se nel gruppo di disponibilità viene inserita una nuova istanza, è possibile eseguire automaticamente o manualmente il seeding dei database tramite un semplice processo, ma tutte le personalizzazioni del database di sistema devono essere riconfigurate nella nuova istanza in modo che corrispondano alle altre repliche.

I gruppi di disponibilità indipendenti estendono il concetto di gruppo di database replicati per includere parti rilevanti dei database master e msdb. Lo si consideri come il contesto di esecuzione per le applicazioni che usano il gruppo di disponibilità indipendente. L'idea è che l'ambiente del gruppo di disponibilità indipendente includa impostazioni che potrebbero influire sull'applicazione basata su di esse. Di conseguenza, l'ambiente del gruppo di disponibilità indipendente riguarda tutti i database con cui l'applicazione interagisce, l'autenticazione usata (account di accesso, utenti, autorizzazioni), tutti i processi pianificati previsti dall'esecuzione e altre impostazioni di configurazione che influiscono sull'applicazione.

Ciò è diverso dai database indipendenti, che usano un meccanismo diverso per gli account utente, archiviando le informazioni utente all'interno del database stesso. I database indipendenti replicano solo gli account di accesso e gli utenti e l'ambito dell'account di accesso o dell'utente replicato è limitato allo specifico database singolo (e alle relative repliche).

Al contrario, in un gruppo di disponibilità indipendente è possibile creare utenti, account di accesso, autorizzazioni e così via a livello del gruppo, che sono quindi coerenti automaticamente tra le repliche nel gruppo di disponibilità, nonché tra i database all'interno di tale gruppo. In questo modo l'amministratore evita la necessità di apportare manualmente tali modifiche.

Differenze

Esistono alcune differenze pratiche da considerare quando si usano gruppi di disponibilità indipendenti, ad esempio la creazione di database di sistema indipendenti, forzando la connessione a livello di gruppo di disponibilità indipendente anziché connettersi a livello di istanza.

Database di sistema indipendenti

Ogni gruppo di disponibilità indipendente dispone dei propri database di sistema master e msdb, denominati in base al nome del gruppo di disponibilità. Nel gruppo di disponibilità indipendente MyContainedAG, ad esempio, sono presenti database denominati MyContainedAG_master e MyContainedAG_msdb. Tali database di sistema vengono automaticamente sottoposto a seeding in nuove repliche e gli aggiornamenti vengono replicati in questi database esattamente come qualsiasi altro database in un gruppo di disponibilità. Ciò significa che quando si aggiunge un oggetto, ad esempio un account di accesso o un processo agente mentre si è connessi al gruppo di disponibilità indipendente, quando quest'ultimo esegue il failover a un'altra istanza connettendosi al gruppo di disponibilità indipendente, verranno comunque visualizzati i processi agente e sarà possibile eseguire l'autenticazione usando l'account di accesso creato nel gruppo di disponibilità indipendente.

Importante

I gruppi di disponibilità indipendenti consentono di mantenere coerenti le configurazioni dell'ambiente di esecuzione tra le repliche di un gruppo di disponibilità. Non rappresentano un limite di sicurezza. Non esiste alcun limite, ad esempio, che impedisca a una connessione a un gruppo di disponibilità indipendente di accedere ai database all'esterno del gruppo di disponibilità.

I database di sistema in un nuovo gruppo di disponibilità indipendente non vengono copiati dall'istanza in cui viene eseguito il comando CREATE AVAILABILITY GROUP. Inizialmente sono modelli vuoti senza dati. Immediatamente dopo la creazione, gli account amministratore nell'istanza che crea il gruppo di disponibilità indipendente vengono copiati nel master di tale gruppo. In questo modo l'amministratore può accedere al gruppo di disponibilità indipendente e definire il resto della configurazione. Se nell'istanza sono stati creati utenti o configurazioni locali, non verranno visualizzati automaticamente quando si creano i database di sistema indipendenti e non saranno visibili quando ci si connette al gruppo di disponibilità indipendente. È necessario ricrearli manualmente nei database di sistema indipendenti nel contesto del gruppo di disponibilità indipendente. L'eccezione è che tutti gli account di accesso nel ruolo sysadmin nell'istanza padre vengono copiati nel nuovo database master specifico del gruppo di disponibilità.

Ripristinare un database di sistema indipendente

È possibile ripristinare un database di sistema indipendente usando uno dei due modi diversi.

• Ripristinare un database indipendente usando una replica secondaria:

  1. Ripristinare il database indipendente master e msdb in un'istanza del server che ospita la replica secondaria, usando RESTORE WITH NORECOVERY per ogni operazione di ripristino. Per altre informazioni, vedere Preparare manualmente un database secondario per un gruppo di disponibilità Always On.

  2. Creare un join di ogni database indipendente al gruppo di disponibilità. Per altre informazioni, vedere Creare un join di un database secondario a un gruppo di disponibilità Always On.

• Ripristinare un database indipendente eliminando il gruppo di disponibilità indipendente:

  1. Escludere il gruppo di disponibilità indipendente.

  2. Ripristinare il database indipendente master e msdb in ognuna delle istanze che fanno parte del gruppo di disponibilità indipendente.

  3. Ricreare il gruppo di disponibilità indipendente usando i nodi originali e il nome usando la sintassi WITH (CONTAINED, REUSE_SYSTEM_DATABASES).

Eseguire la connessione (ambiente indipendente)

È importante distinguere la differenza tra la connessione all'istanza e la connessione al gruppo di disponibilità indipendente. L'unico modo per accedere all'ambiente del gruppo di disponibilità indipendente consiste nel connettersi al listener del gruppo di disponibilità indipendente o nel connettersi a un database presente nel gruppo di disponibilità indipendente,

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

in cui MyContainedDatabase è un database all'interno del gruppo di disponibilità indipendente con cui si vuole interagire.

Ciò significa che per usare in modo efficace un gruppo di disponibilità indipendente è necessario creare un listener specifico per il gruppo. Se ci si connette a una delle istanze che ospitano il gruppo di disponibilità indipendente anziché direttamente al gruppo di disponibilità indipendente tramite il listener, ci si trova nell'ambiente dell'istanza e non nel gruppo di disponibilità indipendente.

Se ad esempio il gruppo di disponibilità MyContainedAG è ospitato nel server SERVER\MSSQLSERVER e anziché connettersi al listener MyContainedAG_Listener ci si connette all'istanza usando SERVER\MSSQLSERVER, ci si trova nell'ambiente dell'istanza e non nell'ambiente di MyContainedAG. Ciò significa che si sarà soggetti al contenuto (utenti, autorizzazioni, processi e così via) presenti nei database di sistema dell'istanza. Per accedere al contenuto trovato nei database di sistema indipendenti del gruppo di disponibilità indipendente, connettersi al listener del gruppo di disponibilità indipendente(ad esempio MyContainedAG_Listener). Dopo la connessione all'istanza tramite il listener del gruppo di disponibilità indipendente, quando si interagisce con master, si viene effettivamente reindirizzati al database indipendente master (ad esempio MyContainedAG_master).

Routing di sola lettura e gruppi di disponibilità indipendenti

Se si configura il routing di sola lettura per reindirizzare le connessioni con finalità di lettura a una replica secondaria (vedere Configurare il routing di sola lettura per un gruppo di disponibilità Always On) e si intende connettersi usando un account di accesso creato solo nel gruppo di disponibilità indipendente, tenere presente alcuni aspetti:

• È necessario specificare un database che fa parte del gruppo di disponibilità indipendente nella stringa di connessione
• L'utente specificato nella stringa di connessione deve disporre dell'autorizzazione per accedere ai database nel gruppo di disponibilità indipendente.

Si consideri ad esempio la stringa di connessione seguente dove AdventureWorks è un database all'interno del gruppo di disponibilità indipendente con MyContainedListener e dove MyUser è un utente definito nel gruppo di disponibilità indipendente e in nessuna delle istanze partecipanti:

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"

La stringa di connessione consente di connettersi al database secondario leggibile che fa parte della configurazione di routing di sola lettura e si troverebbe nel contesto del gruppo di disponibilità indipendente.

Differenze tra la connessione all'istanza e la connessione al gruppo di disponibilità indipendente

• Quando si è connessi al gruppo di disponibilità indipendente, gli utenti visualizzano solo i database nel gruppo di disponibilità indipendente, oltre a tempdb.
• A livello di istanza, i nomi dei gruppi di disponibilità indipendenti master e msdb sono [contained AG]_master e [contained AG]_msdb. All'interno del gruppo di disponibilità indipendente, i nomi sono master e msdb.
• L'ID del database per il master del gruppo di disponibilità indipendente è 1 dall'interno del gruppo, ma è diverso quando si è connessi all'istanza.
• Anche se gli utenti non vedono i database all'esterno del gruppo di disponibilità indipendente in sys.databases quando sono connessi al gruppo, possono accedere a tali database tramite il nome in tre parti o tramite il comando USE.
• La configurazione del server tramite sp_configure può essere letta dalla connessione del gruppo di disponibilità indipendente, ma può essere scritta solo a livello di istanza.
• Dalle connessioni del gruppo di disponibilità indipendenti, l'account sysadmin è in grado di eseguire operazioni a livello di istanza, ad esempio l'arresto di SQL Server.
• La maggior parte delle operazioni a livello di database, di endpoint o di gruppo di disponibilità può essere eseguita solo dalle connessioni di istanza, non dalle connessioni del gruppo di disponibilità indipendente.

Interazioni con altre funzionalità

Sono presenti altre considerazioni quando si usano determinate funzionalità con gruppi di disponibilità indipendenti ed esistono anche alcune funzionalità attualmente non supportate.

Non supportato

In un gruppo di disponibilità indipendente, attualmente le funzionalità di SQL Server seguenti non sono supportate:

• Replica di SQL Server di qualsiasi tipo (transazionale, merge, snapshot e così via).
• Gruppi di disponibilità distribuiti.
• Log shipping in cui il database di destinazione si trova nel gruppo di disponibilità indipendente. Il log shipping con il database di origine nel gruppo di disponibilità indipendente è supportato.

Change data capture

La funzione Change Data Capture (CDC) viene implementata come processi di SQL Agent e di conseguenza SQL Agent deve essere in esecuzione in tutte le istanze con repliche nel gruppo di disponibilità indipendente.

Per usare Change Data Capture con un gruppo di disponibilità indipendente, connettersi al listener del gruppo di disponibilità quando si configura CDC in modo che i metadati CDC siano definiti usando i database di sistema indipendenti.

Log shipping

Il log shipping può essere configurato se il database di origine si trova nel gruppo di disponibilità indipendente. Una destinazione per il log shipping, tuttavia, non è supportata all'interno di un gruppo di disponibilità indipendente. È inoltre previsto un passaggio aggiuntivo per modificare il processo di log shipping dopo la configurazione di CDC.

Per configurare il log shipping con un gruppo di disponibilità indipendente, seguire questi passaggi:

1. Eseguire la connessione al listener del gruppo di disponibilità indipendente.
2. Configurare il log shipping come di consueto.
3. Dopo aver configurato il processo di log shipping, modificare il processo per connettersi al listener del gruppo di disponibilità indipendente prima di eseguire un backup.

Transparent data encryption (TDE)

Per usare Transparent Data Encryption (TDE) con i database in un gruppo di disponibilità indipendente, installare manualmente la chiave master del database nel database indipendente master all'interno del gruppo di disponibilità indipendente.

I database che usano TDE si basano sui certificati nel database master per decrittografare la chiave di crittografia del database. Senza tale certificato, SQL Server non può decrittografare i database crittografati con TDE né portarli online. In un gruppo di disponibilità indipendente, SQL Server controlla entrambi i database master per la chiave master del database, il database master in relazione all'istanza e il database indipendente master nel gruppo di disponibilità indipendente per decrittografare il database. Se non è possibile trovare il certificato in una delle due posizioni, SQL Server non sarà in grado di portare online il database.

Per trasferire la chiave master del database dal database master dell'istanza al database indipendente master, vedere Spostare un database protetto da TDE in un'altra istanza di SQL Server, concentrandosi principalmente sulle parti in cui la chiave master viene trasferita dal server precedente a quello nuovo.

Pacchetti SSIS e piani di manutenzione

L'uso di pacchetti SSIS, inclusi i piani di manutenzione, non è supportato con i gruppi di disponibilità indipendenti.

Modifiche DDL

Le uniche modifiche DDL sono nel flusso di lavoro CREATE AVAILABILITY GROUP. Esistono due nuove clausole WITH:

<with_option_spec> ::=
CONTAINED |
REUSE_SYSTEM_DATABASES

CONTAINED

Specifica che il gruppo di disponibilità creato deve essere un gruppo di disponibilità indipendente.

REUSE_SYSTEM_DATABASES

Questa opzione è valida solo per i gruppi di disponibilità indipendenti e specifica che il gruppo di disponibilità creato deve riutilizzare i database di sistema indipendenti esistenti per un gruppo di disponibilità indipendente precedente con lo stesso nome. Se ad esempio si dispone di un gruppo di disponibilità indipendente denominato MyContainedAG e si desidera eliminarlo e ricrearlo, è possibile usare questa opzione per riutilizzare il contenuto dei database di sistema indipendenti originali.

Modifiche DMV

Esistono due aggiunte alle DMV (viste a gestione dinamica) correlate ai gruppi di disponibilità indipendenti:

• La DMV sys.dm_exec_sessions ha un'ulteriore colonna: contained_availability_group_id
• Per la vista del catalogo sys.availability_groups è presente l'ulteriore colonna: is_contained

Contenuto correlato

• CREATE AVAILABILITY GROUP (Transact-SQL)