SQL Server Integration Runtime

Integration Runtime to komponent łączący środowisko lokalne z usługami danych w chmurze Azure.

SQL Server Integration Runtime jako warstwa pośrednicząca

SQL Server Integration Runtime jest składnikiem środowiska Azure Data Factory oraz Azure Synapse, który wykonuje zadania związane z przepływem danych, transformacją i dostępem do źródeł znajdujących się poza samą usługą chmurową. Nie jest to baza danych ani samodzielny system do przechowywania informacji. Jego rolą jest zapewnienie miejsca, w którym mogą zostać uruchomione określone operacje integracyjne, takie jak odczyt danych, kopiowanie tabel, wywołanie procedury, przygotowanie pliku lub przekazanie wyników do kolejnego etapu procesu.

W praktyce można traktować go jako wykonawcę poleceń zdefiniowanych w potoku danych. Konfiguracja potoku powstaje w usłudze zarządzanej, natomiast Integration Runtime odpowiada za wykonanie wybranych czynności w odpowiednim środowisku. Ma to znaczenie zwłaszcza wtedy, gdy dane pochodzą z lokalnej instancji SQL Server, z sieci prywatnej, z maszyny znajdującej się w centrum danych albo z innego źródła, do którego usługa chmurowa nie powinna mieć bezpośredniego dostępu.

W przypadku SQL Server Integration Runtime często wykorzystywany jest wariant self-hosted. Taki wariant instaluje się w środowisku, które ma dostęp do lokalnego SQL Server oraz do wymaganych zasobów Azure. Dzięki temu przepływ może zostać uruchomiony bez przenoszenia całej bazy do chmury. Jest to podejście przydatne podczas etapowej migracji, budowy kopii analitycznej, okresowego eksportu danych lub łączenia lokalnych aplikacji z usługami przetwarzania danych.

SQL Server Integration Runtime a inne warianty wykonywania

Ważne jest rozróżnienie SQL Server Integration Runtime od pozostałych rodzajów Integration Runtime dostępnych w ekosystemie Azure. Wariant Azure może wykonywać operacje w infrastrukturze zarządzanej przez dostawcę chmury, natomiast self-hosted działa na wskazanym komputerze lub w kontrolowanym środowisku użytkownika. Różnica nie sprowadza się wyłącznie do miejsca instalacji. Wpływa również na dostępność źródeł, przebieg komunikacji, sposób aktualizacji, zasady kontroli dostępu oraz możliwość korzystania z zasobów znajdujących się za zaporą.

Self-hosted Integration Runtime nie powinien być utożsamiany z bramą dostępu do całej sieci. Zakres jego działania wynika z uprawnień konta, konfiguracji połączeń, reguł zapory i ustawień systemu, na którym został zainstalowany. Odpowiednie ograniczenie dostępu zmniejsza ryzyko przypadkowego ujawnienia danych oraz ułatwia ustalenie, które procesy mogą komunikować się z lokalnym SQL Server. Warto również rozdzielić środowiska testowe i produkcyjne, aby sprawdzanie konfiguracji nie wpływało na bieżące zadania.

W porównaniu z bezpośrednim eksportem plików Integration Runtime oferuje centralne sterowanie przepływem, harmonogramem i obsługą błędów. W porównaniu z pełną migracją bazy pozwala pozostawić dane w dotychczasowym miejscu, a do Azure przesyłać tylko wybrane zestawy lub wyniki transformacji. Nie oznacza to jednak, że każda integracja będzie działać tak samo szybko. Wydajność zależy między innymi od obciążenia komputera wykonawczego, jakości połączenia, zapytań SQL, rozmiaru przesyłanych danych i sposobu ustawienia równoległości zadań.

SQL Server Integration Runtime i typowe problemy z integracją

Jednym z częstszych problemów jest brak połączenia z lokalną bazą. Przyczyną może być niepoprawna nazwa instancji, niewłaściwy port, wyłączona usługa SQL Server Browser, blokada na zaporze albo ograniczenie połączeń przychodzących. Błąd może wynikać także z tego, że nazwa serwera jest rozpoznawana z komputera lokalnego, lecz nie z maszyny, na której działa self-hosted Integration Runtime. Diagnostyka powinna obejmować sprawdzenie rozpoznawania nazwy, dostępności portu, poświadczeń oraz uprawnień użytkownika bazy.

Osobną grupę stanowią problemy z uwierzytelnianiem. Połączenie może wymagać logowania SQL, konta systemowego albo mechanizmu zintegrowanego z domeną. Każdy z tych wariantów ma inne wymagania dotyczące haseł, uprawnień i sposobu przechowywania danych dostępowych. Należy unikać nadawania kontu szerszych uprawnień, niż są potrzebne do odczytu, zapisu lub wykonania konkretnej procedury. Warto też sprawdzić, czy hasło nie wygasło i czy konto nie zostało zablokowane.

