WPROWADZENIE

12.1. Wprowadzenie

Rozdział ten prezentuje rozwiązania, o których nie było mowy w poprzed­nich rozdziałach: narzędzia do integracji systemów i rozproszone systemy ope­racyjne.

Wyróżnia się dwa typy przetwarzania rozproszonego:

- przetwarzanie polegające na wykorzystaniu narzędzi i usług umożliwiających współpracę pomiędzy komputerami;

- przetwarzanie wykorzystujące właściwości samego systemu operacyjnego, takiego jak Mach lub Chorus.

12.2. Narzędzia do przetwarzania rozproszonego

12.2.1. DCE

Po określeniu, czym jest DCE (Distributed Computing Environment) w ofer­cie OSF (Open Software Foundation), przedstawimy jego poszczególne elemen­ty składowe.

Miejsce DCE w ofercie OSF

Ofertę OSF tworzą trzy główne produkty:

- system operacyjny OSF/1, którego wersja 1.0 jest dostępna od lipca 1990. OSF/1 jest nowoczesnym systemem, zachowującym z UNIX-a wyłącznie in­terfejs użytkownika i oprogramowania. Jego jądro jest oparte na systemie Mach i jest całkowicie zgodne z BSD 4.4. Warto zauważyć, że Mach jest roz­proszonym systemem operacyjnym, lecz akurat właściwość ta nie została przejęta przez OSF. Proponowanym rozwiązaniem rozproszenia przetwarza­nia oraz danych jest DCE.

- system wielookienkowy Motif, którego pierwsza wersja pojawiła się w roku 1989. Staje się on obecnie standardem. Jest dostarczany przez wszystkich konstruktorów zrzeszonych w OSF, jak również występuje praktycznie we wszystkich odmianach UNIX-a. Jego wersja 1.1 jest oparta na X Window Release 4.

- środowisko przetwarzania rozproszonego DCE (Distributed Computing Environment); jego główne elementy przedstawimy w kolejnych punktach.

Poszczególne moduły DCE zostały stworzone przez OSF w wyniku prze­targu nie ograniczonego wyłącznie do członków OSF, stawiającego następujące warunki:

357

PERSPEKTYWY - przenośność środowiska pomiędzy różnymi systemami;

- moźliwość integrowania różnych elementów, a w szczególności wywołań odległych procedur, odległych serwerów zasobów, kontroli praw dostępu oraz rozproszonych systemów plików;

- zgodność z istniejącymi rozwiązaniami (zwłaszcza z TCPIIP i NFS); ' - otwarcie na normy OSI;

- niezawodność i bezpieczeństwo. i Serwer zasobów

Odwzorowuje on nazwę obiektu na jego adres w celu zlokalizowania go I w sieci.

Zastosowanie serwera zasobów dotyczy jednocześnie komputerów znajdują­cych się w sieci w obrębie tej samej jednostki administracyjnej (celi), jak i sta­i nowisk spoza jednostki. W obu wypadkach są stosowane różne narzędzia: spe­

i ' cjalizowany i szybki serwer lokalny w pierwszym wypadku oraz serwer glo­balny w drugim. Użytkownik lub aplikacja komunikują się wyłącznie z lokal­nym serwerem zasobów (zobacz rys. 12.1). Przekazywanie informacj i pomiędzy ?' I serwerami dokonywane jest za pośrednictwem mostu (bridge).

Jako serwer lokalny przyjęto DECdns, a jako serwer globalny - DIR-X. DECdns korzysta z mostu X500. Jest także przewidziany 111oSt udostępniąjąCy j ~ US~11gę DNS (Domain Name Serwer) w sieci Internet.

uźytkownik lokalny globalny serwer most serwer zasobów I I zasobów aplikacja

Rys. i 2.1. Lokalny i globalny serwer zasobów

Przetwarzanie współbieżne Przetwarzanie współbieżne umożliwia:

- jednoczesną obsługę wielu klientów przez serwer;

- WyWOkyWanie danej uskugi przez klienta przy jednoczesnym wykonywaniu innego kodu.

358

