Projekt i implementacja rozproszonego

POLITECHNIKA KRAKOWSKA Wydział Fizyki, Matematyki i Informatyki Stosowanej Informatyka PRACA MAGISTERSKA Projekt i implementacja rozproszonego systemu czasu rzeczywistego Autor: Marcin Szelc Promotor: dr inż. Lech Jamroż

KRAKÓW, 2008 2

Za pomoc przy pisaniu pracy oraz udzielenie cennych wskazówek składam serdeczne podziękowania Panu dr inż. Lechowi Jamrożowi Spis treści Wstęp. 4 Cel pracy i założenia. 6 Rozdział I Podstawy systemów rozproszonych i czas rzeczywistego. 7 1.1 Systemy rozproszone w aspekcie systemów czasu rzeczywistego. 7 Rozdział II Analiza i charakterystyka systemu. 13 2.1 Zapotrzebowanie przeznaczenie systemu. 13 2.2 Charakterystyka wykonania poszczególnych zadań. 14 Rozdział III Projektowanie systemu. 18 3.1 Architektura. 20 3.2 Projekt rozwiązań cech systemu rozproszonego i czasu rzeczywistego. 24 3.3 Diagramy UML. 33 3.3.1 Diagramy przypadków użycia. 33 3.3.2 Diagramy klas. 35 3.3.3 Diagramy czynności. 47 3.4 Operacje wykonywane przez system. 48 Rozdział IV Implementacja rozproszonego systemu czasu rzeczywistego. 50 4.1 Narzędzia, język programowania i biblioteki użyte do implementacji systemu. _ 50 4.2 Implementacja strony serwera. 51 4.3 Implementacja strony klienta. 53 4.4 Koordynacja komunikacja. 56 4.5 Konfiguracja systemu. 57 4.6 Widoki systemu. 58 Rozdział V Testowanie rozproszonego systemu czasu rzeczywistego. 65 5.1 Testowanie. 65 5.1.1 Testy poprawności logicznej jednostkowe. 65 3

5.1.2 Testy wydajnościowe i czasu rzeczywistego. 69 5.1.3 Testy tolerancji błędów odporność na awarie sprzętu i sieci. 74 Rozdział VI Podsumowanie. 76 6.1 Wnioski. 76 6.2 Podsumowanie 76 Bibliografia. 78 Spis rysunków. 79 Spis kodów źródłowych. 80 Wstęp Wraz z rozwojem technologii rośnie coraz większy nacisk na czas przetwarzania i niezawodność procesów. Większość powstających obecnie dużych systemów to systemy rozproszone. Bardzo często nie są one jednak zoptymalizowane pod kątem wydajności, nacisk kładzie się w nich np. na niezawodność, poprawność działania itp. W systemach czasu rzeczywistego wykonywanie zadań na czas jest priorytetem i jest ważniejsze od dokładności obliczeń. Zaprojektowanie rozproszonego systemu czasu rzeczywistego jest sprawą nie trywialną. Niektóre założenia systemu rozproszonego idą na przekór systemowi czasu rzeczywistego. Oczywiście bardzo wiele zależy od środowiska pracy np. zdecydowanie łatwiej będzie wykonać system przewidywalny pod względem czasowym w środowisku zamkniętym tj. połączony łączami komunikacyjnymi na wyłączność (lokalnymi), niż system, który jest dostępny w sieci internet, gdyż komunikacja połączenia klientserwer może nieść duży narzut czasowy, którego nie można dokładnie określić. Tworzenie systemu czasu rzeczywistego (szczególnie z rygorystycznymi wymaganiami czasowymi), w którym komunikacja pomiędzy węzłami odbywa się z wykorzystanie internetu jest bardzo trudne, wręcz niemożliwe. Sprawa wygląda lepiej w przypadku tworzenia systemu z luźnymi ograniczeniami czasowymi. Bez względu na środowisko, rozmiary takiego systemu, należy dokonać głębokiej analizy każdego projektowanego komponentu, elementów komunikacyjnych. Implementacje należy realizować z wykorzystaniem metod optymalizacji (optymalizację można zacząć przeprowadzać po zakończeniu implementacji i przetestowaniu funkcjonalności, jednak optymalizacja wydajnościowa powinna być w pewnym stopniu przeprowadzana wcześniej), natomiast w końcowej fazie należy przeprowadzić rozległe testy 4

