Katedra Inżynierii Oprogramowania

Transkrypt

1 Politechnika Gdańska WYDZIAŁ ELEKTRONIKI TELEKOMUNIKACJI I INFORMATYKI Katedra Inżynierii Oprogramowania Imię i nazwisko dyplomanta: Nr albumu: Rodzaj studiów: Kierunek studiów: Wojciech Basałaj 78421/ETI Dzienne Informatyka Praca magisterska Wykonanie dystrybucji systemu Linux dla klastrowych stacji bezdyskowych Kierujący pracą: Konsultant: dr hab. inż. Jerzy Kaczmarek mgr inż. Michał Wróbel Zakres pracy: W ramach niniejszej pracy skonstruowano dystrybucję systemu operacyjnego klastrowy cdlinux.pl opartego o jądro GNU/Linux oraz o oprogramowanie, które w większej części wchodzi w skład dystrybucji cdlinux.pl. System operacyjny klastrowy cdlinux.pl uruchamiany jest na komputerze PC całkowicie z jednej płyty CD-ROM i pozwala na automatyczne stworzenie klastra obliczeniowego złożonego z danego komputera PC oraz wszystkich komputerów obecnych w jego sieci lokalnej. W części pisemnej przedstawiono podłoże teoretyczne tematu klastrów oraz szczegółowy opis uruchamiania i budowy systemu klastrowy cdlinux.pl. Część praktyczną stanowi realizacja projektu w postaci płyty z działającym systemem operacyjnym oraz wykonanie testów wydajności ukazujących zalety i wady zaprezentowanego rozwiązania, jak również porównanie skalowalności klastra z klastrami profesjonalnymi. Gdańsk, 2005

2 Spis treści 1. Wstęp Porównanie systemów Linux i Microsoft Windows Dystrybucje uruchamiane z wymiennych nośników Dystrybucja cdlinux.pl Dystrybucja klastrowy cdlinux.pl Środowisko klastrowe openmosix Klastry obliczeniowe Podstawowe pojęcia Klasyfikacja klastrów Typy budowy klastrów HPC NUMA DSM MPI oraz PVM Środowisko openmosix jako klaster HPC Single System Image Perspektywa procesu Perspektywa użytkownika Perspektywa systemu plików openmosix File System Konfiguracja openmosixa Konfiguracja statyczna Konfiguracja dynamiczna automatyczne odkrywanie Oprogramowanie monitorujące openmosixview Zdalne zarządzanie węzłami Główne okno programu Zarządzanie procesami przez openmosixprocs Statystyki Graficzny monitoring i zarządzanie - openmosixmigmon Wykorzystanie środowiska openmosix w klastrowym cdlinux.pl Uruchamianie systemu operacyjnego Uruchamianie kontrolera klastra

3 Wczytanie programu ładującego Linuxa El Torito SYSLINUX Uruchomienie jądra Linuxa Przygotowanie systemów plików Konfigurator yahade Uruchomienie rozszerzeń względem cdlinux.pl Uruchamianie węzła klastra Środowisko PXE (Pre Execution Environment) Nawiązanie komunikacji węzła z kontrolerem klastra Opis usługi Dynamic Host Configuration Protocol (dhcp) Opis usługi Trivial File Transfer Protocol (tftp) PXELINUX druga odsłona SYSLINUXa Uruchomienie jądra z nfsroot Opis protokołu NFS Zakończenie inicjacji węzła Budowa systemu operacyjnego Doinstalowane oprogramowanie Przygotowanie jądra Wsparcie dla NFS w cramfs Opcje kompilacji jądra Linuxa Przygotowanie programu ładującego ISOLINUX Przygotowanie systemów plików Narzędzia openmosix Zmiany dokonane przez yahade Usunięcie niepotrzebnego oprogramowania System plików eksportowany do węzła Stworzenie płyty z dystrybucją Przygotowanie węzła do uruchomienia przez sieć Gotowy produkt Testy wykonanego systemu Test przy pomocy POVRAY w oparciu o PVM Test na trzech węzłach o różnej wydajności

4 Test na węzłach o takiej samej wydajności Pomiar prędkości uruchamiania Renderowanie mało skomplikowanej grafiki Renderowanie bardziej skomplikowanej grafiki Testy w oparciu o MPI Test przy pomocy POVRAY w oparciu o MPI Porównanie klastrowego cdlinux.pl do klastrów Top Podsumowanie Bibliografia Załączniki Spis ilustracji Spis tabel Spis diagramów

