Czy nadal powinienem mieć fizyczny kontroler domeny, nawet po wersji Server 2012?

30

W czasach wcześniejszych niż Windows Server 2012 zalecano, aby przynajmniej jeden fizyczny kontroler domeny znajdował się obok zwirtualizowanych kontrolerów domeny.

Jednym z uzasadnień tego było to, że jeśli hosty Hyper-V były skupione w klastrach, wówczas wymagały one dostępu do kontrolera domeny podczas uruchamiania. Ma to dla mnie całkowity sens.

Jednak często słyszę, jak ludzie mówią, że nadal jest ważne, aby mieć fizyczny kontroler domeny, nawet jeśli nie masz skonfigurowanego klastra (na przykład w prostej konfiguracji z jednym serwerem Hyper-V z kilkoma maszynami wirtualnymi, jednym w tym DC). Uzasadnieniem tego wydawało się (i nigdy nie byłem do końca pewny), że nadal będziesz miał problem w tym sensie, że kiedy host Hyper-V po raz pierwszy uruchamia się, w sieci nie ma prądu stałego. Pamięci podręczne oznaczają, że nadal możesz się zalogować, ale co z tymi wszystkimi bitami, które zdarzają się podczas uruchamiania, co oznacza, że ​​posiadanie DC w pobliżu jest korzystne? Czy to rzeczywiście problem? Czy faktycznie są jakieś operacje, które mogą być uruchamiane tylkopodczas uruchamiania spowoduje to problem? Na przykład jakieś zasady grupy? W zasadzie pytam, czy fizyczny argument DC naprawdę trzyma wodę tylko wtedy, gdy występuje klastrowanie, czy też (przed 2012 rokiem) istniał dla niego istotny techniczny argument bez klastrowania? Ten artykuł z Altaro (patrz sekcja „Mit z kurczakiem i jajkiem”) sugeruje, że nie ma takiej potrzeby, ale nadal nie jestem pewien.

Teraz do drugiej (i głównej) części mojego pytania:

Windows Server 2012 wprowadził kilka funkcji mających na celu rozwiązanie problemów związanych z wirtualizacją kontrolerów domeny, w tym:

  1. Identyfikator generowania maszyny wirtualnej - rozwiązano problem z wycofaniem USN, który oznaczał, że migawka (a ściślej przywracanie do migawki) nie była obsługiwana / naprawdę zły pomysł
  2. Cluster Bootstrapping - Rozwiązano problem „kurczaka i jajka” otaczający Klaster pracy awaryjnej, o którym wspomniałem powyżej. Klaster pracy awaryjnej nie wymaga już obecności kontrolera domeny podczas uruchamiania.

Moje drugie pytanie jest podobne do pierwszego, ale tym razem dla lat 2012+. Zakładając, że zarówno vDC, jak i host są w wersji 2012+, a ty bierzesz klastrowanie z równania, czy są jakieś inne problemy, takie jak wspomniane powyżej, które oznaczają, że nadal powinienem rozważyć fizyczny DC? Czy powinienem nadal rozważać posiadanie fizycznego kontrolera domeny obok mojego pojedynczego, nieklastrowego hosta Hyper-V 2012 / 2012R2, który ma na sobie jeden wirtualny kontroler domeny? Słyszę, jak niektórzy sugerują umieszczenie AD na hoście Hyper-V, ale nie podoba mi się ten pomysł z różnych powodów (pamięć podręczna WB jest wyłączona na początku).

Na marginesie, moje pytanie domyślnie zakłada, że ​​sensowne jest połączenie hosta Hyper-V z domeną w celu poprawy zarządzania. Czy to twierdzenie może zostać poddane kontroli?

AKTUALIZACJA:

Po przeczytaniu niektórych odpowiedzi przyszło mi do głowy, że mogę nieco inaczej sformułować rzeczy, aby dotrzeć do sedna tego, o co pytam:

Nawet po wprowadzeniu ulepszeń w 2012 roku i późniejszych, faktem pozostaje, że bez fizycznych kontrolerów domeny lub wirtualnych kontrolerów domeny na innym hoście, host nadal uruchamia się, gdy nie ma dostępnego kontrolera domeny. Czy to rzeczywiście problem? W pewnym sensie wydaje mi się, że to samo (lub bardzo podobne) pytanie, jeśli całkowicie usuniesz wirtualizację ze zdjęcia. Czy to problem, jeśli regularnie uruchamiasz serwery członkowskie przed dowolnymi kontrolerami domeny?

dbr
źródło
4
Osobiście nigdy nie instalowałbym AD na twoim hoście Hyper-V. Na razie wyjmij wszystko związane z gromadą. Tracisz swój jedyny wirtualny DC - tracisz jedyne źródło DNS.
PnP

Odpowiedzi:

11

Ja też nie chciałbym, aby Hyper-V hostował DC.

