Windows Server 2003 - pierwsze starcie
(62209
odsłon)
 
Od wdrożenia przez nas platformy Windows 2003 Server obsługującej na nowej maszynie Jamę Mastaha minął już praktycznie tydzień. Ponieważ jest to jeden z pierwszych publicznych serwerów w kraju pracujących pod takim obciążeniem i w tak nietypowej konfiguracji jeszcze przed oficjalną premierą systemu, dostajemy wiele zapytań o nasze praktyczne spostrzeżenia wynikłe z unikalnej możliwości administracji takim środowiskiem. Zamiast odpowiadać każdemu po kolei postarałem się więc zebrać pierwsze doświadczenia i podzielić się nimi z czytelnikami...
 Wybór platformy
Decydując się na platformę obsługującą planowany serwer trzeba wziąć pod uwagę kilka bardzo istotnych czynników. Przede wszystkim rolę, jaką będzie on miał pełnić w planowanym środowisku, aspekty wiążące się z osobą lub zespołem realizującym funkcje administracyjne (który - jeśli już u nas istnieje - też ma swoje preferencje, nie ma bowiem specjalistów "od wszystkiego" poza naciągaczami albo ludźmi dyktującymi własne warunki zatrudnienia) oraz kwestie czysto finansowe (jak szacowane zapotrzebowanie na moc serwera oraz środki, którymi chce się to osiągnąć). Te trzy rzeczy są mocno skorelowane i powinny być rozpatrywane całościowo, ponieważ obniżanie kosztów na jednej z nich może spowodować nieproporcjonalny ich wzrost w przypadku drugiej. Biorąc pod uwagę nasze środowisko - od początku były to systemy linuksowe - wstępny wybór właśnie Debiana na platformę nowego serwera wydawał się zupełnie naturalny. W momencie, kiedy zaproponowano nam wdrożenie najnowszego Windowsa 2003 jeszcze przed oficjalną premierą, wraz z korkami od szampana pojawiły się bardzo poważne obawy zmuszające nas do gruntownego przemyślenia sprawy - nawet przy uwzględnieniu, że specyficznemu charakterowi naszego serwisu niewątpliwie sprzyjałaby ewentualna decyzja "na tak".
Pierwszy wywiad środowiskowy, którego podjęliśmy się przed zapaleniem zielonego światła, pokazał jedną rzecz - tak naprawdę, nikt nie wiedział jak to będzie chodziło (zwłaszcza, że planowaliśmy uruchomić pod kontrolą 2003 rozwiązania open source'owe). Jedyne uwagi sprowadzały się do powtarzania obiegowych opinii i stereotypów. Jakich? Spieszymy o nich wspomnieć, bo też są istotne. Chodziło głównie o tragiczną wydajność całej platformy (wróżono, że mocny komputer zacznie pracować jak dwa razy gorsza maszyna, a PHP i mySQL będą nawet tak mało wydajne, że nie udźwigną naszego ruchu). W drugiej kolejności stawiano na wątpliwą stabilność i kłopoty przy migracji z Linuksa. Uzbrojeni w płytki instalacyjne Debiana leżące w pogotowiu (jeśli cenieni fachowcy wróżą rychły wybuch, lepiej się przygotować) podjęliśmy się sprawdzenia, ile w tym prawdy...
Pierwszy kontakt
Pierwszy raz zawsze nadchodzi, nawet dla administratora systemów linuksowych. Wyposażeni w bagaż doświadczeń (głównie bardzo pozytywnych) z opieką nad skomplikowaną platformą debianową, zaczęliśmy instalację systemu, który patrząc z perspektywy sympatyka open source wygląda jak gra komputerowa. Perspektywa ta jest bardzo istotna i należy brać na nią poprawkę w kontaktach z ludźmi podającymi się za administratorów. Dzielą się oni bowiem na dwie kategorie. Pierwsza z nich to czytelnicy kolorowych gazet, których wiedza o zagadnieniach sieciowych i informatycznych nie opiera się na gruntownych podstawach teoretycznych, a na umiejętności zmuszenia konkretnego środowiska do wykonania potrzebnego zadania. W takim wypadku występuje częste zjawisko maskowania własnej niekompetencji wyraźną niechęcią (wydawałoby się uwarunkowaną ideologicznie) do rozwiązań innych niż poznane i stosowane, które stanowią tzw. bezpieczny grunt. Ludzie tacy administrują niestety nie tylko amatorskimi sieciami lokalnymi czy małymi środowiskami typu kafejka internetowa gdzie radzą sobie zupełnie dobrze, ale czasami odpowiadają także za cały system IT w firmie. Druga kategoria to administratorzy, którzy mają co prawda swoje nawyki, przekonania i doświadczenia sugerujące im taki a nie inny wybór narzędzi (których będą się czasami trzymać równie kurczowo, jak islamscy fanatycy religijni), ale dysponują potencjałem pozwalającym im rzetelnie zmierzyć się z każdym zadaniem.
Na opisywane przez nas fakty można zatem patrzeć z różnych perspektyw i stąd pierwszy kontakt z Windowsem 2003 może być określony mianem śmiesznego (identd zajmujący pod Windowsem 4 mb RAMu dla linuksowego wygi to absolutna porażka, a administracja domenami wirtualnymi przy użyciu myszki może wywołać uśmiech politowania), neutralnego (osoby mające pozytywne doświadczenia z zaawansowanymi środowiskami Windowsa 2000 Server nie zostaną niczym specjalnym negatywnie zaskoczone) lub intrygującego (przełożenie naszych linuksowych doświadczeń na nowy grunt było prawie równie pociągające jak chęć sprawdzenia, czy produkt ludzi Gatesa sprawdzi się w planowanej roli).
Sama instalacja przebiega zupełnie bezproblemowo i jest to miłe odróżnienie w stosunku do Debiana 3.0, który do zainstalowania na tej samej maszynie (dokładny opis konfiguracji tutaj) wymagał pewnych sztuczek - z jednej strony jądro bf24 zawierające obsługę systemów xfs i reiserfs miało kłopot z wykorzystaniem dość popularnego kontrolera FastTrak firmy Promise realizującego RAID'a w układzie stripe, z drugiej kłopot był także z kartą sieciową (moduł do jej obsługi znajduje się na drugiej płytce, której niestety nie mieliśmy akurat przy sobie instalując Debiana, nim zgłosił się do nas człowiek z Microsoftu proponując Windowsa 2003). O ile kwestia karty sieciowej jest sprawą zupełnie banalną, o tyle zmuszenie RAID'a do pracy już na etapie instalacji nie uda się bezproblemowo komuś, kto nie jest obeznany z linuksami. Pod tym względem Windows jest zdecydowanie prostszy i będzie lepszym wyborem dla kogoś, kto chciałby po kupnie kilku książek wyasygnować posiadanego już pod ręką informatyka do postawienia prostego serwera realizującego typowe funkcje biurowe.
Ma to też swoje minusy, bowiem kolorowy sposób konfiguracji jest złudny i wykonanie operacji postawienia poważnego już z kolei serwera wbrew pozorom skończy się najprawdopodobniej fatalnie. Niewątpliwą zaletą Linuksa już na etapie wdrażania systemu będzie to, że zmusza on do większego wysiłku intelektualnego, który w przypadku bardziej skomplikowanych środowisk potrzebny jest tak samo do rzetelnej i bezpiecznej konfiguracji prostego na pierwszy rzut oka Windowsa. Jeśli iść dalej w porównania z pingwinem już na etapie pierwszego kontaktu (których opisując system serwerowy po prostu się nie uniknie), znamienną różnicą jest także większe uporządkowanie Linuksa (chociażby centralne miejsce na całą konfigurację systemu i komponentów czy eleganckie zgrupowanie logów, czego Windowsowi niewątpliwie brakuje). Można oczywiście argumentować, że tzw. uporządkowanie to tylko zbiór przyzwyczajeń i nawyków, ale prawda jest taka, że elegancka linuksowa hierarchia związana jest nie tylko z samym systemem, ale i z jego dodatkowymi komponentami - one także podporządkowują się przyjętej konwencji (a instalacja IIS'a, PHP i mySQL'a pod Windowsem kończy się tak, że logi zostaną rozrzucone po trzech różnych miejscach, od c:/windows/system32/logfiles po d:/inetpub/sqlroot i trzeba dopiero ręcznie narzucić im swój porządek, co w przypadku nie wszystkich aplikacji windowsowych jest niestety możliwe - nie wszystkie są tak konfigurowalne i elastyczne, jak ich linuksowe odpowiedniki).
Windows wymaga zatem od administratora żelaznej konsekwencji w trzymaniu się ustalonych reguł porządkowych, w przeciwnym wypadku istnieje spore prawdopodobieństwo, że nawet wersja 2003 po roku działania skończy w typowy dla stacji roboczych sposób wymagając reinstalacji w celu zapewnienia bezawaryjności i odpowiedniej efektywności działania. Uwagi te rzucają się administratorowi z przewagą doświadczeń linuksowych już w trakcie pierwszego kontaktu i dlatego też znalazły się jeszcze w tej części artykułu.
Poznając go bliżej...
Instalacja i wstępna konfiguracja do realizacji funkcji serwerowych Windowsa 2003 zajmuje kompetentnej osobie tyle samo czasu, co podobna operacja linukusowa. W naszym przypadku, ustawienie całego serwera odbyło się praktycznie w trybie pracy zdalnej, która jest kolejną kością niezgody w dyskusjach pomiędzy zwolennikami różnych platform. Twierdzenia, że Remote Desktop Connection jest rozwiązaniem bez porównania gorszym od ssh są delikatnie mówiąc przesadzone, co okazuje się już w pierwszych minutach korzystania z tej usługi (pozbawionej pod serwerową edycją Windowsa opóźniających wodotrysków). Komfort pracy przez RDC już w dostępie realizowanym via terminale SDI jest naprawdę wysoki i nawet w przypadku linuksowego podejścia do konfiguracji w jedynie słusznym trybie tekstowym stopniowe przyzwyczajanie się do takiego sposobu pracy doprowadzić może do uzależnienia. Jedyną wadą jest konieczność instalacji usługi Terminal Services, jeśli zachodzi potrzeba jednoczesnej zdalnej administracji przez więcej jak dwie osoby (do tego poziomu wykorzystuje się tzw. Remote Desktop for Administration).
Z odczuć równie praktycznych - konfiguracja Windowsa 2003, na pozór bardzo prosta i przyjemna, niesie jednak ze sobą ryzyko wpadnięcia w pułapkę kreatorową, czyli bezmyślnego poddawania się sugestiom komputera. Zastosowanie jednak linuksowej wnikliwości daje rewelacyjne efekty i właściwie dopiero wtedy widać pełnię możliwości systemu firmy Microsoft. Przykładem takiej głębszej obserwacji niech będzie kontrola uprawnień do plików i zasobów, znacznie bardziej rozbudowana niż w przypadku systemu Linuksowego i o innej filozofii (dziedziczenia uprawnień, a nie nakładania ich przez umask).
Rzeczy te są zupełnie oczywiste dla fachowców znających platformę NT od podszewki, uznaliśmy jednak że warto o nich wspomnieć kierując tą publikację głównie do ludzi sceptycznie patrzących na serwerowe wykorzystanie Windowsów. Jeśli można coś doradzić tej pierwszej grupie, to fakt że doświadczenia z NT/2000 pozwolą na zupełnie swobodną pracę administracyjną z 2003 - wszystko, co znane z dobrej strony zostało, pojawiły się jedynie nowe możliwości (oscylujące głównie o technologię .NET).
Konfiguracja, za jaką zabraliśmy w przypadku naszego serwera, związana była z postawieniem pod Windowsem 2003 IIS'a 6.0 wraz z językami skryptów PHP i Perl oraz bazą danych mySQL, gdyż poza 2003 i IIS'em w takim właśnie środowisku pracował dotąd serwis. —adnych problemów nie nastręcza ustawienie całości tak, żeby strona wyświetlająca wynik funkcji phpinfo() zadziałała prawidłowo. Problemy, które napotkaliśmy przenosząc rozwiązania linuksowe pod Windowsa 2003 związane były z tym, że nie wszystko okazało się działać w nowym środowisku identycznie, jak w starym - tutaj jednak skala zjawiska jest bardzo indywidualna i zależy od charakteru oraz sposobu napisania skryptów PHP.
Pierwszym problemem jest np. fakt, że funkcja setlocale() nie działa tak, jak pod Linuksem - jej argumentem w przypadku Windowsa nie może być dwuliterowy skrót 'de' czy 'pl', ale określenie 'german' czy 'polish' wynikające z ustawień regionalnych w panelu sterowania. Problem niby błahy, może jednak wymagać ingerencji w treść skryptów. Kolejną obserwacją jest ciekawe działanie funkcji getenv(), które w modelu ISAPI sprowadza się do jej niefunkcjonowania. Niesie to ze sobą znowu konsekwencje przerabiania skryptów. Wymiar problemu jest jednak większy niż w przypadku setlocale(), ponieważ getenv() używane jest często do pobierania od serwera www informacji o adresie IP użytkownika przeglądającego stronę lub o serwisie polecającym - są to dość powszechne i użyteczne operacje. Usunięcie tej niedogodności jest banalnie proste (przez użycie $_SERVER['REMOTE_ADDR']) i w odróżnieniu od problemów z setlocale() nie będzie przeszkodzą w ewentualnym powrocie do starej platformy.
W przypadku serwisu o tak dużej oglądalności jak Jama Mastaha, konieczne staje się użycie kompresji wysyłanego contentu. Powoduje to, że np. dość spora objętościowo strona główna (przeszło 100kb) zmniejszana jest na potrzeby transmisji przez łącze nawet pięciokrotnie, co wiąże się nie tylko z szybszym wczytywaniem się materiałów, ale także ze zmniejszeniem zapotrzebowania na przepustowość łącza (która jest póki co droższa, niż upgrade platformy sprzętowej, której kosztem większego obciążenia realizowana jest kompresja w locie). Realizacja czegoś takiego (która pod Apachem może być na przykład zrobiona przez zastosowanie modułu mod_gzip) pod Windowsem w najprostszym przypadku sprowadza się do użycia handlera ob_gzhandler i rodzi to pewne problemy, przynajmniej w użytej przez nas konfiguracji. Globalne dodanie do konfiguracji PHP linijki output_handler = ob_gzhandler spowoduje wymuszenie zastosowania kompresji (oczywiście w przypadku wykrycia w przeglądarce klienta kompatybilności w tej materii) na wszystkich skryptach, co spowodować może nie wyjaśnione jeszcze przez nas do końca problemy (chociażby z funkcją header() powszechnie realizującą przez skrypty przekierowanie użytkownika pod inny adres). Obejście tego problemu wiąże się z poważnymi ingerencjami w same skrypty, które indywidualnie muszą sterować kompresją przez funkcję ob_start() i nie mogą stosować jej wtedy, kiedy ta okazuje się powodować w przeglądarce klienta kłopoty (objawiające się pod IE6 pustą stroną zamiast docelowej).
Bardzo istotnym w przypadku zastosowania modelu ISAPI staje się też problem maksymalnego czasu wykonywania skryptu, który trzeba dobrać indywidualnie do potrzeb (tak, żeby np. nie powodował kłopotów przy wysyłaniu plików w formularzach, ale też żeby nie stanowił zagrożenia bezpieczeństwa dającego się wykorzystać). Zupełnie bezproblemowe (i przejrzyste dla skryptów) było natomiast przejście w wysyłaniu maili przez podsystem www z modelu polegającego na wywołaniu linuksowego /sbin/sendmail na tryb SMTP - nie wymaga to ingerencji w skrypty i chodzi bardzo wydajnie pod warunkiem obecności serwera SMTP na samej maszynie realizującej www lub w jej bliskim i szybko dostępnym otoczeniu (sprawdziliśmy to przy okazji wysyłki naszego tygodnika, który obsługiwany jest przez skrypt PHP generujący wiele tysięcy egzemplarzy w ciągu kilkudziesięciu sekund).
Podsumowując - migracja z istniejącego pod Linuksem rozwiązania opartego o PHP i mySQL, choć nie pozbawiona pewnych kłopotów, jest jak najbardziej możliwa i wcale nie przesadnie skomplikowana do przeprowadzenia.
Bajki, mity i baśnie
Rzeczą, której najbardziej obawialiśmy się po uruchomieniu całości w środowisku produkcyjnym, była wydajność takiego rozwiązania. Prawie wszyscy, z którymi zdarzyło nam się na ten temat rozmawiać, wróżyli w tej materii jeśli nie absolutną porażkę, to zupełnie nieprzyzwoite rezultaty, które zmuszą nas do powrotu na platformę linuksową. Głosy te były na tyle powszechne, że sami niemalże zaraziliśmy się tym sceptycyzmem. Jak się okazało, był to największy mit ze wszystkich. Tak się złożyło, że przed przeniesieniem spędziliśmy gościnnie dwa tygodnie na bardzo podobnym serwerze obsługującym serwis CDRinfo.pl. Jedynymi różnicami było pół giga RAM'u zamiast gigabajta oraz dwa nieco szybsze procesory Athlon MP zamiast Xeonów. Efekt był taki, że nasz serwis (generowany w całości dynamicznie, w odróżnieniu od CDRinfo o oglądalności jeszcze większej niż nasza, ale serwowanego nie tyle przez serwer www, ile przez squida cache'ujacego wywołania i bardzo redukującego obciążenie maszyny) generował średnie obciążenie na poziomie 50% przy wyłączonym forum dyskusyjnym. Obecnie, przy włączonym forum, wielkość ta wynosi 20% - co widać na załączonym wykresie MRTG.
Różnica jest na tyle duża, że wydaje się aż nierealna. Uczciwie dodamy jednak, że wynikać może nie tylko z zamiany Debiana na Windowsa 2003, ale także z upgrade'u mySQL'a do wersji 4, dwukrotnie większej pamięci RAM na obecnym serwerze oraz prawdopodobnie z różnic w sposobie liczenia przez te dwa systemy obciążenia komputera. Ponadto, obecny serwer poza realizowaniem usługi WWW dla Jamy Mastaha nie pełni absolutnie żadnych innych funkcji, co dopiero stopniowo ulega zmianie. Nie bez znaczenia jest także skorzystanie z najnowszego IIS'a, który - jak pokazały nasze wstępne testy - współpracował z PHP pod Windowsem wydajniej, niż Apache. Potwierdziły się tym samym sugestie pracowników Microsoftu, że nowy IIS jest niewątpliwie wydajniejszy od poprzedniego.
Zauważyć warto jednak jeszcze jedną rzecz - od długiego czasu borykaliśmy się z problemem phpBB, które obsługuje forum dyskusyjne. Z zadziwiającą regularnością doprowadzało ono do zdosowania bazy mySQL'owej powodując niedostępność całej witryny i uciekanie linuksowego parametru loadavarage do poziomu 30/40, gdzie konieczny stawał się restart tandemu PHP+mySQL+Apache. Po zmianie środowiska problem ten zniknął. Niewątpliwie zatem, nawet jeśli w ogólnym rozrachunku wydajność w takim zastosowaniu Windowsa 2003 nie jest większa od linuksowej, z całą pewnością jest porównywalna i nie jest zgodna z przewidywaniami o zupełnym spowolnieniu nawet na tak mocnej maszynie. Naiwnym byłoby jednak sądzić, że na starym komputerze typu P100 ze śladową ilością RAMu Windows 2003 poradzi sobie równie dobrze, co Linuks realizujący z powodzeniem całkiem użyteczne funkcje. Nie jest to oczywiście prawdą, jednak implikacje tego faktu zostawmy na podsumowanie.
Podsumowanie
Podsumowanie przedstawionych faktów i dość subiektywnych odczuć jest jeszcze niepełne, bowiem brakuje tu analizy stabilności i bezpieczeństwa takiego rozwiązania. Jest to jednak parametr, którego nie sposób zweryfikować rzetelnie w ciągu tygodnia czasu (chociaż ten odbył się bez ani jednego zawieszenia i z jednym, celowym restartem przy okazji instalacji oprogramowania do poczty oraz kilkoma bezskutecznymi atakami o różnym charakterze). Wraz z powiększaniem się naszego doświadczenia w tym zakresie, wrócimy do tematu ze stosownym uzupełnieniem.
Póki co można jednak stwierdzić, że powszechne obawy kierowane w stosunku do najnowszego dziecka firmy Microsoft okazały się wyolbrzymione. Możemy także w sposób jasny i niczym nieprzymuszony dodać od siebie, że pomimo pewnych kłopotów z dostosowaniem PHP do IIS'a, jesteśmy z zastosowanego rozwiązania bardzo zadowoleni, a sam Windows 2003 Server wyszedł z pierwszego starcia z rzeczywistością zdecydowanie obronną ręką, którą dodatkowo zdołał zyskać sobie naszą niewątpliwą sympatię (którą także darzyliśmy poprzednią platformę linuksową i co wcale nie uległo zmianie). Czy znaczy to jednak, że każdy z podobnego wdrożenie będzie tak samo zadowolony? Bez owijania w bawełnę od razu odpowiemy, że nie. Różnice w wydajności, o których pisaliśmy w poprzednim akapicie sugerują, że Windows 2003 z powodzeniem sprawdzi się w środowiskach dość wymagających, gdzie konfiguracja sprzętowa pozwoli mu zrównać się pod względem wydajności z systemami linuksowymi (tak - jak pokazuje nasza empiryczna weryfikacja, jest to możliwe) lub nawet w specyficznych przypadkach ją przekroczyć. Nie ma co ukrywać, że polecenie Windowsa 2003 do obsługi mniej wymagających środowisk byłoby nadużyciem z naszej strony - tak biorąc pod uwagę inny w takim przypadku stosunek wydajności na dużo gorszym sprzęcie, jak i niewątpliwie odmienne uwarunkowania ekonomiczne. Wydaje się on jednak być rozwiązaniem zdecydowanie wartym bliższej uwagi w przypadku firm opierających swoją infrastrukturę na produktach Microsoftowych - tym bardziej w środowiskach, gdzie jedynym open source'owym rozwiązaniem jest sprzęgający sieć komputerów desktopowych Linuks (z którego migracja, jak pokazuje nasze doświadczenie, jest jak najbardziej realna).
Na koniec chcielibyśmy podkreślić, że pomimo zestawiania ze sobą pewnych aspektów rozwiązań linuksowych z microsoftowymi, chcielibyśmy uniknąć jednoznacznego wskazania faworyta. Nie dlatego, żeby nikomu się nie "narazić", jak po prostu dlatego, że każde z rozwiązań ma swoje wady i zalety, a ewentualne kwestie wyboru jednego czy drugiego uwarunkowane są czynnikami unikalnymi w każdym rozpatrywanym środowisku - w takiej sytuacji polecenie czegokolwiek "w ciemno" byłoby zupełnie nieprofesjonalne. Niniejszy tekst miał jedynie na celu pokazanie, że produkt który dopiero wyjdzie na rynek 24 kwietnia - a wokół którego narosło już wiele sprzecznych opinii - z całą pewnością nie jest wart skreślenia z listy opcji serwerowych jedynie dlatego, że - jak starają się niektórzy sugerować - w swojej nazwie ma całkiem sympatyczne skąd słowo "Windows". W miarę zdobywania dalszych doświadczeń postaramy się prezentować podobne publikacje, skupiając się już bardziej szczegółowo na konkretnych elementach i zastosowaniach wraz z analizą stabilności oraz bezpieczeństwa. |
Autor: Tomasz Bryja
Data ostatniej aktualizacji: 17.04.2003
[ Indeks sekcji ]
|
|