Dyski twarde (a było ich w testowanym klastrze 16) zostały skonfigurowane w dość skomplikowany sposób. Trzeba je było podzielić na kilka partycji, tak aby test pracował w optymalny sposób i serwer mógł osiągnąć wysoką wydajność. Każdy węzeł miał więc do dyspozycji swój własny dysk, który był używany wyłącznie przez system operacyjny zarządzający tym węzłem. Wbudowany w każdy węzeł kontroler UltraWide SCSI sterował dyskiem zawierającym system operacyjny. Pozostałe 14 dysków zostało podzielonych na dwie części - z tym że dostęp do wszystkich tych dysków miał każdy z węzłów (dyski były zarządzane przez współużytkowane - przez oba serwery - kontrolery SCSI). Sześć dysków stanowiło integralną część klastra (dyski wewnętrzne), a osiem umieszczono w oddzielnej obudowie (dyski zewnętrzne - macierz dyskowa).

Na dziesięciu dyskach utworzono dwie partycje RAID-0 - zapisywanie danych w trybie smużenia (stripping). Jedna partycja była wykorzystywana przez pliki zawierające dane, a druga była wykorzystywana do przechowywania danych SQL (baza danych). Cała dziesiątka dysków była zarządzana przez jeden z kontrolerów RAID wbudowanych w serwer. Drugi kontroler RAID zarządzał pozostałymi czterema dyskami. Z tych czterech dysków wydzielono dwa i utworzono na nich dwie partycje pracujące w trybie smużenia danych (RAID-0). Jedna partycja była używana przez programy SQL, a druga przez narzędzia zarządzające klastrem. Pozostałe dwa dyski skonfigurowano jako jedną partycję RAID-0, która była wykorzystywana do przechowywania plików dziennika tworzonych przez aplikację SQL.

W zaprezentowanej konfiguracji kontrolery RAID nie pracują zgodnie z zasadą redundancji, dlatego wymiana kontrolera pociąga tu za sobą konieczność wyłączenia klastra z eksploatacji. Kontrolery można jednak tak skonfigurować, aby pracowały w trybie „failover“ (automatyczne przełączanie na wypadek awarii jednego z kontrolerów). W testowanym klastrze nie zastosowano tej metody, tak aby oba kontrolery mogły być używane jednocześnie, dzięki czemu serwer pracował bardzo wydajnie.

Klaster CL1850 oferuje nowe rozwiązanie, dzięki czemu jest bardzo prosty w obsłudze: chodzi o możliwość wymiany serwerów „na gorąco“. Oprogramowanie zarządzające serwerem (opracowane przez Microsoft) nosi nazwę Cluster Manager; oprogramowanie to jest zainstalowane w każdym węźle, dlatego węzeł można w razie potrzeby wyłączyć z klastra. Węzeł można następnie wyjąć i w jego miejsce wstawić inny. Cała taka operacja trwa nie więcej niż pięć minut, tak iż użytkownicy węzła nie zdążą nawet dostrzec, że coś takiego nastąpiło. Jest to rzeczywiście bardzo wygodne rozwiązanie - po wyjęciu jednego węzła w wieży (lub w stojaku) jest tak dużo wolnego miejsca, że można wtedy z łatwością uzyskać dostęp do wszystkich innych elementów klastra.

Aby sprawdzić, ile czasu potrzebuje klaster, aby przełączyć klientów z jednego serwera na drugi, użyto testu Benchmark Factory. Test wykazał, że klienci potrzebowali ok. 160 sekund, aby wrócić do normalnej pracy, ale korzystając już z usług i zasobów drugiego serwera. Nie jest to może oszałamiający wynik, ale daje przynajmniej gwarancję, że po upływie dwóch minut wszystko wróci do normy. Eksploatując normalny serwer, nigdy nie byłoby to przecież możliwe.

Oprogramowanie Cluster Manager pozwala też przenosić aplikacje z jednego węzła do drugiego, konfigurować węzły i monitorować pracę całego klastra. Trzeba powiedzieć, że oprogramowanie to pracuje rzeczywiście intuicyjnie, ale samo zainstalowanie programu MSCS nie jest wcale takie łatwe. Klaster nie pracuje zawsze tak, jakby można się tego po nim spodziewać, i nieraz trzeba było wprowadzać różne zmiany do rejestrów obu serwerów, aby modyfikować konfigurację sieciową obu węzłów.

A co z wydajnością?

