Porty dla Service Broker

Porty dla Service Broker wymagają otwarcia dedykowanego endpointu komunikacji między instancjami.

Porty dla Service Broker – czym jest komunikacja między bazami

Porty dla Service Broker to element konfiguracji odpowiedzialny za wymianę komunikatów pomiędzy usługami działającymi w różnych instancjach SQL Server. Service Broker zapewnia mechanizm kolejkowania, routingu i dostarczania wiadomości, dlatego komunikacja nie ogranicza się do lokalnej obsługi kolejki w obrębie jednej bazy. Jeżeli wiadomość ma zostać przekazana do usługi znajdującej się w innej instancji, wymagany jest endpoint Service Broker oraz dostęp do portu TCP wskazanego w jego konfiguracji.

W praktyce endpoint pełni funkcję punktu nasłuchującego. Przyjmuje połączenia z innych instancji, a następnie pozwala na prowadzenie dialogów Service Broker zgodnie z regułami bezpieczeństwa i routingu. Samo utworzenie kolejki, usługi i kontraktu nie wystarcza do komunikacji zdalnej. Potrzebne są jeszcze poprawne trasy, identyfikatory brokerów, odpowiednie uprawnienia oraz przepływ ruchu przez zaporę sieciową. Brak któregoś z tych elementów może sprawić, że wiadomości pozostaną w kolejce nadawczej mimo prawidłowego działania pozostałych obiektów.

Port należy traktować jako część całego łańcucha komunikacyjnego, a nie jako pojedynczą wartość wpisywaną bez dodatkowej analizy. Znaczenie mają między innymi adres lub nazwa hosta, na którym nasłuchuje endpoint, protokół używany przez Service Broker, status endpointu oraz reguły zezwalające na połączenia przychodzące i wychodzące. W dokumentacji środowiska warto zapisać, która instancja pełni rolę nadawcy, która odbiorcy, jaki endpoint jest używany oraz jakie trasy wskazują poszczególne usługi.

Porty dla Service Broker a endpoint, firewall i routing

Konfiguracja portu dla Service Broker obejmuje kilka warstw, które muszą być ze sobą zgodne. Pierwszą warstwą jest endpoint utworzony w instancji SQL Server. Drugą stanowi zapora systemowa na komputerze, na którym działa instancja. Trzecia warstwa może obejmować zaporę sieciową, urządzenie filtrujące lub reguły segmentacji ruchu pomiędzy podsieciami. Dopiero pełna zgodność tych poziomów daje szansę na zestawienie połączenia.

W odróżnieniu od połączenia aplikacyjnego z bazą danych port endpointu Service Broker nie jest wybierany wyłącznie na podstawie numeru portu używanego przez usługę dostępu do SQL Server. Instancja może korzystać z jednego portu do standardowych połączeń klienta i z innego portu do komunikacji Service Broker. Takie rozdzielenie ułatwia kontrolę reguł zapory, analizę logów i ograniczenie zakresu dozwolonego ruchu. W środowisku, w którym występuje kilka instancji, nie powinno się zakładać, że każda z nich korzysta z tego samego portu.

Przydatne jest porównanie trzech sytuacji. W komunikacji lokalnej, gdy nadawca i odbiorca znajdują się w tej samej instancji, dodatkowy ruch sieciowy może nie występować. W komunikacji między bazami znajdującymi się w jednej instancji nadal potrzebne są poprawne obiekty Service Broker, ale problem z zaporą może nie być widoczny. W komunikacji pomiędzy odrębnymi instancjami pojawia się natomiast pełny zestaw wymagań: rozpoznawanie hosta, osiągalność portu, reguły zapory, endpoint w stanie STARTED, trasa do usługi oraz zgodność ustawień bezpieczeństwa.

Nie powinno się też utożsamiać otwartego portu z działającą komunikacją. Test osiągalności TCP potwierdza jedynie możliwość nawiązania połączenia na poziomie sieci. Nie potwierdza poprawności certyfikatów, autoryzacji, tras ani istnienia docelowej usługi. Z kolei błąd związany z dialogiem nie zawsze oznacza problem z samym portem, ponieważ przyczyną może być nieprawidłowy identyfikator brokera, błędna nazwa trasy albo wyłączony endpoint.

Porty dla Service Broker – typowe problemy diagnostyczne

Jednym z częstszych problemów jest rozbieżność pomiędzy portem wpisanym w endpoint a portem dopuszczonym w regułach zapory. Wystarczy zmiana konfiguracji instancji albo odtworzenie reguły na innym hoście, aby połączenia zaczęły być odrzucane. Podobny skutek może wystąpić po zmianie nazwy komputera, adresu sieciowego lub sposobu rozwiązywania nazw. Wtedy trasa wskazuje poprawny obiekt logiczny, ale nie prowadzi do właściwego adresu.