Jeśli chodzi o to, czy powinieneś mieć fizyczny kontroler domeny, moim zdaniem jest to, że wraz ze zmianami, które Microsoft wdrożył w odniesieniu do zwirtualizowanych kontrolerów domeny w ogóle, a konkretnie do ładowania klastra bez DC, osobiście nie widzę potrzeby ani nie zalecam mając fizyczny prąd stały. Utrzymanie fizycznego kontrolera domeny wydaje się sprzeczne z intuicją, polegającą na przeniesieniu infrastruktury na platformę wirtualizacji. Zwirtualizować całą moją infrastrukturę, ale wszystko zależy od jednego fizycznego DC, który jest dostępny? Jaki jest w tym sens?

Istnieją sposoby na ograniczenie „ujawnienia” podczas wirtualizacji kontrolerów domeny. Jednym ze sposobów byłoby rozmieszczenie wielu kontrolerów domeny na różnych hostach w klastrze i użycie funkcji anty-powinowactwa, aby oddzielić je w przypadku awarii hosta (w zależności od liczby hostów w klastrze).

Chociaż odpowiedź Grega zawiera link do niektórych zaleceń MS, ten artykuł ma jednak dwa lata i dotyczy Windows Server 2008 i 2008 R2. Nie uważam tego artykułu za aktualną najlepszą praktykę w stosunku do Windows Server 2012 i 2012 R2. Nie mogę znaleźć oficjalnego dokumentu MS, ale ten facet jest uważany za wiodący autorytet w Hyper-V - http://www.aidanfinn.com/?p=13171

joeqwerty
źródło
Dzięki Joe. Czytałem artykuł Aidana jakiś czas temu i częściowo poinformował o moim pytaniu. Uderza mnie to, że zgodnie z logiką, tak naprawdę nie było przypadku fizycznego DC przed 2012 r., Chyba że działało środowisko klastrowe (inne niż być może przygotowanie klastra do konfiguracji). Właśnie dlatego dodałem drugą część o ludziach, którzy wciąż uzasadniają potrzebę pDC nawet bez grupowania, co wydaje się nie
ulegać
czy zgodziłbyś się z moim powyższym komentarzem, że jeśli wyjmiesz kwestię klastrowania, sytuacja tak naprawdę się nie zmieniła między 2008 a 2012 rokiem?
dbr
@dbr Dodałbym tylko do odpowiedzi Joe, że dla hyper-v (nie xen ani esx) testowałbym wcześniej hyper-v mmc. Jak mi się przydarzyło, martwy host z DC i hyperv mmc potrzebował żywej AD do otwarcia. Utknąłem, nawet jeśli jestem zalogowany jako administrator domeny z buforowaną referencją. Można to naprawić za pomocą najnowszej aktualizacji, ale to ważny fakt. (w przeciwieństwie do esxa, który może korzystać z wbudowanego użytkownika, ponieważ nadal można otwierać vsphere lub vcenter)
yagmoth555 - GoFundMe Monica
Po prostu chcę dodać inne sposoby poprawy odporności: mieć więcej niż jeden klaster hosta wirtualizacji (w tej samej lokalizacji lub w innych lokalizacjach) i / lub zbudować VPN na platformie Azure (lub AWS - Azure ma kilka zalet dla sklepów MS) i umieścić DC lub dwa tam.
Todd Wilcox,
18

Jednym z uzasadnień dla zachowania jednego fizycznego kontrolera domeny na domenę jest to, że jeśli wystąpi poważny incydent, który wpływa na hosta lub niszczy pamięć ramową dla wirtualizowanych kontrolerów domeny, będziesz mieć co najmniej jeden fizyczny kontroler domeny z pamięcią lokalną, aby przeprowadzić odzyskiwanie i zachować ciągłość. Microsoft kontynuuje tę kontrolę i wydaje to zalecenie podczas RAP Active Directory (ocena ryzyka i planowanie).

https://technet.microsoft.com/en-us/library/virtual_active_directory_domain_container_controller_virtualization_hyperv%28v=ws.10%29.aspx

„Utrzymuj fizyczne kontrolery domeny w każdej domenie. Zmniejsza to ryzyko awarii platformy wirtualizacji, która wpływa na wszystkie systemy hostów korzystające z tej platformy”.