5 1. Wstęp Linux jest nowoczesnym systemem operacyjnym, który zdobywa coraz szersze kręgi użytkowników na całym świecie informatycznym. Jest ceniony przede wszystkim za swoją politykę dotyczącą oprogramowania większość jest rozprowadzana na licencji GNU General Public License, której głównym przesłaniem jest darmowe rozpowszechnianie oprogramowania w postaci kodu źródłowego. Kolejną zaletą jest jego wysoka jakość ukazująca się przez wydajność oraz stabilność. Obecnie najczęściej używanymi systemami operacyjnymi na stacjach roboczych są produkty firmy Microsoft serii Windows, jednak nie wszyscy użytkownicy komputerów się na nie decydują Porównanie systemów Linux i Microsoft Windows System operacyjny Linux nie jest łatwy do zainstalowania na stacji roboczej przez przeciętnego użytkownika komputera PC. Problemy wynikają przede wszystkim z odmienności samego systemu od Microsoft Windows. Poniżej zestawiono kilka różnic wpływających ujemnie na łatwość instalacji Linuxa. Podstawowym problemem dla wielu jest inny układ dysków twardych i ich partycji. W systemach operacyjnych DOS oraz Windows (poza serią NT i pochodnymi) partycje wszystkich dysków fizycznych dostępne są w postaci pojedynczej listy i identyfikowane są poprzez kolejne litery alfabetu (A:, B:, C:,...), natomiast w Linuxie partycje dostępne są poprzez nazwę zawierającą w sobie numer dysku twardego oraz partycji względem tego dysku. Obydwa rozwiązania mają swoje wady i zalety. Rozwiązanie firmy Microsoft cechuje prostota (jeżeli istnieje jeden dysk twardy w komputerze, jego pierwsza partycja będzie zawsze dostępna pod nazwą C:), jednak w przypadku częstej zmiany konfiguracji dyskowej komputera, rodzą się problemy. Druga partycja dysku, do tej pory dostępna pod nazwą D:, po dołożeniu drugiego dysku do komputera będzie dostępna pod nazwą E:, natomiast jej miejsce zajmie pierwsza partycja dołożonego dysku. W rozwiązaniu linuxowym administrator musi więcej zwrócić uwagi na poprawne zaadresowanie partycji w systemie (nazwa identyfikująca partycję zawiera numer dysku oraz numer partycji względem dysku), jednak dzięki temu nazwa ta nie zmienia się po dostawieniu, bądź usunięciu innych dysków do/z systemu komputerowego. 5

6 Nowością w Linuxie względem Windows jest większa liczba partycji do przygotowania. Instalując system Windows należy jedynie wskazać, na której partycji ma być zainstalowany system. Podczas instalacji systemu Linux, użytkownik stoi przed zadaniem określenia partycji podstawowej, ewentualnie partycji przeznaczonych na części drzewa katalogów (np. /usr, /home, etc.) oraz tzw. partycji wymiany, która składa się wraz z pamięcią RAM na pamięć wirtualną systemu operacyjnego. Dodatkowo, występujące w systemie Linux narzędzia służące do zarządzania dyskami twardymi oferują więcej możliwości, niż ich odpowiedniki z innych popularnych systemów. Zwiększa to zagubienie świeżego użytkownika. Instalację systemu operacyjnego Linux cechuje większa elastyczność w doborze komponentów. Wprawdzie w większości dystrybucji tegoż systemu operacyjnego dla użytkownika przygotowanych jest kilka zestawów komponentów, co upraszcza wybór, jednak bogaty asortyment dostarczanego oprogramowania powoduje, iż domyślna instalacja może zajmować bardzo dużą przestrzeń dysku twardego. Skłania to użytkowników do eksperymentowania z doborem komponentów do instalacji, co może spowodować frustrację przez nieuruchamiający się, bądź wybrakowany i przez to nieużywalny systemem operacyjny. Z drugiej strony, dla doświadczonych użytkowników dowolność ta jest bardzo pożądana. Innym problemem jest niewielka jeszcze ilość użytkowników Linuxa, która dobrze opanowała sztukę jego instalacji. O ile w obliczu problemów z instalacją systemu Windows możemy liczyć na pomoc ze strony większości znajomych posiadających komputery (w domyśle: używających Windowsa), o tyle spotkawszy się z problemami przy instalacji Linuxa musimy sobie często poradzić sami, bądź szukać odpowiedzi w Internecie, czy prosić o pomoc lokalnego guru Linuxa, który nie zawsze ma ochotę udzielać pomocy. Wyżej opisane wady mogą powodować problemy tylko na początku użytkowania systemu operacyjnego. W rzeczywistości są to zalety, które zatrzymują przy Linuxie osoby, które raz go wypróbowały Dystrybucje uruchamiane z wymiennych nośników Przedstawione wyżej powody zrodziły potrzebę zaistnienia dystrybucji systemu Linux, które albo wyeliminują problemy związane ze zbyt dużą dowolnością przy instalacji, bądź wyeliminują całkowicie instalację. W odpowiedzi powstały dystrybucje systemu Linux 6

