Nu beschikbaarheidsgroepen steeds meer wijdverspreid zijn, dacht ik dat ik een onderwerp zou behandelen dat mogelijk over het hoofd wordt gezien tijdens de eerste planning en installatie van SQL Server in dit soort omgevingen. Om echt een fouttolerante configuratie te hebben, moet er wat aandacht en planning worden besteed aan het opzetten van databaseconnectiviteit.
Ik zal niet ingaan op de details van het opzetten van je AlwaysOn-omgeving in dit bericht, maar voor wat extra hulp raad ik je aan om het bericht van Aaron Bertrand te bekijken, "Problemen oplossen met AlwaysOn - Soms zijn er veel paar ogen nodig." Zodra uw omgeving is geconfigureerd, is de volgende stap bij het bieden van databaseconnectiviteit het maken van een beschikbaarheidsgroep-listener met behulp van SQL Management Studio of T-SQL:
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
AG Listener Connection Strings
Uw Virtual Network Name (VNN) is geregistreerd in DNS en is altijd eigendom van het SQL Server-exemplaar waar de primaire replica zich bevindt. Alle IP-adressen die tijdens het configureren van de AG Listener worden verstrekt, worden in DNS geregistreerd onder dezelfde virtuele netwerknaam.
Nadat u uw AG Listener hebt gemaakt, moet u ervoor zorgen dat uw klanten verbinding kunnen maken. Uw applicatieverbinding werkt op dezelfde manier als altijd, maar in plaats van naar een specifieke server in uw verbindingsreeks te wijzen, wijst u naar de AG Listener.
AG-luisteraars kunnen alleen worden verbonden met TCP en worden door uw lokale DNS omgezet in de lijst met IP-adressen en TCP-poorten die zijn toegewezen aan het VNN. Uw client zal om de beurt proberen verbinding te maken met elk van de IP-adressen totdat deze verbinding krijgt of een time-out voor de verbinding bereikt. Een belangrijke verbindingsreeksparameter die u kunt gebruiken, is MultiSubnetFailover. Als deze parameter is ingesteld op 'true', probeert de client de verbindingen parallel te maken, waardoor een snellere connectiviteit en, indien nodig, snellere client-failovers mogelijk worden:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Wanneer een failover optreedt, worden clientverbindingen opnieuw ingesteld en wordt het eigendom van de AG-listener verplaatst naar de SQL Server-instantie die de primaire replicarol overneemt. Het VNN-eindpunt wordt vervolgens gebonden aan de nieuwe IP-adressen en TCP-poorten van de nieuwe primaire replica-instantie. Afhankelijk van de client zal er automatisch opnieuw verbinding worden gemaakt met de AG of moet de gebruiker de betreffende applicatie of verbinding handmatig opnieuw opstarten.
Toepassingsintentie
Een van de belangrijkste redenen om Beschikbaarheidsgroepen te implementeren, is om de mogelijkheid te bieden om uw back-up- of noodherstelomgevingen te gebruiken om werk van uw productieomgeving te ontlasten. Deze servers kunnen nu worden gebruikt voor back-ups, analyse, ad-hocquery's en rapportage, of elke andere bewerking waarbij een alleen-lezen kopie van de database voldoende is.
Om alleen-lezen toegang tot uw secundaire replica's te bieden, wordt de ApplicationIntent-verbindingsreeksparameter gebruikt. Op elke replica kan een optionele alleen-lezen routeringslijst met SQL Server-eindpunten worden geconfigureerd. Deze lijst wordt gebruikt om clientverbindingsverzoeken die de ApplicationIntent=ReadOnly-parameter gebruiken om te leiden naar de eerste beschikbare secundaire replica die is geconfigureerd met een geschikt toepassingsintentiefilter.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Applicatie-intentiefiltering
Om de toepassingsintentie van de clients die verbinding maken met uw beschikbaarheidsgroep te vergemakkelijken, moet elke SQL Server-instantie in de groep worden geconfigureerd met een geschikt toepassingsintentiefilter. Het filter bepaalt welke soorten verbindingen elke replica accepteert.
Een primaire replica die is geconfigureerd om verbindingen in de primaire rol van "Alle verbindingen toestaan" te hebben, accepteert alle verbindingen die via de AG-listener zijn gemaakt. Een primaire replica die is geconfigureerd als "Lees-/schrijfverbindingen toestaan" zal elke verbinding weigeren die "ApplicationIntent=ReadOnly" specificeert.
Bij het configureren van replica's moet u ook definiëren of elke replica al dan niet een Readable Secondary zal zijn. Een replica die is geconfigureerd als "Nee" zal alle verbindingen weigeren. Er wordt aangenomen dat deze replica alleen wordt gebruikt voor failover in een noodherstelsituatie. Als de secundaire replica is geconfigureerd als "Ja", zijn alle verbindingen toegestaan, maar alleen voor leestoegang, zelfs als "ApplicationIntent=ReadOnly" niet is opgegeven. Als de secundaire is geconfigureerd als "Alleen-lezen-intentie", mogen alleen clients die "ApplicationIntent=ReadOnly" specificeren, verbinding maken.
Alleen-lezen routering
Nu we weten hoe we Application Intent op de serverinstanties moeten configureren en de benodigde verbindingsreeksen moeten maken, moeten we alleen-lezen routering van de beschikbaarheidsgroep configureren. Wanneer u verbinding maakt met de AG-listener met behulp van de verbindingsreeks zoals hierboven gedefinieerd, bevraagt de listener de primaire replica-instantie en bepaalt of de verbinding moet worden gemaakt met de primaire (lezen/schrijven) of met een alleen-lezen secundaire. Om dit te bereiken, moet een routeringslijst worden gemaakt voor ELKE beschikbaarheidsreplica die wordt gebruikt als en wanneer de replica de rol van primair op zich neemt. De best practice is doorgaans om elke alleen-lezen routerings-URL voor elke alleen-lezen secundaire replica op te nemen met de lokale replica-URL aan het einde van de lijst. Verbindingsverzoeken met leesintentie worden gerouteerd naar de eerste beschikbare leesbare secundaire op de routeringslijst, er is geen taakverdeling tussen de secundairen.
Pas eerst elke replica aan om de alleen-lezen routerings-URL op te geven:
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'));
Pas vervolgens elke replica aan om de alleen-lezen routeringslijst op te geven die moet worden gebruikt wanneer de gegeven replica de primaire rol heeft:
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'))); De routerings-URL moet de vorm hebben van “TCP://:”. Zie deze blog en dit script gemaakt door Matt Neerincx voor hulp bij het bepalen van uw URL.
Conclusie
Met uw alleen-lezen routering geconfigureerd, AG Listener gemaakt en uw clienttoepassingen met de juiste verbindingsreeksen, zou u een volledig fouttolerante verbinding voor uw beschikbaarheidsgroep moeten hebben. Zorg ervoor dat u de tijd neemt om uw connectiviteit te testen en het vermogen van uw applicaties om uw servers te volgen wanneer ze een failover uitvoeren.