Porty dynamiczne

Porty dynamiczne to numery przydzielane losowo instancjom nazwanym, wymagające usługi SQL Server Browser do ich wykrycia.

Jak SQL Server przydziela port instancji nazwanej

Port dynamiczny w Microsoft SQL Server jest numerem TCP przydzielanym instancji nazwanej podczas uruchamiania usługi silnika bazy danych. Instancja nazwana nie musi więc stale nasłuchiwać na jednym, ręcznie ustalonym porcie. Mechanizm ten różni się od typowej konfiguracji instancji domyślnej, która standardowo korzysta z portu TCP 1433. W przypadku instancji nazwanej numer portu może zmienić się po restarcie usługi, jeżeli konfiguracja przewiduje dynamiczne przydzielanie portu.

Informacja o używanym porcie jest zapisywana w konfiguracji protokołu TCP/IP dla konkretnej instancji. SQL Server może rozpocząć nasłuchiwanie na porcie wskazanym w polu portu dynamicznego, a następnie utrzymywać ten wybór do czasu ponownego uruchomienia usługi lub zmiany konfiguracji. Sam fakt, że instancja ma nazwę, nie oznacza jeszcze, że zawsze używa portu dynamicznego. Administrator może przypisać jej port statyczny, aby uprościć reguły zapory sieciowej, konfigurację monitoringu i połączenia aplikacyjne.

Rola SQL Server Browser w odnajdywaniu portu

Klient, który zna tylko nazwę komputera oraz nazwę instancji SQL Server, musi ustalić, pod którym numerem portu działa ta instancja. Służy do tego usługa SQL Server Browser. Po uruchomieniu nasłuchuje ona na porcie UDP 1434 i odpowiada na zapytania dotyczące instancji SQL Server dostępnych na danym hoście. Odpowiedź może zawierać między innymi nazwę instancji, informację o włączonych protokołach oraz numer portu TCP używanego przez silnik.

Przykładowe połączenie w formie nazwa-komputera\nazwa-instancji wymaga mechanizmu, który przetłumaczy nazwę instancji na rzeczywisty port. Jeżeli SQL Server Browser jest zatrzymany, zablokowany przez zaporę albo niedostępny przez sieć, klient może nie odnaleźć instancji mimo prawidłowej pracy samego silnika. Połączenie może wtedy działać po podaniu portu bezpośrednio, na przykład w formie nazwa-komputera, numer-portu, o ile port TCP jest osiągalny i silnik SQL Server przyjmuje połączenia sieciowe.

Objawy problemów z portem dynamicznym

Nieprawidłowa konfiguracja portu dynamicznego często ujawnia się jako błąd połączenia aplikacji z nazwanym wystąpieniem SQL Server. Program może zgłaszać brak serwera, przekroczenie limitu czasu, nieodnalezienie określonej instancji albo błąd związany z dostawcą TCP. Taki objaw nie dowodzi jeszcze uszkodzenia bazy danych. Przyczyną może być brak włączonego protokołu TCP/IP, zatrzymana usługa SQL Server Browser, blokada UDP 1434, blokada aktualnego portu TCP albo użycie nieaktualnego numeru portu przez aplikację.

Diagnostyka powinna rozdzielać kilka etapów. Najpierw należy ustalić, czy działa właściwa usługa silnika SQL Server oraz czy instancja nasłuchuje przez TCP/IP. Następnie trzeba sprawdzić aktualny numer portu w SQL Server Configuration Manager, w sekcji protokołu TCP/IP właściwej instancji, zwracając uwagę na ustawienia IPAll, pola TCP Dynamic Ports i TCP Port. W dzienniku błędów SQL Server można również znaleźć komunikat informujący o adresie IP i porcie, na którym serwer rozpoczął nasłuchiwanie. Dopiero potem warto testować dostępność portu z komputera klienckiego.

Port dynamiczny a konfiguracja połączenia i zapory

Dynamiczny port wymaga spójnej konfiguracji po obu stronach połączenia. Na serwerze musi działać silnik SQL Server z włączonym TCP/IP, a sieć musi przepuszczać ruch do aktualnego portu TCP. Jeżeli połączenia wykorzystują nazwę instancji, konieczna może być także dostępność SQL Server Browser przez UDP 1434. Reguła zapory zezwalająca wyłącznie na TCP 1433 nie wystarczy dla nazwanej instancji działającej na innym porcie. W dodatku port dynamiczny może się zmienić po restarcie usługi, dlatego pojedyncze otwarcie starego numeru nie zapewnia trwałego rozwiązania.

W środowisku, w którym wymagane jest przewidywalne filtrowanie ruchu, często przypisuje się instancji nazwanej konkretny port statyczny i odwołuje się do niego bezpośrednio w konfiguracji aplikacji. Takie rozwiązanie ogranicza zależność od SQL Server Browser, ale wymaga wybrania wolnego numeru, ustawienia go w konfiguracji TCP/IP, ponownego uruchomienia usługi oraz utworzenia odpowiedniej reguły zapory. Zmiany powinny być sprawdzane na konkretnym komputerze i dla konkretnej instancji, ponieważ sam numer portu, status Browsera lub ustawienia protokołów nie opisują stanu wszystkich instancji SQL Server w sieci.