7 mieszczące się całkowicie na jednym egzemplarzu nośnika (ewentualnie na dwóch w przypadku dyskietek 1.4MB), które uruchomione z tego nośnika stawały się działającym systemem operacyjnym. Jedną z takich dystrybucji Linuxa była PocketLinux [PKTLNX]. Użyto sformułowania była, gdyż obecnie najświeższą wersją jest 2.51, która ukazała się w 1998 roku. Oparta jest o jądro Linuxa w wersji ( w przypadku wersji -fix-3), obsługuje szereg kart sieciowych, modem, popularne systemy plików (łącznie z vfat znanym z produktów serii Windows firmy Microsoft), standardowe porty szeregowe (równoległe nie są obsługiwane), mysz na porcie PS/2. Posiada bogate oprogramowanie, jak na tak niewielką objętość, które umożliwia automatyczną konfigurację i diagnozę sieci, edycję plików, zdalną pracę, zarządzanie komputerem. Polecenie help udziela krótkiego, lecz treściwego wyjaśnienia dla początkujących. Istnieją niewielkie, jak na obecne warunki, wymagania pamięciowe, czyli około 7 megabajtów pamięci operacyjnej oraz pamięć w postaci pliku, czy partycji wymiany, które to pliki system potrafi sam automatycznie tworzyć na partycjach, a partycje wymiany potrafi wykrywać. Od czasów świetności PocketLinuxa rozwinęła się technologia, popularne nośniki zyskały na pojemności, dostępności, niezawodności. Obecnie standardowym wyposażeniem każdego komputera jest napęd CD-ROM, czyli urządzenie odczytujące nośnik w postaci dysku optycznego bez możliwości zapisu. Pojemności największych płyt CD-ROM sięgają 800MB, co jest wielkością prawie 600 razy większą, niż pojemność dawniej popularnej dyskietki 1.4MB. Z biegiem czasu oprogramowanie zwiększało swoją objętość, zatem i dystrybucje Linuxa, nawet te nieinstalowane, wymagały coraz większych pojemności nośników. Mając do dyspozycji podłoże technologiczne, powstały dystrybucje systemu operacyjnego Linux uruchamiane z CD-ROMu. Ten typ dystrybucji nosi nazwę live CD. Uruchamianie systemu z CD-ROMu przebiega podobnie, jak uruchamianie z dyskietki i jest opisane szerzej w rozdziale dotyczącym uruchamiania systemu będącego przedmiotem pracy. 7

8 Istnieje kilka projektów mających na celu wytworzenie dystrybucji Linuxa uruchamianej z CD-ROMu. Przykładami są: Knoppix Eagle Linux Phrealon cdlinux.pl 1.3. Dystrybucja cdlinux.pl Cdlinux.pl [CDLINUXPL] jest systemem operacyjnym, o który oparta jest niniejsza praca. Został on wytworzony jako przedmiot pracy dyplomowej Michała Wróbla pt. Modyfikacja systemu Linux dla stacji bezdyskowych [WRÓB]. System ten mieści się na jednej płycie CD-ROM, z której można go bezpośrednio uruchomić bez instalacji na dysku twardym. W trakcie pisania niniejszej pracy, cdlinux.pl rozprowadzany jest w dwóch wersjach: duży i mały. Wersja duży zajmuje całą płytę CD-ROM, natomiast mały został zaprojektowany z myślą o płytach CD-ROM o średnicy 8cm. Płyty takie do niedawna jeszcze były w sprzedaży w wersji do 250 megabajtów, jednak obecnie najczęściej spotykanymi rozmiarami są 210 megabajtów. System operacyjny klastrowy cdlinux.pl został oparty o wersję cdlinux.pl-mały pre2. Wersja ta pozbawiona jest dużych aplikacji i środowisk pracy, np. menadżera okien KDE, aplikacji biurowych (w tym OpenOffice.org). Zdecydowano, iż nie będą one potrzebne w najczęstszych przypadkach użycia konstruowanego klastra, a w razie pilnej potrzeby można system łatwo o nie wzbogacić Dystrybucja klastrowy cdlinux.pl Klastrowy cdlinux.pl jest dystrybucją systemu Linux, która pozwala na budowanie jednorodnego klastra obliczeniowego, w którym zwielokrotniona jest pamięć operacyjna, pamięć masowa, moc obliczeniowa. Do korzystania z takiego klastra nie są wymagane specjalnie projektowane dla niego aplikacje, gdyż fakt istnienia wielu procesorów w klastrze jest dla aplikacji ukryty. Klaster cdlinux.pl można przyrównać do jednego komputera z wieloma procesorami, który pracuje pod kontrolą systemu operacyjnego typu Symmetric Multi Processing (SMP). Jądro systemu SMP nie wyróżnia żadnego z procesorów spomiędzy innych obciążenie jest rozkładane w miarę możliwości równomiernie pomiędzy wszystkie 8

