Instalacja MSSQL Server na kontrolerze domeny


(p_and) #1

Witam serdecznie

W pracowni mam skonfigurowany kontroler domeny na Windows Server 2012 R2 Standard. W domenie pracuje 20 hostów. W związku z koniecznością wdrożenia oprogramowania muszę skonfigurować w sieci serwer baz danych MSSQL Server. W związku z niewielkimi wymaganiami dotyczącymi wydajności przetwarzania zapytań i przyrostem danych w bazie w zupełności wystarczy darmowa edycja Express. Niestety spotkałem się z opiniami, że MS nie zaleca instalowania MSSQL Server na Windows Server, który pracuje jako kontroler domeny. Zastanawiam się z czego wynikają takiego ograniczenia. Z tego co się orientuję w ramach licencji, którą posiadam mogę utworzyć wirtualną maszynę z Windows Server 2012 na już zainstalowanym serwerze. Zastanawiam się czy rozwiązaniem problemu może być opcja, gdy jeden z systemów będzie kontrolerem domeny, a drug będzie obsługiwała serwer baz danych. Oczywiście zdaję sobie sprawę, że MSSQL Server mogę postawić na Windows 7/8/10 ale wykluczam takie rozwiązanie. Tak samo nie jestem przekonany czy wirtualna maszyna rozwiąże problem, czy chodzi tu o to, że oprogramowanie serwera baz danych nie może być skonfigurowane do pracy na maszynie na której funkcjonuje kontroler domeny bez względu na sposób instalacji (ta sama instancja serwera, dodatkowa wirtualna maszyna z osobnym serwerem). Chciałbym dowiedzieć się, czy ktoś z szanownych użytkowników spotkał się z takim problemem, eksploatuje podobne rozwiązanie lub zna lepszy sposób na poradzenie sobie z tym problemem. Z góry serdecznie dziękuję za udzielone odpowiedzi.

Piotr


(kowgli) #2

Technicznie oczywiście nie ma problemu, aby na jednej maszynie mieć kontroler domeny i inne usługi (choćby SQL, IIS, Exchange, SharePoint, udziały sieciowe, FTP…). Często tak się robi(ło) w małych firmach. Nawet była do tego specjalna edycja Windowsa, bodaj Small Business Server. Nie jest to jednak zalecane z paru, dosyć oczywistych powodów:

  1. Jeśli jakakolwiek z tych innych usług ma podatności, to mogą one dać atakującemu bezpośredni dostęp do kontrolera domeny. Co już pozwala na praktycznie wszystko…np. automatyzację instalacji jakiegoś malware u wszystkich użytkowników, przejęcie kont, cokolwiek…
  2. Inne usługi mogą wymagać stosunkowo częstych restartów, choćby ze względu na aktualizacje. Coś czego chcemy unikać w kontrolerze domeny.
  3. Generalnie rozdzielanie usług na osobne maszyny (obecnie wirtualne) ułatwia zarządzanie i zapobiega sytuacjom, kiedy jedna z nich “oszaleje” i zacznie np. zjadać cały RAM albo CPU, powodując niedostępność pozostałych.
  4. Inne usługi możesz chcieć wystawić na świat. To dla kontrolera domeny jest zdecydowanie złym pomysłem.

Jeśli nie chcesz inwestować w osobną maszynę lub całkowicie wirtualizować środowika, to postawienie wirtualki z usługami na kontrolerze domeny, będzie na pewno lepsze niż instalowanie bezpośrednio na nim. Szkoda, że kontroler domeny sam w sobie już nie jest maszyną wirtualną. Mógłbyś postawić po prostu kolejną wirtualną maszynę obok, na tym samym fizycznym hoście.
Nawet jeśli trzeba by było kupić osobną licencję na Windows Server, to przecież nie są one jakieś specjalnie drogie.

Patrząc na to jednak nieco bardziej pragmatycznie. Jeśli potrzebujesz tylko SQL Server Express, działającego lokalnie … to zainstaluj na tym serwerze i już. Pamiętaj tylko o ograniczeniu mu (w konfiguracji SQL’a) maksymalnego zużycia RAM.


(p_and) #3

Dziękuje za bardzo obszerne i merytoryczne wyjaśnienie! :slight_smile:

Z tego co się orientuje licencja, którą posiadam pozwala mi na postawienie dwóch wirtualek:

Windows Server licenses are assigned to the physical hosts, not to VMs. A single Standard Edition license grants you the right to run up to two Windows Server VMs concurrently on a given host. There is no limit to the number you can create (other than storage of the host), but the license grants you the right to run up to two Windows Server VMs.

W tej sytuacji rozwiązanie zaproponowane przez Ciebie, które dotyczy dwóch niezależnych wirtualnych maszyn na fizycznym hoście ma dla mnie duży sens. Odpada problem z zarządzaniem maszynami. Przy restarcie instancji z MSSQL Server kontroler domeny cały czas pracuje w tle no i obie instancje są od siebie odizolowane. Teoretycznie uzyskanie dostępu do kontrolera domeny w wyniku wykorzystania luk oprogramowanie serwera baz danych jest utrudnione.

Oczywiście zdaję sobie sprawę z ograniczeń wynikających z wykorzystywania wersji Express serwera baz danych MSSQL, czyli 1,4 GB RAM. Rozumiem, że konieczność ograniczenia pamięci RAM dla wirtualki na której będzie uruchomiony SQL Server wynika z oszczędności zasobów skoro oprogramowanie i tak nie pozwala na większą alokację, czy też jest jeszcze jakiś inny powód?

Zaznaczę tylko, że fizyczny serwer na którym będą skonfigurowane obie wirtualki to Dell PowerEdge R230 z 16 GB RAM i Intel Xeon E3-1220 v6 na pokładzie.

Jeszcze raz dziękuję za odpowiedź. Zdaję sobię sprawę, że pytania mogą być dla Was banalne ale dopiero zaczynam raczkować w rozwiązaniach serwerowych i bazodanowych MS.

Pozdrawiam


(bachus) #4

Moim zdaniem jest praktycznie oczywiste, że powinieneś to rozdzielić na dwie VMki:

  • domenowa (tam możesz trzymać jeszcze DNS, DHCP itd.),
  • aplikacyjna.
    Sama wirtualizacja ułatwi Ci też skalowalność, łatwość backupu i DR (z backupu maszynę wirtualną możesz uruchomić nawet na prostym laptopie do czasu rozwiązania problemów ze sprzętem).

(Luc3k) #5

Dorzucę swoje dwa grosze: mam zainstalowane lokalnie na dwóch serwerach MSSQL Express. Serwery są kontrolerami domeny (Windows 2003 Server SBS oraz Windows Server 2016). Dotychczas nie miałem problemów związanych z bazą, która pracuje na serwerze, który pełni funkcję kontrolera domeny.