NARZĘDZIA DO PRZETWARZANIA ROZPROSZONEGÓ

Przetwarzanie współbieżne opiera się na pojęciu wątków (threads). Wątki, wywodzące się z architektury wieloprocesorowej (zobacz rys. 12.2), są również użyteczne w systemach jednoprocesorowych: dwa wątki mogą współdzielić ob­szar pamięci bez korzystania z pośrednictwa jądra (zobacz rys. 12.3). Stanowi to mechanizm wydajniejszy niż mechanizm IPC typu wspólna pamięć, opisany w rozdz. 3. Zauważmy, że wątki istnieją też w formie biblioteki w pewnych wer­sjach UNIX-a, na przykład w SunOS.

Rozwiązaniem przyjętym przez OSF jest paczka (package) CMA (Concert Multithread Architecture) zaproponowana przez DEC. Produkt ten może być przeniesiony na różne architektury sprzętowe.

APLIKACJA kod 1

thread createll ______________ kod 2 kod 3

wątek thread join()

kod 4

Rys. 12.2. Przetwarzanie wspófbieżne z zastosowaniem wątków: kod 2 oraz kod 3 wykonywane są równolegle

PRZESTRZEŃ UŹYTKOWNIKA

wątek klienta wątek serwera

wspólna pamięć

czytanie pisanie

w dane JĄDRO UNIX-a dane

zewnętrzne zewnętrzne

Rys. 12.3. Wspólna pamięć i wątki

359

PERSPEKTYWY

Protokół RPC w środowisku DCE

Zastosowano NCS w wersji 2.0, ponieważ rozwiązanie to jest bardziej prze­zroczyste w użyciu niż Sun RPC.

Klient może wywoływać serwer nie znając jego lokalizacji. Ustalenie lokali­zacji serwera zapewnia serwer zasobów (zobacz rys. 12.4). Serwer „eksportuje" I interfejs, a klient go „importuje".

i

y,

eksportuje importuje interfejs serwer 1 interfejs

klient serwer zasobów serwer 2

eksportuje interfejs Rys. 12.4. Lokalizowanie serwera

