Najcięższe 34 godziny ostatnich miesięcy.

Od razu uprzedzam – jeżeli kiedykolwiek przyjdzie Wam do głowy reinstalacja głównego kontrolera domeny na Windows Serverze 2003 to dobrze się zastanówcie. Niech to będzie ostateczna ostateczność.

Prolog:
W firmie w której pracuję, Windows Server jest jednym z ważniejszych serwerów. Jego głównym zadaniem jest rola kontrolera domeny. Dodatkowo obsługuje Symfonię, MSSQL, pliki uzytkowników, VPNa, serwer wydruków i kilka(naście) mniejszych lecz równie ważnych usług. Jakiś czas temu wychwalałem jedną z tych usług jaką jest WSUS. Pamiętajcie, że zawsze jednak bardziej stoję po stronie *NIXów więc pochwała Microsftu na tym blogu to duża rzecz ;) W prologu także należy się pochwała dla MS i całej sprawy domenowej. W skrócie (jeśli wszystko działa jak należy) to użytkownik ma swój login i hasło, administrator przypisuje mu prawa i właściwie user musi pamiętać tylko swoje hasło. Jeśli oprócz logowania do komputera ma uprawnienia do logowania do VPNa – robi to tym samym hasłem, a Cisco PIX przy pomocy Radiusa autoryzuje go w sprawdzając w Active Directory czy powinien. Tak samo działa dostęp do plików, drukarek itd. Słowem wszystko co da się ożenić z Active Directory jest zarządzane z jednego miejsca. Dołóżmy do tego zarządzanie stacjami roboczymi, wprowadzanie polityk i uaktualnień i dostajemy całkiem fajny produkt. Gorzej jeśli coś nie działa, a najgorzej jeśli nie działa i nie wiadomo dlaczego oraz jak temu zaradzić. Tak też się stało. Pomijając już problem z samym serwerem a dokładnie z uwalonym dyskiem od jednego RAIDA, który udało się rozwiązać w 2h. Otóż, nasz prześwietny serwer po uruchomieniu działa sobie kilka godzin, lub kilka minut. Po pewnym nieokreślonym czasie uzytkownicy traca do niego dostęp i np nie mogą zapisać już otwartych plików, przestają działać drukarki. Zdalny dostęp jest, ale po podaniu usera i hasła zostaje niebieski ekran i oczekiwanie w nieskończoność (zarówno zdalnie jak i lokalnie na konsoli). CTRL+ALT+DEL nic nie daje. Wszystko jest w dowolny sposób wymiaszane w kolejności i w czasie. Po tygodniu zgłebiania problemu i kilkunastu restartach dziennie zapadła decyzja o reinstalacji.

