Wprowadzenie do systemów rozproszonych Rodzaje systemów Systemy osobiste, które nie są rozproszone i są przeznaczone do pracy na komputerze osobistym lub stacji roboczej. Przykładami takich systemów są m.in. procesory tekstów, arkusze kalkulacyjne, systemy graficzne itd.. Systemy wbudowane, które działają na jednym procesorze lub na zintegrowanej grupie procesorów. Przykładami takich system.ów są m.in. systemy sterowania sprzętem domowym, systemy sterujące przyrządami. Systemy rozproszone, w których oprogramowanie systemowe działa na luźno zintegrowanej grupie współpracujących procesorów połączonych siecią. Przykładami takich systemów są m.in. systemy bankomatów, systemy rezerwacji, systemy pracy grupowej itd. 1
Co to jest system rozproszony? Systemem rozproszonym nazywamy taki system, w którym przetwarzanie informacji odbywa się na wielu komputerach, często znacznie oddalonych geograficznie (od kilku metrów do dziesiątków tysięcy kilometrów). Przeciwieństwem jest system izolowany lub scentralizowany. Obecnie właściwie wszystkie systemy są rozproszone. Ogromnym katalizatorem rozproszenia systemów jest Internet. Projektowanie i własności systemów rozproszonych w dużej mierze są takie same jak systemów scentralizowanych, ale istnieją także istotne różnice, który specjalista inżynierii oprogramowania musi być świadomy. Tendencja do budowy systemów rozproszonych jest pochodną rozbudowy tanich, szybkich, uniwersalnych i niezawodnych sieci komputerowych. Przykłady systemów rozproszonych: sieć bankomatów, system rezerwacji biletów, system pracy grupowej, itd. Nową jakość do tematu systemów rozproszonych wnoszą sieci P2P (Peer-To-Peer) oraz technologie gridowe (grid computing). Zalety systemów rozproszonych (1) Podział zasobów: system rozproszony pozwala dzielić zasoby sprzętowe i programowe pomiędzy wielu użytkowników pracujących na różnych komputerach pracujących w sieci. Otwartość: jest ona definiowana jako zdolność systemu do dołączania nowego sprzętu, oprogramowania i usług. Najlepiej na platformach sprzętowych i systemach operacyjnych dostarczanych przez różnych dostawców. Współbieżność: w systemie rozproszonym wiele procesów może działać w tym samym czasie na różnych komputerach w sieci. Procesy te mogą komunikować się podczas swego działania. Skalowalność: Moc i możliwości przetwarzania może wzrastać w miarę dodawania do systemu nowych zasobów, w szczególności komputerów. W praktyce skalowalność jest często ograniczona poprzez przepustowość sieci oraz (niekiedy) poprzez np. specyficzne protokoły wymiany informacji. Niemniej skalowalność systemu rozproszonego jest nieporównywalnie lepsza w stosunku do systemu scentralizowanego. 2
Zalety systemów rozproszonych (2) Tolerancja błędów: Dostępność wielu komputerów oraz umożliwienie zdublowania informacji (replikacje) oznacza, że rozproszony system jest tolerancyjny w stosunku do pewnych błędów zarówno sprzętowych jak i programowych. Np. awaria węzła komunikacyjnego powoduje wygenerowanie innej trasy przepływu informacji. Przezroczystość: Oznacza ukrycie przed użytkownikiem szczegółów rozproszenia, np. gdzie ulokowane są zasoby lub jak są one fizycznie zaimplementowane, pod jakim systemem pracują, itd. Przezroczystość ma zasadnicze znaczenie dla komfortu działania użytkownika oraz dla niezawodności budowanego oprogramowania. Niekiedy, np. dla celów optymalizacyjnych, użytkownik może zrezygnować z pełnej przezroczystości. Przykładem przezroczystości jest Internet: klikając w aktywne pole na stronie WWW nie interesujemy się, gdzie znajduje się odpowiadająca mu strona, oraz jak i na czym jest zaimplementowana. Wady systemów rozproszonych Złożoność: systemy rozproszone są trudniejsze do zaprogramowania i do administrowania niż systemy scentralizowane. Zależą od własności sieci, np. jej przepustowości i czasu transmisji, co utrudnia zaprojektowanie i zrealizowanie wielu algorytmów i procesów przetwarzania. Ochrona: Dla systemu scentralizowanego wystarcza w zasadzie strażnik z karabinem. System rozproszony nie może być chroniony w ten sposób, przez co może być narażony na różnorodne ataki (włamania, wirusy, sabotaż, odmowa płatności, itd.) z wielu stron, które trudno zidentyfikować. Zdolność do zarządzania: jest ona utrudniona wskutek tego, że konsekwencje różnych działań administracyjnych w systemie rozproszonym są trudniejsze do zidentyfikowania. Podobnie z przyczynami sytuacji anormalnych, w szczególności awarii. Nieprzewidywalność: system rozproszony jest nieprzewidywalny w swoim działaniu, ponieważ zakłócenia mogą być powodowane przez wiele przyczyn: małą przepustowość i awarię łączy, awarię komputerów, zbyt duże obciążenie danego serwera, lokalne decyzje administracji serwera, itd.; patrz WWW. 3
Krytyczne zagadnienia projektowe dla systemów rozproszonych Identyfikacja zasobów: zasoby są podzielone pomiędzy wiele komputerów, w związku z czym schematy ich nazywania muszą być zaprojektowane tak, aby użytkownicy mogli zidentyfikować interesujące ich zasoby. Przykładem takiego schematu jest URL znany z WWW. Komunikacja: może być zaprojektowana w sposób uniwersalny, na bazie np. protokołu internetowego TCP/IP. Niektóre wymagania dotyczące szybkości, kosztu, niezawodności lub bezpieczeństwa mogą prowadzić do specjalnych technik komunikacyjnych. Jakość obsługi: odzwierciedla wydajność systemu, jego dostępność i niezawodność. Podlega ona wielu czynnikom, w szczególności, przypisaniu zadań do procesorów, optymalności geograficznego podziału danych, itd. Architektura oprogramowania: opisuje ona w jaki sposób funkcjonalności systemu są przypisane do logicznych i fizycznych komponentów systemu. Wybór dobrej architektury przesądza o spełnieniu kryterium jakości obsługi. Popularne architektury rozproszenia Klient-serwer: rozproszony system ma wyróżniony węzeł zwany serwerem, oraz szereg podłączonych do niego węzłów zwanych klientami. Związek nie jest symetryczny: serwer wykonuje usługi zlecane przez klientów, nie może im odmówić i nie może im zlecić wykonanie usług. Klient-multi-serwer: podobnie jak dla architektury klient-serwer, ale istnieje wiele serwerów, np. WWW. Koleżeńska (peer-to-peer, P2P): wiele węzłów świadczy sobie wzajemne usługi poprzez bezpośrednie połączenie; nie ma wyraźnego podziału na usługodawców i usługobiorców. Np. Gnutella, NXOR, Napster, Kazaa; JXTA jako narzędzie do P2P. Komercyjny buzz dookoła P2P. Architektura oparta na oprogramowaniu pośredniczącym (middleware): nie występuje podział na klientów i serwery, np. CORBA i WebServices. Architektury gridowe: wirtualny komputer sumujący zasoby wielu komputerów w sposób przezroczysty dla użytkowników. 4
Architektury wieloprocesowe Najprostszym modelem systemu rozproszonego jest system wieloprocesorowy, składający się z kilku różnych procesorów, które mogą (ale nie muszą) działać na oddzielnych procesorach. Z logicznego punktu widzenia procesory zajmujące się zbieraniem informacji, podejmowaniem decyzji i sterowaniem efektorami mogłyby działać na jednym procesorze sterowanym przez moduł szeregujący. Użycie wielu procesorów poprawia efektywność i odporność systemu. Przydział procesów procesorów może być zadany z góry (tak zwykle jest w systemach krytycznych) albo sterowany przez dyspozytora, który decyduje o przyznaniu procesora procesowi. System wieloprocesorowy do kierowania ruchem Procesory detektorów Proces sterujący detektorem Procesory natężenia ruchu Proces wyświetlający Procesory sterujące światłami Proces sterujący światłami Detektory natężenia ruchu i kamery Konsole operatorów Światła 5
Architektury klient-serwer W takiej architekturze program użytkowy jest modelowany jako zbiór usług oferowanych przez serwery i zbiór klientów, którzy z tych usług korzystają. Klienci muszą znać dostępne serwery, ale zwykle nie muszą wiedzieć o istnieniu innych klientów. Klienci i serwery są oddzielnymi procesami. Procesy i procesory systemu nie muszą być wzajemnie jednoznacznie przyporządkowane. System klient-serwer k1 k2 k3 s1 k4 s4 k12 k11 Proces serwera k5 s2 s3 k10 k9 Proces klienta k6 k7 k8 6
Komponenty w sieci klient-serwer k1 k2 k3, c4 KK1 KK2 KK3 s1, s2 Sieć s3, s4 SK2 SK1 Komputer serwera k5, k6, k7 KK4 KK5 k8, k9 k10, k11, k12 KK6 Komputer klienta Warstwy programu użytkowego Warstwa prezentacji dotyczy przedstawiania informacji użytkownikowi i całego kontaktu z użytkownikiem. W warstwie przetwarzania implementuje się logikę programu użytkowego. Warstwa zarządzania danymi jest odpowiedzialna za wszystkie operacje na bazie danych 7
Warstwy programu użytkowego Warstwa prezentacji Warstwa przetwarzania Warstwa zarządzania danymi Rodzaje architektury klient-serwer Model klienta cienkiego W tym modelu całość przetwarzania i zarządzania danymi ma miejsce na serwerze. Jedynym zadaniem klienta jest uruchomienie oprogramowania prezentacyjnego. Model klienta grubego W tym modelu serwer odpowiada jedynie za zarządzanie danymi. Oprogramowanie u klienta implementuje logikę programu użytkowego i kontakt z użytkownikiem systemu. 8
Klient cienki i klient gruby Model klienta cienkiego Klient Prezentacja Serwer Zarządzanie danymi Przetwarzanie Model klienta grubego Klient Prezentacja Przetwarzanie Serwer Zarządzanie danymi Model klienta cienkiego Architektura dwuwarstwowa z klientem cienkim jest najprostszym rozwiązaniem, które można wykorzystać w scentralizowanych systemach odziedziczonych ewoluujących w kierunku architektur klient-serwer. Interfejs użytkowy działa jako serwer i obsługuje przetwarzanie użytkowe oraz zarządzanie danymi. Model klienta cienkiego może być również zaimplementowany tam, gdzie klienci są raczej prostymi urządzeniami sieciowymi, a nie komputerami osobistymi albo stacjami roboczymi. Na takim urządzeniu sieciowym działa przeglądarka sieci oraz interfejs użytkownika realizowany przez ten system. Najważniejsza wadą modelu klienta cienkiego jest duże obciążenie przetwarzaniem zarówno sieci, jak i serwera. 9
Model klienta grubego Korzysta się z dostępnej mocy obliczeniowej i przekazuje klientowi zarówno przetwarzanie związane z logiką programu użytkowego, jak i prezentację. Serwer jest zasadniczo serwerem transakcji, który zarządza transakcjami w bazie danych. Dobrze znanym przykładem architektury tego typu są systemy bankomatów. Bankomat jest tam klientem, a serwerem jest komputer główny obsługujący bazę danych kont klientów. W modelu klienta grubego przetwarzanie jest bardziej efektywne niż w wypadku modelu klienta cienkiego, zarządzanie systemem jest natomiast trudniejsze niż w tym pierwszym modelu. System klient-serwer do obsługi bankomatów Bankomat Bankomat Serwer kont Bankomat Monitor przetwarzania zdalnego Baza danych kont klientów Bankomat 10
Architektura warstwowa W tej architekturze prezentacja, przetwarzanie użytkowe i zarządzanie danymi są logicznie oddzielonymi procesami. Niekoniecznie potrzebne są trzy systemy komputerowe włączone do sieci. Jeden komputer serwera może obsługiwać zarówno przetwarzanie użytkowe, jak i zarządzanie danymi programu użytkowego jako dwa oddzielne logicznie serwery. Gdy jednak oczekiwania wzrosną, można będzie dość łatwo wyodrębnić przetwarzanie użytkowe i zarządzanie danymi, po czym uruchomić je na oddzielnych procesorach. Architektura trójwarstwowa klient-serwer Klient Prezentacja Serwer Przetwarzanie użytkowe Serwer Zarządzanie danymi 11
Architektura rozproszenia systemu bankowego w Sieci Klient Komunikacja HTTP Klient Klient Serwer WWW Obsługa konta Zapytanie SQL Serwer bazy danych SQL Baza danych kont klientów Klient Zastosowania różnych architektur klient-serwer Programy użytkowe, w których obliczenia są wykonywane u klienta przez COTS (kompo- nenty z półki), np. Microsoft Exel. Programy użytkowe wymagające złożonego obliczeniowo przetwarzania danych, np. przedstawiania graficznego danych. Programy użytkowe ze względnie stabilną funkcjonalnością oferowaną użytkownikowi, stosowane w środowisku ze starannie ustalonym zarządzaniem systemem. Architektura Architektura dwuwarstwowa klient-serwer z klientami cienkimi Architektura dwuwarstwowa klient-serwer z klientami grubymi Architektura trójwarstwowa lub wielowarstwowa klient-serwer Zastosowania Systemy odziedziczone, w których oddzielenie przetwarzania użytkowego od zarządzania danymi jest niepraktyczne. Programy użytkowe wykonujące dużo obliczeń, ale w małym stopniu (albo wcale) zarządzające danymi, np. kompilatory. Programy użytkowe dużo korzystające z danych (przeglądanie i zapytywanie), ale wykonujące mało (albo wcale) obliczeń użytkowych. Ogromne programy użytkowe z setkami lub tysiącami użytkowników. Programu użytkowe, w których zarówno dane, jak i programy są płynne. Programy użytkowe, w których integruje się dane z wielu źródeł. 12
Architektury systemów rozproszonych W modelu systemu rozproszonego klient-serwer klienci odróżniają się od serwerów. Klienci otrzymują usługi do serwerów, ale nie od innych klientów. Serwery mogą działać jako klienci korzystający z usług innych serwerów, ale nie mogą żądać usług od klientów. Klienci muszą znać usługi oferowane przez specyficzne serwery i wiedzieć, jak się z tymi serwerami porozumieć. Ten model sprawdza się w wielu zastosowaniach. Ogranicza jednak swobodę projektantów systemu, którzy muszą zdecydować, gdzie mają być oferowane usługi. Architektura obiektów rozproszonych o1 o2 o3 o4 U (o1) U (o2) U (o3) U(o4) Szyna programowa o5 U (o5) o6 U (o6) 13
Zalety modułu architektury systemu rozproszonego Umożliwia projektantowi odłożenie w czasie decyzji, gdzie i jak oferować usługi. Jest architekturą bardzo otwartych systemów, która umożliwia dodawanie nowych zasobów w miarę potrzeby. System jest bardzo elastyczny i skalowalny. Do obsługi rozmaitych obciążeń można utworzyć różne egzemplarze systemu z tym samym zbiorem usług oferowanych przez odrębne lub powielone obiekty. W miarę potrzeby można dynamicznie zmieniać konfigurację systemu przez migrację obiektów w sieci. Wykorzystanie architektury obiektów rozproszonych Jako model logiczny, który pomaga w ustaleniu struktury i organizacji systemu. W tym wypadku trzeba jednak zastanowić się, jak zapewnić funkcjonalność użytkową jedynie w kategoriach usług i ich kombinacji. Następnie należy wypracować sposób oferowania tych usług przez kilka obiektów rozproszonych. Jako elastyczne podejście do implementacji systemów klient-serwer. W tym wypadku model logiczny systemu odpowiada architekturze klient-serwer, ale zarówno klienci, jak i serwery maja postać obiektów rozproszonych porozumiewających się za pośrednictwem szyny programowej. 14
Architektura rozproszona systemu eksploracji danych Baza danych 1 Integrator 1 Generator raportów Baza danych 2 Prezenter Integrator 2 Baza danych 3 Wyświetlacz System eksploracji danych Taka architektura umożliwia zwiększenie liczby wykorzystywanych baz danych bez przerywania pracy systemu. Każda baza danych to po prostu kolejny obiekt rozproszony. Obiekty bazy danych mogą oferować uproszczony interfejs, który umożliwia kontrolę dostępu do danych. Odczytywane bazy danych mogą znajdować się na różnych maszynach. Taka architektura umożliwia eksplorację nowych rodzajów związków przez dodanie nowych obiektów integratorów. 15
CORBA CORBA jest zbiorem standardów dla śródprogramów zdefiniowanym przez OMG (Object Management Group). Implementacje CORBA są dostępne dla Unixa i systemów operacyjnych firmy Microsoft. DCOM jest standardem, który opracowano i zaimplementowano w firmie Microsoft i zintegrowano z systemami operacyjnymi jej produkcji. Model rozproszonych obliczeń w DCOM jest mniej ogólny niż CORBA. Komponenty programu użytkowego Obiekty użytkowe zaprojektowane i zaimplementowane dla tego programu użytkowego. Obiekty standardowe zdefiniowane przez OMG na użytek specyficznej dziedziny. Główne usługi CORBA związane z podstawowymi aspektami obliczeń rozproszonych, takie jak katalogi, zarządzanie zabezpieczeniami itd. Poziome udogodnienia CORBA, takie jak ułatwienia interfejsu użytkownika, zarządzanie systemem itp. 16
Struktura rozproszonego programu użytkowego opartego na CORBA Obiekty użytkowe Udogodnienia dziedzinowe Udogodnienia na poziomie CORBA Pośrednik zleceń obiektowych Usługi CORBA Standardy CORBA Model obiektów użytkowych, w których obiekty CORBA obudowują stan i mają dobrze określony i niezależny od języka interfejs opisany w IDL (Interface Definition Language język opisu interfejsów). Pośrednik zleceń obiektowych (Object Request Broker, ORB), który obsługuje żądania obiektów. Zbiór ogólnych usług obiektowych, które prawdopodobnie będą potrzebne w wielu rozproszonych programach użytkowych. Zbiór wspólnych komponentów zbudowanych na bazie tych podstawowych usług. Te komponenty mogą się przydać w rozmaitych programach użytkowych. 17
Model obiektowy CORBA Obiekt jest obudową atrybutów i usług, jak to jest zwykle w wypadku obiektów. Obiekty CORBA muszą mieć jednak oddzielną definicję interfejsu, w której określa się publiczne atrybuty i operacje obiektu. Interfejs obiektów CORBA ustala się za pomocą standardowego, niezależnego od języka programowania języka opisu interfejsów (IDL). Gdy obiekt pragnie skorzystać z usług innego obiektu, dostaje się do nich przez interfejs IDL. Obiekty CORBA mają unikatowe identyfikatory zwane IOR (Interoperable Object Reference odniesienia obiektów umożliwiające współpracę). Pośrednik zleceń obiektowych(orb) Obiekt wywołujący ma do dyspozycji namiastkę IDL, która zawiera definicję interfejsu obiektu oferującego żądaną usługę. Osoba programująca umieszcza wywołania tej namiastki w swojej implementacji wszędzie tam, gdzie jest potrzebna ta usługa. IDL jest nadzbiorem C++, jeśli więc programuje się w tym języku, to korzystanie z namiastki jest łatwe. Jest również dość łatwe w C i Javie. Zdefiniowano również przekształcenia IDL na inne języki, na przykład COBOL i Ada. W wypadku tych języków zwykle jest jednak konieczne wspomaganie narzędzi łączących z IDL. 18
Komunikacja obiektów za pośrednictwem ORB o1 o2 U (o1) U (o2) Namiastka IDL Szkielet IDL Pośrednik zleceń obiektowych Komunikacja między pośrednikami ORB Pośrednicy ORB często muszą się porozumieć. Implementacja CORBA realizuje komunikacje między pośrednikami ORB przez dostęp do opisu interfejsów w IDL oraz standardowy w OMG protokół Generic Inter-ORB Protocol (GIOP ogólny protokół komunikacji między ORB). W tym protokole zdefiniowano standardowe komunikaty, które mogą być przesyłane przez pośredników ORB i służą do implementacji zdalnych wywołań obiektów oraz przekazywania informacji. Gdy połączy się go z niskopoziomowymi protokołami sieci TCP/IP, GIOP umożliwia komunikację ORB za pośrednictwem sieci. 19
Komunikacja między różnymi egzemplarzami ORB o1 o2 o3 o4 U(o1) U (o2) U (o3) U (o4) IDL IDL IDL IDL Pośrednik zleceń obiektowych Pośrednik zleceń obiektowych Sieć Usługi CORBA Usługa katalogowa i usługa handlowa, dzięki którym obiekty mogą znajdować się i odwoływać do innych obiektów sieci. Usługi powiadamiania, dzięki którym obiekty mogą powiadomić inne obiekty o zajściu pewnego zdarzenia. Usługi transakcyjne do obsługi niepodzielnych transakcji i ich wycofywania w wypadku niepowodzenia. 20
Podsumowanie Obecnie niemal wszystkie nowe wielkie systemy są rozproszone. Ich oprogramowanie systemowe działa na luźno zintegrowanych grupach procesorów. Systemy rozproszone mogą charakteryzować się współdzieleniem zasobów, otwartością, współbieżnością, skalowalnością, odpornością na awarie i przezroczystością. Systemy klient-serwer to systemy rozproszone, których modelem jest zbiór usług oferowanych procesom klientów przez serwery. W systemach klient-serwer interfejs użytkownika działa zwykle u klienta, a zarządzanie danymi jest zawsze wykonywane przez współdzielony serwer. Funkcjonalność użytkowa może być zaimplementowana na komputerze klienta lub na serwerze. Podsumowanie W architekturze obiektów rozproszonych nie ma rozróżnienia na klientów i serwery. Obiekty oferują ogólne usługi, które mogą być wywoływane przez inne obiekty. To podejście można wykorzystać do implementacji systemów klient-serwer. Systemy obiektów rozproszonych muszą korzystać ze śródprogramów do obsługi komunikacji obiektów oraz dodawania i usuwania obiektów z systemu. Na poziomie projektowym można postrzegać te śródprogramy jako szynę programową, do której podłącza się obiekty. CORBA jest zbiorem standardów dla śródprogramów do obsługi architektur obiektów rozproszonych. Obejmuje definicje modelu obiektowego, pośrednika zleceń obiektowych i wspólnych usług. Są już dostępne rozmaite implementacje standardów CORBA. 21