DRS

VOJNA AKADEMIJA VOJSKE JUGOSLAVIJE

Smer slube informatike

Distribuirani raunarski sistemi

-skripta-

Profesor

Studenti

dr Boidar Radenkovi

53. klasa

Fakultet Organizacionih Nauka

Sluba informatike

Beograd, 2001.

Sadraj:

51.KONCEPTI OPERATIVNIH SISTEMA

1.1.Osnove operativnih sistema51.2.Razvoj operativnih sistema51.3.Centralizovani operativni sistemi51.4.Mreni operativni sistemi61.5.Distribuirani operativni sistemi61.6.Kooperativni nezavisni sistemi71.7.Standardizacija72.Koncepti distribuiranih sistema82.1.Koristi od distribuiranih sistema82.2.Servisi82.3.Projektni zahtevi82.4.Sistemski modeli82.5.Transparentnost92.6.Fleksibilnost92.7.Pouzdanost92.8.Performanse102.9.Distribuirani algoritmi103.Konkurentni procesi i programiranje113.1.Konkurentni procesi113.2. Korienje niti113.2.1 Implementacija niti u prostoru korisnikog programa113.2.2 Implementacija niti u kernelu113.3 Klijent - Server model123.4 Vreme u distribuiranim sistemima123.4.1 Logiki sat123.4.2 Fiziki sat133.5 Konkurentno programiranje133.6 Sinhronizacija slanja poruka144.MEUPROCESNA KOMUNIKACIJA154.1.Meuprocesna komunikacija154.2.Komunikacija prenoenjem poruka154.3 Sinhronizacija i prihvatanje poruka164.4 Pipe i socket APIs164.5.Zatitni sloj socketa174.6.Komunikacija grupe i multiprenos(multicast)184.6.1 Ureivanje multiprenosa184.6.2 Uzrono ureen multiprenos184.6.3 Atomski multiprenos184.7 Komunikacija upit/odgovor194.7.1 Parametar prenosa i konverzija podataka194.7.2 RPC kompilacija194.7.3 Povezivanje204.7.4 RPC izuzeci i upravljanje otkazima204.7.5 Sigurnost: Suns Secure RPC214.8 Transakciona komunikacija214.8.1 Dvofazni protokol214.8.2 Tok izvravanja 2PC224.8.3 Oporavak224.9 Servisiranje po imenu i sadraju224.9.1 Rezolucija imena224.9.2 Informaciona baza sadraja235. MEUPROCESNA KOORDINACIJA245.1 Kooperativni procesi245.2 Distribuirana meusobna iskljuenja245.2.1 Lamport-ovi algoritmi distribuiranih meusobnih iskljuenja245.2.2 Ricart i Agrawal-ov algoritam distribiranih meusobnih iskljuenja255.2.3 Algoritmi distribuiranih meusobnih iskljuenja zasnovani na glasanju255.2.4.1 Meusobno iskljuenje prenoenjem tokena. Topologija logikog prstena255.2.4.2 Meusobno iskljuenje prenoenjem tokena. Struktura logikog stabla265.2.5 Meusobno iskljuenje prenoenjem tokena. Prenos265.4.1 Algoritmi za izbor lidera. Potpuna topologija265.4.2 Algoritmi za izbor lidera.Topologija logikog prstena276. RASPOREIVANJE DISTRIBUIRANIH PROCESA286.1Strategije Rasporeivanja Distribuiranih Procesa286.1 Politika Rasporeivanja Distribuiranih Procesa286.2.1 Strategije statinog rasporeivanja distribuiranih procesa28Prednosti Modela Procesa29Komunikacije Model Procesa296.2.2 Strategije dinamikog rasporeivanja procesa29Deljenje optereenja30Rasporeivanje Optereenja306.3 Mehanizmi Rasporeivanja Distribuiranih Procesa306.3.1 Daljinsko izvravanje316.3.2 Prebacivanje procesa318. DISTRIBUIRANI FAJL SISTEMI328.1 Aspekti DFS-a328.2 Organizacija Fajl Sistema328.3 Fajl Serveri338.3.1 Fajl Serveri Sa i Bez Informacija o Postojeem Stanju (Stateful and Stateless)348.4 Semantika Deljenja Fajla348.5 Keiranje358.6 Replikacija Fajla358.6.1 Update Protokoli359. DISTIBUIRANA DELJENA MEMORIJA379.1 Motivacija i Principi379.2 DSM Arhitektura379.2.1 Vrste DSM Sistema389.3 Modeli Postojanosti Memorije389.3.1 Modeli postojanosti generalnog pristupa399.3.2 Modeli postojanosti sinhronizovanog pristupa399.4 Algoritmi Memory Menadmenta3910. ZATITA U DISTRIBUIRANIM RAUNARSKIM SISTEMIMA4110.1 Zatita u raunarskim sistemima4110.2 Osnove raunarske zatite4110.3 Modeli kontrole diskrecionog pristupa4210.4 Mandatorni modeli kontrole pristupa4310.4.1 Lattice "Reetka" model4310.4.2 Bell-LaPadula model4310.5 Modeli kontrole pristupa zasnovani na ulogama (RBAC)4310.6 Kriptografija4410.7 Kriptografski sistemi sa tajnim kljuem4410.8 Kriptografski sistemi sa javnim kljuem4510.9 Autentifikacija i distribucija kljueva4510.9.1 Protokoli autentifikacije4510.10 Kerberos protokol4610.11Prikriveni kanali4710.12 Mehanizam Nadzora4711. UNIX i WINDOWS NT4911.1 Istorija UNIX-a4911.2 Opis ciljeva "ranog" 4BSD Sistema4911.3 Proces adresiranja4911.4 Deljenje memorije u BSD Unix-u5011.5 IPC model5011.6 Komunikaciona semantika5011.7 Tipovi soketa5111.7.1 Sistemski pozivi soketa5111.7.2 Nepovezani komunikacioni soket5111.7.3 Povezani komunikacioni soket5211.8 Besplatni operativni sistemi5311.9 Mreni API u Windows NT5411. 10 Imenovani tokovi5412. MIKROKERNEL5512. 1 Koncept Mikrokernela5512. 2 Monolitni operativni sistem5512. 3 Mikrokernel pristup5512.4 Upravljanje procesima5612.5 Upravljanje memorijom5612.6 Meuprocesna komunikacija5712.7 Ulaz/izlaz5712.8 U2355712.8.1 Procesi i domeni5712.8.2 Meuprocesna komunikacija5712.8.3 Upravljanje memorijom5812.9 Proces rasporeivanja5813 CORBA5913.1 OMA (Object Managment Arhitecture)5913. 2 The OMA Reference Arhitecture5913.3 Common Object Request Broker Arhitecture (CORBA)6013. 4 Object Request Broker6013. 5 Jezik za definiciju interfejsa6113. 6 CORBA meuoperativnost6113. 7 CORBA servis adresiranja6113. 8 Resursi arhitekture CORBA62

1.KONCEPTI OPERATIVNIH SISTEMA

1.1.Osnove operativnih sistema

Glavni cilj operativnih sistema je da obezbedi apstrakciju maine (proirena ili virtuelna maina) predstavljenu kao skup servisa. Servisi su implementirani kao skup softverskih modula koji ine interfejs izmeu programa (alata i aplikacija) i sistemskog hardvera. Sistemski servisi mogu biti grupisani u sledee kategorije: kontrola procesa, manipulacija datotekama, manipulacija ureajima, odravanje informacija o statusu sistema i komunikacija.

Sistemski hardver se sastoji od procesora, memorije, U/I ureaja i komunikacionih interfejsa. Ovi resursi trebaju biti efikasno iskorieni. Sa ove take gledita operativni sistem se mora ponaati kao upravlja resursima. Funkcije operativnog sistema kao upravljaa resursima su sledee:

rasporeivanje procesa

sinhronizacija procesa i meuprocesna komunikacija.

upravljanje ureajima i komunikacijama

upravljanje memorijom

upravljanje datotekama.

1.2.Razvoj operativnih sistema

Centralizovani operativni sistemi (konvencionalni) - dobro razumljivi, koriste virtualni koncept kao virtualnu mainu

Mreni operativni sistemi i distribuirani operativni sistemi su posledica velike ekspanzije umreavanja.

U mrenim operativnim sistemima korisnci su svesni postojanja vie maina(raunara). Koncept saradnje meu mainama omoguava deljenje resursa ukljuujui programe i podatke. Distibuirani operativni sistem daje svima jednosistemski pogled na viestruki raunarski sistem(raunaru spojeni u mreu). Sistem koji realizuje ovaj cilj naziva se transparentnim.

Kooperativni nezavisni sistemi koncept koji preovladava u okruenjima otvorenih sistema. Dodatna funkcija jednoprocesorskom operativnom sistemu koja obezbeuje saradnju meu raunarima je sposobnost razmene informacija preko nekog spoljanjeg komunikacionog kanala. Distribuirani operativni sistemi zahtevaju mnogo manje napora da se postigne potpuna transparentnost. Zbog toga nastaje potreba za algoritmima distribuirane kontrole. Prava transparentnost nije uvek poeljna. Korisnici bi moda vie voleli da budu svesni postojanja viestrukih resursa i da koriste softverske sisteme koji su konstruisani integracijom kooperativnih nezavisnih delova softvera.

1.3.Centralizovani operativni sistemi

Sam operativni sistem je veliki program. Tradicionalno, kad se implementiraju takvi programi, oni su struktuirani u module kojima se moe upravljati.

Dva koriena pristupa su vertikalno i horizontalno raslojavanje. Vertikalno raslojavanje, nazvano lejering (layering : layer = sloj) razdvaja softverski sistem u hijerarhijske slojeve. Uglavnom, komunikacija je dozvoljena samo izmeu susednih slojeva. Horizontalno raslojavanje omoguava konstrukciju modula iz grupe slojeva. Svaki modul moe dalje biti preraen od strane bilo kog od ova dva koncepta ili njihovom kombinacijom. Na primer, operativni sistem moe biti vertikalno raslojen na fajl podsistem i podsistem za kontrolu procesa. Sloj fajl podsistema zaduen za kontrolore ureaja dolazi ispod sloja zaduenog za obezbeivanje fajl servisa.

Generalno operativni sistem je sainjen iz dva sloja. Donji sloj, tik iznad hardvera, implementira neophodne funkcije i naziva se kernel (kernel - jezgro). Struktura kernela je esto monolitna, jer je efikasnost glavna obaveza. Vii sloj implementira funkcije visokog nivoa koje program vidi. On je esto horizontalno raslojen.

Portabilnost operativnog sistema moe biti podrana deljenjem hardverski zavisnog koda. Hardverski zavisan deo bi trebao biti minimiziran da bi se smanjili trokovi portabilnosti. Obino su implementirane sledee funkcije

multipleksiranje procesora sa multiprogramskom podrkom

upravljanje prekidima

drajveri za ureaje

primitive sinhronizacije procesa

primitive meuprocesne komunikacije

U distribuiranoj sredini, raunarska komponenta moe imati specijalizovanu funkcionalnost i ne startuje kompletan operativni sistem ukljuujui sve sistemske servise. Fukcije koje su obino potrebne za svaku raunarsku komponentu formiraju mikrokernel. Mikrokernel bi trebao biti smeten u sloj zaduen za obezbeivanje proirivosti aplikacijama visokog nivoa ukljuujui i kompletan standardan operativni sistem i u sloju hardverske apstrakcije zaduen za portabilnost.

1.4.Mreni operativni sistemi

Raunarska mrea moe biti predstavljena kao labavo povezani sistemi vie raunara gde ne postoji direktna hardverska ili softverska kontrola jedne maine od strane druge. Generalno, raunari povezani u raunarsku mreu rade pod razliitim operativnim sistemima. Cilj mrenog operativnog sistema je da olaka deljenje resursa i razmenu informacija u takvom, verovatno heterogenom, okruenju.

Komunikaciona podmrea koja je odgovorna za razmenu informacija je organizovana hijerarhijski. Transportni servisi su obezbeeni od mrenog operativnog sistema da bi se olakala komunikacija izmeu jednakih procesa. Interfejs izmeu aplikacionih procesa i niih slojeva komunikacione podmree je implementiran u transportnom sloju. API-ji visokog nivoa, kao socket ili RPC (RPC-Remote Procedure Call), se koriste da olakaju transportni servis. Mrene aplikacije koje podravaju korisniku komunikaciju i deljenje resursa su implementirani u transportnom servisu. Tipine mrene aplikacije su udaljeni login, transfer datoteka, slanje i primanje poruka, pretraivanje mree i izvravanje na daljinu.

