Migracja do Windows 2000 jest najtrudniejszym z dotychczasowych wyzwań stawianych administratorom systemów opartych na technologii Microsoft Back Office. Nie da się jej przeprowadzić bez szczegółowego zaplanowania poszczególnych etapów czy lokalizacji poszczególnych serwisów systemowych, a także sekwencji, w jakiej będzie uaktualniać się oprogramowanie serwerowe.

Administratorzy, którzy przeprowadzali kilka lat temu migrację z Windows NT Server 3.51 do Windows NT Server 4.0, powinni mieć raczej miłe wspomnienia. W rzeczywistości bowiem systemy te tylko nieznacznie różnią się od siebie pod względem wewnętrznej architektury. Funkcjonalność NT 4.0 nie wynikała bowiem z fundamentalnych zmian w konstrukcji systemu, ale z modyfikacji jego interfejsu graficznego i wzbogacenia go o dodatkowe komponenty internetowe, takie jak serwer DNS czy serwer Internet Information Server (IIS). Nie zmieniła się także leżąca u podstaw systemu architektura domenowa, co spowodowało, że migracja w dużej mierze ograniczała się do aktualizacji oprogramowania systemowego na serwerach bez konieczności szczegółowego jej planowania.

Na taki luksus nie mogą sobie pozwolić informatycy odpowiedzialni za przeprowadzenie migracji z systemu Windows NT 4.0 (lub też innych) do Windows 2000. Nowy system jest bowiem zbudowany na innym fundamencie niż jego poprzednicy. Są nim usługi katalogowe Active Directory, które wymagają określonego środowiska pracy, np. dynamicznego DNS, który we wszystkich poprzednich wersjach systemu był statyczny (zmiany nie były wprowadzane automatycznie w momencie włączania i wyłączania komputerów podłączonych do sieci). Dlatego w każdej firmie konieczne jest szczegółowe określenie, które serwery i w jakiej sekwencji powinny być aktualizowane, tak by praca sieci była zakłócona w jak najmniejszym stopniu. Konieczne jest także sprecyzowanie parametrów technicznych, które będą niezbędne do pracy poszczególnych usług systemowych, i porównanie ich z aktualną konfiguracją serwerów. Może się okazać, że przejście na nową platformę będzie wymagać inwestycji w dodatkowy sprzęt (pamięć, procesory, dyski).

Konieczne jest również podjęcie decyzji, jaką wersję serwerowego systemu operacyjnego zamierza zastosować firma, w jakim tempie przeprowadzić wdrożenie, jakie usługi Windows NT 4.0 poddać migracji, a jakie pozostawić w nie zmienionym stanie. Często niezbędnym elementem procesu planowania migracji jest przeprowadzenie instalacji pilotażowej, która zweryfikuje, czy zaplanowane działania można zrealizować zgodnie z wcześniejszymi założeniami.

Migracja w firmie Powietrze SA

Informatycy firmy Powietrze SA podeszli do problemu migracji w sposób pragmatyczny. Dwóch spośród czterech informatyków uczestniczyło w szkoleniach dotyczących administracji systemem Windows 2000 oraz przygotowaniach do wdrożenia i administracji usług katalogowych Active Directory (lista szkoleń zamieszczona jest w ramce na str. 14). Szkolenia te trwały trzy tygodnie, podczas których pozostali dwaj pracownicy działu informatyki zajmowali się bieżącą obsługą systemu informatycznego i użytkowników, a także dokumentowaniem posiadanej infrastruktury serwerowej i testowaniem stanu jej przygotowania do wdrożenia nowej wersji systemu operacyjnego.

Serwery firmy Powietrze SA są wyposażone w procesory Pentium Pro, Pentium II i Pentium III, toteż nie należało się tu spodziewać problemów w migracji do Windows 2000. Informatycy założyli jednak, że konieczne będzie zwiększenie ilości pamięci operacyjnej - szczególnie w serwerach Neptun i Saturn, które pełnią funkcję kontrolerów domenowych. Na tym etapie planowania migracji nie było jeszcze wiadomo, jaka docelowa ilość pamięci będzie optymalna. Po powrocie kolegów ze szkolenia zdecydowano, że zostanie dwukrotnie zwiększona ilość pamięci w serwerze Neptun (do 256 MB), o tyle samo powiększy się ilość pamięci w serwerze Saturn (do 192 MB), który będzie pełnić funkcję kontrolera domenowego i globalnego katalogu Active Directory, i do 128 MB zwiększy się ilość pamięci w serwerze Jowisz.

