Wat is een ingesloten beschikbaarheidsgroep?

van toepassing op: SQL Server 2022 (16.x)

Een ingesloten beschikbaarheidsgroep is een AlwaysOn-beschikbaarheidsgroep (AG) die ondersteuning biedt voor:

• het beheren van metagegevensobjecten (gebruikers, aanmeldingen, machtigingen, SQL Agent-taken, enzovoort) op AG-niveau naast het exemplaarniveau.

• gespecialiseerde ingesloten systeemdatabases binnen de AG.

In dit artikel worden de overeenkomsten, verschillen en functionaliteiten van ingesloten AG's beschreven.

Overzicht

AG's bestaan over het algemeen uit een of meer gebruikersdatabases die zijn bedoeld om te werken als een gecoördineerde groep en die worden gerepliceerd op een aantal knooppunten in een cluster. Wanneer er een fout opgetreden is in het knooppunt of in de status van SQL Server op het knooppunt waarop de primaire kopie wordt gehost, wordt de groep databases verplaatst als een eenheid naar een ander replicaknooppunt in de AG. Alle gebruikersdatabases worden gesynchroniseerd over alle replica's van de beschikbaarheidsgroep, in een synchrone of asynchrone modus.

Dit werkt goed voor toepassingen die alleen met die set gebruikersdatabases werken, maar er zijn uitdagingen wanneer toepassingen ook afhankelijk zijn van objecten zoals gebruikers, aanmeldingen, machtigingen, agenttaken, enzovoort, die zijn opgeslagen in een van de systeemdatabases (master of msdb). Om de toepassingen soepel en voorspelbaar te laten functioneren, moet de beheerder handmatig ervoor zorgen dat wijzigingen in deze objecten worden gedupliceerd in alle replica-exemplaren in de beschikbaarheidsgroep. Als een nieuw exemplaar in de beschikbaarheidsgroep wordt gebracht, kunnen de databases automatisch of handmatig worden geseed in een eenvoudig proces, maar moeten alle aanpassingen van de systeemdatabase opnieuw worden geconfigureerd op het nieuwe exemplaar zodat deze overeenkomen met de andere replica's.

Ingesloten AG's breiden het concept uit van de groep databases die wordt gerepliceerd om relevante delen van de master en msdb databases op te nemen. Denk hieraan als de uitvoeringscontext voor toepassingen die de ingesloten AG gebruiken. Het idee is dat de ingesloten AG-omgeving instellingen bevat die van invloed zijn op de toepassing die erop vertrouwt. Als zodanig heeft de ingesloten AG-omgeving betrekking op alle databases waarmee de toepassing communiceert, de verificatie die wordt gebruikt (aanmeldingen, gebruikers, machtigingen), geplande taken die worden verwacht uit te voeren en andere configuratie-instellingen die van invloed zijn op de toepassing.

