Ansluta till en AlwaysOn-tillgänglighetsgrupplyssnare

Gäller för:SQL Server

I den här artikeln lär du dig hur du ansluter till en AlwaysOn-tillgänglighetsgruppslyssnare för SQL Server. En tillgänglighetsgruppslyssnare är ett virtuellt nätverksnamn som klienter använder för att ansluta till en databas som finns i en tillgänglighetsgrupp. Lyssnaren tillhandahåller en konsekvent anslutningsslutpunkt för klientprogram, oavsett vilken tillgänglighetsreplik som för närvarande är värd för den primära databasen. Lyssnaren aktiverar också stöd för endast läsbar routning och automatisk övergång.

När du har konfigurerat lyssnaren uppdaterar du anslutningssträngarna så att de pekar på lyssnaren så att programtrafiken dirigeras automatiskt till den avsedda repliken utan att behöva uppdatera anslutningssträngen manuellt efter varje redundansväxling.

Ansluta till den primära repliken

Ange DNS-namnet för tillgänglighetsgruppens lyssnare i anslutningssträngen för att ansluta till den primära repliken för läs- och skrivåtkomst.

Om du till exempel vill ansluta till den primära repliken i SQL Server Management Studio via lyssnaren anger du lyssnarens DNS-namn i fältet servernamn:

När den primära repliken ändras under en redundansväxling kopplas befintliga anslutningar till lyssnaren från och nya anslutningar dirigeras till den nya primära repliken.

Ett exempel på en grundläggande anslutningssträng för ADO.NET-providern (Microsoft.Data.SqlClient eller System.Data.SqlClient):

Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI

Du kan kontrollera vilken replik du för närvarande är ansluten till via lyssnaren genom att köra följande Transact-SQL-kommando (T-SQL):

SELECT @@SERVERNAME

Till exempel när SQLVM1 är den primära repliken:

Du kan fortfarande ansluta direkt till instansen av SQL Server med instansnamnet för den primära eller sekundära repliken i stället för att använda tillgänglighetsgruppens lyssnare. Du förlorar dock fördelen med att nya anslutningar dirigeras automatiskt till den nya primära repliken. Dessutom förlorar du fördelen med skrivskyddad routning, där anslutningar som anges med read-intent automatiskt dirigeras till den läsbara sekundära repliken.

Ansluta till en skrivskyddad replik

Skrivskyddad routning syftar på automatisk routning av inkommande lyssnaranslutningar till en läsbar sekundär replik som är konfigurerad för att tillåta skrivskyddade arbetsbelastningar.

Anslutningar dirigeras automatiskt till den skrivskyddade repliken om följande är sant:

• Minst en sekundär replik är inställd på skrivskyddad åtkomst och varje skrivskyddad sekundär replik och den primära repliken har konfigurerats för skrivskyddad routning.

• Anslutningssträngen refererar till en databas som ingår i tillgänglighetsgruppen. Ett alternativ till detta är att inloggningen som används i anslutningen har databasen konfigurerad som standarddatabas. Mer information finns i den här artikeln om hur algoritmen fungerar med skrivskyddad routning.

• Anslutningssträngen refererar till en tillgänglighetsgruppslyssnare och programavsikten för den inkommande anslutningen är inställd på endast läsning (till exempel genom att använda nyckelordet Application Intent=ReadOnly i ODBC- eller OLEDB-anslutningssträngar eller anslutningsattribut eller egenskaper).

Attributet för program avsikt lagras i klientens session under inloggningen. Instansen SQL Server bearbetar avsikten och avgör vad som ska göras enligt konfigurationen av tillgänglighetsgruppen och det aktuella läs- och skrivtillståndet för måldatabasen i den sekundära repliken.

Om du till exempel vill ansluta till en skrivskyddad replik med hjälp av SQL Server Management Studio väljer du Alternativ i dialogrutan Anslut till server , väljer fliken Ytterligare anslutningsparametrar och anger ApplicationIntent=ReadOnly sedan i textrutan:

Ett exempel på en anslutningssträng för ADO.NET-leverantören (Microsoft.Data.SqlClient eller System.Data.SqlClient) som anger skrivskyddad programavsikt:

Server=tcp:AGListener;Database=AdventureWorks;Integrated Security=SSPI;ApplicationIntent=ReadOnly

Mer information finns i Konfigurera skrivskyddad åtkomst på en tillgänglighetsreplik i SQL Server

Icke-standardport

När du skapar lyssnaren anger du en port som lyssnaren ska använda. Om porten är standardporten 1433 behöver du inte ange ett portnummer när du ansluter till lyssnaren. Men om porten inte är 1433 måste porten anges i anslutningssträngen i formatet listenername,port som:

Ett exempel på en anslutningssträng för ADO.NET providern (Microsoft.Data.SqlClient eller System.Data.SqlClient) som anger en nondefault-port för lyssnaren:

Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI

Kringgå lyssnare

Tillgänglighetsgrupplyssnare aktiverar stöd för omdirigering vid failover och skrivskyddad routning, men klientanslutningar behöver inte använda dem. En klientanslutning kan också referera direkt till SQL Server-instansen i stället för att ansluta till lyssnaren för tillgänglighetsgruppen.

För SQL Server-instansen är det irrelevant om en anslutning loggar in med tillgänglighetsgruppens lyssnare eller använder en annan instansslutpunkt. SQL Server-instansen verifierar måldatabasens status och antingen tillåter eller nekar anslutning baserat på konfigurationen av tillgänglighetsgruppen och databasens aktuella status på instansen. Om ett klientprogram till exempel ansluter direkt till en instans av SQL Server-porten och ansluter till en måldatabas som finns i en tillgänglighetsgrupp, och måldatabasen är i primärt tillstånd och online, så lyckas anslutningen. Om måldatabasen är offline eller i ett övergångstillstånd misslyckas anslutningen till databasen.

Alternativt, när du migrerar från databasspegling till Always On-tillgänglighetsgrupper kan program också ange databasspeglingsanslutningssträngen, förutsatt att det bara finns en sekundär replik och att den inte tillåter användaranslutningar.

Anslutningssträngar för databasspegling

Om en tillgänglighetsgrupp bara har en sekundär replik och har konfigurerats med antingen ALLOW_CONNECTIONS = READ_ONLY eller ALLOW_CONNECTIONS = NONE för den sekundära repliken, kan klienterna ansluta till den primära repliken med hjälp av en databasspeglingsanslutningssträng. Den här metoden kan vara användbar när du migrerar ett befintligt program från databasspegling till en tillgänglighetsgrupp, så länge du begränsar tillgänglighetsgruppen till två tillgänglighetsrepliker (en primär replik och en sekundär replik). Om du lägger till ytterligare sekundära repliker måste du skapa en tillgänglighetsgrupplyssnare för tillgänglighetsgruppen och uppdatera dina program så att de använder DNS-namnet för tillgänglighetsgruppens lyssnare.

När du använder anslutningssträngar för databasspegling kan klienten använda antingen SQL Server Native Client eller .NET Framework Data Provider för SQL Server. Anslutningssträngen som tillhandahålls av en klient måste minimalt ange namnet på en serverinstans, det första partnernamnet, för att identifiera den serverinstans som ursprungligen är värd för tillgänglighetsrepliken som du tänker ansluta till. Alternativt kan anslutningssträngen även ange namnet på en annan serverinstans, redundanspartnernamnet, för att identifiera den serverinstans som ursprungligen är värd för den sekundära repliken som partnernamn för redundans.

Mer information om databasspegling av anslutningssträngar finns i Ansluta klienter till en databasspeglingssession (SQL Server).

Redundans för flera undernät

Om du använder klientbibliotek som stöder anslutningsalternativet MultiSubnetFailover i anslutningssträngen kan du optimera redundansväxlingen för tillgänglighetsgruppen till ett annat undernät genom att ange MultiSubnetFailover till "True" eller "Yes", beroende på syntaxen för providern som du använder.

Alternativet MultiSubnetFailover-anslutning fungerar bara med TCP-nätverksprotokollet och stöds endast när du ansluter till en tillgänglighetsgruppslyssnare och för alla virtuella nätverksnamn som ansluter till SQL Server.

Ett exempel på ADO.NET provider (Microsoft.Data.SqlClient eller System.Data.SqlClient) anslutningssträng som aktiverar redundans för flera undernät är följande:

Server=tcp:AGListener,1433;Database=AdventureWorks;Integrated Security=SSPI; MultiSubnetFailover=True

Anslutningsalternativet MultiSubnetFailover ska vara inställt på Sant även om tillgänglighetsgruppen bara sträcker sig över ett enda undernät. Med det här alternativet kan du förkonfigurera nya klienter för att hantera överlappande av undernät i framtiden utan att framtida ändringar av klientanslutningssträngar behövs, och optimerar även redundansprestanda för redundansväxlingar med ett enda undernät. Alternativet MultiSubnetFailover-anslutning krävs inte, men det ger fördelen med en snabbare redundansväxling i undernätet. Klientdrivrutinen försöker parallellt öppna en TCP-socket för varje IP-adress som är knuten till tillgänglighetsgruppen. Klientdrivrutinen väntar på att den första IP-adressen ska svara med framgång och när den väl gör det använder den för anslutningen.

Lyssnare och TLS/SSL-certifikat

När du ansluter till en tillgänglighetsgruppslyssnare, om de deltagande instanserna av SQL Server använder TLS/SSL-certifikat tillsammans med sessionskryptering, måste den anslutande klientdrivrutinen ha stöd för alternativt ämnesnamn i TLS/SSL-certifikatet för att tvinga fram kryptering.

Ett X.509-certifikat måste konfigureras för varje deltagande servernod i redundansklustret med en lista över alla tillgänglighetsgrupplyssnare som angetts i certifikatets alternativa ämnesnamn.

Formatet för certifikatvärdena är:

CN = Server.FQDN
SAN = Server.FQDN,Listener1.FQDN,Listener2.FQDN

Du har till exempel följande värden:

Servername: Win2019
Instance: SQL2019
AG: AG2019
Listener: Listener2019
Domain: contoso.com  (which is also the FQDN)

För en WSFC som har en enda tillgänglighetsgrupp ska certifikatet ha serverns fullständigt kvalificerade domännamn (FQDN) och lyssnarens FQDN:

CN: Win2019.contoso.com
SAN: Win2019.contoso.com, Listener2019.contoso.com

Med den här konfigurationen krypteras anslutningen när du ansluter till instansen (WIN2019\SQL2019) eller lyssnaren (Listener2019).

Beroende på hur nätverk har konfigurerats finns det en liten delmängd kunder som kan behöva lägga till NetBIOS i SAN också. I så fall ska certifikatvärdena vara:

CN: Win2019.contoso.com
SAN: Win2019,Win2019.contoso.com,Listener2019,Listener2019.contoso.com

Om WSFC har tre lyssnare för tillgänglighetsgrupper, till exempel: Listener1, Listener2, Listener3

Sedan ska certifikatvärdena vara:

CN: Win2019.contoso.com
SAN: Win2019.contoso.com,Listener1.contoso.com,Listener2.contoso.com,Listener3.contoso.com

Lyssnare och Kerberos (SPN)

En domänadministratör måste konfigurera ett SPN (Service Principal Name) i Active Directory för varje tillgänglighetsgrupplyssnare för att aktivera Kerberos för klientanslutningar till lyssnaren. När du registrerar SPN måste du använda tjänstkontot för den serverinstans som är värd för tillgänglighetsrepliken. För att SPN ska fungera för alla repliker måste samma tjänstkonto användas för alla instanser i WSFC-klustret som är värd för tillgänglighetsgruppen.

Använd kommandoradsverktyget setspn Windows för att konfigurera SPN. Till exempel för att konfigurera ett SPN för en tillgänglighetsgrupplyssnare med namnet AG1listener.Adventure-Works.com värdhanterad på en uppsättning instanser av SQL Server som alla har konfigurerats för att köras under domänkontot corp\svclogin2:

setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp\svclogin2

Mer information om manuell registrering av ett SPN för SQL Server finns i Registrera ett tjänsthuvudnamn för Kerberos-anslutningar.

Relaterat innehåll

• Skrivskyddade arbetsbelastningar
• Backups
• Övervakningsstrategier för tillgänglighetsgrupper
• Vad är en AlwaysOn-tillgänglighetsgrupp?