Laboratorium wirtualne 2/Moduł 5 - ćwiczenie 5
wersja beta
LABORATORIUM WIRTUALNE 2
Ćwiczenie 5 - Aplikacje rozproszone w systemie operacyjnym Linux
|
|
System rozproszony to układ przejść sterowany komunikacją asynchroniczną. Komunikacja synchroniczna jest traktowana jako szczególny przypadek komunikacji asynchronicznej.
Węzły funkcjonują niezależnie i na każdym z nich algorytm komunikacji jest wykonywany lokalnie. Lokalne wykonania tworzą zbiór - rozproszony algorytm komunikacji. Jest on niezbędny w realizowaniu algorytmów bardziej skomplikowanych. Wykonywanie algorytmu komunikacji opiera się na realizacji kolejnych tak zwanych zdarzeń Dzieli się je na wewnętrzne (stany węzła) oraz zewnętrzne (wysyłanie i odbieranie komunikatów). Zmienne współdzielone nie są formą komunikacji według definicji, jednak mogą być wykorzystane. System rozproszony jest układem przejść, nie jest jednak prostym układem sekwencyjnym lub kombinacyjnym, gdyż wiele ze zdarzeń wpływających na aktualny jego stan jest niezależna od samego systemu.
|
|
GNU/Linux jest w dużej mierze zgodny ze standardem IEEE1003 (tak zwanym POSIX) a niektóre z dystrybucji przeszły procedury certyfikacyjne. Od roku 1996 jądro wykorzystuje możliwości systemów wieloprocesorowych w trybie SMP czyli symetrycznej wieloprocesorowości.
Rozproszone systemy plików dostępne dla Linuksa funkcjonują w sposób przeźroczysty dla użytkownika. Dostępna jest szeroka gama rozproszonych systemów plików. Na szczególną uwagę zasługują trzy z nich: popularny wśród Uniksów system NFS, tak zwana Samba czyli system oparty o protokół SMB oraz bardziej zaawansowane systemy plików, takie jak Lustre wykorzystywany w systemach klastrowych dużej skali. Linux i większość oprogramowania dla niego dostępne są na wolnych licencjach, które typowo gwarantują wolność używania, modyfikowania a także rozprowadzania i sprzedaży. Dzięki temu jest on łatwo dostępny w Internecie w wielu wersjach, dostosowanych do nawet bardzo specjalistycznych potrzeb od klastrów i komputerów wieloprocesorowych, poprzez systemy biurowe, do systemów wbudowanych. Dostępna jest szeroka gama oprogramowania i bibliotek programistycznych, dzięki czemu mogło powstać na przykład to ćwiczenie.
|
|
Zdalne uruchomienie aplikacji i wykonanie przez nią pewnego zadania na innym komputerze niż ten, z którego wysłano żądanie, można uznać za wstęp do stworzenia systemu rozproszonego. Istnieje wiele sposobów zdalnego uruchamiania aplikacji, takich jak na przykład RPC, CORBA, SOAP i wiele innych. W prezentowanym przykładzie wykorzystujemy metodę bardzo prostą i przez swą prostotę atrakcyjną z punktu widzenia użytkownika końcowego.
Zdalne uruchomienie aplikacji może odbywać się poprzez wysłanie odpowiedniego komunikatu powszechnym, prostym i znanym protokołem http. Użytkownik a dokładniej - jego przeglądarka www, jest tutaj tak zwanym inicjatorem. Przekazuje ona wiadomość do serwera. Na wiadomość składają się między innymi wartości wpisane w pola formularza. Te wartości są jedynie propozycjami. Serwer sprawdza je, pełniąc rolę tak zwanego akceptora. Proszę sprawdzić czy to działa wpisując w pola formularza coś nietypowego. Serwer http nie wykonuje żadnych obliczeń, robi to tak zwany uczeń. Uczeń to ten element systemu, który otrzymuje zaakceptowane wartości i wykonuje na nich swoje zadanie. W naszym przykładzie uczniem jest skrypt tworzący wykresy. Z chwila stworzenia wykresów role odwracają się - to skrypt proponuje wartości (grafiki z wykresami) serwerowi a ten przedstawia je przeglądarce, która stając się uczniem akceptuje je.
|
|
W przykładzie pokazane zostało komunikowanie się trzech typowych elementów systemu, tak zwanych agentów oraz zdarzenia jakim podlegają. Zaprezentowane podejście do komunikacji w systemie rozproszonym można rozszerzyć do większej liczby niezależnych agentów. Pozwala ono na osiągnięcie konsensusu, co jest jednym z najważniejszych problemów systemów rozproszonych.
Trzeba jednak pamiętać o spełnieniu trzech wymogów. Po pierwsze wartości proponowane akceptorom muszą wynikać z funkcjonowania systemu a konkretnie wywodzić się od agentów proponujących. Po drugie, wszyscy uczniowie po otrzymaniu wypracowanych przez akceptorów wartości, mogą znaleźć się w dokładnie jednym stanie, gdyż zgodnie z regułą konsensusu osiągniętemu porozumieniu jednakowo podlegają wszystkie elementy. Reguła trzecia dotycząca żywotności systemu to gwarancja, że komunikacja pomiędzy poprawnie działającymi akceptorami a uczniami funkcjonuje właściwie. Problem gdy agenci nie funkcjonują prawidłowo wykracza poza zakres tego ćwiczenia, chociaż we własnym zakresie można go przeanalizować.
|
|
GNU/Octave jest dostępnym na licencji GNU General Public License "matematycznym laboratorium". W składni jest w 99% zgodny z popularnym programem Matlab.
Wiele definicji systemu rozproszonego jest ostrzejsze, niż przedstawiona wcześniej. Często wymogiem jest aby węzły systemu były dla siebie nawzajem przeźroczyste. Wykonanie obliczeń z tej części ćwiczenia jest przeźroczyste dla użytkownika korzystającego z przeglądarki. Obliczenia, które obecnie są wykonywane na jednym serwerze, mogłyby zostać rozproszone na większą liczbę maszyn (być może już są?). Użytkownik nie odnotowałby tej zmiany. |
|
Zdalnie uruchamiana aplikacja została napisana w postaci skryptu programu GNU/Octave. Szerokie możliwości Octave'a obejmują również cyfrowe przetwarzanie sygnałów, wykorzystane w niniejszym ćwiczeniu jako przykład zdalnych obliczeń. Skrypt otrzymuje wartości wpisane przez użytkownika w pola formularza po uprzednim zaakceptowaniu ich przez oprogramowanie serwera http. Na podstawie tych danych tworzy sygnały harmoniczne, przekształca je i generuje wykresy. Grafiki z wykresami są następnie przekazywane z powrotem do przeglądarki oczywiście znowu za pośrednictwem serwera http.
Dla każdego z żądań użytkownika końcowego, po sprawdzeniu wartości przez akceptora, uruchamiany jest proces Octave'a. Powiedzieliśmy wcześniej, że węzłami systemu rozproszonego mogą być również procesy, nie definiując czym one są. Załóżmy, że lokalizacja wykonywania procesu obliczeniowego nie jest znana i każdy z tych procesów traktujemy jako węzeł. Wiemy, że procesy te są uruchamiane na żądanie, dlatego ten system określimy jako dynamiczny. Podobnie dynamicznie do systemu dołączają (rejestrują się) przeglądarki. Jedynym statycznym elementem jest serwer http, jednak aby cały system rozproszony był statycznym, wszystkie jego elementy muszą być statyczne. Skrypt można rozszerzyć o inne możliwości, takie jak na przykład filtracja sygnałów. Zamiast skryptu w Octave'a można oczywiście uruchamiać inną aplikację. W przykładzie nie jest jednak najistotniejsze to, co jest uruchamiane, a podstawy tworzenia systemów rozproszonych.
|
|
Wiemy już, że od strony systemu operacyjnego kontrolującego urządzenie tworzące węzeł na zdarzenia reagują tak na prawdę zadania. Zadania w większości systemów dzielą się na procesy i wątki. Wątki są wykonywane w tej samej przestrzeni adresowej co proces, który je stworzył. Procesy są wykonywane w różnych przestrzeniach adresowych, jednak istnieją techniki współdzielenia pamięci - wspomniane zmienne dzielone.
Sygnał to zdarzenie mające numer z pewnego przedziału, zwykle niewielkich liczb całkowitych większych od zera. Proces wysyłający wybiera odbiorcę (możliwe też wysłanie jeden-do-wielu) oraz numer sygnału. Do procesu odbierającego nie jest przekazywana żadna informacja poza numerem sygnału. Numerowi sygnału można przyporządkować jakąś charakterystyczną sytuację, na którą proces powinien zareagować w ściśle określony sposób. Przyporządkowania dokonuje się na etapie projektowania systemu i aplikacji. Wiele sygnałów jest unormowane Posiksem. Reasumując: sygnały same w sobie nie są zdarzeniami, ale niosą informację o zdarzeniach. Dlatego też nie są traktowane jako metoda komunikacji międzyprocesowej, chociaż mogą służyć synchronizacji procesów. Semafor to zmienna na której operacja testu i modyfikacji jest dokonywana niepodzielnie. Dzięki tej własności zadania w środowisku wielozadaniowym mogą zostać wiarygodnie zsynchronizowane. Semafory są uznawane za metodę IPC. Są to jednak zmienne współdzielone, dlatego w systemach rozproszonych mogą być używane w ograniczonym zakresie. Zadania muszą mieć wstępnie uzgodnione wykorzystanie semaforów, a przez to nie są dla siebie przeźroczyste. Wykorzystanie semaforów pomiędzy węzłami odległymi w przestrzeni jest możliwe, ale na tyle skomplikowane, że wówczas zwykle wykorzystuje się bardziej zaawansowane mechanizmy. Komunikaty to zwykle nieduże struktury danych przekazywane pomiedzy zadaniami. W niektórych systemach dostępne jest przeźroczyste przekazywanie komunikatów pomiędzy rozproszonymi terytorialnie węzłami. W ćwiczeniu komunikacja odbywa się pomiędzy dwoma procesami na tym samym komputerze - węźle. Gniazda to punkty końcowe lokalnej komunikacji międzyprocesowej (gniazda domeny Unix) lub Internetu. W ćwiczeniu testowana jest wydajność jądra Linux w operowaniu na gniazdach Internetowych. Szybkość transmisji przez fizyczne łącza jest oczywiście dużo mniejsza. |
|
W tej części ćwiczenia należy przetestować wydajność działania czterech wybranych mechanizmów Posiksowej komunikacji międzyprocesowej (IPC - interprocess communication). Testy są uruchamiane zdalnie na serwerze, podobnie jak miało to miejsce w pierwszej części ćwiczenia. Niektóre z testów mogą trwać dość długo, zależnie od parametrów wybranych przez użytkownika. Maksymalny czas oczekiwania na wyniki nie powinien przekroczyć minuty. Wyniki mogą zależeć od chwilowego obciążenia serwera. Należy pamiętać, że w rzeczywistych aplikacjach do każdego z mechanizmów konieczne jest dodanie wielu elementów, dlatego wydajność uzyskana w testach jest większa niż ta, jakiej można się spodziewać po "prawdziwej" aplikacji. |
|
Wspomniana dynamika systemu rozproszonego może być oczywiście bardziej skomplikowana niż w pierwszym przykładzie. Po pierwsze struktura takiego systemu może nie być znana w żadnej chwili jego istnienia. Agenci rejestrują się i wyrejestrowują bez przerwy, w przypadkowych chwilach. Tworzy to skomplikowaną sieć w której żaden z węzłów może nie być uprzywilejowany.
Często też agenci są wyłączani lub doznają awarii bez wyrejestrowywania z systemu, co powoduje dodatkowe problemy. Co na przykład, jeśli agent akceptujący dozna awarii? System musi być tak skonstruowany aby dopuszczał awaryjność pewnej ilości agentów, jednocześnie dając gwarancję poprawności działania całości. System rozproszony jako układ współpracujących i na przykład replikujących się węzłów, i tak jest bardziej bezawaryjny niż jedno, monolityczne urządzenie. Wiadomo też, że zrównoleglanie procesów poprawia wydajność. Algorytm komunikacji w systemie dynamicznym również jest zadaniem nietrywialnym, zwłaszcza jeśli wydajność ma kluczowe znaczenie. Istnieją trzy podejścia w tworzeniu algorytmu przekazywania komunikatów. Pierwszy opiera się o prawdopodobieństwo, że komunikat zostanie przekazany odbiorcy szybciej, jeśli zostanie przekazany do węzła leżącego potencjalnie bliżej węzła docelowego. Bliżej według "tablicy routingu" ale nie fizycznej topologii, która pozostaje nieznana. Drugie podejście to stworzenie mapy logicznej i dopasowanie jej do mapy fizycznej. Węzły otrzymują identyfikatory zgodne ze stworzoną korelacją. Komunikaty są przekazywane do węzłów o identyfikatorach bliższych identyfikatorowi węzła docelowego. Może to jednak powodować problemy z lokalną wydajnością działania systemu, co może wpłynąć na spadek wydajności całego systemu. Trzeci przypadek to kompromis pomiędzy dwoma omówionymi podejściami: komunikat jest przekazywany do węzła, którego identyfikator należy do grupy węzłów leżacych bliżej celu a jednocześnie jest on bliżej celu według tablicy routingu
|
|
XMPP jest protokołem komunikacji, który z powodzeniem można wykorzystać w dużych i bardzo dużych dynamicznych systemach rozproszonych. XMPP to skrót od "rozszerzalny protokół przekazywania komunikatów i informacji o obecności". Powstał on jako standaryzacja protokołu Jabbera - komunikatora internetowego. Sam Jabber to nie tylko XMPP, jednak XMPP jest protokołem opartym o XML, dlatego można go swobodnie wykorzystać do przesyłania dowolnych komunikatów.
Serwery Jabbera tworzą rozproszoną sieć co odróżnia go od innych komunikatorów, gdzie serwery tworzą farmy i są zarządzane centralnie. Każdy może uruchomić serwer Jabbera. Taki właśnie serwer został uruchomiony na potrzeby tego ćwiczenia. Oprogramowanie klienckie również jest powszechnie dostępne, często na wolnych licencjach. Biblioteki programistyczne pomocne w tworzeniu aplikacji jabberowych są dostępne dla języków takich jak między innymi C, C++, Perl, Python, PHP, Java, .NET, Mono, Delphi i Flash. Transmisja może być zabezpieczona przez SSL lub SASL, co pozwala na wirtualizację systemów rozproszonych wewnątrz innych sieci rozległych takich jak na przykład Internet.
|
|
Serwer tego ćwiczenia jest też serwerem Jabbera, na którym użytkownicy mogą założyć konto. Celem jest wspólne, rozproszone wykonywanie obliczeń. Zadaniem niech będzie dopasowanie wzorca, takie że dla pewnego łańcucha tekstowego możliwe jest przekształcenie go do pewnej liczby łańcuchów. Przekształcenie odwrotne nie jest możliwe, ale każdemu łańcuchowi wtórnemu odpowiada co najwyżej jeden łańcuch pierwotny. Aplikacje użytkowników jako agenci uczący się mogą otrzymać łańcuch wtórny i próbować znaleźć łańcuch pierwotny. Jako agenci proponujący, aplikacje użytkowników mogą wysyłać łańcuch wtórny do analizy.
Możliwy jest jeden z czterech styli komunikacji. Wszyscy mogą komunikować się ze wszystkimi, co jest jednak bardzo niewydajne. W drugim przypadku inicjator, czyli agent proponujący jest liderem. Lider wysyła komunikat - zapytanie do wszystkich węzłów systemu. Po otrzymaniu odpowiedzi od wszystkich węzłów, przekazuje im z powrotem informację podsumowującą. W trzecim przypadku inicjator nie jest liderem. Lider po otrzymaniu wiadomości od inicjatora uruchamia algorytm lidera. Czwarty przypadek to pierścień węzłów, w którym informacja propaguje wzdłuż krawędzi, konieczne jest więc przekazanie niemal dwa razy tyle komunikatów co węzłów. Przy dobrej wydajności połączenia między inicjatorem a pozostałymi węzłami zastosowalibyśmy algorytm drugi. Jednak nie możemy tego założyć, dlatego użyjemy algorytmu trzeciego. Inicjatorem będą jabberowe aplikacje klienckie. Desygnowanym liderem będzie proces kontrolujący specjalne konto jabberowe. Jego identyfikator to leader@serwer.cwiczenia.pw.edu.pl. Po dodaniu go do listy kontaktów należy wysłać wiadomość "help" aby uzyskać pomoc w przeprowadzeniu eksperymentu. Żądania obliczeń mogą być przekazywane liderowi. Ten odpytuje znanych mu klientów o gotowość wykonania zadania. Po uzyskaniu tej informacji przekazuje z powrotem wiadomość, który z węzłów został wybrany do realizacji obliczeń. Wybranemu węzłowi jest dodatkowo przekazywany ciąg do analizy.
|
|
Na zakończenie ćwiczenia proponowana jest analiza działania protokołu Jabbera. Do tego celu najlepiej wykorzystać program Ethereal (od pewnego czasu znany pod nową nazwą - Wireshark). Pozwala on na zebranie przekazywanych pakietów i ułatwia ich analizę. Bardziej zaawansowane osoby mogą skorzystać z programów takich jak tcpdump lub snort. Należy obejrzeć zarówno komunikację zaszyfrowaną jak i niezaszyfrowaną. Wewnątrz niezaszyfrowanych pakietów z łatwością można znaleźć XML. |
|
Literatura |
