Jetzt, da Verfügbarkeitsgruppen immer weiter verbreitet sind, dachte ich, ich würde ein Thema behandeln, das während der anfänglichen Planung und Installation von SQL Server in dieser Art von Umgebung möglicherweise übersehen wird. Um wirklich eine fehlertolerante Konfiguration zu haben, müssen einige Überlegungen und Planungen in die Einrichtung der Datenbankkonnektivität einfließen.
Ich werde in diesem Beitrag nicht auf die Details der Einrichtung Ihrer AlwaysOn-Umgebung eingehen, aber für zusätzliche Hilfe empfehle ich Ihnen, sich Aaron Bertrands Beitrag „Fehlerbehebung bei AlwaysOn – Manchmal braucht es viele Augen“ anzusehen. Sobald Ihre Umgebung konfiguriert ist, besteht der nächste Schritt bei der Bereitstellung von Datenbankkonnektivität darin, einen Verfügbarkeitsgruppen-Listener mit SQL Management Studio oder T-SQL zu erstellen:
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
AG-Listener-Verbindungszeichenfolgen
Ihr virtueller Netzwerkname (VNN) ist im DNS registriert und gehört immer der SQL Server-Instanz, in der sich das primäre Replikat befindet. Alle IP-Adressen, die beim Konfigurieren des AG-Listeners bereitgestellt werden, werden im DNS unter demselben Namen des virtuellen Netzwerks registriert.
Nachdem Sie Ihren AG-Listener erstellt haben, müssen Sie sicherstellen, dass Ihre Clients eine Verbindung herstellen können. Ihre Anwendungsverbindung funktioniert auf die gleiche Weise wie immer, aber anstatt auf einen bestimmten Server in Ihrer Verbindungszeichenfolge zu verweisen, verweisen Sie auf den AG-Listener.
AG-Listener können nur über TCP verbunden werden und werden von Ihrem lokalen DNS in die Liste der IP-Adressen und TCP-Ports aufgelöst, die dem VNN zugeordnet sind. Ihr Client wird nacheinander versuchen, sich mit jeder der IP-Adressen zu verbinden, bis er entweder eine Verbindung erhält oder bis er eine Verbindungszeitüberschreitung erreicht. Ein wichtiger Verbindungszeichenfolgenparameter, der in Betracht gezogen werden sollte, ist MultiSubnetFailover. Wenn dieser Parameter auf „true“ gesetzt ist, versucht der Client, die Verbindungen parallel herzustellen, was eine schnellere Konnektivität und, falls erforderlich, schnellere Client-Failover ermöglicht:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Wenn ein Failover auftritt, werden Clientverbindungen zurückgesetzt, und der Besitz des AG-Listeners wird auf die SQL Server-Instanz verschoben, die die Rolle des primären Replikats übernimmt. Der VNN-Endpunkt wird dann an die neuen IP-Adressen und TCP-Ports der neuen primären Replikatinstanz gebunden. Je nach Client erfolgt eine automatische Wiederverbindung mit der AG, oder der Benutzer muss die betroffene Anwendung oder Verbindung möglicherweise manuell neu starten.
Bewerbungsabsicht
Einer der wichtigsten Gründe für die Implementierung von Verfügbarkeitsgruppen ist die Möglichkeit, Ihre Sicherungs- oder Notfallwiederherstellungsumgebungen zu nutzen, um Arbeit aus Ihrer Produktionsumgebung zu entlasten. Diese Server können jetzt für Sicherungen, Analysen, Ad-hoc-Abfragen und Berichte oder andere Vorgänge verwendet werden, bei denen eine schreibgeschützte Kopie der Datenbank ausreicht.
Um schreibgeschützten Zugriff auf Ihre sekundären Replikate bereitzustellen, wird der ApplicationIntent-Verbindungszeichenfolgenparameter verwendet. Auf jedem Replikat kann eine optionale schreibgeschützte Routingliste von SQL Server-Endpunkten konfiguriert werden. Diese Liste wird verwendet, um Client-Verbindungsanfragen, die den Parameter ApplicationIntent=ReadOnly verwenden, an das erste verfügbare sekundäre Replikat umzuleiten, das mit einem geeigneten Anwendungsabsichtsfilter konfiguriert wurde.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Filterung der Anwendungsabsicht
Um Application Intent von den Clients zu erleichtern, die eine Verbindung zu Ihrer Verfügbarkeitsgruppe herstellen, sollte jede SQL Server-Instanz in der Gruppe mit einem geeigneten Application Intent-Filter konfiguriert werden. Der Filter bestimmt, welche Arten von Verbindungen jedes Replikat akzeptiert.
Ein primäres Replikat, das so konfiguriert ist, dass es Verbindungen in der primären Rolle „Alle Verbindungen zulassen“ hat, akzeptiert alle Verbindungen, die über den AG-Listener hergestellt werden. Ein primäres Replikat, das als „Lese-/Schreibverbindungen zulassen“ konfiguriert ist, lehnt jede Verbindung ab, die „ApplicationIntent=ReadOnly“ angibt.
Beim Konfigurieren von Replikaten müssen Sie auch definieren, ob es sich bei jedem um einen lesbaren sekundären Replikat handelt oder nicht. Ein Replikat, das als „Nein“ konfiguriert ist, wird alle Verbindungen ablehnen. Es wird davon ausgegangen, dass dieses Replikat nur für Failover in einer Notfallwiederherstellungssituation verwendet wird. Wenn das sekundäre Replikat als „Ja“ konfiguriert ist, werden alle Verbindungen zugelassen, jedoch nur für den Lesezugriff, auch wenn „ApplicationIntent=ReadOnly“ nicht angegeben ist. Wenn schließlich der sekundäre Client als „Nur-Lese-Intent“ konfiguriert ist, dürfen nur Clients, die „ApplicationIntent=ReadOnly“ angeben, eine Verbindung herstellen.
Nur-Lese-Routing
Nachdem wir nun wissen, wie Application Intent auf den Serverinstanzen konfiguriert und die erforderlichen Verbindungszeichenfolgen erstellt werden, müssen wir das schreibgeschützte Routing der Verfügbarkeitsgruppe konfigurieren. Wenn Sie mithilfe der oben definierten Verbindungszeichenfolge eine Verbindung zum AG-Listener herstellen, fragt der Listener die primäre Replikatinstanz ab und bestimmt, ob die Verbindung zur primären (Lese-/Schreibzugriff) oder zu einer schreibgeschützten sekundären Instanz hergestellt werden soll. Dazu muss für JEDES Verfügbarkeitsreplikat eine Routingliste erstellt werden, die verwendet wird, wenn das Replikat die Rolle des Primären übernimmt. In der Regel besteht die bewährte Methode darin, jede schreibgeschützte Routing-URL für jedes schreibgeschützte sekundäre Replikat mit der lokalen Replikat-URL am Ende der Liste einzuschließen. Verbindungsanfragen mit Leseabsicht werden an den ersten verfügbaren lesbaren sekundären Server in der Routingliste weitergeleitet, es gibt keinen Lastenausgleich zwischen den sekundären Servern.
Ändern Sie zuerst jedes Replikat, um die schreibgeschützte Routing-URL bereitzustellen:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.mydomain.com:1433')); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.mydomain.com:1433'));
Ändern Sie zweitens jedes Replikat, um die schreibgeschützte Routingliste bereitzustellen, die verwendet werden soll, wenn das angegebene Replikat die primäre Rolle hat:
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02'))); Die Routing-URL sollte das Format „TCP://:“ haben. Hilfe beim Bestimmen Ihrer URL finden Sie in diesem Blog und Skript von Matt Neerincx.
Schlussfolgerung
Wenn Ihr schreibgeschütztes Routing konfiguriert, der AG-Listener erstellt und Ihre Clientanwendungen die richtigen Verbindungszeichenfolgen verwenden, sollten Sie über eine vollständig fehlertolerante Verbindung für Ihre Verfügbarkeitsgruppe verfügen. Stellen Sie sicher, dass Sie sich etwas Zeit nehmen, um Ihre Konnektivität und die Fähigkeit Ihrer Anwendungen zu testen, Ihren Servern bei einem Failover zu folgen.