funkcjonalne, ze szczególnym uwzględnieniem symulowania niekorzystnych warunków, dzięki czemu będzie można poznać reakcje systemu w krytycznych sytuacjach i otrzymać wstępną odpowiedź czy system w danym stanie w ogóle nadaje się do zastosowania jako system czasu rzeczywistego. Modelowanie komponentów, które wymagają synchronizacji dostępu, będzie wymagało kompromisu czasowego (każda synchronizacja niesie ze sobą narzut czasowy). Dlatego też należy wyizolować najmniejszy fragment operacji, który należy poddać synchronizacji, aby zminimalizować straty. Projektowanie systemu czasu rzeczywistego wiąże się w dużej mierze z optymalizacją systemu pod kątem wydajności jest to kluczowy element takiego systemu. Równie ważne jest szeregowanie zadań, a w przypadku systemu rozproszonego odpowiedni rozdział zadań, podzadań do jednostek przetwarzających. O ile poprawa wydajności poszczególnych elementów może sprowadzać się do testów jednostkowych i optymalizacji fragmentów kodu, o tyle zastosowany algorytm ściśle zależy od wymagań czasowych, środowiska pracy, powinien być więc wypadkową działania całego systemu. Przy projektowaniu systemu należy kłaść duży nacisk na jego elastyczność. Na wstępie został przedstawiony jedynie zarys niektórych aspektów rozproszonych systemów czasu rzeczywistego, więcej tych aspektów oraz szerzej o nich w kolejnych rozdziałach pracy. 5

Cel pracy i założenia Celem pracy jest zaprojektowanie i implementacja rozproszonego systemu czasu rzeczywistego, a także zarysowanie problematyki systemów rozproszonych i czasu rzeczywistego w kontekście zderzenia się tych dwóch technologii. Założeniem realizowanego systemu jest przetwarzanie zadań (dostarczanych przez klientów) w czasie rzeczywistym przez system rozproszony. Klient wywołuje serwis obsługi zadań i przesyła zadanie do wykonania. Zadanie jest przesyłane w częściach (klient dokonuje podziału zadania) do serwera będącego w danej chwili dyspozytorem (serwerem centralnym), który dokonuje rozdziału podzadań do serwerów wykonujących (zwanych dalej operacyjnymi lub współpracującymi). Serwery wybierane są na podstawie wykonywanej cyklicznie analizy ich obciążenia oraz priorytetu zadania, żądanego czasu zakończenia zadania (deadline) i szacowanego czasu zakończenia. Wyniki wykonania zadania są przesyłane w częściach do klientów. Biorąc pod uwagę, że implementacja rozproszonego systemu czasu rzeczywistego to problematyka niezmiernie złożona i czasochłonna, system będący tematem niniejszej pracy tworzy namiastkę takiego systemu, daje jednak podwaliny pod dalszą rozbudowę poprzez wydzielenie aspektów strategicznych działania takiego systemu (np. planisty szeregującego zadania, synchronizacji dostępu do danych, synchronizacji czasowej, koordynacji działania). Realizowany system ma możliwość łatwego dołączania nowych zadań, które będzie mógł wykonywać. W realizowanym systemie 6

dołączony został moduł matematyczny mnożenia dwóch macierzy o dowolnych rozmiarach ze względu na łatwą skalowalność tego zadania, dzięki czemu można było porównywać wyniki przy różnych rozmiarach macierzy. Również w łatwy sposób można dołączać nowe algorytmy szeregujące zadanie, które mogą być zmieniane podczas działania systemu w zależności od satysfakcji uzyskiwanych czasów wykonania zadania. Rozdział I Podstawy systemów czasu rzeczywistego i systemów rozproszonych 1.1 Systemy rozproszone w aspekcie systemów czasu rzeczywistego. System czasu rzeczywistego jest to system, w którym obsługiwanie zdarzeń powinno być wykonane w ustalonym limicie czasu. Poprawność działania tego systemu zależy nie tylko od poprawności wyników, ale także od dostarczenia tych wyników przed upływem nieprzekraczalnego terminu deadline. W systemach czasu rzeczywistego duży nacisk kładzie się na scenariusze pesymistyczne duże obciążenia zasobów. Kosztem średniej wydajności systemu i mocy obliczeniowej, polepsza się czasy w przypadkach pesymistycznych. Przykłady: komputer sterujący rakietą musi w określonym czasie wyznaczyć jej kurs, odtwarzacz filmów musi zdekodować klatki w określonym i krótkim czasie, zależnym od liczby klatek na sekundę np. dla 50 klatek na sekundę, każda klatka musi być zdefiniowana w czasie nie większym niż 25ms, komputer sterujący różnego typu urządzeniami np. AGD sterowanie pompą w pralce. 7