Istotnym etapem planowania migracji, przesądzającym w zasadzie o przydatności poszczególnych serwerów, była weryfikacja, czy są one przygotowane do pracy z systemem Windows 2000. Taką weryfikację informatycy firmy Powietrze SA przeprowadzili na kilka sposobów. W pierwszej kolejności pobrali spod adresuhttp://www.microsoft.com/windows2000/downloads/deployment/readiness/default.asp narzędzie Windows 2000 Readiness Analyzer, weryfikujące, czy dany komputer spełnia wymagania techniczne stawiane przez system. Ponadto sprawdzili, czy konkretne modele serwerów znajdują się na liście urządzeń kompatybilnych z Windows 2000 (http://www.microsoft.com/windows2000/upgrade/compat/issues.asp). W przedostatnim etapie pobrali ze stron producentów serwerów najnowsze aktualizacje BIOS, wymagane do poprawnej pracy Windows 2000, a w ostatnim sprawdzili, czy na lokalnych dyskach twardych serwerów znajduje się odpowiednia ilość wolnego miejsca (minimum 650 MB wolnej powierzchni na partycji, na której ma być zainstalowany system).

Wybór właściwego systemu

Windows 2000 jest dostępny w dwóch wersjach serwerowych, a wkrótce na rynek trafi trzecia. Informatycy firmy Powietrze SA już na etapie planowania migracji musieli zdecydować, którą wersję chcą wdrożyć.

Podstawowa wersja systemu Windows 2000 Server umożliwia obsługę serwerów 4-procesorowych, wyposażonych maksymalnie w 4 GB RAM.

Bardziej zaawansowana wersja oprogramowania serwera - Windows 2000 Advanced Server - może pracować na maszynach 8-procesorowych i obsługuje do 8 GB RAM. Zastępuje ona dostępną dotychczas wersję Windows NT Server 4.0 Enterprise Edition. Oprócz obsługi większej ilości procesorów i pamięci, Advanced Server wyposażono także w możliwość pracy w konfiguracjach klastrowych składających się maksymalnie z 2 serwerów, a także w możliwość równoważenia obciążenia TCP/IP pomiędzy wieloma serwerami (do 32) udostępniającymi usługi internetowe.

Microsoft zapowiada również wprowadzenie na rynek jeszcze jednej, najbardziej zaawansowanej wersji - Windows 2000 Datacenter Server. Będzie ona obsługiwać do 64 GB pamięci RAM i ok. 32 procesorów. Umożliwi także budowanie konfiguracji klastrowych składających się z 4 serwerów, przy czym wszystkie będą mogły pracować równolegle.

Potrzeby firmy Powietrze SA w zupełności zaspokaja podstawowa wersja systemu serwerowego. Nie ma ona bowiem serwerów wieloprocesorowych (dwa z nich umożliwiają co prawda rozszerzenie do 2 procesorów, ale taką liczbę obsługuje jeszcze Windows 2000 Server i nie wymaga konfiguracji klastrowych). Być może w przyszłości informatycy zdecydują się zastosować technologię Windows Load Balancing, równoważącą obciążenie pomiędzy serwerami internetowymi (jest ona wbudowana w Windows 2000 Advanced Server), gdy firma w większym stopniu będzie wykorzystywać Internet do prowadzenia elektronicznego handlu, ale na razie jej zastosowanie nie jest uzasadnione.

Dokumentacja środowiska

Istotnym elementem poprzedzającym migrację jest przygotowanie pełnej dokumentacji opisującej konfigurację serwerów, zainstalowanych na nich systemów, usług sieciowych, a także wzajemnych relacji między serwerami i domenami. Jest to szczególnie istotne w przypadku dużych, wielodomenowych sieci korporacyjnych, w których między domenami istnieją jedno- lub dwukierunkowe relacje zaufania. W tych środowiskach istotne jest również udokumentowanie takich elementów, jak scenariusz replikacji danych pomiędzy rozproszonymi kontrolerami domenowymi (szczególnie wtedy, gdy oddzielone są one routerami), scenariusz replikacji plików (zwłaszcza w przypadku skryptów logowania), a także baz WINS.