Co się działo po tej decyzji:
Muszę przyznać, że była to pierwsza reinstalacja w mojej karierze tego typu, czyli z pełnym zachowaniem wszystkiego. Przez cały piątek i poniedziałek zrobiłem listę rzeczy do zbackupowania oraz innych spraw o których należy pamiętać. Lista uruchomionych usług, zainstalowanego oprogramowania itd. Po analizie wyszło mi, że jak zaczniemy o 18 w poniedziałek to na 7 we wtorek wszystko powinno śmigać i zostaną tylko jakieś drobiazgi do wyeliminowania. W międzyczasie postawiłem drugi tymczasowy serwer 2003, dodałem go jako kolejny kontroler domeny aby zreplikował się Active Directory oraz ustaliłem na nim DFS aby zreplikowały się dane ze wszystkich dysków. Replikacja AD poszła sprawnie, dane przesyłały się po gigabicie od piatku rana do około 18 w piatek. Było tego około 400GB tak więc całkiem sprawnie jak na maszynę obciążoną innymi zadaniami i co jakiś czas resetowaną. Po całkowitej synchronizacji sprawdziłem wydajność replikacji DFS przez tworzenie plików i katalogów na starym serwerze i patrzeniu jak szybko pojawią się na nowym. Wypadło to nieźle ponieważ dla pojedynczych plików czas pomiędzy przełączeniem się między zdalnymi pulpitami wystarczył aby plik znalazł się w odpowiednim miejscu. Po godzinie 18 sprawdziliśmy jeszcze czy wszystko się zreplikowało oraz dla pewności wykonaliśmy pełen backup na taśmę 400GB. Pełen backup w nocy wykonuje się około 3h, tym razem wykonywał się około 4 i pół. Z perspektywy mogę powiedzieć, że był on całkowicie nieprzydatny, a dane zgrane przez DFS w zupełności wystarczyły. Przed taśmą jeszcze backup wszystkich baz MSSQL także zabrał prawie dwie godziny. Koniec końców przed 24 mogliśmy zacząć faktyczną reinstalację. Aby było super, zdecydowałem się także na update BIOSu DELLa oraz jego kontrolera SCSI. Kontroler wymagał update’u ponieważ Openmange Server meldował o niezgodności oprogramowania. Update z dyskietek skończył się miganiem diody od błędu na obudowie Della. Okazało się także, że jest wersja Windowsowa do aktualizacji biosów. Należało uruchomić zatem serwer jeszcze kilka razy (a minuty lecą). Windowsowy update poszedł bez problemu, natomiast był dość czasochłonny. Na koniec jeszcze dcpromo aby obniżyć rangę serwera i przetransferować kontrolę na serwer tymczasowy. Poszło to także bez problemu natomiast zrobiło sie grubo po północy. Po zalogowaniu się i upewnieniu, że serwer został już tylko członkiem domeny, nadszedł upragniony czas reinstalacji. Instalacja odbyła się bezproblemowo, instalator wykrył PERC’a bez problemu więc tu mamy do przodu, ale czas na przebudowe raidów znowu nas spowolnił. Szczęśliwie po zalogowaniu trzeba było dograć tylko sterownik karty sieciowej i streamera. Aby mieć dobrą bazę wyjściową zainstalowaliśmy wszystkie poprawki łącznie z Service Packiem 2 dla 2003. Nie muszę mówić, że znowu czas potrzebny do instalacji wszystkiego okazał się o wiele dłuższy niż zakładaliśmy. W końcu przyszedł czas na dcpromo i dodanie nowego serwera do istniejącej domeny na serwerze zapasowym. I tu zonk. Po wskazaniu domeny oraz podania hasła i usera, który ma prawa aby dołączyć kontroler komunikat – nie można znaleźć domeny. No tak, nie ma serwera DNS na zapasowym, szybko postawiony DNS nie rozwiązał problemu. Zaczęło robić się nerwowo, jest już poważna noc a właściwie wcześnie rano (koło 3-4) a tu nawet AD nie chce działać… W czasie rozwiązywania problemów z DNSem zaczeliśmy zgrywać przez sieć dane uzytkowników, o dziwo w drugą stronę szło to strasznie wolno. Po półtorej godzieni udało się ruszyć DNS na tyle, że nowy kontroler w końcu znalazł zapasowy serwer. Okazało się, że w głównej mierze odpowiedzialny za to był Windows Firewall. Dziwne o tyle, że nie powinien się włączyć ponieważ tak było ustawione GPO, dodatkowo komunikaty od dcpromo wskazywały na coś zupełnie innego. Nic to jednak, system zalogowany do domeny jako kontroler domeny! Yaaay! No to teraz dcpromo na zapasowym aby obniżyć go do członka z kontrolera. Poszło to sprawnie lecz… cała konfiguracja zreplikowała się nie wiedzieć czemu na serwer oddalony o 35 km od Poznania – do Szamotuł, po vpnie, na łączu 128 kbs. Tak wiem, lame trochę :) trzeba było odłączyć kabelek, lub chociaż zrestartować Szamotuły, albo skasować połączenie w Sites and Services. No trudno, stało się, odkręcę później. Rzecz w tym, że teraz dostęp do usług katalogowych odbywa się przeraźliwie wolno i przez przysłowiowe „do Warszawy przez Szczecin” czy jak to leciało. Kolejne minuty lecą, kolejne usługi są doinstalowywane. DHCP, DNS. Tak więc godzina 6:40 wybiła, pojawiają się pierwsze koleżanki księgowe, my mamy AD z zespołem Downa lub Autystyczne, ledwo działające DHCP oraz około 70% plików użytkowników. Jesteśmy po prostu zajebiści! W przeciągu najbliższej godziny udało się przywrócić DHCP i DNS aby działało ładnie po AD. Userzy mogą już się logować. Wspinamy się na wyżyny naszej wiedzy i nawet skróty do udziałów działają bez modyfikacji. 70% danych jest wystarczające aby księgowość pracowała, w tle dogrywamy inteligentnie resztę – ważne katalogi najpierw, nieważne później. W trakcie walki z Szamotulskim serwerem, który skutecznie odmawia dcpromo ponieważ nie widzi Poznania (chociaż cały czas się z nim replikuje debil!) doinstalowuję kolejne usługi, File Server, Print Server etc. O godzinie 9 mamy już prawie działające drukarki (również prawie bez zmian na kilkudziesięciu klientch, dobra nasza!). HR w międzyczasie zaczyna układać sobie papiery na półkach z braku dostępu do Symfonii. Ja w tym czasie dwa razy instaluję MS SQL’a ponieważ ten prześwietny program w połączeniu z Symfonią musi mieć locale ustawione na polski gdyż inaczej nie da rady zainstalować bazy Symfonii. Oczywiście potzrebne są service packi itp. Gdy w końcu Enterprise Manager rusza, i można restorować bazy jest już chyba po 12, zaczyna dawać o sobie znać kryzys niewyspania. Zaczynam się poważnie wkurzać na AD i Szamotuły, kontakt ze znajomym MVP (Hi nixtone ! ;) owocuje garścią przydatnych linków odnośnie rół serwera. Udaje się przetransferować ręcznie 2 z 3 ról. Kontroler Schematów niestety nie chce się transferować. Cholerna Symfonia z SQLem jest tak powolna, że kilkuset megowe bazy restorują się kilka godzin. Po jakimś czasie Kontroler Schematu zgłasza się, że można go przetransferować. Go! Kontrolne dcpromo w Szamotułach – brak błędu, że to już ostatni kontroler domeny – mam cię! Tymczasowego serwera nie ma, więc dcpromo na 100% zreplikuje i przetransferuje mi AD do Poznania. W międzyczasie po instalacji softu do sieciowego skanowania do pdf na serwer, wymagany jest restart. Bardzo zła decyzja, serwer wstaje bez problemu natomiast wisi około godziny na „Preparing Network Connections”. W tle dokonuje się transfer AD, kontrolera domeny, ról i co tam jeszcze. Usługi działają, użytkownicy nie narzekają, ale nie ma dostępu do serwera. Staje się jasne, że nie wyjdziemy planowo o 16. Kiedy koło 14:30 serwer w końcu wstaje, sieć dostaje niesamowitego kopa, nie czeka się już kilka(naście) sekund na zapisanie czegoś na serwerze (poprzednio AD z Szamotuł sprawdzało czy user z Poznania może zapisać w Poznaniu :). Pozostało do zrobienia – VPN, skanowanie i Symfonia, to jest mission critical, pomniejsze sprawy mogą poczekać. Skaner udaje się uruchomić po 16:30, VPN prawie chodzi, ale ostatecznie zaczyna działać (znowu bardzo szybko, o wiele szybciej niż poprzednio) w środę rano.) Koniec restore baz kadrowych kończy się po 18 we wtorek! Symfonia zaczyna działać około 10 w środę. Wychodzimy z firmy przed 19 we wtorek po 34 h non stop przy monitorach. Krótki sen i dokończenie konfiguracji w środę. Teraz jest czwartek i pozostała kosmetyka oraz kilka usług nie tak ważnych z punktu widzenia użytkowników.

