Thursday, April 23rd, 2009...11:38 pm

Czas goni nas … a może to my gonimy czas

Jump to Comments

Wirtualizacja to rewelacja” pisałem ostatnio (no powiedzmy że nie dosłownie) nawet nie myśląć, że do tematu wirtualizacji w kontekście usługi katalogowej tak szybko powróce. A pretekstem do powrotu do tematu są przypadki Wojtka z jego infrastrukturą usługi katalogowej. W całości zwirtualizowanej dodajmy – ach cóż to za wspaniała rzecz ta wirtualizacja, nieprawdaż. Problem pojawia się tylko wtedy kiedy to wszystko weźmie i się… powiedzmy popsuje. W tym konkretnym wypadku zegarek na DC nagle wskaże 1970-01-01 (cóż za okrągła data 😉 ).

Tematem tej lekcji będzie więc CZAS.

 

(cc) badboy69

Problemy z czasem w środowiskach wirtualnych są dobrze znane i opisane. I nie dotyczą w żadnym wypadku tylko jednego dostawcy tej technologii. Taki już urok tej technologii ….

 

Czas jak wiemy (a przynajmniej zakładam że wiemy) w środowisku usługi katalogowej pełni dosyć istotną rolę. Tą, którą wszyscy kojarzą to oczywiście uwierzytelnienie Kerberos, który to mechanizm na różnice w czasie jest jak najbarziej wrażliwy.

Mamy więc nasze środowisk wirtualne, wszystkie kontrolery domeny ładnie zwirtualizwane i nagle bumm … niespodzianka … czas nam wariuje. Efekty mogą być różne, w zależności od tego jaka różnica czasu i w którym kierunku nastąpiła. W przypadku infrastruktury Wojtka czas się wyzerował (tak wie, duże uproszczenie).

A co gdyby czas przeskoczył do przodu … powiedzmy o “czas życia nagrobków
+1 dzień? Pomijając już same problemy z mechanizmami uwierzytelnienia mielibyśmy kilka ciekawych efektów:

  • nagrobki obiektów zostałyby usunięte jako wynik działania standardowego procesu w raamach katalogu.
  • wszystkie posiadane przez nas kopie zapasowe kontrolerów domeny nagle stałyby się kompletnie bezużyteczne.

Miejmy nadzieję że taka sytuacja nie zdarzy się akurat wtedy gdy zachodzi potrzeba odzyskania tego OU, które”właśnie nam sie usunęło”. Warto o takich rzeczach pomyśleć wcześniej …

Czy więc wirtualizacja kontrolerów domeny jest ZŁA!!! Czy wirtualizacji mówimy NIE!!!? Ja osobiście mówię TAK, tylko z małym dodatkiem – Z głową Panowie, z głową. Jeżeli już coś robimy to warto się zastanowić jakie są tego skutki i jak należy się do tego przygotować, tudzież jak uwzględnić specyfikę środowiska wirtualnego w naszej usłudze. Tym bardziej, że temat jest dobrze znany i opisany.

Po pierwsze, tak jak już wspominałem wirtualizacja wszystkich kontrolerów domeny w środowisku nie jest zalecana, cytując:

You should retain one or two physical domain controllers per domain in your Active Directory infrastructure. An issue that is specific to virtualization software or the hardware on which it runs can interrupt services on every domain controller in the domain, or even in the forest. If possible, diversify the hardware that you use to host domain controllers so that a single hardware issue cannot interrupt your Active Directory services.

Ja osobiście się do powyższego mocno przychylam. Wracając do tematu wykładu – jeżeli już mamy w środowisku maszynę fizyczną, to oczywiście jest ona dobrym kandydatem na źródło czasu w domenie – warto o tym pomyśleć i zaplanować.

A dla pozostałych kontrolerów domeny lub gdy decydujemy się na wirtualizację całego środowiska usługi katalogowej (patrz powyżej i przeczytaj zalecenie jeszcze raz) należy zastanowić sie jak należy podejść do tematu chociażby synchronizacji czasu. W szczególnym przypadku VMWare warto zapoznać się z następującymi artykułami:

Napewno nie należy w tak krytycznym w ramach infrastruktury usługi katlaogowej elemencie jak synchronizacja czasu zwierzać systemowi operacyjnemu, który działa jako gość w środowisku wirtualnym (również routerom i innym urządzeniom sieciowym, w szczególności jeżeli nie mamy nad nimi kontroli). Jeżeli istnieje opcja synchronizacji czasu pomiędzy gościem a hostem, w przypadku kontrolerów domeny należy ją wyłączyć (zresztą pisze o tym VMWare w wymienionym powyżej dokumencie).

Co prawda w innym dokumencie VMWare zachęca jednak do tego, aby z synchronizcji czasu w relacji host –> gość jak najbardziej korzystać (VMware Time Sync and Windows Time Service), ale jakie mogą być tego skutki widzimy w relacji Wojtka.