Funkcije mrenog operativnog sistema, gore opisane, mogu se dodati tradicionalnim operativnim sistemima njihovim proirenjem.

1.5.Distribuirani operativni sistemi

U sutini ne postoji koordinacija kada umreeni raunari rade pod mrenim operativnim sistemom. Jedini zahtev je da se potuje komunikacioni protokol. Proirenje deljenja resursa sa optijim formama koopertaivnih aktivnosti, poput posedovanja jenog meuprocesnog komunikacionog mehanizma, istog upravljanja procesima, ili isti izgled fajl sistema na svakom umreenom raunaru bi bio sledei logian korak. Posledica je da se identian kernel izvrava na svim mainama u sistemu. Distribuirani operativni sistem treba svuda da obezbedi istu jednomainsku sliku umreenih maina .Kljuno pitanje projektovanja distribuiranh operativnih sistema je koncept transparentnosti. Postoje nekoliko tipova transparentnosti: lokaciona transparentnost

migraciona transparentnost

replikaciona transparentnost

konkurentna transparentnost

paralelna transparentnost1.6.Kooperativni nezavisni sistemi

Distribuirani sistem je prirodno okruenje za podrku grupi korisnika koji zajedno rade na heterogenoj mrei.Ovaj koncept je nazvan raunarski podran kooperativni rad (Computer Supported Co-operative Work). Ideja o kooperativnim nezavisnim sistemima je proirenje svega toga. Drugim reima, cilj je da se obezbedi logiki mreni domen grupi korisnika da bi mogli da startuju specifine softverske sisteme sainjene od nezavisnih delova softvera. Kooperativni nezavisni sistemi treba da olakaju servise za integraciju nezavisnih aplikacija.

Dok su pravi distribuirani sistemi okarakterisani dekompozicijom servisa izmeu vie raunarskih sistema, kooperativni nezavisni sistemi se formiraju integracijom servisa.

1.7.Standardizacija

Potreba za kooperativnim nezavisnim sistemima je uslovila nekolko aktivnosti za standardizaciju distribuiranih raunarskih sistema.

Otvoreno Distribuirano Procesiranje (ODP- Open Distributed Processing)

ODP standardizuje OSI komunikacioni sloj. ODP je OSI proirenje koje se odnosi na krajnje ponaanje sistema. Cilj ODP-a je da omogui razvoj distribuiranih sistema u okruenju veeg broja prualaca usluga.

Distribuirano Raunarsko Okruenje (DCE- Distributed Computing Environment)

DCE je proizvod fondacije za otvoren softver (OSF). OSF je konzorcijum nekoliko raunarskih kompanija, ukljuujui IBM, DEC i Hewlett-Pacard, sa ciljem da razviju i naprave trite za Unix operativni sistem. DCE je integrisan paket softvera i alata za razvojn distribuiranih aplikacija na postojeim operativnim sistemima, prvenstveno Unix-u. DCE distribucioni model je baziran na svom RPC RPC (remote procedure call) olakanju i koristi proceduralno orjentisan distribucioni model. U DCE-u klijent poziva proceduru, koju RPC mapira sa odgovarjuom funkcijom na serveru.

Common Object Request Broker Architecture ( CORBA )

CORBA je specifikacija za standard objektno orjentisane arhitekture za aplikacije. CORBA je definisana od strane Objekt Menadment Grupe (OMG) u vodiu za arhitekturu upravljanja objektima. Verziju 1.1 ove specifikacije su zajedniki razvili DEC, Hewlett-Pacard, Hyper Desk Corporation, NCR, Object Design INC., i SunSoft Inc. a pregledana je i prihvaena od strane svih lanova OMG-a. CORBA distribucioni model je baziran na objektima i koristi objektno orjentisan distribucioni model. U CORBI klijent alje zahtev posredniku za objektne zahteve, koji tada upuuje zahtev klijenta serveru koji moe izvriti traeni zadatak.

Distribuirani Komponentno Objektni Model (DCOM - Distributed Components Object Model)

DCOM je proirenje Microsoft-ovom Komponentno Objektnom Modelu (COM) da bi se podrali objekti distribuirani preko mree. COM je otvorena softverska arhitektura od DEC-a i Microsoft-a, koja dozvoljava meusobnu saradnju ObjectBrocker-a i OLE-a

2.Koncepti distribuiranih sistema

2.1.Koristi od distribuiranih sistema

Primarni cilj distribuiranih sistema je sposobnost da se efikasnije koriste raunarski resursi. Ovo je omogueno korienjem sledeih tehnika

Deljenje resursa. To moe biti od koristi usled nedovoljnih hardverskih komponenti ili nedovoljnih podataka.

Rasporeivanje procesorskog opetereenja izmeu vie razliitih maina. To moe dovesti do znatnog ubrzanja proraunavanja.

Reflektovanje nasleene distributivnosti nekih aplikacija. Na primer meunarodni lanac hotela. Postoje razdvojeni lokalni racunari ali s vremena na vreme menadment zahteva globalan pogled.

Poveanje pouzdanosti. Poslovi koji su se izvravali na krahiranoj maini mogu biti preuzeti od strane druge maine

2.2.Servisi

Da bi se iskoristile mogunosti distrubuiranih sistema, servisi ponueni od strane konvencionalnih operativnih sistema moraju biti proireni. Postoje dva osnovna pristupa

Prvi, nazvan monolotni kernel, baziran je na centralizovanom operativnom sistemu, npr. UNIX, bez podrke za mrenu komunikaciju i integraciju udaljenih servisa.

Mikrokernelski pristup je baziran na ideji da se obezbede samo neophodni servisi kernela. Generalno, ovi servisi spadaju u etiri kategorije meuprocesne komunikacije, primitivnog upravljanja memorijom, U/I niskog nivoa, i mali deo upravljanja procesa niskog nivoa. Ostali servisi se nalaze izvan kernela i obezbeeni su od strane sistemskih servera. Neki od tipinih servera su procesni server, mrezni server, fajl server i autentifikacioni server. Ovi servisi su neophodni za implementaciju distribuiranih sistema. Dodatni servisi podravaju distribuirane aplikacije i nalaze se na vrhu sistemskih servisa. Primeri takvih servera su grupni server, mail server i web server.

2.3.Projektni zahtevi

U distribuiranim sistemima je dostupno vie procesora. Kako se procesori koriste, je glavno pitanje projektovanja. Procesori u distribuiranom sistemu mogu biti organizovani prema modelu radne stanice, procesorske liste ili njihovom kombinacijom.

Sledei projektni zahtev bavi se osnovnim osobinama distribuiranih sistema. To su transparentnost, fleksibilnost, pouzdanost i performanse.

Implementacija servisa distribuiranih operativnih sistema je podrana od strane distribuiranih algoritama. Postoji mnotvo centralizovanih algoritama, korienih od konvencionalnih operativnih sistema ani oni moraju biti ponovo provereni za distribuirano okruenje. Distribuirani algoritmi treba da uzmu u obzir sledee karakteristike distribuiranih sistema:

nedostatak globalnih informacija

nepostojanje globalnog sata

algoritam treba da je u stanju da rei situaciju kada se izgubi poruka ili krahira maina

2.4.Sistemski modeli

Osnovni model organizacije procesa u distribuiranom sistemu je model radne stanice. Ovaj model se prosto sastoji od meusobno povezanih radnih stanica. Ako je svaka od ovih radnih stanica komletna maina sa sposobnou da kontaktira druge maine, blii smo mrenom operativnom sistemu. Druga mogunost je da su neke maine posveene samo odreenim servisima. Na primer, svim datotekam se centralizovano upravlja na malom broju fajl servera. Tada se model preciznije naziva model radne stanice - servera. Nasuprot modelu sa kompletnim mainama, neke radne stanice mogu biti bez diska, i ako se obavlja udaljeno procesiranje te maine postaju terminali.

Reenje za nezaposlene maine je da se procesori sakupe na jednom mestu i da se dinamiki dodeljuju korisnicima na osnovu zahteva. Ova organizacija procesora u distribuiranim sistemima naziva se model procesorske liste. U tom modelu korisnici imaju sliku virtuelne vieprocesorske maine. Umesto radnih stanica inteligentni terminali (poput X terminala) su na raspolaganju korisnicima da pristupe sistemu.Dva pristupa, model radne stanice i model procesorske liste mogu biti kombinovani.Osnovni nain njihovog kombinovanja je da se model radne stanice proiri procesorskom listom. U tom hibridnom modelu korisnici mogu obavljati interaktivan rad na radnim stanicama, i da zahtevaju dodatnu procesorsku snagu iz procesorske liste za komplikovane proraune.Takoe je mogue da se procesori radnih stanica posmatraju kao oblik procesorske liste ako sistem poseduje efikasnu implementaciju migracije procesa.2.5.Transparentnost

Transparentnost zaklanja fiziku podeljenost objekata, njihovo upravljanje u distribuiranim sistemima, od njihovih korisnika. U isto vreme koncept transparentnosti kreira eljenu sliku sistema. Kompletna transparentnost je ekstremna. Ona nije uvek poeljna. Korisnik koji eli da odtampa dokument vie bi voleo da saeka da lokalni zauzeti tampa zavri posao nego da tampa na 100 kilometara udaljenom slobodnom tampau.

Postoji nekoliko tipova transparentnosti u distribuiranom sistemu

Lokaciona transparentnost znai da korisnici nisu svesni gde se objekti nalaze. Objektima se pristupa preko njihovih logikih imena. Oni ne moraju da sadre informaciju gde se objekti nalaze

Migraciona transparentnost znai da se objektima pristupa preko njihovih logikih imena ak i ako se oni prebace na drugu fiziku lokaciju bez menjanja njihovog logikog imena.

Replikaciona transparentnost znai da korisnici nisu svesni postojanja viestrukih kopija objekata u sistemu.

Konkurentna transparentnost znai da korisnici ne smetaju jedan drugom ako dele objekte Paralelna transparentnost omoguava paralelne aktivnosti bez znanja korisnika2.6.Fleksibilnost

Fleksibilnost je jedan od glavnih projektnih zahteva u distribuiranim sistemima, zato to trebamo da oekujemo razvoj novih tehnologija u budunosti koje moraju da budu ukljuene u trenutno projektovane sisteme. Drugi razlog je mogua potreba za poboljanjem distribuiranih sistema, ak i sa heterogenim komponentama. Drugim reima moramo da oslikamo mogunost da se sistem razvija u vremenu i prostoru.

Koncept fleksibilnosti ukljuuje osobine poput modularnosti, skalabilnosti, portabilnosti i meusaradnje.2.7.Pouzdanost

Pouzdanost je oigledno bitniji zahtev u distribuiranim sistemima nego u centralizovanim, zbog njihove visoke kompleksnosti i geografske distribucije.

Moe se desiti da korisnicima bude onemoguen rad zbog kvarova na komunikacionim linkovima ili udaljenim serverima. U sluaju kad je mnogo resursa potrebno da bi se izvrio zadatak, krajnja pouzdanost je proizvod pouzdanosti komponenti.Ovo ini kvarove u distribuiranim sistemima eim, jer je traeni servis dostupan samo ako sve komponente funkcioniu. Sa druge strane mogue je organizovati distribuirani sistem tako da ako jedna komponenta otkae druga preuzima njene poslove. Ova ideja poveava pouzdanost jer je servis dostupan ako bar jedna komponenta radi. Pouzdanost ima vie aspekata. Upravo smo raspravljani o jednom koji je nazvan dostupnost.

Povrh toga, ako servise obezbeuje grupa kooperatvnih servera, i ako servis nastavlja da bude dostupan kada jedan ili dva servera budu izgubljeni zbog nekog pada performansi sistem je otporan na greke. Otpornost na greke je jo jedan aspekt pouzdanosti.

Dok su kvarovi na komponentama u distribuiranim sistemima nenamerni, namerni upadi, ako je bezbednost naruena mogu izazvati ozbiljne tete. Bezbednost je novi vaan aspekt pouzdanosti.

2.8.Performanse

Posedovanje transparentnog, fleksibilnog distribuiranog sistema, sa estim preoptereenjima sistema, gde se aplikacije sporo izvravaju bilo bi beskorisno. Nasuprot tome performanse bi trebal biti bolje ili bar jednake izvravanju iste aplikacije na centralizovanom sistemu.