Epilog.
Jak widzicie skoro mam czas na napisanie tego, to wszystko dobrze się kończy. Najważniejsze pytanie, czy warto? Teraz mogę powiedzieć, że tak. Serwer działa stabilnie, i wydajnie. Przywracanie go do stanu używalności obciązało go maksymalnie i ani razu nie odmówił działania ani się nie zawiesił. Wyeliminowany został także główny powód reinstalacji czyli niewiadome odmowy usług. Serwer działa także zauważalnie szybciej oraz ma sensowniej porozdzielaną przestrzeń dyskową. Istotne jest także to, że własnoręcznie zainstalowany system działa bardziej przewidywanie, a Administrator wie co w nim piszczy. Pozostaje tylko pytanie dlaczego nawet na potęznych maszynch Windows jest tak strasznie powolny. Odtwarzanie baz SQL to koszmar, Active Directory i jej transfer jest tak nieintuicyjny i czasochłonny jeśli nie jest w tej samej sieci a przy tym upierdliwy (robi się przy starcie systemu zamiast po starcie). Następnym razem (który mam nadzieję nie nastąpi) trzeba będzie lepiej oszacować czas aby nie wystawiać się na gniew użytkowników i zwierzchników. Ostatecznie jednak, pomijając jeden dzień bałaganu w firmie, wszystkim wyszło na dobre. Administratorzy mają spokój z serwerem i kilka spraw uporządkowanych, serwer działa odpowiednio szybko i stabilnie, użytkownicy nie tracą danych i nie mają przestojów przez brak połączenia. Mam nadzieję, że ludzie nad IT także to dostrzegają ;)

[donate]

© odwiedź stronę http://maciejewski.org po więcej fajnych postów!