Rozmieszczenie usług na serwerach w infrastrukturze IT

Kontroler domeny, serwer plików, serwer wydruku, serwer aplikacji niosą ze sobą nieco problemów, jakich? Chodzi o rozmieszczenie tych usług na serwerach i tutaj kolejne pytanie, serwery tylko fizyczne czy również wirtualne a może kontenery? Jeżeli fizyczne to kiedy z nich korzystać, jakie plusy niosą za sobą maszyny wirtualne. Rozmieszczenie usług na różnych maszynach ma sens, ogranicza zakres awarii, w powiązaniu z serwerami wirtualnymi pozwala na maksymalne wykorzystanie zasobów.

Kontroler domeny (DC)

W średnich lub dużych sieciach głównym komputerem staje się kontroler domeny (DC). Odpowiada on za zarządzanie użytkownikami domeny oraz komputerami, które w tej domenie istnieją. Może również dodatkowo utrzymywać DNS, czyli konwersje nazwy komputera lub udziału sieciowego na adres IP. Mając wiele urządzeń warto postawić również na usługę DHCP, która będzie dostarczała adresację oraz konfigurację sieci (maska sieciowa, brama domyślna, adresy serwerów DNS) do tych urządzeń.

Teraz pytanie czy taki serwer musi być zawsze fizyczny, czy może warto pomyśleć o wirtualizacji?

Odpowiedź na to pytanie kilka lat temu byłaby jedna, oczywiście tylko fizyczny. Jednak dziś w dobie wirtualizacji: Hyper-V, VMware etc. warto pomyśleć o zaoszczędzeniu zarówno miejsca jak i zasobów na fizyczne pudełko.

W dalszej części kilka mitów oraz zaleceń w jaki sposób zabrać się za przygotowanie tej części środowiska.

Mit 1 Kontrolery domeny nie powinny być wirtualizowane

Wiele organizacji już teraz korzysta z kontrolerów zwirtualizowanych, gdzie nie ma żadnej różnicy jeżeli chodzi o wydajność. Chmura publiczna, która jest bardziej zaawansowanym środowiskiem wirtualnym niż to lokalne oparte o Hyper-V jest tego najlepszym przykładem.

Mit 2 Musisz zachować co najmniej jeden fizyczny kontroler domeny

Chociaż wiele lat temu mogło to być prawdą, dziś nie jest to duży problem. Powody, dla których ludzie wcześniej utrzymywali fizyczne kontrolery domeny, miały więcej wspólnego ze stosunkowo prymitywnym stanem wirtualizacji. Awarie i problemy były bardziej powszechne. Nawet gdy awarie nie występowały, wirtualizacja była wciąż młodą i nieco nieznaną usługą. Sam pierwszy raz zetknąłem się z wirtualizacją poprzez VirtualBox a później z pierwszą wersją w Windows Server 2008. Dostawcy szybko poprawili je, aby służyły Administratorom do ułatwienia pracy.

Czasy się zmieniły. Jeśli masz fizyczny kontroler domeny, nie spieszyłbym się, aby się go pozbyć. Jeśli go nie masz lub masz taki, którego nie chcesz zachować, rozważ jego wirtualizację. Jeżeli obawiasz się o ewentualne uszkodzenia, warto przygotować backup pod maszyny wirtualne.

Mit 3 Nie mogę zalogować się do komputera, ponieważ kontroler domeny nie został uruchomiony

Tak, jeżeli kontroler domeny nie działa może pojawić się problem w dostępie do udostępnionych katalogów czy drukarek. Jednak nie ma znaczenia czy kontroler jest fizyczny czy wirtualny. Problemy mogą zdarzyć się zawsze. Sam tego doświadczyłem, gdy w kontrolerze domeny uległ uszkodzeniu sterownik karty sieciowej i przez 2h nie było dostępu do zasobów. Jednak jak szybko można naprawić system na fizycznym serwerze? Postawienie wszystkiego od zera zajmie godziny lub dni, a maszynę wirtualną można odzyskać w ciągu kilkunastu minut.