9 procesory. Podobnie klaster cdlinux.pl stara się zrównoważyć obciążenie każdego ze swoich węzłów, przy czym obciążenie jest rozumiane zarówno jako zajętość pamięci, jak i obciążenie CPU (Central Processing Unit, głównego procesora obliczeniowego systemu komputerowego). Przy równoważeniu obciążenia brana jest pod uwagę znamionowa pojemność pamięci operacyjnej jak i znamionowa szybkość CPU. Zasadniczą różnicą między porównywanymi rozwiązaniami jest to, że SMP składa się z wielu procesorów na wspólnej szynie danych, natomiast w klastrze cdlinux.pl procesory są w odrębnych komputerach, a zatem połączone na wyższej warstwie komunikacyjnej poprzez sieć komputerową. Z tego tytułu komunikacja między procesorami jest o kilka rzędów mniej sprawna w klastrze, niż w SMP oraz synchronizacja jest utrudniona. Technologią użytą w celu wzbogacenia Linuxa o wsparcie dla klastrów jest mechanizm stworzony w projekcie openmosix, któremu poświęcony zostanie osobny rozdział. Do skonstruowania klastra w oparciu o klastrowy cdlinux.pl wystarczy jedna płyta CD-ROM. System operacyjny z niej uruchomiony jest centralnym węzłem klastra (nazywanym dalej kontrolerem klastra). Proces jego uruchomienia nie odbiega daleko od procesu uruchamiania zwykłego cdlinux.pl. Po zainicjowaniu systemu, uruchomione zostają pozostałe komputery mające wejść w skład klastra. Komputer taki jest albo skonfigurowany do uruchomienia systemu operacyjnego przez sieć (jeżeli karta sieciowa oraz płyta główna komputera na to pozwalają), bądź stosowana jest dyskietka startowa, która zastępuje część ładującą systemu, która powinna być na karcie sieciowej. Komputer wykrywa kontroler klastra poprzez uruchomiony na tym ostatnim serwer bootp. Z tegoż serwera węzeł dowiaduje się, skąd ma pobrać program ładujący oraz jądro systemu operacyjnego (otrzymuje adres serwera tftp) i wzbogacony o tę wiedzę, pobiera ww. składowe systemu. Po uruchomieniu nowo pozyskanego jądra, skrypty startowe montują udziały sieciowego systemu plików NFS w trybie tylko do odczytu z kontrolera klastra, tworzą wirtualne dyski w pamięci RAM (ramdyski) i oddają kontrolę nad inicjacją systemu do standardowych skryptów inicjacyjnych cdlinux.pl. Po zakończeniu inicjacji system operacyjny uruchomiony na węźle funkcjonuje bardzo podobnie do systemu operacyjnego kontrolera klastra. Pod koniec procesu uruchamiania systemu operacyjnego, inicjowany jest podsystem openmosix, przy czym proces ten jest prawie identyczny zarówno na kontrolerze, jak i na 9

10 węzłach, gdyż żaden z elementów klastra nie jest wyróżniony z punktu widzenia pracy klastra. Inicjacja podsystemu openmosix polega na wydaniu odpowiedniego rozkazu do jądra systemu (przez interfejs sysctl) oraz na uruchomieniu daemona omdiscd, który odpowiedzialny jest za automatyczne dołączanie węzłów do klastra. Dodatkowo na kontrolerze klastra uruchomiony zostaje daemon openmosixcollector, który wspomaga pracę programu realizującego pulpit kontrolny klastra, openmosixview. W dalszych częściach pracy przedstawiono szczegółowo system openmosix oraz pewne rozwiązania z nim związane w klastrowym cdlinux.pl. Następnie omówiono proces uruchamiania klastra ze szczególnym naciskiem na elementy różniące go od cdlinux.pl oraz jego budowę. W ostatniej części pracy znajdują się wyniki testów wydajności zbudowanego systemu operacyjnego. 10

11 2. Środowisko klastrowe openmosix 2.1. Klastry obliczeniowe Pomysł klastrów komputerowych powstał w wyniku zapotrzebowania na dużą skalowalną moc obliczeniową uzyskaną kosztem niedrogiego sprzętu. Tym niedrogim sprzętem mogą być popularne obecnie komputery PC zakupione na poczet budowy klastra, a mogą to być również stacje robocze końcowych użytkowników. Użytkownicy przez większą część czasu nie potrzebują wielkich mocy obliczeniowych swoich stacji roboczych do wykonywania pracy, więc nie są one dociążane. Z drugiej strony, okazjonalnie miewają potrzeby krótkich, lecz intensywnych obliczeń i wtedy dociążają swoje stacje do granic wytrzymałości. Nasuwa się spostrzeżenie, iż praca przebiegałaby bardziej wydajnie, gdyby komputery były częścią większej całości nagłe zapotrzebowanie na moc obliczeniową byłoby rozkładane na większą ilość komputerów, czyli między innymi na niedociążane zwykle stacje robocze. Tradycyjnie skomplikowanymi obliczeniami zajmowały się korporacyjne superkomputery maszyny zaprojektowane do konkretnej wydajnej pracy nad pewnymi zagadnieniami matematycznymi, fizycznymi, chemicznymi, czy rozrywkowymi (komputery grające w szachy). Superkomputery były i są bardzo kosztowne, gdyż nie należą do produktów masowych, tworzone są na zamówienie. Ich wysoka cena zawężała grono użytkowników do dużych korporacji, czy uniwersytetów. Ponadto, w obliczu obecnego szybkiego rozwoju techniki, nawet superkomputery mogą szybko stać się zbyt wolne i zbyt przestarzałe jak na cenę, którą należało za nie zapłacić. Tych wszystkich wad pozbawione są klastry obliczeniowe, które przede wszystkim są zbudowane z tanich komputerów, a ponadto są łatwe w rozbudowie Podstawowe pojęcia Podstawową jednostką klastra jest węzeł, czyli pojedyncza maszyna (komputer) wchodząca w jego skład. Węzły są połączone między sobą przez sieć komputerową. Topologie połączeń mogą być bardzo zróżnicowane zależnie od środowiska, w którym klaster pracuje. W pracowni komputerowej będzie to przeważnie sieć LAN Ethernet bądź TokenRing, na odległych maszynach porozrzucanych po sieci metropolitarnej MAN może to być ATM czy 11