Współbieżność przetwarzania jest zapewniona przez zastosowanie wątków (zobacz punkt „Przetwarzanie równoległe"). Aplikacja klient przekazuje obsługę wywołań RPC osobnemu wątkowi i kontynuuje w tym czasie swoje działanie (zobacz rys. 12.5). Zastosowanie wątków umożliwia także implementację serwe­rów współbieżnych.

APLIKACJA KLIENT utworzenie wątku

wywołanie wykonanie RPC SIEĆ współbieżne

oczekiwanie na zakończenie

wykonywania wątku

Rys. 12.5. Współbieżność RPC

serwer RPC

360

NARZĘDZIA DO PRZETWARZANIA ROZPROSZONEGO

Wersja 2.0 NCS wprowadza w stosunku do wersji 1.5 następujące ulepsze­nia:

- zmodyfikowane i uzupełnione funkcje biblioteczne; - możliwość wyboru protokołu transportu;

- zastosowanie serwera zasobów (który uzupełnia brokerów).

Bezpieczeństwo zasobów

Mechanizmy zapewniające bezpieczeństwo zasobów obejmują kontrolę praw dostępu do zasobów, legalizację komunikujących się ze sobą jednostek, jak również spójność i poufność przesyłanych przez sieć komunikatów. Me­chanizm legalizacji służy do identyfikacji upoważnionych klientów i serwerów. Kontrola praw dostępu do zasobów opiera się na mechanizmie ACL (Access Control List). Z danym obiektem związana jest lista, opisująca jednostki upo­ważnione do korzystania z dostępu do tego obiektu. Spójność i poufność danych mogą być zapewnione przez szyfrowanie.

Zastosowany został mechanizm legalizacji Kerberos (produkt MIT) oraz nie­które mechanizmy bezpieczeństwa pochodzące od HP.

Zastosowane są także mechanizmy bezpieczeństwa pochodzące od RPC ­Secure RPC.

Synchronizacja czasu

Ważnym problemem jest synchronizacja czasu systemowego osobnych systemów, aby zapewnić wspólny dla wszystkich czas odniesienia.

Zastosowany został produkt DECdts. Może on funkcjonować razem z serwe­rem lub klientem NTP (Network Time Protocol, zastosowany w Internecie).

Rozproszony system plików

Rozproszony system plików umożliwia dostęp do odległych danych, tym samym rozszerzając w przezroczysty sposób lokalny system plików. Rozwiązaniem przyjętym przez OSF jest AFS (Andrew File System) wersja

4.0. System ten, stworzony na uniwersytecie Carnegie-Mellon, jest lepiej przy­stosowany do obsługi dużej liczby klientów niż NFS. Ponadto AFS stosuje pa­mięć podręczną dysku o dużym rozmiarze, mogącą przechowywać pliki w calo­ści. Serwer obsługuje stany plików klientów. Każda modyfikacja pliku powo­duje wysłanie do wszystkich aktualnie korzystających z niego klientów komuni­katu o dezaktualizacji zawartości pamięci podręcznej.

AFS jest zgodny z NFS, będącym aktualnie standardem. Klient NFS może '° korzystać z serwera AFS i odwrotnie. OSF/1 zawiera w swoim jądrze serwer

NFS.

361

a~ PERSPEKTYWY

Dla stacji bezdyskowych zastosowano produkt IłP oparty na AFS. Pojęcie CDF (Context Dependent File) umożliwia współi.,toienie różnych typów archi­tektur komputerów.

Integracja z komputerami osobistymi

Możliwe jest wykorzystanie stacji LJNIX-owych jako serwerów plików lub ',' i drukarek dla mikrokomputerów pracujących w systemie MS-DOS lub OS/2. OSF stosuje LM/X (Lan Manager/UNIX) oraz PC NFS.

Oba rozwiązania zapewniają podstawowe funkcje (współdzielenie plików i drukarek) oraz pewne usługi pomocnicze, takie jak terminal wirtualny, zdalne wykonywanie procedur, przesyłanie plików, API). OSF dostarcza wyłącznie ', moduł serwera.

Uwagi 'I ' DCE integruje ze sobą istniejące rozwiązania, dodając do nich pewne nowe możliwości. Celem jest umożliwienie współdziałania odmiennych systemów.

~ Zalety DCE uwidaczniają się w pełni przy implementacji tego systemu w ar­chitekturze wieloprocesorowej.