Systemy czasu rzeczywistego stosuje się w następujących dziedzinach: multimedia, telekomunikacja, przemysł, medycyna, astronomia, aeronautyka, robotyka, kontrola i pomiary, urządzenia podwodne. Cechy systemu czasu rzeczywistego: równoległe działanie oddzielnych komponentów systemu, udogodnienie w interakcjach ze sprzętem, gwarantowany czas odpowiedzi, ekstremalna solidność, wydajna implementacja, tolerancja błędów. Podział systemów czasu rzeczywistego ze względu na ograniczenia czasowe: rygorystyczne (hard real time) system, w którym wykonanie zadania w żądanym czasie ma znaczenia dla poprawności funkcjonowania, tj. przekroczenie deadline może spowodować awarie systemu, nieprawidłowe działanie itp. w zależności od specyfiki systemu, a nawet zagrożenie dla ludzi, luźne (soft real time) system, w którym incydentalnie mogą zdarzać się przekroczenia żądanego czasu wykonania bez wpływu na poprawność oraz rezultaty jego działania, mocno rygorystyczne (real real time) jest to system hard real time, w którym dodatkowo czasy żądania wykonania zadania są bardzo małe, bezwzględnie rygorystyczne (firm real time) jest to specyficzny system hard real time, w którym przekroczenie deadline powoduje bezużyteczność otrzymanych wyników, jednak nie powoduje groźnych skutków. 8

Algorytmy szeregowania w systemach czasu rzeczywistego EDF (Earliest deadline first) najpierw z najwcześniejszym czasem deadline, LST (Least slack time first) najpierw z najmocniejszym ograniczeniem czasowym, DM (Deadline monotonic) monotoniczne. Parametry algorytmów szeregowania: faza (phase), okres (periodic), trwanie (duration), względne ograniczenie czasowe (relative deadline). Zadania, z którymi należy się zmierzyć podczas projektowania systemu czasu rzeczywistego: zidentyfikowanie zdarzeń, na które system powinien reagować, dla każdego zdarzenia i związanej z nim reakcji należy zidentyfikować wymagania czasowe, zdarzenia i reakcje należy zaprojektować we współbieżnych wątkach, dla każdego zdarzenia i reakcji zaprojektować algorytmy do przeprowadzania koniecznych obliczeń. Algorytmy te powinny być opracowane we wczesnej fazie projektu, aby znać ilość przetwarzania i czas potrzebny do jego realizacji, szeregowanie powinno zapewnić, że procesy będą uruchomione w chwili wystarczającej do spełnienia ograniczeń czasowych, integracja wszystkich modułów. Wartość systemu czasu rzeczywistego określana jest poprzez: przewidywalność i szybkość odpowiedzi na ważne zdarzenia, wysoki poziom planowania, stabilność podczas przejściowego przeładowania w sytuacji przeładowania systemu, gdy nie jest możliwe wykonanie wszystkich zadań na czas, system gwarantuje nie przekroczenie deadline dla krytycznych operacji, w przypadku systemu rozproszonego sieć komunikacyjna musi działać stabilnie. Główne moduły wchodzące w skład systemu czasu rzeczywistego: 9

moduł wykonawczy, moduł monitorowania i sterowania, moduł gromadzenia danych o stanach systemu w określonym czasie. Obecnie istnieje kilka systemów operacyjnych czasu rzeczywistego, najważniejsze to: QNX, WxWorks. System rozproszony (distributed system) to zbiór niezależnych węzłów (komputerów) połączonych w jedną, spójną logicznie całość, których zadaniem jest współdziałanie przy wykonywaniu zadań. Połączenie węzłów najczęściej realizowane jest przez sieć komputerową, jednak można wykorzystać również inne, prostsze rozwiązania, np. magistrale systemowe. Cechy systemu rozproszonego: współdzielenie zasobów (resource sharing) zasoby są (mogą być) współdzielone przez wielu użytkowników (klientów), otwartość (openness) możliwość rozbudowy systemu zarówno pod względem sprzętowym, jak i oprogramowania, współbieżność (concurrency) zdolność do przetwarzania wielu zadań jednocześnie, skalowalność (scalability) polega na zachowaniu podobnej wydajności systemu przy zwiększeniu skali systemu (np. liczby procesów, komputerów, itp.), odporność na błędy (fault tolerance) zdolność działania systemu mimo pojawiania się błędów (np. poprzez utrzymywanie nadmiarowego sprzętu), transparentność, przeźroczystość (transparency) postrzeganie systemu przez użytkownika jako całości, a nie poszczególnych składowych. Zadania, z którymi należy się zmierzyć podczas projektowania systemu rozproszonego: projektowanie działania systemu, synchronizacja procesów wykorzystanie koordynatora zarządzającego. Brak centralnego zegara i współdzielonej pamięci (kłopot z określeniem kolejności zdarzeń), planowanie przydziału (schedulling zasobów) przydział zadania do określonego węzła, 10