12 sieci DSL, natomiast w ogólności, gdy maszyny połączone są ze sobą przez Internet, sieci są dowolnego rodzaju i nie ma to większego znaczenia. Klastry zwykle są zaprojektowane w sposób, który umożliwia ich łatwą rozbudowę o kolejne węzły - skalowanie. Niektóre rozwiązania pozwalają nawet na swobodne podłączanie i odłączanie węzłów podczas pracy klastra. Fakt ten oraz duże zróżnicowanie sprzętu, który wchodzić może w skład heterogenicznego (zbudowanego z komponentów różnych typów) klastra powodują, iż mechanizmy rządzące klastrem mają trudne zadanie zapewnienia wysokiej wydajności całego organizmu Klasyfikacja klastrów Można wyodrębnić trzy podstawowe typy klastrów [OMHOWTO]: klastry odpornena-awarie (ang. fail-over cluster), klastry rozkładające obciążenie (ang. load-balancing cluster) i klastry wysokiej wydajności obliczeniowej, czyli HPC (ang. High Performance Computing cluster). Klastry odporne-na-awarie polegają na połączeniu w sieć dwóch lub większej ilości komputerów. Z logicznego punktu widzenia, oprócz połączenia ogólnego przeznaczenia (np. transmisji danych), występuje również połączenie kontrolne, tzw. heartbeat (ang. bicie serca), czyli sposób sprawdzania, czy komputery nadal działają. Jeżeli tego typu klaster wykonuje jakąś usługę, to wykonuje ją w rzeczywistości tylko jeden z komputerów wchodzących w jego skład. Pozostałe tylko obserwują, czy ten jeden nie przestanie działać. Jeżeli to nastąpi, jeden z pozostałych zajmuje jego miejsce w wykonywaniu usługi. Oczywiście usług może być wiele, niekoniecznie jeden z węzłów musi być przeznaczony do wykonywania wszystkich usług jednocześnie. Gdy w klastrze rozkładającym obciążenie nadchodzi żądanie usługi, jest ono kierowane do najmniej obciążonego węzła klastra. Ma to zastosowanie najczęściej w przypadku farmy serwerów WWW, gdzie wszystkie węzły mają dostęp do bazy danych, skąd czerpią zawartość stron do zaprezentowania użytkownikowi. Klastry rozkładające obciążenie są też przeważnie klastrami odpornymi-na-awarie, tylko że zwykle posiadają więcej węzłów. Klastry HPC są zaprojektowane z myślą o wysokiej wydajności przetwarzania danych. Łączą w sobie cechy obydwu wyżej wymienionych typów klastrów, jednak zasadniczym mechanizmem ich działania jest zrównoleglanie wykonywania programów podprogramy nie 12

13 muszą zawsze czekać na wykonanie poprzednich, mogą być równolegle wykonywane na innych węzłach klastra. Programy wykonywane na klastrach HPC są zwykle projektowane specjalnie pod dany typ klastra, a czasami nawet pod konkretną topologię sieciową, która łączy jego węzły Typy budowy klastrów HPC Jeżeli mówi się o przetwarzaniu równoległym w klastrach, ma się na myśli raczej klastry HPC. Ze względu na mechanizmy równoległego przetwarzania można wyodrębnić kilka rodzajów klastrów HPC: Non-Uniform Memory Access, Distributed Shared Memory, Parallel Virtual Machine, Message Passing Interface NUMA Non-Uniform Memory Access (NUMA), czyli Nie-Jednolity Dostęp do Pamięci [NUMA], nie jest stricte oznaczeniem typu klastra, a raczej rodzaju pojedynczej maszyny, która jednak bardzo podobna jest w budowie do klastra. NUMA oznacza maszynę, która ma wiele procesorów (CPU) i pamięć, której różne regiony mają różne czasy dostępu z punktu widzenia poszczególnych CPU. Można przyjąć, że w maszynie jest kilka szyn danych. Do każdej z szyn podłączone są jeden lub więcej CPU oraz pamięci. W maszynie NUMA istnieje pojęcie węzłów i w omawianym założeniu węzłem będzie jedna szyna danych wraz z otoczeniem, czyli podłączonymi do niej procesorami oraz pamięciami. Mając to na uwadze, z punktu widzenia procesora z węzła A, pamięć w węźle A będzie lokalna (ang. local), natomiast pamięć w węźle B będzie odległa (ang. remote). Klasyfikację taką przeprowadza się w ten sposób dlatego, że czas dostępu z procesorów z węzła A do pamięci węzła B będzie większy, niż czas dostępu do pamięci w obrębie jednego węzła. Analogia do klastra polega na tym, że w NUMA też występują węzły z procesorami jako oddzielne jednostki, w obrębie których nie ma zróżnicowania co do dostępu do pamięci. Zasadniczą różnicą jest to, że w klastrze każdy węzeł pracuje pod kontrolą osobnego systemu operacyjnego z własną kontrolą dostępu do pamięci, zasobów wejścia/wyjścia, etc. W systemie NUMA jeden system operacyjny zarządza wszystkimi węzłami, czyli wszystkimi procesorami. Różnicą są też przepływności komunikacyjne między węzłami. W systemie NUMA węzły są częścią jednego komputera, zatem przepływności będą dużo wyższe niż w 13

