Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.
Ein Beispiel für eine einfache Verbindungszeichenfolge für den ADO.NET-Anbieter (Microsoft.Data.SqlClient oder System.Data.SqlClient):
Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI
Hinweis
Microsoft.Data.SqlClient ist der empfohlene ADO.NET Datenanbieter für die neue Anwendungsentwicklung. Es unterstützt dieselben Verbindungszeichenfolgenstichwörter wie System.Data.SqlClient. Weitere Informationen finden Sie in der Einführung in den Microsoft.Data.SqlClient-Namespace.
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: Wenn 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 entfällt das schreibgeschützte Routing, bei dem die mit read-intent angegebenen Verbindungen automatisch an das lesbare sekundäre Replikat weitergeleitet werden.
Verbindung zu einem schreibgeschützten Replikat herstellen
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 Artikel zur Funktionsweise des Algorithmus mit dem schreibgeschützten Routing.
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 Anwendungsabsichtsattribut wird während der Anmeldung in der Sitzung des Clients gespeichert. Die Instanz von SQL Server verarbeitet die Absicht und bestimmt, was gemäß der Konfiguration der Verfügbarkeitsgruppe und dem aktuellen Lese-/Schreibstatus der Zieldatenbank im sekundären Replikat zu tun ist.
Wenn Sie z. B. mithilfe von SQL Server Management Studio eine Verbindung mit einem schreibgeschützten Replikat herstellen möchten, wählen Sie im Dialogfeld Verbindung mit ServerOptionen aus, wählen Sie die Registerkarte Zusätzliche Verbindungsparameter aus, und geben Sie dann im Textfeld folgendes anApplicationIntent=ReadOnly:
Ein Beispiel für eine Verbindungszeichenfolge für den ADO.NET-Anbieter (Microsoft.Data.SqlClient oder System.Data.SqlClient) der schreibgeschützte Anwendungsabsicht angibt:
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:
Ein Beispiel für eine Verbindungszeichenfolge für den ADO.NET-Anbieter (Microsoft.Data.SqlClient oder System.Data.SqlClient) zur Angabe eines nicht standardmäßigen Ports für den Listener:
Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI
Bypass-Zuhörer
Während Verfügbarkeitsgruppen-Listener die Unterstützung für Failover-Umleitung und schreibgeschütztes Routing ermöglichen, sind Clientverbindungen nicht darauf angewiesen, sie zu 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 Sql Server-Instanz überprüft den Status der Zieldatenbank und lässt die Konnektivität basierend auf der Konfiguration der Verfügbarkeitsgruppe und dem aktuellen Zustand der Datenbank auf der Instanz zu oder lässt sie nicht zu. 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. Wenn die Zieldatenbank offline ist oder sich in einem Übergangszustand befindet, schlägt die Verbindung mit der Datenbank fehl.
Alternativ können Anwendungen beim Migrieren von der Datenbankspiegelung zu Always On-Verfügbarkeitsgruppen die Verbindungszeichenfolge für die Datenbankspiegelung angeben, sofern nur ein sekundäres Replikat vorhanden ist und Benutzerverbindungen nicht zulä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
Wir empfehlen diese Einstellung sowohl für Einzel- als auch Mehrfach-Subnetzverbindungen zu Verfügbarkeitsgruppen-Listenern und zu Namen von SQL Server-Failover-Cluster-Instanzen. 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.
Ein Beispiel für die Verbindungszeichenfolge eines ADO.NET-Anbieters (Microsoft.Data.SqlClient oder System.Data.SqlClient), die ein Multi-Subnetz-Failover ermöglicht, lautet wie folgt:
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. Mit dieser Option können Sie neue Clients vorkonfigurieren, die zukünftige Einbettung von Subnetzen unterstützen, ohne dass spätere Änderungen an der Client-Verbindungszeichenfolge nötig werden, und optimiert die Failover-Leistung für Failovers einzelner Subnetze. Die Verbindungsoption MultiSubnetFailover ist zwar nicht erforderlich, bietet jedoch den Vorteil eines schnelleren Subnetzfailovers. Der Clienttreiber versucht, einen TCP-Socket für jede IP-Adresse parallel zur Verfügbarkeitsgruppe zu öffnen. Der Clienttreiber wartet auf die erste IP-Adresse, um erfolgreich zu reagieren, und verwendet ihn dann für die Verbindung.
Listener und TLS/SSL-Zertifikate
Wenn die teilnehmenden Instanzen von SQL Server TLS/SSL-Zertifikate in Verbindung mit der Sitzungsverschlüsselung verwenden, muss der verbindende Clienttreiber den Subject Alternate Name 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
Bei dieser Konfiguration wird Die Verbindung beim Herstellen einer Verbindung mit der Instanz (WIN2019\SQL2019) oder dem Listener (Listener2019) verschlüsselt.
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
Wenn der WSFC zum Beispiel drei Listener für Verfügbarkeitsgruppen hat, wie: 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.