Brak kontrolera nie powoduje, że użytkownicy nie mogą pracować. Hasła dla kont użytkowników na komputerach nie potrzebują kontaktu z kontrolerem, ponieważ przechowywane są lokalnie, więc zezwolą na logowanie na profil użytkownika.

W Windows Server 2008 R2 i wcześniejszych usługa klastra (połączone min. 2 maszyny) w ogóle się nie uruchomiła, jeżeli nie mogła skontaktować się z kontrolerem domeny. Od wersji 2012 R2 nie jest to prawdą. Nawet jeśli usługa klastrowania się nie uruchomi, uruchomią się zarówno Hyper-V, jak i VMMS.EXE. Dzięki podstawowym technikom rozwiązywania problemów z klastrem można przełączyć klastrowaną maszynę wirtualną do trybu online bez działania klastra.

Mit 4 Hyper-V hostujący własny kontroler domeny

Nie ma problemu, aby kontroler działał jako maszyna wirtualna i współpracował z maszynami zapasowymi, które również są wirtualne.

Wirtualizacja serwera domeny

Mit 5 Przesunięcie czasu jest niekontrolowane, gdy kontrolery domeny są zwirtualizowane

Windows nie jest systemem operacyjnym czasu rzeczywistego, więc różnica czasu jest nieunikniona. Jeśli procesory hosta Hyper-V są mocno obciążone, rozregulowanie czasu będzie znaczniejsze. Nie jest to jednak problem niekontrolowany, chyba że procesory nie odpowiadają. W takim przypadku problem nie polega na tym, że kontroler domeny jest zwirtualizowany; problem polega na tym, że host jest przeciążony.

Dobre praktyki wirtualizacji kontrolera domeny

Przyjrzyjmy się niektórym najlepszym praktykom dotyczącym kontrolerów domeny, z naciskiem na uruchamianie ich w środowisku zwirtualizowanym.

1. Zawsze zaczynaj od oceny swojej sytuacji

Zanim zaczniesz, określ, jak ma wyglądać ostateczna sytuacja kontrolera domeny, jak małe awarie będą obsługiwane i jak będziesz odzyskiwać środowisko. Ile kontrolerów domeny potrzebujesz? Miejsce działania? Czy kontrolery domeny powinny być wysokiej dostępności? Jak będzie wyglądał harmonogram tworzenia kopii zapasowych? Odpowiedzi na te pytania nakreślą najbardziej ostateczny obraz tego, jak powinno wyglądać Twoje wdrożenie.

2. Określ, ile kontrolerów domeny jest niezbędnych

Pojedynczy kontroler domeny może z łatwością obsłużyć tysiące obiektów (użytkowników, komputerów). Wszelkie dodatkowe kontrolery domeny służą zwiększeniu odporności. W przypadku wielu lokacji, spróbuj umieścić co najmniej jeden kontroler domeny w każdej z nich. Odpowiednia konfiguracja pozwoli na wymianę konfiguracji pomiędzy nimi. Warto skorzystać z dokumentacji Microsoftu w kwestii przygotowania konfiguracji środowiska kontrolera domeny.

3. Określ, gdzie umieścić kontrolery domeny

Istnieje kilka bardzo prostych wskazówek dotyczących umieszczania kontrolera domeny.

  • Jeśli to możliwe, wiele kontrolerów domeny nie powinno znajdować się na tym samym sprzęcie. Głównym celem wielu kontrolerów domeny jest zapewnienie 100% dostępności usług domeny. Jeśli masz dwa kontrolery domeny na tym samym hoście, nie jest to znacznie lepsze niż działanie z jednym kontrolerem domeny. Active Directory jest odporny nawet bez nadmiarowości
  • Jeśli masz wiele lokacji i mają one ze sobą jakiekolwiek połączenie sieciowe, preferowanym rozwiązaniem powinno być umieszczenie jednego kontrolera domeny w każdej lokacji. Potrzeba kontrolerów domeny w dowolnej lokacji zdalnej jest powiązana z liczbą użytkowników w tej lokacji i jakością połączenia międzylokacyjnego. Jeśli masz wielu użytkowników, potrzebujesz kontrolera domeny.
  • Jeśli jakość łącza między lokacjami jest niska, potrzebujesz kontrolera domeny. Upewnij się, że na kontrolerze domeny lub innym serwerze w zdalnej lokacji działa również system DNS i że wszystkie systemy w tej lokacji odwołują się do niego.