14 klastrze, gdzie węzły znajdują się na osobnych komputerach połączonych siecią komputerową. Obecnie głównymi implementacjami maszyn NUMA są komputery IBM NUMA-Q, Compaq Wildfire, SGI MIPS64. W systemie operacyjnym Linux istnieje wsparcie dla NUMA, jednak obecnie tylko w gałęziach kodu 2.5.X oraz 2.6.X DSM Distributed Shared Memory (DSM) jest pojęciem opisującym pewną warstwę abstrakcji implementowaną zarówno w oprogramowaniu, jak i sprzęcie, która ma zapewnić dostęp do fizycznie rozproszonej pamięci [CHANDRA]. Polega to głównie na wymianie porcji danych między węzłami klastra i przedstawienie ich przez API (Application Programming Interface, interfejs programistyczny) do aplikacji. Sprzętowe systemy DSM charakteryzują się zapewnieniem spójności danych na poziomie poszczególnych linii pamięci podręcznej oraz replikacją danych w pamięci podręcznej procesorów. Dotyczy to szybkiej wymiany niewielkiej porcji danych, gdyż pamięć podręczna jest o kilka rzędów mniej pojemna, niż pamięć operacyjna. Z drugiej strony, programowe rozwiązania DSM polegają na wymianie dużych obszarów pamięci operacyjnej kosztem wolniejszej komunikacji. Mimo, iż rozwiązania programowe stosuje się przeważnie w rozproszonych środowiskach z luźno powiązanymi węzłami, niektóre programowe mechanizmy mają potencjalnie zastosowanie tam, gdzie procesory są ze sobą ściśle powiązane. Jest tak na przykład w przypadku aplikacji, gdzie każdy procesor pracuje na dużych zestawach danych i wtedy replikacja ma miejsce w pamięci głównej całych zestawów. Istnieje dużo projektów informatycznych dotyczących programowych rozwiązań DSM. Listę zbierającą część z nich można znaleźć w [DSMWWW] MPI oraz PVM Message Passing Interface (MPI) i Parallel Virtual Machine (PVM), czyli odpowiednio Interfejs Przesyłania Wiadomości i Równoległa Maszyna Wirtualna, są to podobne rozwiązania programowe oferujące wsparcie dla przetwarzania rozproszonego. Komunikacja między węzłami klastra opartego na MPI i PVM polega na przesyłaniu tzw. wiadomości, czyli paczek danych o ściśle określonej strukturze. Poprzez wiadomości przesyłane jest sterowanie jak i dane do wykonywanego programu. Podczas gdy PVM jest konkretnym pakietem 14

15 oprogramowania (dostępnym w [PVMWWW]), MPI jest otwartym standardem, którego najpopularniejszymi implementacjami są MPICH [MPICHWWW], LAM/MPI [LAMWWW] Środowisko openmosix jako klaster HPC Dzięki projektowi openmosix istnieje możliwość zbudowania klastra w oparciu o oprogramowanie typu opensource (otwarte źródło), co dodatkowo zwiększa dostępność klastrów. Projekt openmosix wywodzi się z projektu Mosix, który został zapoczątkowany w roku 1977 w Hebrew University of Jerusalem przez profesora Amnona Baraka. Celem Mosixa było przekształcenie zbioru komputerów, niekoniecznie tego samego typu, w jeden wydajny klaster obliczeniowy. Odbywało się to na zasadzie dokonania zmian w jądrze systemu operacyjnego mających na celu zbudowanie klastra SSI (patrz niżej) oraz planisty, który potrafi przenosić procesy między węzłami klastra w zależności od obciążenia węzła. Mosix pracował nawet na takich maszynach, jak PDP11/45, czy VAX, pod kontrolą systemu operacyjnego AT&T UNIX 6, BSD/OS 3.0. System operacyjny GNU/Linux został wybrany jako platforma rozwojowa kolejnego wcielenia systemu Mosix w roku W roku 1999 dr Moshe Bar objął stanowisko drugiego menedżera projektu Mosix. W roku 2002, w wyniku różnicy zdań profesora Baraka oraz dr Bara co do komercyjnej przyszłości projektu Mosix, dr Moshe Bar odłączył się od projektu zakładając firmę Qlusters Inc. i jednocześnie zapoczątkował projekt openmosix bazując na Mosixie. Główną cechą różniącą Mosixa od openmosixa była licencja, na jakiej oprogramowanie było rozprowadzane. Mosix był komercyjnym produktem, natomiast openmosix, jak sama nazwa sugeruje, od samego początku rozprowadzany był na licencji GNU, czyli wolny od opłat, ze źródłem kodu powszechnie dostępnym. Obecnie istnieją obydwa projekty Mosix oraz openmosix, jednak z wypowiedzi dr Moshe Bara z 2002 roku wynika, iż około 97% użytkowników Mosixa zaczęło używać openmosixa Single System Image Pojęcie Single System Image (SSI) można zdefiniować jako iluzję stworzoną przez oprogramowanie lub sprzęt przedstawiającą zbiór elementów obliczeniowych jako jeden logiczny zasób [PFISTER]. Według Pfistera, w klastrze wyodrębnić można różne poziomy SSI część podsystemów rozpozna klaster jako SSI, a część nie. Aby dobrze 15