migracja procesów redystrybucja zadań pomiędzy jednostkami należącymi do systemu, dostęp do sekcji krytycznej może być wąskim gardłem, asynchroniczność wykonywanie zadań w niezdefiniowanej kolejności, bezawaryjność obsługa sytuacji wyjątkowych, awarii, elekcja koordynatora w wyniku awarii (np. algorytm Tyrana), bezpieczeństwo danych ochrona dostępu do zasobów. Jednym z najważniejszych aspektów systemu rozproszonego jest problem przydziału zadań do węzłów systemu. Wyróżnia się dwa podejścia do tego problemu: dzielenie obciążania (load sharing) nowe zadanie jest uruchamiane na jednostce najmniej obciążonej w danym momencie. Proces mający za zadanie dzielenie obciążenia wyszukuje najmniej obciążone węzły systemu, równoważenie obciążenia (load balancing) równoważenie obciążenia pomiędzy wszystkie jednostki. Algorytmy dzielenia obciążenia: token ring jednostki wchodzące w skład systemu tworzą logiczny pierścień. Jednostka będąca w danej chwili posiadaczem tokena ma możliwość wysłania do pozostałych węzłów tokena z żądaniem użycia bezczynnej (najmniej obciążonej) jednostki, program robaka (worm program) wyszukiwana jest bezczynna jednostka, po czym alokowane są na niej potrzebne zasoby do wykonania zadania. Tworzony jest potomek tego procesu, który poszukuje następną bezczynną jednostkę. Gdy zostanie znaleziona odpowiednia liczba jednostek do wykonania zadanie, zostaje ono wykonane, system w górę i w dół istnieje jednostka zwana koordynatorem, która przydziela zasoby jednostki do realizacji zadań. Dodatkowo na każdej jednostce istnieje proces szeregujące zadania na danej jednostce. Projektowanie algorytmów równoważenia obciążenia jest nieco trudniejsze w stosunku do algorytmów dzielenia obciążenia. Potrzebne jest tutaj: porównanie obciążenia pojedynczych jednostek szczególnie trudne w systemach heterogenicznych, 11

umieszczenie procesu badającego obciążenie w odpowiednim węźle, migracja zadań. Algorytmy load balancing można podzielić na dwie główne kategorie: statyczne zadania są przypisywane do jednostek w momencie ich kompilacji, przed rozpoczęciem wykonywania. Nie występuje tutaj migracja zadań (przenoszenie zadań na inną jednostkę w trakcie wykonywania). Dokładne oszacowanie zachowania aplikacji na etapie kompilacji jest zadaniem trudnym, jednak daje wymierne korzyści wynikające z utraty czasu na dokonanie wyboru jednostki do wykonania danego zadania na etapie działania programu oraz braku potrzeby śledzenia stanu systemu (jego obciążenia) podczas działania. Efektywność tych algorytmów w znacznej mierze zależy od możliwości przewidzenia działania systemu, homogeniczności, wielkości zadań, ilości danych komunikacyjnych, dynamiczne zadania są przydzielane do poszczególnych jednostek podczas działania systemu. Może występować migracja zadań przenoszenia zadania na jednostki mniej obciążone od tych, na których w danej chwili wykonywane jest zadanie. Dynamiczne równoważenie obciążenia daje lepsze rezultaty dla zadań, w których trudno jest dokładnie oszacować czas trwania oraz liczbę danych do komunikacji oraz dla aplikacji, których wymagania systemowe mają wiele parametrów. Ta metoda równoważenia obciążenia ponosi koszty czasowe i zasobowe potrzebne do ciągłej analizy obciążenia systemu. Wśród algorytmów dynamicznych wyróżnia się adaptujące się (dynamiczna i modyfikowana redystrybucja zadań), zcentralizowane (istnieje maszyna zwana koordynatorem, która zarządza przydziałem zasobów), rozproszone (w przydziale zasobów uczestniczy wiele węzłów systemu). Przykłady algorytmów równoważących obciążenie: Bryant a i Finkel a tworzone są pary pomiędzy jednostkami, pomiędzy którymi procesy są migrowane. Jeśli w danej chwili jednostka będąca z daną jednostką, na której wykonywane jest zadanie w parze jest mniej obciążona, to na nią migrowane jest zadanie, Barak a i Shiloh a do utrzymywania stanu obciążenia jednostek w systemie wykorzystywany jest wektor obciążenia, który posiada każda jednostka. Dane te są aktualizowane w określonych odstępach czasu przez jednostki oraz połowa takiego wektora jest odsyłana na losowo wybraną jednostkę, 12

