Test serwera HP rp8400

Nazwa serwera sugeruje, że mamy do czynienia z platformą RISC (p od PA-RISC) i urządzeniem przystosowanym do instalowania w szafie (r od rack), chociaż HP ma też w swojej ofercie wersję wolno stojącą serwera.

Nazwa serwera sugeruje, że mamy do czynienia z platformą RISC (p od PA-RISC) i urządzeniem przystosowanym do instalowania w szafie (r od rack), chociaż HP ma też w swojej ofercie wersję wolno stojącą serwera.

Doskonała wydajność za niemałą cenę

Test serwera HP rp8400
Jest to już rzeczywiście kawał sprzętu. Komputer, określany przez HP jako uniksowy serwer klasy średniej dla przedsiębiorstw, ma wysokość 75,5 cm (17U) i waży 160 kilogramów, tak że na plecach byłoby go raczej trudno przenieść. Produkt jest adresowany do tych przedsiębiorstw, które muszą dysponować wyjątkowo silnym serwerem i które jest stać na tak drogi sprzęt.

Wyobraźmy sobie duże centrum danych, które musi przetwarzać olbrzymią masę danych. Niejeden projektant takiego centrum zastanawia się, czy nie warto byłoby kupić kilka mocnych serwerów i zbudować wydajny klaster. Jednak sprawa nie jest taka prosta. Przede wszystkim aplikacje eksploatowane przez takie centrum trzeba przystosować do pracy w takim środowisku, a bieżąca eksploatacja i serwis techniczny klastra kosztują.

Istnieje rozwiązanie alternatywne - wystarczy kupić jeden duży wieloprocesorowy serwer. Są to z reguły duże i drogie serwery, oferujące wiele dodatkowych rozwiązań. Taki jest serwer HP rp8400.

Testowany serwer dysponował szesnastoma procesorami, a cały system można tak skonfigurować, że użytkownik ma do dyspozycji dwa w pełni funkcjonalne serwery. Producent instaluje w serwerze procesory PA-8700 RISC i dostarcza produkt razem z systemem operacyjnym HP-UX11i (Unix). Serwer nie należy do najtańszych. Testowany model kosztuje na rynku amerykańskim 605 tys. USD. Jeśli jednak użytkownikowi zależy na dużej wydajności, nie będą to stracone pieniądze.

Wyposażenie

Serwer rp8400 oferuje szereg dodatkowych i niezwykle przydatnych rozwiązań. Na pierwszym miejscu trzeba wymienić doskonałą skalowalność. Niewiele jest serwerów, które oferują w tej dziedzinie tak dopracowane rozwiązania. Testowany serwer był wyposażony w 16 procesorów i w 32 GB pamięci RAM, a użytkownik może podzielić komputer na dwie sprzętowe partycje, każda dysponująca własnymi kartami PCI i dyskami twardymi. Szkoda tylko, że po każdej rekonfiguracji partycji serwer trzeba zamknąć i uruchomić ponownie.

Serwer rp8400 jest oparty na wieloprocesorowej architekturze stosowanej w komputerach linii Superdome, której podstawową cechą jest wysoka dostępność. Układy CPU i pamięć RAM są instalowane na specjalnych kartach zwanych komórkami. Na każdej karcie można umieścić od dwóch do czterech procesorów i do 16 GB pamięci RAM. Każda komórka zawiera kontroler ze specjalnym procesorem, który łączy ze sobą wszystkie robocze procesory i układy RAM zainstalowane na karcie. Gdy kolejna karta zostanie zainstalowana w chassis, kontroler łączy kartę z krzyżową magistralą danych serwera.

Magistrala danych zarządza komórkami, systemem zasilania, szesnastoma gniazdami PCI i układami obsługującymi dyski twarde. Wszystkie gniazda PCI są podzielone na dwa banki (jeden bank to osiem gniazd PCI), a komunikację między nimi obsługuje specjalny kontroler. Każde gniazdo PCI jest podłączone do swojej własnej magistrali PCI, tak iż gniazda PCI są kompletnie od siebie odizolowane. Ponieważ każde gniazdo PCI ma swoją własną magistralę PCI, awaria jednej karty PCI nie ma wpływu na pracę innych kart, a karty nie muszą współdzielić jednego medium (i oferowanej przez to medium przepustowości).