Poboljanje performansi deljenjem posla meu vie procesora zahteva slanje poruka. Poput toga, koordinacija nekoliko servera, koja obezbeuje pouzdane servise, zahteva razmenu informacija. Komunikaciona zadrka je injenica koja je neizbena u distribuiranim sistemima. Zbog toga komunikacioni sistem, ukljuujui komunikacione primitive i komunikacione protokole mora biti paljivo projektovani.

2.9.Distribuirani algoritmi

Generalno uzevi algoritmi korieni u centralizovanim sistemima ne mogu biti direktno korieni u distribuiranim sistemima. Sledee injenice se moraju uzeti u obzir:

Na razliitim vorovima je nepotpuna i nedosledna slika sistema, zbog nepostojanja deljene memorije i komunikacionih zadrki. Koordinacija izmeu procesa na razliitim vorovima se postie slanjem poruka.

Ne postoji globalan sat. ak i ako postoji centralni sat u distribuiranom sistemu, vremensko kanjenje prenoenja vremenske informacije razliitim vorovima e se razlikovati i moe varirati, na primer u zavisnosti od mrenog saobraaja.

Distribuirani sistemi mogu imati menjajuu topologiju, na primer zbog povezivanja novog vora. Kvarovi na komunikacionim linkovima i vorovima moe takoe izmeniti topologiju

U zavisnosti od upravljanja kontrolom, distribuirani algoritmi mogu biti potpuno centralizovani ili decentralizovani. Kasnije, ako centalizovani kontroler doivi kvar, algoritam mora biti u stanju da ga oporavi.

3.Konkurentni procesi i programiranje

3.1.Konkurentni procesi

Procesi su sekvencijalni programi koji se izvravaju. Sekvencijalni procesi imaju jednu nit kontrole izvrenja i adresni prostor.

Konkurentni procesi su sekvencijalni procesi koji se simultano izvravaju. Svaki od tih procesa ima svoj adresni prostor i oni su asinhroni. Neki od konkurentnih procesa se mogu razdvojiti i izvriti konkurentno. Ostalima moe biti potrebna koordinacija u obliku komunikacije ili sinhronizacije.

U nekim situacijama, raunanje mora biti podeljeno u viestruke kontrolne niti koje dele iste podatke. To dovodi do sjedinjavanja viestrukih kontrolnih niti (treads), prosto nazvanih niti, ili sitnih procesa, koji se izvravaju u deljenom adresnom prostoru. Na taj nain drugi nivo konkurentnosti se formira konkurentnim izvravanjem niti u procesu.

3.2. Korienje niti

Otkrie niti dozvoljava kombinovanje sekvencijelnih procesa, paralelno izvravanje i blokiranje procesa. Tipian primer njihovog korienja su serveri, poput terminal ili fajl servera

Serverski procesi su potrebni da bi se dobili slini servisi za vie klijenata. Klijenti mogu zahtevati te servise paralelno. Ako serverski proces ima jednu kontrolnu nit i trenutno je suspendovan ekajui neki dogaaj, zahtevi ostalih klijenta ne mogu biti obraeni i procesi klijenata su blokirani. Kreiranjem niti za svaki zahtev omoguava da se procesi klijenata ne blokiraju, ako je zahtevani proces suspendovan i niti u serverskim procesima mogu deliti uobiajne podatke. Serverski proces obrauje zahteve klijenata konkurentno, ali se svaka nit izvrava sekvencijalno.

Postoje dva osnovna pristupa implementaciji niti: u prostoru korisnikog programa i u kernelu. Kombinacija ova dva pristupa je takoe mogua.

3.2.1 Implementacija niti u prostoru korisnikog programa

Vienitni procesi su u potpunosti u prostoru korisnikog programa, i oni operativnom sistemu izgledaju kao obian jednonitni proces. Operatvini sistem dodeljuje procesorsko vreme procesu na uobiajen nain.Taj dodeljeni vremenski period je razdeljen meu nitima u procesu.

Niti se izvravaju preko izvrne biblioteke, koja je kolekcija procedura koje upravljaju izvravanjem niti. Kad nit koja se izvrava napravi blokirajui sistemski poziv, ona poziva izvrnu proceduru, koja snima registre niti iz koje je pozvana (programski broja, registar, pokaziva na stek), odabira nit spremnu za izvravanje i uitava vrednosti koje su uskladitene u niti u registre. Efektivno se ne pojavljuje blokiranje procesa, izvravanje procesa se nastavlja izvravanjem odabrane niti. Menjanje niti na ovaj nain zahteva veoma malo dodatnog optereenja.

Rasporeivanje niti se obavlja podrkom izvrnog sistema, i uglavnom je neprekidno, zbog nedostatka vremenskih prekida u okviru procesa. To zani da ako nit pone da se izvrava, ona se izvrava dok ne bude blokirana.

3.2.2 Implementacija niti u kernelu

Niti se stvarju i unitavaju pozivima kernela i kernel ih stvara i unitava. Niti su tretirane kao jednonitni procesi. Kada se nit blokira kernel moe odabrati da pokrene novu nit iz istog procesa ili nit iz nekog drugog procesa. Poto niti rasporeuje kernel, dozvoljeno je rasporeivanje sa izbacivanjem. Nizak troak menjanja niti je izbaen.

Kombinacija implementacije u prostoru korisnikog programa i kernelu (npr. Sun-ov Solaris) zadrava prednosti oba pristupa. Na primer na Solarisu postoji srednji nivo niti nazvan jednostavniji proces (light weight proces), koji slue kao veza izmeu niti kernela i korisnikih niti. Light weight procese kreiraju korisniki procesi. Korisnikie niti su razdeljene light weight procesima, a light weight procesi su razdeljeni na procese kernela, formirajui tri nivoa konkurentnosti. Tada blokirajui poziv korisnikog procesa moe blokirati povezani light weight proces, ali korisniki proces moe nastaviti izvravanje izvrenjem niti povezane sa drugim light weight procesom u istom korisnikom procesu. Rasporeivanje korisnikih niti sa izbacivanjem je mogue jer light weight procesi mogu biti izbaeni od strane kernela.

3.3 Klijent - Server model

Ideja ovog modela je da se napravi kooperacija procesa izmeu servera koji obezbeuju servise i klijenata koji servise zahtevaju. Ova paradigma se koristi na nivou aplikacije podjednako kao i na nivou operativnog sistema. Svaki proces u interakciji igra ili ulogu servera ili ulogu klijenta. Sa druge strane, proces koji se ponaa kao server moe zahtevati servis od drugog servera da bi izvrio neki zadatak, time dobijauji i ulogu klijenta. Maina moe biti jedan klijent, jedan server, vie klijenata ili servera ili meavina klijenata i servera.

Logika komunikacija izmeu klijenata i servera je bazirana na razmeni zahteva i odgovora:

Klijent alje zahtev serveru i blokira se

Server prima zahtev, obavlja traeni posao, i vraa odgovor klijentu.

Klijent prima odgovor i nastavlja izvravanje

Fiziki, zahtevi i odgovori se prosleuju dotinom kernelu, i alju kroz komunikacionu mreu ciljnim kernelima i procesima. Iz jednostavnosti ovog modela proizilazi potreba za samo dva komunikaciona sistemska poziva kernelu: send (poalji) i receive (primi) poruku.

Vano pitanje je kako klijent locira server ako on promeni lokaciju ili postoji vie servera. Zbog fleksibilnosti serveri se identifikuju preko imena. Serveri, nazvani vezujui serveri (binder servers) spajaju klijente i servere. Procedura koja izvrava ovo spajanje je nazvana dinamiko povezivanje (dynamic binding). Kada se server startuje, on alje povezivau podatke o svojoj lokaciji. Tada klijenti preko povezivaa znaju lokaciju odgovarajueg servera. Kao dodatak, poveziva moe pomagati u autentifikaciji klijenata za servere.

3.4 Vreme u distribuiranim sistemima

Vreme ima bitnu ulogu u raunarskim sistemima. Na primer, procesi su rasporeeni za izvravanje, odrava se vreme pristupa fajlovima, isteci vremena se koriste u drajverima za ureaje, dogaaji, poput backup-a sistema u pono su raporeeni. U centralizovanom sistemu, vremenski servisi su dati od strane kernela, koji koristi prekide hardverskog sata. Na taj nain svi softverski zahtevi za vremenom, vremenska taka ili vremenski interval, su zadovoljeni od istog izvora. tavie, ako je tano podeeno, sistemsko vreme je priblino jednako realnom vremenu.

U distribuiranim sistemi se sreemo sa potpuno razliitom situacijom. Svaka maina poseduje svoj sat, i nemogue je garantovati identinu brzinu svakog od njih. Postoji nepredvidivo propagaciono kanjenje prilikom obavetavanja o vrednosti sata u distribuiranim sistemima. Zbog toga je nemogue saznati globalno fiziko vreme.

Rasporeivanje dogaaja bi trebalo da bude bazirano na fizikom vremenu nihovog pojavljivanja. Zbog nedostatka globalnog fizikog vremena ta metoda je nedostupna. Koncept rasporeivanja dogaaja koji se koristi u distribuiranim sistemima je bez globalnog fizikog sata, i zove se logiki sat.

3.4.1 Logiki sat

Dogaaji u istom procesu su rasporeeni redosledom pojavljivanja. Dodeljujemo logiki sat svakom procesu, pa ako se dogaaj a pojavi pre dogaaja b tada logiki satovi C(a) i C(b) zadovoljavaju relaciju C(a) < C(b). Prosto gledano logiki sat je celobrojni broja koji se uvea svaki put kada nastupi dogaaj.

Sinhronizacija logikih satova se bazira na interakciji procesa slanjem poruka. S obzirom da se slanje poruke u jednom procesu pojavljuje pre primanja te poruke u drugom procesu, moemo oekivati da odgovarajui logiki satovi slanja i primanja zadovoljavaju relaciju C(slanje) < C(primanje). To je osigurano ako proces koji alje doda poruci vrednost svog logikog sata, nazvanu marker vremena (timestamp) i proces koji prima postavlja svoj logiki sat na veu vrednost izmeu svog sata i uveane vrednosti markera vremena.

S obzirom da je relacija pojavilo se ranije, koja se tako zove desilo se ranije, tranzitivna, dodeljivanje vrednosti logikom satu na ovaj nain odrava relaciju izmeu vremena pojavljivanja bilo koja dva dogaaja koji sluajno utiu jedan na drugi, kao to je gore opisano. Zbog toga je uvedena totalna ureenost izmeu takvih sluajno povezanih dogaaja.

Sa druge strane, mogu postojati dogaaji u razliitim procesima koji se mogu pojaviti pre, posle, ili paralelno jedan sa drugim, npr dogaaji koji se pojave izmeu dve uzastopne razmene poruka u dva procesa. Za takve dogaaje se kae da su razdvojeni ili konkurentni. Jasno je da je skup svih dogaaja samo parcijano ureen.Nekim distribuiranim algoritmima je potrebna potpuna ureenost svih dogaaja. To se moe reiti dodavanjem jedinstvene vrednosti procesa u kome je dogaaj nastupio, na logiki sat dogaeja. Ako se desi da dva dogaaja u razlitim procesima imaju isti marker vremena, prednost odreuje nii broj procesa. Ako su Ci(a) i Cj(b) vrednosti logikog sata dogaaja u procesima Pi i Pj , generalno se ne moe odrediti da li je dogaaj a nastupio pre dogaaja b ako je Ci(a) < Cj(b) jer mogu biti konkurentni. Tu situaciju reava vektorski logiki sat. Vektorski logiki sat dogaaja a u procesu Pi je vektor [TS1, TS2, ..., Ci(a), ..., TSn] gde je n broj procesa, TSk, k=1, ...,n, ki je posladnja znana vrednost logikog sata za proces Pk, dobijena kao vremenska marka razmenom poruka, a Ci(a) takoe oznaava TSi, vrednost logikog sata dogaaja u procesu Pi.