Problemy te nie dotyczą jednak firmy Powietrze SA. Wykorzystuje ona relatywnie proste środowisko Back Office, składające się z jednej domeny Windows NT. Żaden z serwerów nie jest również oddzielony od podstawowej sieci łączem o małej przepustowości, które wymuszałoby optymalizację procesów replikacji danych.

W ramach procesu dokumentacji środowiska sieciowego administratorzy firmy Powietrze SA posłużyli się narzędziem Ecora.com Network Documentor, które uruchamiane z przeglądarki internetowej automatycznie tworzy dokładną dokumentację techniczną serwera, na którym zostało ono uruchomione. Narzędzie to jest dostępne bezpłatnie do testów pod adresemhttp://www.ecora.com, a jego działanie było opisane w Computerworld 4/2000. Z wykorzystaniem tego narzędzia opisano konfigurację serwerów Neptun i Saturn. Informatycy musieli jednak ręcznie spisać konfigurację serwerów DHCP i WINS, gdyż Network Documentor nie oferuje takiej funkcji.

Dokumentację Plutona, w szczególności opisanie udostępnionych na nim katalogów wraz z prawami dostępu, spisanie konfiguracji karty sieciowej i karty graficznej, wykonano ręcznie. Podobnie potraktowano serwer Jowisz, na którym pracował system operacyjny Linux.

Mając szczegółową dokumentację konfiguracji serwerów Neptun, Pluton, Saturn i Jowisz (tylko te serwery poddane zostaną migracji, zgodnie z wariantem obranym przez firmę Powietrze SA), można było przystąpić do określenia docelowej sekwencji migracji serwerów i udostępnianych na nich usług sieciowych.

Najpierw kontrolery domeny...

Przy złożoności procesu, jakim może być migracja z domeny Windows NT 4.0 do domen Windows 2000, przeprowadzenie go w środowisku jednodomenowym jest łatwe. Producent systemu przyłożył bowiem ogromną wagę do opracowania jak najmniej problematycznej procedury aktualizacji serwerów pracujących pod kontrolą Windows NT Server 4.0 - w tym także kontrolerów domenowych. Jedynym wymaganiem jest przestrzeganie odpowiedniej kolejności aktualizacji maszyn pełniących funkcje domenowe.

W przypadku aktualizacji kontrolera domeny systemowa baza bezpieczeństwa SAM, zawierająca m.in. informacje o użytkownikach domenowych, jest zachowywana tylko przy uaktualnianiu serwera pełniącego funkcję podstawowego kontrolera domeny (PDC). W każdym innym przypadku, np. podczas aktualizacji zapasowego kontrolera domeny (BDC), baza ta jest usuwana. Oznacza to, że jeśli migracja ma się zakończyć powodzeniem, konieczne jest w pierwszej kolejności zaktualizowanie do Windows 2000 podstawowego kontrolera domeny, którym w przypadku firmy Powietrze SA jest serwer Neptun.

Po zainstalowaniu na nim Windows 2000 (procedura migracji opisana jest poniżej) nowy system automatycznie wykryje, że właśnie uaktualniony został podstawowy kontroler dotychczasowej domeny i zaproponuje instalację na nim usług katalogowych Active Directory w domyślnej konfiguracji (automatycznie uruchomione zostanie narzędzie DCPROMO.EXE). Zanim jednak to nastąpi, na serwerze Neptun będzie musiał być zainstalowany nowy serwer DNS niezbędny do pracy Active Directory (jest on w Windows 2000 znacznie rozszerzony w porównaniu z wersją dostępną w Windows NT Server 4.0 pracującą na serwerze Saturn). Więcej o Active Directory piszemy w artykule Katalogi na steroidach.

