Herstellen einer Verbindung mit einem Always On-Verfügbarkeitsgruppenlistener
Gilt für: 
SQL Server
In diesem Artikel erfahren Sie, wie Sie eine Verbindung mit einem Always On-Verfügbarkeitsgruppenlistener für SQL Server herstellen. Bei einem Verfügbarkeitsgruppenlistener handelt es sich um den Namen eines virtuellen Netzwerks, mit dessen Hilfe Clients eine Verbindung mit einer Datenbank in einer Verfügbarkeitsgruppe herstellen. Der Listener stellt einen konsistenten Verbindungsendpunkt für Clientanwendungen bereit, unabhängig davon, welches Verfügbarkeitsreplikat zum jeweiligen Zeitpunkt die primäre Datenbank hostet. Außerdem ermöglicht der Listener die Unterstützung für schreibgeschütztes Routing und automatisches Failover.
Aktualisieren Sie nach der Konfiguration des Listeners die Verbindungszeichenfolgen so, dass sie auf den Listener zeigen, damit der Anwendungsdatenverkehr automatisch an das beabsichtigte Replikat weitergeleitet wird und die Verbindungszeichenfolge nicht nach jedem Failover manuell aktualisiert werden muss.
Herstellen einer Verbindung mit dem primären Replikat
Geben Sie in der Verbindungszeichenfolge den DNS-Namen des Verfügbarkeitsgruppenlisteners an, um für den Lese-/Schreibzugriff eine Verbindung mit dem primären Replikat herzustellen.
Geben Sie beispielsweise den DNS-Namen des Listeners in das Servernamenfeld ein, um über den Listener eine Verbindung mit dem primären Replikat in SQL Server Management Studio herzustellen:
Wenn bei einem Failover das primäre Replikat geändert wird, werden vorhandene Verbindungen zum Listener getrennt, und neue Verbindungen werden an das neue primäre Replikat weitergeleitet.
Beispiel für eine einfache Verbindungszeichenfolge für den ADO.NET-Anbieter (System.Data.SqlClient):
Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI
Sie können überprüfen, mit welchem Replikat Sie zurzeit über den Listener verbunden sind, indem Sie den folgenden Transact-SQL-Befehl (T-SQL) ausführen:
SELECT @@SERVERNAME
Beispiel für den Fall, dass SQLVM1 das primäre Replikat ist:
Sie können noch immer eine direkte Verbindung mit der SQL Server-Instanz herstellen, indem Sie den Instanznamen des primären oder sekundären Replikats anstelle des Verfügbarkeitsgruppenlisteners verwenden. Allerdings werden neue Verbindungen dann nicht mehr automatisch an das neue aktuelle, primäre Replikat weitergeleitet. Außerdem erfolgt kein schreibgeschütztes Routing mehr, bei dem mit read-intent angegebene Verbindungen automatisch an das lesbare sekundäre Replikat weitergeleitet werden.
Herstellen einer Verbindung mit einem schreibgeschützten Replikat
Das schreibgeschützte Routing bezieht sich auf das automatische Routing eingehender Listenerverbindungen an ein lesbares sekundäres Replikat, das für das Zulassen schreibgeschützter Workloads konfiguriert ist.
Verbindungen werden automatisch an das schreibgeschützte Replikat weitergeleitet, wenn Folgendes zutrifft:
Mindestens ein sekundäres Replikat ist auf schreibgeschützten Zugriff festgelegt, und jedes schreibgeschützte sekundäre Replikat sowie das primäre Replikat werden konfiguriert, um schreibgeschütztes Routing zu unterstützen.
Die Verbindungszeichenfolge verweist auf eine Datenbank innerhalb der Verfügbarkeitsgruppe. Eine Alternative dazu ist es, für den Anmeldenamen, der für die Verbindung verwendet wird, die Datenbank als Standarddatenbank zu konfigurieren. Weitere Informationen dazu finden Sie in diesem Blogbeitrag zur Funktionsweise des Algorithmus mit dem schreibgeschützten Routing (in englischer Sprache).
Die Verbindungszeichenfolge verweist auf einen Verfügbarkeitsgruppenlistener, und die Anwendungsabsicht der eingehenden Verbindung wird auf schreibgeschützt festgelegt, z. B. mithilfe des Schlüsselworts Application Intent=ReadOnly in den ODBC- oder OLEBD-Verbindungszeichenfolgen, -Verbindungsattributen oder -Eigenschaften.
Das Attribut der Anwendungsabsicht wird während der Anmeldung in der Clientsitzung gespeichert. Die Instanz von SQL Server verarbeitet dann diese Absicht und ermittelt das weitere Vorgehen entsprechend der Konfiguration der Verfügbarkeitsgruppe und dem aktuellen Lese-/Schreibstatus der Zieldatenbank im sekundären Replikat.
Klicken Sie zunächst im Dialogfeld Verbindung mit Server herstellen auf Optionen und dann auf die Registerkarte Zusätzliche Verbindungsparameter, und geben Sie dann ApplicationIntent=ReadOnly im Textfeld an, wenn Sie beispielsweise mithilfe von SQL Server Management Studio eine Verbindung mit einem schreibgeschützten Replikat herstellen möchten:
Beispiel für eine Verbindungszeichenfolge für den ADO.NET-Anbieter (System.Data.SqlClient) mit Festlegung einer schreibgeschützten Anwendungsabsicht:
Server=tcp:AGListener;Database=AdventureWorks;Integrated Security=SSPI;ApplicationIntent=ReadOnly
Weitere Informationen finden Sie unter Konfigurieren des schreibgeschützten Zugriffs auf ein Verfügbarkeitsreplikat (SQL Server).
Nicht-standardmäßiger Port
Wenn Sie den Listener erstellen, legen Sie einen Port fest, der vom Listener verwendet werden soll. Wenn der Port der Standardport 1433 ist, müssen Sie beim Herstellen einer Verbindung mit dem Listener keine Portnummer angeben. Wenn es sich bei dem Port jedoch nicht um Port 1433 handelt, muss der Port beispielsweise wie folgt in der Verbindungszeichenfolge im Format listenername,port angegeben werden:
Beispiel für eine Verbindungszeichenfolge für den ADO.NET-Anbieter (System.Data.SqlClient), der einen nicht-standardmäßigen Port für den Listener angibt:
Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI
Umgehungslistener
Während Verfügbarkeitsgruppenlistener Unterstützung für Failoverumleitung und schreibgeschütztes Routing ermöglichen, müssen Clientverbindungen diese nicht verwenden. Eine Clientverbindung kann auch direkt auf die Instanz von SQL Server verweisen, statt eine Verbindung mit dem Verfügbarkeitsgruppenlistener herzustellen.
Für die Instanz von SQL Server spielt es keine Rolle, ob eine Verbindung mithilfe des Verfügbarkeitsgruppenlisteners oder mithilfe eines anderen Instanzendpunkts angemeldet wird. Die Instanz von SQL Server überprüft den Status der Zieldatenbank und ermöglicht oder verweigert die Konnektivität basierend auf der Konfiguration der Verfügbarkeitsgruppe und dem aktuellen Status der Datenbank auf der Instanz. Wenn z. B. eine Clientanwendung direkt eine Verbindung mit einer Instanz des SQL Server-Ports herstellt und eine Verbindung mit einer Zieldatenbank in einer Verfügbarkeitsgruppe herstellt und die Zieldatenbank sich im primären Status befindet und online ist, ist die Konnektivität erfolgreich. Ist die Zieldatenbank offline oder in einem Übergangsstatus, schlägt die Konnektivität zur Datenbank fehl.
Alternativ können Anwendungen beim Migrieren von der Datenbankspiegelung zu Always On-Verfügbarkeitsgruppendie Verbindungszeichenfolge für die Datenbankspiegelung angeben, sofern nur ein sekundäres Replikat vorhanden ist und Benutzerverbindungen unzulässig sind.
Verbindungszeichenfolgen für Datenbankspiegelung
Wenn eine Verfügbarkeitsgruppe nur ein sekundäres Replikat besitzt und mit ALLOW_CONNECTIONS = READ_ONLY oder ALLOW_CONNECTIONS = NONE für das sekundäre Replikat konfiguriert wird, können Clients mithilfe einer Verbindungszeichenfolge für die Datenbankspiegelung eine Verbindung mit dem primären Replikat herstellen. Dieser Ansatz kann beim Migrieren einer vorhandenen Anwendung von der Datenbankspiegelung zu einer Verfügbarkeitsgruppe nützlich sein, sofern Sie die Verfügbarkeitsgruppe auf zwei Verfügbarkeitsreplikate (ein primäres und ein sekundäres Replikat) beschränken. Wenn Sie zusätzliche sekundäre Replikate hinzufügen, müssen Sie einen Verfügbarkeitsgruppenlistener für die Verfügbarkeitsgruppe erstellen und die Anwendungen so aktualisieren, dass der DNS-Name des Verfügbarkeitsgruppenlisteners verwendet wird.
Wenn Sie die Verbindungszeichenfolgen der Datenbankspiegelung verwenden, kann der Client entweder SQL Server Native Client oder .NET Framework-Datenanbieter für SQL Serververwenden. Die von einem Client bereitgestellte Verbindungszeichenfolge muss mindestens den Namen einer Serverinstanz, den ursprünglichen Partnernamen, angeben, um die Serverinstanz zu identifizieren, auf der das Verfügbarkeitsreplikat, zu dem Sie eine Verbindung herstellen möchten, ursprünglich gehostet wird. Optional kann die Verbindungszeichenfolge auch den Namen einer anderen Serverinstanz, den Failoverpartnernamen, enthalten, um die Serverinstanz zu identifizieren, auf der das sekundäre Replikat ursprünglich gehostet wird.
Weitere Informationen zu Verbindungszeichenfolgen für die Datenbankspiegelung finden Sie unter Verbinden von Clients mit einer Datenbank-Spiegelungssitzung (SQL Server).
Multisubnetzfailover
Wenn Sie Clientbibliotheken nutzen, die die Verbindungsoption „MultiSubnetFailover“ in der Verbindungszeichenfolge unterstützen, können Sie das Verfügbarkeitsgruppenfailover auf ein anderes Subnetz optimieren, indem Sie „MultiSubnetFailover“ je nach Syntax des verwendeten Anbieters auf „True“ oder „Yes“ festlegen.
Hinweis
Diese Einstellung wird für Verbindungen mit einem Subnetz und mehreren Subnetzen mit den Namen von Verfügbarkeitslistenern und SQL Server-Failoverclusterinstanzen empfohlen. Wenn Sie diese Option aktivieren, stehen auch für Szenarien mit einem Subnetz weitere Optimierungen zur Verfügung.
Die MultiSubnetFailover -Verbindungsoption funktioniert nur mit dem TCP-Netzwerkprotokoll und wird nur beim Herstellen einer Verbindung mit einem Verfügbarkeitsgruppenlistener und für beliebige virtuelle Netzwerknamen unterstützt, die eine Verbindung mit SQL Serverherstellen.
Beispiel für eine Verbindungszeichenfolge des ADO.NET-Anbieters (System.Data.SqlClient) mit aktiviertem Multisubnetzfailover:
Server=tcp:AGListener,1433;Database=AdventureWorks;Integrated Security=SSPI; MultiSubnetFailover=True
Die MultiSubnetFailover -Verbindungsoption sollte auf True festgelegt werden, auch wenn die Verfügbarkeitsgruppe nur ein einzelnes Subnetz umfasst. Dies ermöglicht es Ihnen, neue Clients vorzukonfigurieren, um künftig weitere Subnetze zu unterstützen, ohne dass die Clientverbindungszeichenfolgen geändert werden müssen. Darüber hinaus wird die Failoverleistung für Failover in einem Subnetz optimiert. Die Verbindungsoption MultiSubnetFailover ist zwar nicht erforderlich, bietet jedoch den Vorteil eines schnelleren Subnetzfailovers. Das liegt daran, dass der Clienttreiber versucht, parallel ein TCP-Socket für alle der Verfügbarkeitsgruppe zugeordneten IP-Adressen zu öffnen. Der Clienttreiber wartet, bis die erste IP-Adresse erfolgreich antwortet, und verwendet diese dann für die Verbindung.
Listener und TLS/SSL-Zertifikate
Wenn beim Herstellen einer Verbindung mit einem Verfügbarkeitsgruppenlistener die beteiligten Instanzen von SQL Server TLS/SSL-Zertifikate zusammen mit Sitzungsverschlüsselung verwenden, muss der Clienttreiber den alternativen Antragstellernamen im TLS/SSL-Zertifikat unterstützen, um die Verschlüsselung zu erzwingen.
Ein X.509-Zertifikat muss für alle beteiligten Serverknoten im Failovercluster mit einer Liste aller im alternativen Antragstellernamen des Zertifikats festgelegten Verfügbarkeitsgruppenlistenern konfiguriert werden.
Die Zertifikatwerte haben folgendes Format:
CN = Server.FQDN
SAN = Server.FQDN,Listener1.FQDN,Listener2.FQDN
Sie haben z. B. folgende Werte:
Servername: Win2019
Instance: SQL2019
AG: AG2019
Listener: Listener2019
Domain: contoso.com (which is also the FQDN)
Bei einem WSFC mit einer einzelnen Verfügbarkeitsgruppe sollte das Zertifikat den voll qualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Servers und den FQDN des Listeners aufweisen:
CN: Win2019.contoso.com
SAN: Win2019.contoso.com, Listener2019.contoso.com
Mit dieser Konfiguration werden die Verbindungen verschlüsselt, wenn eine Verbindung mit der Instanz (WIN2019\SQL2019) oder dem Listener (Listener2019) hergestellt wird.
Abhängig von der Netzwerkkonfiguration gibt es eine kleine Teilmenge von Kund*innen, die dem SAN unter Umständen auch das NetBIOS hinzufügen müssen. In diesem Fall sollten die Zertifikatwerte wie folgt lauten:
CN: Win2019.contoso.com
SAN: Win2019,Win2019.contoso.com,Listener2019,Listener2019.contoso.com
Der WSFC umfasst z. B. drei Verfügbarkeitsgruppenlistener: Listener1, Listener2, Listener3
Dann sollten die Zertifikatwerte wie folgt lauten:
CN: Win2019.contoso.com
SAN: Win2019.contoso.com,Listener1.contoso.com,Listener2.contoso.com,Listener3.contoso.com
Listener und Kerberos (SPNs)
Ein Domänenadministrator muss in Active Directory einen Dienstprinzipalnamen (Service Principal Name, SPN) für jeden Verfügbarkeitsgruppenlistener konfigurieren, um Kerberos für Clientverbindungen mit dem Listener zu aktivieren. Bei der Registrierung des Dienstprinzipalnamens (SPN) müssen Sie das Dienstkonto derjenigen Serverinstanz verwenden, die das Verfügbarkeitsreplikat hostet. Damit der SPN in allen Replikaten funktioniert, muss dasselbe Dienstkonto für alle Instanzen im WSFC-Cluster verwendet werden, der die Verfügbarkeitsgruppe hostet.
Konfigurieren Sie den SPN mithilfe des setspn Windows-Befehlszeilentools. Beispiel für die Konfiguration eines SPN für den Verfügbarkeitsgruppenlistener AG1listener.Adventure-Works.com, der auf einer Reihe von SQL Server-Instanzen gehostet wird, die alle zur Ausführung unter dem Domänenkonto corp\svclogin2 konfiguriert sind:
setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp\svclogin2
Weitere Informationen zur manuellen Registrierung eines SPN für SQL Server finden Sie unter Registrieren eines Dienstprinzipalnamens für Kerberos-Verbindungen.