How Domain Controllers are Located in Windows - TechNet Articles - United  States (English) - TechNet Wiki
Kontroler domeny w każdej lokalizacji

4. Nie używaj migawek stanu systemu (snapchat)

W wersjach starszych niż Windows Server 2012 przywrócenie kontrolera domeny do punktu kontrolnego (migawki) może spowodować nieodwracalne uszkodzenie domeny. Spowodowane jest to tym, że inne kontrolery domeny sądziły, że wykonały już replikację z tym kontrolerem domeny. Przywrócenie stanu maszyna z przed awarii spowoduje, że te replikacje ulegną zatarciu. Następnie ponownie prześle zmiany obiektów przy użyciu numerów sekwencji aktualizacji, których już używał, powodując niespójności w katalogu. Czasami katalog może wykryć te problemy (tzw. wycofanie USN); czasami nie może. Problem jest poważny, a jego rozwiązanie bolesne, czasami niemożliwe. W dokumentacji widnieje sposób rozwiązania takiego problemu.

Nowoczesne oprogramowanie do tworzenia kopii zapasowych opiera się na punktach kontrolnych Hyper-V do wykonywania kopii zapasowych. Jednak mogłeś również zauważyć, że te punkty kontrolne nie pojawiają się w większości typowych narzędzi. Jest ku temu bardzo dobry powód: Microsoft nigdy nie zamierzał przywracać kopii zapasowych z punktów kontrolnych. Gdy maszyna wirtualna ma punkt kontrolny, cała aktywność trafia do nowo utworzonych plików punktów kontrolnych. Wszystko przed tym jest w stanie tylko do odczytu. To idealny warunek do korzystania z oprogramowania do tworzenia kopii zapasowych. Po zakończeniu tworzenia kopii zapasowej oprogramowanie powinno powiadomić Hyper-V, aby mogło scalić punkt kontrolny. Tego typu punkty kontrolne nie zagrażają kontrolerom domeny, ponieważ nigdy nie są przywracane.

5. Wyłącz synchronizację czasu Hyper-V dla zwirtualizowanych kontrolerów domeny

Domyślnie Hyper-V odpowiada za aktualizowanie zegarów u swoich gościach. W przeszłości zalecane było współdzielenie odpowiedzialności za zegar w zwirtualizowanych kontrolerach domeny. Dzieje się tak, ponieważ wznowienie maszyny wirtualnej z zapisanego stanu lub przywrócenie punktu kontrolnego powoduje, że jej zegar będzie nieprawidłowy, w związku z tym, nie umożliwi aktualizacji za pośrednictwem kanałów innych niż usługa integracji czasu Hyper-V. W przypadku aplikacji takich jak usługi domenowe, może to doprowadzić do niestabilności w działaniu usługi. Niestety ustawienie współdzielonej odpowiedzialności nie jest już możliwe, co powoduje, że całkowicie zastępuje ona wszelkie inne źródła ustawione dla usługi czasu systemu Windows. Oznacza to, że każdy gość z włączoną usługą synchronizacji czasu funkcji Hyper-V zawsze otrzyma swój czas od hosta. Jako, że kontrolery domeny uważają, że to one są najważniejsze w lokalnej hierarchii czasu, może to powodować problemy w sieci.

Dlatego tak istotne jest wyłączenie synchronizacji czasu pomiędzy hostem a maszyną wirtualną, która utrzymuje kontroler domeny.

Wyłączenie synchronizacji czasu

6. Nie umieszczaj kontrolerów domeny w stanie zapisanym