symetrycznie inicjowany połączenie dwóch protokołów alokacji zadań inicjowany przez nadawcę i inicjowany przez odbiorcę. W pierwszym przypadku akcja inicjowana jest przez przeciążoną maszynę, która poszukuje jednostki do migracji swojego zadania. W drugiej przypadku inicjatorem jest mało obciążona jednostka, która próbuje uzyskać zadanie od bardziej obciążonej jednostki. Systemy rozproszone w aspekcie systemów czasu rzeczywistego W systemach rozproszonych dąży się do dzielenia obciążenia oraz równoważenia obciążenia. W ogólnym problemie przetwarzania zadań daje to najlepsze pod względem czasowym (w ujęciu całościowym) wykonanie zadań. Jednak w systemach rozproszonych interesuje nas bardziej czas wykonania każdego zadania w ujęciu lokalnym (w obrębie tego zadania). W systemie czasu rzeczywistego zadania mają różne oczekiwane czasy wykonania, różne priorytety, tak więc podczas działania systemu jednostki powinny być obciążone w sposób nierównomierny, aby np. podczas potrzeby wykonania zadania z krytycznymi ograniczeniami czasowymi istniała jednostka, która jest nieobciążona (lub przynajmniej słabo obciążona). Inne przykłady czynników kolidujących ze sobą pomiędzy systemami rozproszonymi, a czasu rzeczywistego: komunikacja sieciowa opóźnienia spowodowane komunikacją negatywny wpływ zarówno dla systemów czasu rzeczywistego jak i rozproszonych szczególnie dla niewielkiej ilości obliczeń w stosunku do ilości danych zadania, zastosowanie koordynatora w systemie rozproszonym staje się wąskim gardłem w systemie czasu rzeczywistego, synchronizacja synchronizacja dostępu do danych (dotyczy również synchronizacji lokalnej współbieżnych wątków) podobnie jak przy komunikacji, wiele węzłów większa możliwość awarii poszczególnych jednostek może to być krytyczne dla pojedynczych zadań (system czasu rzeczywistego), w ujęciu systemu jest to pozytywne, gdyż pojedynczy węzeł ma mały wpływ na cały system (może być łatwo zastąpiony). Pozytywny wpływ systemu rozproszonego na elementy systemu czasu rzeczywistego (straty czasowe): większe możliwości obliczeniowe nwęzłów od pojedynczego, odporność na awarie wiele węzłów, które mogą się zastępować bardzo istotne zarówno w systemach czasu rzeczywistego jak i rozproszonych, 13