Jeżeli już decydujemy się na wirtualizacje wszystkich systemów, należy na etapie projektu technicznego usługi zaplanować synchronizację czasu ze pewnym źródłem zewnątrznym lub wewnętrznym przez określony kontroler domeny i na tej podstawie synchronizować czas w ramach usługi katalogowej. Specjalistą od VMware nie jestem, ale w zasadzie nawet w środowisku ESX poszczególne hosty mogą synchronizować się z serwerem zarządzającym (z tym że wymaga to o ile się zdążyłem zorientować w sieci zakupu oprogramowania do zarządzania ESX). Co prawda nadal nie rozwiązuje to problemu synchronizacji czasu na poziomie host –> gość, ale pozwala chociażby zapanować nad czasem w ramach hostów. Lub też użyć tego serwera NTP jako źródła czasu w domenie.

Podsumowując – idąc za obecnym trendem warto jednak pamiętać, że jakby nie doskonała to technologia wirtualizacji opiera się na oprogramowaniu. A oprogramowanie, nieważne z jakiej stajni ma swoje narowy. I te mogą być zdradliwe.  I tym optymistycznym akcentem ….

P.S #1 Jeżeli już o wirtualizacji DC piszę to dla przypomnienia – oprócz powyższego, chociaż nie jest to tematem dzisiejszej lekcji, należy pamiętać, że obrazy maszyn (snapshot) jako metoda backupu jest ZŁA !!!

P.S. #2 I już całkiem na zakończenie link do blogu Jorge, który zebrał ostatnio w jednym wpisie linki do dokumentacj związanej z usługami katalogowymi i wirtualizacją.

P.S. #3 Długie wyszło …

3 Comments

  • Długie wyszło, ale jak zawsze dobrze się czyta i jak zawsze człowiek uczy się czegoś nowego 🙂

  • Tomku, bardzo dobrze, że napisałeś o oficjalnych zaleceniach Microsoftu i potencjalnych problemach z wirtualizacją kontrolerów. Muszę uczciwie przyznać, że wiedziałem o nich już wcześniej. Z Twojego posta odczytałem jednak przesłanie: wirtualizacja DCs jest ZŁA! i nie róbcie tego! bo na technet.microsoft.com jest napisane żeby tego nie robić bo to ZŁO 🙂

    Niestety zalecenia są tylko zaleceniami, nie zawsze można się do nich dostosować i nie każdy ma do dyspozycji oddzielne maszyny fizyczne na kontrolery domen, oddzielne na serwery bazodanowe (bo tych Microsoft też nie zaleca wirtualizować) i tak dalej. Życie najczęściej stwarza takie scenariusze, w których trudno być w 100% zgodzie z “kodeksem dobrego administratora”… i trzeba iść na jakiś kompromis.

  • @Wojtek
    Szczerze … nie wiem gdzie wyczytałeś w tym wpisie, że jestem przeciwko wirtualizacji DC. Żeby było jasne, to jeszcze raz zacytuje część tego co napisałem powyżej:

    (…)
    Czy wirtualizacji mówimy NIE!!! Ja osobiście mówię TAK, tylko z małym dodatkiem – Z głową Panowie, z głową.
    (…)

    To “TAK”, oznaczone dodatkowo dużymi literami odnosi sie do wirtualizacji właśnie. Nie wiem jak wyraźniej napisać że jestem za tym żeby z tej technologii korzystać.

    Nie wiem dlaczego piszesz też, że na Technet jest napisane żeby nie wirtualizować DC – w artykule do którego link umieściłem i który zacytowałem napisane jest jak najbardziej ŻE MOŻNA TO ROBIĆ I JEST TO WSPIERANE.

    Nie wiem też dlaczego piszesz że Microsoft nie zaleca wirtualizować serwerów baz danych – KB956893 (http://support.microsoft.com/?id=956893) definiuje warunki w których rozwiązanie takie jest wspierane i jak widać wirtualizacja SQL JEST WSPIERANA.

    Wskazałem tylko, że są znane problemy występujące w takich środowiskach i jeżeli już decydujemy się na korzystanie z wirtualizacji to warto je uwzględnić i zaplanować infrastrukturę tak, żeby ich uniknąć.

    Jak widać zalecenia pozostawienia jednego (lub więcej) DC fizycznych mają jakiś tam sens, tudzież zalecenia co do infrastruktury synchronizacji czasu w środowisku wirtualnym też mają jakiś tam sens. Jeżeli je znałeś to znaczy tylko tyle że świadomie podjąłeś ryzyko związane z ich pomięciem i doszedłeś do wniosku, że zyski związane z takim rozwiązaniem są większe niż potencjalne koszty związane z ich wdrożeniem.

    Jak dla mnie OK – napisałem ten wpis tylko po to, żeby inni którzy będą taką infrastrukturę planować też byli świadomi tych zagrożeń których Ty byłeś świadom i podjęli swoją decyzję świadomie.

    Ech … komentarz też mi długi wyszedł …

Leave a Reply