Studia Podyplomowe IT w Biznesie Systemy Rozproszone Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 1 Wprowadzenie do systemów rozproszonych Wykładowca: dr hab. inż. Kazimierz Subieta profesor PJWSTK subieta@ipipan.waw.pl, http://www.ipipan.waw.pl/~subieta Niniejszy materiał jest dostępny pod: http://www.si.pjwstk.edu.pl

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 (poza domowymi komputerami) są rozproszone. Ogromnym katalizatorem rozproszenia systemów jest Internet. Komputer z Internetem można już uważać za system rozproszony. 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.

Zalety systemów rozproszonych (1) Podział zasobów: system rozproszony pozwala dzielić zasoby sprzętowe i programowe (pamięci dyskowe, drukarki, pliki, kompilatory, itd.) 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. Otwarte systemy często mają tę zdolność również w stosunku do w/w zasobów ulokowanych 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ą (jakkolwiek nie muszą) 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.

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.

Krytyczne zagadnienia projektowe dla systemów rozproszonych Identyfikacja zasobów: zasoby w systemie rozproszonym 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 (Uniform Resource Locator) znany z WWW. Komunikacja: może być zaprojektowana w sposób uniwersalny, na bazie np. protokołu internetowego TCP/IP lub któregoś protokołu pochodnego (ftp, http, itd.). 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. Przykładem jest WWW. Koleżeńska (peer-to-peer): 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. Architektura oparta na oprogramowaniu pośredniczącym (middleware): nie występuje podział na klientów i serwery. Węzły komunikują się poprzez specjalne oprogramowanie pośredniczące, które zakłada wspólny (przezroczysty dla użytkowników) protokół komunikacyjny. Przykładem jest CORBA (rozproszone obiekty) lub Napster (rozproszone bazy plików mp3).

Architektura klient-(multi) serwer (1) Połączenia bezpośrednie: k2 k3 k7 k1 s4 k4 s1 k8 s3 k5 s2 k9 k6 k10 k11

Architektura klient-(multi) serwer (2) Połączenia poprzez sieć: nie ma bezpośrednich połączeń, zarówno serwery jak i klienci są przyłączani w jednakowy sposób do wspólnej sieci komputerowej. k1 k2 s4 k3 k9 k4 s1 Sieć komputerowa k8 k5 s3 k6 s2 k7

Reguły architektury klient-serwer (1) Zachowanie autonomii serwera. Klienci powinni zachowywać reguły wykorzystania serwera, nie powinni powodować jego niedostępność (np. poprzez zamykanie dużych ilości danych), nie powinni łamać ograniczeń integralności. Zachowanie autonomii klienta. Klienci nie powinni zachowywać się różnie w zależności od tego, czy serwer jest lokalny czy odległy. Użytkownicy powinni być odizolowani od kwestii fizycznego ulokowania danych. Wspomaganie dla aplikacji niezależnych od serwera. Dostęp do własności (danych, usług) serwera. Klienci mogą żądać od serwera wykonanie przewidzianych dla niego funkcji. Wspomaganie dla bieżącego dostępu do danych. Dostęp ten powinien być bezpośredni, bez pośrednictwa plików przekazywanych do/od klienta. Minimalny wpływ architektury K/S na wymagania dla klienta. Oprogramowanie klienta w architekturze K/S nie powinno wykazywać znacznego zwiększenia zapotrzebowania na RAM lub objętość dysku.

