Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of mappen te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen om mappen te wijzigen.
Van toepassing op:SQL Server
AlwaysOn-beschikbaarheidsgroepen (AG's) vereisen een onderliggend Windows Server-failovercluster (WSFC). Voor het implementeren van een WSFC via Windows Server 2012 R2 is vereist dat de servers die deelnemen aan een WSFC, ook wel knooppunten genoemd, lid zijn van hetzelfde domein. Zie Wat zijn domeinen en foresten? voor meer informatie over Active Directory Domain Services (AD DS)
De afhankelijkheid van AD DS en WSFC is complexer dan eerder is geïmplementeerd met een databasespiegelingsconfiguratie (DBM), omdat DBM kan worden geïmplementeerd in meerdere datacenters met behulp van certificaten, zonder dergelijke afhankelijkheden. Een traditionele beschikbaarheidsgroep die meerdere datacenters beslaat, vereist dat alle servers lid moeten zijn van hetzelfde Active Directory-domein. Verschillende domeinen, zelfs vertrouwde domeinen, werken niet. Alle servers moeten knooppunten van dezelfde WSFC zijn. In de volgende afbeelding ziet u deze configuratie. SQL Server 2016 (13.x) en latere versies hebben ook gedistribueerde AG's, waardoor dit doel op een andere manier wordt bereikt.
Windows Server 2012 R2 heeft een Active Directory-losgekoppeld cluster geïntroduceerd, een gespecialiseerde vorm van een Windows Server-failovercluster, dat kan worden gebruikt met beschikbaarheidsgroepen. Dit type WSFC vereist nog steeds dat de knooppunten lid zijn van hetzelfde Active Directory-domein, maar in dit geval gebruikt de WSFC DNS, maar niet het domein. Aangezien een domein nog steeds betrokken is, biedt een cluster dat is losgekoppeld van Active Directory nog steeds geen domeinvrije ervaring.
Windows Server 2016 heeft een nieuw type Windows Server-failovercluster geïntroduceerd op basis van de basis van het Active Directory-ontkoppelde cluster: een werkgroepcluster. Met een werkgroepcluster kan SQL Server een beschikbaarheidsgroep implementeren boven op een WSFC waarvoor AD DS niet is vereist. SQL Server vereist het gebruik van certificaten voor eindpuntbeveiliging, net zoals voor het scenario voor databasespiegeling certificaten zijn vereist. Dit type beschikbaarheidsgroep wordt een domeinonafhankelijke beschikbaarheidsgroep genoemd. Het implementeren van een beschikbaarheidsgroep met een onderliggend werkgroepcluster ondersteunt de volgende combinaties voor de knooppunten waaruit de WSFC bestaat:
- Er zijn geen knooppunten gekoppeld aan een domein.
- Alle knooppunten worden gekoppeld aan verschillende domeinen.
- Er is een mix van domein-gekoppelde en niet-domein-gekoppelde knooppunten.
In de volgende afbeelding ziet u een voorbeeld van een domeinonafhankelijke beschikbaarheidsgroep waarbij de knooppunten in Data Center 1 lid zijn van een domein, maar de knooppunten in Data Center 2 alleen DNS gebruiken. In dit geval stelt u het DNS-achtervoegsel in op alle servers die knooppunten van de WSFC zijn. Elke toepassing en server die toegang heeft tot de beschikbaarheidsgroep, moeten dezelfde DNS-gegevens zien.
Een domeinonafhankelijke beschikbaarheidsgroep is niet alleen bedoeld voor scenario's met meerdere sites of herstel na noodgevallen. U kunt het implementeren in één datacenter en zelfs gebruiken met een eenvoudige beschikbaarheidsgroep. Deze configuratie biedt een vergelijkbare architectuur als wat mogelijk is met behulp van databasespiegeling met certificaten, zoals wordt weergegeven.
Het implementeren van een domeinonafhankelijke beschikbaarheidsgroep kent enkele bekende opmerkingen:
De enige witness-typen die beschikbaar zijn voor gebruik met quorum zijn schijf en cloud, wat nieuw is in Windows Server 2016. Schijf is problematisch omdat er waarschijnlijk geen gebruik wordtgemaakt van gedeelde schijven door de beschikbaarheidsgroep.
De onderliggende werkgroepclustervariant van een WSFC kan alleen worden gemaakt met behulp van PowerShell, maar kan vervolgens worden beheerd met de Failover Cluster Manager.
Als Kerberos is vereist, moet u een standaard WSFC implementeren die is gekoppeld aan een Active Directory-domein en een domeinonafhankelijke beschikbaarheidsgroep is waarschijnlijk geen optie.
Hoewel een listener kan worden geconfigureerd, moet deze worden geregistreerd in DNS om te kunnen worden gebruikt. Zoals eerder vermeld, is er geen Kerberos-ondersteuning voor de listener.
Toepassingen die verbinding maken met SQL Server moeten voornamelijk GEBRUIKMAKEN van SQL Server-verificatie, omdat domeinen mogelijk niet bestaan of niet zijn geconfigureerd om samen te werken.
Certificaten worden gebruikt in de configuratie van de beschikbaarheidsgroep.
Het DNS-achtervoegsel op alle replicaservers instellen en controleren
Een gemeenschappelijk DNS-achtervoegsel is nodig voor het werkgroepcluster van een domeinonafhankelijke beschikbaarheidsgroep. Als u het DNS-achtervoegsel wilt instellen en controleren op elke Windows Server die als host fungeert voor een replica voor de beschikbaarheidsgroep, volgt u deze instructies:
- Selecteer Systeem met de Windows-toets + X.
- Als de computernaam en de volledige computernaam hetzelfde zijn, is het DNS-achtervoegsel niet ingesteld. Als de computernaam bijvoorbeeld is
SERVER1, mag de waarde voor de volledige computernaam niet alleenSERVER1zijn. Het zou iets moeten zijn alsSERVER1.CONTOSO.LAB.CONTOSO.LABis het DNS-achtervoegsel. De waarde voor Werkgroep moet zeggenWORKGROUP. Als u het DNS-achtervoegsel wilt instellen, selecteert u Instellingen wijzigen. - Selecteer Wijzigen op het tabblad Computernaam in het dialoogvenster Systeemeigenschappen.
- Selecteer Meer in het dialoogvenster Computernaam/Domeinwijzigingen.
- Voer in het dialoogvenster DNS-achtervoegsel en NetBIOS-computernaam het algemene DNS-achtervoegsel in als het primaire DNS-achtervoegsel .
- Selecteer OK om het dialoogvenster DNS-achtervoegsel en NetBIOS-computernaam te sluiten.
- Selecteer OK om het dialoogvenster Computernaam/Domeinwijzigingen te sluiten.
- U wordt gevraagd de server opnieuw op te starten om de wijzigingen van kracht te laten worden. Selecteer OK om het dialoogvenster Computernaam/Domeinwijzigingen te sluiten.
- Selecteer Sluiten om het dialoogvenster Systeemeigenschappen te sluiten.
- U wordt gevraagd om opnieuw op te starten. Als u niet onmiddellijk opnieuw wilt opstarten, selecteert u Later opnieuw opstarten, anders selecteert u Nu opnieuw opstarten.
- Nadat de server opnieuw is opgestart, controleert u of het algemene DNS-achtervoegsel is geconfigureerd door het systeem opnieuw te bekijken.
Opmerking
Als u meerdere subnetten gebruikt en een statische DNS hebt, moet u een proces hebben om de DNS-record bij te werken die is gekoppeld aan de listener voordat u een failover uitvoert, omdat anders de netwerknaam niet online komt.
Een domeinonafhankelijke beschikbaarheidsgroep maken
Het maken van een domeinonafhankelijke beschikbaarheidsgroep kan momenteel niet volledig worden bereikt met behulp van SQL Server Management Studio. Hoewel het maken van de domeinonafhankelijke beschikbaarheidsgroep in feite hetzelfde is als het maken van een normale beschikbaarheidsgroep, zijn bepaalde aspecten (zoals het maken van de certificaten) alleen mogelijk met Transact-SQL. In het volgende voorbeeld wordt uitgegaan van een configuratie van een beschikbaarheidsgroep met twee replica's: één primaire en één secundaire.
Gebruik de instructies van werkgroep- en multidomeinclusters in Windows Server 2016 om een werkgroepcluster te implementeren dat bestaat uit alle servers die deelnemen aan de beschikbaarheidsgroep. Zorg ervoor dat het algemene DNS-achtervoegsel al is geconfigureerd voordat u het werkgroepcluster configureert.
Schakel de functie AlwaysOn-beschikbaarheidsgroep in of uit voor elk exemplaar dat deelneemt aan de beschikbaarheidsgroep. Hiervoor moet elke SQL Server-instantie opnieuw worden opgestart.
Voor elk exemplaar dat als host fungeert voor de primaire replica, is een DMK (Database Master Key) vereist. Als er nog geen DMK bestaat, voert u de volgende opdracht uit:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Strong Password'; GOMaak op het exemplaar dat de primaire replica is het certificaat dat wordt gebruikt voor binnenkomende verbindingen op de secundaire replica's en voor het beveiligen van het eindpunt op de primaire replica.
CREATE CERTIFICATE InstanceA_Cert WITH SUBJECT = 'InstanceA Certificate'; GOMaak een back-up van het certificaat. U kunt deze desgewenst ook verder beveiligen met een persoonlijke sleutel. In dit voorbeeld wordt geen persoonlijke sleutel gebruikt.
BACKUP CERTIFICATE InstanceA_Cert TO FILE = 'Backup_path\InstanceA_Cert.cer'; GOHerhaal stap 4 en 5 om certificaten voor elke secundaire replica te maken en er een back-up van te maken, met behulp van de juiste namen voor de certificaten, zoals
InstanceB_Cert.Op de primaire replica moet u een aanmelding maken voor elke secundaire replica van de beschikbaarheidsgroep. Aan deze aanmelding worden machtigingen verleend om verbinding te maken met het eindpunt dat wordt gebruikt door de onafhankelijke beschikbaarheidsgroep van het domein. Bijvoorbeeld voor een replica met de naam
InstanceB:CREATE LOGIN InstanceB_Login WITH PASSWORD = 'Strong Password'; GOMaak op elke secundaire replica een aanmelding voor de primaire replica. Aan deze aanmelding worden machtigingen verleend om verbinding te maken met het eindpunt. Bijvoorbeeld op een replica met de naam
InstanceB:CREATE LOGIN InstanceA_Login WITH PASSWORD = 'Strong Password'; GOMaak in alle gevallen een gebruiker voor elke aanmeldingssessie die is gemaakt. Deze gebruiker wordt gebruikt bij het herstellen van de certificaten. Als u bijvoorbeeld een gebruiker wilt maken voor de primaire replica:
CREATE USER InstanceA_User FOR LOGIN InstanceA_Login; GOVoor elke replica die mogelijk primair is, maak een login en gebruiker aan op alle relevante secundaire replica's.
Herstel op elk exemplaar de certificaten voor de andere exemplaren met een bestaande inlog en gebruiker. Zet alle certificaten van secundaire replica's terug op de primaire replica. Herstel op elke secundaire het certificaat op de primaire replica en ook op andere replica's die een primaire kunnen zijn. Voorbeeld:
CREATE CERTIFICATE [InstanceB_Cert] AUTHORIZATION InstanceB_User FROM FILE = 'Restore_path\InstanceB_Cert.cer';Maak het eindpunt dat wordt gebruikt door de beschikbaarheidsgroep op elk exemplaar dat een replica is. Voor beschikbaarheidsgroepen moet het eindpunt een type
DATABASE_MIRRORINGhebben. Het eindpunt gebruikt het certificaat dat in stap 4 is gemaakt voor verificatie. De syntaxis wordt weergegeven in het volgende voorbeeld om een eindpunt te maken met behulp van een certificaat. Gebruik de juiste versleutelingsmethode en andere opties die relevant zijn voor uw omgeving. Zie CREATE ENDPOINT voor meer informatie over de beschikbare opties.CREATE ENDPOINT DIAG_EP STATE = STARTED AS TCP ( LISTENER_PORT = 5022, LISTENER_IP = ALL ) FOR DATABASE_MIRRORING ( AUTHENTICATION = CERTIFICATE InstanceX_Cert, ROLE = ALL );Wijs rechten toe aan elke aanmelding die in stap 8 is gemaakt om verbinding te kunnen maken met het eindpunt.
GRANT CONNECT ON ENDPOINT::DIAG_EP TO [InstanceX_Login]; GOZodra de onderliggende certificaten en eindpuntbeveiliging zijn geconfigureerd, maakt u de beschikbaarheidsgroep met behulp van uw voorkeursmethode. Maak handmatig een back-up, kopieer en herstel de back-up die wordt gebruikt om de secundaire server te initialiseren, of je maakt gebruik van automatische seeding. Het gebruik van de wizard voor het initialiseren van de secundaire replica's omvat het gebruik van SMB-bestanden (Server Message Block), wat mogelijk niet werkt wanneer u een werkgroepcluster gebruikt dat niet lid is van een domein.
Als u een listener maakt, moet u ervoor zorgen dat zowel de naam als het IP-adres ervan zijn geregistreerd in DNS.