Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:
SQL Server
In dit artikel leert u hoe u verbinding maakt met een AlwaysOn-beschikbaarheidsgroeplistener voor SQL Server. Een listener voor beschikbaarheidsgroepen is een naam voor een virtueel netwerk die clients gebruiken om verbinding te maken met een database die wordt gehost in een beschikbaarheidsgroep. De listener biedt een consistent verbindingseindpunt voor clienttoepassingen, ongeacht welke beschikbaarheidsreplica momenteel als host fungeert voor de primaire database. De listener biedt ook ondersteuning voor read-only routing en automatische failover.
Nadat u de listener hebt geconfigureerd, werkt u de verbindingsreeksen bij zodat het toepassingsverkeer automatisch naar de beoogde replica wordt gerouteerd zonder dat u de verbindingsreeks na elke failover handmatig hoeft bij te werken.
Verbinding maken met de primaire replica
Geef de DNS-naam van de listener van de beschikbaarheidsgroep op in de verbindingsreeks om verbinding te maken met de primaire replica voor lees-schrijftoegang.
Als u bijvoorbeeld via de listener verbinding wilt maken met de primaire replica in SQL Server Management Studio, voert u de DNS-naam van de listener in het veld servernaam in:
Wanneer tijdens een failover de primaire replica wordt gewijzigd, worden bestaande verbindingen met de listener verbroken en worden nieuwe verbindingen doorgestuurd naar de nieuwe primaire replica.
Een voorbeeld van een eenvoudige verbindingsreeks voor de ADO.NET-provider (Microsoft.Data.SqlClient of System.Data.SqlClient):
Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI
Opmerking
Microsoft.Data.SqlClient is de aanbevolen ADO.NET gegevensprovider voor het ontwikkelen van nieuwe toepassingen. Het ondersteunt dezelfde trefwoorden voor verbindingsreeksen als System.Data.SqlClient. Zie Inleiding tot de naamruimte Microsoft.Data.SqlClient voor meer informatie.
U kunt controleren met welke replica u momenteel bent verbonden via de listener door de volgende Transact-SQL (T-SQL)-opdracht uit te voeren:
SELECT @@SERVERNAME
Als SQLVM1 bijvoorbeeld de primaire replica is:
U kunt nog steeds rechtstreeks verbinding maken met het exemplaar van SQL Server met behulp van de exemplaarnaam van de primaire of secundaire replica in plaats van de listener voor de beschikbaarheidsgroep te gebruiken. U verliest echter het voordeel dat nieuwe verbindingen automatisch worden gerouteerd naar de nieuwe huidige primaire replica. Bovendien verliest u het voordeel van alleen-lezen-routering, waarbij de verbindingen die met read-intent zijn opgegeven, automatisch naar de leesbare secundaire replica worden gerouteerd.
Verbinding maken met een alleen-lezen replica
Alleen-lezenroutering verwijst naar het automatisch routeren van binnenkomende listenerverbindingen naar een leesbare secundaire replica die is geconfigureerd om alleen-lezenworkloads toe te staan.
Verbindingen worden automatisch doorgestuurd naar de alleen-lezen replica als het volgende waar is:
Ten minste één secundaire replica is ingesteld op alleen-lezentoegang en elke alleen-lezen secundaire replica en de primaire replica zijn geconfigureerd ter ondersteuning van alleen-lezenroutering.
De verbindingsreeks verwijst naar een database die betrokken is bij de beschikbaarheidsgroep. Een alternatief hiervoor zou zijn dat de database die is geconfigureerd als standaarddatabase, wordt gebruikt door de aanmelding in de verbinding. Voor meer informatie, zie dit artikel over hoe het algoritme werkt met alleen-lezen routering.
De verbindingsreeks verwijst naar een listener voor een beschikbaarheidsgroep en de toepassingsintentie van de binnenkomende verbinding is ingesteld op alleen-lezen (bijvoorbeeld met behulp van het trefwoord Application Intent=ReadOnly in de ODBC- of OLEDB-verbindingsreeksen of verbindingskenmerken of -eigenschappen).
Het kenmerk voor de intentie van de toepassing wordt tijdens de aanmelding opgeslagen in de sessie van de client. Het exemplaar van SQL Server verwerkt de intentie en bepaalt wat er moet worden uitgevoerd volgens de configuratie van de beschikbaarheidsgroep en de huidige lees-/schrijfstatus van de doeldatabase in de secundaire replica.
Als u bijvoorbeeld verbinding wilt maken met een alleen-lezen replica met behulp van SQL Server Management Studio, selecteert u Opties in het dialoogvenster Verbinding maken met server , selecteert u het tabblad Aanvullende verbindingsparameters en geeft u ApplicationIntent=ReadOnly het volgende op in het tekstvak:
Een voorbeeld van een verbindingsreeks voor de ADO.NET-provider (Microsoft.Data.SqlClient of System.Data.SqlClient) die de intentie alleen-lezentoepassing aangeeft:
Server=tcp:AGListener;Database=AdventureWorks;Integrated Security=SSPI;ApplicationIntent=ReadOnly
Zie Read-Only-toegang configureren op een beschikbaarheidsreplica (SQL Server) voor meer informatie
Niet-standaardpoort
Wanneer u uw listener maakt, wijst u een poort aan die de listener moet gebruiken. Als de poort de standaardpoort van 1433 is, hoeft u geen poortnummer op te geven wanneer u verbinding maakt met uw listener. Als de poort niet 1433 is, moet de poort echter worden opgegeven in de verbindingsreeks in het formaat van listenername,port zoals:
Een voorbeeld van een verbindingsreeks voor de ADO.NET-provider (Microsoft.Data.SqlClient of System.Data.SqlClient) die een niet-standaardpoort voor de listener opgeeft:
Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI
Listeners overslaan
Hoewel listeners van beschikbaarheidsgroepen ondersteuning bieden voor failoveromleiding en alleen-lezenroutering, hoeven clientverbindingen deze niet te gebruiken. Een clientverbinding kan ook rechtstreeks verwijzen naar het exemplaar van SQL Server in plaats van verbinding te maken met de listener van de beschikbaarheidsgroep.
Voor het exemplaar van SQL Server is het niet relevant of een verbinding zich aanmeldt met behulp van de listener van de beschikbaarheidsgroep of een ander exemplaareindpunt. Het exemplaar van SQL Server controleert de status van de doeldatabase en staat connectiviteit toe of weigert deze op basis van de configuratie van de beschikbaarheidsgroep en de huidige status van de database op het exemplaar. Als een clienttoepassing bijvoorbeeld rechtstreeks verbinding maakt met een exemplaar van de SQL Server-poort en verbinding maakt met een doeldatabase die wordt gehost in een beschikbaarheidsgroep en de doeldatabase zich in de primaire staat bevindt en online is, slaagt de verbinding. Als de doeldatabase offline is of een overgangsstatus heeft, mislukt de verbinding met de database.
U kunt ook tijdens het migreren van databasespiegeling naar Always On-beschikbaarheidsgroepen de verbindingsreeks voor databasespiegeling opgeven zolang er maar één secundaire replica bestaat en gebruikersverbindingen niet zijn toegestaan.
Verbindingsreeksen voor database-mirroring
Als een beschikbaarheidsgroep slechts één secundaire replica bezit en is geconfigureerd met ALLOW_CONNECTIONS = READ_ONLY of ALLOW_CONNECTIONS = NONE voor de secundaire replica, kunnen clients verbinding maken met de primaire replica met behulp van een databasespiegelingsreeks. Deze benadering kan handig zijn bij het migreren van een bestaande toepassing van databasespiegeling naar een beschikbaarheidsgroep, zolang u de beschikbaarheidsgroep beperkt tot twee beschikbaarheidsreplica's (een primaire replica en één secundaire replica). Als u extra secundaire replica's toevoegt, moet u een listener voor beschikbaarheidsgroepen maken voor de beschikbaarheidsgroep en uw toepassingen bijwerken om de DNS-naam van de beschikbaarheidsgroeplistener te gebruiken.
Wanneer u verbindingsreeksen voor databasespiegeling gebruikt, kan de client SQL Server Native Client of .NET Framework-gegevensprovider voor SQL Server gebruiken. De verbindingsreeks die door een client wordt geleverd, moet minimaal de naam van één serverexemplaar, de initiële partnernaam, opgeven om de serverexemplaar te identificeren die aanvankelijk als host fungeert voor de beschikbaarheidsreplica waarmee u verbinding wilt maken. Optioneel kan de verbindingsreeks ook de naam van een andere serverinstantie, de failoverpartnernaam, opgeven om de serverinstantie te identificeren die aanvankelijk de secundaire replica host als de failoverpartnernaam.
Zie Clients verbinden met een databasespiegelingssessie (SQL Server) voor meer informatie over verbindingsreeksen voor databasespiegeling.
Failovers met meerdere subnetten
Als u clientbibliotheken gebruikt die ondersteuning bieden voor de verbindingsoptie MultiSubnetFailover in de verbindingsreeks, kunt u failover van beschikbaarheidsgroepen optimaliseren naar een ander subnet door MultiSubnetFailover in te stellen op True of Ja, afhankelijk van de syntaxis van de provider die u gebruikt.
Opmerking
We raden deze instelling aan voor zowel enkele als meerdere subnetverbindingen met beschikbaarheidsgroep-luisteraars en namen van SQL Server-failoverclusterinstanties. Als u deze optie inschakelt, worden extra optimalisaties toegevoegd, zelfs voor scenario's met één subnet.
De optie MultiSubnetFailover-verbinding werkt alleen met het TCP-netwerkprotocol en wordt alleen ondersteund wanneer u verbinding maakt met een listener van een beschikbaarheidsgroep en voor elke naam van het virtuele netwerk die verbinding maakt met SQL Server.
Een voorbeeld van de ADO.NET-provider (Microsoft.Data.SqlClient of System.Data.SqlClient) verbindingsreeks die failover met meerdere subnetten mogelijk maakt, is als volgt:
Server=tcp:AGListener,1433;Database=AdventureWorks;Integrated Security=SSPI; MultiSubnetFailover=True
De verbindingsoptie MultiSubnetFailover moet worden ingesteld op True , zelfs als de beschikbaarheidsgroep slechts één subnet omvat. Met deze optie kunt u nieuwe clients vooraf configureren om toekomstige spanning van subnetten te ondersteunen zonder dat toekomstige wijzigingen in de clientverbindingsreeks nodig zijn en ook de failoverprestaties voor failovers van één subnet worden geoptimaliseerd. Hoewel de optie MultiSubnetFailover-verbinding niet vereist is, biedt dit wel het voordeel van een snellere subnetfailover. Het clientstuurprogramma probeert een TCP-socket te openen voor elk IP-adres dat parallel is gekoppeld aan de beschikbaarheidsgroep. Het clientstuurprogramma wacht tot het eerste IP-adres met succes reageert, en zodra dat gebeurt, wordt het gebruikt voor de verbinding.
Listeners en TLS/SSL-certificaten
Wanneer u verbinding maakt met een listener voor een beschikbaarheidsgroep en als de deelnemende exemplaren van SQL Server TLS/SSL-certificaten gebruiken in combinatie met sessieversleuteling, moet het clientstuurprogramma ondersteuning bieden voor de alternatieve naam van het onderwerp in het TLS/SSL-certificaat om versleuteling af te dwingen.
Een X.509-certificaat moet worden geconfigureerd voor elk deelnemende serverknooppunt in het failovercluster met een lijst met alle listeners voor beschikbaarheidsgroepen die zijn ingesteld in de alternatieve onderwerpnaam van het certificaat.
De notatie voor de certificaatwaarden is:
CN = Server.FQDN
SAN = Server.FQDN,Listener1.FQDN,Listener2.FQDN
U hebt bijvoorbeeld de volgende waarden:
Servername: Win2019
Instance: SQL2019
AG: AG2019
Listener: Listener2019
Domain: contoso.com (which is also the FQDN)
Voor een WSFC met één beschikbaarheidsgroep moet het certificaat de FQDN (Fully Qualified Domain Name) van de server en de FQDN van de listener hebben:
CN: Win2019.contoso.com
SAN: Win2019.contoso.com, Listener2019.contoso.com
Met deze configuratie wordt uw verbinding versleuteld wanneer u verbinding maakt met het exemplaar (WIN2019\SQL2019) of de listener (Listener2019).
Afhankelijk van hoe netwerken zijn geconfigureerd, is er een kleine subset van klanten die mogelijk ook de NetBIOS aan het SAN moeten toevoegen. In dat geval moeten de certificaatwaarden het volgende zijn:
CN: Win2019.contoso.com
SAN: Win2019,Win2019.contoso.com,Listener2019,Listener2019.contoso.com
Als de WSFC drie listeners voor beschikbaarheidsgroepen heeft, zoals: Listener1, Listener2, Listener3
Vervolgens moeten de certificaatwaarden het volgende zijn:
CN: Win2019.contoso.com
SAN: Win2019.contoso.com,Listener1.contoso.com,Listener2.contoso.com,Listener3.contoso.com
Listeners en Kerberos (SPNs)
Een domeinbeheerder moet een SPN (Service Principal Name) configureren in Active Directory voor elke listener van een beschikbaarheidsgroep om Kerberos in te schakelen voor clientverbindingen met de listener. Wanneer u de SPN registreert, moet u het serviceaccount van de serverinstantie gebruiken die als host fungeert voor de beschikbaarheidsreplica. Om de SPN te laten werken voor alle replica's, moet hetzelfde serviceaccount worden gebruikt voor alle exemplaren in het WSFC-cluster dat als host fungeert voor de beschikbaarheidsgroep.
Gebruik het opdrachtregelprogramma setspn Windows om de SPN te configureren. Als u bijvoorbeeld een SPN wilt configureren voor een listener voor een beschikbaarheidsgroep die onder de domeinaccount corp\svclogin2 wordt gehost op een set SQL Server-exemplaren, die allemaal zijn geconfigureerd om daaronder te draaien:
setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp\svclogin2
Zie Een service-principalnaam registreren voor Kerberos-verbindingen voor meer informatie over handmatige registratie van een SPN voor SQL Server.