SQL Server i kontroler domeny

Instalacja SQL Server na kontrolerze domeny jest odradzana ze względów bezpieczeństwa i wydajności.

Rola SQL Server i kontrolera domeny w jednej infrastrukturze

SQL Server jest systemem zarządzania relacyjnymi bazami danych używanymi przez aplikacje biznesowe, programy księgowe, systemy magazynowe, oprogramowanie produkcyjne i rozwiązania obsługujące dane użytkowników. Kontroler domeny pełni inną funkcję: przechowuje katalog Active Directory, uwierzytelnia konta, wydaje informacje o członkostwie w grupach oraz uczestniczy w stosowaniu zasad bezpieczeństwa na komputerach podłączonych do domeny. Połączenie obu ról na jednym komputerze oznacza, że system odpowiedzialny za tożsamość całej organizacji staje się jednocześnie platformą dla usługi bazodanowej.

Kontroler domeny nie działa jak typowy komputer z systemem Windows. Nie udostępnia standardowego zestawu lokalnych kont i grup, ponieważ zarządzanie użytkownikami odbywa się przede wszystkim przez katalog domenowy. Ma to znaczenie podczas instalowania SQL Server, konfigurowania kont usług, nadawania praw do plików oraz ustalania, które procesy mogą uruchamiać się automatycznie. Błąd w konfiguracji uprawnień może dotknąć nie tylko jednej aplikacji, lecz także mechanizmów logowania i zarządzania urządzeniami w całej domenie.

Instalacja SQL Server na kontrolerze domeny nie jest technicznie tym samym co instalacja na oddzielnym komputerze członkowskim. Usługa bazodanowa korzysta z zasobów procesora, pamięci operacyjnej, dysków i sieci, a kontroler domeny musi zachować dostępność dla uwierzytelniania oraz obsługi katalogu. Obciążenie generowane przez zapytania, kompilację planów wykonania, zapis transakcji lub operacje konserwacyjne może więc konkurować z zadaniami katalogowymi.

Skutki połączenia dwóch ról na jednym komputerze

Najważniejszym problemem jest wspólna granica awarii. Uszkodzenie systemu operacyjnego, problem z podsystemem dyskowym, błędna aktualizacja albo przeciążenie pamięci może jednocześnie ograniczyć dostęp do baz danych i logowanie użytkowników. Na oddzielnych komputerach awaria jednej roli nie musi zatrzymać drugiej. Rozdzielenie funkcji ułatwia także planowanie kopii zapasowych, aktualizacji i okien serwisowych.

Znaczenie ma również powierzchnia ataku. SQL Server udostępnia dodatkowe usługi, biblioteki, punkty komunikacji oraz mechanizmy uwierzytelniania. Każdy dodatkowy komponent wymaga aktualizacji, właściwego ograniczenia dostępu i monitorowania. Jeżeli podatność lub błąd konfiguracji pozwoli na przejęcie procesu działającego z wysokimi uprawnieniami, konsekwencje mogą obejmować zasoby katalogu domenowego, a nie tylko pojedynczą bazę.

Wspólna instalacja utrudnia dobór uprawnień. SQL Server powinien działać z kontem usługowym dopasowanym do wymaganych zadań, a nie z szeroko uprzywilejowanym kontem administratora domeny. Trzeba rozdzielić uprawnienia do plików danych, dzienników transakcji, kopii zapasowych i katalogów tymczasowych. Należy także sprawdzić, czy aplikacja korzystająca z bazy używa uwierzytelniania Windows, czy innego trybu obsługi kont, oraz czy zasady domenowe nie zmieniają parametrów potrzebnych do prawidłowego uruchomienia usługi.

W małej firmie taka konfiguracja może pojawić się z powodu ograniczonego budżetu, braku dodatkowego komputera albo odziedziczonej instalacji. Jeżeli baza jest niewielka, obciążenie sporadyczne, a środowisko ma poprawnie wykonane kopie zapasowe, ryzyko operacyjne może być akceptowane przez właściciela infrastruktury. Nie zmienia to faktu, że jest to kompromis, który powinien być udokumentowany i regularnie oceniany.

Objawy, które mylą diagnozę