Reguły architektury klient-serwer (2) Kompletność opcji niezbędnych do połączenia. Oprogramowanie klienta nie powinno wymagać dodatkowego programowania do zrealizowania połączenia z serwerem.Powinien to zapewniać serwer komunikacyjny. Możliwość budowy lokalnych prototypów. Programista powinien mieć możliwość budowy i testowania prototypu aplikacji K/S wyłącznie na stacji klienta. Kompletność narzędzi użytkownika końcowego. Projektowanie ekranów, generacja zapytań, itd. powinny być częścią środowiska. Kompletność środowiska budowy aplikacji. Powinno przewidywać możliwość łączenia się w sieci, dostęp do usług globalnych w zakresie nazw, lokacji danych, itd. Otwarte środowisko języka-gospodarza. Powinno zapewniać możliwość użycia uniwersalnego języka programowania do budowy aplikacji. Szczególna troska o standardy. Im bardziej będą one przestrzegane, tym mniej będzie późniejszych kłopotów ze współdziałaniem.

Logiczna architektura oprogramowania Architektura klient-serwer powinna odzwierciedlać logiczny podział oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym. Architektura trójwarstwowa: Zasada oddzielania aspektów (separation of concerns principle, E.Dijkstra) cienki klient Warstwa prezentacyjna (interfejs użytkownika) Staranne rozdzielenie tych warstw jest bardzo istotne z punktu widzenia tworzenia i modyfikowalności oprogramowania. Dzięki temu rozdzieleniu, możliwa jest np. poprawa interfejsu użytkownika bez jakichkolwiek interwencji w pozostałe warstwy oprogramowania. gruby klient Warstwa przetwarzania (logika biznesu) Warstwa zarządzania bazą danych Architektura wielowarstwowa: rozbicie środkowej warstwy na kilka warstw.

Cienki i gruby klient Terminy cienki klient (thin client) oraz gruby klient (fat client) odnoszą się do mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer. Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania, ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci przeglądarki WWW. Model grubego klienta: klient posiada znacznie bogatsze możliwości przetwarzania, w szczególności może zajmować się nie tylko warstwą prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu). Powyższy podział posiada oczywiście pewną gradację. Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest duże obciążenie serwera i linii komunikacyjnych. Model grubego klienta używa większej mocy komputera klienta do przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone.

Architektury dwuwarstwowe Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem. Warstwa prezentacyjna (interfejs użytkownika) + Warstwa przetwarzania (logika biznesu) cienki klient Warstwa prezentacyjna (interfejs użytkownika) gruby klient Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych Warstwa przetwarzania (logika biznesu) + Warstwa zarządzania bazą danych W tym modelu przetwarzanie (logika biznesu) jest dzielone pomiędzy klienta i serwera. Zaprojektowanie jej jest trudniejsze.

Przykład architektury K/S - sieć bankomatów Serwer kont klientów banku Monitor tele-przetwarzania Baza danych kont klientów banku Bankomat Oprogramowanie pośredniczące organizujące komunikację z odległymi klientami i szeregujące transakcje klientów celem przetwarzania ich przez bazę danych. Bankomat

Przykład architektury K/S - portal WWW interakcja poprzez HTTP klient zapytania SQL Serwer Web: generacja dynamicznych stron HTML dla klienta + zlecenia do bazy danych Serwer bazy danych: wykonywanie zapytań w SQL wyniki zapytań SQL

Zastosowanie różnych architektur K/S Dwuwarstwowa architektura K/S z cienkim klientem Dwuwarstwowa architektura K/S z grubym klientem Trzywarstwowa lub wielowarstwowa archiktektura K/S Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarządzania danymi jest niepraktyczne. Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest bardzo mała interakcja z bazą danych. Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie występuje lub jest bardzo małe przetwarzanie. Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane oprogramowanie klienta, np. MS Excel. Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem multimediów). Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze określonym zarządzaniem. Aplikacje o dużej skali z setkami lub tysiącami klientów. Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne). Aplikacje integrujące dane z wielu rozproszonych źródeł.