Optymalnym i zalecanym przez Microsoft sposobem migracji zapasowych kontrolerów domeny jest zainstalowanie na nich Windows 2000 w "czystej" konfiguracji - jak gdyby na tym serwerze nigdy nie był zainstalowany system Windows NT Server 4.0. Oczywiście, jest to możliwe tylko wtedy, jeśli poza funkcją zapasowego kontrolera domenowego serwer nie oferuje innych dodatkowych usług, które powinny być poddane uaktualnieniu. Tak jednak nie jest w przypadku firmy Powietrze SA. Na serwerze Saturn pracują bowiem usługi serwera zdalnego dostępu (RAS), serwera DHCP przydzielającego numery IP stacjom roboczym, serwera WINS i DNS. Dlatego on również, podobnie jak Neptun, musi być poddany procesowi uaktualnienia (upgrade).

... potem reszta serwerów

Dwa pozostałe serwery przeznaczone do migracji to Pluton i Jowisz, wyposażone odpowiednio w systemy NetWare 3.12 i Red Hat Linux. Pierwszy z nich pełni rolę serwera plików (w tym udostępnia bazę danych Microsoft FoxPro), drugi pełni funkcję serwera internetowego, udostępniającego firmową stronę WWW.

Informatycy firmy Powietrze SA zdecydowali, że nie będą aktualizować serwera Pluton do systemu operacyjnego Windows 2000, gdyż docelowo realizowane przez ten serwer zadania ma przejąć Neptun. Pozwoli to oddelegować Plutona do realizacji innych, jeszcze nie sprecyzowanych zadań (informatycy rozważają możliwość uczynienia z niego serwera terminali, aczkolwiek ze względu na jego słabą konfigurację sprzętową nie należy tego pomysłu traktować jako dobrego rozwiązania).

Fakt, że brakuje pomysłu na zagospodarowanie Plutona, nie oznacza, iż można opóźniać migrację przechowywanych na nim danych. Przeniesienie danych na Neptuna pozwoli bowiem usunąć ze stacji roboczych dedykowane oprogramowanie klienta NetWare, które, niestety, stanowi dodatkowe obciążenie dla komputerów. Pozwoli również całkowicie usunąć z sieci protokół IPX i w całości oprzeć ją na TCP/IP. Innymi argumentami przemawiającymi za szybką migracją jest oczekiwane ułatwienie zarządzania serwerami (administratorzy będą pracować w jednym, w miarę spójnym środowisku), a także konieczność wykorzystania dodatkowego serwera podczas migracji serwera Jowisz udostępniającego usługi internetowe (piszemy o tym dalej).

Migrację serwera Pluton można przeprowadzić na dwa sposoby, które szczegółowo opisane są w artykule Dwa w jednym.

Pora na WWW

Ostatnim serwerem, który poddany zostanie migracji będzie Jowisz, udostępniający serwis WWW dla użytkowników Internetu. Podstawowym założeniem, które poczyniono już na etapie planowania migracji, była konieczność minimalizacji czasu przestoju serwera.

Podstawowa trudność w migracji tego serwera, podobnie jak w przypadku serwera NetWare, polega na tym, że nie można w żaden sposób uaktualnić zainstalowanego na serwerze systemu do Windows 2000 z zachowaniem konfiguracji serwera internetowego. Początkowo informatycy rozważali skopiowanie zapisanych na Jowiszu plików na inny serwer, jego pełne wyczyszczenie i zainstalowanie od nowa systemu Windows 2000 Server wraz z oprogramowaniem serwera internetowego Internet Information Server 5.0 (IIS). Niemniej to rozwiązanie wymagałoby dużego nakładu pracy i powodowałoby przestój serwera co najmniej na czas reinstalacji.

Ostatecznie zdecydowano się więc skorzystać z innego rozwiązania. Wymagany był do niego "wyczyszczony" wcześniej z plików serwer Pluton oraz dodatkowe narzędzie dostępne w pakiecie Windows 2000 Server Resource Kit. O tym, jak przeprowadzono tę migrację, można przeczytać w artykule Jak pozbyć się Apacza?.

Procedura aktualizacji serwera

Informatycy firmy Powietrze SA opracowali również procedury aktualizacji wszystkich serwerów.

W przypadku kontrolerów domenowych, na których system miał być poddany aktualizacji (upgrade), najpierw uruchamiano na nich program instalacyjny ze specjalnym parametrem wymuszającym przetestowanie, czy dana maszyna z zainstalowanym na niej systemem operacyjnym kwalifikuje się do aktualizacji. Składnia tego polecenia była następująca:

WINNT32 /CHECKUPGRADEONLY