Zapisywanie kontrolera domeny nie jest tak niebezpieczne, jak użycie punktów kontrolnych, ale również nie jest dobrym wyborem. Gdy maszyna wirtualna zostanie wznowiona z zapisanego stanu lub zostanie przywrócona do punktu kontrolnego, jedyną rzeczą, która gwarantuje naprawienie jej zegara, jest usługa synchronizacji czasu funkcji Hyper-V. Ale, jak wiesz z poprzedniego punktu, nie możesz tego włączyć na zwirtualizowanych kontrolerach domeny. Jeśli jego zegar zostanie rozregulowany, może nigdy nie naprawić się automatycznie.

Jeszcze gorszą sytuacja jest długo zachowany kontroler domeny w stanie zapisania.

  • Zwirtualizowany kontroler domeny został zapisany.
  • Użytkownik zostaje usunięty.
  • Po jakimś czasie zwirtualizowany kontroler domeny zostanie wznowiony.


Taki przypadek powodujący problemy objawi się gdy w sieci znajduje się wiele kontrolerów domeny.

W opisanym scenariuszu wznowiony kontroler domeny ponownie posiada działający obiekt użytkownika . Dzieje się tak, ponieważ obiekt był aktywny na tym kontrolerze domeny w czasie jego zapisywania. Po wznowieniu miał aktywny rekord, podczas gdy żaden inny kontroler domeny w środowisku nawet nie pamiętał, że kiedykolwiek istniał. Będą postrzegać to jako nowy obiekt i powielać go tak, jakby nic się nigdy nie wydarzyło. Taka sytuacja może wpłynąć na bezpieczeństwo, ponieważ użytkownik, który nie powinien istnieć nagle ponownie stał się dostępny w sieci.

Jeśli masz wiele kontrolerów domeny i stwierdzisz, że jeden z nich był zapisany przez bardzo długi czas, możesz odrzucić jego zapisany stan. Active Directory może z łatwością poradzić sobie z utratą danych.

7. Ustaw akcję automatycznego zatrzymania wirtualnych kontrolerów domeny w trakcie zamknięcia hosta

Domyślnie wyłączenie hosta Hyper-V w wersji 2012 lub nowszej spowoduje zapisanie wszystkich działających gości. W przypadku zwirtualizowanych kontrolerów domeny chcemy uniknąć pozostawienia opcji Saved State (zapisanie stanu maszyny). Guest operating system shutdown (Zamknięcie systemu operacyjnego gościa) powinna zostać zaznaczona, zgodnie z poniższą konfiguracją.

Automatyczne zamknięcie maszyny wirtualnej

8. Automatyczne uruchamianie maszyny po starcie hosta

Usługi domenowe w usłudze Active Directory zazwyczaj zapewniają podstawową funkcjonalność większości pozostałych elementów środowiska Windows. Upewnij się, że jest dostępny bez ręcznej interwencji.

Automatyczne uruchamianie maszyny wirtualnej

9. Nie zapewniaj wysokiej dostępności wirtualnych maszyn kontrolera domeny

Ze względu na bardzo różne rodzaje technologii funkcje wysokiej dostępności usługi Active Directory znacznie przewyższają wszystko, co może zapewnić Hyper-V i klaster pracy awaryjnej. Ogólnie rzecz biorąc, klastrowanie maszyny wirtualnej zawierającej kontroler domeny nie przynosi żadnych korzyści. Jest od tego mały wyjątek: rozważ klastrowanie maszyn wirtualnych, które posiadają role FSMO, ale tylko wtedy, gdy masz co najmniej jeden kontroler domeny inny niż HA i masz wystarczającą aktywność domeny, aby to uzasadnić.

Maszyna wirtualna o wysokiej dostępności musi mieć dostępną wirtualizację bezpośrednio na każdym hoście, na którym będzie kiedykolwiek działać:

Wysoka wydajność w kontrolerach domeny

10. Umieść zwirtualizowane kontrolery domeny w lokalnej, najlepiej wewnętrznej pamięci masowej

Los maszyn wirtualnych bez HA jest już nierozerwalnie związany z losem hosta, na którym żyją, najlepiej jest umieścić je w pamięci wewnętrznej. Użyj dublowania (RAID 1) lub innej technologii, aby chronić je przed awariami pamięci masowej.

