Porty dla Always On

Porty dla Always On obejmują port endpointu grupy dostępności, domyślnie 5022, obok standardowego portu instancji.

Port endpointu grupy dostępności w SQL Server

W środowisku SQL Server Always On Availability Groups komunikacja między replikami odbywa się przez punkt końcowy grupy dostępności, nazywany także endpointem typu Database Mirroring. Jest to obiekt konfigurowany w konkretnej instancji SQL Server i używany do przesyłania informacji o stanie replik, blokach dziennika transakcji oraz synchronizacji baz danych. Domyślnie endpoint korzysta z portu TCP 5022. Port ten nie jest jednak portem aplikacyjnym samej bazy danych ani portem, na którym klient wykonuje zwykłe zapytania do instancji.

Numer 5022 jest wartością domyślną, a nie obowiązkowym numerem dla każdej instalacji. Administrator może utworzyć endpoint na innym porcie TCP, jeżeli wymaga tego istniejąca topologia sieci, polityka zapory albo współistnienie kilku instancji SQL Server na jednym hoście. Wszystkie repliki uczestniczące w danej konfiguracji muszą mieć możliwość nawiązania połączenia z odpowiednim endpointem. Zmiana portu wymaga więc spójnej aktualizacji konfiguracji SQL Server, reguł zapory oraz ewentualnych dokumentów opisujących połączenia między serwerami.

Różnica między endpointem, portem instancji i listenerem

Port endpointu Always On należy odróżnić od portu, na którym nasłuchuje instancja SQL Server. Dla domyślnej instancji często spotyka się TCP 1433, ale nie jest to reguła bez wyjątków. Instancja nazwana może korzystać z portu dynamicznego albo ze statycznego numeru ustalonego w SQL Server Configuration Manager. Ten port służy do obsługi połączeń klientów z silnikiem bazy danych, natomiast port 5022 służy do komunikacji replik między sobą.

Osobnym elementem jest SQL Server Availability Group Listener. Listener udostępnia nazwę sieciową i adres IP, pod który aplikacja może kierować połączenia do grupy dostępności. Listener ma własny port klienta, często ustawiony na 1433, lecz może działać również na innym porcie. Jego port nie zastępuje portu endpointu replik. W praktyce jedna konfiguracja może więc wymagać osobnego dopuszczenia ruchu do portu endpointu, portu instancji oraz portu listenera. SQL Server Browser korzysta z UDP 1434 i może pomagać w wykrywaniu portu instancji nazwanej, ale nie jest mechanizmem synchronizacji Always On i nie zastępuje reguły dla endpointu TCP.

Reguły zapory i kierunek komunikacji

Reguła zapory dla endpointu powinna dopuszczać ruch TCP na porcie skonfigurowanym dla endpointu, domyślnie 5022. Zakres źródeł najlepiej ograniczyć do adresów IP lub podsieci używanych przez serwery będące replikami. Samo otwarcie portu na jednym komputerze nie zapewnia komunikacji, ponieważ połączenie między replikami wymaga poprawnej drogi sieciowej w obu kierunkach oraz odpowiednich reguł na zaporach pośrednich. W zależności od topologii trzeba uwzględnić zaporę systemu Windows, urządzenia sieciowe oraz reguły bezpieczeństwa obowiązujące w segmentach, w których znajdują się repliki.

Weryfikacja powinna rozpocząć się od ustalenia rzeczywistego numeru portu przypisanego do endpointu, a nie od założenia, że zawsze jest to 5022. W SQL Server można sprawdzić konfigurację endpointów w katalogu systemowym, między innymi za pomocą widoku sys.database_mirroring_endpoints. Stan endpointu można także ocenić przez widok sys.endpoints. Następnie należy sprawdzić, czy port nasłuchuje na właściwym adresie oraz czy połączenie między serwerami jest możliwe. W systemie Windows pomocne są narzędzia takie jak Test-NetConnection z parametrem -Port, użyte z adresem konkretnej repliki. Test powinien być wykonany z każdego serwera, który musi inicjować połączenie do pozostałych.

Objawy błędnego portu w konfiguracji Always On

Nieprawidłowy port endpointu może powodować brak synchronizacji baz, przejście repliki w stan niesynchronizowany albo błędy połączenia widoczne w dzienniku SQL Server. Jeżeli endpoint jest zatrzymany, nasłuchuje na innym porcie niż wskazuje dokumentacja lub jest blokowany przez zaporę, repliki nie będą mogły prawidłowo wymieniać danych. Podobny objaw może pojawić się po odtworzeniu serwera, zmianie adresów sieciowych, migracji instancji albo wdrożeniu nowej reguły bezpieczeństwa.

Diagnostyka powinna rozdzielać trzy warstwy: dostępność sieciową portu endpointu, stan samego endpointu w SQL Server oraz stan repliki w grupie dostępności. Udane połączenie do portu instancji nie dowodzi, że działa komunikacja Always On, ponieważ port instancji i port endpointu pełnią różne funkcje. Należy również sprawdzić, czy nazwy DNS używane przez listener wskazują aktualne adresy oraz czy aplikacja łączy się z właściwym portem klienta. W przypadku konfiguracji wielosieciowej znaczenie może mieć także poprawne rozwiązywanie nazwy listenera i dostęp do odpowiednich adresów IP, ale nie zmienia to faktu, że replikacja nadal wymaga działającego endpointu TCP.

Przy naprawie problemu trzeba zachować zgodność między konfiguracją endpointu, ustawieniami instancji i zaporą. Nie należy otwierać przypadkowych portów ani zamieniać portu listenera z portem endpointu bez sprawdzenia definicji używanej w konkretnej instalacji SQL Server. Rzetelna diagnostyka obejmuje odczyt konfiguracji, test połączenia z właściwego serwera, analizę komunikatów SQL Server oraz ponowną kontrolę synchronizacji po zmianie reguł.