Wednesday, March 11th, 2009...1:38 am

Komu kontroler komu?

Jump to Comments

Active Directory ma według mnie jedną, niezaprzeczalną zaletę (wady też się znajdą 🙂 ). Usługa jest zaprojektowana w ten sposób, że przy jej prawidłowym wdrożeniu bardzo łatwo jest zapewnić jej ciągłość działania i niezawodność.

W końcu mamy:

  • możliwość utworzenia wielu replik katalogu
  • replikacje w trybie multimaster
  • mechanizm lokalizowania DC w oparciu o usługę DNS

dzięki czemu naprawdę trzeba się postarać aby ta usługa zawiodła.

Pytanie więc … dlaczego z tego wszystkiego rezygnować??


(cc) sea turtle

Przyczynkiem do tego poniekąd marudząco \ roztrząsajęgo wpisu było kilka różnych wątków na wss.pl i innych forach, w których poruszany był temat zapewnienia ciągłości działania usług, kopii zapasowych itp. Elementem wspólnym we wszystkich był fakt, że we wszystkich przypadkac przygotowywane były plany wykonywania kopii zapasowych i odtworzenia nie uwzględniające jednego faktu – zapewnienia conajmniej jednego, dodatkowego kontrolera domeny w celu zachowania ciągłości dostępu do usługi w chwili awarii jednego z nich.

Jak więc wyglądał będzie scenariusz naszej awarii w przypadku gdy posiadamy tylko jeden kontroler domeny. Nadchodzi wielki dzień i ….

  • Awarii ulega jedyny kontroler domeny
  • Jeżeli mamy odpowiedni sprzęt
    • Instalujemy OS
  • Jeżeli nie mamy odpowiedniego sprzętu to go szybko szukamy
    • Odtworzenie zajmuje chwilę dłużej, zawsze pojawiają się jakieś problemy z warstwą sprzętu itp.
  • Odtwarzamy wszystkie niezbędne dane, usługę katalogową itp.
  • Zakładając że wszystko poszło dobrze po jakiś 2-3 godzinach (heh – optymiasta) wszystko wraca do normy.

A w trakcie tych 2-3 godzin:

  • Użytkownicy nie mają dostępu do zasobów sieciowych
  • Poczta, jeżeli zintegrowana z katalogiem to nie jest dostępna
  • Jeżeli dostęp do sieci też był uwierzytelniony przez AD to nawet gazety nie da się poczytać w sieci.
    • Pozostaje pasjans :).

Cały ten opis nie uwzględnia tego, że:

  • awarią musimy zająć się natychmiast, ponieważ powoduje ona przerwę w możliwości prac użytkowników
  • nad głową wisi nam <tutaj wpisać odpowiednie nazwisko lub stanowisko>, który domaga się aby wszystko zaczęło działać.
  • w zasadzie to jestśmy najbardziej opanowni pod słońcem, zero stresu i postępujemy zgodnie z przygotowaną wcześniej procedurą (mamy ją?? 🙂 ).

Czyli kilkugodzinna przerwa w pracy związana  z odtworzeniem kontrolera domeny, wymagająca naszej intensywnej pracy i co ważniejsze obecności na miejscu, a wszystkiego tego można by uniknąć gdyby … w sieci pracował dodatkowy kontroler domeny. A jak wtedy wyglądałby nasz scenariusz:

  • Awarii ulega jeden z wielu kontrolerów domeny
  • W sieci nikt niczego nie zauważa, ewentualnie klient musi zlokalizować nowy kontroler domeny
  • Administrator w tym czasie kończy kawę i kanapkę i postępując zgodnie z przygotowanym za wczasu planem odtworzenia usługi (mamy go ?:) ) ustala jaką ścieżke rozwiązania awarii przyjmie.
  • Spokojnie, zgodnie z opracowanym planem przystępujemy do usunięcia awarii.

Dla mnie różnica jest zasadnicza. W szczególności brak punktu uwzględniający obecność <tutaj wpisać odpowiednie nazwisko lub stanowisko> nad naszą głową wydaje im się cenny. W zasadzie <tutaj wpisać odpowiednie nazwisko lub stanowisko> może nawet nie wiedzieć, że coś się wydarzyło chociaż dobry plan na wypadek awarii powinien pewnie zakładać poinformowanie pewnych osób odpowiedzialnych za działanie firmy, między innymi może też i <tutaj wpisać odpowiednie nazwisko lub stanowisko>.

To na co chciałem tutaj tym przydługim marudzeniem zwrócic uwagę to fakt, że planując wyszukane metody wykonywania kopii zapasowych, stawiając klastry dla serwerów SQL i aplikacji często zapominamy o najprostszych metodach zapewnienia działania podstawowej usługi, jaką w momencie wdrożenia staje sie usługa katalogowa. A do zapewnienia jej działania wystarczy tak niewiele … dodatkowa maszyna, odpowiednia konfiguracja i plan działań na wypadek awarii. W zasadzie powinno się to skalkulować przy wystąpieniu pierwszej awarii :).

