Poprzedni wpis był poniekąd teoretyczny i ten też taki trochę będzie. A i temat będzie taki, który już kiedyś poruszałem. Co ja poradzę, że pytania w temacie przychodzą
i przychodzą. Temat dzisiejszego odcinka – po co komu dodatkowy kontroler domeny? Dzisiaj może w trochę innym ujęciu – jak przekonać kogoś, że takowy jest nam
w firmie potrzebny.
Pytanie ze swej natury padać będzie raczej w środowiskach małych lub średnich. Przy większych środowiskach kwestia ta raczej nie podlega dyskusji lub też łatwo wykazać, że takowe rozwiązanie jest nam potrzebne i przydatne, a przy tym wcale nie takie kosztowne.
Zacznijmy od przypadku ekstremalnego, czyli stanowisko ni, bo nie. Chciałem zacząć od tego przejaskrawionego przykładu, ponieważ tutaj poruszamy się w obszarze poza merytorycznym a więc i dyskusji merytorycznej nie ma często, co prowadzić. Gdyby ktoś jednak chciał … polecam czytać dalej. Jeżeli nie ma chęci lub jest to wysiłek bezcelowy – wnioski pozostawiam osobie w konkretnej sytuacji.
To tyle tytułem wstępu. Jeżeli jednak da się rozmawiać a potrzebne są nam rzeczowe argumenty, to pierwsze zagadnienie, nad którym warto się pochylić chwilę, to dlaczego takie pytanie padło i jakie są przyczyny roztrząsania tematu. Przyczyn mogę wyobrazić sobie, co najmniej kilka:
- Brak wiedzy w temacie i chęć zaspokojenia ciekawości, co do roli dodatkowego DC w sieci przez zadającego pytanie
- Kwestie związane z kosztem zakupu dodatkowego sprzętu \ wydzielenia zasobów dla maszyny wirtualnej, licencji i późniejszego utrzymania takiej maszyny.
- Podobne do powyższych kwestie związane z ograniczeniem kosztów dla już istniejących w środowisku rozwiązań.
Pytanie takie często trafia do administratora czy innego pracownika działu IT … no
i właśnie, jak podejść do udzielenia odpowiedzi.
W przypadku pierwszym, czyli chęci zaspokojenia chęci wiedzy pytającego, należy po prostu udzielić merytorycznej odpowiedzi (przesłanki do tej w moim wcześniejszym wpisie) i to powinno sprawę rozwiązać. Co prawda może powodować też przejście do pytania z tej drugiej kategorii – czyli “Tak, to może by się go tak pozbyć bo jednak to trochę kosztuje ! Mamy wszystko zwirtualizowane, łatwo to odzyskać, redundancja w tym zakresie nam naprawdę nie jest potrzebna” . To jeszcze raz …
… po co to wszystko
Dodatkowy kontroler domeny w środowisku ma za zadanie zapewnienie dostępności usługi, zapewnienia ciągłości jej działania oraz co w tym kontekście może jest mniej istotne, zapewnienia rozłożenia obciążenia usługi. Skupiając się tylko na aspekcie dostępności usługi, awaria kontrolera domeny, w przypadku, gdy jest to jedyny kontroler w naszym środowisku powoduje:
- Brak możliwości zalogowania się użytkowników w trakcie trwania awarii
- Brak możliwości uzyskania dostępu do zasobów i usług w sieci, w trakcie trwania awarii. Użytkownicy, którzy posiadają ważne bilety dostępu do usług będą mogli nadal z nich korzystać, jednak nie będą mogli uzyskać dostępu do nowych usług i zasobów, a posiadane bilety w końcu stracą ważność.
W przypadku, gdy w firmie korzystamy z serwera Exchange jako serwera poczty i pracy grupowej awaria DC w takim scenariuszu powoduje, że usługa ta przestaje działać. - W przypadku, gdy kontroler domeny jest jednocześnie serwerem DNS, jego awaria spowoduje problemy w komunikacji sieciowej (często spotykane
w takich wypadkach). To samo dotyczy innych usług sieciowych utrzymywanych na DC (DHCP, WINS itp.).
To od strony technicznej. Od strony działania firmy powoduje to że:
- Użytkownicy nie mogą pracować z usługami i aplikacjami w sieci. Z dużym prawdopodobieństwem ich praca ograniczy się tylko do lokalnych aplikacji
i danych. - Jeżeli nasz system pocztowy jest powiązany z AD to tracimy możliwość komunikacji pomiędzy pracownikami firmy jak i ze światem zewnętrznym.
- Całość powyższego przekłada się na fakt, że przynajmniej od strony technologicznej firma stoi.
Teraz ważne pytanie – czy powoduje to też, że nie działa biznes? Jeżeli działalność firmy opiera się na narzędziach i systemach sieciowych – prawdopodobnie odpowiedź brzmi TAK. Jeżeli działalność firmy wymaga ciągłej możliwości komunikacji
w ramach firmy jak i ze światem zewnętrznym a taka awaria powoduje, że komunikacja ta jest zaburzone – prawie na pewno awaria infrastruktury powoduje, że w jakiś sposób naruszony zostaje też interes firmy od strony biznesowej. Jeżeli pracujemy w firmie produkcyjnej, gdzie główną działalnością jest produkcja produktu firmy, a awaria usługi katalogowej nie dotyka tego fragmentu firmy bezpośrednio, to może się okazać, że dopuszczalny jest jakiś czas przestoju działów niezwiązanych bezpośrednio
z produkcją … i dalej w ten deseń.
Jak poważne jest to zaburzenie i ile ono kosztuję firmę? Ano właśnie, na to pytanie Wam nie odpowiem, ponieważ zależy to od tego jaki jest profil działalności firmy
i w jakim stopniu awaria taka zakłóca możliwość jej prowadzenia. Nie zmienia to faktu, że na odpowiedź właśnie na takie pytanie w tym kontekście powinniście być przygotowani. Czyli kilka pierwszych do przygotowania się do dyskusji:
W jaki sposób awaria jedynego kontrolera domeny w naszej sieci zakłóca działanie systemów informatycznych firmy?
Jak zakłócenie działania tych systemów wpływa na możliwość wykonywania zadań w ramach firmy, w szczególności jej podstawowych zadań?
Czy jest możliwe określenie kosztu przestoju w takim wypadku? Jeżeli tak – postarajmy się je oszacować.
Jeżeli przestój usługi katalogowej powoduje, że przez godzinę czy dwie firma nie może prowadzić swojej działalności albo jest w tym ograniczona i użytkownicy grają
w pasjansa, to może jednak warto utrzymywać tą dodatkową maszynę. I to starajmy się wykazać.
… ok, ale mamy wirtualizację
“Ano właśnie”, powiem nam na to osoba, która zadaje nam takie pytanie – przecież mamy tą całą wirtualizację. Jak coś się stanie to szast prast i już mamy odtworzoną ze snapshotu maszynę i wszystko działa poprawnie. Ano właśnie …
… czy to jest do końca prawda. Załóżmy więc, że mamy naszą jedyną maszynę pełniącą rolę kontrolera domeny w postaci maszyny wirtualnej i wykonujemy jej kopie w jakiś, poprawny dla tego środowiska sposób. Ponieważ maszyna jest jedna, to nie mamy problemu z usn-roll back i podobnymi przypadłościami. Super.
Co jednak daje nam wirtualizacja? Wirtualizacja, w takim wydaniu nie zabezpiecza nas przed awarią, jedynie zmniejsza czas wymagany do odtworzenia usługi (przynajmniej w założeniach). Czas odtworzenia maszyny wirtualnej jest krótszy, niż czas odbudowy DC i odtworzenia go z kopii zapasowej. Czyli jest dobrze?
Nie do końca. Nadal, w przypadku awarii DC, gdy posiadamy tylko jedną maszynę występuje czas przestoju związany z koniecznością przywrócenia działania usługi. Może i krótszy ale jednak (patrz powyżej). Dodatkowo, taka metoda odtworzenia usług, czyli przywrócenie obrazu maszyny jest zawsze metodą *stratną*. Nie odzyskujemy usługi w takim stanie jak w chwili wystąpienia awarii, ale w stanie, w jakim stwozona została kopia zapasowa. A to może być okres dłuższy lub krótszy – zawsze jednak należy zakładać, że jakaś część danych zostanie utracona – czy to zmiany na kontach użytkowników, grupach czy też zmiany haseł.
To ostatnie jest wbrew pozorom ważne. Może się bowiem okazać, że nasze konta serwisowe czy konta maszyn, na których działają nasze usługi zmieniły hało od czasu wykonania ostatniego zrzutu maszyny wirtualnej. Wtedy, nawet po odtworzeniu naszej maszyny wirtualnej, nadal może się okazać, że nasze usługi nie działają
a dodatkowo konieczne będzie przeprowadzenie procedury troubleshooting w celu określenia przyczyny problemu.
Ale … tak wiem, mamy klaster pod naszą wirtualizację, z całym narzutem infrastruktury, aby klaster ten działał. No cóż, pytanie co jest w takim wypadku bardziej kosztowne – zapewnienie i utrzymanie tego klastra czy też utrzymanie dodatkowego DC. Oprócz tego pytanie – jak zarządzany jest ten klaster, czy też należy do domeny?? Jeżeli tak, to mamy większy problem. A jeżeli nie, to pozostałe pytania pozostają otwarte. No tak – ale już i tak zainwestowaliśmy w wirutalizację.
… czy to naprawdę tak dużo kosztuje.
Ano właśnie, czy i ile to tak naprawdę nas kosztuje?
Na jednej ręce mamy więc koszt związany z zakupem oprogramowania (Win Server Std. minimum a w tym segmencie, którego myślę takie dywagacje dotyczą to maksimum), sprzęt z tym związany (patrz poprzedni teoretyczny wpis), dodatkowe oprogramowanie (AV, backup) i utrzymanie (aczkolwiek kosztu utrzymania dodatkowego DC w małej czy średniej sieci bym nie demonizował to istnieć to on istnieje). To wszystko należy porównać, z leżącym na drugiej ręce kosztem ewentualnego przestoju firmy, utraty\odtworzenia informacji itp.
Tak według mnie powinien być rozważany koszt ewentualnego wdrożenia w infrastrukturze dodatkowych rozwiązań czy mechanizmów, a takim jest kontroler domeny. Ponieważ to nie koszt tego oprogramowania czy sprzętu dla niego potrzebnego jest decydujący, a porównanie go, z tym co za ten koszt początkowy i potem związany z utrzymaniem, tak naprawdę otrzymujemy. A otrzymujemy święty spokój w przypadku awarii jednego z komputerów, brak przestojów i przerw w pracy pracowników, co w zasadzie przekłada się na konkretne, mierzalne korzyści dla firmy.
Z tym, że niestety nie zawsze jako ludzie zajmujący się IT wiemy jak je policzyć i przedstawić. A bez tego, niestety faktycznie trudno obronić kolejne pudełko czy licencję. Nieważne czy będzie to kontroler domeny, serwer SQL czy inne rozwiązanie.
No i tak to, dobrnęliśmy do końca … komentarze jak najbardziej otwarte.