Nu hvor tilgængelighedsgrupper er ved at blive mere udbredt, tænkte jeg, at jeg ville dække et emne, som kan blive overset under den indledende planlægning og installation af SQL Server i denne type miljø. For virkelig at have en fejltolerant konfiguration skal der tænkes og planlægges i opsætningen af databaseforbindelse.
Jeg vil ikke gå ind i detaljerne omkring opsætningen af dit AlwaysOn-miljø i dette indlæg, men for yderligere hjælp foreslår jeg, at du tager et kig på Aaron Bertrands indlæg, "Fejlfinding AlwaysOn – Nogle gange kræver det mange sæt øjne." Når dit miljø er konfigureret, er næste trin i at levere databaseforbindelse at oprette en Availability Group Listener ved hjælp af SQL Management Studio eller 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
Dit virtuelle netværksnavn (VNN) er registreret i DNS og ejes altid af den SQL Server-instans, hvor den primære replika findes. Alle de IP-adresser, der leveres under konfiguration af AG Listener, er registreret i DNS under det samme virtuelle netværksnavn.
Når du har oprettet din AG Listener, skal du sikre dig, at dine kunder kan oprette forbindelse. Din applikationsforbindelse fungerer på samme måde, som den altid har gjort, men i stedet for at pege mod en bestemt server i din forbindelsesstreng, peger du mod AG Listener.
AG-lyttere kan kun tilsluttes ved hjælp af TCP og løses af din lokale DNS til listen over IP-adresser og TCP-porte, der er knyttet til VNN. Din klient vil forsøge at oprette forbindelse til hver af IP-adresserne på skift, indtil den enten får en forbindelse, eller indtil den når en forbindelsestimeout. En vigtig forbindelsesstrengparameter at overveje at bruge er MultiSubnetFailover. Hvis denne parameter er indstillet til sand, vil klienten forsøge at forbinde parallelt, hvilket muliggør hurtigere forbindelse og om nødvendigt hurtigere klient-failovers:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Når der opstår en failover, nulstilles klientforbindelserne, og ejerskabet af AG Listener flyttes til den SQL Server-instans, der overtager den primære replika-rolle. VNN-slutpunktet er derefter bundet til de nye IP-adresser og TCP-porte på den nye primære replikainstans. Afhængigt af klienten vil der ske en automatisk genforbindelse til AG'en, eller brugeren skal muligvis genstarte den berørte applikation eller forbindelse manuelt.
Ansøgningshensigt
En af de største grunde til at implementere Availability Groups er at give mulighed for at udnytte dine backup- eller katastrofegendannelsesmiljøer til at aflaste arbejde fra dit produktionsmiljø. Disse servere kan nu bruges til sikkerhedskopiering, analyse, ad-hoc-forespørgsler og rapportering eller enhver anden operation, hvor det er tilstrækkeligt at have en skrivebeskyttet kopi af databasen.
For at give skrivebeskyttet adgang til dine sekundære replikaer bruges ApplicationIntent-forbindelsesstrengparameteren. En valgfri skrivebeskyttet routingliste over SQL Server-slutpunkter kan konfigureres på hver replika. Denne liste bruges til at omdirigere klientforbindelsesanmodninger, der bruger ApplicationIntent=ReadOnly-parameteren til den første tilgængelige sekundære replika, som er blevet konfigureret med et passende programhensigtsfilter.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Applikationshensigtsfiltrering
For at lette Application Intent fra de klienter, der forbinder til din Availability Group, skal hver SQL Server-instans i gruppen konfigureres med et passende Application Intent Filter. Filteret bestemmer, hvilke typer forbindelser hver replika vil acceptere.
En primær replika, som er konfigureret til at have forbindelser i den primære rolle "Tillad alle forbindelser", vil acceptere alle forbindelser, der er foretaget gennem AG Listener. En primær replika konfigureret som "Tillad læse-/skriveforbindelser" vil afvise enhver forbindelse, der angiver "ApplicationIntent=ReadOnly."
Når du konfigurerer replikaer, skal du også definere, om hver enkelt skal være en læsbar sekundær. En replika, der er konfigureret som "Nej", vil afvise alle forbindelser. Denne replika antages kun at blive brugt til failover i en katastrofeoprettelse. Hvis den sekundære replika er konfigureret som "Ja", vil alle forbindelser være tilladt, men kun for læseadgang, selvom "ApplicationIntent=ReadOnly" ikke er angivet. Endelig, hvis den sekundære er konfigureret som "Skrivebeskyttet hensigt", vil kun klienter, der angiver "ApplicationIntent=ReadOnly" have tilladelse til at oprette forbindelse.
Skrivebeskyttet routing
Nu hvor vi ved, hvordan man konfigurerer Application Intent på serverforekomsterne og opretter de nødvendige forbindelsesstrenge, er vi nødt til at konfigurere Availability Group skrivebeskyttet routing. Når du opretter forbindelse til AG Listener ved hjælp af forbindelsesstrengen som defineret ovenfor, forespørger lytteren den primære replikaforekomst og bestemmer, om forbindelsen skal foretages til den primære (læse/skrive) eller til en skrivebeskyttet sekundær. For at opnå dette skal der oprettes en routingliste for HVER tilgængelighedsreplika, som bruges, hvis og når replikaen påtager sig rollen som primær. Typisk er den bedste praksis at inkludere hver skrivebeskyttet routing-URL for hver skrivebeskyttet sekundær replika med den lokale replika-URL i slutningen af listen. Læsehensigtsforbindelsesanmodninger dirigeres til den første tilgængelige læsbare sekundære på routinglisten, der er ingen belastningsbalancering mellem sekundærerne.
Først skal du ændre hver replika for at give den skrivebeskyttede routing-URL:
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'));
For det andet skal du ændre hver replika for at give den skrivebeskyttede routingliste, der skal bruges, når den givne replika er i den primære rolle:
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'))); Routing-URL'en skal være i form af "TCP://:". For at få hjælp til at bestemme din URL, se denne blog og script lavet af Matt Neerincx.
Konklusion
Med din skrivebeskyttede routing konfigureret, AG Listener oprettet, og dine klientapplikationer bruger de korrekte forbindelsesstrenge, bør du have en fuldstændig fejltolerant forbindelse til din tilgængelighedsgruppe. Sørg for at bruge lidt tid på at teste din forbindelse og dine applikationers evne til at følge dine servere, når de fejler.