Greg Askew
źródło
2
Nie jestem jednak pewien, czy to ma sens - patrz, na przykład, wiem, że firma jest w 100% wirtualna z DC i regularnie tworzy kopie zapasowe i ma 3 DC na 2 kontynentach (2 w Europie, 1 w USA) ... ciężko wyobrażać sobie tutaj wszystko, co wieje w sposób uniemożliwiający odzyskanie rzeczy.
TomTom,
Wydaje mi się, że próbują zrobić to, jeśli istnieje jakiś problem, który wpływa na Hyper-V jako całość, to byłbyś (tymczasowo) wkręcony, dopóki nie możesz przywrócić kontrolera domeny, co oznacza, że ​​posiadanie pDC oznaczałoby mniej zakłóceń. Nie jestem pewien, czy się zgodzę, ponieważ i tak byłbyś dość spieprzony, gdyby wystąpił problem z przestojem w całej Hyper-V!
dbr
1
Ładne i eleganckie, ale znów zupełnie nieistotne, chyba że masz wtedy znaczną część swojej infrastruktury z Hyper-V. DC działa, ale udziały plików, sharepoint, wymiana, drukowanie i wszystkie inne rzeczy są wyłączone - oznacza to, że raczej nie dbam o to, że DC znowu się uruchomi;) Przeważnie spływa, aby „mieć wiele kontrolerów domeny i tworzyć kopie zapasowe” i tak jest w przypadku obie strony (Hyper-V i fizyczne).
TomTom,
@TomTom Właśnie temu wymykałem się z moim komentarzem „i tak byś był całkiem spieprzony” :) Zakładałem, że wszystko inne i tak zostanie zwirtualizowane. Całkowicie się zgadzam, że sprowadza się to do „posiadania wielu DC i tworzenia kopii zapasowych”
dbr
@TomTom Firma, dla której pracuję, jest całkowicie wirtualna również dla infrastruktury AD. I to już od W2K3. Ale nie używamy HyperV: ESX do końca. 2 oddzielne zestawy infrastruktury klastrowej ESX na każdym kontynencie. Każda domena ma (co najmniej) 3 kontrolery domeny: 1 kontroler domeny na innym kontynencie i 1 kontroler domeny w każdym z 2 środowisk ESX na kontynencie „macierzystym”.
Tonny
10

Czuję, że szukasz odpowiedzi w jednym wierszu, więc oto:

Powinieneś mieć fizyczny kontroler domeny, jeśli nie ufasz zdolności środowiska wirtualnego do wytrzymania awarii.

Przy każdym scenariuszu moglibyśmy mówić o osobliwościach i wyjątkach, ale myślę, że to uderza w sedno pytania.

blaughw
źródło
3

Wyciągnijmy klastry z równania i skupmy się na jednej linii w twoim pytaniu, która wywołuje u mnie dreszcze.

Czy powinienem nadal rozważać posiadanie fizycznego kontrolera domeny obok mojego pojedynczego, nieklastrowego hosta Hyper-V 2012 / 2012R2 z pojedynczym wirtualizowanym kontrolerem domeny?

Dlaczego, dlaczego, dlaczego chcesz pojedynczego DC? W każdym środowisku staramy się unikać pojedynczych punktów awarii dla danej infrastruktury. DC to Twój chleb powszedni - zapewniają DNS, kręgosłup Active Directory. Poważnie, przebuduj komputer stacjonarny z systemem Windows 7 na 2008R2 i promuj go. Jest zawsze mocne argumenty dla fizycznego DC.

Hyper-V z AD DS? Nie, po prostu nie. Po pierwsze, Microsoft nie obsługuje tego. Po drugie, jak wspomniałeś, obsługa kopii zapasowych stanie się trudna w zależności od konfiguracji dysku. Nie wspominając o tym, że zaletą wirtualizacji jest możliwość wycofania fizycznych hostów tak szybko, jak możemy je zbudować (i doceniam, że dcpromo to nie jest wielka sprawa (w zależności od wielkości twojego środowiska)) i hosting AD DS po prostu komplikuje sprawy Wprowadzasz także kolejną złożoność czasu systemu Windows.

Osobiście zostawiam samodzielne hosty Hyper-V poza domeną, ale w rzeczywistości nie mam prawdziwych argumentów za żadną konfiguracją.

PnP
źródło
3
Większość odpowiedzi jest niepotrzebnie krytyczna, ponieważ zawiera punkty, które są całkowicie ważne, ale nie mają nic wspólnego z pytaniem. Oczywiście wiele DC jest prawie zawsze koniecznością - cytowana część służy do zilustrowania pytania / pytania. Kombinacja HV + AD znowu jest naprawdę tylko dodatkowym akcentem i myślę, że byłem całkiem pewien, że nie jestem miłośnikiem tej kombinacji.
dbr
2
Jeśli „zawsze jest silny argument za fizycznym DC”. [vs. na przykład drugie vDC] - czy możesz wyjaśnić tę sprawę? To naprawdę moje pytanie.
dbr
1

Aby odpowiedzieć na ostatnie pytanie, czy rzeczywiście jest to kiedykolwiek problem: zauważyłem, że moje hosty Hyper-V z włączoną obsługą RDP, ale wymagające NLA, nie zezwalają na RDP, dopóki nie zrestartuję usługi rozpoznawania lokalizacji sieci, jeśli nie ma DC się uruchamia po uruchomieniu. Miałem sporadyczne problemy ze zdalnym łączeniem się z VMMS również w tych punktach, ale tylko wtedy, gdy coś innego również zostało zepsute. Kiedy nie możesz RDP lub zdalnie połączyć się z menedżerem Hyper-V, naprawdę trudno jest ustalić, co jest zepsute i naprawić. Utrzymywanie fizycznego prądu stałego zapobiegło temu, aby mi się to przytrafiło w dowolnym momencie.

RobbieCrash
źródło