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:
- 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ł
- 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?
Odpowiedzi:
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
źródło
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”.
źródło
Czuję, że szukasz odpowiedzi w jednym wierszu, więc oto:
Przy każdym scenariuszu moglibyśmy mówić o osobliwościach i wyjątkach, ale myślę, że to uderza w sedno pytania.
źródło
Wyciągnijmy klastry z równania i skupmy się na jednej linii w twoim pytaniu, która wywołuje u mnie dreszcze.
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ą.
źródło
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.
źródło