Serwer rp8400 można podzielić na dwie partycje. Każda partycja ma do dyspozycji własne procesory, pamięć RAM i układy I/O. Partycjonowanie układów CPU i pamięci RAM (co pozwala utworzyć dwa oddzielne systemy) jest wykonywane na poziomie komórek. Znaczy to, że partycja nie może zawierać mniej elementów, niż znajduje się w jednej komórce. Budując partycje, użytkownik nie musi jednak używać wszystkich dostępnych komórek.

Każde rekonfigurowanie partycji wymaga ponownego uruchomienia serwera. Tak więc partycji nie można rekonfigurować w tzw. przelocie. Każdą partycję można jednak zamknąć, a druga partycja jest wtedy operacyjna i pracuje normalnie. Po zamknięciu partycji użytkownik może wymienić komórki wchodzące w jej skład - druga partycja pracuje w tym czasie normalnie.

Testowany serwer rp8400 był wyposażony w cztery karty (komórki), każda dysponująca czterema procesorami PA-8700. Na każdej karcie znajdowała się pamięć RAM o pojemności 8 GB (razem 32 GB). Serwer komunikował się z siecią przez dwa urządzenia: kartę PCI Gigabit Ethernet i przez wbudowany w system adapter Ethernet 10/100Base-T. HP nagrał system operacyjny na pierwszą partycję dyskową RAID 1 (zapis lustrzany), a druga partycja dyskowa RAID 1 była używana do zapisywania danych.

Metodologia testowania

Serwer testowano przy użyciu urządzenia Flamethrower (Antara), a testy umieszczono w dwóch grupach: w pierwszej były programy mierzące wydajność układów CPU, a w drugiej programy mierzące wydajność sieciową systemu.

W urządzeniu Flamethrower zainstalowano cztery karty. Każda karta dysponowała dwoma portami Ethernet 10/100Base-T. Każdy port podłączono do przełącznika Cisco 2948 (100 Mb/s; dupleks). Serwer podłączono do portu gigabitowego przełącznika Cisco 2948 (dupleks).

Przy testowaniu układów CPU tester Flamethrower generował żądania HTTP (pobieranie z serwera krótkich plików), używając przy transmitowaniu danych zabezpieczenia SSL (Secure Sockets Layer). Technologia SSL jest dość wymagająca względem procesorów (szyfrowanie wymaga intensywnego przetwarzania danych przez procesory). Aby jeszcze bardziej zwiększyć obciążenie układów CPU, wyłączono opcję, która normalnie pozwala klientowi i serwerowi wznawiać przerwane i wynegocjowane już transakcje SSL. Konfiguracja taka powoduje, że klient i serwer muszą otwierać nową sesję za każdym razem, gdy klient zgłasza żądanie pobrania pliku z serwera.

Zwiększając sukcesywnie liczbę transakcji SSL, monitorowano zachowanie się serwera. Mierzono liczbę wszystkich generowanych i prawidłowo obsłużonych transakcji SSL, szczególnie wtedy, gdy obciążenie procesorów zbliżało się do poziomu 100 proc. Gdy tester stwierdzał, że transakcje SSL zaczynają być wykonywane błędnie, liczbę transakcji zmniejszano do poziomu, przy którym błędy przestają występować. Pomiary wykonywano przez jedną minutę (w odstępach sekundowych), obliczając w kolejnym kroku średnią wydajność serwera.

Te same testy uruchamiano też na serwerze Compaq ProLiant 6400 (intelowskie procesory 500 MHz i pamięć RAM o pojemności 2 GB), po to, aby porównać wydajność obu serwerów. Aby porównanie było miarodajne, serwer rp8400 dysponował wtedy tylko jedną komórką, tak aby serwery były wyposażone w taką samą liczbę procesorów (cztery procesory RISC w serwerze Hewlett-Packard PA-8700 i cztery Intel Pentium III Xeon w serwerze ProLiant 6400).

Aby sprawdzić, czy zwiększenie liczby procesorów zainstalowanych w serwerze rp8400 powoduje, że wydajność całego systemu zwiększa się liniowo w takim samym stopniu, testy uruchamiano cztery razy (4, 8, 12 i 16 procesorów).

Testy webowe nie wykorzystujące technologii SSL pracowały w ten sposób, że wirtualni klienci skonfigurowani w urządzeniu Flamethrower generowali żądania pobrania z serwera dużych plików (10 MB). Testy weryfikowały, czy serwer jest w stanie wykorzystać w pełni przepustowość łącza, przez które komunikuje się z siecią. Testy sieciowe nie były niestety miarodajne, ponieważ tester nie był w stanie w pełni obciążyć serwera.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200