Nu när tillgänglighetsgrupper blir mer utbredda tänkte jag ta upp ett ämne som kan förbises under den första planeringen och installationen av SQL Server i denna typ av miljö. För att verkligen ha en feltålig konfiguration måste en del eftertanke och planering läggas ner på installationen av databasanslutning.
Jag kommer inte att gå in på detaljerna om hur du ställer in din AlwaysOn-miljö i det här inlägget, men för ytterligare hjälp föreslår jag att du tar en titt på Aaron Bertrands inlägg, "Felsökning av AlwaysOn – Ibland krävs det många uppsättningar ögon." När din miljö väl har konfigurerats är nästa steg för att tillhandahålla databasanslutning att skapa en Availability Group Listener med 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
Ditt virtuella nätverksnamn (VNN) är registrerat i DNS och ägs alltid av SQL Server-instansen där den primära repliken finns. Alla IP-adresser som tillhandahålls när AG Listener konfigureras registreras i DNS under samma virtuella nätverksnamn.
När du har skapat din AG Listener måste du se till att dina kunder kan ansluta. Din applikationsanslutning fungerar på samma sätt som den alltid har gjort, men istället för att peka mot en specifik server i din anslutningssträng, pekar du mot AG Listener.
AG-lyssnare kan endast anslutas till att använda TCP och löses av din lokala DNS till listan över IP-adresser och TCP-portar som är mappade till VNN. Din klient kommer att försöka ansluta till var och en av IP-adresserna i tur och ordning tills den antingen får en anslutning eller tills den når en anslutningstidsgräns. En viktig anslutningssträngparameter att överväga att använda är MultiSubnetFailover. Om den här parametern är inställd på sant kommer klienten att försöka ansluta parallellt vilket möjliggör snabbare anslutning och om nödvändigt snabbare klientfel:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
När en failover inträffar återställs klientanslutningarna och ägandet av AG Listener flyttas till SQL Server-instansen som tar över den primära replikrollen. VNN-slutpunkten är sedan bunden till de nya IP-adresserna och TCP-portarna för den nya primära replikinstansen. Beroende på klienten kommer en automatisk återanslutning till AG att ske, eller så kan användaren behöva starta om den berörda applikationen eller anslutningen manuellt.
Applikationsavsikt
En av de största anledningarna till att implementera Availability Groups är att ge möjligheten att utnyttja dina backup- eller katastrofåterställningsmiljöer för att ladda ner arbete från din produktionsmiljö. Dessa servrar kan nu användas för säkerhetskopiering, analys, ad-hoc-frågor och rapportering, eller någon annan operation där det räcker med en skrivskyddad kopia av databasen.
För att ge skrivskyddad åtkomst till dina sekundära repliker används ApplicationIntent-anslutningssträngsparametern. En valfri skrivskyddad routinglista med SQL Server-slutpunkter kan konfigureras på varje replik. Den här listan används för att omdirigera klientanslutningsförfrågningar som använder parametern ApplicationIntent=ReadOnly till den första tillgängliga sekundära repliken som har konfigurerats med ett lämpligt programavsiktsfilter.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Applikationsavsiktsfiltrering
För att underlätta Application Intent från klienterna som ansluter till din tillgänglighetsgrupp, bör varje SQL Server-instans i gruppen konfigureras med ett lämpligt Application Intent Filter. Filtret bestämmer vilka typer av anslutningar varje replik kommer att acceptera.
En primär replik som är konfigurerad att ha anslutningar i primärrollen "Tillåt alla anslutningar" kommer att acceptera alla anslutningar som görs via AG Listener. En primär replik som konfigurerats som "Tillåt läs-/skrivanslutningar" kommer att avvisa alla anslutningar som anger "ApplicationIntent=ReadOnly."
När du konfigurerar repliker måste du också definiera om var och en ska vara en läsbar sekundär eller inte. En replik som är konfigurerad som "Nej" kommer att neka alla anslutningar. Denna replik antas endast användas för failover i en katastrofåterställningssituation. Om den sekundära repliken är konfigurerad som "Ja", kommer alla anslutningar att tillåtas, men endast för läsbehörighet, även om "ApplicationIntent=ReadOnly" inte är angivet. Slutligen, om den sekundära är konfigurerad som "Skrivskyddad avsikt", kommer endast klienter som anger "ApplicationIntent=ReadOnly" att tillåtas att ansluta.
Skrivskyddad routing
Nu när vi vet hur man konfigurerar Application Intent på serverinstanserna och skapar de nödvändiga anslutningssträngarna, måste vi konfigurera Availability Group skrivskyddad routing. När du ansluter till AG Listener med anslutningssträngen enligt definitionen ovan frågar lyssnaren den primära replikinstansen och avgör om anslutningen ska göras till den primära (läs/skriv) eller till en skrivskyddad sekundär. För att åstadkomma detta måste en routinglista skapas för VARJE tillgänglighetsreplik som används om och när repliken antar rollen som primär. Vanligtvis är det bästa sättet att inkludera varje skrivskyddad routing-URL för varje skrivskyddad sekundär replik med den lokala replik-URL:n i slutet av listan. Anslutningsförfrågningar med läsavsikt dirigeras till den första tillgängliga läsbara sekundären på routinglistan, det finns ingen lastbalansering mellan sekundärerna.
Ändra först varje replik för att tillhandahålla den skrivskyddade 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'));
För det andra, ändra varje replik för att tillhandahålla den skrivskyddade routningslistan som ska användas när den givna repliken är i den primära rollen:
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'))); Routningsadressen ska ha formen "TCP://:". För hjälp med att fastställa din webbadress, se den här bloggen och skriptet skapat av Matt Neerincx.
Slutsats
Med din skrivskyddade routing konfigurerad, AG Listener skapad och dina klientapplikationer använder rätt anslutningssträngar, bör du ha en fullt feltolerant anslutning för din tillgänglighetsgrupp. Se till att du tar dig tid att testa din anslutning och dina programs förmåga att följa dina servrar när de misslyckas.