Cube - Studencki Projekt Heterogenicznego Klastra Obliczeniowego

Cube - Studencki Projekt Heterogenicznego Klastra Obliczeniowego

Cube - Studencki Projekt Heterogenicznego
Klastra Obliczeniowego
Adam Mikuta, Piotr Rak, Adam Sawicki, Przemysław Sowa, Radosław Stawiarski
Wydział Inżynierii Mechanicznej i Informatyki
Kierunek Informatyka, Rok II
Streszczenie
Referat dotyczy projektu heterogenicznego klastra obliczeniowego Cube, który tworzony jest od niedawna przez grup˛e studentów Politechniki Cz˛estochowskiej.
Przedstawia podstawowe założenia projektu – heterogeniczność oraz zapewnienie testowego środowiska klastrowego zbudowanego z różnorodnych komputerów pracujacych
˛
pod kontrola˛ różnych systemów operacyjnych. Opisuje architektur˛e sprz˛etowoprogramowa˛ klastra oraz obecny stan prac. Wskazuje także jego potencjalne zastosowania.
1
Wst˛ep
Wraz ze wzrostem rozmiaru analizowanych przez naukowców problemów rosło zapotrzebowanie na moc obliczeniowa.˛ Pierwotnie do przetwarzania dużych ilości danych używano superkomputerów. Niestety szybko okazały si˛e one zbyt kosztowne nawet dla dużych
instytucji badawczych. Gigantyczne koszty zakupu oraz utrzymania takich systemów stanowiły barier˛e rozwoju w wielu dziedzinach nauki [13]. Rozwiazaniem
˛
tego problemu
okazał si˛e być system Linux oraz zwykłe, tanie komputery osobiste.
Wszystko to stało si˛e możliwe za sprawa˛ grupy naukowców pod kierownictwem Thomasa Sterlinga [1], którzy jako pracownicy NASA [2] próbowali w 1994 roku znaleźć tani
sposób na rozwiazywanie
˛
wielkich układów równań.
Eksperyment nazwany Beowulf Project [3] miał sprawdzić, czy grupa zwykłych pecetów pod kontrola˛ systemu Linux może funkcjonować jak superkomputer. Przedsi˛ewzi˛ecie
odniosło sukces i zapoczatkowało
˛
szerokie wykorzystanie tego typu klastrów na całym
świecie. Systemy te dzi˛eki niewielkim kosztom budowy sa˛ dost˛epne nawet dla małych
organizacji. Wiele firm oferuje komercyjne rozwiazania
˛
tego typu, które daja˛ si˛e łatwo
dostosować do własnych potrzeb. Możliwe jest nawet zbudowanie klastra Beowulf (jak
si˛e je nazywa) praktycznie za darmo, wykorzystujac
˛ posiadane już maszyny. Tak właśnie
jest w przypadku systemu przedstawionego w poniższej pracy.
1
2
Architektura klastrów Beowulf
Najcz˛eściej poszczególne w˛ezły systemu klastrowego składaja˛ si˛e z komputerów wyposażonych w szybkie procesory oraz duża˛ pami˛eć operacyjna.˛ Maszyny te połaczone
˛
sa˛
szybkimi magistralami i posiadaja˛ spora˛ ilość pami˛eci podr˛ecznej.
W wi˛ekszości przypadków komputery łaczy
˛
si˛e ze soba˛ tradycyjna˛ siecia˛ Ethernet[4]
o przepustowości od 100 megabitów na sekund˛e do 1 gigabita na sekund˛e. Zdarza si˛e,
że parametry te nie sa˛ wystarczajace.
˛ W takiej sytuacji wykorzystuje si˛e komercyjne rozwiazania
˛
sieciowe. Najpopularniejsze z nich to Myrinet[5] oraz Scali[6], a także nowo powstała architektura Infinibend[7] Zwi˛ekszaja˛ one przepustowość oraz zmniejszaja˛ opóźnienie potrzebne do otwarcia kanału transmisyjnego, jednak znacznie zwi˛ekszaja˛ koszty
budowy klastra.
Cz˛esto wyróżnia si˛e jeden z komputerów systemu i łaczy
˛
go z siecia˛ zewn˛etrzna.˛ W˛ezeł ten nazywany głównym lub dost˛epowym jest ogniwem łacz
˛ acym
˛
klaster ze światem.
Rozwiazanie
˛
takie pozwala uniknać
˛ zb˛ednego ruchu sieciowego generowanego przez "obce" maszyny oraz zwi˛eksza bezpieczeństwo, ponieważ wszelka autoryzacja dokonywana
jest tylko na tym jednym komputerze.
Najwi˛ekszym wyzwaniem przy budowie klastrów Beowulf jest instalacja oprogramowania oraz codzienna administracja poszczególnymi maszynami. Możliwych jest wiele
podejść, jednak najcz˛eściej stosowane to tzw. single image system. W podejściu tym, każdy w˛ezeł klastra jest dokładna˛ kopia˛ każdego innego. Dotyczy to zarówno systemu operacyjnego jak i oprogramowania użytkowego, np. kompilatorów czy bibliotek, katalogi
domowe udost˛epniane sa˛ zaś za pomoca˛ sieciowych systemów plików, np. NFS.
Podstawowym zagadnieniem zwiazanym
˛
z klastrami jest podział czasu klastra pomi˛edzy użytkowników. R˛eczne przyznawanie dost˛epu do systemu jest praktycznie niewykonalne, przy czym należy pami˛etać, że każda aplikacja ma inne wymogi dotyczace
˛ używanych zasobów, a to oznacza że optymalne wykorzystanie klastra jest zadaniem niezwykle
trudnym. Czas procesora jest bardzo kosztowny dlatego na przestrzeni lat opracowano
oprogramowanie, które bierze na siebie ci˛eżar zarzadzania
˛
klastrem.
Programy tego typu nosza˛ nazw˛e menedżerów zadań, a ich praca polega na automatycznym uruchamianiu zadań i planowaniu kolejności uruchamiania tak, aby optymalnie wykorzystać dost˛epne zasoby klastra. Najpopularniejszymi systemami tego typu sa˛
OpenPBS[8] i Sun Microsystems’s Grid Engine[9]. Oba programy dost˛epne sa˛ za darmo wraz z kodem źródłowym oraz moga˛ działać na wielu systemach linuksowych oraz
uniksowych.
Oprogramowanie tego rodzaju składa si˛e z trzech elementów: serwera zadań (ang.
job server), wykonawcy zadań (ang. job executor), oraz planisty zadań (ang. job scheduler). Dodatkowym elementem jest zestaw poleceń do zgłaszania i zarzadzania
˛
zadaniami,
cz˛esto dost˛epny jako wygodne narz˛edzia graficzne lub w postaci portalu WWW. Serwer
zadań udost˛epnia mechanizmy do tworzenia, modyfikowania oraz wstawiania do kolejki
zlecanych prac. Obowiazkiem
˛
wykonawcy zadań jest faktyczne uruchamiania programów,
kiedy zezwoli na to planista. Planista natomiast decyduje o terminie i parametrach wykonania poszczególnych zadań, uwzgl˛edniajac
˛ przy tym cz˛esto bardzo skomplikowana˛
polityk˛e zarzadzania
˛
klastrem.
Głównym przeznaczeniem klastrów Beowulf jest uruchamianie aplikacji równoległych i rozproszonych. Wiele badanych współcześnie problemów jest zbyt dużych dla
tradycyjnych sekwencyjnych komputerów. Dzieje si˛e tak, gdyż post˛ep nauki jest znacz2
nie szybszy niż rozwój sprz˛etu ograniczony prawem Moora. Z roku na rok rośnie ilość
danych które naukowcy chca˛ przetwarzać oraz wzrasta złożoność analizowanych modeli.
3
Klaster Cube – założenia
Klaster b˛edacy
˛ przedmiotem poniższej pracy powstał w Instytucie Informatyki Teoretycznej i Stosowanej Politechniki Cz˛estochowskiej z inicjatywy mgr inż. Jarosława Żoli [12]
oraz czwórki studentów. Podstawowym założeniem było zbudowanie taniego systemu z
dost˛epnych w IITiS, wycofanych z użycia komputerów. Klaster ten miał być czysto akademickim eksperymentem, to znaczy nie starano si˛e stworzyć konkurencji dla istniejacych
˛
na uczelni systemów, a jedynie zbudować nietypowy klaster spełniajacy
˛ rol˛e interesuja˛
cego środowiska testowego i badawczego.
Z tego powodu zdecydowano si˛e na całkowicie heterogeniczna˛ architektur˛e. Zastosowano różne rozwiazania
˛
sprz˛etowe oraz programowe, dodatkowo wprowadzono kolejne
urozmaicenie w postaci kaskadowego łaczenia
˛
sieci klastra.
Klaster ten ma służyć jako narz˛edzie wspomagajace
˛ rozwój i analiz˛e oprogramowania równoległego tworzonego w IITiS. Budowany jest z myśla˛ o testowaniu algorytmów
rozproszonych oraz wszelakich aplikacji równoległych pisanych w oparciu o standard
MPI [10]. Niektóre z planowanych zastosowań to badania nad dynamicznym podziałem
zadań, równoważeniem obciażenia,
˛
rozproszonymi bazami danych. Inne rozważane dziedziny to wykorzystanie klastra do uruchamiania testowych aplikacji z dziedziny bioinformatyki, a w przyszłości testowanie aplikacji Gridowych [14]. Duży potencjał drzemie
również w zastosowaniach bardziej ogólnych: testowanie przenośności czy stabilności
przed wdrożeniem na wi˛ekszy system, gdzie czas procesora jest niezwykle kosztowny.
4
Architektura klastra Cube
Klaster docelowo ma si˛e składać z 15 w˛ezłów. Ze wzgl˛edu na heterogeniczność systemu
poszczególne komputery mocno si˛e różnia.˛ Od strony sprz˛etowej zróżnicowanie to polega
na zastosowaniu różnych architektur oraz parametrów poszczególnych jednostek.
Trzynaście maszyn to zwykłe komputery klasy IBM PC. Najsłabsza z nich posiada
procesor o cz˛estotliwości zaledwie 133 MHz i 64 MB pami˛eci RAM. Została ona przeznaczona na w˛ezeł główny, który nie wykonuje obliczeń a jedynie zarzadza
˛
całym systemem. Kolejne dwanaście maszyn to komputery o procesorach od Intel Celeron 333 MHz
i 128 MB RAM do Intel Pentium III 500 MHz i 256 MB RAM.
W skład klastra wchodzi również komputer o architekturze SMP z dwoma jednostkami Intel Celeron 500 MHz oraz 768 MB RAM. Najbardziej odmienna˛ maszyna˛ jest
posiadany przez nas sprz˛et produkcji Sun Microsystems z 64–bitowym procesorem Ultra
Sparc 300 MHz oraz 128 MB RAM.
Maszyny posiadaja˛ różne dyski twarde jakkolwiek każdy z w˛ezłów dysponuje co najmniej sześcioma gigabajtami pami˛eci masowej przeznaczonymi na system operacyjny
oraz dwoma gigabajtami w postaci osobnej partycji dedykowanej do przechowywania
wyników obliczeń.
W klastrze Cube również warstwa sieciowa została zrealizowana nietypowo. Ze wzgl˛edu na niski koszt budowy, który był priorytetem, nie można było pozwolić sobie na rozwiazania
˛
dedykowane dla tego typu systemów jak na przykład Myrinet. Zastosowano tra3
dycyjna˛ sieć Fast Ethernet, jednak w˛ezły nie sa˛ połaczone
˛
jak w wi˛ekszości tego typu
sprz˛etu. Celowo utworzone zostało "waskie
˛
gardło" komunikacji. Osiagni˛
˛ eto to dzielac
˛
w˛ezły na dwie grupy po siedem oraz osiem komputerów. Każda grupa została podpi˛eta
do osobnego switcha, a urzadzenia
˛
te połaczono
˛
mi˛edzy soba˛ pojedynczym kablem.
Heterogeniczność tworzonego systemu przejawia si˛e również w warstwie oprogramowania. Osiem w˛ezłów pracuje pod kontrola˛ systemu Debian Linux [15], sześć używa
systemu FreeBSD [16] natomiast komputer Sun pracuje pod kontrola˛ Sun Solaris [17].
Tak duże zróżnicowanie całego klastra wymaga odmiennego modelu administrowania
systemem. Nie jest możliwe zastosowanie modelu SIS (Single Image System), w którym
to tworzymy obraz dysku z pierwszego w pełni skonfigurowanego w˛ezła, a nast˛epnie
przenosimy go na pozostałe. Nie pozwalaja˛ na to ani różnice w fizycznej konfiguracji
komputerów ani użyte różne systemy operacyjne.
W tej sytuacji opracowano specjalny zestaw skryptów. Dziela˛ si˛e one na dwie kategorie: instalacyjne oraz administracyjne. Pierwsze z nich pozwalaja˛ na w pełni zautomatyzowana˛ instalacj˛e systemu operacyjnego, drugie natomiast służa˛ do uruchamiania poleceń
równocześnie na wszystkich badź
˛ wybranych w˛ezłach systemu oraz na kontrol˛e wyników.
Jeżeli chodzi o kwestie bezpieczeństwa to klaster komunikuje si˛e ze światem zewn˛etrznym jedynie za pośrednictwem jednego w˛ezła, zwanego dost˛epowym (lub głównym). Dokonuje on autoryzacji użytkowników poprzez protokół SSH na podstawie ich
kluczy publicznych, takie samo rozwiazanie
˛
zastosowano na poszczególnych w˛ezłach.
Do zarzadzania
˛
zasobami klastra użyto oprogramowania Torque Cluster Manager [18]
oraz Maui Scheduler [19]. Wybór tego drugiego podyktowany był jego ogromnymi możliwościami. Maui to zaawansowane oprogramowanie przeznaczone dla wielce wydajnych
platform obliczeniowych. Podejmuje decyzje: gdzie, kiedy oraz jak uruchomić zakolejkowane zadania opierajac
˛ si˛e na zaawansowanej polityce zarzadzania,
˛
priorytetach oraz
ograniczeniach systemowych. Udost˛epnia rozległa˛ administracj˛e zasobami systemowymi,
zapewnia rezerwacj˛e zadań oraz oferuje rozbudowany mechanizm logowania i monitorowania wykorzystania systemu.
5
Podsumowanie
W referacie przedstawiony został projekt studenckiego, heterogenicznego klastra obliczeniowego Cube, który powstaje w IITiS. Projekt jest w ciagłej
˛
realizacji w czasie wolnym
od zaj˛eć.
W przyszłości planuje si˛e wykorzystanie klastra do realizacji wielu projektów naukowych takich jak na przykład rozproszone bazy danych z replikacja˛ czy @Home Computing, ponieważ ze wzgl˛edu na heterogeniczność nadaje si˛e on idealnie do testów tego typu
aplikacji.
Jednym z ciekawszych zagadnień jest dokładna analiza wydajności za pomoca˛ zestawów testowych Linpack [20] z rankingu TOP500 Supercomputer Sites [21] która mamy
nadziej˛e pokaże czy Cube miał szans˛e kiedykolwiek znaleźć si˛e na tej elitarnej liście.
Wi˛ecej informacji na temat klastra przedstawionego w tej pracy można znaleźć na
oficjalnej stronie projektu: http://icis.pcz.pl/~cube.
4
Literatura
[1] Thomas Sterling - Strona domowa, http://www.cacr.caltech.edu/~tron
[2] National Aeronautics and Space Administration, http://www.nasa.gov
[3] Beowulf Project, http://www.beowulf.org
[4] Ethernet - IEEE 802.3
[5] Myricom Myrinet, http://www.myri.com/myrinet/
[6] Scali, http://www.scali.com
[7] Intel
InfiniBand
infiniband/
Architecture,
http://www.intel.com/technology/
[8] Open Portable Batch System, http://www.openpbs.org
[9] Sun Microsystems’s Grid Engine http://gridengine.sunsource.net
[10] MPI: A Message-Passing Interface Standard, http://www-unix.mcs.anl.gov/
mpi/mpi-standard/mpi-report-1.1/mpi-report.htm
[11] Parallel Virtual Machine, http://www.csm.ornl.gov/pvm/pvm_home.html
[12] Jarosław Żola - Strona domowa, http://icis.pcz.pl/~zola
[13] J. Błażewicz, K. Ecker, B. Plateau, D. Trystram, Handbook on Parallel and Distributed Processing, Springer–Verlag 2000
[14] I. Foster, C. Kesselman, The Grid 2: Blueprint for a New Computing Infrastructure,
Morgan Kaufmann 2003
[15] Debian Linux, http://www.debian.org
[16] The FreeBSD Project, http://www.freebsd.org
[17] Sun Solaris, http://www.sun.com/software/solaris
[18] Torque Resource Manager, http://www.clusterresources.com/products/
torque/
[19] Maui Cluster Scheduler, http://www.clusterresources.com/products/maui/
[20] The Linpack Benchmark, http://clusters.top500.org/lists/linpack.php
[21] TOP500 Supercomputer Sites, http://clusters.top500.org
5
Rys. 1: Architektura klastra Cube.
Rys. 2: Logo klastra Cube.
6