Teraz, gdy grupy dostępności stają się coraz bardziej rozpowszechnione, pomyślałem, że omówię temat, który może zostać przeoczony podczas wstępnego planowania i instalacji SQL Server w tego typu środowisku. Aby naprawdę mieć konfigurację odporną na błędy, należy przemyśleć i zaplanować konfigurację połączenia z bazą danych.
W tym poście nie będę wchodził w szczegóły konfigurowania środowiska AlwaysOn, ale w celu uzyskania dodatkowej pomocy sugeruję zapoznanie się z postem Aarona Bertranda „Rozwiązywanie problemów z AlwaysOn – Czasami wymaga to wielu par oczu”. Po skonfigurowaniu środowiska następnym krokiem w zapewnieniu łączności z bazą danych jest utworzenie nasłuchiwania grupy dostępności za pomocą SQL Management Studio lub T-SQL:
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
Ciągły połączenia odbiornika AG
Twoja nazwa sieci wirtualnej (VNN) jest zarejestrowana w systemie DNS i zawsze należy do wystąpienia programu SQL Server, w którym znajduje się replika podstawowa. Wszystkie adresy IP podane podczas konfigurowania odbiornika AG są zarejestrowane w systemie DNS pod tą samą nazwą sieci wirtualnej.
Po utworzeniu odbiornika AG musisz upewnić się, że Twoi klienci mogą się połączyć. Połączenie aplikacji działa w ten sam sposób, w jaki zawsze, jednak zamiast wskazywać konkretny serwer w ciągu połączenia, wskazujesz na odbiornik AG.
Odbiorniki AG mogą być połączone tylko przy użyciu protokołu TCP i są rozwiązywane przez lokalny serwer DNS do listy adresów IP i portów TCP, które są mapowane na VNN. Twój klient będzie próbował połączyć się z każdym z adresów IP po kolei, dopóki nie uzyska połączenia lub osiągnie limit czasu połączenia. Ważnym parametrem parametrów połączenia, który należy rozważyć, jest MultiSubnetFailover. Jeśli ten parametr jest ustawiony na true, klient będzie próbował połączyć się równolegle, umożliwiając szybszą łączność i, jeśli to konieczne, szybsze przełączanie awaryjne klienta:
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Gdy nastąpi przełączenie awaryjne, połączenia klientów są resetowane, a własność odbiornika AG zostaje przeniesiona do wystąpienia SQL Server, które przejmuje rolę repliki podstawowej. Punkt końcowy VNN jest następnie powiązany z nowymi adresami IP i portami TCP nowego wystąpienia repliki podstawowej. W zależności od klienta nastąpi automatyczne ponowne połączenie z AG lub użytkownik może być zmuszony do ręcznego ponownego uruchomienia aplikacji lub połączenia, którego dotyczy problem.
Zamiar aplikacji
Jednym z najważniejszych powodów, dla których warto wdrożyć grupy dostępności, jest zapewnienie możliwości wykorzystania środowisk tworzenia kopii zapasowych lub odzyskiwania po awarii w celu odciążenia środowiska produkcyjnego. Serwery te mogą być teraz używane do tworzenia kopii zapasowych, analiz, zapytań ad hoc i raportowania lub wszelkich innych operacji, w których wystarczy mieć kopię bazy danych tylko do odczytu.
Aby zapewnić dostęp tylko do odczytu do replik pomocniczych, używany jest parametr parametrów połączenia ApplicationIntent. W każdej replice można skonfigurować opcjonalną listę routingu tylko do odczytu punktów końcowych programu SQL Server. Ta lista służy do przekierowywania żądań połączeń klientów, które używają parametru ApplicationIntent=ReadOnly do pierwszej dostępnej repliki pomocniczej, która została skonfigurowana z odpowiednim filtrem intencji aplikacji.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Filtrowanie intencji aplikacji
Aby ułatwić klientom nawiązywanie połączenia z grupą dostępności, każda instancja programu SQL Server w grupie powinna być skonfigurowana z odpowiednim filtrem zamiarów aplikacji. Filtr określa, jakie typy połączeń zaakceptuje każda replika.
Replika podstawowa, która jest skonfigurowana tak, aby mieć Połączenia w roli podstawowej „Zezwalaj na wszystkie połączenia” będzie akceptować wszelkie połączenia wykonane przez odbiornik AG. Replika podstawowa skonfigurowana jako „Zezwalaj na połączenia do odczytu/zapisu” odrzuci każde połączenie, które określa „ApplicationIntent=ReadOnly”.
Podczas konfigurowania replik należy również określić, czy każda z nich będzie czytelnym plikiem pomocniczym. Replika skonfigurowana jako „Nie” odrzuci wszystkie połączenia. Zakłada się, że ta replika jest używana tylko do przełączania awaryjnego w sytuacji odzyskiwania po awarii. Jeśli replika pomocnicza jest skonfigurowana jako „Tak”, wszystkie połączenia będą dozwolone, ale tylko do odczytu, nawet jeśli nie określono „ApplicationIntent=ReadOnly”. Wreszcie, jeśli serwer pomocniczy jest skonfigurowany jako „Intencja tylko do odczytu”, tylko klienci, którzy określą „ApplicationIntent=ReadOnly” będą mogli się połączyć.
Routing tylko do odczytu
Teraz, gdy wiemy, jak skonfigurować zamiar aplikacji na wystąpieniach serwera i utworzyć niezbędne parametry połączenia, musimy skonfigurować routing tylko do odczytu grupy dostępności. Po nawiązaniu połączenia z odbiornikiem AG przy użyciu parametrów połączenia zdefiniowanych powyżej odbiornik wysyła zapytanie do wystąpienia repliki podstawowej i określa, czy połączenie powinno zostać nawiązane z podstawowym (odczyt/zapis), czy z pomocniczym tylko do odczytu. Aby to osiągnąć, należy utworzyć listę routingu dla KAŻDEJ repliki dostępności, która jest używana wtedy, gdy replika przyjmuje rolę podstawowej. Zazwyczaj najlepszym rozwiązaniem jest uwzględnienie każdego adresu URL routingu tylko do odczytu dla każdej repliki pomocniczej tylko do odczytu z adresem URL repliki lokalnej na końcu listy. Żądania połączenia z zamiarem odczytu są kierowane do pierwszego dostępnego do odczytu wtórnego na liście routingu, nie ma równoważenia obciążenia między drugorzędnymi.
Najpierw zmodyfikuj każdą replikę, aby zapewnić adres URL routingu tylko do odczytu:
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'));
Po drugie, zmodyfikuj każdą replikę, aby udostępnić listę routingu tylko do odczytu, która będzie używana, gdy dana replika pełni rolę podstawową:
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'))); Adres URL routingu powinien mieć postać „TCP://:”. Aby uzyskać pomoc w określeniu adresu URL, zobacz ten blog i skrypt stworzony przez Matta Neerincx.
Wniosek
Po skonfigurowaniu routingu tylko do odczytu, utworzeniu nasłuchiwania AG i korzystaniu przez aplikacje klienckie z poprawnych parametrów połączenia, połączenie dla grupy dostępności powinno być w pełni odporne na błędy. Poświęć trochę czasu na przetestowanie łączności i zdolności aplikacji do śledzenia serwerów po awarii.