11. Nie wykonuj konwersji fizycznych na wirtualne na kontrolerach domeny

Active Directory ma jedną z najpłynniejszych ścieżek migracji, jakie kiedykolwiek widziałem dla dowolnej aplikacji. Jeśli chcesz zachować nazwę i adres IP fizycznego kontrolera domeny, użyj tymczasowego kontrolera domeny, aby dokonać przejścia na nową maszynę (w tym również wirtualną). Opisałem ten proces z jednej z lekcji. Proces ten nie jest prosty, ani bezpieczny, dlatego trzeba się do niego odpowiednio przygotować.

Prosta ścieżka:

  1. Zbuduj nową maszynę wirtualną, zainstaluj system Windows Server i upewnij się, że ma prawidłowy, aktywowany klucz.
  2. Zainstaluj AD DS na nowej maszynie wirtualnej jako nowy kontroler domeny w istniejącej domenie. Upewnij się, że łączy się z istniejącą domeną.
  3. W razie potrzeby ustaw nowy kontroler domeny jako wykaz globalny i/lub przenieś role FSMO. W razie potrzeby skonfiguruj DNS, DHCP i wszelkie inne usługi dodatkowe świadczone przez kontrolery domeny. Jeśli masz źródłowy serwer DHCP w wersji 2012 lub nowszej, możesz użyć przełączania awaryjnego DHCP, aby szybko i łatwo replikować zakresy DHCP, a następnie w razie potrzeby zerwać relację.
  4. Gdy będziesz gotowy, odinstaluj AD DS i zlikwiduj istniejący fizyczny kontroler domeny (w ramach najlepszej praktyki powinieneś wykonać krok 7 poniżej, ale jest to mniej krytyczne, gdy stara nazwa kontrolera domeny nie jest ponownie używana).

Skomplikowana ścieżka, jeśli chcesz zachować nazwę i IP istniejącego DC:

  1. Zbuduj nową maszynę wirtualną i zainstaluj system Windows Server. Jest to instalacja tymczasowa.
  2. Zainstaluj AD DS na nowej maszynie wirtualnej jako nowy kontroler domeny w istniejącej domenie. Upewnij się, że łączy się z istniejącą domeną.
  3. Ustaw nowy kontroler domeny w wykazie globalnym i przenieś role FSMO.
  4. Skonfiguruj DNS, DHCP i wszelkie inne usługi dodatkowe wykonywane przez oryginalny kontroler domeny. Jeśli na oryginalnym kontrolerze domeny są uruchomione usługi DHCP i jest to system Windows Server 2012 lub nowszy, można użyć trybu failover DHCP, aby szybko i łatwo replikować zakresy DHCP, a następnie zerwać relację.
  5. Usuń DNS, DHCP itp. z oryginalnego kontrolera domeny.
  6. Usuń AD DS z oryginalnego kontrolera domeny i zlikwiduj go.
  7. W Active Directory Sites and Services (Lokacjach i usługach Active Directory), Active Directory Users and Computers (Użytkownicy i komputery usługi Active Directory) oraz ADSIEdit wyśledź pozostałości oryginalnego kontrolera domeny i wyczyść je. Najważniejszym miejscem jest Active Directory Synchronization Service (ADSS).
  8. Wykonaj ponownie kroki 1-7, używając maszyny, która ma być docelowym kontrolerem domeny o tej samej nazwie i adresie IP co źródło.

12. Koniecznie dołącz maszynę hosta do domeny

Osoby, które nie mają kontrolerów domeny, mogą pozostawić swoje hosty Hyper-V w trybie grupy roboczej, gdy wszyscy jego goście znajdują się DMZ. Dobrze znam kontrargumenty, więc zajmę się nimi teraz:

Dołączenie hosta Hyper-V do domeny pomaga w pracy z maszynami, nie będzie problemów z uprawnieniami, dostępami etc.

13. Czy potrzebuję drugiego kontrolera domeny, czy wystarczy jeden?