Więc może warto znaleźć środki na zakup dodatkowej maszyny i licencij jeszcze w tym budżecie a nie przekładać tego na rok następny … lub nigdy.

I to w zasadzie tyle ….

… a nie … zapomniałbym, WIRUTALIZACJA. Buzz word wszystkich informtyków w ostatnich czasach. W zasadzie po co stawiać ten dodatkowy kontroler domeny, przecież obecny mam zwirtualizowany, mogę go jakby co szybko odtworzyć ze snapshotu czy innego ustrojstwa do strzelania :).

Niby tak, ale:

  • Takie rozwiązania pozwalają jedynie na skrócenie czasu odtworzenia usługi
  • Przy awarii sprzętu –> czy naprawdę aż tak bardzo skracają ten czas – w szczególności gdy awarii ulegnie ważna i jakby na to nie patrzeć nie tania infrastruktura SAN czy innych tam dysków?

Opieranie strategii odtworzenia usługi o wirtualizację i jej możliwości (miłe, nie zaprzeczam) w zasadzie niczym nie różni się od planu zakładającego użycie kopii zapasowych:

  • Nadal zakładamy przestój w pracy usługi
  • Nadal wymagana jest nasza obecność
  • Całość odbywa się pod presją <tutaj wpisać odpowiednie nazwisko lub stanowisko> związaną z wpływem awarii na działanie organizacji.

Tak więc WIRTUALIZACJA, tak – ale jeżeli już to żeby zapewnić platformę do utrzymania dodatkowego kontrolera domeny a nie jako centrum naszego planu zapewnienia ciągłości działania usług. Pomijając już fakt, że wirtualizację wszystkich maszyn pracujących w centrum infrastruktury takim jakim jest usługa katalogowa nie uważam za dobry pomysł (teraz to mi się oberwie od zwolenników wirtualizacji totalnej 🙂 ).

P.S. #1 Tym wpisem nawet nie pretenduje to stworzenia czegoś co można by nazwać planem awaryjnym czy planem odtworzenia usługi katalogowej. Po prostu chciałem zwrócić uwagę na coś co mnie kilka raz zakłuło w oczy.

P.S. #2 Punkt widzenia autora tego wpisu nie jest prawdą objawioną i jedyną wykładnią. Komentarze mile widziane i wskazane. Dyskusja jak najbardziej również.