bardziej stabilne działanie, otrzymywanie rezultatów na czas. Rozdział II Analiza i charakterystyka systemu 2.1 Zapotrzebowanie przeznaczenie systemu Przeznaczenie systemu dotyczy jego wykorzystania do wykonania konkretnych zadań. System powinien być w jak największym stopniu systemem ogólnego przeznaczenia (tj. powinna być łatwa możliwość podłączania modułów po stronie serwera i klienta, dzięki którym możliwe będzie wykonywanie nowych zadań. System w wersji podstawowej powinien zawierać moduł przetwarzający zadanie matematyczne mnożenie dwóch macierzy. System powinien posiadać następujące cechy i spełniać wymogi: wykonywać zadania na czas (zgodnie ze specyfiką systemu czasu rzeczywistego), wykorzystując do osiągnięcia tego celu algorytmy szeregowania globalnego (przydział jednostki do wykonania danego zadania) oraz szeregowania lokalnego (szeregowanie zadań w danym węźle), stabilność system powinien działać stabilnie przy dużym obciążeniu połączeniami i obliczeniami, modyfikować swoje działanie podczas pracy zmiana algorytmu planowania w przypadku nie spełniania wymagań czasowych wykonywanych zadań, odporność na awarie system powinien w miarę wcześnie wykrywać awarie i wykonywać procedury, które spowodują, że awaria pojedynczych węzłów nie zachwieje działania całego systemu, przezroczystość działania dla użytkownika po stronie klienta system powinien być jak pojedyncza jednostka przetwarzająca, dzielenie obciążenia (load share) i równoważenie obciążenia (load balancing). Dzielenie obciążenia jest specyficzne dla systemów czasu rzeczywistego, zwykłe systemy rozproszone raczej wykorzystują równoważenie obciążenia, obsługa sesji klient jest jednoznacznie identyfikowany, jak również pojedyncze operacje składające się na zadanie, których wykonywanie wywołuje w systemie, są identyfikowane w obrębie tego zadania i obsługi tegoż klienta, 14

monitorowanie i raportowanie działania system monitoruje obciążenie poszczególnych jednostek, jak również wykonywanie zadań w czasie deadline. 2.2 Charakterystyka wykonania poszczególnych zadań Poniżej zostanie zaprezentowane uruchomienie systemu (serwerów i klienta) w kolejnych krokach. Serwer: uruchomienie serwera (dyspozytora), serwer dyspozytor dokonuje inicjalizacji poszczególnych modułów na podstawie pliku (plików) konfiguracyjnego, uruchomienie kolejnego (kolejnych serwerów) operacyjnych (opcjonalnie możliwość uruchamiania wszystkich serwerów z poziomu serwera głównego), serwery operacyjne wczytują plik konfiguracyjny i inicjalizuje odpowiednie moduły, synchronizacja serwera dyspozytora i serwerów operacyjnych, podczas której dochodzi do wymiany podstawowych parametrów i testów (np. wydajności jednostek procesor, pamięć itp.), synchronizacja zegarów, ustanowienia rezerwowych serwerów centralnych na wypadek awarii lub wyłączenia aktualnie zarządzającego serwera, testowania łącza (przepustowość, zmienność przepustowości) parametry te mogą zmieniać się podczas działania systemu, dlatego potrzebna jest okresowe testowanie, każdy serwer zgłasza dyspozytorowi gotowość działania system jest gotowy do użycia, gdy sam się skonfiguruje, dołączanie kolejnych serwerów może nastąpić w dowolnej chwili. Klient: uruchomienie klienta, klient wczytuje podstawowe parametry inicjalizacji, w tym adres dostępu do usługi (oczywiście istnieje możliwość ustawienia tych parametrów przez użytkownika już podczas działania aplikacji klienta z panelu administracyjnego, 15 na żądanie użytkownika (lub automatycznie) następuje połączenie do serwera,

na żądanie użytkownika (lub automatycznie), następuje rozpoczęcie wykonywania zadań (działania systemu). Wykonywanie zadania (zarówno klient jak i serwer są wielowątkowe): zadania i operacje są wczytywane z plików (xml lub properties), fabryki uruchamiają odpowiednie moduły do pobierania zadania, komunikacji z serwerem, odbioru wyników i prezentacji lub zapisu ich rezultatów, klient przesyła kolejne części zadania do serwera dyspozytora lub serwera współpracującego, zadanie wykonane w całości aktualizacja statystyk serwer centralny (oraz konkretni klienci) posiadają statystyki wykonania poszczególnych zadań względem żądanego czasu, algorytmu itp. Scenariusz w przypadku przesłania zadania do systemu serwera dyspozytora: serwer centralny odbiera zadanie i w zależności od deadline oraz priorytetu dokonuje wyboru (algorytm przydziału) serwera operacyjnego, do którego prześle daną część zadania, serwer operacyjny wykonuje zadania (części) i przesyła je do serwera centralnego, który odsyła kolejne części do odpowiedniego klienta. Scenariusz w przypadku przesłania zadania do serwera stacja wybrana na podstawie algorytmu przydziału do wykonania danej części (całości zadania), serwer operacyjny wykonuje operacje i przesyła wyniki bezpośrednio do klienta. Sposób przetwarzania operacji: przydzielenie serwera operacyjnego dla całego zadania klient otrzymuje adres serwera operacyjnego i komunikuje się z nim bezpośrednio w celu wykonania zadania wykorzystywane do mniejszych zadań, zadanie wykonywane przez kilka serwerów klient komunikuje się z serwerem centralnym, który rozporządza przydziałem wykonywania poszczególnych części zadania do serwerów operacyjnych dla średnich i dużych zadań. mix połączenie obu powyższych metod serwer centralny przydziela klientowi serwer operacyjny do wykonania danego zadania. Komunikacja pomiędzy serwerem operacyjnym a klientem jak w pierwszym sposobie, jednak w każdej chwili serwer operacyjny może przydzielić klientowi nowy serwer najbardziej skomplikowana metoda, może dawać bardzo dobre rezultaty dla zadań najdłuższych. 16

Zadanie jest to jednostka logiczna składająca się z operacji pojedyncza operacja to funkcja (analogiczna do funkcji w języku programowania) np. dodawanie dwóch macierzy. Operacja jest dzielona np. dla dodawania macierzy częścią operacji będzie dodawanie pojedynczych wierszy. Osoba tworząca plik zadaniowy używa w nim pojęć tj. zadania i operacji, natomiast podział operacji na części jest dokonywana przez moduł funkcjonalny systemu odpowiedzialny za wykonanie danej operacji. Wyniki operacji są składane przez odpowiedzialny za to zadanie moduł klienta. Rozważane sposoby komunikacji: UDP protokół UDP może zostać wykorzystany do zadań wymagających dużej szybkości wykonania, które są mało wrażliwe na częściowe braki wykonania operacji, TCP dla zadań w których ważniejsze jest otrzymanie odpowiednich i kompletnych wyników od szybkości ich otrzymania. TCP z serializacją Java wykorzystanie mechanizmu serializacji zaimplementowanego w standardzie JDK. W systemie użyte zostały sposób trzeci, jednak zważywszy na zaprojektowanie systemu z położeniem dużego nacisku na: projektowanie interfejsów, polimorfizm (dzięki dziedziczeniu), składowanie obiektów, w dość łatwy sposób można zaimplementować i podłączyć do systemu inne sposoby komunikacji. Do zaimplementowania komunikacji poprzez protokół UDP, należałoby tworzyć pakiet z: adresem klienta, nazwą typu operacji, nazwą operacji argumentami, numerem części zadania. W przypadku protokołu TCP, który jest połączeniowy i automatycznie dołącza adres klienta, pole to można było pominąć. Atrybuty zadania (operacji): 17 deadline, priorytet.

W wyniku wystąpienia sytuacji anormalnych tj. w przypadku awarii serwera operacyjnego serwer dyspozytor wysyła do klienta informacje o tym, jakie operacje nie zostały wykonane. Klient (aplikacja klienta) decyduje o wysłaniu ponownego żądania wykonania tych operacji lub ignoruje tą informację (w przypadku mniej istotnych operacji, ich niewielkiej ilości na podstawie analizy kosztów i zysków odnośnie wymagań czasowych i jakości działania), klient może wywołać ponowne żądanie w przypadku, gdy uzna, że wyniki zadania są niezbędne do prawidłowego działania systemu. Parametry serwerów: wydajność znana podczas startu systemu niezmienna w czasie działania systemu, obciążenie zmienne podczas działania systemu. Przepustowość łącza zmienna podczas działania systemu na skutek: ogólnego obciążenia sieci, obciążenia sieci przez system zadanie może wymagać względnie niewielkiej ilości obliczeń w stosunku do przesyłanych danych i odwrotnie dużej ilości zadań i małej ilości przesyłanych danych. Algorytm przydziału (system posiada kilka algorytmów przydziału) dokonuje wyboru odpowiedniego serwera operacyjnego do wykonania zadania (lub operacji) na podstawie: typu zadania, parametrów serwera, przepustowości łącza. Wykonywanie powinno odbywać się: z wykorzystaniem load sharing moduł odpowiedzialny za nierównomierne obciążenie serwerów. Oczywiście jest on powiązany z algorytmem przydziału (sercem systemu), bezawaryjnie oprócz wspomnianej wcześniej kontroli zagubionych pakietów system posiada również możliwość reorganizacji serwerów na wypadek awarii, przezroczyście dla klienta klient nie jest świadomy istnienia wielu jednostek, system traktowany jest jako całość. Ogólny podział awarii, które mogą wystąpić podczas działania systemu: 18

serwera operacyjnego awaria ta nie powinna w żadnym wypadku powodować poważnych szkód działania systemu, oprócz chwilowych opóźnień czasowych wykonania poszczególnych zadań, serwera dyspozytora awaria ta w skrajnych przypadkach może powodować poważne problemy wykonania poszczególnych zadań (duże opóźnienia czasowe), jednak nie powinna powodować zatrzymania działania systemu, jego załamania. W przypadku wystąpienia awarii system powinien: przeorganizować się poprzez wybór nowego serwera dyspozytora, poinformować klientów o typie awarii (względem poszczególnych zadań i ich priorytetów), w razie potrzeby (żądań klientów) wykonać niewykonane zadania. Bardzo ważne jest informacja dla klientów o stanie awarii, oraz o możliwych opóźnieniach (ich stopniu) w zależności ile zadań uległo zagubieniu na skutek awarii. W wyniku tego klient (aplikacja) będzie miał możliwość podjęcia decyzji o ponownym wykonaniu zadania lub jego zaniechaniu i kontynuowaniu pracy. Rozdział III Projektowanie systemu Projektowanie systemu to najważniejszy element całego przedsięwzięcia. Odpowiednio zaprojektowany system posiada następujące cechy: łatwo modyfikowalny, skalowalny, intuicyjny w obsłudze, Proces projektowania wpływa na wszystkie pozostałe elementy tworzenia systemu tj. jego implementację, testowanie i wdrożenie. Podstawowe składniki systemu będącego tematem niniejszej pracy: biblioteki klasy wspólne dla 3 poniższych składników pracy: narzędzi, serwerów, klientów, narzędzia do tworzenia danych, serwery dyspozytor i współpracujący, Zadaniem serwera współpracującego jest realizacja żądań wykonania zadań przez stacje klientów, ciągła komunikacja z systemem w celu monitorowania działania. 19

Zadaniem serwera dyspozytor jest odbieranie żądań od klientów, zarządzanie dzieleniem obciążenia pomiędzy jednostki wchodzące w skład systemu, monitorowanie działanie całego systemu (wszystkich jednostek wchodzących w jego skład). klient(ci) realizacja odczytu zadań do realizacji, tworzenie interfejsu użytkownika, wysyłanie żądań wykonania zadania do systemu oraz prezentacja wyników. Zaprojektowanie odpowiedniego algorytmu przydziału zadań wymaga zdefiniowania charakterystyki zadań. W systemie czasu rzeczywistego taką charakterystykę można przeprowadzić w oparciu o wymagania czasowe. Wymagania te mogą być znane z wyprzedzeniem, więc równie wcześnie można zaprojektować odpowiedni algorytm. Zadanie z ograniczeniami czasowymi zadanie powinno posiadać następujące parametry: czas rozpoczęcia wykonania, czas trwania (szacowany), żądany czas zakończenia (ang. deadline). Czas rozpoczęcia i wymagany czas zakończenia określany jest mianem czasu życia zadania. Stosunek czasu jego wykonania do czasu życia określa jego wymaganie wykonania, którego wartość im bliższa 1, tym większe zapotrzebowanie na procesor. Biorąc pod uwagę, że zadania mogą mieć różne wymagania czasowe, należy w systemie zaprojektować kilka algorytmów szeregowania lokalnego. Odpowiednie algorytmy można statycznie przydzielić do wykonania określonych zadań, bądź zaprojektować mechanizm, systemu, który będzie wykonywał to automatycznie. Przykładami tych algorytmów są: Round Robin algorytm dynamiczny, wykorzystuje wywłaszczanie. Posiada cykliczną kolejkę zadań, w której zadania są umieszczane zgodnie z algorytmem FIFO (First Input First Output). Zadaniom są przydzielane kolejne kwanty czasu procesora, EDF (Earliest Deadline First) algorytm dynamiczny, wywłaszczający. Regularnie aktualizowane są informacje o deadline poszczególnych zadań, LSTF (Least Slack Time First) najpierw zadanie z najmniejszym luźnym czasem (różnica między żądanym, a przewidywanym czasem wykonania), kombinacyjny biorący pod uwagę kilka parametrów z odpowiednimi wagami, np. połączenie algorytmu EDF i LSTF. Lokalne planowanie wątków opiera się na priorytetach. Istnieją dwa główne rodzaje szeregowania: wywłaszczające jeśli zostanie do kolejki dodane nowe zadanie to wywłaszczy ono aktualnie wykonywane w przypadku, gdy posiada wyższy priorytet, 20