Problemy mogą pojawić się również podczas kopiowania danych. Niezgodne typy kolumn, wartości puste, znaki spoza oczekiwanego kodowania, różnice w formacie daty albo kolizje nazw mogą zatrzymać potok mimo prawidłowego połączenia z bazą. Przy większych tabelach znaczenie ma sposób filtrowania danych. Pełne odczyty wykonywane przy każdym uruchomieniu obciążają źródło i wydłużają pracę, dlatego często stosuje się pobieranie przyrostowe na podstawie znacznika czasu, klucza rosnącego lub rejestru zmian.

Nie należy pomijać stanu samego komputera wykonawczego. Brak miejsca na dysku, ograniczenia antywirusa, uśpienie systemu, restart po aktualizacji albo zatrzymana usługa mogą spowodować przerwę w działaniu. Przydatne jest regularne sprawdzanie logów, stanu usługi oraz historii uruchomień potoków. Jeżeli błąd występuje tylko w określonych porach, warto porównać go z obciążeniem procesora, pamięci, dysku i łącza.

SQL Server Integration Runtime w codziennej konfiguracji

Przed instalacją warto opisać przepływ danych w prosty sposób: skąd dane są pobierane, gdzie mają trafić, jakie operacje są wykonywane i jak ma być rozpoznane poprawne zakończenie zadania. Taki opis ułatwia wybór wariantu Integration Runtime oraz ogranicza liczbę późniejszych zmian. Należy określić, czy połączenie będzie używane do jednorazowej migracji, regularnego zasilania hurtowni, synchronizacji wybranych tabel czy wykonywania transformacji.

Podczas instalacji self-hosted Integration Runtime trzeba zwrócić uwagę na konto usługi, dostęp do sieci oraz możliwość komunikacji z wymaganymi usługami Azure. Komputer powinien być utrzymany w stanie, który pozwala na stabilne wykonywanie zadań. Nie zaleca się instalowania komponentu na przypadkowej stacji używanej równocześnie do wielu niezwiązanych czynności, jeżeli przepływy mają działać w sposób przewidywalny. Znaczenie ma także plan aktualizacji i możliwość odtworzenia ustawień po awarii.

Bezpieczna konfiguracja obejmuje ograniczenie uprawnień, ochronę danych uwierzytelniających oraz kontrolę reguł zapory. Jeżeli zakres źródeł lub odbiorców się zmienia, należy przejrzeć połączenia i upewnić się, że stare dostępy zostały wycofane. Przydatne jest prowadzenie dokumentacji zawierającej nazwy potoków, wykorzystywane połączenia, właścicieli danych, zasady ponawiania oraz sposób postępowania z rekordami, których nie udało się przetworzyć.

Warto również rozdzielić błąd techniczny od błędu danych. Niedostępny port lub zatrzymana usługa wskazują na problem infrastrukturalny, natomiast brak wymaganej wartości w kolumnie może oznaczać problem jakości danych albo niepełną regułę mapowania. Taki podział skraca diagnostykę i pomaga skierować sprawę do właściwej osoby. Przy projektowaniu potoków należy przewidzieć logowanie, ścieżkę obsługi błędów i możliwość ponownego uruchomienia bez tworzenia duplikatów.

Kiedy zgłosić SQL Server Integration Runtime do serwisu

Wsparcie może być potrzebne, gdy połączenie z SQL Server przestaje działać po zmianie systemu, aktualizacji, modyfikacji zapory lub przeniesieniu bazy na inną maszynę. Zgłoszenie jest zasadne także wtedy, gdy potok działa tylko ręcznie, losowo się zatrzymuje, przetwarza dane niepełne albo wykonuje zadania znacznie dłużej niż wcześniej. Przed przekazaniem sprawy warto zebrać komunikat błędu, czas wystąpienia, nazwę potoku, rodzaj używanego Integration Runtime oraz informację, czy problem dotyczy wszystkich, czy tylko wybranych źródeł.

W Warszawie analizę takich problemów można zlecić firmie Warszawskie Pogotowie Komputerowe 24/7, szczególnie gdy konieczne jest sprawdzenie komputera wykonawczego, połączeń sieciowych, usług systemowych lub konfiguracji dostępu do SQL Server. Przydatne jest wcześniejsze ustalenie, czy problem dotyczy samego środowiska lokalnego, czy ustawień potoku w Azure. Pozwala to ograniczyć zakres diagnostyki i przygotować uporządkowany opis objawów.

Nie powinno się samodzielnie usuwać komponentu ani kasować logów przed wykonaniem kopii informacji diagnostycznych. Zmiana wielu ustawień naraz może utrudnić ustalenie przyczyny. Rozsądne postępowanie polega na zapisaniu aktualnej konfiguracji, sprawdzeniu podstawowej łączności, porównaniu działającego i niedziałającego zadania oraz zachowaniu komunikatów błędów. Dzięki temu SQL Server Integration Runtime można ocenić jako element całego przepływu, a nie wyłącznie jako pojedynczą aplikację zainstalowaną na komputerze.