Drugą grupę stanowią problemy z zakresem ruchu. Reguła może zezwalać na połączenia z jednego adresu, podczas gdy komunikacja faktycznie pochodzi z innego interfejsu lub podsieci. W przypadku translacji adresów źródłowych widoczny w zaporze adres może różnić się od adresu zapisującego konfigurację. Dlatego podczas analizy należy uwzględnić rzeczywisty kierunek ruchu, adres źródłowy obserwowany w logach oraz urządzenia pośredniczące.

Trudności powoduje także uruchamianie kilku endpointów na tym samym porcie albo próba przypisania portu zajętego przez inną usługę. W takiej sytuacji endpoint może nie wystartować lub działać inaczej, niż zakładano. Warto sprawdzić stan endpointu, komunikaty SQL Server, bieżące nasłuchiwanie TCP oraz zgodność konfiguracji obu stron dialogu. Weryfikacja powinna obejmować również to, czy wiadomości oczekujące w kolejce mają status wskazujący na problem z dostarczeniem, czy raczej na błąd aplikacyjny.

Ważne jest odróżnienie blokady sieciowej od błędu konfiguracji Service Broker. Jeżeli port nie jest osiągalny, test połączenia TCP zwykle kończy się niepowodzeniem lub przekroczeniem czasu. Jeżeli port odpowiada, ale dialog nie jest dostarczany, należy sprawdzić certyfikaty, użytkowników, powiązanie endpointu z mechanizmem uwierzytelniania, trasę i nazwę usługi. Analiza logów po obu stronach skraca czas poszukiwania przyczyny, ponieważ pokazuje, na którym etapie komunikacja przestaje być kontynuowana.

Porty dla Service Broker – praktyczne wskazówki konfiguracji

Przed zmianą konfiguracji warto sporządzić prostą mapę zależności. Powinny znaleźć się na niej instancja nadawcza, instancja odbiorcza, nazwy baz, adresy hostów, port endpointu oraz kierunek połączenia. Przydatne jest również zapisanie informacji, czy ruch ma przebiegać w jedną stronę, czy w obu kierunkach. Service Broker korzysta z dialogów, dlatego wymagania komunikacyjne mogą być szersze, niż wynikałoby to z samego opisu wysyłania wiadomości.

Numer portu powinien być ustalony świadomie i utrzymywany w dokumentacji. Nie zaleca się przypadkowego wybierania wartości ani pozostawiania konfiguracji bez opisu. Przy zmianie portu trzeba zaktualizować endpoint, reguły zapory i wszystkie trasy odwołujące się do danego adresu. Po modyfikacji należy wykonać test z hosta nadawczego do hosta odbiorczego, a następnie sprawdzić dostarczenie kontrolowej wiadomości i stan kolejki.

Reguły zapory powinny być możliwie precyzyjne. Warto ograniczyć je do konkretnego portu, protokołu i znanych adresów źródłowych, o ile architektura komunikacji na to pozwala. Należy unikać otwierania szerokiego zakresu portów bez uzasadnienia, ponieważ utrudnia to późniejszą diagnostykę i zwiększa powierzchnię dostępu. Równocześnie zbyt restrykcyjna reguła może zablokować odpowiedzi lub komunikację zwrotną wymaganą przez dialog.

Po zakończeniu konfiguracji powinno się wykonać test w kilku etapach: sprawdzić rozwiązywanie nazwy hosta, osiągalność adresu, dostępność konkretnego portu, stan endpointu, poprawność trasy i stan kolejki. Jeżeli występują opóźnienia, warto obserwować czas narastania liczby wiadomości oczekujących oraz wpisy w dziennikach. Taka sekwencja pozwala odróżnić problem z siecią od problemu logicznego i ogranicza liczbę niekontrolowanych zmian.

Porty dla Service Broker – kiedy zgłosić się do serwisu

Wsparcie serwisowe bywa zasadne, gdy po zmianie zapory, migracji instancji, odtworzeniu bazy albo modyfikacji adresacji komunikaty przestają docierać do celu. Szczególnej uwagi wymaga sytuacja, w której test portu przechodzi poprawnie, lecz kolejka nadawcza stale rośnie, endpoint zmienia stan albo w logach pojawiają się błędy uwierzytelniania. W takich przypadkach potrzebna jest analiza konfiguracji SQL Server, reguł sieciowych i zależności pomiędzy usługami.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się analizą usterek sprzętowych i systemowych, a naprawy z reguły realizowane są do 3 dni roboczych. Przy zgłoszeniu warto przekazać opis objawów, moment pojawienia się problemu, informacje o ostatnich zmianach oraz wyniki dostępnych testów. Ułatwia to rozdzielenie awarii sieciowej od błędu konfiguracji i pozwala dobrać zakres dalszej diagnostyki bez przypadkowego zmieniania wielu parametrów jednocześnie.