16 scharakteryzować openmosixa jako SSI, należy rozpatrzyć różne poziomy SSI z różnych perspektyw, zwłaszcza z perspektywy procesu, użytkownika, systemu plików Perspektywa procesu W systemie operacyjnym UNIX mówi się o programie jako o wykonywalnym pliku, natomiast jego uruchomiona instancja to proces. Przestrzeń procesów to zbiór informacji o wszystkich działających procesach w systemie. W tradycyjnych systemach nie-ssi, każda maszyna posiada własną przestrzeń procesów, która jest zarządzana oddzielnie i niezależnie od innych maszyn. W openmosixie istnieje dla danego procesu pojęcie UHN Unique Home Node, czyli Unikalnego Węzła Domowego. Jest to węzeł, na którym proces został uruchomiony. Każdy proces zostaje podzielony na 2 części: systemową oraz użytkownika. Część systemowa zawsze pozostaje na UHN, natomiast część użytkownika może migrować na inne węzły. Mimo to, z punktu widzenia użytkownika UHN proces znajduje się w jednej przestrzeni procesów. Przestrzeń tę tworzą dla UHN wszystkie inne węzły klastra. Proces może być w pełni zarządzany z UHN, nawet jeżeli w danym momencie został migrowany na węzeł inny niż UHN. Dla końcowego użytkownika fakt migracji jest przezroczysty, dlatego mówi się o SSI, czyli iluzji pojedynczego systemu z perspektywy przestrzeni procesów. Aby równomiernie rozłożyć obciążenie na węzłach klastra, openmosix stara się ocenić obciążenie każdego z węzłów. W przypadku węzłów posiadających taką sama moc obliczeniową i tyle samo pamięci operacyjnej, zadanie to nie byłoby trudne. Sprowadzałoby się to do oceny obciążenia każdego z węzłów w oparciu o procentową zajętość CPU oraz pamięci operacyjnej i porównania obciążeń. Jednak w heterogenicznym środowisku nie jest to takie łatwe. Przy dodawaniu węzłów do klastra openmosix stara się ocenić moc obliczeniową każdego z węzłów, by następnie móc wprowadzać korekty do algorytmu obliczania obciążenia węzłów. Na podstawie danych pozyskanych według takich kryteriów, openmosix próbuje migrować procesy z bardziej obciążonych węzłów na mniej obciążone Perspektywa użytkownika Z perspektywy użytkownika zarządzanie procesami odbywa się tak samo, jak na pojedynczej stacji roboczej. Użytkownik nie musi wiedzieć, na którym węźle w danym momencie dany proces pracuje, żeby mu wysłać sygnał. Po prostu wysyła sygnał do procesu na UHN, a openmosix zajmuje się dostarczeniem go do odpowiedniego węzła do części 16

17 systemowej procesu. Równie ważny jest fakt automatycznej migracji procesów celem równoważenia obciążenia. Użytkownik może ingerować w proces migracji, jednak jest to całkowicie opcjonalne. Ingerencja może polegać na zakazaniu lub nakazaniu migracji a'priori, czy też wręcz na przemieszczaniu procesów między poszczególnymi węzłami. Jeżeli jednak użytkownik zdecyduje się nie wnikać w szczegóły pracy klastra, openmosix zajmie się tym za niego. Kolejnym zadaniem, przy którym użytkownik, a dokładniej administrator jest wyręczany, jest proces dodawania i usuwania węzłów do/z klastra. Tradycyjnie lista węzłów klastra musiała być zachowana w pliku na każdym z węzłów i uaktualniana przy dodawaniu/usuwaniu węzłów. Obecnie jednym z narzędzi openmosixa jest daemon omdiscd, który jeżeli jest uruchomiony na każdym z węzłów, zajmuje się automatycznym kompletowaniem klastra. Nie istnieje potrzeba administracyjnego formułowania listy węzłów, gdyż daemon omdiscd, przez zastosowanie ruchu sieciowego multicast, wykryje wszystkie węzły i spowoduje, że każdy z nich uzna pozostałe jako części klastra. Przy automatycznym dodawaniu węzła również ma miejsce ocenianie jego mocy obliczeniowej i zasobów pamięciowych, celem wykorzystania tej wiedzy następnie w algorytmie równoważenia obciążenia Perspektywa systemu plików System plików jest kluczowym elementem pracy procesu. Programy są często tak zaprojektowane, by korzystały z systemu plików do odczytywania i zapisywania danych. Jeżeli dany proces zostanie uruchomiony na UHN i stworzy tam plik /tmp/plik, lecz w wyniku migracji znajdzie się później na innym węźle, to gdy będzie chciał odwołać się do stworzonego wcześniej pliku, okaże się, że go tam nie ma, gdyż został na UHN, gdzie proces nie jest w danym momencie wykonywany. Innym, bardziej ogólnym problemem, jest potrzeba współdzielenia przez wiele węzłów (spośród których każdy ma być UHN dla własnych procesów) tych samych zasobów systemów plików. Zwykle można to osiągnąć przez korzystanie z sieciowego systemu plików NFS, jednak system ten jest daleki od doskonałości. Po pierwsze, występują tradycyjne dla NFS problemy z pamięcią podręczną, znacznikami czasowymi, prawami dostępu do plików, a po drugie, jest to zewnętrzny mechanizm powodujący dodatkowy ruch w sieci. W systemie openmosix istnieje kilka mechanizmów, które zajmują się wyżej wymienionymi problemami. 17

