Wstęp
Wszystko zaczęło się od wpisu, który poczyniłem tydzień temu. Zafascynowała mnie koncepcja małego, bezgłośnego, energooszczędnego i taniego komputera, który mógłby pracować w systemie 24/7 i służyć np. za domowy NAS. Terminal HP Compaq T5520 okazał się być łatwo dostępny. Poniżej znajduje się krótki opis tego, czym jest taki terminal i jakie oferuje możliwości.
Cienki klient HP między popularnym modemem kablowym Motoroli, a routerem Linksysa. Wymiary terminala T5520: około 35 x 10 x 35 centymetrów.
Między bebechami
Na zakupiony przeze mnie model składa się procesor VIA Eden ESP 8000 (rdzeń „Nehamiah” 0,13 µm taktowany 800 MHz, 133 MHz FSB, 64 KiB L2), chipset VIA CLE266, 128 MiB SODIMM (przylutowane do płyty głównej), karta Ethernet 100 Mbit, karta graficzna S3 UniChrome (przywłaszcza sobie 16 MiB z RAM-u) oraz karta muzyczna. Całość dopełniają 4 gniazda USB 2.0, port szeregowy, równoległy, PS/2, VGA, LAN oraz wejście mikrofonowe i wyjście słuchawkowe. Mnie interesowały głównie porty USB, bo i tak większość z pozostałych zostałaby użyta jedynie podczas instalacji systemu operacyjnego. W tym momencie warto od razu odpowiedzieć na pytanie, gdzie taki system można umieścić. Całość dostarczana jest z 64 MB pamięci flash (zawiera ona system Windows CE 5.0) podpiętej przez 2,5" złącze ATA do płyty głównej. Jak łatwo się domyślić, jedną z atrakcji jest możliwość wymienienia jej na 2,5'' dysk twardy z interfejsem ATA - jedyne o czym należy pamiętać to zdobycie odpowiedniej tasiemki IDE (złącza żeńskie-żeńskie). Warto jeszcze wspomnieć, że o ile sam CPU na płycie głównej nie jest zbyt wydajny to całkiem nieźle sprawdza się w przypadku szyfrowania danych cipherem AES ze względu na sprzętowe wsparcie szyfrowania symetrycznego (tzw. VIA Padlock). Przejdźmy teraz do samej kwestii instalacji właściwego systemu operacyjnego.
Instalacja GNU/Linuksa
Pierwsze, co zrobiłem po otrzymaniu sprzętu to jego rozkręcenie oraz wyjęcie na kilka sekund baterii z płyty głównej zasilającej CMOS. W przypadku, gdyby ekran konfiguracji BIOS-u był zabezpieczony hasłem pozwoliłoby mi to na zaoszczędzenie czasu poprzez wcześniejsze usunięcie go w ten sposób. Przy okazji przyjrzałem się wnętrzu urządzenia i sprawdziłem, czy wszystkie kondensatory są w normie. Po złożeniu i podłączeniu peryferiów uruchomiłem terminal trzymając podczas startu klawisz F9 aż do momentu, gdy usłyszałem dźwięk z wbudowanego głośniczka. To oznaczało, że konfiguracja Windowsa CE powróciła do ustawień fabrycznych i będę mógł się z nim nieco pobawić. Zapewniam jednak, że 5 minut w zupełności na to wystarcza. Później pozostało jedynie przejść do konfiguracji BIOS-u i ustawić odpowiednią kolejność bootowania. W moim przypadku koncepcja była prosta.
Nie miałem zamiaru bawić się zbyt długo, dlatego uznałem, że skorzystam z Ubuntu 9.10 Server Edition dostępnego na płycie CD oraz mojego napędu DVD znajdującego się w kieszeni z interfejsem USB. Wbudowany w terminal dysk flash miał posłużyć jako miejsce składowe dla jądra (/boot) oraz GRUB-a, a podpięty przeze mnie 4 GB dysk jako miejsce dla całej reszty systemu (/ oraz swap). Jak pomyślałem tak też zrobiłem. W trakcie instalacji zaliczyłem „freeze”, więc szybko zmieniłem początkowe założenia. Ubuntu zostało wyparte przez Debiana „Lenny” 5.04 w wersji „network install”. I to była właściwa decyzja. Debian kolejny raz uratował mi odwłok. Po długotrwałej instalacji (30 minut? 60?) dorzuciłem jeszcze na pokład serwer SSH i wyłączyłem system. To był czas na przejście w „tryb bezgłowy” i zarządzanie z poziomu innego komputera. Kilka wpisów w domowym DNS-ie i Thor (mitologia nordycka rządzi) był gotowy do działania.
Serwer SSH to nie wszystko. Docelowo terminal ten ma służyć do kilku celów, które spełniać mają serwery: NTP, CUPS, NFS, Samba, czy też webowy interfejs Transmission (klient BitTorrenta). Wszystkie dane, które nie są systemem operacyjnym i jego plikami konfiguracyjnymi muszą być również szyfrowane AES-em. Oznacza to m.in. wykorzystanie dysku 2.5" w kieszeni USB oraz DM-Crypta, który do najmniej zasobożernych rozwiązań nie należy. A jak wygląda kwestia zasobów po czystej instalacji systemu? Brak obciążenia procesora, około 16 MiB pamięci (z pominięciem buforów) pożartej przez system i podstawowe usługi oraz niewielka konsumpcja przestrzeni dyskowej. Jest to indywidualna sprawa, ale warto o niej wspomnieć. System wstaje około minuty licząc od zerwania połączenia SSH po wydaniu polecenia reboot do momentu, kiedy możliwe jest ponowne zalogowanie poprzez SSH. Czas na prawdziwą pracę! Tj. zaraz po upgrade do obecnego wydania testing Debiana, czyli przyszłego „Squeeze”.
Wydajność
To, co miało być głównym przeznaczeniem tego miniserwera to przede wszystkim dostęp do zaszyfrowanego (DM-Crypt, LUKS i cipher AES) dysku z wykorzystaniem NFS. Zacznijmy zatem od samego szyfrowania oraz od tego, jak sprawdza się terminal w takich zastosowaniach. Do testów wykorzystałem polecenie hdparm -t. Na początku zastosowałem to polecenie kilkukrotnie na dysku, który nie został poddany szyfrowaniu:
zal@thor:/media$ sudo hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 94 MB in 3.01 seconds = 31.23 MB/sec
Całkiem niezły wynik, najprawdopodobniej maksymalny możliwy do uzyskania transfer w przypadku wykorzystania USB 2.0. Następnie wykonałem standardowe polecenia cryptsetup mające na celu stworzenie utworzenie i zmapowanie zaszyfrowanej partycji po czym wykonałem na niej test z hdparm. Rezultat jest mało zadowalający:
zal@thor:/media$ sudo hdparm -t /dev/mapper/XXX
/dev/mapper/XXX:
Timing buffered disk reads: 22 MB in 3.28 seconds = 6.70 MB/sec
A teraz najważniejsze. Ponowiłem ww. operację ładując wcześniej do pamięci moduł padlock-aes dzięki któremu możliwe jest wykorzystanie wsparcia sprzętowego (procesor z rozwiązaniem VIA Padlock) dla szyfrowania przy pomocy ciphera AES. Oto i rezultat:
zal@thor:/media$ sudo hdparm -t /dev/mapper/XXX
/dev/mapper/XXX:
Timing buffered disk reads: 62 MB in 3.02 seconds = 20.51 MB/sec
Wygląda to zdecydowanie lepiej. Niestety, nie byłem w stanie określić obciążenia procesora w tym momencie. Wygląda jednak na to, że nawet na takim sprzęcie szyfrowanie całego dysku może mieć sens.
Reszta testów (m.in. dot. obciążenia procesora podczas przesyłu danych oraz prędkości przesyłania danych) będzie miała sens dopiero, gdy złożę odpowiednie środowisko testowe. W obecnej chwili uważam, że zbyt duży wpływ na wynik takich badań może mieć router (działający w oparciu o DD-WRT) pośredniczący w przepływie danych oraz kwestia tego, że jeden z komputerów przesyła dane za pośrednictwem sieci bezprzewodowej. Gdyby jednak ktoś chciał przeczytać to, co uzyskałem korzystając z ww. środowiska może to zrobić zaglądając w kod XHTML niniejszego wpisu i szukając najdłuższego komentarza w nim zawartego. Wskazówka, znajduje się on pod niniejszym paragrafem.
Podsumowanie
Niniejszy wpis powstał zaledwie w ciągu kilku godzin od momentu uruchomienia przeze mnie opisywanego terminala. Pomimo tego, że sprzętem jestem zachwycony to należy mieć na uwadze to, że tak krótki okres jest niewystarczający do tego by móc polecić tego cienkiego klienta komukolwiek. Dopiero po miesiącu, czy też dwóch, użytkowania mogą wyjść na jaw jego największe wady, jak i zalety. Obecnie uważam, że sprzęt ten ma naprawdę duży potencjał i może stanowić konkurencję dla samodzielnie składanych, domowych NAS-ów opartych o stare podzespoły. Nie jest demonem prędkości, ale jest tani, cichy i energooszczędny.
Ciąg dalszy zapewne nastąpi w bliżej nieokreślonej przyszłości. Mam zamiar wykonać bardziej precyzyjne i wiarygodne testy dot. wydajności.