Niektórzy Administratorzy twierdzą, że dobrze jest mieć kilka kontrolerów domeny na czarną godzinę. Do tej pory tylko w obecnej organizacji stoją dwa stare serwery domeny, po poprzednich organizacjach był zawsze jeden i nie było problemu (nie licząc sterownika sieciówki w jednym;).

Pojedynczy serwer ma również swoje uzasadnienie:

  • Oszczędzamy na licencjach Windows i kosztach sprzętu.
  • Wycofanie USN jest niemożliwe; jest to ważne w małym środowisku, ponieważ brakuje zasobów technicznych zdolnych do jego wykrycia oraz wiedzy fachowej umożliwiającej jego naprawę.
  • W przypadku wystąpienia awarii przywracanie usług domenowych w jednym środowisku DC jest niezwykle proste, o ile zostały przygotowane kopie zapasowe bazy AD oraz konfiguracji GPO.


W dzisiejszym świecie wszechobecnej wirtualizacji pojedyncze środowisko DC wiąże się z dość niskim ryzykiem. Mała firma może uruchomić Hyper-V na hoście z dwoma gośćmi; jeden prowadzi usługi domenowe, a drugi inne usługi firmy. Wymaga to tylko jednej licencji Windows Server Standard Edition i spełnia najlepsze praktyki oddzielania usług domeny od innych aplikacji serwerowych. To wszystko można następnie wykonać za pomocą Hyper-V.

Najważniejszą rzeczą jest tworzenie kopii zapasowych. Backup zapewnia redundancję danych przy bardzo niskich kosztach. Zapewnienie nadmiarowości w czasie wykonywania ponad dwukrotnie zwiększa koszty. Jeśli ten koszt jest zbyt wysoki, rozumiesz ryzyko i poświęcasz czas na opracowanie solidnych strategii systemu kopii zapasowej.

14. Jeśli mam jednego hosta Hyper-V, który obsługuje jedyny kontroler domeny, co się stanie, jeśli kontroler domeny się nie uruchomi?

Dołączenie do domeny domyślnie nie wpływa na poświadczenia lokalne. Żadna polityka domeny nie powinna wyłączać administratora lokalnego, zwłaszcza na serwerach o znaczeniu krytycznym. Wyłączenie konta administratora lokalnego nie poprawia znacząco bezpieczeństwa, ale naraża Cię na niepotrzebne ryzyko. Powinieneś już mieć politykę utrzymywania poświadczeń administratora lokalnego w bezpieczny sposób. Dopóki masz te dostępne, możesz się zalogować. Tak długo, jak masz dostępną kopię zapasową, możesz odbudować kontroler od zera w najgorszym przypadku.

Ponadto większość domen zachowuje domyślne ustawienie poświadczeń w pamięci podręcznej, które umożliwia logowanie się przy użyciu dowolnego konta domeny, które host ostatnio widział.

15. Czy powinienem porzucić fizyczne kontrolery domeny?

Jeśli masz działający sprzęt i nie musisz zwalniać miejsca fizycznego ani przenosić licencji (lub jeśli jest to OEM, a licencji nie można przenieść), zachowaj istniejący fizyczny kontroler domeny.

16. Czy powinienem używać wirtualnych kontrolerów domeny ze stałymi czy dynamicznie rozszerzającymi się wirtualnymi dyskami twardymi?

Jeśli nie sprawisz, że twoje pliki VHDX będą śmiesznie małe, twoje zwirtualizowane kontrolery domeny nigdy nie zajmą przydzielonego im miejsca. Kontrolery domeny są stosunkowo niskie w skali zużycia IOPS.

Serwer plików

W przypadku tej usługi, często równie krytycznej jak AD nie ma wątpliwości, że serwer musi być oddzielny. Idealnie gdyby taki serwer był zdublowany, dzięki czemu mając nadmiarowość pliki są bezpieczne. Warto rozważyć chmurę, która posiada blisko 100% bezpieczeństwo przechowywania danych.

Nie trzeba tutaj kupować pełnowymiarowego serwera, wystarczy NAS. Tego typu urządzenia obsługują dyski hot-swap, które można wymienić bez zatrzymywania dostępu do plików.

Serwer wydruku