Polecenie to sprawdza, czy serwer spełnia niezbędne wymogi techniczne do pracy Windows 2000 i czy zainstalowane na nim aplikacje są kompatybilne z nowym systemem. Oczywiście wynik działania tego testu nie jest jednoznaczną odpowiedzią, czy dany serwer wraz z pracującymi na nim aplikacjami można zaktualizować do Windows 2000, ale pozwala on szybko określić np. ewentualne problemy sprzętowe, potencjalną niezgodność sterowników itp.

Instalację systemu na serwerach Neptun i Saturn informatycy zdecydowali się przeprowadzić w trybie w pełni automatycznym - bez zadawania przez procedurę instalacyjną zbędnych pytań i z migracją wszystkich komponentów w sposób domyślny. Aby właśnie tak zainstalować system, musieli uruchomić procedurę instalacyjną w następujący sposób:

WINNT32 /UNATTEND

Aby jednak upewnić się, czy taka procedura poprawnie uaktualni najważniejszy serwer w firmie, czyli podstawowy kontroler domeny, jakim jest serwer Neptun, informatycy zdecydowali się zrealizować testową migrację pilotażową.

Instalacja oprogramowania na serwerach Jowisz i Pluton była realizowana indywidualnie i bez automatyzacji, według procedury opisanej w artykule Jak pozbyć się Apacza?.

Pilot

Informatycy firmy Powietrze SA mają zbyt małą sieć, by decydować się na realizację instalacji pilotażowej odzwierciedlającej każdy komponent sieci i każdą usługę sieciową, realizowaną przez firmowe serwery. Najbardziej obawiali się o los domenowej bazy danych, zawierającej informacje o wszystkich kontach użytkowników, i dlatego zdecydowali się przetestować wyłącznie ten element migracji. Większym firmom, wykorzystującym sieci wielodomenowe, zdecydowanie zaleca się stworzenie instalacji pilotażowej Windows 2000, odzwierciedlającej w miniaturze strukturę sieci korporacyjnej. Jak bowiem widać na przykładzie firmy Powietrze SA, nawet w tak małej organizacji informatycznej migracja do nowego systemu bez jej właściwego zaplanowania może zakończyć się niepowodzeniem lub niepełnym powodzeniem, które neguje sens przedsięwzięcia.

Aby przetestować, jak odbywa się migracja kontrolera domenowego, informatycy tymczasowo wyposażyli jeden z komputerów wykorzystywanych w dziale informatyki w 256 MB RAM i zainstalowali na nim system Windows NT Server 4.0, pracujący jako zapasowy kontroler domeny (BDC). Następnie serwer ten odłączono od sieci lokalnej i podłączono do wydzielonego przełącznika sieciowego, do którego była podłączona jeszcze dodatkowa, standardowo skonfigurowana, stacja robocza uczestnicząca w teście. Po zrestartowaniu serwera administratorzy awansowali go do funkcji podstawowego kontrolera domeny (można to uczynić z każdym BDC, jeśli w sieci nie jest widoczny, np. z powodu awarii, podstawowy kontroler domeny PDC). Operacji tej nie mogli przeprowadzić w podstawowej sieci lokalnej, gdyż doprowadziłaby ona do nienaturalnej sytuacji, w której w domenie istniałyby dwa PDC.

Po przetestowaniu możliwości zalogowania do sieci z komputera testowego, informatycy wykonali aktualizację serwera do Windows 2000 według opisanej wcześniej procedury. Zgodnie z planem operację przeprowadzono automatycznie i po kilkakrotnym restartowaniu na serwerze pracował już system Windows 2000. Po zalogowaniu na nim administratora system zasugerował instalację serwera DNS i usług katalogowych Active Directory.

Po przeprowadzeniu tej operacji sprawdzono możliwość logowania użytkownika z komputera testowego do nowej domeny Windows 2000. Jako że standardowo pracowała ona w trybie zgodności (Mixed) z trybem domenowym Windows NT Server 4.0, użytkownik na stacji roboczej nie wyposażonej w klienta Active Directory mógł się bez przeszkód zalogować w domenie Windows 2000. Jak wykazała więc instalacja testowa, procedura aktualizacyjna przygotowana przez informatyków firmy Powietrze SA pracowała w pełni poprawnie.