Spowolnienie aplikacji korzystającej z SQL Server nie zawsze oznacza problem z samą bazą. Przyczyną może być brak wolnego miejsca na dysku, powolny nośnik, konkurencja o pamięć, błędne ustawienia zasilania, opóźnienia sieciowe albo jednoczesne wykonywanie zadań katalogowych. Diagnoza powinna obejmować obciążenie procesora, wykorzystanie pamięci, czas oczekiwania na operacje dyskowe, stan usług oraz zdarzenia systemowe, bez wyłączania zabezpieczeń na próbę.

Charakterystycznym sygnałem problemu z konfiguracją konta jest sytuacja, w której usługa SQL Server nie uruchamia się po restarcie, mimo że wcześniej działała poprawnie. Możliwe powody obejmują zmianę hasła konta usługowego, odebranie prawa do uruchamiania usługi, modyfikację zasad domenowych, brak dostępu do katalogu z plikami bazy lub uszkodzenie zależności wymaganych przez aplikację. Samo ponowne uruchomienie komputera nie wyjaśnia przyczyny i może utrudnić późniejszą analizę.

Inny przypadek to poprawne działanie logowania domenowego przy równoczesnych błędach aplikacji. Może wtedy brakować połączenia z właściwym wystąpieniem SQL Server, aplikacja może wskazywać nieaktualną nazwę komputera, a zapora systemowa może blokować skonfigurowany kanał komunikacji. Warto sprawdzić konfigurację klienta, nazwę instancji, sposób rozwiązywania nazw, uprawnienia do konkretnej bazy oraz aktualny stan usług, zamiast zmieniać przypadkowo ustawienia katalogu domenowego.

Problematyczne bywają także kopie zapasowe. Kopia plików całego komputera nie zastępuje poprawnie zaplanowanej ochrony baz danych i dzienników transakcji. Trzeba ustalić, gdzie są zapisywane kopie, kto może je odczytać, czy na nośniku pozostaje wystarczająca ilość miejsca oraz czy odtworzenie zostało kiedykolwiek sprawdzone. Wspólna rola kontrolera domeny i SQL Server zwiększa znaczenie testów odtwarzania, ponieważ awaria jednego komputera może pozbawić organizację kilku kluczowych funkcji naraz.

Przygotowanie bezpiecznej diagnozy i dalszych działań

Do analizy takiej instalacji warto przygotować listę usług, sposób logowania do SQL Server, lokalizacje plików baz i kopii, informacje o wolnym miejscu oraz opis aplikacji, która korzysta z danych. Przydatne są również godziny występowania problemu, komunikaty z dzienników systemowych i SQL Server oraz informacja o ostatnich aktualizacjach. Nie należy usuwać baz, dzienników ani plików konfiguracyjnych przed wykonaniem kopii i ustaleniem ich roli.

Jeżeli celem jest trwałe ograniczenie ryzyka, typowym kierunkiem jest przeniesienie SQL Server na osobny komputer członkowski, a następnie przeprowadzenie kontrolowanej migracji baz, kont usługowych, połączeń aplikacji, harmonogramów kopii i uprawnień. Taka operacja wymaga sprawdzenia zgodności wersji, czasu niedostępności, sposobu przełączenia aplikacji oraz planu powrotu do poprzedniego stanu. Nie powinno się jej rozpoczynać bez potwierdzonej kopii i przetestowanej procedury odtworzenia.

Do serwisu sprzętu komputerowego warto zgłosić się wtedy, gdy objawom towarzyszą restarty, zawieszanie systemu, błędy dysku, problemy z pamięcią, nadmierna temperatura, niestabilne zasilanie albo utrata dostępu do danych. Serwis może sprawdzić stan fizyczny komputera, dysków, pamięci, płyty głównej i zasilania oraz wykonać podstawowy odzysk danych z uszkodzonych nośników. W przypadku środowiska łączącego SQL Server z kontrolerem domeny wyniki diagnostyki sprzętowej powinny zostać przekazane osobie odpowiedzialnej za administrację, aby decyzje dotyczące usług, uprawnień i migracji nie były podejmowane wyłącznie na podstawie objawów sprzętowych.