SQL Server Listener

SQL Server Listener to wirtualna nazwa sieciowa grupy dostępności, kierująca klientów do aktualnej repliki podstawowej.

Rola SQL Server Listener w grupie dostępności

SQL Server Listener, określany także jako listener grupy dostępności, jest logicznym punktem dostępu dla klientów łączących się z bazą działającą w ramach Always On Availability Groups. Nie wskazuje on bezpośrednio jednej, niezmiennej instancji SQL Server. Zamiast tego korzysta z wirtualnej nazwy sieciowej oraz przypisanego adresu IP, aby kierować połączenia do repliki, która w danym momencie pełni rolę podstawowej. Dzięki temu aplikacja może używać jednego adresu w konfiguracji połączenia, nawet gdy po przełączeniu awaryjnym aktywna replika znajduje się na innym hoście.

Listener nie jest osobnym silnikiem bazy danych ani usługą przechowującą dane. Jego zadaniem jest pośredniczenie w lokalizacji właściwego endpointu instancji SQL Server. Stan repliki, role podstawowej i pomocniczej oraz dostępność poszczególnych baz są obsługiwane przez mechanizmy Always On Availability Groups. Po zmianie roli repliki nazwa listenera pozostaje taka sama, natomiast odpowiedź sieciowa i sposób obsługi połączeń umożliwiają klientowi dotarcie do aktualnej repliki podstawowej.

Nazwa DNS, adres IP i port połączenia

Listener ma własną nazwę sieciową, która musi być rozpoznawana przez DNS w środowisku, z którego korzystają klienci. W zależności od topologii może być powiązany z jednym adresem IP albo z wieloma adresami IP należącymi do różnych podsieci. W konfiguracji SQL Server określa się również port TCP, na którym klient ma nawiązywać połączenie. Najczęściej używa się portu 1433, ale listener może działać na innym porcie, jeśli taki port został skonfigurowany dla odpowiedniej instancji i dopuszczony w zaporze.

W środowisku obejmującym kilka podsieci listener może zwracać więcej niż jeden adres IP. Klient powinien wtedy obsługiwać szybkie nawiązywanie połączeń z wieloma adresami. W sterownikach Microsoft SQL Server stosuje się do tego parametr MultiSubnetFailover=True w łańcuchu połączenia. Parametr ten zmienia sposób próby połączenia tak, aby klient nie czekał kolejno na wygaśnięcie limitu czasu dla każdego nieaktywnego adresu. Nie zastępuje on jednak poprawnej konfiguracji DNS, routingu, zapory ani samej grupy dostępności.

Ważne jest rozróżnienie między nazwą listenera a nazwą komputera lub instancji SQL Server. Wpisanie nazwy konkretnego węzła omija listener i wiąże aplikację z jednym hostem. Taka konfiguracja może przestać działać po przełączeniu awaryjnym, ponieważ wskazany komputer nie musi już obsługiwać roli podstawowej. W łańcuchu połączenia należy używać nazwy listenera oraz, gdy jest to wymagane, jawnie podanego portu w formacie nazwa-listenera,port.

Przełączanie awaryjne i kierowanie ruchu

Podczas failoveru replika pomocnicza przejmuje rolę podstawowej, a poprzednia replika podstawowa może przejść do roli pomocniczej albo stać się niedostępna. Listener zachowuje tę samą nazwę, lecz jego aktywne powiązania sieciowe muszą odzwierciedlać nowy stan grupy. Istniejące połączenia TCP zwykle nie są automatycznie przenoszone między instancjami. Aplikacja musi wykryć zerwanie połączenia i wykonać ponowną próbę, korzystając z tego samego listenera.

Skuteczne wykorzystanie listenera wymaga, aby aplikacja miała właściwie ustawione limity czasu, mechanizm ponawiania połączeń oraz obsługę transakcji przerwanych podczas przełączenia. Sam listener nie gwarantuje bezprzerwowej pracy aplikacji. Zapewnia stabilny punkt adresowy, ale zachowanie klienta po błędzie zależy od używanego sterownika, biblioteki dostępu do danych i konfiguracji aplikacji. Połączenia przeznaczone do zapisu powinny trafiać do repliki podstawowej. Dla odczytów można skonfigurować routing tylko do odczytu, jeżeli grupa dostępności, repliki i sterownik obsługują ten mechanizm.

W łańcuchu połączenia można spotkać właściwości takie jak ApplicationIntent=ReadOnly. Informuje ona SQL Server, że połączenie ma zamiar wykonywać operacje odczytu, ale nie oznacza samodzielnie, że ruch zostanie skierowany do konkretnej repliki pomocniczej. Do takiego kierowania potrzebne są dodatkowe ustawienia read-only routing po stronie grupy dostępności oraz odpowiednia konfiguracja klienta. Listener związany z ruchem podstawowym i listener używany do odczytów mogą pełnić różne funkcje zależnie od projektu środowiska.

Diagnostyka problemów z listenerem

Analizę problemu należy rozpocząć od ustalenia, czy nazwa listenera rozwiązuje się w DNS na właściwy adres lub zestaw adresów. Następnie trzeba sprawdzić osiągalność wskazanego portu TCP z komputera klienta, reguły zapory oraz stan usługi SQL Server na aktywnej replice. Sam fakt, że nazwa odpowiada na zapytanie DNS, nie potwierdza jeszcze działania połączenia do silnika. Błąd może występować na poziomie rozpoznawania nazwy, routingu, zapory, portu, uwierzytelniania albo stanu grupy dostępności.

Warto porównać połączenie wykonane przez listener z połączeniem wykonanym bezpośrednio do nazwy konkretnej instancji. Jeżeli połączenie bezpośrednie działa, a listener nie, podejrzenie pada na konfigurację nazwy sieciowej, adresów IP, portu, uprawnień do utworzenia lub aktualizacji obiektu w katalogu oraz rejestracji DNS. Jeżeli oba połączenia zawodzą, problem może dotyczyć samej usługi SQL Server, zapory albo stanu repliki. Po przełączeniu awaryjnym należy również zweryfikować, czy klient ponawia połączenie i czy korzysta z parametru MultiSubnetFailover=True, gdy listener obejmuje wiele podsieci.

SQL Server Listener jest więc elementem konfiguracji wysokiej dostępności, a nie uniwersalnym mechanizmem naprawiającym błędy sieciowe lub błędy aplikacji. Prawidłowa diagnostyka obejmuje jednocześnie stan grupy dostępności, role replik, rozwiązywanie DNS, adresy IP, port TCP, reguły zapory, łańcuch połączenia oraz zachowanie sterownika po utracie sesji. Dopiero zgodność tych warstw pozwala ocenić, czy klient rzeczywiście korzysta z aktualnej repliki podstawowej i czy przełączenie awaryjne zostanie przez niego prawidłowo obsłużone.