TCP Dynamic Ports

TCP Dynamic Ports to numery przydzielane losowo instancjom nazwanym, wykrywane przez SQL Server Browser.

TCP Dynamic Ports w nazwanych instancjach SQL Server

TCP Dynamic Ports to mechanizm używany przez nazwane instancje Microsoft SQL Server. Nazwana instancja nie musi nasłuchiwać stale na jednym, z góry ustalonym numerze portu TCP. Podczas uruchamiania usługa SQL Server może otrzymać dostępny port dynamiczny i rozpocząć na nim przyjmowanie połączeń. Numer przypisany konkretnej instancji jest zapisywany w konfiguracji protokołu TCP/IP i może zostać zmieniony przy kolejnym uruchomieniu usługi, jeżeli instancja nadal korzysta z trybu dynamicznego.

Mechanizm dotyczy warstwy transportowej TCP, a nie samego języka SQL ani struktury baz danych. Klient musi znać adres komputera oraz numer portu, na którym działa wybrana instancja. W przypadku połączenia zapisanego jako nazwa serwera i nazwa instancji klient może skorzystać z usługi SQL Server Browser. Browser nasłuchuje na porcie UDP 1434 i odpowiada informacją o portach oraz protokołach używanych przez zarejestrowane instancje SQL Server na danym komputerze.

Dynamiczny port nie oznacza, że połączenie jest losowe albo nieprzewidywalne w czasie pojedynczej sesji. Po uruchomieniu usługi instancja nasłuchuje na konkretnym numerze TCP, a istniejące połączenie pozostaje związane z tym portem do czasu jego zakończenia lub zatrzymania usługi. Zmiana numeru może wystąpić przy restarcie SQL Server, dlatego reguły zapory i konfiguracja klientów muszą uwzględniać sposób przydzielania portów.

Jak klient odnajduje port nazwanej instancji

W typowym scenariuszu użytkownik lub aplikacja podaje nazwę w formacie komputer\instancja. Klient nie musi wtedy znać numeru portu, ale musi mieć możliwość odnalezienia go. Sterownik wysyła zapytanie do SQL Server Browser przez UDP 1434. Browser rozpoznaje nazwę instancji i zwraca informacje o konfiguracji, w tym numerze portu TCP używanym przez daną instancję. Następnie klient nawiązuje właściwe połączenie już przez TCP z tym numerem.

Do zestawienia takiego połączenia potrzebne są więc dwa niezależne elementy komunikacji. Pierwszym jest dostęp do UDP 1434 na komputerze, na którym działa SQL Server Browser. Drugim jest dostęp do konkretnego portu TCP, na którym nasłuchuje nazwana instancja. Otwarcie samego UDP 1434 nie wystarczy, ponieważ Browser nie przekazuje danych zapytania SQL i nie zastępuje portu nasłuchu instancji. Z kolei otwarcie portu TCP bez działającego mechanizmu rozpoznawania nazwy nie umożliwi automatycznego połączenia przez zapis `serwer\instancja`, jeśli klient nie otrzyma numeru portu z innego źródła.

Alternatywą dla SQL Server Browser jest podanie portu bezpośrednio, na przykład w zapisie tcp:serwer,port. Wtedy klient łączy się z określonym adresem TCP i nie musi pytać Browsera o lokalizację instancji. Takie rozwiązanie wymaga jednak, aby numer portu był znany i stabilny. Przy dynamicznej konfiguracji port może ulec zmianie po restarcie usługi, dlatego bezpośredni zapis ma sens dopiero po ustaleniu, że instancja korzysta z konkretnego portu stałego albo że proces aktualizacji konfiguracji klientów jest kontrolowany.

Konfiguracja portów w SQL Server Configuration Manager

Ustawienia dynamicznych portów znajdują się w SQL Server Configuration Manager, w właściwościach protokołu TCP/IP przypisanego do konkretnej usługi SQL Server. W zakładce dotyczącej adresów IP można znaleźć sekcje odpowiadające poszczególnym adresom oraz sekcję IPAll. Pole TCP Dynamic Ports wskazuje tryb używania portu dynamicznego, natomiast pole TCP Port służy do wskazania numeru portu stałego. Puste wartości oraz sposób ich interpretacji należy oceniać zgodnie z aktualnym stanem konfiguracji danej instancji, a nie na podstawie samej nazwy pola.

Jeżeli administrator chce wymusić stały port, zwykle usuwa wartość z pola TCP Dynamic Ports i wpisuje wybrany numer w TCP Port, a następnie restartuje usługę SQL Server. Restart jest istotny, ponieważ zmiana parametrów protokołu nie przełącza już działającego gniazda TCP bez ponownego uruchomienia usługi. Po zmianie należy sprawdzić rzeczywisty port nasłuchu oraz dostosować reguły zapory systemu Windows, zapory sieciowej i ewentualnych urządzeń filtrujących ruch pomiędzy klientem a serwerem.

Przy pozostawieniu trybu dynamicznego trzeba ustalić, jaki numer został faktycznie przydzielony po uruchomieniu instancji. Można wykorzystać informacje raportowane przez SQL Server Configuration Manager, log błędów SQL Server lub narzędzia systemowe pokazujące aktywne porty nasłuchujące. Diagnostyka powinna odróżniać port skonfigurowany od portu rzeczywiście używanego: błędna wartość w konfiguracji, brak restartu albo uruchomienie innej instancji może prowadzić do odmiennych wyników.

Diagnostyka problemów z połączeniem przez port dynamiczny

Objawem problemu może być sytuacja, w której klient widzi komputer w sieci, ale nie może połączyć się z nazwą instancji. Najpierw należy ustalić, czy usługa SQL Server działa i czy protokół TCP/IP jest włączony dla właściwej instancji. Następnie trzeba sprawdzić, czy SQL Server Browser jest uruchomiony, jeśli połączenie korzysta z automatycznego odnajdywania portu. Kolejny krok to potwierdzenie, że zapora przepuszcza UDP 1434 oraz bieżący port TCP instancji.

Warto również wykonać test z pominięciem Browsera, używając bezpośredniego adresu i numeru portu, na przykład tcp:nazwa-hosta,51432, przy założeniu, że 51432 jest rzeczywistym portem nasłuchu. Jeżeli takie połączenie działa, a zapis z nazwą instancji nie działa, problem zwykle dotyczy wykrywania instancji, usługi Browser albo filtrowania UDP. Jeżeli nie działa także połączenie bezpośrednie, trzeba sprawdzić port TCP, reguły zapory, trasę sieciową oraz to, czy wskazany adres prowadzi do właściwego komputera.

Przy analizie logów należy zwrócić uwagę na komunikaty o uruchomieniu serwera TCP oraz na numer portu, na którym instancja rozpoczęła nasłuch. Numery portów mogą być inne dla różnych instancji działających na tym samym hoście, a po restarcie mogą się zmienić w trybie dynamicznym. Dlatego dokumentacja połączeń powinna zawierać pełną nazwę instancji, sposób odnajdywania portu, wymagane reguły sieciowe i informację, czy port jest dynamiczny, czy statyczny. Taka weryfikacja pozwala oddzielić błąd konfiguracji SQL Server od problemu z DNS, zaporą lub nieprawidłowym parametrem połączenia.