QoS W SYSTEMACH KLASTROWYCH Tomasz Rak Rzeszow

QoS W SYSTEMACH KLASTROWYCH
Tomasz Rak
Rzeszow University of Technology, Control and Computer Engineering Chair, ul.
Wincentego Pola 2, 35-959 Rzeszow
[email protected], tel. (+48 17) 8651767
Quality of Service, systemy klastrowe
Streszczenie
Obecnie, rozwój usług internetowych osiągnął etap, w którym oczekuje się od nich gwarancji
dostępu oraz prawidłowego działania. W niniejszym opracowaniu zostaną przedstawione
podstawowe informacje na temat gwarancji jakości usług (QoS) dla serwisu internetowego
opartego na systemie klastrowym. ZałoŜono, Ŝe serwis internetowy jest w duŜej mierze
niezaleŜny od stosowanych usług i platformy sprzętowej.
Abstract
A stage has at whitch availability and performance guarantees are expected of these web
services. In the paper is presented information to provide Quality of Service (QoS) guarantee
for cluster-based Internet service. It is assumed that the internet service is largely independent
of the service application and the hardware/platform of the cluster.
1. Wstęp
Gwałtowny wzrost wykorzystania Internetu do celów komercyjnych zwiększył wymagania
dla platform sprzętowych, na których bazują poszczególne jego węzły. Nowe zastosowania
wymagają m. in. większej mocy obliczeniowej, szybszej komunikacji, większej szerokości
pasma, bardziej elastycznej kontroli zasobów, większej dostępności i tolerancji błędu.
Obecnie systemy internetowe muszą być bardziej niezawodne (powtarzalność jednorodnej
strukturze), lepiej skalowalne oraz przenośne. Ich zakres działania obejmuje m. in. symulację
on-line zjawisk pogodowych, akwizycję i analizę danych, środków łączności, multimediów,
awioniki, rozłoŜonych rozliczeń finansowych, odzyskiwania informacji, cyfrowych bibliotek i
interfejsów elektronicznych. Nowym wyzwaniem jest wymaganie, aby poprawność działania
aplikacji nie zaleŜała tylko od poprawności wyników, ale teŜ od czasu ich dostarczenia. Tym
wymaganiom moŜe sprostać tylko odpowiednio projektowane architektury systemu oraz
ustalene najbardziej odpowiednie zasady ich działania. System musi być zdolny do
dostarczenia aplikacjom potrzebnych parametrów osiągów taki sposób osiągów i w takim
czasie, aby usługi spełniały zdefiniowane parametry jakościowe QoS (ang. Quality of
Service). Oczekiwania te mogą m. in. spełniać systemy klastrowe, ze względu na ich
moŜliwość dostosowania do zmieniających się potrzeb [7].
2. Systemy klastrowe
Klastry stacji roboczych stają się atrakcyjną ekonomicznie alternatywą dla superkomputerów
przeznaczonych do wysokowydajnych obliczeń. UŜywanie klastrów staje się bardzo
popularną metodą rozwiązywania duŜych i problemów naukowych. Rozbudowane systemy
tego typu są bardziej efektywne i niezawodne (dla np. systemów składowania danych czy
systemów militarnych) niŜ superkomputery.
Jednym z obszarów ich zastosowań jest przetwarzanie baz danych umiejscowionych na wielu
odległych komputerach. Przykładem jest modelowanie map pogody z wykorzystaniem
systemu Paragon (do obliczeń atmosferycznych) i C90 (do modelowania promieniowania
słonecznego).
Luźnie połączone sieci stacji roboczych mają następujące właściwości:
•
Globalna moc obliczeniowa jest dostępna lokalnie.
•
Zmniejszenie czasu odpowiedzi przez wykorzystanie wysokiej mocy obliczeniowej.
•
Stacje są często bezdyskowe po to by proces uruchamiania maksymalnie uprościć.
Poszczególne stacje wchodzące w skład klastra są często własnością określonego
uŜytkownika i wtedy są tak odciąŜane dodatkowymi zadaniami, aby nie zwiększyć czasu
odpowiedzi dla programów właściciela.
Znane od wielu lat komputery wieloprocesorowe SMP (ang. Symmetric MultiProcessing)
rzadko mają więcej niŜ 32 procesory, zaś w maszynach typu NUMA (ang. Non-Uniform
Memory Access) i pokrewnych, kosztownym i skomplikowanym elementem są podsystemy
łączące procesory z pamięcią). Klaster to kilka maszyn połączonych interfejsem
komunikacyjnym, które z punktu widzenia uŜytkownika (konkretnej usługi) są pojedynczym
systemem. Klastry z zasady są tańsze, (choć w przeliczeniu na sumaryczną ilość procesorów i
pamięci nieco mniej wydajne) oraz charakteryzują się wyŜszą dostępnością. Rozwiązanie
klastrowe moŜna zakwalifikować do jednej z trzech grup:
• Klastry HA (ang. High Availability) - Rozwiązania mające na celu zapewnienie ciągłej
(wysokiej) dostępności usług. Poza dublowaniem maszyn w klastrach HA wprowadza się
redundantne połączenia pomiędzy maszynami, wchodzącymi w skład klastra oraz
redundantne połączenia z pamięciami masowymi. Poszczególne węzły klastra HA
kontrolują działanie "sąsiadów" przy pomocy protokołu „bicia serca” (ang. heartbeat
protocol). Po stwierdzeniu niedostępności monitorowanej usługi, jest ona przejmowana
przez inny węzeł. Klaster HA moŜna zorganizować na kilka sposobów. MoŜe on zawierać
węzły wolne, oczekujące na przejęcie ruchu od węzłów pracujących lub wszystkie węzły
mogą udostępniać pewne usługi i wzajemnie się monitorować. W drugim przypadku
klaster moŜe dodatkowo równowaŜyć obciąŜenie. Poszczególne węzły mogą udostępniać
tę samą usługę i wzajemnie się zastępować.
•
Klastry obsługujące bazy danych - Przeznaczone do uruchamiania duŜych baz danych lub
hurtowni danych (ang. data warehouse). Podstawowym zadaniem klastra jest tu
równowaŜenie obciąŜenia związanego ze skomplikowanym przetwarzaniem duŜych ilości
danych. Aby zapewnić poprawne działanie tego typu systemów konieczne jest wsparcie
ze strony systemów bazodanowych. Wszystkie najpopularniejsze systemy zarządzania
bazami danych mają wsparcie dla wybranych rozwiązań klastrowych.
•
Klastry do obliczeń równoległych HPC (ang. High Performance Computing) równowaŜą
obciąŜenie związane z obliczeniami. Stosowane są głównie do uruchamiania aplikacji
inŜynierskich i symulacji w warunkach laboratoryjnych. Zarządzanie obciąŜeniem leŜy
zwykle w gestii samych aplikacji (PVM - ang. Parallel Virtual Machine, MPI - ang.
Message Passing Interface), zaś klaster powinien oferować wygodne mechanizmy
komunikacji i odpowiednie biblioteki oraz narzędzia do monitorowania obciąŜenia i
rozliczania uŜytkowników [6] [8] [9].
Architektura klastra sieciowego (internetowego)
Klastry internetowe moŜna zaliczyć do dwóch głównych grup: HA i bazodanowych.
Architektura klastra internetowego jest wielowarstwowa. W architekturze tej wyróŜnia się co
najmniej trzy warstwy:
-
serwerów internetowych,
-
aplikacji internetowych,
-
serwerów bazy danych.
Klaster internetowy ma dość złoŜoną architekturę. Jest ona uwarunkowana koniecznością
realizacji róŜnych funkcji oraz wielu czynników obocznych.
NajwaŜniejszym z nich jest bezpieczeństwo. Jak wiadomo serwery internetowe naraŜone są w
największym stopniu na ataki z zewnątrz. Dzięki warstwowej strukturze moŜliwe jest
umieszczenie pomiędzy poszczególnymi warstwami „zapór ogniowych” tzw. Firewall-i.
Innym waŜnym czynnikiem jest zapewne niezawodność systemu, tak aby nawet w wypadku
awarii była moŜliwa ingerencja z zewnątrz, która umoŜliwi uruchomić ponownie system.
Dzięki wykorzystaniu architektury wielowarstwowej moŜliwe jest wyeliminowanie
krytycznych punktów, których awaria mogłaby unieruchomić cały system a co za tym idzie
zablokować wszystkie usługi [1].
Systemy klastrowe (Linux)
Systemy operacyjne stosowane w rozwiązaniach klastrowych to głownie Linux i BSD. Fakt
ten rodzi tylko pytanie o przyszłość. Metodologia rozwoju, która doprowadziła Linux-a do
szczytów popularności, ma jednak pewne ograniczenia. Aby dopracować konkretny aspekt
systemu, potrzebne jest odpowiednie wsparcie ze strony programistów, zainteresowanych
rozwiązaniem tego problemu - np. przeniesienie systemu na konkretną platformę sprzętową
moŜliwe jest tylko wtedy, gdy odpowiednio duŜo osób ma stosowny sprzęt. To samo dotyczy
funkcjonalności. Trudno spodziewać się duŜego wsparcia dla funkcjonalności
charakterystycznej dla bardzo duŜych systemów. Organizacje potrzebujące wielkich
systemów z reguły stać na zakup ich wersji komercyjnych. Z tych powodów Linux
znakomicie sprawuje się na popularnym sprzęcie (x86), ale znacznie gorzej na mniej
popularnym i słabiej udokumentowanym maszynach RISC-owych (ang. Reduced Instruction
Set Computing/Computer).
Wraz ze wzrostem popularności Linux-a oprogramowaniem (Open Source) zainteresowały się
równieŜ wielkie firmy. Niektóre z nich partycypują w rozwoju Linux-a, jednak nie zawsze są
one zainteresowane zwiększaniem skalowalności darmowego oprogramowania. Z pomocą
przyjść mogą firmy Linux-owe zarabiające głównie na usługach czy wsparciu technicznym
oraz firmy produkujące sprzęt. Przyszłość oprogramowania Open Source jako platformy highend nie jest do końca jasna, choć zanosi się na to, Ŝe w przyszłości open source będzie
skutecznie konkurować z największymi systemami komputerowymi.
Linux jest sztandarowym produktem społeczności Open Source. Rozwijany od prawie
dziesięciu lat, jest chyba najbardziej przenośnym systemem operacyjnym ogólnego
zastosowania. Jako system 64-bitowy działa na platformach Alpha, IA-64, MIPS i SPARC.
Jego duŜa uniwersalność, względnie duŜa stabilność i niskie koszty utrzymania sprawiły, Ŝe
stał się najpopularniejszą platformą wśród serwerów internetowych.
Na razie Linux nadaje się przede wszystkim do budowy małych i średnich serwerów i
przewyŜszając moŜliwości Windows NT - przeznaczonego dla tego samego segmentu rynku stanowi dlań bezpośrednią konkurencję. Cechą charakterystyczną systemu Linux jest jego
otwartość - dostępne oprogramowanie pozwala działać jako serwer sieci lokalnej, serwer
internetowy, serwer aplikacji, router, stacja robocza, a nawet jako komputer biurowy (jest
trudniejszy w konfiguracji i ma znacznie mniej oprogramowania, ale jest łatwiejszy i tańszy w
utrzymaniu). Wielkie firmy produkujące oprogramowanie komercyjne przeniosły juŜ swoje
produkty na Linuksa. Dostępne są m.in. serwery baz danych (IBM DB2, Oracle 8i, Informix,
SAP DB, Adabas, Interbase), serwery aplikacji (Oracle WebDB, IBM WebSphere),
środowisko Java (Sun, IBM). Wielość dostępnych dystrybucji pozwala wybrać system o
odpowiadającej charakterystyce i konfiguracji. Coraz powszechniejsze są pakiety
umoŜliwiające tworzenie klastrów przy wykorzystaniu systemu Linux. Producenci duŜych
systemów operacyjnych typu Unix, zapewnia zgodność ich systemów z Linux-em. Wsparcie
dla Linux-a potentatów rynku informatycznego jest faktem.
3. Jakość usług - Quality of Service
W pierwszej kolejności jakość usług była definiowana dla sieci komputerowych. O sieci,
której wydajność róŜni się w zaleŜności od aplikacji Ŝądających do niej dostępu mówi się, Ŝe
ma klasę lub teŜ jakości usług - QoS. QoS jest wskaźnikiem wyróŜniającym sieć spośród
wielu innych.
QoS jest to taka zdolność dowolnych elementów sieci (np. aplikacji, hosta czy routera), która,
daje im moŜliwość zapewnienia takiego natęŜenia ruchu oraz poziomu jakości oferowanych
usług sieciowych, aby były one satysfakcjonujące dla jej końcowego uŜytkownika. MoŜna
powiedzieć, Ŝe im wyŜszy wskaźnik usług QoS, tym szybszy dostęp i mniejsze opóźnienie.
Przez przypisanie aplikacji do róŜnych poziomów QoS moŜemy zróŜnicować wydajność, jaką
będą miały nasze aplikacje, zgodnie z wymaganiami stawianymi sieci. Aby zapewnić QoS
wymagana jest współpraca na wszystkich poziomach sieci (from top-to-buttom), jak równieŜ
we wszystkich jej elementach (from end-to-end).
Przez ostatnie lata, QoS rozwinął się na polu wspomagania nowych typów aplikacji, bardzo
często równieŜ w sieciach i systemach komputerowych. Celem mechanizmów QoS jest
zapewnienie (gwarancja) określonych zasad i obiecywanych wymogów.
NajwaŜniejsze cechy, z punktu widzenia zarządzania siecią (1-5), z punktu widzenia klienta
(6-10), to [3], [4], [10], [11], [12], [13]:
1. Koszty (ang. Cost).
2. Konkurencyjna cena (ang. Competitiveness).
3. Wydajność (ang. Efficiency).
4. Małe koszty wdroŜenia (ang. Implementation costs).
5. Małe koszty uŜytkowania (ang. Usage costs).
6. Jasność i zrozumiałość (ang. Comprehensibility).
7. MoŜliwość łatwej kontroli (ang. Controllability).
8. Przewidywalność zachowania (ang. Predictability).
9. Stabilność (ang. Stability).
10. Sprawiedliwy podział zasobów (ang. Fairness).
Dokładnie, jakie atrybuty (jakości usług), powinny spełniać klastrowe systemy operacyjne
jest wciąŜ sprawą otwartą. PoniŜej podano krótką listę najbardziej poŜądanych cech: łatwość
zarządzania, otwartość, skalowalność, funkcjonalność, dostępność, moŜliwość rozbudowy i
wymiany elementów, tolerowanie awarii, spójność, jakość połączeń, niejednorodność,
wsparcie, stabilność, przezroczystość, bezpieczeństwo, synchronizacja, cena, czas reakcji, itp.
Lista ta nie wyczerpuje zapewne tematu, ale jest dobrym wstępem do pojęcia QoS w
systemach klastrowych. Przedstawione zostaną teraz, bardziej szczegółowo, najwaŜniejsze z
nich:
•
Łatwość zarządzania, administrowania (ang. Manageability) – Absolutną koniecznością
jest zdalne i intuicyjne administrowanie systemem. Jest to często kojarzone z Single
System Imane (SSI), który moŜe być zrealizowany na róŜnych poziomach, sięgając od
wysokiego poziomu ustawień specjalnych skryptów, aŜ po rzeczywisty podział stanów na
poziomie systemu operacyjnego (OS).
•
Stabilność (ang. Stability) –Stabilność jest osiągana przez wykluczenie częstych zmian.
Nic nie powinno zmuszać lub zachęcać nas do wprowadzania zmian w działającym
poprawnie systemie. Stabilność systemu jest bardzo waŜną rzeczą w chwilach duŜego
obciąŜenia systemu.
•
Rozszerzalność, moŜliwość rozbudowy (ang. Extensibility) – System operacyjny
powinien pozwalać na łatwą integrację ze specyficznymi klastrowymi rozszerzeniami.
Aby to uzyskać konieczne jest posiadanie kodu źródłowego, poniewaŜ ujawnia to
wszystkie wewnętrzne szczegóły i pozwala na modyfikacje funkcjonalności. Dobrym
przykładem takiego system klajstrowego jest MOSIX bazujący na Linux-ie.
•
Skalowalność (ang. Scalability) – Skalowanie systemu w obrębie jednej maszyny ma
oczywiście swoje ograniczenia (polegające np. na ograniczeniu liczby węzłów). Systemy
operacyjne działające na klastrze muszą być przystosowane do zmian konfiguracji "w
locie". Skalowalność moŜna rozpatrywać w kilku aspektach:
•
•
Sposób reakcji systemu na wzrost obciąŜenia. Zbyt duŜe obciąŜenie moŜe
doprowadzić do przerwania działania systemu lub jego przeciąŜenia gwałtownego spadku jego wydajności.
Trudno jest dodawać do systemu nowy sprzęt (procesory, pamięć, dyski,
urządzenia we/wy).
•
•
To samo środowisko moŜe obsługiwać małe, średnie i duŜe serwisy oraz rozwijać
się wraz ze wzrostem wymagań.
Wsparcie (ang. Support) – Wiele inteligentnych, technologicznie lepszych rozwiązań w
informatyce nie nadaje się do wykorzystania z powodu braków w: oprogramowaniu,
sterownikach lub narzędziach. Wsparcie zaleŜy głównie od liczby uŜytkowników
głównego systemu, którzy w kontekście klastrów głównie wpływają na koszt sprzętu.
Dodatkowo, wsparcie dla sprzętu do połączeń między węzłami.
•
Niejednorodność (ang. Heterogenity) – Klastry dostarczają dynamicznego sposobu
zarządzania, dzięki czemu mogą być one rozszerzane lub ograniczane na róŜnym sprzęcie,
dokładnie tak jak uŜytkownik potrzebuje lub pozwala. Dlatego teŜ zarządzanie klastrami
nie wymaga jednorodnego sprzętu. To wymaganie, takŜe powoduje, Ŝe sam system
operacyjny powinien pozwalać na zróŜnicowaną architekturę. JeŜeli taki system
operacyjny nie istnieje dla danego sprzętu, naleŜy uŜyć innego.
•
Spójność (ang. Cohesion) - W zaleŜności od rozwiązania system moŜe rzeczywiście
przypominać pojedynczą, równoległą maszynę (ze wspólną przestrzenią identyfikatorów
procesów, wspólnymi zasobami, urządzeniami itd.) lub szybką sieć maszyn mających
jedynie wspólny system plików i oprogramowanie wspomagające uruchamianie aplikacji
równoległych. UŜytkownik korzysta z klastra w łatwy i efektywny sposób bez znajomości
wewnętrznej architektury systemu. Środowisko operacyjne wydaje się znajome (poprzez
znany interfejs komunikacyjny) i wygodne do uŜytku. UŜytkownik ma pełny widok
globalnego systemu plików, procesów i sieci. Na przykład: w klastrze z pojedynczym
punktem wejścia, uŜytkownik moŜe się zalogować na dowolnym węźle. Administrator
systemu instaluje oprogramowanie na węźle dowolnego uŜytkownika, a jest ono widoczne
na przestrzeni całego klastra. W systemach rozproszonych trzeba instalować to samo
oprogramowanie dla kaŜdego węzła. Szczegóły zarządzania zasobami i kontroli
aktywności jak: przydział, zwalnianie i kopiowanie zasobów, są niewidoczne dla
procesów uŜytkownika. Pozwala to uŜytkownikowi na dostęp do zasobów systemowych
jak: pamięć, procesory i sieć, przezroczyście, niezaleŜnie czy są one dostępne lokalnie czy
zdalnie.
Dostępność (ang. Availability) - Wymienione systemy muszą charakteryzować się duŜą
dostępnością. Usługi oprogramowania pośredniczącego muszą być zawsze dostępne. W
dowolnym czasie, punkt awarii powinien być moŜliwy do naprawy bez oddziaływania na
działające aplikacje uŜytkowników. MoŜna to osiągnąć poprzez zorganizowanie punktów
kontrolnych i technologii tolerancji błędów (szybkie przechodzenie w stan spoczynku,
dublowanie i omijanie błędów).
•
•
Tolerowanie awarii (ang. Failure Tolerance) - Musi istnieć moŜliwość rozbudowy i
wymiany poszczególnych elementów systemu podczas pracy (ang. hot swap) oraz pewna
redundancja, umoŜliwiająca tolerowanie awarii. Kiedy usługi są udostępniane przy uŜyciu
zasobów systemowych na wielu węzłach, awaria któregokolwiek węzła nie powinna
wpływać na funkcjonalność systemu. Na przykład: kiedy system plików jest rozdzielony
między wiele węzłów z pewnym stopniem redundancji, gdy węzeł ulega awarii, wtedy
fragment systemu plików moŜe być przemieszczony do innego węzła w sposób
niewidoczny dla uŜytkownika końcowego.
•
Jakość połączeń i rozmieszczenie geograficzne (ang. Quality Connection) - Klaster moŜe
mieć większe lub mniejsze wymagania, co do jakości i szybkości połączeń pomiędzy
węzłami. W klastrach wymagających bardzo szybkich połączeń moŜe zaistnieć
konieczność umieszczenia wszystkich węzłów w jednym miejscu, w wyniku czego system
nie jest odporny np. na klęski Ŝywiołowe. Systemy klastrowe równie dobrze mogą być
•
budowane z węzłów znajdujących się na duŜym obszarze. W takim wypadku na pewno
szybkość ulegnie pogorszeniu, jednak wzrośnie jego niezawodność i niezaleŜność od
czynników zewnętrznych.
Czas reakcji (ang. Response Time) – Czas, w jakim system zareaguje nie jest sprawą
obojętną. Reakcja musi być ściśle określona, a jej czas z góry załoŜony i spełniony. Nie
zachowanie norm czasowych nie pociąga za sobą utraty danych, ale jeŜeli chcemy, aby
jakość usług została zachowana to czas ten ma bardzo duŜy wpływ na system i nie moŜe
zostać wydłuŜony.
4. Jakość usług w systemach czasu rzeczywistego
Systemy czasu rzeczywistego RT (ang. real-time) są definiowane jako takie systemy, w
których poprawność działania zaleŜy nie tylko od logicznego wyniku obliczeń, ale teŜ od
czasu, w jakim te wyniki są otrzymywane. Systemy RT uprawniają do wykonywania
specjalnych zadań w czasie rzeczywistym i obsługę przerwań. Te zadania musza zostać
wykonane niezaleŜnie od innych. Na przykład dla systemu RTLinux w najgorszym przypadku
czas między momentem, kiedy przerwanie sprzętowe jest wykryte przez procesor, a
momentem kiedy przerwanie programu obsługi zaczyna się wykonywać, wynosi poniŜej 15
mikrosekund (dla komputerów x86) [14], [16].
Zwykle, system czasu rzeczywistego składa się z systemu kontrolującego i systemu
kontrolowanego. DuŜy odsetek aktualnie zaimplementowanych systemów czasu
rzeczywistego jest dynamiczne w swojej naturze. Co waŜniejsze, będą musiały być
utrzymywane i rozszerzane naleŜnie z ich ewoluującą naturą i projektowanym długim czasem
Ŝycia. Z powodu tych właściwości, systemy czasu rzeczywistego muszą spełniać wskaźniki
jakości usług. Ich zapewnienie gwarantuje zachowanie ograniczeń czasowych w systemach z
krytycznym czasem wykonywania usług.
Z punktu widzenia zadań czasu rzeczywistego najwaŜniejsze są: przewidywalność, szybkość,
niezawodność, elastyczność, przetwarzanie zadań, itd. Oto one:
•
Przewidywalność – Jest chyba najwaŜniejszym wymogiem jaki musi spełniać warstwa
przesyłania wiadomości czasu rzeczywistego i implikuje determinizm w opóźnieniu
wiadomości. Mówi się o niej wtedy, gdy zadanie lub komplet zadań są aktywowane i
powinno być moŜliwe określenie czasu ich zakończenia. Musi być to jeszcze rozpatrzone
z uwzględnieniem relacji stanu systemu i zadań potrzebujących tych zasobów.
Nieprzewidywalność moŜe w efekcie powodować katastrofalne konsekwencje. Mówimy o
systemach twardych czasu rzeczywistego i systemach miękkich czasu rzeczywistego.
Zadania twardych systemów czasu rzeczywistego są bardziej trudne w realizacji niŜ
zadania systemów miękkich czasu rzeczywistego. Systemy, które obejmowałyby oba typy
równocześnie są jeszcze bardzo trudne w realizacji [15].
•
Szybkość – Nie chodzi tu o jak najszybsze wykonanie zadań, ale o poprawne ich
wykonanie w jak najkrótszym czasie. Szybkość jest więc warunkiem koniecznym, ale
niewystarczającym wykonywania zadań.
•
Niezawodność - Większość systemów czasu rzeczywistego działa z surowymi
wymaganiami niezawodności. Te zadania zwykle mają zagwarantowane wykonanie się w
nieprzekraczalnym terminie, w wyniku wcześniejszych analiz off-line i programów
rezerwujących zasoby dla tych zadań nawet, jeśli to oznacza, Ŝe te zasoby są najczęściej
bezczynne. Inaczej mówiąc, wymagane jest od zadań krytycznych, aby wszystkie
wykonywały się w nieprzekraczalnym terminie (100% gwarancji), przyjmując
wystąpienie pewnych defektów i dodatkowych obciąŜeń.
•
Elastyczność – Systemy czasu rzeczywistego muszą w łatwy sposób przystosowywać się
do nowych oczekiwań. Brak elastyczności takiego systemu jest równieŜ pewnym
ograniczeniem.
•
Rodzaje szeregowania zadań - UŜywając indywidualnego podejścia do sposobów
szeregowania zadań, moŜna przewidywać, Ŝe wykonywane zadania nie będą przekraczać
określonych dla nich limitów czasowych.
Dodatkowo duŜe znaczenie mają:
•
Funkcjonalność,
•
Tolerowanie awarii,
•
Spójność,
•
Jakość połączeń,
•
Stabilność,
•
Wydajność,
•
Skalowalność,
•
Bezpieczeństwo.
Zapewne nie są to wszystkie moŜliwe właściwości QoS jakie dotyczą systemów RT. MoŜna
powiedzieć, Ŝe są to najwaŜniejsze z nich.
5. Wnioski
Dostępne systemy klastrowe mogą uwzględniać tylko niektóre z powyŜszych właściwości
QoS, chociaŜ dostępnych jest coraz więcej klastrów uniwersalnych. Rozwiązania
poszczególnych producentów znacznie róŜnią się między sobą. Niektóre z wymienionych
właściwości zachodzą na siebie. Trzeba zaznaczyć równieŜ, jak pokazują doświadczenia, Ŝe
cele QoS mogą być wzajemnie sprzeczne. Dla przykładu, zapewnienie, określonych usług na
poziomie systemu operacyjnego, drastycznie ogranicza skalowalność. Innym przykładem jest
dostępność otwartego kodu wraz z moŜliwością do rozszerzania systemu operacyjnego na tej
bazie. Dostępność ta ma negatywny wpływ na stabilność systemu. Po pewnym czasie wiele
rodzajów systemu operacyjnego będzie rozwijane i jego róŜne rozszerzenia mogą być
wzajemnie sprzeczne, dlatego waŜną jest odpowiednia koordynacja prac. Zadaniem
projektanta sytemu jest więc, dokładne określenie potrzeb i następnie dobranie do nich
stosownego rozwiązania [2] [5].
Bibliografia:
[1] Cardellini V., Casalicchio E., Colajanni M.: A Performance Study of Distributed
Architectures for the Quality of Web Services, Proc. of Hawaii Int'l Conf. on System Sciences
(HICSS-34), Software Technology Track, Maui, Hawaii, pp. 3551-3560, Jan. 2001. IEEE
Computer Society.
[2] Cardellini V., Casalicchio E., Colajanni M.: Mechanisms for Quality of service in Web
clusters, Computer Networks, Elsevier Science, Vol. 36, No. 6, pp. 759-769, Nov. 2001.
[3] Baker M., Buyya R.: Cluster Computing at a Glance, volume 1 of High Performance
Cluster Computing, pp. 246-269, Prentice Hall PTR, May 1999.
[4] Barak A., La’adan O.: The MOSIX Multicomputer Operating System for High
Performance Cluster Computing, Journal of Future Generation Computer Systems, April
1998.
[5] Zhao W., Olshefski D., Schulzrinne H.: Inetrenet Quality of Service: an Overview,
Technical Report CUCS-003-00, Columbia Univ., Computer Since Dept., Feb. 2000.
[6] Chiola G., Ciaccio G.: Operating Systems Support for Fast Communications in a Network
of Workstations, http://www.disi.unige.it/person/ChiolaG/.
[7] Hwang K., Jin H., Chow C., Wang C., Xu Z.: Designing SSSI Clusters with Hierarchical
Checkpointing and Single I/O Space, IEEE Concurrency, Los Alamitos, USA, IEEE
Computer Society, pp. 60-69, 1999.
[8] Bernard G., Simatic M.: A Decentralized and Efficient Algorithm for Load Sharing in
Networks of Workstations, In Proc. EurOpen Spring '91 Conference, Tromso (Norway), May
1991.
[9] Geist G.: Cluster Computing: The Wave of the Future? , Parallel Scientific Computing,
First International Workshop, PARA '94, Lyngby, Denmark, June 20-23, pp. 236-246, 1994.
[10] WhitePaper: The Need for QoS, The Internet Protocol’s „best-effort” service has worked
well so far, so why do we need to change it?, http://www.stardust.com/.
[11] Steinmetz R., Wolf L., Hutchison D.: Quality of Service: Where are We? , IWQoS2001
(Proceedings of the 9th International Workshop on Quality of Service), Vol. 2092 in Lecture
Notes in Computer Science. Springer-Verlag, Heidelberg, 2001.
[12] Ferrari D., Delgrossi L.: Charging For QoS, CTR-T98-003, Piacenza, Aprile 1998.
[13] Moorsel A., Aad P.: Metrics for the Internet Age: Quality of Experience and Quality of
Bisiness, HP Labs Technical Report.
[14] Yodaiken V., Barabanow M.: RTLinux Version Two, LinuxJournal, 34, February1997.
[15] Stankovic J., Ramamrutham K.: What is Predictability for real-Time Systems, Real-Time
Systems Journal, vol. 2, pp. 247-254, December 1990.
16. Stankovic J.: Misconceptions about real time computing: A serious problem for nextgeneration systems, IEEE Computer, vol 21, no. 10, October 1988.