16 Comments

  • Tomek, ale dlaczego nie zwirtualizaować wszystkich DC? Oczywiście zakładam wdrożenie na klastrach,z redudancją wszystkiego co może nam nawalić. Zwlaszcza na Server 2008 R2 z LiveMigration.
    Zresztą na TechNet’cie jest to całkiem nieźle opisane: http://technet.microsoft.com/en-us/library/dd363553.aspx 🙂

  • Ostatnio robiłem przeliczenia i kosztorys wdrożenia wirtualizacji dla pewnej firmy. Okazało się, że w przypadku małej firmy wdrożenie wirtualizacji znacznie przekraczały możliwości finansowe:/ Ostatnio też czytałem art, o tym jak w pewnej firmie poszła główna macierz, na której siedziały maszyny wirtualne:) Koszty naprawy i czas odzyskania wygenerowały ciekawe straty. Dlatego wydaje mi się, że zwolennicy wirtualizacji nie zjedzą cie w komentarzach:) Ja też jestem zdania, że należy wizualizować ale z głową. A wykonywanie snapshotów na produkcyjnych DC to czasami takie czekanie na krach.

  • “Zwlaszcza na Server 2008 R2 z LiveMigration.”
    W vmware też jest LM i na ostatnim webcascie gość się zapytał kilkunastu adminów, kiedy tego używają i czy często. Pracownicy stwierdzają, że funkcja jest ważna jednak maszyny przenoszą tylko w godzinach nocnych. Na pytanie dlaczego, powiedzieli: “bo ta funkcja czasem powoduje crash maszyny:/”

  • To po kolei:

    @ Piotrek
    Nie mówię, żeby nie wirtualizować w ogóle a tylko żeby zabezpieczyć sobie “tyły” na żelazie. Dlaczego?? Dlatego że w przypadku gdy zwirtualizujemy wszystko awaria infrastruktury wirtualizacji lub oprogramowania (patrz zeszłoroczne problemy VWMare z licencjami) powoduje że cała twoja infrastruktura leży i kwiczy.

    Zresztą jeżeli zajrzysz w link zaczynąjący się od “Planning …” w artykule który podesłałeś znajdziesz coś takiego:

    (…)
    Planning to keep some physical domain controllers

    You should retain one or two physical domain controllers per domain in your Active Directory infrastructure.
    (…)

    🙂

  • @Kaarol
    Nie wiem jakie wyliczenie robiłeś. Zgadzam się, że postawienie środowiska wirtualizacji tak jak rozumiemy to w jakimś większym środowisku – czyli zasoby dyskowe, zapewnienie możliwości przenoszenia maszyn itp mogą być zbyt duże.
    Z drugiej strony większość kupowanego w tej chwili sprzętu może znacznie przekraczać wymagania stawiane serwerom w małych i średnich firmach. W takim wypadku użycie jednego z dostępnych hypervisorów pozwala ładnie zoptymalizować wykorzystanie tych maszyn :).

  • @Tomek:
    🙂 Owe, kluczowe, zdanie w artukule o planowaniu przeoczyłem 🙂

    @Kaarol:
    Co do LM w nocy: jak najbardziej się zgadzam z tym podejściem. Nie zaryzykowałbym przenoszenia produkcyjnej maszyny w ciągu dnia.
    Chyba że w momencie przenoszenia maszyna nic nie robi i ewentualny downtime byłby dopuszczalny.

  • @t.onyszko
    “Z drugiej strony większość kupowanego w tej chwili sprzętu może znacznie przekraczać wymagania stawiane serwerom w małych i średnich firmach.”

    Zgadzam się. Jednak stawianie Hypervisora na serwerze bez sieciowego zasobu dyskowego jest trochę ryzykowne. No chyba, że są to mało ważne maszynki i możemy sobie pozwolić na ich czasowy downtime.

  • @Kaarol
    To jest zawsze kwestia planowanej funkcjonalności, do kosztów jej wdrożenia itp.

    Jeżeli na przykład mamy jeden kontroler domeny i drugi serwer pełniący jakąś rolę, która nie wykorzystuje jego zasobów – wtedy zwirtualizowanie na tym drugim serwerze dodatkowego kontrolera domeny jest rozsadnym krokiem IMO nawet bez dużej infrastruktury.

  • wszystko pięknie dopóki używamy tylko AD, problem pojawia się gdy musimy część AD zreplikować na np: OpenLdap

  • @wolvverine

    Hmmm … OK, ale czy z powodu dodatkowego kontrolera domeny :)? OpenLDAP tez wspiera repliki i replikacje danych … mozesz rozszerzyc (moze być na e-mail) na czym polega problem?

  • […] Allana Mitchella, András Belokosztolszki , a z naszych rodzimych m.in.: Marka Byszewskiego, Tomasza Onyszko, Karola Stilgera, Marka Adamczuka i Radka Kępę.  O wszystkich specjalistach, których spotkasz […]

  • […] Allana Mitchella, András Belokosztolszki , a z naszych rodzimych m.in.: Marka Byszewskiego, Tomasza Onyszko, Karola Stilgera, Marka Adamczuka i Radka Kępę.  O wszystkich specjalistach, których spotkasz […]

  • […] to rewelacja” pisałem ostatnio (no powiedzmy że nie dosłownie) nawet nie myśląć, że do tematu wirtualizacji w kontekście […]

  • Wpis ma ponad dwa lata, ale dorzucę “swoje 3 gr” – myślałem ostatnio nad tym, czy wszystko wirtualizować itp. – czy rzeczywiście wirtualizacja z jednej strony dająca jakąś tam redundancję okazuje się równocześnie miejscem, gdzie nasza domena padnie, bo jest tylko jedna macierz/podłączenie do niej. Nie jestem tak pewien, że jeden z DC musi być na “bare metal” – bardziej skłaniałbym się do tego, żeby był “na osobnym sprzęcie” – ale czemu nie zwirtualizowany? Może być przecież tak, że mamy naszego hypervisora z maszynami na pamięci masowej, na nim jeden lub dwa DC, a kolejny (na VM) DC na sprzęcie wręcz “labowym”, gdzie pracuje 2 dyski w RAID a sprzęt jest klasy desktopowej. Myślę, że nawet taki sprzęt wystarczy, aby na chwilę pociągnąć domenę w przypadku jakichś problemów z głównymi DC czy hypervisorem.
    A jest to też jakiś rodzaj rozwoju wszerz domeny.

  • Ten dodatkowy kontroler to fikcja. Od kilku dni czytam (książki i na stronach M$/ forach) i nikt nie potrafi odpowiedzieć jak sprawić by drugi po awarii pierwszego kontynuował role pierwszego. Drugi może owszem działać ale pod warunkiem, że pierwszy działa. Gdy wysiądzie pierwsz – drugi jest bezużyteczny.

  • xyzt … nic na to nie poradzę że nie możesz do tego dojść. Z mojego doświadczenia – drugi i n-ty zawsze przejmuje rolę tego pierwszego czy innego n-tego. O ile wszystko jest poprawnie skonfigurowane i w środowisku nie ma problemów

    A z tego co piszesz to na pierwszy rzut strzelałbym konfiguracje DNS :).

Leave a Reply