~i i DCE zostanie w przyszłości uzupełnione o DME (Distributed Management ,, ,

`'' ' Environment), środowisko umożliwiające przezroczyste zarządzanie sieciami i zasobami. Podobnie jak w przypadku DCE, w ramach DME zostaną zintegro­wane różnorodne istniejące produkty.

12.2.2. Oferta UNIX International Atlas

Dla zapewnienia współdziałania między odmiennymi systemami, organizacja L1NIX International zaproponowała rozwiązanie Atlas/DCF (Distributed Com­',j puting Framework).

j i Architektura ta opiera się na zastosowaniu pojęcia obiektu jako jednostki podlegającej rozproszeniu. Strona wysyłająca żądanie nie musi znać interfejsu obiektu. Uzyskuje ona dostęp do zasobu przez wysłanie do brokera komunikatu zawierającego identyfikator obiektu. Broker znajduje obiekt w sieci, odsyła jego adres oraz jego interfejs (zobacz rys. 12.6).

Atlas łączy w sobie standardowe rozwiązania przetwarzania rozproszonego:

- produkty ONC (Open Network Computing) firmy Sun Microsystems; - DCE.

Atlas ma także na celu zaimplementowanie protokołów OSI opierając się na zaleceniach GOSIP (Government OSI Protocol). Plaszczyzna ONP (Open Net­work Platform), stworzona wraz z UNIX-em System V Release 4, składa się

362

NARZĘDZIA DO PRZETWARZANIA ROZPROSZONEGO

z zestawu protokołów i usług OSI (FTAM, X500, zarządzanie sieciami itp.) za­implementowanych z zastosowaniem mechanizmu STRUMIENI.

W oczekiwaniu na ukazanie się Atlasa, będącego celem działań na najbliższe trzy lata, UNIX International proponuje ponadto następujące usprawnienia dla SVR4:

- mechanizm zapewnienia bezpieczeństwa zasobów Kerberos; - protokół NTP (Network Time Protocol);

- usprawnienia RPC i NFS;

- dołączenie do systemu X400 i X500.

KLIENT OBIEKTY

- adres

- interfejs

żądanie skierowane

do obiektu poszukiwanie obiektu

określonego przez na podstawie jego

identyfikator identyfikatora

BROKER

Rys. 12.6. Obiekty w środowisku rozproszonym

Ewolucja RPC i NFS

Przewidziano wprowadzenie następujących usprawnień do RPC:

- obsługa wątków;

- mechanizm Kerberos;

- mechanizm multicast (okólnik przeznaczony dla ograniczonej grupy kompu­terów);

- biblioteka niezależna od stosowanego transportu - TIRPC (Transport Inde­pendent RPC). Biblioteka TIRPC umożliwia wybór protokohz transportu w funkcji parametrów konfiguracji. Aplikacja używa zastępczej nazwy trans­portu. Zmienna środowiska NETPATH określa stosowany protokół trans­portu. Plik / etc /netconf ig wskazuje bibliotekę funkcji służących do odwzorowania nazw na adresy (Name To Address Mapping). Możliwe jest zastępowanie jednego protokołu transportu przez inny bez konieczności mo­dyfikowania aplikacji. Biblioteka TIRPC zaimplementowana jest ponad TLI;

363

! PERSPEKTYWY

- demon portmap jest zastąpiony przez rpcbind, który spełnia identyczne funkcje, lecz jest niezależny od protokołu transportu.

Usprawnienia wprowadzone do NFS w wersji 3 obejmują zwiększenie wy­dajności przy zapisach oraz zwiększenie bezpieczeństwa danych (przez zastoso­i wanie Secure RPC lub mechanizmu legalizacji Kerberos).

Przypominamy, że w SVR4 polecenia służące do administracji NFS oraz RFS zostały ujednolicone (zobacz rozdz. 7).

12.2.3. Wspólne projekty firm Sun i HP

Równolegle do projektów DCE i Atlas, firmy Sun i HP współpracują ze sobą w ramach OMG (Object Management Group) i zawarły umowy dotyczące nastę­! I pujących prac w dziedzinie przetwarzania rozproszonego:

e', ', - zapewnienie zgodności Sun RPC z NCS;

- DOMF (Distributed Object Management Facilities). o

DOMF budują następujące koncepcje: i.t

- komunikacja oparta na Sun RPC oraz na NCS;

- zarządzanie obiektami: tworzenie, instalowanie, usuwanie;

' - język programowania CDL (Class Definition Language), zbliżony do C++, ~' '~ pozwalający definiować obiekty wraz z ich interfejsem niezależnie od zasto­~I j~ sowanego mechanizmu RPC.

i v'' DOMF posłuży więc do tworzenia aplikacji rozproszonych z zastosowaniem interfejsu jeszcze wyższego poziomu niż RPC.

.I

12.3. Rozproszone systemy operacyjne

"'' ' Przedstawimy w skrócie systemy Mach i Chorus, będące obecnie najspraw­niejszymi rozproszonymi systemami operacyjnymi.

Zorganizowane są one wokół mikrojądra, wykonującego tylko najbardziej elementarne czynności:

- szeregowanie (zarządzanie wątkami i zadaniami); - zarządzanie pamięcią wirtualną;

I - komunikacja pomiędzy aktywnymi jednostkami (wątkami i zadaniami) nie­i

zależnie od ich lokalizacji - IPC (Interprocess Communication).

364

ROZPROSZONE SYSTEMY OPERACYJNE

Ponad jądrem znajdują się serwery świadczące wiele usług. Umożliwiają one skonstruowanie kompletnego systemu operacyjnego, którym może być na przy­kład UNIX BSD 4.3 czy też System V Release 4. Mechanizmy IPC zapewniają komunikację pomiędzy serwerami a jądrem oraz pomiędzy samymi serwerami.

Warto zaznajomić się z pojęciami występującymi w tych systemach rozpro­szonych, zaczynającymi pojawiać się w wielu systemach z rodziny UNIX-a:

wątek - elementarna aktywna jednostka systemu;

zadanie (task) - jednostka obsługująca zasoby (pamięć, porty komunika­cyjne itp.), działająca w zabezpieczonym obszarze pa­mięci (Zadanie może zawierać jeden lub kilka wątków. Proces UNIX-a odpowiada zadaniu. Wszystkie wątki na­leżące do zadania korzystają z jego zasobów.);

port - punkt dostępu do kanału komunikacji (uogólnienie poję­cia portu TCP/IP);

komunikat - jednostka komunikacji pomiędzy wątkami;

obiekty - wszystkie zasoby systemu łącznie z pamięcią widziane są jako obiekty. Komunikują się one między sobą przesyła­jąc komunikaty poprzez porty. Komunikaty te mogą być przesyłane w obrębie stanowiska lokalnego lub pomiędzy stanowiskami odległymi. Komunikacjązajmuje się serwer komunikatów.

Warto zauważyć, że istnieje sieciowy serwer pamięci („mapper" w systemie Chorus), umożliwiający współdzielenie pamięci poprzez sieć.

aplikacje zarządzanie zorz dzanie sieci procesami ą ą UNIX-a

mikrojądro - zadania i wątki

- komunikaty i porty - pamięć wirtualna Rys. 12.7. Mikrojądro i usługi

365

PERSPEKTYWY

12.3.1. Mach

System Mach (Multiple Asynchronous Communication Host) powstał na uniwersytecie Carnegie-Mellon. Może on być stosowany na komputerach jedno­procesorowych, wieloprocesorowych, jak również na komputerach połączonych siecią. Jednym z głównych założeń systemu Mach jest zgodność ze środowi­skiem LTNIX-a.

Do manipulowania wątkami służy biblioteka P-thread (zgodna z normą

POSIX). Ponadto, do komunikacji między procesami można stosować trady-

cyjne funkcje IINIX-a.

Język MIG (Mach Interface Generator) służy do generowania aplikacji dzia-

łających w systemie Mach, wykorzystujących RPC.

12.3.2. Chorus

Chorus jest rozproszonym systemem operacyjnym, stworzonym i sprzedawa-

nym przez Chorus Systemes. Podobnie jak Mach, jest on zorganizowany wokół

mikrojądra. Mikrojądro staje się standardową bazą dla wszystkich systemów

rozproszonych i systemów czasu rzeczywistego. Chorus/MiX Release 3.2 jest

rozproszonym systemem czasu rzeczywistego, zgodnym z IJNIX-em System V

Release 3.2. Podczas gdy Mach jest przeznaczony dla komputerów wieloproce-

sorowych silnie sprzężonych, Chorus jest implementowany na architekturach

'. .': i

luźno sprzężonych (na przykład o strukturze typu hipersześcian).

Jedną z różnic pomiędzy Chorusem a Machem jest zastosowanie pojęcia

nadzorcy, działającego w osobnym obszarze pamięci i korzystającego z uprzy-

wilejowanych instrukcji (zobacz rys. 12.8).

',j ' Inną różnicą, być może nawet jeszcze ważniejszą, jest sposób, w jaki Chorus

obsługuje interfejs komunikacyjny. Bez wdawania się w szczegóły można po-

wiedzieć, że Chorus stosuje prostszy mechanizm do identyfikacji portów

i obiektów niż Mach. Celem jest pozostawienie maksymalnej swobody podsys-

ternom w obsłudze praw dostępu do obiektów. Pozwala to na realizację wydaj-

nych aplikacji czasu rzeczywistego i uniknięcie nawarstwiania kilku systemów

I, kontroli praw dostępu, tak jak to ma miejsce w przypadku systemu takiego jak

LTNIX.

Chorus jest obecnie najszerzej rozpowszechnionym w przemyśle rozproszo-

nym systemem operacyjnym i być może zostanie wybrany przez AT&T do kon-

strukcji nowego własnego systemu rozproszonego.

366

ROZPROSZONE SYSTEMY OPERAGYJNE

PF7ZFSTFJZFŃ ZJŻYTNOWNINA PRZESTRZEŃ NADZORCY

zarządzanie zarządzanie procesami plikami

zarządzanie zarządzanie terminalami gniazdkami

MIKROJĄDRO

Rys. 12.8. Architektura systemu Chorus

12.4. Tendencje

Rozproszenie staje się słowem kluczowym architektur oprogramowania w la­tach 90.

W koncepcji przetwarzania rozproszonego istnieją dwa przeciwstawne podej­ścia:

- z punktu widzenia rozproszonych systemów operacyjnych (Mach, Chorus); zakłada się jednorodne środowisko, w którym wszystkie komputery działają w tym samym systemie operacyjnym;

- z punktu widzenia narzędzi do tworzenia aplikacji rozproszonych. Jest to po­dejście wybrane przez OSF i LJNIX International, zakładające współdziałanie pomiędzy odmiennymi komputerami i systemami. Warto zauważyć, że UNIX International zachowuje (przynajmniej na jakiś czas) tradycyjne jądro LJNIX-a, podczas gdy OSF proponuje system zorganizowany wokół mikro­j ądra.

Pomimo różnic w obu podejściach istnieje pewna zbieżność w wykorzysta­niu pewnych koncepcji i mechanizmów:

- wątki zapewniające współbieżność;

- wykorzystanie RPC jako narzędzia do komunikacji sieciowej między proce­sami;

367

,, PERSPEKTYWY i

- integrowanie różnorodnych usług w spójnych systemach;

- dążenie do zgodności z normami X/Open i POSIX, a także z normami OSI. ;;j

',' Widać też nową tendencję - obiektowo zorientowane podejście do zarzą­dzania zasobami.

'i Pojawia się nowa generacja aplikacji, składających się z wielu modułów mo­gących działać na wielu komputerach zależnie od parametrów konfiguracji. Przykładowo, aplikacja służąca do wizualizacji danych naukowych AVS (Application Visualisation System) zawiera w sobie zestaw modułów mogących '' współdziałać ze sobą w sieci.

12.5. Podsumowanie ,.i

OSF (Open Software Foundation) proponuje środowisko DCE (Distributed Computing Environment). Jest nim zestaw spójnych i jednolitych usług zapew­niających współdziałanie odmiennych systemów.

wLJNIX International proponuje rozwiązanie takiego samego rodzaju o nazwie i:~ i' ', Atlas. Jest ono w większości oparte na sieciowym oprogramowaniu firmy Sun i uzupełnione przez produkty DCE i standardy OSI.

Rozproszone systemy operacyjne, z których najbardziej rozproszonymi są Mach i Chorus, stanowią alternatywę dla tradycyjnych systemów z rodziny LJNIX-a wraz z zastosowanymi narzędziami. Zorganizowane są one wokół mi­

Ei krojądra, wykonującego podstawowe czynności systemu. Pozostałe usługi znaj­dują się w przestrzeniu użytkownika. Dostęp do zasobów lokalnych i odległych jest identyczny i jest obsługiwany przez system.

Literatura OSF obszernie opisuje swoje produkty w wielu artykułach: [OSF 90] opisuje

DCE. Bull [BULL 91] przejął DCE do ogólniejszej architektury zwanej DCM (Distributed Computing Model).

LTNIX International nie pozostaje w tyle i prezentuje swoje produkty i archi­tektury: [PAPAYANNI,91], [SL3N 90B], [SCHUELKE 91] oraz [UNIX INTERNATIONAL 91 ].

Liczne artykuły opisują system Chorus: [ARMAND 91] i [GIEN 91] są jed­nymi z nowszych. Mach jest często prezentowany na seminariach [BITAR 91 J. [BAUER 91] opisuje konstrukcję rozproszonych systemów operacyjnych.

---