Często przyszłość organizacji zależy od poprawności działania serwera wydruków. Jeżeli zamówienia produkcyjne są drukowane automatycznie, serwer wydruków musi działać bez przeszkód. Tutaj wirtualizacja może się sprawdzić, ponieważ zapewnia szybką możliwość odzyskania maszyny wirtualnej z zachowaniem całej jej konfiguracji. Serwer wydruków nie jest skomplikowany, dodajesz drukarki, sterowniki i działa.

Serwer aplikacji

Kolejnym istotnym elementem jest serwer aplikacji. Z reguły jest to maszyna z bazą danych oraz instancją aplikacji. Wirtualizacja sprawdzi się tutaj doskonale. Jednak może warto pójść krok dalej i zainteresować się konteneryzacją? Na jednym hoście można uruchomić wiele maszyn wirtualnych a w nich uruchomić dziesiątki lekkich instancji z aplikacją oraz bazą danych. Zarządzanie taką infrastrukturą przy pomocy chociażby Kubernetesa jest wygodne i zapewnia automatyczną reakcje na zatrzymanie części instancji aplikacji, poprzez ich odbudowanie. Oczywiście takie podejście wymaga wiedzy, aby odpowiednio przygotować takie rozwiązanie, jednak daje jeszcze lepsze wykorzystanie zasobów.

Klaster?

Połączenie przynajmniej dwóch maszyn pozwoli na zbudowanie klastra, który jest w stanie równoważyć obciążenie w przypadku gdy potrzebna jest lepsza wydajność. Do klastra można dodawać kolejne maszyny, aby środowisko było dostępne oraz wydajne w każdym momencie. Takie podejście pozwala na przeprowadzanie prac serwisowych, bez zatrzymywania środowiska IT, na którym działa krytyczna infrastruktura dla organizacji. Tego typu rozwiązania dostępne są zarówno w środowisku Windows jak i GNU/Linux.

Podsumowanie

Rozmieszczenie usług możliwie jak najbardziej odseparowanych od siebie, rozłożonych na różnych maszyna czy lokalizacjach znacząco poprawia bezpieczeństwo infrastruktury IT. Jeżeli już dojdzie do awarii będzie miała ona punktowy charakter, przestanie działać jedna z usług a nie wszystkie. Wpuszczenie poprawki do systemu, która może zatrzymać cały serwer na którym jest wszystko bo ktoś kiedyś zaoszczędził pieniądze może w ostatecznym rozrachunku doprowadzić do upadku organizacji. Nie, nie chodzi o to, żeby kupić dużo, ale bardzie o to, żeby to co mamy sensownie wykorzystać. Nie sztuką jest kupić serwer na 100k zł, ale sztuką jest wykorzystać jego możliwości do maksimum, tak aby usługi były wydajne, ich dostępność była na odpowiednim poziomie i żeby przerwy były niezauważalne dla użytkowników.


Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.

Link do formularza tutaj: https://beitadmin.pl/pomysly

Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).

2 komentarze do “Rozmieszczenie usług na serwerach w infrastrukturze IT”

  1. Dziękuję za ten wpis. Rozjaśnił mi trochę rozmieszczenie usług w IT. Czytałem go kilkakrotnie i analizowałem. Z tego co piszesz to praktycznie wszystkie usługi powinny być instalowane na osobnych serwerach jedynie kontroler domeny i AD powinny być zainstalowane na tym samym serwerze ponieważ są od siebie uzależnione dodatkowo można doinstalować do niego DNS i DHCP? Czy dobrze to zrozumiałem? 🙂

    Odpowiedz
    • Dokładnie tak. Do tej pory takie podejście mi się sprawdza. Oczywiście jak zwykle trzeba pilnować, żeby jakaś aktualizacja nie rozwaliła wszystkich maszyn, jak to ostatnio bywa z Windows:), czy dyski pracują poprawnie i to najlepiej w RAID. Kontroler nie zaszkodzi, żeby był zdublowany na innej maszynie nawet wirtualnej.

      Odpowiedz

Dodaj komentarz

beitadmin.pl - Droga Administratora IT