Architektura rozproszonych obiektów (1) W architekturze klient-serwer istnieje wyraźna asymetria pomiędzy klientem i serwerem; w szczególności, nie występuje tam komunikacja bezpośrednio pomiędzy klientami. Model taki dla wielu zastosowań jest mało elastyczny i zapewnia zbyt małą skalowalność. Architektura rozproszonych obiektów znosi podział na klientów i serwery. Każde miejsce w rozproszonym systemie jest jednocześnie klientem i serwerem. Konieczne jest sprowadzenie wszystkich danych i usług do jednego standardu. Taki standard obejmuje: Model (pojęciowy i logiczny) danych i usług, który jest w stanie "przykryć" wszystkie możliwe dane i usługi, które mogą kiedykolwiek pojawić się w systemie rozproszonym; Specjalne oprogramowanie zwane pośrednikiem (broker), które akceptuje wspólny model danych i usług umożliwiając ich udostępnienie dla dowolnych miejsc w systemie rozproszonym. Specjalne oprogramowanie, zwane osłoną, adapterem lub mediatorem, które przystosowuje konkretne miejsce do modelu przyjętego przez pośrednika.

Architektura rozproszonych obiektów (2) Aplikacja napisana w C++ Aplikacja na relacyjnej bazie danych Aplikacja na Lotus Notes Osłona 1 Osłona 2 Osłona 3 ... ... Pośrednik Pośrednik Pośrednik Szyna oprogramowania (software bus) Miejsce 1 Miejsce 2 Miejsce 3

Struktura logiczna rozproszonych obiektów Obiekty O9 O4 O6 O8 K1 Operacje na obiektach (w klasach) K3 K2 K4 Szyna oprogramowania (software bus) Aplikacje A1 A2 A3 Szyna oprogramowania tworzy jedną przestrzeń obiektów. Obiekty te są dostępne dla dowolnego miejsca poprzez operacje (zgrupowane w klasach). Miejsca i sposoby implementacji obiektów są niewidoczne. Aplikacje korzystają z całej puli obiektów.

Zalety rozproszonych obiektów Zgodność z logiką biznesu - bezpośrednia implementacja obiektów biznesowych. Umożliwienie projektantom opóźnienie decyzji - gdzie i jakie usługi powinny być zapewnione. Skalowalność aplikacji: mała zależność czasu reakcji systemu od zwiększenia ilości danych, liczby użytkowników, liczby węzłów. Dekompozycja aplikacji na małe elementy wykonawcze (obiekty, metody,...). Przyrostowe dodawanie/odejmowanie funkcjonalności (“płacę tylko za to, czego używam”). Podział zasobów i zbalansowanie obciążeń. Współbieżność i asynchroniczne przetwarzanie. Elastyczność zmian w oprogramowaniu (konserwacja), w szczególności, przenoszenie obiektów i usług do innych miejsc. Możliwość przyłączania aplikacji spadkowych (funkcjonujących wcześniej jako scentralizowane).

Oprogramowanie i standardy dla rozproszonych obiektów OMG CORBA (Common Object Request Broker Architecture) - najbardziej uniwersalny standard obejmujący ogromną liczbę aspektów (m.in.notacja UML jest jego składową). Pakiety ORB (Object Request Broker) są oprogramowaniem pośrednika realizującym tę architekturę. Wbrew twierdzeniom Microsoftu, istnieje wiele dobrze zrealizowanych ORB-ów. DCOM (Distributed Component Object Model - rozproszony obiektowy model składników) - standard Microsoftu zintegrowany z systemami operacyjnymi Microsoftu. Znacznie ograniczony w stosunku do standardu CORBA. Znaczny „szok kulturalny” w stosunku do standardowych definicji pojęć obiektowości. Został przez Microsoft uznany za przestarzały na rzecz platformy .NET. RMI (Remote Method Invocation – zdalne wywoływanie procedur) - oprogramowanie firmy Sun, ograniczone w stosunku do standardu CORBA, o nieco innej filozofii. XML - standard zaproponowany dla Internetu, zapewniający semantyczną kwalifikację danych przechowywanych na serwerach WWW. Standard umożliwia wymianę informacji w sieci Internet. Technologie związane z XML są mniej elastyczne i ograniczone w stosunku do standardu CORBA.