Dit verschilt van ingesloten databases, die gebruikmaken van een ander mechanisme voor de gebruikersaccounts, waarbij de gebruikersgegevens in de database zelf worden opgeslagen. Ingesloten databases repliceren alleen aanmeldingen en gebruikers en het bereik van de gerepliceerde aanmelding of gebruiker is beperkt tot die individuele database (en de bijbehorende replica's).

In een ingesloten beschikbaarheidsgroep kunt u daarentegen gebruikers, aanmeldingen, machtigingen enzovoort maken, op ag-niveau, en ze worden automatisch automatisch consistent in replica's in de AG, evenals consistent in databases binnen die ag. Hierdoor hoeft de beheerder deze wijzigingen niet handmatig aan te brengen.

Verschillen

Er zijn enkele praktische verschillen waarmee u rekening moet houden bij het werken met ingesloten AG's, zoals het maken van ingesloten systeemdatabases en het afdwingen van de verbinding op het niveau van de ingesloten AG, in plaats van verbinding te maken op exemplaarniveau.

Ingesloten systeemdatabases

Elke ingesloten beschikbaarheidsgroep heeft eigen master en msdb systeemdatabases, genoemd naar de naam van de beschikbaarheidsgroep. In ingesloten AG-MyContainedAGhebt u bijvoorbeeld databases met de naam MyContainedAG_master en MyContainedAG_msdb. Deze systeemdatabases worden automatisch geseed naar nieuwe replica's en updates worden gerepliceerd naar deze databases, net als elke andere database in een beschikbaarheidsgroep. Dit betekent dat wanneer u een object zoals een aanmeldingstaak of agenttaak toevoegt terwijl deze is verbonden met de ingesloten AG, wanneer de ingesloten AG een failover naar een ander exemplaar uitvoert, u nog steeds de agenttaken ziet en u zich kunt verifiëren met behulp van de aanmelding die is gemaakt in de ingesloten AG.

Belangrijk

Ingesloten AG's zijn een mechanisme voor het consistent houden van uitvoeringsomgevingconfiguraties in de replica's van een beschikbaarheidsgroep. Ze vertegenwoordigen geen beveiligingsgrens. Er is geen grens die een verbinding met een ingesloten AG ervan weerhoudt om toegang te krijgen tot databases buiten de AG, bijvoorbeeld.

De systeemdatabases in een nieuw gemaakte ag zijn geen kopieën van het exemplaar waarop de opdracht CREATE AVAILABILITY GROUP wordt uitgevoerd. Ze zijn in eerste instantie lege sjablonen zonder gegevens. Onmiddellijk na de creatie worden de beheerdersaccounts op het exemplaar dat de ingesloten AG creëert, gekopieerd naar de ingesloten AG (master). Op die manier kan de beheerder zich aanmelden bij de ingesloten beschikbaarheidsgroep (AG) en de rest van de configuratie instellen.

Als u lokale gebruikers of configuraties in uw exemplaar maakt, worden ze niet automatisch weergegeven wanneer u de ingesloten systeemdatabases maakt, en zijn ze ook niet zichtbaar wanneer u verbinding maakt met de ingesloten beschikbaarheidsgroep. Zodra de gebruikersdatabase is toegevoegd aan een ingesloten beschikbaarheidsgroep, is deze onmiddellijk niet toegankelijk voor deze gebruikers. U moet ze handmatig opnieuw maken in de ingesloten systeemdatabases binnen de context van de ingesloten AG door rechtstreeks verbinding te maken met de database of door het listener-eindpunt te gebruiken. De uitzondering hierop is dat alle aanmeldingen die de rol van sysadmin hebben in de bovenliggende instantie worden gekopieerd naar de nieuwe AG-specifieke master-database.

Notitie

Omdat de master-database afzonderlijk is voor elke ingesloten beschikbaarheidsgroep, worden activiteiten op serverbereik die worden uitgevoerd in de context van de ingesloten beschikbaarheidsgroep, alleen bewaard in de ingesloten systeemdatabase. Dit omvat controle. Als u activiteit op serverniveau controleert met SQL Server Auditing, moet u dezelfde servercontroles maken binnen elke ingesloten BESCHIKBAARHEIDSGROEP.

Een ingesloten systeemdatabase herstellen

U kunt een ingesloten systeemdatabase op twee verschillende manieren herstellen.

• Een ingesloten database herstellen met behulp van een secundaire replica:

  1. Herstel de ingesloten master en msdb database op een serverexemplaar dat de secundaire replica host, met behulp van RESTORE WITH NORECOVERY voor elke herstelbewerking. Zie Een secundaire database voorbereiden voor een AlwaysOn-beschikbaarheidsgroepvoor meer informatie.

  2. Voeg elke ingesloten database toe aan de beschikbaarheidsgroep. Zie Een secundaire database toevoegen aan een AlwaysOn-beschikbaarheidsgroepvoor meer informatie.

• een ingesloten database herstellen door de ingesloten AG-te verwijderen:

  1. Verwijder de ingesloten beschikbaarheidsgroep.

  2. Herstel de ingesloten master en msdb database in elk van de exemplaren die deelnemen aan de ingesloten beschikbaarheidsgroep.

  3. Recreëer de ingesloten AG met oorspronkelijke knooppunten en naam, met WITH (CONTAINED, REUSE_SYSTEM_DATABASES) syntaxis.

Bevatte beschikbaarheidsgroepwerkzaamheden

Taken die deel uitmaken van een ingesloten beschikbaarheidsgroep worden alleen uitgevoerd op de primaire replica. Ze worden niet uitgevoerd op secundaire replica's.

Verbinding maken (ingesloten omgeving)

Het is belangrijk om onderscheid te maken tussen het maken van verbinding met de instantie en het maken van verbinding met de bevatten AG. De enige manier om toegang te krijgen tot de omgeving van de ingesloten AG is om verbinding te maken met de ingesloten AG-listener of om verbinding te maken met een database die zich in de ingesloten AG bevindt.

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

Waar MyContainedDatabase een database is binnen de ingesloten AG waarmee u wilt interageren.

Dit betekent dat u een listener voor de ingesloten beschikbaarheidsgroep moet maken om effectief een ingesloten beschikbaarheidsgroep te kunnen gebruiken. Als u verbinding maakt met een van de exemplaren die als host fungeren voor de ingesloten AG in plaats van rechtstreeks naar de ingesloten AG te via de listener, bevindt u zich in de omgeving van het exemplaar en niet de ingesloten ag.

Als uw beschikbaarheidsgroep bijvoorbeeld MyContainedAG wordt gehost op de server SERVER\MSSQLSERVERen in plaats van verbinding te maken met de listener MyContainedAG_Listener, maakt u verbinding met het exemplaar met behulp van SERVER\MSSQLSERVER, bevindt u zich in de omgeving van het exemplaar en niet in de omgeving van MyContainedAG. Dit betekent dat u gebonden bent aan de inhoud (gebruikers, machtigingen, taken, enzovoort) die in de systeemdatabases van de instantie worden gevonden. Voor toegang tot de inhoud in de ingesloten systeemdatabases van de ingesloten AG maakt u in plaats daarvan verbinding met de ingesloten AG-listener (bijvoorbeeldMyContainedAG_Listener). Wanneer u bent verbonden met het exemplaar via de ingesloten AG-listener, wanneer u met mastercommuniceert, wordt u daadwerkelijk omgeleid naar de ingesloten master-database (bijvoorbeeld MyContainedAG_master).

Alleen-lezen routering en ingesloten beschikbaarheidsgroepen

Als u alleen-lezenroutering configureert om verbindingen met een leesintentie om te leiden naar een secundaire replica (zie Alleen-lezenroutering configureren voor een AlwaysOn-beschikbaarheidsgroep) en u verbinding wilt maken met behulp van een aanmelding die alleen in de ingesloten beschikbaarheidsgroep is gemaakt, zijn er enkele aanvullende overwegingen:

• U moet een database opgeven die deel uitmaakt van de contained AG in de verbindingsreeks
• De gebruiker die is opgegeven in de connectiestring, moet permissie hebben om toegang te krijgen tot de databases in de bevatte AG.

Bijvoorbeeld in de volgende verbindingsreeks, waarbij AdventureWorks een database is binnen de contained AG met MyContainedListeneren waarbij MyUser een gebruiker is die is gedefinieerd in de contained AG en niet in een van de deelnemende instanties:

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

Met deze verbindingsreeks hebt u verbinding gemaakt met de leesbare secundaire die deel uitmaakt van de configuratie readOnly-routering. U bevindt zich in de context van de ingesloten beschikbaarheidsgroep.

Verschillen tussen het maken van verbinding met het exemplaar en het maken van verbinding met de ingesloten beschikbaarheidsgroep

• Wanneer ze zijn verbonden met een ingesloten beschikbaarheidsgroep, zien gebruikers alleen databases in de ingesloten beschikbaarheidsgroep, plus tempdb.
• Op instantie-niveau zijn de ingesloten AG master en msdb namen [contained AG]_masteren [contained AG]_msdb. Binnen de ingesloten AG worden hun namen master en msdb.
• De database-id voor de ingesloten AG master is 1 vanuit de ingesloten AG, maar iets anders wanneer verbonden met het exemplaar.
• Hoewel gebruikers geen databases buiten de ingesloten AG in sys.databases zien wanneer ze verbonden zijn via een ingesloten AG-verbinding, kunnen ze toegang verkrijgen tot die databases met een driedelige naam of via de opdracht USE.
• Serverconfiguratie via sp_configure kan worden gelezen vanuit de ingesloten AG-verbinding, maar kan alleen worden geschreven vanaf exemplaarniveau.
• Vanuit ingesloten AG-verbindingen kan de systeembeheerder bewerkingen op exemplaarniveau uitvoeren, zoals het afsluiten van SQL Server.
• De meeste bewerkingen op databaseniveau, eindpuntniveau of AG-niveau kunnen alleen worden uitgevoerd vanuit exemplaarverbindingen, niet vanuit contained AG-verbindingen.

Interacties met andere functies

Er zijn aanvullende overwegingen bij het gebruik van bepaalde functies met ingesloten AG's en er zijn enkele functies die momenteel niet worden ondersteund.

Reservekopie maken

Procedures voor het maken van back-ups van databases in een ingesloten beschikbaarheidsgroep zijn hetzelfde als back-upprocedures voor gebruikersdatabases. Dit geldt voor zowel de ingesloten AG-gebruikersdatabases als de ingesloten AG-systeemdatabases.

Als de back-uplocatie lokaal is, worden de back-upbestanden op de server geplaatst waarop de back-uptaak wordt uitgevoerd. Dit betekent dat uw back-upbestanden zich mogelijk op verschillende locaties bevinden.

Als de back-uplocatie zich op een netwerkresource bevindt, hebben alle servers die replica's hosten toegang nodig tot die resource.

Resourcesbeheerder

Resource governor werkt op exemplaarniveau. Resource governor met een ingesloten beschikbaarheidsgroep is niet van toepassing.

DDL-opdrachten voor resource governor-configuratie hebben geen effect wanneer ze worden uitgevoerd op een ingesloten beschikbaarheidsgroepverbinding.

Als resource governor is ingeschakeld via een exemplaarverbinding, heeft dit geen invloed op de ingesloten beschikbaarheidsgroepverbindingen.

Gegevens vastleggen wijzigen

Change Data Capture (CDC) wordt geïmplementeerd als SQL Agent-taken, dus de SQL Agent moet worden uitgevoerd op alle exemplaren met replica's in de ingesloten AG.

Als u wijzigingsgegevens vastleggen wilt gebruiken met een ingesloten AG, maakt u verbinding met de AG-listener wanneer u CDC configureert, zodat de CDC-metagegevens worden geconfigureerd door de ingesloten systeemdatabases te gebruiken.

Logboekverzending

Logboekverzending kan worden geconfigureerd als de brondatabase zich in de ingesloten beschikbaarheidsgroep (contained AG) bevindt. Een verzenddoel voor logboeken wordt echter niet ondersteund binnen een ingesloten AG. Daarnaast is er een extra stap voor het wijzigen van de taak voor het verzenden van logboeken nadat CDC is geconfigureerd.

Volg deze stappen om log shipping met een zelfstandige beschikbaarheidsgroep te configureren:

1. Maak verbinding met de ingesloten AG-listener.
2. Configureer logboekverzending zoals u dat normaal zou doen.
3. Nadat de logboekverzendingstaak is geconfigureerd, wijzigt u de taak om verbinding te maken met de ingesloten AG-listener voordat u een back-up maakt.

Transparent Data Encryption (TDE)

Als u TDE (Transparent Data Encryption) wilt gebruiken met databases in een ingesloten beschikbaarheidsgroep, installeert u de DATABASE Master Key (DMK) handmatig op de ingesloten master-database in de ingesloten BESCHIKBAARHEIDSGROEP.

Databases die gebruikmaken van TDE zijn afhankelijk van certificaten in de master-database om de DEK (Database Encryption Key) te ontsleutelen. Zonder dat certificaat kan SQL Server databases die zijn versleuteld met TDE niet ontsleutelen of online brengen. In een ingesloten beschikbaarheidsgroep controleert SQL Server beide master-databases op de DMK, de master-database voor het exemplaar en de ingesloten master-database binnen de beschikbaarheidsgroep om de database te ontsleutelen. Als het certificaat niet op een van beide locaties kan worden gevonden, kan SQL Server de database niet online brengen.

Als u de DMK wilt overdragen van de master-database van de instance naar de ingesloten master-database, raadpleegt u Een met TDE beveiligde database verplaatsen naar een andere SQL Server, met de nadruk op de gedeelten waar de DMK van de oude server naar de nieuwe wordt overgebracht.

SSIS-pakketten & onderhoudsplannen

Het gebruik van SSIS-pakketten, inclusief onderhoudsplannen, wordt niet ondersteund met ingesloten beschikbaarheidsgroepen.

Niet ondersteund

Momenteel worden de volgende SQL Server-functies niet ondersteund met een Contained Availability Group (CAG):

• SQL Server-replicatie van elk type (transactionele, samenvoeging, momentopname, enzovoort).
• Gedistribueerde beschikbaarheidsgroepen.
• Log shipping waarbij de doeldatabase zich in de gesloten AG bevindt. Logboekverzending met de brondatabase in de ingesloten beschikbaarheidsgroep wordt ondersteund.

DDL-wijzigingen

De enige DDL-wijzigingen bevinden zich in de CREATE AVAILABILITY GROUP werkstroom. Er zijn twee nieuwe WITH-clausules:

<with_option_spec> ::=
CONTAINED |
REUSE_SYSTEM_DATABASES

INGESLOTEN

Hiermee wordt aangegeven dat de te maken AG een ingesloten AG moet zijn.

REUSE_SYSTEM_DATABASES

Deze optie is alleen geldig voor ingesloten AG's en geeft aan dat de zojuist gemaakte AG bestaande ingesloten systeemdatabases opnieuw moet gebruiken voor een eerdere ingesloten AG met dezelfde naam. Als u bijvoorbeeld een ingesloten beschikbaarheidsgroep met de naam MyContainedAGhebt en deze wilt verwijderen en opnieuw wilt maken, kunt u deze optie gebruiken om de inhoud van de oorspronkelijke ingesloten systeemdatabases opnieuw te gebruiken.

DMV-wijzigingen

Er zijn twee toevoegingen aan DMV's met betrekking tot ingesloten AG's:

• De DMV-sys.dm_exec_sessions heeft een toegevoegde kolom: contained_availability_group_id
• De sys.availability_groups catalogusweergave bevat de toegevoegde kolom: is_contained

Verwante inhoud

• AANMAKEN AVAILABILITY GROUP (Transact-SQL)