W naszej topologii sieciowej istnieją dwa serwery 2012 R2 o nazwach WinServ2012A oraz WinServ2012B. Serwer WinServ2012A pracuje jako kontroler domeny - w scenariusz przyjęto domenę: firma.local Nie pokazuję krok po kroku jak zainstalować odpowiednie role tak by serwer mógł obsługiwać domenę gdyż zagadnienie było już omawiane i odpowiednie wpisy dotyczące tej tematyki znajdziesz pod adresami: Windows Server 2012. Poradnik administratora. Wstęp oraz Active Directory - Instalacja Na potrzeby tego wpisu przyjmujemy, że domena działa. Dodatkowo na każdym z serwerów został zainstalowany serwer DNS oraz DHCP.
Naszym pierwszym zadaniem będzie zainstalowanie na drugim z serwerów odpowiednich ról i funkcji i dodanie go do już istniejącej domeny firma.local tak by mógł on pełnić rolę dodatkowego kontrolera domeny.
Na komputerze WinServ2012B po instalacji usługi Active Directory Domain Services (rolę instalujemy tak samo jak w przypadku pierwszego kontrolera) przechodzimy do konfiguracji roli w tym celu po kliknięciu na ikonę Informacji wybieramy: Podnieś poziom tego serwera do poziomu kontrolera domeny.
Po wyborze opcji zostanie uruchomiony Kreator konfiguracji usług domenowych Active Directory Ponieważ mamy już utworzony las i działającą w tym lesie jedną domenę a dodawany serwer ma pełnić rolę kontrolera w tej domenie na pytanie kreatora o wybór operacji wdrażania zaznaczamy opcję: Dodaj kontroler domeny do istniejącej domeny (punkt 1).
Kolejnym krokiem jest wybór domeny. Operację możemy zrealizować poprzez wpisanie nazwy domeny bądź poprzez kliknięcie na przycisk: Wybierz Decydujemy się na drugie rozwiązanie (punkt 2) i tu natrafiamy na pierwszą trudność - Napotkano błąd podczas nawiązywania kontaktu z domeną firma.local. Serwer nie działa (punkt 3).
Powodem problemu jest brak definicji adresu IP serwera DNS (usługę serwera DNS pełni pierwszy kontroler domeny). Konfigurację sieciową należy poprawić i w polu: Preferowany serwer DNS wpisać adres IP komputera WinServ2012A czyli 10.0.0.10
Po zatwierdzeniu poprawionej konfiguracji karty sieciowej ponowne wybranie przycisku: Wybierz kończy się poprawnym nawiązaniem połączenia z domeną firma.local
Ostatnią czynnością jaka musimy wykonać na tym ekranie jest podanie danych uwierzytelniających konta, które ma prawo wykonania operacji podłączenia komputera do domeny - podajemy konto administratora domeny. Aby wprowadzić niezbędne informacje wybieramy przycisk: Zmień i w nowo otwartym oknie wpisujemy login i hasło administratora. Całość zatwierdzamy przyciskiem OK i klikamy Dalej.
Po wykonaniu poprawnie wszystkich czynności kolejnym ekranem są opcje kontrolera domeny. Aby drugi serwer mógł realizować poprawnie swoje zadania zaznaczamy opcję: Wykaz globalny. Usługa serwera DNS została zaznaczona automatycznie gdyż jej instalacja nastąpiła wraz z instalacją usługi Active Directory Domain Services.
Wykaz globalny to baza danych w której zapisane są dane wszystkich obiektów w lesie usług domenowych opartych o Active Directory.
Podczas przeprowadzenia instalacji roli AD DS wykaz globalny dla nowego lasu jest tworzony automatycznie na pierwszym kontrolerze domeny w lesie. Obsługę wykazu globalnego możemy dodawać/usuwać na innych kontrolerach domeny.
Serwer wykazu globalnego wykonuje następujące działania (źródło: https://technet.microsoft.com/pl-pl/library/cc730749(v=ws.11).aspx):
Znajdowanie obiektów - wykaz globalny umożliwia przeszukiwanie informacji zapisanych w katalogu we wszystkich domenach w lesie, niezależnie do tego, gdzie dane te są przechowywane. Wyszukiwanie odbywa się np. gdy użytkownik wyszukuje osoby lub drukarki.
Zapewnienie uwierzytelniania nazwy głównej użytkownika - serwer wykazu globalnego odpowiedzialny jest za rozpoznanie nazwy logującego się użytkownika i jego uwierzytelnienie w domenie. Uwierzytelniający kontroler domeny jeśli nie posiada informacji na temat konta użytkownika przeszukuje wykaz globalny celem jego odnalezienia. Na przykład jeśli konto użytkownika znajduje się w domenie marketing.firma.pl i użytkownik zaloguje się za pomocą nazwy UPN Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript. z komputera znajdującego się w domenie sprzedaż.firma.pl kontroler domeny w domenie sprzedaż.firma.pl nie będzie mógł odnaleźć konta użytkownika i będzie musiał skontaktować się z serwerem wykazu globalnego w celu ukończenia procesu logowania.
Sprawdzanie poprawności odwołania do obiektów w lesie - kontrolery domeny używają wykazu globalnego do sprawdzania poprawności odwołań do obiektów w innych domenach w lesie. Gdy kontroler domeny przechowuje obiekt katalogu z atrybutem zawierającym odwołanie do obiektu w innej domenie, kontroler domeny sprawdza poprawność odwołania, kontaktując się z serwerem wykazu globalnego.
Dostarczanie informacji o członkostwie w grupie uniwersalnej w środowisku wielodomenowym - kontroler domeny zawsze może odnaleźć informację o kontach, które znajdują się w grupie lokalnej domeny i w grupie globalnej dowolnego użytkownika w jego domenie, a informacja o przynależności do tych grup nie jest replikowane do wykazu globalnego. W lesie zawierającym jedną domenę, kontroler domeny może także określić członkostwo w grupie uniwersalnej. Jednak członkowie grup uniwersalnych mogą znajdować się w rożnych domenach. Dlatego też lista członków tej grupy jest replikowana do wykazu globalnego. Gdy użytkownik w lesie zawierającym wiele domen loguje się do domeny, w której są dozwolone grupy uniwersalne, kontroler domeny musi skontaktować się z serwerem wykazu globalnego, aby pobrać listę jej członków.
Kontroler domeny tylko do odczytu (ang. Read Only Domain Controler) jest specjalnym typem kontrolera domeny używanym w lokalizacjach, w których nie można zagwarantować fizycznego bezpieczeństwa serwera. Zadaniem RODC jest pełnienie roli kontrolera domeny ale w przeciwieństwie do kontrolera standardowego hostuje on kopię bazy danych Active Directory w wersji tylko do odczytu. Ograniczenie te powoduje, że kontrolery tego typu nie mogą bezpośrednio wdrażać zmian do bazy danych Active Directory, lecz zamiast tego przekazują aktualizacje do kontrolera. Uaktualnienie kontrolera odbywa się poprzez pobranie bazy danych Active Directory ze standardowych kontrolerów domeny. Podsumowując kontroler tego typu stosujemy w lokalizacjach wymagających szybkich i niezawodnych usług uwierzytelniania, w których nie można jednak zapewnić pełnego bezpieczeństwa fizycznego.
Nazwę lokacji pozostawiamy bez zmian.
Definiujemy hasło trybu przywracania usług katalogowych (DSRM).
Wybieramy Dalej.
Na ekranie opcji DNS wybieramy Dalej (błędem delegowania się nie przejmujemy).
W oknie Opcje dodatkowe określamy skąd ma odbywać się replikacja - wybieramy serwer WinServ2012A
Kontroler domeny można również zainstalować za pomocą kopii zapasowej nośnika przy użyciu opcji instalacji z nośnika (IFM). Nośnik używany w ramach opcji IFM jest tworzony za pomocą narzędzia Kopia zapasowa systemu Windows Server.
Na ekranie Ścieżki domyślne zaproponowane przez kreatora lokalizacje zapisu plików bazy danych usługi AD DS, plików dziennika oraz folderu Sysvol pozostawiamy bez zmian (oczywiście jeśli mamy taką potrzebę lokalizację plików możemy określić sami).
Przedostatnim ekranem jest przegląd zdefiniowanych opcji.
Jeśli wszystkie ustawienia spełniają nasze oczekiwania wybieramy przycisk Zainstaluj.
Uzbrajamy się w cierpliwość - trwa konfiguracja ustawień dodatkowego kontrolera domeny.
Wszystko przebiegło bez problemów. Dodatkowy kontroler został dodany do domeny firma.local Weryfikację dodania kontrolera możemy przeprowadzić w oknie Użytkownicy i komputery usługi Active Directory klikając na gałąź Domain Controllers. Jak widać po poniższym zrzucie w kontenerze znajdują się dwa komputery Winserv2012A oraz Winserv2012B.
Nasza domena posiada dwa kontrolery domeny wydaje się, że wszystko działa prawidłowo lecz żeby mieć 100% pewność wypadałoby by przeprowadzić małe testy i tak też zrobimy lecz zanim do nich przejdziemy zatrzymajmy się na chwilę i skonfigurujmy możliwość kontrolowania jednego serwera z poziomu drugiego.
Pierwszą metodę jaką wykorzystamy jest łączność pomiędzy serwerami z wykorzystaniem sesji PowerShell. Jak taką sesję zestawić w tym wpisie również nie pokażę gdyż pełen opis konfiguracji został zamieszczony tutaj: Jest we mnie MOC. Konfiguracja interfejsów sieciowych oraz dostępu zdalnego z wykorzystaniem PowerShella.
Postępując zgodnie ze wskazówkami umieszczonymi w artykule do którego link podałem powyżej na pewno uda Ci się taką sesję poprawnie skonfigurować.
Konfiguracja połączenia przebiegła bez problemów a jej efekt przedstawiam poniżej.
Z serwera Winserv2012A zostaje nawiązane połączenie z hostem Winserv2012B - na obu hostach zostało wydane polecenie: ipconfig jak można zauważyć efekt wydania polecenia przed i po ustanowieniu połączenia jest różny.
I tą samą czynność powtarzamy lecz tym razem połączenie zostaje ustanowione z serwera Winserv2012B
Łączność pomiędzy komputerami z wykorzystaniem powłoki PowerShell działa.
Sprawdźmy zatem czy uda Nam się kontrolować komputer Winserv2012A z poziomu przystawek MMC (konsola oczywiście zostanie uruchomiona na serwerze Winserv2012B). Ponieważ na obu serwerach została zainstalowana rola DHCP zatem wykorzystajmy konsolę MMC wraz z odpowiednią przystawką aby sprawdzić czy kontrola systemu z wykorzystaniem tej metody zadziała.
Poniżej została wywołana konsola MMC - w polu Uruchom (Windows+R) wpisujemy: mmc - do której zostały dodane przystawki DHCP (po jednej dla każdego serwera). Operację udało wykonać się bez żadnych komplikacji - możliwość prowadzenia konfiguracji przy pomocy MMC jest zapewniona.
Przywołany przeze mnie artykuł zawiera również opis konfiguracji sesji z wykorzystaniem Pulpitu zdalnego i taką konfigurację również przeprowadziłem. Poniżej przykład w którym host Winserv2012A nawiązuje połączenie z serwerem Winserv2012b (kreator połączenia sesji Remote Desktop wywołasz za pomocą skrótu: mstsc).
Uzyskaliśmy możliwość kontrolowania jednego serwera z poziomu drugiego możemy zatem przejść do testów zachowania się kontrolerów w tak zbudowanej sieci.
Rozpoczniemy od konfiguracji konta dla użytkownika Jan Kowalski, operację tą wykonamy na serwerze Winserv2012A. Konto dzięki użyciu narzędzia Użytkownicy i komputery Active Directory zostaje utworzone. Dodatkowo nowe powstałe konto zostaje umieszczone w jednostce organizacyjnej: marketing
Ponieważ oba kontrolery domeny przechowują kopię wykazu globalnego i pomiędzy serwerami zachodzi replikacja utworzenie konta na jednym z nich spowoduje przekazanie tej informacji do drugiego. Konto użytkownika zostało utworzone na Winserv2012A tak więc odzwierciedlenie przeprowadzonej operacji powinno pozostawić ślad na serwerze Winserv2012B. Sprawdzenie dostępnych kont i jednostek organizacyjnych na tym serwerze uwidacznia wprowadzone zmiany, które zostały wykonane na Winserv2012A. Oczywiście proces replikacji jest obustronny tak więc wprowadzone zmiany na Winserv2012B będzie można zweryfikować na Winserv2012A. Aby fakt ten potwierdzić zostaje utworzone konto: Tadeusz Nowak
I jak można było przewidzieć wprowadzone zmiany zostaną uwidocznione na hoście Winserv2012A.
Konta użytkowników zostały utworzone. Czas sprawdzić domenę w działaniu i wykonać próbę logowania. Lecz zanim tę operację wykonamy musimy mieć z czego się zalogować tak więc naszym kolejnym krokiem będzie dodanie komputera do domeny.
Nazwa dodawanego hosta to: XXX zaś jego adres IP wynosi: 172.16.0.10. Adres ten wraz z innymi adresami został przyznany przez serwer Winserv2012A gdyż obecnie to ten komputer pełni rolę serwera DHCP (na serwerze Winserv2012B rola DHCP została skonfigurowana lecz serwer nie został skonfigurowany). O czym należy pamiętać? - Nie zapominamy o konfiguracji przekazywania pakietów DHCP na routerze. Serwery i dodawany host leżą w innej przestrzeni adresowej i aby przypisanie adresów doszło do skutków musi być pomiędzy sieciami zapewniony routing oraz włączone przekazywanie pakietów DHCP w kierunku od klienta do serwera i z powrotem. Jak router skonfigurować by zapewniał Nam przekazanie danych protokołu DHCP opisałem w artykule: Co w sieci siedzi. Protokół DHCP (dotyczy routerów CISCO). Oczywiście sytuację uprościmy jeśli serwery i klienci będą należeć do wspólnej podsieci (niestety z różnych względów nie zawsze jest to możliwe).
Komputer XXX (system Windows 7)został przyłączony do domeny (opis całej operacji zawarty został w wpisie: Windows Server 2012. Poradnik administratora. Wstęp).
Komputer XXX stał się częścią domeny firma.local Fakt ten zweryfikujemy na dowolnym z kontrolerów domeny - po lewej serwer WinServ2012A zaś po prawej host WinServ2012B.
Jak można zauważyć poniżej proces logowania z wykorzystaniem konta domenowego (konto: jankow) zakończył się pełnym sukcesem.
Przechodzimy zatem do ostatniej fazy testów i sprawdźmy zachowanie się kontrolerów w przypadku awarii jednego z nich. W tym celu zostały utworzone dwa nowe konta: Beata Tryla (beatry) oraz Piotr Mazur (piomaz). Przy wykorzystaniu tych kont wykonamy proces logowania z hosta XXX przy wyłączonym serwerze WinServ2012A (serwer WinServ2012B włączony) a następnie w sytuacji odwrotnej. To co należy zaznaczyć - oba komputery zostały skonfigurowane jako serwery DHCP (tryb failover - opis konfiguracji w dalszej części wpisu).
Rozpoczynamy od wyłączenia serwera WinServ2012A, za obsługę klientów domeny odpowiada host WinServ2012B. Wykonujemy próbę logowania z wykorzystaniem konta: beatry Jak widać poniżej test ten kończy się sukcesem.
Sytuacja odwrotna - host WinServ2012A zostaje włączony (teraz on odpowiada za uwierzytelnienie użytkowników) zaś serwer WinServ2012B zostaje od sieci odcięty. Test ponownie wykonujemy na komputerze XXX przy użyciu konta: piomaz I jak można było przewidzieć test ten również kończy się powodzeniem.
Dzięki podłączeniu drugiego kontrolera domeny zapewniliśmy redundancję prowadzonych usług. W przypadku awarii jednego z serwerów jego obowiązki przejmuje drugi - zostaje zapewniona ciągłość usług.
Obydwa serwery są kontrolerami, które przechowują global catalog. Gdybyśmy z jakiś powodów chcieli wyłączyć na danym serwerze tą funkcję musimy do tego celu posłużyć się przystawką Lokacje i usługi Active Directory (ang. Active Directory Sites And Services).
Spróbujmy zatem przeprowadzić operację wyłączenia wykazu globalnego. Czynność wykonamy na serwerze WinServ2012B.
W tym celu otwieramy okno Lokacje i usługi Active Directory i rozwijamy następujące gałęzie: Sites/<nazwa_lokacji>/Servers/<nazwa_serwera>/ po czym PPM klikamy na NTDS Settings i z menu wybieramy Właściwości. W nowo otwartym oknie na zakładce Ogólne odhaczamy opcję Wykaz globalny.
Sprawdzenie wyłączenia wykazu globalnego możemy np. sprawdzić na drugim serwerze. Sprawdzenia dokonujemy po otwarciu przystawki Użytkownicy i komputery usługi Active Directory i po przejściu do gałęzi Domain Controllers. Jak widać poniżej na komputerze WinServ2012B funkcja wykazu globalnego została wyłączona (typ kontrolera jest ustalony na DC w przypadku korzystania z global catalog typ kontrolera jest ustalany na GC).
Włączenie/wyłączenie obsługi wykazu globalnego możemy również wykonać przy użyciu polecenia konsoli PowerShell. Aby wyłączyć global catalog na serwerze WinServ2012A należy wydać polecenie: Set-ADObject "CN=NTDS Settings,CN=Winserv2012a,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=firma,DC=local" -Replace @{options='0'}
Włączenie odbywa się poprzez zamienienie w poleceniu 0 na 1.
Przystawkę Lokacje i usługi Active Directory możemy również wykorzystać do wykonania operacji replikacji informacji zawartych w bazie Active Directory. Replikacja jest wykonywana pomiędzy kontrolerami domeny a jej uaktywnienie odbywa się poprzez kliknięcie PPM na obiekt połączenia i wybraniu z menu kontekstowego kierunku replikacji. Na rysunku poniżej pokazano możliwość wyzwolenia replikacji z serwera WinServ2012B w kierunku hosta WinServ2012A i na odwrót.
Partnerów replikacji poznamy po wyświetleniu zakładki Połączenia dostępnej po wybraniu Właściwości obiektu NTDS Settings.
Do zarządzania i monitorowania stanu replikacji prócz trybu GUI możemy użyć narzędzia wiersza poleceń: repadmin.
Podsumowanie replikacji domeny przejrzymy wydając polecenie: repadmin z opcją replsummary.
Wydanie polecenia pozwoli Nam ustalić, kiedy nastąpiła replikacja i czy zakończyła się ona sukcesem. Komenda poinformuje Nas również o interwale pomiędzy kolejnymi replikacjami.
Narzędzie repadmin z ustawioną flagą showrepl ukaże informacje dotyczące ruchu replikacji. Uzyskane dane pozwolą sprawdzić Nam listę obiektów, które replikacji podlegały wraz z czasem wystąpienia zdarzenia.
Z narzędziem repadmin zostały skojarzone następujące funkcje:
/queue - lista obiektów jaka musi zostać przetworzona w celu osiągnięcia zbieżności z partnerami replikacji,
/prp - informacja o zreplikowanych hasłach użytkowników,
/replicate - wymuszenie replikacji określonej partycji Active Directory,
/replsingleobj - wymuszenie replikacji dla pojedynczego obiektu.
Następujące polecenie synchronizuje określony DC ze wszystkimi partnerami replikacji: repadmin /syncall /adep
Celem wprowadzenia dodatkowego kontrolera jest zapewnienie redundancji tak by została zachowana ciągłość dostarczanych usług - w przypadku awarii jednego drugi przejmuje jego zadania. Mając do dyspozycji dwa kontrolery domeny możemy pokusić się o zdublowanie funkcji serwera DHCP.
DHCP jest krytyczną usługą sieciową gdyż niedziałający serwer nie przyzna adresów IP klientom a klienci ci bez konfiguracji sieciowej nie uzyskają dostępu do sieci. W wcześniejszych wersjach systemu Windows Server dublowanie roli serwera DHCP było utrudnione i kłopotliwe w realizacji. Dostrzeżono tę lukę i wraz z wydaniem wersji Windows Server 2012 wprowadzono obsługę awaryjnej pracy serwera DHCP. Usługę tą można skonfigurować dwojako tak by funkcja serwera DHCP mogła być prowadzona nieprzerwanie.
W przypadku korzystania z wersji systemu Windows Server nie obsługujących trybu failover należy skonfigurować usługę DHCP z podziałem zakresu. Usługa DHCP z podziałem zakresu do działania używa dwóch niezależnych serwerów DHCP, które są współodpowiedzialne za zakres. Zazwyczaj 70% adresów w zasięgu jest przydzielonych do serwera podstawowego, a pozostałe 30% — do serwera zapasowego. Jeśli klient nie może uzyskać dostępu do serwera podstawowego, może uzyskać konfigurację protokołu IP z serwera pomocniczego.
Aby móc skonfigurować klaster DHCP i tym samym zapewnić ciągłość pracy serwera niezbędne jest posiadanie dwóch działających serwerów DHCP (działamy w oparciu o AD tak więc oba serwery w domenie muszą zostać autoryzowane) oraz zdefiniowanego zakresu (jeden wystarczy) możliwych do przyznania adresów IP.
Praca serwera DHCP może opierać się na:
- Load Sharing (tryb współdzielenia obciążenia): pracy dwóch lub więcej serwerów DHCP w trybie równoważenia obciążenia (jest to domyślny tryb działania). Dwa serwery jednocześnie udostępniają adresy IP i opcje klientom w danej podsieci. Żądania klientów podlegają równoważeniu obciążenia i są współdzielone między dwoma serwerami. Tryb współdzielenia obciążenia najlepiej nadaje się na potrzeby wdrożeń, w których oba serwery w relacji trybu failover znajdują się w tej samej lokacji fizycznej. Oba serwery odpowiadają na żądania klientów DHCP na podstawie współczynnika dystrybucji obciążenia skonfigurowanego przez administratora
- Hot Standby (tryb rezerwy dynamicznej): dzierżawie adresów IP z skonfigurowanego zakresu, jeśli główny serwer DHCP znajdzie się w trybie offline - drugi serwer DHCP uaktywnia się w momencie w którym wykryje awarie serwera głównego. Podczas normalnej pracy podstawowy serwer DHCP jest odpowiedzialny za przypisanie konfiguracji sieci zaś pomocniczy serwer DHCP uaktywnia się w momencie braku kontaktu z serwerem podstawowym. Serwer DHCP dla danej podsieci może jednocześnie pełnić rolę serwera podstawowego zaś dla innego zakresu być serwerem pomocniczym. Konfiguracja tego trybu pracy serwerów DHCP polega na zdefiniowaniu procentu puli adresów IP (domyślnie 5%), która jest przekazywana serwerowi pomocniczemu. Dodatkowo określany jest interwał czasu tzw. MCTL po minięciu, którego serwer ten przejmuje kontrolę całego zakresu IP.
Konfigurację serwera przeprowadzimy na hoście WinServ2012A zaś trybem pracy serwera DHCP będzie Load Sharing (omówimy konfigurację obu trybów). Wymagania odnośnie konfigurowanej funkcji dostępne są pod tym linkiem: https://technet.microsoft.com/en-us/library/dn338982(v=ws.11).aspx
Rozpoczynamy od uruchomienia przystawki MMC odpowiedzialnej za konfigurację serwera DHCP. Po jej uruchomieniu wybieramy dany serwer i po kliknięciu na nim PPM odszukujemy opcję: Konfiguruj tryb failover…
W pierwszym oknie kreatora Konfigurowanie trybu failover (ang. DHCP Failover) wybieramy zakres (bądź zakresy), które będą obsługiwane przez klaster serwerów DHCP. Następnie wybieramy Dalej.
W Naszym scenariuszu serwery DHCP są odpowiedzialne za przydzielanie adresów IP sieci 172.16.0.0/24 więc taki zakres adresów zostaje wybrany.
W oknie Określanie serwera partnerskiego do użycia dla trybu failover (ang. Specify the partner server to use for failover), w polu Serwer partnera (ang. Partner Server) wpisujemy nazwę drugiego serwera DHCP (lub jego adres IP), bądź korzystamy z przycisku Dodaj serwer. Następnie wybieramy Dalej.
Został wybrany host WinServ2012B.
Kolejne okno i zawarte w Nim opcje zależne będą od wybranego trybu pracy serwera DHCP. W przypadku wybrania trybu Równoważenia obciążenia dostępne ustawienia oraz ich przeznaczenie prezentuje się następująco:
W oknie Tworzenie nowej relacji trybu failover (ang. Create a new failover relationship), w polu Nazwa relacji (ang. Relationship Name) widoczna jest nazwa tworzonego powiązania, domyślnie nazwa ta jest tworzona poprzez połączenie nazw FQDN serwerów (powiązanie można nazwać dowolnie). Pole Maksymalny czas przedłużenia klienta (ang. Maximum Client Lead Time) pozwala określić Nam czas po którym serwer zapasowy przejmie w całości kontrolę nad danym zakresem/zakresami (domyślna wartość wynosi: 1 godzina). Pole Tryb (ang. Mode) pozwala na wybór trybu pracy serwera.
Pole Rola serwera partnerskiego (ang. Role of Partner Server) pozwala określić, który z serwerów ma być aktywny a który pasywny. Domyślna opcja Wstrzymane (ang. Standby) spowoduje skonfigurowanie serwera WinServ2012B do pracy w trybie pasywnym. Pole Adresy zastrzeżone dla serwera rezerwowego (ang. Addresses reserved for standby server) określa procentową rezerwację adresów IP dla serwera pasywnego na czas określony w polu Maksymalny czas przedłużenia klienta (wartość domyślna to 5%). Pole Interwał przełączania stanu (ang. State Switchover Interval) określa czas po którym partner zostanie uznany za niedziałający. Po zaznaczeniu pola Włącz uwierzytelnienie komunikatów (ang. Enable Message Authentication), serwery DHCP będą autoryzować swoją komunikację wspólnym hasłem określonym w polu Wspólny klucz tajny (ang. Shared Secret). Całość ustawień zatwierdzamy przyciskiem Dalej.
W przypadku wybrania trybu Rezerwa dynamiczna:
Opcje: nazwa relacji, maksymalny czas przedłużenia klienta, interwał przełączania stanu oraz włącz uwierzytelnienie komunikatów występują również i ich przeznaczenie jest takie same jak w przypadku wybrania trybu równoważenie obciążenia.
Nowymi opcjami są te zgrupowane w sekcji Wartość procentowa równoważenia obciążenia. W polach Serwer lokalny (ang. Local Server) oraz Serwer partnera (ang. Partner Server) definiujemy procentowy udział związany z obsługą dostępnych adresów IP. Domyślne ustawienie 50% na 50% oznacza równe obciążenie maszyn.
Na potrzeby ćwiczenia został wybrany tryb równoważenia obciążenia z ustawieniami domyślnymi.
Po wybraniu Dalej w kolejnym oknie widoczne jest podsumowanie naszej konfiguracji. Celem zatwierdzenia ustawień wybieramy Zakończ.
Kliknięcie przycisku Zakończ kończy pracę kreatora, następuje proces konfigurowania trybu failover. Wszystkie ustawienia zostały wprowadzone z powodzeniem.
Stan mechanizmu DHCP failover skontrolujemy klikając PPM na gałąź IPv4 (dostępne po rozwinięciu wszystkich opcji serwera DHCP) a następnie Właściwości. Wszystkie informacje oraz opcje zostały zgrupowane na zakładce Tryb failover. Zmianę ustawień trybu pracy serwerów DHCP dokonamy po wybraniu przycisku Edytuj. Poniżej przedstawiłem zrzuty ekranów opcji dostępnych na serwerze WinServ2012A.
I te same opcje na serwerze WinServ2012B. Po analizie zrzutów można dojść do wniosku, że cała konfiguracja została przeprowadzona prawidłowo.
Ponieważ od tej pory serwery pracują w trybie kooperacji muszą być one w stanie przekazywać między sobą informacje. Jednym z przekazywanych ustawień są dane dotyczące zastrzeżeń adresów IP (powiązanie adresu MAC z adresem IP - tak by host o danym adresie fizycznym zawsze otrzymał ten sam adres IP). Sprawdźmy zatem czy definicja takiego zastrzeżenia na jednym z serwerów zostanie przekazana drugiemu.
Na hoście WinServ2012B zostaje utworzone zastrzeżenie łączące adres MAC komputera z adresem IP. Od tej pory hostowi XXX zostanie zawsze przypisany adres IP 172.16.0.10.
Aby wymusić replikację należy wybrać opcję: Replikuj zakresy trybu failover (opcja dostępna po kliknięciu PPM na nazwę serwera DHCP). Wybranie opcji musimy zatwierdzić kliknięciem na przycisk OK.
Zatwierdzenie akcji spowoduje wymuszenie replikacji danych pomiędzy serwerami DHCP.
Sprawdźmy zatem czy utworzone zastrzeżenie na serwerze WinServ2012B będzie dostępne na WinServ2012A. Jak widać poniżej informacja o zastrzeżeniu została przekazana poprawnie na serwer partnerski.
Poniżej jeszcze jeden przykład, który obrazuje, że pomimo utraty kontaktu z serwerem partnerskim (został wyłączony host WinServ2012B) pula adresów IP w zdefiniowanym zakresie jest nadal dostępna dla zgłaszających się klientów.
Opisany mechanizm failover serwera DHCP pozwala administratorom na taką konfigurację serwerów DHCP, aby udostępniały one konfigurację adresów IP na potrzeby podłączających się klientów. Funkcja failover gwarantuje ciągłość usługi DHCP. Dzięki replikacji informacji o dzierżawach adresów IP pomiędzy serwerami DHCP mamy pewność działania usługi w przypadku awarii jednego z serwerów DHCP i jego niedostępności - obsługę klientów przejmie serwer partnerski.
Możesz zapytać Czytelniku - Czy to koniec możliwości kooperacji dwóch serwerów ze sobą? Otóż nie. Większa liczba serwerów otwiera przed Nami nowe możliwości tak więc świadomie ominąłem tematy związane z DNS czy rozproszonym systemem plików DFS by do nich powrócić w odrębnych wpisach.
BIBLIOGRAFIA:
Krok po kroku: konfigurowanie protokołu DHCP na potrzeby trybu failover
Wysoka dostępność uslug DHCP - DHCP Failover | TechNet (Polska)
Rozwiązywanie problemów z replikacją usług domenowych Active Directory
Komentarze
Dobry opis!
Pytanie -czy taką konfigurację da się zrobić dla domeny AD rozłożonej na dwie lokalizacje (2 różne podsieci) połączone VPNem ?
Chodzi o zabezpieczenie sytuacji kiedy pada serwer A w lokalizacji A domenę mógł "przejąć" serwer B w lokalizacji B.
Co z konfiguracją DHCP?
Może "lepiej" zrobić ją na UTMach w obulokalizacjac h ?
Pozdr!
Trochę nie za bardzo wiem co masz dokładnie na myśli??? Proszę napisz bardziej szczegółowo.
Mam również pytanie. Czy w środowisku, w których DHCP jest realizowane na routerze należy również replikować DNS?