18 Pierwszym, najbardziej ogólnym sposobem, jest przechwytywanie operacji wejścia/wyjścia. Operacje te są przechwytywane przez węzeł, na którym w danym momencie wykonywany jest proces i kierowane są do UHN, gdzie istnieją fizycznie zasoby, do których proces się odwołuje. Można sobie łatwo wyobrazić, iż proces ten jest stosunkowo wolny, gdyż wymaga narzutu spowodowanego przez przekierowywanie żądań wejścia/wyjścia do UHN, obsługiwanie ich tam i powrót sterowania do węzła, na którym wykonywany jest proces. Drugim, bardziej eleganckim sposobem jest wykorzystanie omfs, czyli sieciowego systemu plików openmosix File System. 18

19 openmosix File System omfs jest systemem plików podobnym w użyciu do NFS [NFSHOWTO], jednak pozbawionym uciążliwych cech NFS związanych z pamięcią podręczną, znacznikami czasowymi, prawami dostępu do plików, etc. Dzięki zamontowaniu systemu plików omfs na danym węźle, każdy proces uruchomiony na nim otrzymuje dostęp do dowolnego pliku na dowolnym węźle klastra. Wyjątek stanowią zawartości katalogów /proc węzłów oraz pliki specjalne, np. pliki urządzeń do tych plików umieszczonych na węzłach nie można uzyskać dostępu przez omfs. Idea omfs została zobrazowana na diagramie nr. Zakłada się, że w klastrze istnieją węzły o numerach ID 1, 2, 5. Przedstawiono uproszczoną zawartość katalogu głównego każdego z węzłów oraz zawartość zamontowanego systemu omfs w katalogu /mfs jednego z węzłów === === === `-bin `-bin `-etc `-etc `-boot `-home `-home `-etc `-sbin `-usr `-home `-usr (dowolny) =========... `-mfs `-1 `-bin `-etc `-home `-usr `-2 `-bin `-boot `-etc `-home `-5 `-etc `-home `-sbin `-usr Diagram 1. Połączenia między węzłami klastra w obrębie omfs 19

20 Widać jak każdy z węzłów ma dostęp do systemów plików każdego z pozostałych węzłów klastra. Oprócz tej ogólnej zasady, w katalogu /mfs znajdują się również następujące specjalne katalogi, które są de facto niemodyfikowalnymi dowiązaniami symbolicznymi do katalogów reprezentujących systemy plików różnych węzłów. Ich znaczenie zależne jest od nazwy: /mfs/here - bieżący węzeł /mfs/home - węzeł UHN /mfs/magic - jest to bieżący węzeł, jeżeli ścieżka użyta jest przy wywołaniu systemowym tworzącym plik (creat bądź open z opcją O_CREAT), a w innym przypadku jest to węzeł, na którym ostatnio proces stworzył plik przez omfs; mechanizm przydatny przy wykorzystywaniu plików tymczasowych /mfs/lastexec - węzeł, na którym proces ostatnio z powodzeniem wykonał wywołanie systemowe execve /mfs/selected - węzeł zaznaczony (ang. selected) przez dany proces lub jednego z jego przodków przez zapisanie liczby do pliku /proc/self/selected. System plików omfs jest obecnie wyposażony w mechanizm DFSA Direct File System Access, czyli bezpośredni dostęp do systemu plików. Umożliwia on przezroczysty dostęp do zasobów systemu plików UHN dla wywołań systemowych procesu wykonywanego na innym węźle przez system plików omfs. Bez uruchomionego mechanizmu DFSA, omfs nadal będzie udostępniał zdalne systemy plików, jednak uruchomione na węzłach procesy nie będą mogły z nich przezroczyście korzystać. Co więcej, dzięki DFSA openmosix dokonuje oceny, czy bardziej korzystnie jest kontynuować wykonywanie danego procesu zdalnie i udostępniać mu dane przez sieć, czy przywołać go z powrotem do UHN, gdzie dane są dostępne lokalnie. Zalecane jest łączenie w klaster openmosix komputerów, które pracują pod kontrolą tak samo skonfigurowanego podsystemu openmosix w jądrze. Ma to znaczenie w szczególności dla pracy DFSA. Należy ponadto zwrócić uwagę na to, by na każdym z węzłów numery użytkowników (UID) oraz grup (GID) były takie same dla tych samych nazw użytkowników i grup. Również nie należy się przejmować wynikiem polecenia df, podającego rozmiar oraz zajętość zamontowanych systemów plików w systemie operacyjnym, gdyż często ma miejsce błędny odczyt pojemności i zajętości zamontowanego omfs. 20