Svaki proces inicijalizuje svoj vektorski sat na prazan vektor na poetku izvravanja. Vektorskim satom dogaaja u istom procesu se pristupa kao skalarnom satu. Kada proces Pi poalje poruku (dogaaj a), negov vektorski sat VCi(a) se doda poruci. Prihvatajui proces Pj postavlja svoj vektorski sat VCj(b) po prijemu te poruke (dogaaj b) takav da je TSk(b), k(j ureeni par najveih vrednosti prispelog vektorskog sata VCi(a) i sopstvenog vektorskog sata, i uveava svoj logiki sat Cj.

Jasno je da ako se dogaaj a u Pi pojavi pre nego dogaaj b u Pj tada je TSk(a)(TSk(b), k=1, ..., n, k(j i TSk(a)Sk.

Odbaci poruku sko je TiiSi.

Protokol uzronog poretka simulira multiprenos u zatvorenoj grupi, i multiprenosi ne mogu spojiti grupe.4.6.3 Atomski multiprenos

Implementacija: dve faze, multiprenos potpunog poretka.

1. Faza: Tvorac poruka emituje poruke i prikuplja potvrde sa logikim vremenskim rokom od svih lanova grupe.2. Faza: Nakon to su sve potvrde prikupljene, tvorac alje commitment poruku koja nosi najvei vremenski rok potvrde kao logiku vezu za angaovanje. lanovi grupe tada odluuju da li angaovana poruka treba biti smetena ili isporuena bazirajui se na globalnim logikim vremenima angaovanja multiprenosnih poruka.4.7 Komunikacija upit/odgovor

Komunikacija upit/odgovor je servisno orjentisana i predstavlja sledei nivo komunikacije u odnosu na prenoenje poruka.

Komunikacija upit/odgovor koja se najee koristi je daljinsko pozivanje procedura (Remote Procedure Call- RPC), koji predstavlja jeziku apstrakciju mehanizma upit/odgovor. RPC je istovetan lokalnom pozivu procedure, ali ima razliitu semantiku (zadravanja, prekidi u mrenoj komunikaciji). RPC je jednostavan i elegantan nain postizanja transparentne komunikacije pomou omota sistemskih poziva niskog nivoa, konverzije podataka i mrene komunikacije.

Primeri RPC:

SUN-RPC (SunSoft)

DCE-RPC (Open Group)

4.7.1 Parametar prenosa i konverzija podataka

Veina RPC implementacija koriste call-by-value i call-by-copy/restore parametre prenosa. Call-by-copy/restore parametar prenosa je kombinacija call-by-copy na ulazak procedure i call-by-reference na povratak, kada su rezultati prekopirani u pozivajuu proceduru.

RPC se moe javljati izmeu sistema sa razliitim arhitekturama, pa se stoga parametri i vraene vrednosti moraju predstavljati na standardan nain. Ovo obuhvata konverziju izmeu sintakse podataka i poruka i dovodi nas do tri jedinstvena problema:

zapisivanje podataka

predstavljanje podataka

sintaksa prenosa podataka

Abstract Syitax Notation One (ANS.1) je standard za zapisivanje i predstavljanje podataka. Postojee RPC implementacije najvie koriste podskup ANS.1. Primeri:

SUN-RPC koristi XDR (eXternal Data Representation)

DCE-RPS koristi IDL (Interface Definition Language)

Parametar prenosa i data/message konverzije se esto nazivaju parametar uvoenja.

4.7.2 RPC kompilacija

RPC je jezika apstrakcija i zbog toga zahteva komilaciju, tj. prevoenje. Glavne komponente ovog procesa su:

datoteka interfejs specifikacije koja opisuje interfejs servisima koje server obezbeuje i koje klijent moe da pozove

RPC generator koji uzima interfejs specifikaciju kao ulaz i proizvodi klijent i server izvorni kod stub procedure kao izlaz

Run-time biblioteka za podraavanja izvrenja RPC (obuhvata pomo za povezivanje, konverziju podataka i komunikaciju)

4.7.3 Povezivanje

Povezivanje opisuje proces prijavljivanja servisa koje prua server i proces pronalaenja servera od strane klijenata. Obuhvata sledee korake:

na poetku, server alje svoj program i broj verzije zajedno sa portom, koji slua, port mapper-u. Port mapper je serverov proces, koji upravlja program/port planiranjem i ima dobro poznatu adresu porta

pre daljinskog poziva procedure, klijent kontaktira udaljeni port mapper radi dobijanje rukovanja udaljenim serverom

port mapper vraa broj porta eljenog servisa (ako je registrovan)

klijent tada koristi clijent handle za kasniji RPC.

Ako je serverova maina nepoznata, druga sredstva (kao server sadraja) se prvo moraju koristiti za lociranje serverove maine.

4.7.4 RPC izuzeci i upravljanje otkazima

Upravljanje izuzecima je komplikovanije nego kod lokalnih poziva procedura. Server mora izvestiti klijenta o statusnim informacijama, a klijent mora da poalje kontrolne informacije serveru. Signalni podaci mogu biti: poslati zajedno sa podacima

in-band signaliziranje, gde su signalni podaci unutar normalnih podataka out-band signaliziranje, gde signalni podaci koriste poseban kanal (out-band signaliziranje je podrano sa strane mnogih prenosnih servisa) koristi se zasebna konekcija

izuzecima se upravlja transparentno uz pomo stub biblioteke.

Upravljanje otkazima

otkaze je teko pronai i uiniti jasnim

Mogui tipovi otkaza:

greka lociranja servisa njome se moe upravljati kao izuzetkom

izgubljene poruk reava se retransmisijom koja dovodi do problema viestrukih servisnih poziva koji se moe reiti pomou:

pravljenja zahteva istog znaaja, tj. ponovljeni zahtev proizvodi iste rezultate (na primer: itanje bloka, pisanje u bloku, ali ne dodavanje bloka datoteci)

korienjem rednih brojeva ili korienjem pouzdane konekcije transportno orjentisanog servisa (TCP)

pad sistema klijent ne zna da li je servis izvren ili ne, a eljena semantika je da servis bude izvren tano jednom. Ovo se mora implementirati korienjem transakcija.

krah klijenta dovodi do ostataka raunanja kod servera, koji se moe eliminisati pomou:

klijenta prilikom ponovnog butovanja klijent brie status servera

servera periodino proverava postojanje svojih klijenata

izdisanja'' operaciji je dat ivotni vek i klijent mora eksplicitno da trai dodatno vreme

4.7.5 Sigurnost: Suns Secure RPC

Sigurnost je vana za RPC RPC dozvoljava daljinska izvrenja i tako dovodi do ranjivosti raunarskog sistema. RPC je osnova za klijent/server komunikaciju i to nagovetava da sve karakteristike pouzdanosti raunarskog sistema treba da budu izgraene na vrhu pouzdanosti RPC.

Suns Secure RPC:

koristi javne kriptografske metode tokom logovanja i simetrine kriptografske metode (DES) za komunikaciju sa kljuem etape

Secure RPC poruke mogu sadrati kao dodatk podacima: vremenski rok, sadanjost, pregled poruka

koristi NIS+ (Network Information Service) kao mesto za smetanje korisnikovih mrenih naziva javnih i tajnih kljueva.

4.8 Transakciona komunikacija

Kombinacija multi prenosa i upit/odgovor komunikacije formira novi nivo komunikacije koja se zove transakciona komunikacija. Transakcija je skup asinhronih komunikacija upit/odgovor koje poseduju ACID (atomnost, konzistentnost, izolovanost, trajnost) osobine nasuprot bazama podataka, bez prinudnog redosleda. Komunikaciona transakcija moe implicirati multiprenos iste poruke kopiranim serverima i razliitih zahteva podeljenim serverima.

Atomnost: ili su sve operacije izvrene ili nijedna

Konzistentnost: izvrenje interno odobrene transakcija je ekvivalentno serijskom izvrenju transakcija po nekom redosledu. Konzistentnost se takoe naziva i serijabilnost.

Izolovanost: parcijalni rezultati nedovrene transakcije nisu dostupni drugima pre uspenog zavretka transakcije.

Trajnost: sistem garantuje da e rezultati izvrene transakcije biti permanentni, ak iako se dogodi otkaz nakon smetanja.

ACID svojstva se mogu postii uz pomou dvofaznog protokola (Two-phase Commit Protocol 2PC)

4.8.1 Dvofazni protokol

Dvofazni protokol je analogan shemi tajnog glasanja:

glasanje inicijalizuje koordinator transakcije

svi uesnici distribuirane transakcije moraju doi do dogovora da li izvriti ili prekinuti transakciju i moraju ekati saoptenje odluke

pre nego to uesnik glasa za izvrenje mora biti spreman da obavi to izvrenje

transakcija se izvrava samo ukoliko su svi uesnici pristali i spremni za izvrenje.

Svaki uesnik (ukljuujui koordinatora) odrava privatni radni prostor za praenje aururanih objekata podataka (sadri staru i novu vrednost).

Da bi savladali otkaze, aurirani podaci se smetaju log stabilne aktivnosti. Log aktivnosti se moe koristiti za oporavak nakon otkaza za ponovno izvrenje izvrene transakcije ili za ponitavanje neizvrene.

4.8.2 Tok izvravanja 2PC

1. Koordinator poinje pisanjem precommit zapisa na svoj log aktivnosti; koordinator mora biti spreman da izvri transakciju

2. Zahtev za glasanje se alje svim uesnicima

3. Kada uesnik primi zahtev za glasanje, on proverava da li transakcija moe biti izvrena i ako moe pie precommit svom logu aktivnosti i alje DA kao odgovor, u suprotnom prekida transakciju I alje NE kao odgovor.

4. Ukoliko je koordinator u stanju da prikupi sve DA odgovore u odreenom vremenskom intervalu, on izvrava transakciju tako to pie commit zapis na svoj log I alje commit pruku svim uesnicima.

5. Kada primi commit poruku, uesnik izvrava transakciju tako to zapisuje commit zapis u svoj log aktivnosti i oslobaa transakcione izvore.

4.8.3 Oporavak

S obzirom da pisanje precommit i commit zapisa u log aktivnosti brie sve aurirane podatke pre ovih sinhronizacionih taaka, odgovarajue akcije prilikom oporavka od otkaza mogu se osloniti na odgovor loga barem do sinhronizacionih taaka. Akcije oporavka se mogu kategorizovati u tri tipa:

otkazi pre precommit

otkazi nakon precommit, ali pre commit

otkazi nakon commit

4.9 Servisiranje po imenu i sadraju

Look-up operacije dato ime ili atributi entiteta. Vie atributa je steeno

Bilo koji objektni entitet (servisi ili objekti) u sistemu moraju biti imenovani (prepoznatljivi) i lociran

Operacija lociranja servisa, resolution proces, je podeljen u dva dela:

rezolucija imena mapira imena do logikih adresa osnovna funkcija distribuiranih sistema

rezolucija adrese mapira logike adrese do mrenih putanja (fizike lokacije) ovo je domen mrenog softvera

Primeri servisa sadraja:

X.500 (ITU)

DCE servis koji daje nazive

CORBA COS servis koji daje imena

4.9.1 Rezolucija imena

U kontekstu rezolucije imena zainteresovani smo za dva specijalna atributa objekta, a to su ime i adresa. Imena su atributi sa jedinstvenom vrednou koji slue za identifikaciju. Kolekcija imena, koja je prepoznatljiva servisu imena, sa njihovim odgovarajuim atributima i adresama, se naziva name space. Name space velikog obima koji sadri razliite klase objekata se moe struktuirati izimajui u obzir jedinstvene tipove.

Naziv objekta (entiteta):

moe biti sam atribut (flat naziv)

moe sastojati od nekoliko atributa

hijerarhijski struktuiran (olanani atributi)

structure free (kolekcija atributa)

Podela atributa za ime objekta mogu biti:

fizicka

organizaciona

funkcionalna

Shema rezolucije imena moe biti:

hijerarhijska struktura bazirana na imenima

structure free bazirana na atributima

Performanse rezolucije imena se mogu poveati pomou caching i replication.

4.9.2 Informaciona baza sadraja

Konceptualni model podataka za smetanje i predstavljanje objektnih informacija se naziva informaciona baza podataka (Directory Information Base DIB). Servis sadraja (Directory Service DS) ITU X.500 standarda daje strukturna i sintaksna pravila za opisivanje DIB u hijerarhijskom Directory Information Tree (DIT). Atributi koji odgovaraju ulaznom objektu predstavljaju skup atributa sa vorova korena stabla. Atributi koji se koriste za imenovanje se nazivaju distinguished attributes (na primer: drava, organizacija, korisnik).

Name space velikog obima (i odgovarajui DIT) moe se rastaviti na imenovane domene (samo administrativno rukovodstvo) i imenovane kontekste (podstabla)

Directory Service Agents (DSA) serveri za servise imena

Directory User Agents (DUA) inicijator procesa rezolucije imena

5. MEUPROCESNA KOORDINACIJA

5.1 Kooperativni procesi

Viestruki procesi esto moraju dostii neki sporazum (na primer da bi pristupili deljenom objektu) ili neke zakljuke o sistemu (na primer u vezi tipologije sistema).

Razmatramo tri osnovna scenarija komunikacije:

jednosmerana

klijent/server

ravna komunikacija

Ravna komunikacija je neophodna za postizanje pomenute koordinacione aktivnosti kooperativnih procesa.

Dva vna problema distribuirane koordinacije su:

distribuirana meusobna iskljuenja

distribuirani izbor takozvanog lidera.

5.2 Distribuirana meusobna iskljuenja

Klasian problem meusobnog iskljuenja zahteva da konkurentni procesi imaju serijski pristup deljenim resursima ili podacima.

Algoritmi koji se koriste u jednoprocesorskim sistemima baziraju se na konstruisanju sebe samih koristei deljene podatke (na primer, semafori, monitori i slino).

U sluaju distribuiranih sistema problem se mora reiti samo korienjem ravne komunikacije.

Za reavanje problema distribuiranog meusobnog iskljuenja moe se koristiti ili pristup na bazi argumenta ili kontrolisani pristup.

Pristup na bazi argumenta podrazumeva da se sukob oko pristupa deljenom objektu, kada se istovremeni zahtev pojavi, reava korienjem nekog kriterijuma za prekid veze. Mogui kriterijumi koji omoguavaju nepristrasnu odluku su (logiko) vreme zahteva (zahtevprvog procesa je odobren) ili glasanje (proces koji je dobio najvie glasova je odobren).

Kod kontrolisanog pristupa, pravo pristupa je predstavljeno uz pomo logikog tokena, koji se proputa na kontrolisani nain izmeu konkurentnih procesa.

5.2.1 Lamport-ovi algoritmi distribuiranih meusobnih iskljuenja

Koncept Lamport-ovog logikog sata se koristi za potpuno ureenje svih zahteva za ulazak u kritinu oblast. Algoritam radi na sledei nain. Kada proces eli da ue u kritinu oblast, on alje vremenski utisnutu REQUEST poruku svim ostalim procesima, ukljuujui i sebe. Kada primi REQUEST poruku, proces stavlja u red poruku i alje REPLY poruku procesu koji je poslao zahtev. Proces moe da ue u svoju kritinu oblast samo ako je primio sve REPLY poruke i ako njegova poruka u redu ima najkrai vremenski rok. Kada naputa kritinu oblast, proces alje RELEASE svim ostalim procesima. Kada primi RELEASE poruku, proces uklanja zavren zahtev iz svog reda i ako njegov ureeni zahtev ima najkrai vremenski rok, dozvoljeno mu je da ue u svoju kritinu oblast. Oigledno, ukupan broj potrebnih poruka po ulasku je 3*(N-1), gde je N broj procesa u sistemu.

Kompleksnost poruke Lampert-ovog algoritma su umanjili Ricart i Agrawala.

5.2.2 Ricart i Agrawal-ov algoritam distribiranih meusobnih iskljuenja

Kao i kod Lamport-ovog algoritma, kada proces eli da ue u kritinu oblast, on alje vremenski utisnutu REQUEST poruku svm drugim procesima, ukljuujui i sebe. Kada primi REQUEST poruku, akcija koju preduzma proces koji je primio poruku zavisi od njegovog stanja. Razlikuju se tri sluaja:

1. Ukoliko on nije u kritinoj oblasti niti eli da ue u nju, on alj natrag REPLY poruku.

2. Ukoliko je u kritinoj oblasti, on ne odgovara i stavlja poruku u red.

3. Ukoliko eli da ue u svoju kritinu obast, on uporeuje vremenski rok poruke, koju je primio, sa onim koji se nalazi u njegovoj REQUEST poruci, koju je poslao svim drugim procesima. Ukoliko je vremenski rok poruke koju je primio manji, primalac poruke alje nazad REPLY poruku, a u suprotnom REQUEST poruku stavlja u red.

Prijavljenom procesu je dozvoljeno da ue u svoju kritinu oblast samo ako je prikupio REPLY poruke od svih ostalih procesa, kao i kod Lamport-ovog algoritma. Kada naputa kritinu oblast, on alje REPLY poruke svim procesima iz njegovog reda i uklanja ih iz reda. Kompleksnost poruka je smanjena na 2*(N-1).

5.2.3 Algoritmi distribuiranih meusobnih iskljuenja zasnovani na glasanju

Kada se koristi Lampot-ov ili Ricart i Agrwala-ov algoritam, ako je jedan jedini procesor nedostupan, proces koji trai da ue u svoju kritinu oblast ne moe prikupiti sve REPLY poruke i kao posledica toga, on je onemoguen da pristupi kritinoj oblasti.

Ideja izbora se zasniva na dobijanju veine glasova i moe primeniti na problem distribuiranih meusobnih iskljuenja.

Kada proces primi REQUEST poruku, on alje natrag REPLY poruku (glas) samo ako nije glasao za neki drugi prijavljeni proces. Proces koji je sakupio veinu glasova moe da pristupi svojoj kritinoj oblasti. Kada naputa kritinu oblast proces alje RELEASE poruku svim drugim procesima. Nakon to primi RELEACE poruku proces moe ponovo da glasa. S obzirom da smo jedan proces moe da prikupi veinu glasova u jednom trenutku, meusobno iskljuenje je zagarantovano.

Problem ovog algoritma je zastoj, na primer, ako je N paran broj, dva procesa mogu imati podjednak broj glasova. Da bi se reio ovaj problem, potrebna je globalnija komunikacija.

Algoritam izgleda ovako. Vremenski rok je vezan za svaku REQUEST poruku. Ukoliko proces koji je glasao primi REQUEST poruku koja ima manji vremenski rok u odnosu na procesa za koji je glasao, proces pokuava da povrati glas tako to alje INQUIRE poruku procesu kome je dao glas. Kada primi INQUIRE poruku, ukoliko proces nije uao u kritinu oblast, on vraa glas procesu koji je poslao INQUIRE poruku tako to mu upuuje RELINQUSH poruku. U suprotnom, glas se vraa slanjem RELEASE poruke kada proces napusti svoju kritinu oblast. Kada proces povrati svoj glas, glasa za proces sa najmanjim vremenskim rokom.

Kompleksnost poruke po ulasku je O(N) plus poruke za izbegavanje zastoja. Dodatne poruke se mogu umanjiti smanjenjem broja glasova koji je potreban za ulazak u kritinu oblast. Svakom procesu pridruujemo podskup svih procesa koji nazivamo skup zahteva. Procesu treba glas od svakog procesa iz svog skupa zahteva. Presek svaka dva skupa zahteva mora biti neprazan skup da bi se osiguralo meusobno iskljuenje.

5.2.4.1 Meusobno iskljuenje prenoenjem tokena. Topologija logikog prstena

Trokovi poruka algoritama meusobnog iskljuenja na bazi argumenta su visoki. Specijalna vrsta poruke, koja se predaje kao token, moe preneti doputenje za ulazak u kritinu oblast. Prosleivanje tokena mora biti kontrolisano tako da podnosilac zahteva u svoje vreme dobije token. Algoritmi prosleivanja tokena namee logiku topologiju procesima radi ostvarivanja ovog cilja.

Procesi formiraju logiki prsten u okviru koga token krui. Vlasnik tokena moe da ue u svoju kritinu oblast. Kada izae iz kritine oblasti, on alje token nasledniku. Ukoliko proces ne eli da pristupi svojoj kritinoj oblasti, on prosleuje token dalje. Tako, token krui po prstenu ak i ako ni jedan proces ne eli da ue u svoju kritinu oblast, a rezultat su nepotrebne poruke.

Tipologija prstena koja je nametnuta procesima nije najbolji nain za dobijanje tokena, jer putanja moe biti dugaka (na primer, ako je zahteva poslao token neposredno pre nego to je hteo da pristupi svojoj kritinoj oblasti, putanja je za jedan korak kraa od duine celog kruga). Alternativno reenje je nametnuti procesima tipologiju stabla.

5.2.4.2 Meusobno iskljuenje prenoenjem tokena. Struktura logikog stabla

Struktura stabla je nametnuta procesima na sledei nain. Stablo je ukorenjeno u vlasnicima tokena. Ivice u stablu su orjentisane, tako da pokazuju prema korenu. Stoga, sledei vor koji lei na putu izmeu onog koji trai i onog kod koga je token je vor na koji dolazea ivica pokazuje. Zahtev za tokon je poslat ovim putem. Ukoliko je vor ve traio token, ne mora triti ponovo kada primi drugi zahtev s obzirom da e token stii u svoje vreme. Povratna putanja tokena mora biti zabeleena na putu zahteva do korena. Svaki vor tog puta stavlja vor koji je poslao zahtev u lokalni FIFO red. Sada, glave FIFO redova definiu povratnu putanju. Ako posednik tokena ne koristi token, a postoji zahtevi u njegovom FIFO redu, token se alje procesu sa poetka FIFO reda, proces se uklanja iz FIFO reda, i orjentacija odgovarajue ivice se menja. Ako postoji jo neki nereen zahtev, vor ispraa zahtev s obzirom na izmenjen pravac ivice. Ukoliko je sam proces na poetu FIFO reda, uklanja se iz FIFO reda i ulazi u svoju kritinu oblast. Predstavljeni algoritam je zasluga Raymonda. Viak poruka u Raymond-ovom algoritmu je O(logn) po ulasku u kritianu oblast.

5.2.5 Meusobno iskljuenje prenoenjem tokena. Prenos

Nametanje logike topologije procesima prozrokuje trokove, s obzirom da se topologija mora kreirati i odravati. Token, kao specijalna vrsta poruke, moe nositi korisne globalne informacije zajedno sa procesima. Prenos se koristi za upravljanje ovim centralno smetenim informacijama na distribuirani nain. Suzuki/Kasami-je algoritam prenosa je sledei.

Proces trai token tako to emitiju REQUEST poruku koja sadri lokalni redni broj seq. Svaki proces ustanovljava lokalni redni vektor S. Ulazi vektora S indeksirani brojevima procesa i sadre najvei redni broj koji je proces ikada imao. Kada zahtevaoc req emituje REQUEST poruku njegov ulaz S[req] se inkrementira S[req]=S[req]+1 i seq=S[req]. Nakon primanja REQUEST poruke, primalac aurira svoj vektor S, S[req]=max(S[req].seq).

Token se sastoji od token vektora T i FIFO reda zahteva. Ulazi vektora T takoe su indeksirani brojevima procesa i sadri broj zavretaka kritine oblasti od strane odgovarajueg procesa. Kada proces kod koga je token primi REQUEST poruku, on preduzima sledee akcije:

1. Aurira svoj vektor S.

2. alje token zahtevaocu ako je S[req]=T[req]+1.

Kada proces primi token moe da prisupi svojoj kritinoj oblasti. Nakon zavretka kritine oblasti, proces p preduzima sledee akcije:

1. Podeava T[p]=S[p].2. Prikljuuje sve procese sa S[k]=T[k]+1, izuzev k=p, redu zahteva u tokenu, ako ve nisu u njemu.

3. Ako je red zahteva prazan, zadrava token. U suprotnom, uklanja ulaz sa vrha reda zahteva i alje token procesu koji je naznaen u uklonjenom ulazu.

5.4.1 Algoritmi za izbor lidera. Potpuna topologija

Mnogi distribuirani algoritmi zahtevaju jedan proces koji igra specijalnu ulogu (na primer, ponaa se kao centralni kontrolor). Generalno, nije vano koji proces iz grupe procesa igra specijalnu ulogu, ali jedan mora to da uradi. Koristiemo termin lider kao generiko ime za specijalan proces. Otkaz lidera moe ograniiti funkcionisanje sistema. Problem se moe umanjiti biranjem novog lidera kada postojei lider otkae. Algoritam izbora lidera pokuava da izabere lidera iz grupe procesa koji se trenutno izvravaju. Algoritam za izbor lidera se aktivira kada se sistem inicijalizuje ili kada postojei lider otkae. Tipino, otkrivanje otkaza je bazirano na pauzama. Slino kao kod algoritama distribuiranih meusobnih iskljuenja, algoritmi za izbor lidera takoe zavise od topologije grupe procesa.

Prvo emo razmatrati potpunu topologiju, gde svaki proces u grupi moe dosegnuti bilo koji drugi proces iz iste grupe u jednom skoku. Dalje pretpostavke su sledee:

1. Svaki proces u grupi ima jedinstveni broj.

2. Komunikacioni kanali su pouzdani.

3. Detekcija otkaza je sigurna korienjem skupa vremenskih intervala koji su malo vei od zbira zadravanja poruke u putu i upravljanja porukom. Proces koji je otkazao znae da je okazao kada se oporavi.

P alje ELECTION poruku svim procesima sa viim brojevima.

Ukoliko nema odgovora, P alje svim procesima sa niim brojevima LEADER poruku pokuavajui da postavi sebe za lidera. P potaje lider nakom to primi odgovor na LEADER poruku ili ako istekne vreme za odgovor za svaki nie numerisan proces.

Ako postoje UP odgovori od procesa sa viim brojevima, P odustaje i proces sa viim brojem zapoinje izbore, ako ih ve ne odrava. Na kraju, svi procesi osim jednog odustanu, i taj proces je novi lider.

Kada se oporavi proces koji je otkazao, on zapoinje izbore.

5.4.2 Algoritmi za izbor lidera.Topologija logikog prstena

Pretpostavka za algoritme koji koriste topologiju logikog prstena je da nakon to je prsten inicijalno konstruisan, topologija se odrava na mestu otkaza vora. Ovo se ostvaruje lake ako postojea mrea podrava prenos u hardveru. Otkazi se otkrivaju i prsten se ponovo konfigurie prikazivanjem i emitovanjem poruka. U suprotnom, prenos se simulira point-to-point komunikacijom.

Kada bilo koji proces u prstenu primeti da lider ne funkcionie, on zapoinje izbore tako to alje svom nasledniku ELECTION poruku koja sadri njegov id. Poruka krui u prstenu i svaki proces joj dodaje svoj id. Kada se poruka vrati inicijatoru izbora, on bira proces sa najveim id u poruci i prenosi liderov id ostalim procesima.

Chang i Roberts su poboljali algoritme krunih izbora na dva naina. Prvo, suvino je ako poruka, koja je poslata du prstena, sadri najvii ulazni i primaoev id. Sada, lider je izabran ako su ulazni i primaoev id jednaki. Drugo, proces koji ve uestvuje u izborima ne mora da alje napred poruku, osim ako je njegov id vei od onog koji je sadran u ulaznoj poruci.

6. RASPOREIVANJE DISTRIBUIRANIH PROCESA6.1Strategije Rasporeivanja Distribuiranih Procesa

Kod distribuiranih sistema, obino postoji veliki broj procesora slobodnih za izvravanje sekvencijalnih procesa. Kako bi se iskoristo ovaj operativniprostor, mora se doneti odluka koji e se proces kada izvriti i na kom procesoru. U prilog tome mora postojati nain da se procesi rasporede na bilo koji od postojeih procesora. Gore navedeni problem je poznat kao rasporeivanje distribuiranih procesa.Glavna svrha rasporeivanja distribuiranih procesa je dodeljivanje procesora procesima na efikasan nain, tako da vreme izvravanja procesa minimalno ili efikasnom upotrebom resursa.

Problem rasporeivanja distribuiranih procesa moe se podeliti i prouavati na dva nezavisna nivoa:

Politika rasporeivanja distribuiranih procesa, odreuje koj prenos e se kada izvriti i na kom raunaru. Obino strategija rasporeivanja distribuiranih procesa pokuava da distribuira optereenje sistema izmeu raunara distribuiranog sistema

Mehanizmi rasporeivanja distribuiranih procesa, obezbeuju olakice potrebne za izvoenje odreene strategije distribuiranja. Ovi mehanizmi se mogu obino nai na nivou operativnog sistema.

6.1 Politika Rasporeivanja Distribuiranih Procesa

Politika rasporeivanja distribuiranih procesa je odgovorna za dodelu procesora procesima. Za ovo je nepohodno da se odgovori na sledea pitanja:

1. Kada se proces izvrava i na kom procesoru?

2. Kada e proces biti startovan za izvravanje?

3. kada i gde e proces prei sa teko optereenog raunara?

Na osnovu vremena dobijenih iz odgovora na postavljena pitanja, politike rasporeivaanja distribuiranih procesa mogu se podeliti na sledei nain:

STRATEGIJE STATINOG RASPOREIVANJA sve odluke rasporeivanja se donose pre startovanja procesa za izvravanje. Nakon to je proces startovan nije dozvoljeno prelaenje na idealan ili manje optereen raunar.

STRATEGIJE DINAMIKOG RASPOREIVANJA odluke rasporeivanja se na donose samo pre startovanja procesa ve i u toku njegovog izvravanja.. Ova grupa strategija podstie, na primer pojednostavljuje prelazak procesa radi izjednaavanja optereenja sistema.

6.2.1 Strategije statinog rasporeivanja distribuiranih procesa

U sluaju statinog rasporeivanja distribuiranih procesa, sve odluke se donose pre startovanja procesa za izvravanje. Kako bi se rasporeivanje izvrilo pravilno,na bilo koji od naina, rasporeiva mora da poseduje dobro znanje ablona komunikacije i prorauna procesa, komunikaciona kanjenja, mrenih i proraunskih mogunosti raunara ukljuenih u distribuirano okruenje prorauna.

Informacije o komunikacionom i proraunskom ponaanju moe se nai putem programskog jezika raunara. Informacije o komunikacionim i proraunskim trokovima mogu se dobiti merenjem.

Statino rasporeivanje procesa se ne brine o prelascima procesa niti zasniva svoje odluke na trnutnom optereenju raunara. Tako u situaciji kada su neki raunari idealni ili manje optereeni, mogu se pojaviti drugi teko optereeni.

Poto rasporeiva ne mora da odrava stanje trenutnog rasporeivanja optereenja, on moe biti vrlo jednostavan i efektivan. Sdruge strane, rasporeiva je centralizovani deo distribuiranog sistema.

Prednosti Modela Procesa

Vanost veza izmeu procesa moe se opisati sa Direct Acylic Graph (DAG) u kome punktovi predstavljaju procese sa poznatim remenom izvravanja, a granice predstavljaju vanost veza izmeu procesa. Granice se oznaavaju sa teinom preneenih poruka izmeu postupaka u okviru granica roditelja.

Distribuirano raunarsko okruenje moe se prilagoditi pomou neusmerenog grafa. Ovde punktovi predstavljaju raunare a granice predstavljaju komunikacione kanale meu raunarima. Svaka granica je oznaena sa komunikacionim kanjenjem.

Rasporeiva trai raspored procesa po procesorima tako da ukupno vreme izvravanja bude minimalno. Komunikacija meu procesima na istom procesoru nije od velike vanosti.

Poto je problem iznalaenja optimalnog dodeljivanja procesora procesima NP zavren, ponueno je nekoliko heuristikih algoritama:

RASPOREIVANJE LISTE procesi se dodeljuju procesorima im je to mogue. Prekomernekomunikacije se ne uzimaju u obzir

RASPOREIVANJE ROIRENE LISTE procesi se prvo rasporeuju korienjem algoritma za rasporeivanje a kasnije se komunikacija uzima u obzir.

PRVI NAJRANIJI PROCES najraniji proces spreman za rasporeivanje se prvi rasporeuje.

Komunikacije Model Procesa

Ukolik nam nisu poznate prednosti veza meu procesima ili vreme zavretka procesa, vanost modela procesa nije pogodna za njihovo modeliranje. U ovom sluaju moemo koristiti model procesa komunikacije.

Model procesa komunikacije moe se predstaviti neusmerenim grafom, u kome punktovi predstavljaju procese a granice predstavljaju meuprocesnu komunikaciju.

Jaina procesa komunikacije je izraena sredstvima trokova komunikacije.

Svaki procesor definie funkciju trokova izvravanja procesa, koja rasporeuje svaki proces na osnovu trokova njihovog izvrvanja na tom procesoru.

Ciljrasporeivanja procesa je minimiziranje sume vremena izvravanja procesa i vremena komunikacije procesa. U tu svrhu, trokovi komunikacije meu procesima koji se izvravaju na istom raunaru se smatraju jednakim nuli. Ovaj problem je identian problemu iznalaenjaa maksimalnog protokola i minimalnog prekida na grafu.

6.2.2 Strategije dinamikog rasporeivanja procesa

Strategije statinog rasporeinanja procesa se ne mogu koristiti ako rasporeiva nema prethodnog iskustva o komunikaciskim i propaunskim ablonima procesa. U ovom sluaju, ipak, rasporeiva moe prikupiti informacije o trenutnom optereenju distribuiranja i rasporeivanja procesa na idealan ili najmanje optereen raunar.

Strategije dinamikog rasporeivanja mogu se podeliti na dve grupe:

DELENJE OPTEREENJA rasporeiva procesa tei da rasporedi proces na neoptereeni ili malo optereeni raunar. Nakon to je proces rasporeen, izvrava se na ovom procesoru dok se na zavri.

RASPOREIVANJE OPTEREENJA rasporeia procesa tei da rasporedi proces na neoptereen ili malo optereen raunar. Suprotno pristupu deljenja optereenja, ipak, kada se neki raunar postane idealan ili manje optereen nego raunar na kome se proces izvrava, rasporeiva moe prebaciti proces na taj raunar.

Dinamiko rasporeivanje procesa sastoji se od:

STRATEGIJE TRANSFERA, koja odreuje da li e se proces izvriti u lokalu ili na daljinskom kmpjuteru

STRATEGIJA IZBORA (SELEKCIJE), odreuje koji proces treba rasporediti

STRATEGIJA LOKACIJE, odreuje na kom raunaru bi proces trebalo izvriti.

Deljenje optereenja

U sluaju deljenja optereenja, optereenje se distribuira preko distribuiranih sistema rasporeivanjem procesa na neoptereen ili malo optereen raunar. Ovaj pristup, ipak, obezbeuje samo lokalno reenje rasporeivanja distribuiranih procesa, na primer, unapreuje samo izvoenje na lokalnoj maini. U prilog tome, ukupno optereenje se moe distribuirati nejednako.

Kako bi se raspodelio proces, neophodno je da rasporeiva zna informacije o trenutnom optereenju prenosa (distribucije). Generalno, mogua su dva pristupa:

SAMOSTALNI RASPOREIVA sve odluke o dodeljivanju procesara procesima donosi sam rasporeiva

VIE RASPOREIVAA procese kreirane na odreenom raunaru rasporeiva rasporeuje na tom raunaru. U ovom sluaju, vie rasporeivaa rasporeuje procese na procesore tako da se informacija o trenutnom optereenju distribuira preko sistema i rasporeiva je mora prikupljati periodino.

Rasporeivanje Optereenja

Glavni razlog rasporeivanja optereenja je izjednaavanje optereenja svih raunara u distribuiranom sistemu. Ovaj cilj se moe postii prebacivanjem procesa sa veoma optereenih raunara na neoptereene ili malo optereene raunare.

Na osnovu vremena kada rasporeiva inicira premetanje procesa, algoritmi rasporeivanja optereenja mogu se podeliti na sledee grupe:

ALGORITMI SA NAGLASKOM NA POILJAOCA prebacivanje procesa zapoinje kada duina rasporeivaevog reda prevazie odreeni prag. Rasporeiva tada bira malo optereen raunar (strategija lokacije) i proces koji e prei (strategija izbora). Ovaj algoritam se dobro primanjuje kod malo optereenih distribuiranih sistema.

ALGORITMI SA NAGLASKOM NA PRIMAOCA prebacivanje procesa zapoinje kada duina rasporeivaevog reda prevazie odreeni prag. Rasporeiva tada bira malo optereen raunar (strategija lokacije) sa kog e proces prei. Proces koji e prei na eljeni raunar se bira od strane rasporeivaa (strategija izbora). Ova shema se dobro primenjuje kod veoma optereenih distribuiranih okruenja.

Premetanje procesa mora bititransparentno sa prebaenim procesom i svim procesima sa kojima komunicira.

6.3 Mehanizmi Rasporeivanja Distribuiranih Procesa

Rasporeivau procesa trebaju jednostavni i moni mehanizmi ijim korienjem moe sprovesti strategije rasporeivanja. Dve takve mogunosti su:

daljinsko izvravanje i

prebacivanje procesa

Mogunost daljinskog izvravanja dozvoljava rasporeivau da zapone proces na daljinskom raunaru. Jednom kad se proces zapone, nije dozvoljeno premetanje na drugi raunar.

Vie upotena ali i skuplja mogunost je prebacivanje procesa. Ovo omoguava rasporeivau da ukine jedan od njegovih procesa i iznova zapone njegovo izvravanje na drugom, manje optereenom.

Oba mehanizma mogu biti implementirana na razliitim nivoima abstrakcije:

nivo operativnog sistema

LOCUS, CHARLOTTE

nivo programskog jezika

SR, PVM

nivo aplikacije

rexec

rlogin

6.3.1 Daljinsko izvravanje

Mogunost daljinskog izvravanja je neophodna za impementaciju strategija i dinamikog rasporeivanja distribuiranog procesa. To je alat koji rasporeiva moe koristiti da rasporedi proces da se izvrava na daljinskoj maini.

Daljinsko izvravanje se sprovodi kroz sledee korake:

rasporeiva bira raunar na kom e sproces biti izvren

rasporeiva se povezuje na daljinski izvrni server izabranog raunara i trai da izvri odabrani proces

daljinski izvrni server gradi okruenje za novi proces

rasporeiva alje potpuno proraunsko stanje procesa (program, poetne podatke, stack) na daljinski izvrni server

daljinski izvrni server inicijalizuje okruenje i zapoinje proces

rasporeiva unitava staro okruenje procesa

6.3.2 Prebacivanje procesa

Mogucnost premetanja procesa se koristi za implementaciju klase rasporeivanja optereenja strategije rasporeivanja. Dozvoljava rasporeivau da ukine proces izvravanja na lokalnom raunaru i da ga iznova zapone na daljinskom.

Kada se proces premesti na daljinski raunar, oba njegova stanja, komunikacijsko i propraunsko, moraju se premestiti. Proraunsko stanje se sastoji od programa, podataka, stack-a i vrednosti registara. Komunikacisko stanje sadri komunikacijske linkove, primljene poruke i poruke u prenosu.

Postoji nekoliko naina kako da se nosimo sa porukama primljenim nakom to je proces prebaen:

Prosleivanje poruka, kada raunar na kome se proces izvravao primi poruku za taj proces, on jednostavno prosleuje poruku novoj procesorskoj lokaciji.

Preventiva protiv gubljenja poruke, pre nego to se proces premesti, svi procesi sa kojima taj proces komunicira su obaveteni o novoj procesorskoj lokaciji. Povrratak izgubljene poruke, nakon to je proces premeten na novi raunar, ponovo uspostavlja sve komunikacione kanale i inicijalizuje protokol povratka izgubljene poruke.8. DISTRIBUIRANI FAJL SISTEMI

Fajl (Datoteka) sistem je kljuna komponenta svakog distribuiranog sistema. Uloga fajl sistema je da skladiti postojane imenovane objekte podataka zvane fajlovi, i da omoguci da budu dostupni kad je to potrebno. Fajl sistem je dakle odgovoran za kreiranje, brisanje, povraaj, izmene i zatitu fajlova.

Distribuirani fajl sistem (DFS) predstavlja implementaciju fajl sistema u disribuiranom sistemskom okruenju koje se sastoji od fiziki razdvojenih (distribuiranih u smislu lokacije) skladita podataka ali koji obezbeuje tradicionalnu preglednost fajl sistema za korisnike. Zato se mnogi vani koncepti u izradi distribuiranih sistema mogu demonstrirati implementacijom DFS-a:

1. distribuirani fajl sistemi primenjuju koncept transparentnosti

2. nacin adresiranja u DFS-u je primer ''opsluivanja imenoanja''

3. korienje keiranja i replikacije fajlova radi poveanja performansi i bolje dostupnosti faljova

4. Kontrola pristupa i zatita podataka u DFS-u predstavlja problem.

8.1 Aspekti DFS-a

Veliki broj korisnika i fajlova je kljuni aspekt fajl sistema, a distribuiranom okruenju je ovaj aspekt jo izraeniji. Novi aspekt DFS-a je disperzija krisnika i fajlova(Npr korisnik u DFS-u moe da pristupa svojim podacima koji se nalaze na HD-u nekog drugog raunara u mrei). Disperziju i mnotvo (korisnika i fajlova) bi trebalo sakriti od korisnika.

DISTRIBUIRANI KLIJENTI. DFS bi trebao da omogui transparentno logovnje tj. korisnik treba da vidi sistem jedinstveno nezavisno od servera ("HOST" raunar) uklljuujui i proceduru za logovanje i transparentan pristup. Mehanizam pristupa fajlu je jedinstven, bez obzira da li su fajlovi na lokalnom ili udaljenom serveru. DISTRIBUIRANI FAJLOVI. DFS bi trebalo da omogui trasparentnost lokacije, tj. imena fajlova ne treba da sadre informacije o njiovoj fizikoj lokaciji i nezavisnoj lokaciji, tj. fajlovi se mogu premetati sa jedne lokacije na drugu bez promene imena. VELIKI BROJ KORISNIKA. DFS bi trebao da omogui tansparentnu konkurentnost, tj. fajlu koji deli vie krisnika moe se pristupiti bez greke od strane bilo kog korisnika. VELIKI BROJ FAJLOVA. DFS bi trebaloda omogui transparentnost replikacije tj. auriranje replika se vri na atomskom nivou i korisnici nisu ni svesni postojanja vie od jedne kopije. Drugi aspekti ukljuuju otpornost na greke, skalabilnost, heterogenost DFS-a.8.2 Organizacija Fajl Sistema

Posmatrano funkcijski, fajl sistem se sastoji od etiri glavne komponente:

1. servis direktorijuma

2. servis autorizacije

3. servis fajlova

4. servisi sistema

SERVIS DIREKTORIJUMA. Glavna funkcija je mapiranje tekstualnih imena fajlova u adrese. Mapiranje je dosta nezavisno od trenutnih operacija nad fajlom. Zbog toga, uobiajeno je odvajanje servisa direktorijuma od servisa fajlova kako bi se podrala modularnost i portabilnst . Obino je opsluivanje fajlova na usluzi razliitim strukturama direktorijuma. Operacije nad direktorijumima ukljuuju pregled, dodavanje i brisanje sadraja direktorijuma.

SERVIS AUTORIZACIJE . Uloga servisa autorizacije je da obezbedi kontrolu pristupanja fajlu. U implementaciji, autorizacija se moe realizovati u sklopu servisa direktorijuma ili servisa fajlova. U prethodnom sluaju, komponenta za servis direktorijuma uva informacije o pristupima fajlovima i direktorijumima. Ako je korisnik autorizovan za pristup fajlu ili direktorijumu, njemu se omoguava obrada eljenog fajla , i odreene mogunosti, koje se definiu pravima korisnika pri korienju fajla. Kada se kasnije pristupa fajlu, prava pristupa se proveravaju preko fajl servera. Kasnije komponenta za servis direktorijuma obezbeuje samo obradu fajla. Klijent mora bit autorizovan od strane fajl sistema svaki put kad izvodi neku operaciju nad fajlom.

SERVIS FAJLOVA. Fajl sistemi koji podravaju transakcije dele fajl servise na transakcione i osnovne fajl servise. Transakcioni servisi sprovode upravljanje konkurentnom obradom i upravljanje replikacijama. Osnovni fajl servisi su ''read/write'' i ''get/set''. Servis fajlova takoe podrava kreiranje i brisanje fajlova. Servis fajlova je u interakciji sa sistemskim opsluivanjem kod poslova dodeljivanja i oslobaanja prostora bafera i fajla.

SERVISI SISTEMA. Funkcije koje obezbeuje sistem obuhvataju trenutne ''read/write'' operacije, mapiranje logikih u fiziki blok adresa, i upravljanje prostorom koji zauzima (memorijom) fajl. Upravljanje keom i odzivima je takoe usluga sistemskih servisa fajl sistema.

8.3 Fajl Serveri

Servisi se implementiraju procesima zvanim serveri. Servis moe biti implementiran od strane samo jednog servera ili veeg broja kooperativnih servera. Server moe obezbediti mnotvo usluga. Velik fajl sistemi su sastavljeni od razliitih fajl servera.

Montiranje fajlova (maunting) je koristan koncept za projektovanje velikih fajl sistema. Operacija montiranja od strane klijenta spaja udaljeni imenovani fajl sistem za klijentovu hierarhiju fajl sistema u trenutku identifikacije preko imenovane putanje. Taka (mesto) montiranja je obino prazan poddirektorijum. Specificiranje fajl sistema koji e se mauntovati se vri prema konvenciji imenovanja udaljenog fajl sistema. Na ovaj nain se ostvaruje transparentnost lokacije. Korienjem mehanizma montiranja razliiti klijenti mogu dobiti razliite poglede fajl sistema.

Fajl server moe zabraniti montiranje celog ili dela njegovog fajl sistema predefinisan skupom servera (host raunari) zbog bezbednosnih razloga.

Montiranje fajl sistema moe se sprovesti na tri naina:

EKSPLICITNO MONTIRANJE. Klijenti zahtevaju operaciju mauntovanja eksplicitno kad im ustreba. "Pogled" fajl sistema je definisan od strane korisnika. BOOT MONTIRANJE. Propisani skup se mauntuje u vreme "boot-ovanja" korisnika. Klijenti imaju jedinstven statian pogled celog fajl sistema, ak i ako nekima od njih nee trebati svi propisani mauntovani serveri. AUTO MONTIRANJE. Server se bezuslovno mauntuje kada klijent po prvi put otvori fajl. Pogled fajl sistema je dinamian, kao kod eksplicitnog mauntovanja ali bez potrebe za pozivima eksplicitnog mauntovanja.Montiranje zahteva poznavanje lokacija fajl servera. Fajl server se moe locirati na dva naina:

Klijenti se konsultuju sa registracioni serverom tamo gde se serveri moraju registrovati za svoje usluge. Registracioni server dodeljuje, po nekom kriterijumu, najbolji server. Klijenti emituju zahteve za montiranjem a fajl serveri odgovore na te zahteve. Sada klijent moe da bira jedan od servera, koji su se javili, primenom neke strategije.8.3.1 Fajl Serveri Sa i Bez Informacija o Postojeem Stanju (Stateful and Stateless)

Klijentovi ''read/write'' zahtevi mogu biti jednopotezne operacije. Obino, klijent pokree takozvanu fajl sesiju putem operacije otvranja, nakon koje slede kasniji ''read-write'' zahtevi. U ovom sluaju postoji informacija o stanju za svaku fajl-sesiju. Na primer informacije o stanju mogu obhvatiti:

koji klijent je otvorio fajl fajl-deskriptore zbog identifikacije fajla u predstojeim operacijama pokazivae trenutne pozicije fajla za sledei sekvencijalni pristup montiranje informacija zbog daljinskog pristupa lock status zbog koordiniranja deljenja fajla jednokratni sesijski kljuevi zbog bezbedne komunikacije sadraj kea ili bafera radi poboljanja performansiJasno je da informacije o stanju fajl-sesije mogu biti podeljene izmeu klijenta i fajl servera.

Fajl server sa informacijama o stanju je onaj koji sadri neke bitne informacije o stanju fajla. Na primer; kada se fajl otvori, klijent prima fajl deskriptor za sledei pristup. Tabela mapiranja fail deskriptora za fajlove odrava se od strane servera. Slino tome, pokaziva pozicije fajla uva se za svakog klijenta tokom sekvencijalnog pristupa fajlu, osim u sluaju "nasleivanja".

''Stateless'' fajl server se zove tako zato to ne uva informacije o stanju. U ovom sluaju, svaki zahtev bi sadrao puno ime fajla i pokaziva pozicije fajla.

Informacije o stanju koje se nalaze u zahtevima stateless servera (bez informacija o stanju) poveavaju duinu poruke i moraju biti izvrene od strane servera svaki put kada se pristupi fajlu.

uvanje informacija u statefull serveru omoguava postizanje bolih performansi. Sa druge strane ako statefull file server "padne", informacija o stanju za svaku fajl-sesiju je zauvek izgubljena a oporavak, ako je uopte mogu, zavisi iskljuivo od klijenta. "Pad" stateless fajl servera je lako povratiti, a javlja se kao kanjenje odziva.

8.4 Semantika Deljenja Fajla

Deljenje fajla od strane vie klijenata pokree dva vana problema. Operacije pristupa mogu se prekopiti ako postoj vie kopija istog fajla. To omoguava simultani pristup deljenom podatku. Svaki vor(raunar u mrei) koji ima kopiju fajla moe imati razliito vienje podatka. Ovaj problem naziva se kontrola postojanosti (koherencije).

Viestruki pristupi od strane klijenata istom deljenom fajlu imaju formu povezanih jednostavnih read/write operacija, iluzija simultanosti moe se postii preplitanjem izvrenja ovih sekvenci. Primari razlog je postizanje postojanog stanja podatka nakon preplitanja u izvravanju sekvenci, na primer, rezultat je jednak nekom serijskom izvravanju ovih sekvenci bez preplitanja. Reenje pomenutog problema zavisi od semantike itanja i pisanja.

UNIX SEMANTIKA. Read operacija e vratiti ''poslednju'' upisanu vrednost. Ova semantika potie od sistema sa jednim procesorom, gde se podaci keiraju po fajl osnovama. U distribuiranim sistemima moe postojati mnotvo kea istog fajl podatka i problem konzistentnosti kea mora da se rei.

Unix semantika modelira poslove sa prostim read/write operacijama i pokuava da postigne globalni konzistentni pogled deljenog podatka i moe se posmatrati na dva naina, tako da se odnosi na semantiku transakcije i semantiku sesije.

SEMANTIKA TRANSAKCIJE: Jedinca pristupa fajlu ili grupi fajlova je nedeljiva sekvenca read i write operacija. Operacije transakcije su obuhvaene parom naredbi: poetak transakcije/kraj transakcije. Izvravanje transakcije se ne ometa od strane drugih konkurentnih transakcija. To znai da zahtev za izvravanje dve ili vie konkurentnih transakcija je isti kao da se izvravaju jedna za drugom(sekvencijalno). Jedino se odrava konzistentnost podataka, stalne izmene fajla se sprovode samo na kraju uspene transakcije.

SEMANTIKA SESIJE: Izmene na otvorenom fajlu su fiziki vidljive samo lokalnom klijentu. Samo kada je fajl zatvoren izmenjeni fajl se kopira na fajl server i promena je trajno izvrena. Tako da je sesija obuhvaena parom naredbi: ''open/close'' i deljenje fajla postoji samo izmeu uspenih sesija.

8.5 Keiranje

Keiranje od strane korisnika klijent-server sistema eliminie prenos kroz mreu kada klijent pristupi fajlu. Na ovaj nain se moe postii prednost u izvravanju ali keiranje klijenta unosi nekonzistentnost u sistem. Ako klijent lokalno vri izmene keiranog fajla i ubrzo zatim drugi kljient proita fajl sa servera, drugi klijent dobija zastareo fajl.

''WRITE-TROUGH'' STRATEGIJA pokuava da rei problem nekonzistentnosti trenutnim slanjem ''write'' naredbi fajl serveru. Shodno tome, kada drugi klijent ita fajl sa fajl servera, dobija novu vrednost. Ipak promene se nee videti od strane drugih procesa koji imaju isti fajl u svom keu.

''WRITE-INVALIDATE'' ili ''WRITE-UPDATE'' protokoli se mogu koristiti za reenje ovog problema. Ponitavanje keeva od strane fajl servera obavetava sve klijente da su njihovi keevi "zastareli" i da se moraju ponovo uitati za predstojee korienje.

''Write-trough'' i ''write-invalidate'' simuliraju Unix semantiku.

Jasno je da sa ''write-trough'' keom prenos mreom je eliminisan samo za itanje. Kako bi se snizio promet write naredbi kroz mreu promene se mogu prikupiti na strani klijenta i da se periodino alje write naredba. Ova strategija kontrole se naziva ''WRITE-BACK'' i nije podrana od strane Unix semantike.

Dalja olakanja u radu sa keiranjem trae usvajanje semantike sesije. Izmenjeni fajl se aurira(slanjem "write" naredbe) posle zatvaranja. Ova strategija se zove ''WRITE-ON-CLOSE''.

8.6 Replikacija Fajla

U distribuiranim fajl sistemima se esto vri replikacija fajlova. To znai da postoji vie kopija fajla i svaka kopija se odrava na odvojenim serverima.

Glavni razlozi za ovo su:

poveanje sigurnosti (pouzdanosti) sa viestrukim ''backup''-ima dozvoljavanje pristupa fajlu ako fajl server "padne" rasporeivanje optereenja putem vie serveraJasno se vidi da replikacijom fajla puzdanost, pristupanost i performanse sistema mogu da se poboljaju.

Kada se vre izmene na replikovanom fajlu, izmene se moraju poslati svim kopijama. Ako proces ovo radi sekvencijalno i "srui se" nakon to je zapoeo slanje poruka o izmenama, a pre nego to uspe da poalje poslednju, neke operacije itanja u budunosti mogu dobiti novu vrednost a druge mogu dobiti staru vrednost fajla. ''Update'' protokol reava ovaj problem.

8.6.1 Update Protokoli

Replikacija osnovne kopjie. Jedan server je dizajniran kao primarni, svi ostali su sekundarni. Izmena replikovanog fajla se alje primarnom serveru, koji vri izmene lokalno na fajlu i zatim alje poruke o izmenama sekundarnim serverima. Operacije itanja mogu se izvoditi na bilo kojoj kopiji primarnoj ili sekundarnoj. Kako bi se izbegla situacija da se ne update-uju sve sekundarne kopije, a prmarna kopija se "srui" prvo se upisuju izmene u trajno skladite fajla, a posle se vri promena primarne kopije. Nakon oporavka od "pada" sa primarnih se moe zavriti slanje zahteva za izmenu sekundarnim. Ipak, ako je primarni iskljuen, ne mogu se izvriti izmene.

"Quorum" glasanje. Klijenti moraju zahtevati i odravati dozvole mnogih servera bilo pre itanja ili pisanja u odazvani fajl. Pretpostavimo da se fajl replikuje na N servera. Pisanje u replikovani fajl, zahteva od klijenta da sakupi "quorum" za pisanje Nw, koji je ogranien na 2*Nw N. Kad se sakupi Nw servera koji su se sloili, u fajl se upisuje i nova verzija je povezana sa fajlom. Broj verzije je isti za sve novoizmenjene kopije. Kako bi se itao replikovani fajl, klijent mora da prikupi kvorum za itanje (read quorum) Nr, koji je ogranien na Nr+Nw N. Poto su oba kvoruma isprepletana meusobno, bilo koji sakupljeni kvorum itanja e morati da sadri veinu izmenjene kopije. Jasno je, da je metod kvorum glasanja robusniji ako se uporedi sa replikacijom osnovne kopije.

9. DISTIBUIRANA DELJENA MEMORIJA

9.1 Motivacija i Principi

Posledica okruenja distribuirnih sistema gde su, meusobno povezani raunari, fiziki odvojeni je korienje paradigme slanja poruka za meuprocesnu komunikaciju. Ova paradigma je podrana od strane hardvera komunikacijske mree u pravom smislu. Meusobno povezani raunar mogu veoma lako da formiraju multiraunar sa hiljadama procesora. Dizajniranje multiprocesorske maine procesora slinih karakteristika koji koriste istu memoriju je teak posao.

Mnoge tehnike korienja maina sa deljenom memorijom za sinhronizaciju procesa i meuprocesnu komunikaciju su poznate kao multiprocesorsko programiranje. U sluaju multiprocesora, odsustvo deljne memorije zahteva korienje tehnika razliitih od onih u upotrebi kod maina sa deljenom memorijom. Generalno gledano, paradigma prenosa poruke se mora koristiti. Prenos poruke nosi sa sobom mnoga komplikovana pitanja ukljuujui kontrolu toka, gubitak poruka, baferovanje i takozvani ''blocking''.

Korienje RPC-a(Remote procedure call) prikriva neke od ovih potekoa skrivajui time i trenutnu komunikaciju od programera u bibliotekim procedurama. Tako, RPC (Remote Procedure Calls) obezbeuje transparentnost komunikacije. Postoje ogranienja pri korienju RPC-a, na primer velika struktura podataka koja sadri pokazivae ne moe se preneti RPC-om bez znaajnog truda.

Komunikacija se prirodno ogleda u oblicima razmene informacija izmeu nepovezanih adresnih prostora. Postoji oigledna potreba direktnog deljenja informacija u okruenju distribuiranog sistema, tj. omoguiti procesoru da pristupi memoriji udaljenog raunara. Distribuirana deljena memorija (DSM) simulira logiki prostor deljene memorije preko fiziki odvojenih maina. Time se postie direktno deljenje informacija. To ima za posledicu da paradigma programiranja deljene memorije moe da se koristiti u okruenju distribuiranog sistema. Kada se pristupa memoriji udaljenog raunara, stvarna komunikacija je transpatentna od strane aplikacionog sloja na vrhu komunikacije prenosa poruke.

9.2 DSM Arhitektura

U istraivanju multiprocesorskih sistema, alternativni dizajn je distribuiranje pojedinanog logiki deljnog prostora tako da procesori mogu pristupiti memoriji udaljene maine bez keiranja. U tom sluaju pristup udaljenoj memoriji je mnogo sporiji nego pristup lokalnoj memoriji i ova injenica nije skrivena korienjem hardverskog keiranja. Multiprocesorska arhitektura sa ovakvim tipom memorije se pretstavlja se kao maina sa neuniformnim pristupom memoriji (NUMA).

DSM sistem je NUMA sistem deljene memorije. Postoje neke razlike izmeu NUMA multiprocesora i DSM sistema. Neki od njih jasno lee u hardverskim komponentama, na primer vremena pristupa ili nain na koji podravaju broadcast komunikaciju.

Svarna razlika je da se na NUMA multiprocesorima udaljenim podacima pristupa preko adresa dok je na DSM sistemima softverska podrka uvek neophodna.

Za dalju diskusiju moramo poznavati osnovne organizacije jedinica memorije.

Kad blok sa eljenim podacima nije u lokalnoj memoriji, moe se daljinski pristupiti bloku ili se blok premeta u lokalnu memoriju za budue pristupe. Premetanje bloka moe znaiti da je blok stvarno premeten ili samo iskopiran (premetanje bloka i replikacija bloka).

Premetanje bloka postje neophodno kada uestalost daljinskog pristupa pree neki prag.Postojee strategije premetanja su ''pull-based'', tj. procesor povlai blok iz udaljene memorije kada je potreban ili po zahtevu. Alternativno procesor moe gurnuti blok drugom procesoru u nadi da e prosleeni blok biti potreban drugom procesoru veoma brzo. Usled premetanja bloka moe doi do takozvanog "pucanja" bloka. Moe se dogoditi da se permeteni blok odmah zahteva od strane drugog procesora, moda i prethodnog, tako da neprekidno prelazi sa jednog procesora na drugi. Replikacija bloka reava ovaj problem. ta vie, replikacija bloka podrava konkurentni pristup istim podacima. Ali replikacija bloka poveava potrebu korienja skupe kontrole memorykoherencije.

Fizika organizacija memorije u okviru bloka ne utie na logiku organizaciju podatka. Ova injenica moe pokrenuti problem tzv. pogrenog deljenja. Blok je premeten ili iskopiran ak i ako se samo mali deo podataka u okviru bloka zahteva od strane nekog procesora. Ako je podatak iz drugog dela bloka potreban drugom procesoru, DSM tretira blok kao deljeni blok i ako se ustvari podaci ne dele.

9.2.1 Vrste DSM Sistema

Moemo razlikovati 3 vrste DMS-a:

page-based DSM (zasnovani na stranicama)

shared-variable DSM (deljena promenjljiva)

object-based DSM (zasnovani na objektima)

PAGE-BASED DSM. Mehanizam koji se koristi je slian klasinom sistemu stranine organizacije memorije. Udaljeni procesor preuzima ulogu povratnog skladitenja. Pokuaj da se referencira stranica na udaljenoj maini prouzrokuje prekid za operativni sistem. Operativni sistem tada zahteva stranu tako to alje poruku udaljenoj maini, koja pronalazi traenu stranu i alje je nazad.

SHARED-VARIABLE DSM. Samo se odabrana veliina adresnog prostora deli. Da bi se odredila deljena promenjljiva ptrebna je informacija od strane korisnika.

OBJECT-BASED DSM. Korienje objektne tehnologije prouzrokuje da programi ne mogu samo prosto da pristupe deljenom podatku, ve moraju da potiju metode zatite. Kao posledica, sistem izvravanja (runtime system) moe preuzeti kontrolu za svaki pristup pomaui tako ouvanje konzistentnosti deljenog podatka.

''Shared-variable'' DSM i ''object-based'' DSM nemaju problema sa pogrenim deljenjem.

9.3 Modeli Postojanosti Memorije

Problem koherencije u kontekstu vieadresnih (multicast) i distribuiranih fajl sistema se tie ugla iz kojeg posmatramo podatke. Deljeni podaci su eksterni za proces. U DSM sistemima procesi ostaju sami u deljenoj memoriji. N