Cos'è un gruppo di disponibilità contenuto?

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

Un gruppo di disponibilità contenuto è un gruppo di disponibilità Always On (AG) che supporta:

• 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 specializzati contenuti 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à (AG) sono in genere costituiti da uno o più database utente destinati a funzionare come gruppo coordinato e che vengono replicati su un certo numero di nodi all'interno di 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 dell'Availability Group, 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 nell'AG. Se una nuova istanza viene portata nel gruppo di disponibilità (AG), è possibile eseguire il seeding dei database automaticamente o manualmente in modo semplice, ma tutte le personalizzazioni del database di sistema devono essere riconfigurate nella nuova istanza affinché corrispondano alle altre repliche.

I gruppi di disponibilità contenuti 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à contenuto AG. L'idea è che l'ambiente AG contenuto includa impostazioni che potrebbero influire sull'applicazione che dipende da esse. Di conseguenza, l'ambiente AG contenuto riguarda tutti i database con cui l'applicazione interagisce, l'autenticazione utilizzata (account di accesso, utenti, permessi), i processi pianificati che l'applicazione si aspetta siano in 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 lavora con gruppi di disponibilità contenuti, ad esempio la creazione di database di sistema contenuti e la forzatura della connessione a livello di gruppo di disponibilità contenuto, invece di connettersi a livello di istanza.

Database di sistema contenuti

Ogni gruppo di disponibilità contenuto dispone dei propri database di sistema master e msdb, che hanno lo stesso nome del gruppo di disponibilità. Nel MyContainedAG contenuto AG, ad esempio, sono presenti database denominati MyContainedAG_master e MyContainedAG_msdb. Questi database di sistema ricevono automaticamente il seeding su nuove repliche e gli aggiornamenti vengono replicati su questi database proprio 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à contenuti sono un meccanismo per 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à Contenuto e completare 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. Dopo che il database utente è stato aggiunto a un gruppo di disponibilità contenuta, diventerà immediatamente inaccessibile per questi utenti. È necessario ricrearli manualmente nei database di sistema indipendenti nel contesto del gruppo di disponibilità indipendente collegandoli direttamente al database oppure utilizzando l’endpoint listener. L'eccezione è che tutti gli account di accesso nel ruolo sysadmin nell'istanza padre vengono copiati nel nuovo database specifico del gruppo di disponibilità (AG) master.

Nota

Poiché il database master è separato per ogni gruppo di disponibilità indipendente, le attività dell'ambito server eseguite nel contesto del gruppo di disponibilità indipendente vengono mantenute solo nel database di sistema indipendente. Ciò include il controllo. Se si effettua l'audit dell'attività a livello di istanza di server con il sistema di auditing di SQL Server, è necessario creare gli stessi audit del server all'interno di ciascun AG contenuto.

Ripristinare un database di sistema contenuto

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

• Ripristinare un database contenuto usando una replica secondaria:

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

  2. Unire ogni database contenuto al gruppo di disponibilità. Per ulteriori informazioni, consultare Unire un database secondario a un gruppo di disponibilità Always On.

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

  1. Rimuovere il gruppo di disponibilità contenuto.

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

  3. Ricreare l'AG contenuto utilizzando i nodi e il nome originali, usando la sintassi WITH (CONTAINED, REUSE_SYSTEM_DATABASES).

Processi del gruppo di disponibilità contenuto

I lavori che appartengono a un gruppo di disponibilità contenuto vengono eseguiti solo sulla replica primaria. Non vengono eseguiti su repliche secondarie.

Effettuare la connessione (ambiente contenuto)

È 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à contenuto 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à contenuti

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 desidera connettersi usando un login creato solo nel gruppo di disponibilità contenuto, ci sono alcune considerazioni aggiuntive da tenere presente:

• È 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 degli AG 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à contenuto è 1 dall'interno del gruppo, ma è diverso quando si effettua la connessione all'istanza.
• Anche se gli utenti non vedono i database al di fuori del gruppo di disponibilità indipendente in sys.databases quando sono connessi a una connessione AG contenuta, possono accedere a questi 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.

Esegui backup

Le procedure per eseguire il backup dei database in un gruppo di disponibilità indipendente sono identiche a tutte le procedure di backup del database utente. Questo vale sia per i database utente contenuti nel gruppo di disponibilità che per i database di sistema contenuti nel gruppo di disponibilità.

Se il percorso di backup è locale, i file di backup vengono memorizzati sul server che esegue il processo di backup. Ciò significa che i file di backup possono trovarsi in posizioni diverse.

Se il percorso di backup si trova in una risorsa di rete, tutti i server che ospitano le repliche devono accedere a tale risorsa.

Governatore delle Risorse

In SQL Server 2022 (16.x) prima dell'aggiornamento cumulativo 18 e nelle versioni precedenti di SQL Server, la configurazione o l'uso di Resource Governor nelle connessioni del gruppo di disponibilità indipendente non è supportata.

A partire da SQL Server 2022 (16.x) Aggiornamento cumulativo 18, se si configura il Resource Governor su una connessione all'istanza, il consumo di risorse nelle connessioni di istanza o nelle connessioni del gruppo di disponibilità contenuto viene regolato come previsto. Se si tenta di configurare Resource Governor in una connessione al gruppo di disponibilità indipendente, viene visualizzato un errore.

Resource Governor funziona a livello di istanza del motore di database. La configurazione di Resource Governor a livello di istanza non viene propagata alle repliche di disponibilità. È necessario configurare Resource Governor in ogni istanza che ospita una replica di disponibilità.

Suggerimento

È consigliabile usare la stessa configurazione di Resource Governor per tutte le istanze del motore di database che ospitano repliche di disponibilità per garantire un comportamento coerente quando si verificano failover del gruppo di disponibilità.

Per altre informazioni, vedere Esempi di configurazione di Resource Governor e Resource Governor e procedure consigliate.

Cattura delle modifiche ai dati

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.

Spedizione dei log

Il log shipping può essere configurato se il database di origine si trova nell'AG contenuto. Tuttavia, una destinazione per il log shipping non è supportata all'interno di un gruppo di disponibilità contenuto. È 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à contenuti.

Non supportato

Attualmente, le seguenti funzionalità di SQL Server non sono supportate in un gruppo di disponibilità contenuto:

• 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 nell'AG contenuto. Il log shipping con il database di origine nell'AG contenuto è supportato.

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

CONTENUTO

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

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. Ad esempio, se si dispone di un AG contenuto denominato MyContainedAG e si desidera eliminarlo e ricrearlo, è possibile utilizzare questa opzione per riutilizzare i contenuti dei database di sistema contenuti originali.

Modifiche alla Motorizzazione Civile

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

• 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

• CREA GRUPPO DI DISPONIBILITÀ (Transact-SQL)