Serwer CL1850 uzyskał w kategorii oceny „Wydajność” 8,0 punktów. Jeśli chodzi o test sprawdzający wydajność przy przetwarzaniu plików (serwer plików), to serwer uzyskał 8,3 punktu - głównie dzięki obecności wielu dysków pracujących w trybie RAID-0 i doskonałej wydajności kontrolerów RAID. Po uruchomieniu testu sprawdzającego wydajność układów CPU serwer uzyskał notę 8,2. Wyniku takiego można się było spodziewać - procesory Pentium III 550 MHz pracują przecież bardzo szybko. W kategorii oceny „Praca w sieci” produkt uzyskał notę 7,5. Oprogramowanie zarządzające klastrem musi kontrolować cały czas oba serwery, co odbija się jednak niekorzystnie na wydajności układów współpracujących z siecią.

#Opis techniczny testowanego produktu#^
Serwer	CL1850
Producent	Compaq
Typ procesora	Pentium III 550 MHz (z pamięcią podręczną L2 512 kB)
Liczba procesorów	2
Liczba obsługiwanych procesorów	2
Pamięć RAM	4 x 256 MB
Liczba i typ gniazd na pamięć RAM	4 DIMM
Dostępne gniazda	3 x PCI (32-bitowe; 66 MHz); 1 x PCI/ISA
Kontroler dysków	CR3500 (jednokanałowy kontroler U2 SCSI; cache 128 MB
Dyski twarde	6 x 9,1 GB U2 SCSI wewnętrzne; 1 x 9,1 GB U2 SCSI, węzeł numer 1, OS; 1 x 9,1 GB U2 SCSI, węzeł numer 2, OS; 8 x 9,1 GB U2 SCSI, zewnętrzne – macierz dyskowa
Rozmieszczenie dysków twardych	2 x 1-calowe kieszenie w każdym węźle; 6 x 1-calowe kieszenie w wewnętrznym współużytkowanym module; 14 x 1-calowe kieszenie w module zewnętrznym – macierz dyskowa
Karty sieciowe	Trzy karty sieciowe (NIC) Intel Pro 100+ w każdym węźle. Jedna karta obsługuje komunikację między węzłami
Dostępne rozwiązania	Klaster pracuje w trybie „failover“ (przełączanie serwerów); redundancyjne kontrolery RAID; zapasowe wentylatory; zapasowy zasilacz
Zarządzanie Narzędzia	Microsoft Cluster Manager i Compaq Insight Manager XE
Bezpieczeństwo	Zamykana obudowa; hasło Power On; zabezpieczenia systemu NT
Dołączone oprogramowanie	Compaq Insight Manager XE
Gwarancja	Trzy lata

W kategorii oceny „Dodatkowe funkcje i skalowalność” klaster zebrał 9,2 punktu. Bardzo dobry wynik, możliwy do uzyskania dzięki takim rozwiązaniom jak magistrala danych PCI 66 MHz, szereg zawansowanych funkcji realizowanych przez klaster i obecność tak wielu pojemnych dysków twardych. No i dwie ostanie kategorie oceny: „Zarządzanie” (7,8 punktu) i „Łatwość obsługi” (10 punktów). Jeśli chodzi o tę drugą notę - można powiedzieć - produkt doskonały. Niższą notę w kategorii oceny „Zarządzanie” klaster zawdzięcza oprogramowaniu MSCS, z którym były jednak pewne kłopoty. Compaq dostarcza z klasterem swoją firmową platformę zarządzania (Compaq Insight Manager), która zawiera takie narzędzia jak Cluster Monitor i Intelligent Cluster Administrator. Klaster jest wyjątkowo łatwy w obsłudze, tak iż administrator może bez żadnego kłopotu wymienić w jednym z serwerów procesor lub pamięć RAM, nie wyłączając klastra z eksploatacji.

Jednak skonfigurowanie klastra wymaga pewnego wysiłku. Zainstalowanie na klastrze systemu operacyjnego Windows NT 4.0 razem z oprogramowaniem (a następnie zainstalowanie odpowiednich aplikacji) wymaga trochę czasu i cierpliwości, i może być nieraz frustrujące. Ale jest to właściwie „zasługą” firmy Microsoft (oprogramowania zarządzającego klastrami) i Compaq nie ponosi za to odpowiedzialności. Należałoby tylko wyrazić życzenie, aby Microsoft usprawnił pracę narzędzi zarządzających klastrami i pomyślał o opcji, która potrafi równomiernie obciążać zadaniami serwery wchodzących w skład klastra (load balancing). Jeśli tak się stanie w przyszłości, to klastry podobne do jednostki CL1850 bardziej masowo wejdą do małych i średnich przedsiębiorstw eksploatujących szczególnie krytyczne aplikacje, które nie powinny odmówić świadczenia usług.

<hr>

Metodologia testowania

Aby sprawdzić, jak sprawuje się serwer wchodzący w skład klastra CL1845, uruchomiono trzy testy: jeden sprawdzał wydajność sieciową, drugi wydajność układów CPU, a trzeci, jak szybko serwer obsługuje system plików. Wszystkie testy pracowały pod systemem operacyjnym Windows NT 4.0. Test CPU był oparty na oprogramowaniu Benchmark Factory (jest to test porównawczy opracowany przez firmę Client Server Systems, wykorzystujący bazę danych MSSQL 7.0). Do testowania wydajności systemu plików wykorzystano oprogramowanie Dynameasure File Professional wersja 2.0 (Bluecurve). Sieciową wydajność serwera sprawdzał test Chariot (Ganymede Software). Test sprawdzający wydajność systemu plików został tak zaprojektowany, aby wykorzystywał w maksymalnym stopniu podsystem plików, starając się jednocześnie w minimalnym korzystać z usług układu CPU i sieci. Aby to zrobić, przesyłano pliki o długości 12 KB między klientami i serwerem tak szybko, jak jest to tylko możliwe (transmisja odbywała się jednocześnie w obu kierunkach). W ten sposób zwiększono obciążenie kontrolera dysków, tak aby sieć nie miała zbyt dużego wpływy na uzyskane wyniki. Produkowane obecnie serwery dysponują wydajnymi procesorami, a ten test nie obciąża procesora zbyt intensywnie. Test uruchamiano sześć razy. Za każdym razem zwiększano liczbę symulowanych użytkowników, zwiększając stopniowo obciążenie serwera. Na samym początku z usług serwera korzystał jeden użytkownik, a następnie 10, 20, 30, 40 i wreszcie 50 użytkowników.

Oprogramowanie firmy Bluecurve jest łatwe w obsłudze, ponieważ wiele zadań wykonuje automatycznie. Test przebiegał dlatego bardzo sprawnie i sześć kolejnych sesji testowania trwało tylko kilka godzin. Należy tu podkreślić, że test ten realizuje najgorszy z możliwych scenariuszy. W świecie rzeczywistym rzadko mamy do czynienia z tak intensywnym obciążeniem serwera. Klienci są tu tak skonfigurowani, że wysyłają kolejne żądanie jak najszybciej, natychmiast po tym, gdy poprzednie żądanie zostało obsłużone przez serwer. Typowy użytkownik nie generuje nigdy żądań z taką częstotliwością; dlatego na liczbę symulowanych użytkowników w momencie szczytowej wydajności serwera nie należy patrzeć jako na parametr wskazujący, ilu użytkowników może obsłużyć testowany serwer. W rzeczywistości serwer może obsłużyć jednocześnie dużo większą liczbę użytkowników, niż sugerują to wyniki tego testu. Blok danych użyty do testowania systemu plików miał długość 2 GB. Nie jest to dużo, biorąc pod uwagę fakt, że pamięć RAM serwera ma pojemność 1 GB, ale Bluecurve tak właśnie pracuje. W idealnej konfiguracji blok danych powinien mieć pojemność odpowiadającą czterokrotnej lub pięciokrotnej pojemności pamięci RAM, tak aby uniknąć sytuacji, w której system operacyjny Windows robi użytek ze swojej pamięci podręcznej. Test CPU został tak skonstruowany, aby obciążać maksymalnie procesor, pomijając wpływ takich elementów jak podsystem plików i sieć. Użyto do tego celu testu Benchmark Factory SQL, który generował żądania czytania danych z bazy danych obsługiwanej przez (zainstalowane na testowanym serwerze) oprogramowanie MSSQL 7.0. Tak jak w przypadku testu sprawdzającego wydajność systemu plików, tak i tu zwiększano stopniowo liczbę symulowanych użytkowników. Tym razem zaczynano od jednego użytkownika, a następnie z usług serwera korzystało po kolei 2, 4, 6 i wreszcie 8 użytkowników. Istnieje tu analogia do sytuacji przy testowaniu wydajności systemu plików. Chodzi o to, że test jest bardzo wymagający i w rzeczywistości serwer może prawdopodobnie obsłużyć dużo większą liczbę użytkowników. Do sprawdzenia wydajności sieciowej serwera użyto testu Chariot (Ganymede). Najpierw dwóch klientów wysyłało do jednej karty sieciowej zainstalowanej w serwerze (transmisja w trybie dwukierunkowym) dwa strumienie danych TCP. Następnie dwie karty sieciowe zainstalowane w serwerze obsługiwały czterech klientów i cztery strumienie danych TCP. Dwa strumienie symulowały transakcje tekstowe http, a pozostałe dwa strumienie symulowały transakcje graficzne http (przesyłanie obrazów gif). Jedna sesja testu trwała 10 minut. Po jej ukończeniu zawsze obliczano wartość średnią, obrazującą szybkość transmisji danych dla tej sesji.

Wykonano pięć takich sesji, wyliczając na ich podstawie średnią ogólną. Zbudowana sieć komputerowa była oparta na przełączniku Fast Ethernet. Wszyscy klienci i klaster byli podłączeni bezpośrednio do poszczególnych portów tego przełącznika.