of 46/46

Dizajn distribuiranih operativnih sistema - goranrakic.comgoranrakic.com/maturski/maturski.pdf · mašinom koje će obezbediti precizniji i uniformniji rad. Zaposlio je ćerku engleskog

  • View
    222

  • Download
    1

Embed Size (px)

Text of Dizajn distribuiranih operativnih sistema - goranrakic.comgoranrakic.com/maturski/maturski.pdf ·...

  • Dizajn distribuiranih operativnih sistema

    2

    Sadraj

    Sadraj 2

    Uvodni tekst 3

    S E K C I J A 1

    Pojam operativnog sistema 5

    Istorijski razvoj i klasifikacija 6

    Pokretanje operativnog sistema 8

    Logike komponente sistema 10

    Organizacija memorije 10

    Organizacija procesa 11

    Organizacija resura 12

    S E K C I J A 2

    Principi distribuiranih sistema 15

    Web kao najvei distribuirani sistem 17

    Distribuirani sistemi objekata 18

    Primeri distribuiranih sistema 19

    S E K C I J A 3

    Definicija distribuiranog operativnog sistema 22

    Komponente DOS-a 23

    Model deljanja memorije 23

    Model deljenja resursa 24

    Model deljenja procesorskog vremena 26

    Komunikacija 26

    Sinhronizacija vremena 30

    Kontrola greaka 31

    Distribuirani sistemi datoteka 33

    Primeri distribuiranih sistema datoteka 37

    CODA sistem datoteka 37

    Lustre sistem datoteka 38

    Sigurnost i viekorisniki rad 40

    Dizajn Amoeba sistema 41

    Dalji razvoj 44

    Popis koriene literature 45

  • Dizajn distribuiranih operativnih sistema

    3

    1. Uvodni tekst

    Operativni sistemi i generalno sistemski softver su jedno od retkih, moda i jedino polje softvera gde su inovacije i korenski nove ideje vrlo retke. Prvenstveno zbog konzervativnosti u prihvatanju novih ideja od strane programera i korisnika, evolucija sistemskog softvera drastino kasni u odnosu na razvoj hardverskih komponenti raunarskog sistema. Iako smo svi svedoci poveanja snage sistema, pristup resursima raunarskog sistema, komunikacija sa njima, kontrolisanje organizacije memorije i procesa i ostalo to spada u polje poslova koje obavlja operativni sistem su sa manjim izmenama isti kao i pre 20 godina.

    Znaajni napredak postoji jedino u grafikom interfejsu operativnog sistema, to je bilo uslovljeno eljama trita u prvenstveno komercijalnom razvoju poznatijih operativnih sistema. Meutim, negativna posledica trinog razvoja operativnih sistema jeste esto evolutivno nazadovanje kroz istoriju razvoja ovog dela softvera.

    Pojavom elje za monim viekorisnikim sistemima sa neblokirajuom organizacijom procesa zapoeo je i razvoj distribuiranih operativnih sistema kao sistema koji rade na homogenim i heterogenim klaster reenjima i obezbeuju korisnicima transparentnost pri korienju, odnosno skrivaju samu prirodu sistema, mrenu komunikaciju, pojavu greaka na razliitim nivoima u razliitim podsistemima itd. Kako je izrada raunarskig sistema velike procesorsko-memorijske moi kroz klaster reenja jeftino i otvoreno za nova proirenja, distribuirani sistemi se nameu kao optimalno reenje za razliite kritine operacije. Ovakvi sistemi najee imaju veliki broj korisnika, dinamiki broj i vrstu resursa, a same komponente sistema se mogu nalaziti na geografski razliitim lokacijama.

    U ovom radu e se prvo govoriti o samim operativnim sistemima namenjenim jednoprocesorskim raunarskim sistemima, karakteristinim delovima i operacijama. Zatim e se uvesti pojam distribuiranog sistema uz definicije slojeva distribuiranog sistema, karakteristika, i ciljeva i zadataka. Bie pomenuti i najvei danas prisutni distribuirani sistemi poput Web-a kao najveeg distribuiranog sistema. Sledea celina se bavi distribuiranim operativnim sistemima, i pokriva razliite sekcije i probleme u realizaciji ovakvih sistema.

    Kao ponuena reenja posebnih problema e se eventualno pojaviti i nove, do sada neviene ideje u trenutno prisutnim distribuiranim operativnim sistemima. Posebna panja e biti obraena na neke nove tek najavljene tehnologije prvenstveno u realizaciji ureenog sistema datoteka nad klaster reenjem sa distribucijom i sinhronizacijom i samog sistema datoteka po jedinicama klastera u cilju ubrzavanja pristupa, organizacije i pretraivanja razliitih tipova podataka.

  • 4

    SEKC I J A 1

    OPERATIVNI SISTEMI

    Operativni sistem nam olakava komunikaciju i pristup resursima koje raunarski sistem poseduje i, ureuje i organizuje njihovo korienje. Spada u grupu osnovnog sistemskog softvera i nemogue je zamisliti funkcionalan raunarski sistem koji ne poseduje neku implementaciju operativnog sistema.

  • Dizajn distribuiranih operativnih sistema

    5

    2. Pojam operativnog sistema

    Operativni sistem predstavlja osnovni sistemski softver i prisutan je od samog nastanka raunarskih sistema. Mnogi pojavu operativnih sistema vezuju za pojavu programiranja, jer je neophodno postojanje sistemskog softvera kako bi nastao aplikativni softver, odnosno kako bi sam raunarski sklop imao ikakvu funkciju.

    Kada je engleski matematiar Charles Babagge (1792-1871) pokuao da napravi mehaniku analitiku mainu, shvatio je da mu je za ispravno funkcionisanje ureaja neophodno sredstvo za lake sporazumevanje sa mainom koje e obezbediti precizniji i uniformniji rad. Zaposlio je erku engleskog pesnika Bajrona, Ada-u Lovelace1 koja je time postala prvi programer i ujedno i autor prvog operativnog sistema. Iako maina nikada nije proradila zbog mehanike nepreciznosti na osnovu poetnog motiva za razvoj prvog operativnog sistema moemo operativni sistem definisati kao:

    Operativni sistem predstavlja osnovni sistemski softver koji skriva detalje o hardveru raunarskog sistema, olakavajui rad korisnicima sa ciljem da obezbedi lepe i prijatnije okruenje.

    Ovaj pristup definiciji se oznaava kao princip ulepavanja. Princip ulepavanja ne treba shvatiti bukvalno jer nije jedini cilj olakati pristup resursima ve je cilj i obezbediti unificiran pristup resursima na razliitim raunarskim sistemima. Takoe, pod principom ulepavanja se podrazumeva i obezbeivanje sigurnosti korienja, jer se kroz apstrakciju pristupa resursima zabranjuju nedozvoljenje operacije nad pojedinim resursima.

    Operativni sistem ima cilj da organizuje pristup resursima raunarskog sistema. Da prati zauzimanja i oslobaanja resursa od strane izvravanih procesa, odrava liste slobodnih resursa, doputa ili zabranjuje korienje resursa itd. Pojavom modernih raunarskih sistema (pedesetih godina dvadesetog veka) operativni sistemi prvenstveno slue za organizaciju resursa to je postao prekomplikovani posao za operatore, odnosno posao bi kotao previe vremena na skupim mainframe raunarima i greke bi bile este. Tako definiemo princip resursa:

    Operativni sistem je sistemski softver iji je osnovni cilj da organizuje resurse raunarskog sistema i ureuje njihovo dodeljivanje procesima, odnosno obezbeuje njihovo oslobaanje.

    1 U ast Ada-e Lovelace, prvog programera u logikom smislu, programski jezik Ada nosi ba to ime.

    Ilustracija 1 Hardverski i softverski slojevi raunarskog sistema

  • Dizajn distribuiranih operativnih sistema

    6

    Po obimu operativni sistem se takoe moe posmatrati dvojako. U komercijalno-trinom pristupu pod operativnim sistemom se ne podrazumeva samo kernel operativnog sistema, ve i raznovrsni programi koji obezbeuju funkcionalan sistem, pa se ak podrazumeva i grafiki interfejs (grafika koljka) sistema. Meutim, u ovom radu se pod operativnim sistemom podrazumeva samo jezgro (kernel) operativnog sistema, bez, za objanjenje osnova funkcionisanja sistema, suvinih detalja poput korisnikog interfejsa i moda neophodnih aplikativnih programa. Naravno, u produkcionom operativnom sistemu takvi delovi ne mogu da se izostave, ali izrada produkcionog operativnog sistema nije ni cilj ovog rada. Kod distribuiranih operativnih sistema, najee zbog neobinosti platfotme na kojoj se izvrava sam aplikativni softver ovakva, moda naizgled isuvie kruta i uska definicija onoga to operativni sistem obuhvata dobija svoj pravi smisao, iako je definicija potpuno u skladu i sa principom ulepavanja i sa principom resursa koji se mogu koristiti za utvrivanje pojma operativnog sistema.

    3. Istorijski razvoj i klasifikacija

    Kada se govori o operativnim sistemima bilo koje vrste nemogue je izbei barem skraeni pregled istorijskog razvoja sistemskog softvera. Uvidom u istorijski pregled razvoja se moe stei slika tendencija koje su se pojavljivale u razvoju i otkriti uzroci zato su odreeni koncepti u operativnim sistemima ba takvi kakvi jesu.

    U povoju informatike, razvoj operativnih sistema je bio tesno povezan sa razvojem hardvera. Ukoliko odredimo operativni sistem kao sistemski softver, dovoljno apstraktan, fleksibilan i zamenjiv drugim softverom, i tako odbacimo hardversko-logike operativne sisteme2 koji su bili integrisani u sam raunarski sistem, prvi operativni sistemi su se pojavili sa pojavom viih programskih jezika, koji su pojednostavili komunikaciju sa raunarskim sistemom.

    Sredinom pedesetih godina dvadesetog veka, prvi operativni sistemi su bili jednokorisniki sistemi koji su mogli da izvravaju iskljuivo jedan proces u jednom trenutku. To je stvaralo velike gubitke vremena jer se program unosio, prevodio i izvravao bez mogunosti da se neki drugi program za to vreme prevodi ili izvrava. To su bili IBM-ovi sistemi FMS i IBSYS, napisani u FORTRAN-u namenjeni IBM-ovom 7094 raunarskom sistemu. Mane sistema su reavane uvoenjem podele rada, tj. koristili su se jeftini sistemi (na primer IBM 1401) za unoenje programa i tampanje rezultata, i skupi sistemi za prevoenje i izvravanje programa. To je dovelo do postojanja dve potpuno nekompatibilne serije sistema.

    ezdesetih godina je IBM predstavio seriju sistema System/360 (sa operativnim sistemom OS/360), koje su bili softverski kompatibilne, tako da su programi za jedan sistem radili i na nekom snanijem i skupljem sistemu. Iako je OS/360 bio izuzetno glomazan sistem zbog elje da se pokriju svi sistemi kako oni najjeftiniji tako i oni najskuplji sa velikim brojem razliitih periferija, ono to je OS/360 prvi put predstavio jeste multiprogramiranje, odnosno mogunost da dok jedan proces radi sa periferijama (na primer tampaem), drugi proces koristi procesor. Kako bi se obezbedila separacija procesa u memoriji, radna memorija je bila podeljena i svaki proces se izvravao u svojoj memoriji. Ova, za dananje standarde, vrlo primitivna tehnika multiprogramiranja oznaena kao spooling3 je omoguila bolje iskorienje procesora, ali je brzo otklanjanje greaka i pravo izvravanje vie procesa istovremeno pomou organizacije procesa kakvu danas poznajemo jo uvek bilo relativno daleko. Sledea faza

    2 Ukoliko su postojali ulazno-izlazni ureaji raunarskog sistema, bez postojanja operativnog sistema logino se namee pitanje kako su ti ureaji bili kontrolisani. Tako dolazimo do privobitnih hardversko-logikih operativnih sistema koji su bili implementirani u samim ureajima i kontrolisali same ureaje. Stoga je ispravna tvrdnja da su operativni sistemi postojali od samog poetka razvoja raunarskih sistema.

    3 Simultaneous Periphereal Operation On Line istovremene operacije sa periferijama

  • Dizajn distribuiranih operativnih sistema

    7

    multiprogramiranja jeste deljenje vremena, gde bi kratki aktivni procesi jednako delili slobodno vreme4.

    U ovom trenutku treba pomenuti i Multics operativni sistem koji su napravili MIT, Bell Labs i General Electrics koji je imao ideju da omogui napredno deljenje vremena (time shareing) velikom broju korisnika. Nakon brojnih problema u realizaciji, kompanija Honeywell je otkupila sistem i dovrila njegov razvoj. Ideje prikazane u Multics operativnom sistemu su sluile kao osnov za prve distribuirane sisteme. Veliki sistemi su sluili kao serveri ije usluge su potraivali jeftini klijenti koji su bili laki za odravanje i korienje. Kao pouzdan sistem Multics je korien u velikim sistemima sve do sredine devedesetih godina dvadesetog veka.

    Programeri iz belovih laboratorija, nakon prekida rada na Multics sistemu (Ken Thompson i Dennis Ritchie) poinju da razvijaju svoju verziju multikorisnikog, multiprogramskog sistema pod imenom Unix. Uporedo oni razvijaju i vii programski jezik C, u kome se pie i Unix. Javljaju se razliite implementacije Unix operativnog sistema to dovodi do razbijanja kompatibilnosti. Kako bi se to spreilo dolazi do usvajanja POSIX standarda koji definie minimalan set sistemskih poziva koji jedan Unix operativni sistem mora da podri. Usvajaju se i standardi za C biblioteku, osnovni aplikativni softver Unix operativnog sistema,...

    U 1987. godini, pojavljuje se osiromaena verzija Unix-a pod imenom Minix. Bila je besplatno ustupana za edukacione potrebe. Finac, Linus Torvalds objavljuje otvoreni operativni sistem pod imenom Linux, kompatibilnim sa POSIX standardima izgraenim po ugledu na Minix. Zbog ideje razvoja putem otvorenog koda, Linux je dobio veliku popularnost. U trenutku pisanja ovog rada aktuelna je verzija 2.6 Linux kernela.

    Poseban podsticaj razvoju operativnih sistema daje pojava personalnih raunara. Iako znatno slabiji u odnosu na tada prisutne gigante (prvenstveno u I/O moi) zbog svoje cene su obezbedili snaan prodor na trite. Nakon to je Intel izdao svoj 8080 procesor, trebao mu je operativni sistem. Gary Kidall je napisao CP/M operativni sistem. Istovremeno, IBM konstruie PC raunarski sistem sa eljom da otkupi prava na CP/M sistem, to im nije polo za rukom. Koincidencijom sluaja, IBM angauje Bil Gates-a koji je otkupio DOS (Disk Operating System), proizvod lokalne kompanije iz Sijetla da uradi modifikacije u tom operativnom sistemu. On osniva kompaniju Microsoft i izdaje MS-DOS. To je bio jednokorisniki sistem bez podrke za multiprogramiranje, mnogo loiji od ranije pomenutih sistema, ali zbog svoje cene i cene samih PC raunara, vrlo brzo osvaja trite.

    Komercijalni razvoj uzima maha, pa se sredstva i inventivnost troe na pridobijanje trita. Nastaju grafiki sistemi Xerox PARC, AppleOS i na kraju Microsoft Windows, dok stari sistemi dobijaju podrku za grafiki interfejs X Window System na Unix sistemima.

    Takoe, u ovom periodu se intezivno razvijaju real-time operativni sistemi namenjeni za rad u embded sistemima kao to su medicinski ureaji, kuni aparati, mobilni telefoni. Specifinost ovih sistema umnogome odreuju nain razvoja operativnih sistema, koji poseduju tano utvreno tajmiranje, bez ikakve varijabilnosti u vremenu izvravanja neke operacije.

    Za nas interesantniji period poinje polovinom osamdesetih kada se javljaju prvi distribuirani operativni sistemi. Razvoj se ipak nije glatko odvijao. Razni mreni operativni sistemi nisu podravali transparentnost distribuiranog sistema, ve je svaki sistem imao svoj lokalni OS, dok je deljenje datoteka bilo mogue kroz operativni sistem. Kao i pre pojave mutliprogramiranja, uvia se da je veliko vreme na brojnim jeftinim PC sistemima neiskorieno. Sa razvojem brzih mrea, pojavljuju se prvi distribuirani operativni sistemi koji zbog svoje izuzetne sloenosti i danas predstavljaju poslednju fazu razvoja operativnih sistema. Ideja distribuiranih operativnih sistema, odnosno distribuiranog programiranja jeste distribucija procesa na veliki broj nezavisnih raunarskih sistema (koji se povezuju mrenom

    4 Pod pojmom vremena se podrazumeva procesorsko vreme, odnosno vreme ekanja procesora da se neka I/O zahtevna operacija zavri.

  • Dizajn distribuiranih operativnih sistema

    8

    komunikacijom klasteri5) ime se poveava iskorienost svakog procesora u sistemu. Ono to predstavlja probleme u razvoju ovog tipa sistema jeste problem sinhronizacije procesa, podele procesa i nezavisnot procesa od periferija koje postoje na jednoj, a ne i na drugoj jedinici heterogenog klastera. Distribuirani sistem mora da obezbedi i transparentnost za samog korisnika, tj. da sakrije karakteristinosti klastera, da obezbedi kontrolu greaka mrene komunikacije, da uspeno funkcionie i uz latenciju komunikacije, itd. Parametri za rad rasporeda procesa u distribuiranim operativnim sistemima su najee nepravovremeni, nepotpuni ili netani, to samo poveava sloenost u odnosu na jednoprocesorski sistem.

    Vrlo sloeni zadaci distribuiranog operativnog sistema jo uvek nemaju pravog i jedinstvenog odgovora, tako da ovo polje i danas ostaje polje stalnih istraivanja i raanja novih ideja, moda i jedini takav prostor u razvoju sistemskog softvera to je upravo ono to ovu oblast programiranja ini nadasve interesantnom.

    Ukoliko dobro pogledamo istorijski pregled moemo da uvidimo da se kroz istorijski razvoj esto ilo korak unazad. Kada su se pojavili jeftiniji raunarski sistemi, njihovi prvobitni operativni sistemi su bili jednokorisniki, bez podrke za multiprogramiranje, napisani u asembleru, iako su tada na velikim sistemima ve postojali viekorisniki, multiprogramski sistemi. Isto se ponovilo i sa pojavom PC raunara kao i sa PDA sistemima.

    Mnogi programeri veruju da je standardizacija Unix sistema (POSIX standardi) unitila razvoj operativnog sistema. Standardizacija je jednostavno zabranila bilo kakva odstupanja od standarda koji su svi hteli da barem teorijski potuju. Ono to je rezultiralo takvom politkom razvoja je sa jedne strane velika kompatibilnost sistema, mogunost umreavanja razliitih arhitektura i sistema, ali sa druge strane je spreilo inovativnost, premetajui kreativnost sa sistemskog na aplikativni nivo.

    Zavisno od karakteristika operativnog sistema, operativne sisteme moemo karakterisati u sisteme sa podrkom za multiprogramiranje i one bez podrke. Dalje, moemo ih podeliti u jednokorisnike i viekorisnike i na kraju ih moemo podeliti u lokalne (klasine) i distribuirane operativne sisteme. Ovakva kategorizacija je dovoljno determinisana, a i dovoljno otvorena tako da u navedene kategorije moemo podeliti sve operativne sisteme.

    4. Pokretanje operativnog sistema

    Startovanje raunara predstavlja sloeni proces u kome hardver i softver naizmenino preuzimaju glavne uloge. Nakon ukljuivanja raunara, inicijalizuje se POST sekvenca (Power On Self Test) matine ploe koja proverava osnovne hardverske delove raunara. Po zavretku procedure, BIOS (Basic Input Output System) dobija punu kontrolu nad hardverom sa osnovnim ciljem pokretanja operativnog sistema. BIOS pretrauje memorijske ureaje kako bi uitao image veliine 512 bajta, odnosno veliine jednog sektora koji se oznaava kao bootsector. Redosled pretrage je najee korisniki definisan, a obino BIOS najpre pretrauje disketnu jedinicu, pa onda hard disk ureaje prisutne na sistemu. Po pronalasku validnog image-a, BIOS uitava kod u memoriju i izvrava ga.

    Kako je praktino nemogue napisati kernel operativnog sistema koji bi bio manji od

    512b, u bootsector-u se nalazi program (oznaen kao bootloader) koji po startovanju sa predefinisane fizike memorijske lokacije uitava kernel operativnog sistema koji onda nije ogranien veliinom sektora.

    5 Klasteri mogu biti homogeni i heterogeni. Homogeni klasteri u kojima su sve jedinice klastera jednake sa istim procesorima, resursima i periferijama, dok se jedinice klastera u heterogenim klasterima razlikuju.

  • Dizajn distribuiranih operativnih sistema

    9

    Bootloader mora biti manji od 512b, to uvodi brojna ogranienja. Najee se pie u asembleru kako bi se to vie dobilo na veliini. Takoe, kako bi BIOS prepoznao da se radi o validnom bootloader-u, zadnja dva bajta bootsector-a moraju biti oznaka 0x55 0xAA (pri tome treba voditi rauna o razlici izmeu Little Endian i Big Endian arhitektura jer na Intel x86 platformi koja je Little Endian 511 bajt je 0xAA, a 512 bajt 0x55). BIOS e bootloader uitati na fiziku memorijsku adresu 0x7C00 nakon ega bootloader treba sa zadate pozicije da uita kernel operativnog sistema i prepusti mu izvravanje.

    Ukoliko se kernel uitava sa hard diska,

    BIOS e prvo uitati MBR (Master Boot Record) koji se nalazi u prvom sektoru hard diska i sadri tabelu primarnih particija. MBR pretrauje pristustvo bootloader-a (koji zavrava sa specifinom oznakom i nije vei od 512 bajta) na particiji koja ima boot oznaku, pa onda i na ostalim primarnim particijama.

    Iako bootloader najee uitava kernel

    u memoriju, on mora prethodno da uradi dodatnu inicijalizaciju sistema, poput prebacivanja u 32-bitni nain rada procesora sa aktiviranjem protected mod mogunosti, ukljuivanje A20 linije (preko ipa za kontrolu tastature) i slino. Ukoliko bootloader podrava vie kernela, esto se moe dogoditi da bootloader postane preglomazan pa ga je potrebno podeliti u dva dela bootsector koji se nalazi u prvih 512 bajta memorijskog ureaja sa koga poinje uitavanje sistema i bootloader koji se nalazi na nekoj fiksnoj poziciji, koga poziva bootsector, a koji ulazi u 32-bitni nain rada i zatim pokree kernel sa druge lokacije na disku.

    Po uitavanju kernel e inicijalizovati

    delove, prebrojati memoriju, podsisteme za upravljanje memorijom, rasporeivanje procesa i mehanizam za ureivanje pristupa resursima, a zatim uitati ostale korisnike programe kako bi korisniku podesio radno okruenje.

    Listing 1 Primer bootloadera koji tampa karakter 'A' na ekranu

    01 ; kod je 16bitni jer nismo ukljucili 32bitni rezim 02 ; i bice ucitan na 0x7C00 03 [BITS 16] 04 [ORG 0x7C00] 05

    06 main: 07

    08 ; pozivamo BIOS funkciju da bismo prikazali tekst na ekranu 09 ; koja se nalazi na adresi 0x0E 10 mov ah,0x0E 11 mov bh,0x00 12

    13 ; postavljamo nacin ispisa teksta beli tekst na crnoj podlozi 14 mov bl,0x07 15

    16 ; stavljamo karakter koji ce se ispisati 17 ; ASCII vrednost velikog slova A 18 mov al,65

    Ilustracija 2 ematski prikaz startovanja operativnog sistema

  • Dizajn distribuiranih operativnih sistema

    10

    Listing 1 Primer bootloadera koji tampa karakter 'A' na ekranu

    19

    20 int 0x10 21

    22 ; ne radi vise nista 23 jmp $ 24

    25 ; dopuni do 510 bajta i zavrsi sa oznakom boot loadera 26 times 510-($-$$) db 0 27 dw 0xAA55

    5. Logike komponente sistema

    Glavne funkcije operativnog sistema jesu organizacija procesa i resursa. Iako su funkcije naizgled jednostavne, realizacija ovih operacija nije ni malo trivijalna, jer implementacija mora biti dovoljno efikasna, sigurna i proiriva. Od ostalih funkcija treba napomenuti implementaciju sigurne (u smislu pouzdanosti) komunikacije procesa i interfejsa pristupa hardveru koji je mogue koristiti iz procesa (API operativnog sistema). Ne smemo gubiti iz vida i organizaciju radne memorije sistema koja se zbog specifinog naina korienja od svih procesa pa i kernela ne moe poistovetiti sa ostalim sistemskim resursima.

    Proces predstavlja jednu nit izvravanja programa, odnosno program u celini ukoliko on ne koristi vie niti. Kako procesor moe izvravati samo jedan proces istovremeno6, on moe biti u fazi izvravanja ili u fazi ekanja na izvravanje. Poto je takvo izvravanje krajne neefikasno jer bi pojava procesa koji ima intenzivni rad sa I/O resursima potpuno zaustavilo neke procese koji bi se mnogo bre izvrili. Operativni sistem mora da definie efikasniji nain organizacije procesa od sistema ekanja u redu, pa moemo proces podeliti na najmanje deljive jedinice, oznaene kao atomske operacije ili atomski procesi koji se moraju izvriti istovremeno. Zatim emo selektivno svakom procesu dodeljivati procesorsko vreme, a potom se prebaciti na drugi proces. Ukoliko koliina procesorskog vremena bude isuvie mala dogodie se previe prebacivanja procesa to je operacija koja takoe ima vreme trajanja pa emo isuvie vremena izgubiti na prebacivanje umesto da ga posvetimo izvravanju procesa. Kako operatvni sistem treba da maksimum procesorskog vremena ostavi za izvravanje samih procesa (inae OS postaje beskoristan) algoritam za organizovanje procesa, izbora dela vremena, naina za odreivanje kritinih procesa, i slino postaje sloeniji.

    U ovom delu emo prikazati nain rada i funkcionisanja tri dela sistema organizaciju memorije, organizaciju procesa i organizaciju resursa.

    Organizacija memorije

    Kao to je ve objanjeno, po ukljuivanju raunara BIOS uitava boot loader sa predefinisane lokacije, koji uitava kernel operativnog sistema na unapred zadatu adresu u memoriji sistema. Jedan od prvih delova koju kernel poziva jeste deo za organizaciju memorije

    Kernel operativnog sistema (i njegov deo za organizaciju memorije) e po startovanju imati punu kontrolu nad fizikom radnom memorijom. Ovo nije samo RAM memorija, ve ovaj adresni opseg obuhvata i BIOS memoriju, tabelu prekida (interupt-a), videomemoriju, i RAM memoriju. Deo RAM memorije je u startu rezervisan, pa e BIOS, na primer, u 0x7C00 do 0x7DFF uitati bootsector memorijskog ureaja sa koga se obavlja startovanje sistema.

    6 Intelova tehnologija HyperThreading neke moe zavarati da procesor moe da izvrava dve operacije istovremeno. To meutim nije sluaj, jer se takav procesor ponaa kao dvoprocesorski sistem gde je emulacija drugog procesora uraena na nivou hardvera.

  • Dizajn distribuiranih operativnih sistema

    11

    Pored fizike postoji i virtualna memorija to je svojevrsna apstrakcija fizike memorije koja je sprovedena na hardverskom nivou (MMU deo procesora) i nivou kernela operativnog sistema omoguava korienje veeg adresnog opsega nego to prua fizika memorija, podrku za dodelu istog virtualnog adresnog opsega razliitim procesima i zatitu memorije od pristupa iz drugog procesa. Tako kernel moe imati podrku za izvravanje vie procesa istovremeno, podrku za swap memoriju i sl. Uz pomo MMU-a deo kernela za organizaciju memorije povezuje delove adresnog prostora virtualne memorije sa stvarnom fizikom memorijom.

    Funkcije koje memory management treba da obezbedi jesu alociranje (obezbeivanje memorije procesu koji ju je zatraio), dealociranje (oslobaanje alocirane memorije), i realociranje (poveanje ve alociranog bloka uz zadravanje sadraja prethodno alocirane memorije). Takoe, ne sme se zaboraviti ni pruanje usluge deljenja memorije izmeu vie procesa.

    Postoje dva osnovna principa organizacije memorije segmentacija i stranienje (paging). to se tie hardverske podrke, segmentacija je podrana samo na I32 arhitekturi pa to treba imati u vidu pri pisanju kenela. Operativni sistemi koji danas postoje primenjuju jedan ili drugi princip. Segmentacija obezbeuje laku zabranu pristupa delovima memorije iz neautorizovanih procesa, dok se kod stranienja to mora implementirati u memory management podsklopu.

    Stranienje se zasniva na podeli celokupnog adresnog prostora na blokove fiksne duine (4kb) sa kojima e se operisati kao sa kvantima memorije. Dalje, potrebno je obezbediti nain za obeleavanje slobodne memorije to se moe izvesti prisustvom zaglavlja svake stranice koja oznaava status stranice (globalna povezana lista gde svaki vor ukazuje na sledeu slobodnu stranicu) ili smetanjem adresa slobodnih stranica u globalni niz, to je najee loije reenje.

    Segmentacija pak podrazumeva podelu adresnog prostora na delove (segmente) koji imaju jasno oznaeno pravo pristupa koje ureuje MMU procesora. Unutar segmenta, procesi alociraju tano onoliko memorije koliko im je potrebno, ali je problem memory management-a kako da obezbedi tako alociranje pri kome moe da ouva dovoljno veliki kontinuirani blok memorije koji nekom porcesu moe zatrebati.

    Za potrebe distribuiranih sistema je stranienje bolje reenje jer ne postoji MMU nadlean za odreeni adresni prostor memorije, dok se stranice memorije mogu distribuirati transparentnije za same procese koji se izvravaju u na taj nain deljenoj memoriji.

    Organizacija procesa

    Druga bitna uloga kernela operativnog sistema jeste organizacija procesa, tj. dodeljivanje procesorskog vremena procesima kako bi se oni mogli izvravati. Sve procese moemo podeliti na aktivne (one koji se izvravaju moe biti jedan po procesoru), spremne (oni koji ekaju dodelu procesorskog vremena) i procese koji ekaju bilo zavretak rada sa nekim resursom ili na zavretak nekog drugog procesa i tek po ispunjenju uslova ekanja mogu postati spremni.

    Najjednostavniji nain organizovanja procesa jeste dodela procesorskog vremena prvom procesu, pa tek kada se on zavri uitati tabelu virtualne memorije sledeeg spremnog procesa i prei na njegovo izvravanje itd. Ovo je princip rada FCFS (First Come First Served) ili FIFO (First In First Out) algoritma i nije optimalni nain realizacije, jer se pojavljuje preveliko vreme

    Ilustracija 3 Struktura stranice memorije

  • Dizajn distribuiranih operativnih sistema

    12

    ekanja kratkih procesa koji dolaze iza dugih procesa u odnosu na samo trajanje izvravanja tih kratkih procesa.

    Jedan od kvalitetnijih algoritama ja Round Robin. Koji odreuje kvant procesorskog vremena koje dobijaju procesi iz grupe spremnih procesa. Za mali kvant vremena, procesi e se izvravati skoro simultano, ali e biti dosta izgubljenog vremena na prebacivanje procesa. Za veliki kvant vremena, Round Robin prelazi u FCFS algoritam jer e se proces izvriti pre nego to istekne dodeljeno vreme.

    Danas se najee koriste varijacije Multiple Feedback algoritma koji favorizuje krae procese. Svi procesi su osim podele na osnovu stanja podeljeni u kategorije. Procesi koji pripadaju kategoriji sa manjim rednim brojem imaju vei prioritet. Svaki novi proces koji prelazi u listu spremnih postaje proces prve kategorije dok je nulta rezervisana za sam kernel sistema. Za samo izvravanje se koristi Round Robin algoritam, stim to se kvant vremena ee dodeljuje procesima iz kategorije sa veim prioritetom. Nakon to procesor dobije odreeni broj kvantova vremena, prelazi u kategoriju sa manjim prioritetom. Na ovaj nain se krai procesi izvravaju bre, a algoritam prua mogunost za podeavanja i od strane korisnika odabirom kvanta vremena i razlike izmeu koliine vremena koje se dodeljuje kategorijama sa razliitim prioritetom, pa i samim brojem kategorija.

    Svaki od ovih algoritama se dalje moe nadograivati stvaranjem posebnih grupa procesa na osnovu okruenja procesa i sistema u kojima se procesi razliito organizuju upotrebom drugih algoritama, prilagoenih datoj grupi procesa.

    Organizacija resursa

    Trei neizostavni deo kernela operativnog sistema jeste menaer resursa koji vodi rauna koji resursi su dodeljeni pojedinim procesima i u zavisnosti od toga asistira u organizaciji procesa blokirajui pojedine procese. Posao ovog dela kernela je i da sprei upad u zamke kakva je prikazana na dijagramu na sledeoj stranici, koji bi bez postojanja menadera resursa potpuno blokirao rasporeivanje procesa.

    Reavanje ovog problema uopte nije trivijalno iako postoji vie manje ili vie uspenih metoda. Najjednostavnije je zabraniti upotrebu bilo kog resursa dok je ijedan resurs zauzet. Meutim ovo nije nimalo efikasno. Drugi pristup jeste obaveza svih procesa da prijave sve resurse koji im mogu zatrebati to nije efikasno sa programerske strane jer procesi esto ne znaju koji im resursi mogu trebati.

    Menader resursa mora biti sposoban da organizuje kako deljive resurse (TCP na primer) tako i one koji se ne mogu deliti (tampa). Stoga se namee kao logino reenje implementacija ovog dela kao modularnog sistema gde bi sam menader resursa bio korien za svaki pojedini resurs ili za tip nekog resursa. Svaki pojedini menader moe implemenirati sopstveni model obezbeivanja od zaglavljivanja, a dodatno kernel moe pruati uslugu prekida ekanja na resurs ukoliko ekanje pree kritinu granicu. Na ovaj nain, ukoliko na bilo kom nivou doe do zaglavljivanja procesa, kernel e proces obavestiti u greci pri dodeli resursa i prebaciti ga u grupu spremnih procesa kako bi mogao da nastavi izvravanje.

    Tako e na primer menader resursa za tampa implementirati spooler sistem gde e uvati podatke prispele za tampanje obezbeujui trenutni nastavak procesa koji je zatraio resurs, a kasnije gore opisanom metodom ekanja podatke preneti pravom resursu.

    Ovakav decentralizovani nain menadera resursa najee ima implementiran i sam upravljaki program za sam ureaj, a model je pogodan za implementaciju u distribuiranim operativnim sistemima. U modernim operativnim sistemima pod menaderom resursa se najee podrazumeva samo deo za interakciju razliitih menadera za pojedine resurse i implementaciju prekida usled dugog ekanja, dok se sami menaderi za pojedine resurse razvijaju kao korisniki aplikativni softver. Primer ovoga jesu sistemi za tampanje na Unix sistemima (cups), sistem za upravljanje zvukom na Linux sistemima (aRTSd, ESD) itd.

  • Dizajn distribuiranih operativnih sistema

    13

    Ilustracija 4 Scenario zaglavljivanja procesa usled nepostojanja kvalitetnog menadera resursa

  • 14

    SEKC I J A 2

    DISTRIBUIRANI SISTEMI

    Pojava jeftinih PC raunara male procesorsko-memorijske snage i brzih LAN i WAN mrea su omoguili pojavu distribuiranih sistema, odnosno udruivanje nezavisnih sistema koji se korisnicima prikazuju kao jedinstveni koherentni sistem sa velikom zbirnom procesorsko-memorijskom moi i niskom cenom

  • Dizajn distribuiranih operativnih sistema

    15

    6. Principi distribuiranih sistema

    Po definiciji, distribuirani sistem predstavlja kolekciju udruenih nezavisnih raunarskih sistema koji se korisnicima, i procesima koji se na njima odvijaju predstavljaju kao jedinstveni koherentni sistem.7

    Distribuirano programiranje predstavlja evolutivni nastavak modela razvoja softvera oznaenog kao mreno programiranje. Kao to i samo ime odreuje, distribuirano programiranje kao osnovu sadri ideju podele celokupnog sistema na vie ili manje nezavisne delove koji e se izvravati na nezavisnim kompjuterima u mrenom okruenju. Distribuirani sistem moe potovati centralizovan server-klijent model dizajniranja informacionog sistema ili biti izgraen od ravnopravnih vorova mree.

    Na ovaj nain izgraen sistem prua brojne prednosti kao to su laka proirivost, velika otpornost na greke usled padova pojedinih delova sistema i najee usled velikog broja vorova velika zbirna procesorska i memorijska mo.

    Postoji vie razliitih tipova distribuiranih sistema, a kategorizacija se vri na osnovu tipa objekata koji su distribuirani. Danas se esto pominju termini distribucije dokumenata, distribucije procedura, distribucije objekata i distribucije procesa (distribuirani operativni sistem).

    Da bi distribuirani sistem mogao da povee heterogene delove sistema i obezbedi unificirani pristup virtualnom jedinstvenom sistemu potrebno je da on implementira sloj koji e obezbediti distribuiranu komponentu koji se najee naziva middleware. Osnovni cilj ovog sloja jeste da ispuni povezivanje resursa bilo da su to dokumenti, deljene procedure ili objekti ili resursi poput tampaa, TCP/IP veze i slino.

    Ciljevi koji se obavezno moraju ostvariti programiranjem sistema u skladu sa distribuiranim modelom jesu: povezivanje resursa i korisnika, transparentnost, otvorenost i proirivost. Zapravo, distribuirani sistem treba da omogui lako povezivanje korisnika i resursa, da omogui transparentni pristup distribuiranim resursima kao da su oni dostupni lokalno, i da bude dovoljno otvoren i proiriv kako bi u potpunosti bio distribuiran.

    Prvi zadatak, povezivanje, predstavlja glavni cilj distribuiranog sistema. Resursi, zavisno od objekta distribucije u sistemu mogu biti bilo ta - tampa, slobodno procesorsko vreme, memorija, datoteke i dokumenti,... Povezivanjem se ostvaruju brojne prednosti od isto ekonomskih do organizacionih - lake saradnje vie korisnika putem namenskog softvera, najee oznaenog kao groupware. Sa omoguavanjem deljenja resursa, javlja se i problem sigurnosti pa u dananjim distribuiranim sistemima delovi koji reguliu sigurnost koriste ifrovane komunikacione kanale, viestuke verifikacije pristupa na osnovu lokacije potraivanja resursa, koriste korisnike polise za pristup resursima itd.

    7 Distribuirani sistemi principi i paradigme, Andrew Tanenbaum i Maarten van Steen, strana 2

    Ilustracija 5 pozicija middleware sloja

  • Dizajn distribuiranih operativnih sistema

    16

    Transparentnost je oigledno neophodna kako bi korisnik ili procesi koje je korisnik aktivirao mogli neometano da pristupaju resursima. Transparentnost najece obezbeuje middleware sloj distribuiranog sistema i moe se ostvariti kao transparentnost pri pristupu, transparentnost lokacije, migracije, relokacije, replikacije, konkurentskog pristupa, i transparentnost pri grekama.

    Transparentnost pristupa se zasniva na skrivanju naina pristupa resursima. Na primer, ukoliko postoji distribuirana procedura, proces bi joj morao pristupati na drugaiji nain, sa specijalno obraenim podacima za pristup nego da se ona nalazi lokalno. Upravo interfejs middleware-a reava taj problem.

    Transparentnost lokacije implementira takav pristup resursima da korisnik (ili proces) ne mora da zna tanu fiziku lokaciju na kom voru distriburianog sistema se resurs nalazi da bi ga koristio. Tipian primer ovakve transparentnosti jeste URL adresa dokumenta (distribuiranog resursa) na danas najveem distribuiranom sistemu - World Wide Web-u gde korisnik ili proces koji pristupa resursu ne mora da poznaje geografsku lokaciju servera gde je dokument sauvan. Ukoliko resurs moe da promeni lokaciju, a da se ne izmeni nain pozivanja resursa onda sistem podrava transparentnost migracije. Korak dalje predstavlja mogunost da resurs promeni fiziku lokaciju za vreme koricenja i tada se govori o transparentnosti relokacije.

    U distribuiranim sistemima se esto formira lokalna kopija resursa (ukoliko se radi o resursima koji se mogu lokalno kopirati kao to su dokumenti, memorijska lokacija, procedure, objekti itd) kako bi se poboljale performanse. Sam korisnik resursa (proces) ne treba da bude svestan postojanja kopije jer se onda gubi smisao postojanja iste, te ukoliko je ovo ispunjeno distribuirani sistem podrava i transparentnost replikacije. Prilikom pristupa resursima treba napomenuti i estu potrebu da vie procesa pristupa istim resursima ili da simultano pristupa razliitim kopijama istog resursa. Ukoliko je ova mogunost podrana, kaemo da postoji transparentnost konkurencije.

    Transparentnost pri grekama ili otpornost na greke je jako bitna za distribuirane sisteme jer se oni sastoje od velikog broja nezavisnih raunarskih sistema, njihov rad se odvija u mrenom okruenju, najee imaju veliki broj korisnika i procesa koji se izvravaju te lako moe doi do neplaniranih situacija. Jedan od popularnih aljivih odgovora na pitanje ta je distribuirani sistem lepo ocrtava problem otpornosti na greke u dananjim distribuiranim sistemima, a glasi Znate da imate jedan kada vas greka na kompjuteru za koji nikada niste uli spreava da obavite posao koji ste trebali da obavite. Veliki problem predstavlja samo okruenje distribuiranog sistema. Naime, jako je teko razlikovati resurs koji je prestao da funkcionie od resursa koji je preoptereen ili je komunikacija sa njim oteana usled sporog mrenog okruenja.

    Otvorenost distribuiranog sistema se postie definisanjem interfejsa pristupa distribuiranim elementima koji ne zavisi od broja vorova i strukture njihovog povezivanja. Pravila formiranog interfejsa za interakciju sa distribuiranim sistemom (deljenje lokalnih resursa i pristup udaljenim resursima) se specifiraju u protokolima koji se nalaze u sloju aplikativnog protokola OSI modela. (Jabber, RPC i sl.) Protokol definie nain komunikacije, procedure i funkcije koje su dostupne, listu parametara, povratne vrednosti itd. Potpuno otvoren distribuiran sistem poseduje portabilan i interoperatibilan protokol (interfejs) tako da se procesi pod istim protokolom mogu izvravati na razliitim distribuiranim sistemima, kao i da se na sistemu mogu izvravati razliiti procesi na isti nain.

    Proirivost se nadovezuje na otvorenost dodajui podrku za zamenu i proirivanje hardvera vorova distribuiranog sistema, menjanje broja vorova i dodavanje novih distribuiranih resursa bez potrebe za promenom interfejsa i procesa koji e se na sistemu odvijati. Takav distribuirani sistem koristi decentralizovani model poput Jabber IM sistema8 ili DNS (Domain Name Server) sistema. Po ovom modelu ni jedan vor ne poseduje kompletne

    8 Komunikacija procesa korienjem Jabber protokola, Goran Raki, Republika smotra mladih talenata, Kladovo 2003. godine

  • Dizajn distribuiranih operativnih sistema

    17

    podatke o stanju sistema, sistem se odvija na svakom voru samo na osnovu lokalno dostupnih informacija, pad jednog vora ne rui ceo sistem i na kraju, ali ne i manje bitno, ne postoji pretpostavka da je tajmiranje na svakom voru isto.

    Ilustracija 6 Prikaz otvorenog distribuiranog sistema na primeru DNS-a

    7. Web kao najvei distribuirani sistem

    Najvei, danas prisutan distribuirani sistem predstavlja World Wide Web (WWW ili skraeno samo Web), sistem koji je zasluan za veliku popularizaciju umreavanja i distribuiranih sistema uopte. Sama ideja Web-a je u predstavljanju svega kao dokument, te ovaj sistem pripada grupi sistema sa distribuiranim dokumentima. Web se danas sastoji od miliona klijenata i servera na kojima je deljeno vie milijardi dokumenata. Ideja se rodila na CERN-u u enevi kao nain za deljenje dokumenata i materijala izmeu geografski udaljenih istraivakih centara u svetu. Od 1994. godine razvojem Web-a, definisanjem standarda i protokola se bavi World Wide Web Consortium (W3C) osnovan od strane vodeih istraivakih instituta, CERN-a i MIT-a.

    Svaki dokument (resurs) na Web-u se moe locirati preko URL-a (Uniform Resource Locator). Nain adresiranja resursa preko URL-a podrava sve transparentnosti distribuiranih sistema - lokacije, relokacije, migracije i konkurencije. URL definie i tip protokola koji treba koristiti, pa kako su protokoli tano utvreni od strane W3C-a, postoji portabilnost i interoperabilnost samog sistema.

    Mana URL-a jeste to podrava Ilustracija 7 Uniform Resource Locator

  • Dizajn distribuiranih operativnih sistema

    18

    samo ASCII stranu karaktera. Meutim, karakteri iz drugih karakternih strana se mogu predstaviti enkodovani u ASCII entitete pomou UrlEncode algoritma.

    Sama razmena dokumenata (korienje resursa) izmeu klijenta i servera se aktivira pristizanjem zahteva za odreenim URL-om koji klijent upuuju na adresu servera. Server prihvata zahtev, nalazi dokument u memoriji i prosleuje ga klijentu koristei protokol iz URL-a. Naravno, neophodno je da i klijent i server podravaju dati protokol. Kako su protokoli koji se koriste na Web-u standardizovani kroz rad W3C organizacije, ovo ne predstavlja problem.

    8. Distribuirani sistemi objekata

    Iako jako rairen, Web kao sistem distribuiranih dokumenata ne predstavlja tehniki kompleksno reenje kao kada se radi o distribuciji procedura, objekata ili procesorsko-memorijske moi kao kod distribuiranih operativnih sistema. Kada se govori o primerima sistema koji distribuiraju objekte nemogue je ne pomenuti CORBA i Microsoft DCOM arhitekture kao modele pri izradi distribuiranih sistema. Objektni distribuirani sistemi svaki resurs tretiraju kao objekat, napram dokumenta kao osnovne paradigme kod Web-a.

    CORBA (Common Object Request Broker Architecture) je vie specifikacija

    distribuiranog sistema distribuiranih objekata nego sam sistem. Predstavlja industrijski standard iza koga stoji preko 800 razliitih konzorcijuma i industrijskih lidera. Prva CORBA specifikacija se pojavila poetkom devedesetih godina dvadesetog veka i od tada se primenjuje u velikom broju distribuiranih sistema bilo da su to projekti zajednike kolaboracije, deljenja informacija, distribuirane relacione baze podataka itd. CORBA se zasniva na postojanju ORB (Object Request Broker) sloja kao middleware-a u sistemu koji slui za uspostavljanje komunikacije izmeu objekata i klijenata koji im pristupaju. Iznad ORB sloja se nalaze delovi koji obezbeuju uspenu interakciju deljenih objekata i samog sistema. Sami deljeni objekti su specifirani preko jezika za definiciju interfejsa (IDL) kojim se odreuju metode objekata, liste parametara poziva i povratne vrednosti metoda. Specifikacija objekata moe biti dvojaka u binarnoj formi kada se data specifikacija linkuje sa samim procesom koji e je koristiti i u vidu biblioteka koje koriste IDL specifikaciju da bi koristili objekat. Da bismo koristili dinamiki interfejs moramo imati biblioteku koja barata sa IDL specifikacijama napisanu za programski jezik koji koristimo. Poziv objekta moe biti statiki (IDL) ili dinamiki (DII). Proces moe kombinovati oba pristupa i na taj nain ostvarujui maksimalnu slobodu u pristupu distribuiranim objektima.

    Ilustracija 8 CORBA specifikacija

  • Dizajn distribuiranih operativnih sistema

    19

    Na drugoj strani DCOM je Microsoft-ova tehnologija iza koje ne stoji ni jedna otvorena organizacija te ista ne moe predstavljati industrijski stanard kao to je to CORBA. Nastao kao evolucija COM interfejsa, popularne komponente za povezivanje aplikacija. DCOM proiruje COM omoguavajui korienje udaljenih objekata. DCOM takoe opisuje objekte pomou nestandardne specfikacije nalik IDL-u (Microsoft IDL) ali se ona moe koristiti samo u binarnoj formi. Svaki IDL poseduje jedinstvenu indentifikaciju (IID) preko koga se uspostavlja instanca objekta i dobija indentifikacija klase/objekta (CLSID). Zbog ovakovog definisanja, DCOM vodi rauna o referencama poziva objekta pa sam oslobaa memoriju kada ne postoji ni jedan proces koji koristi dati objekat. Umesto ORB sloja, postoji Service Control Manager (SCM) koji se takoe bavi povezivanjem i pruanjem usluga middleware-a, ali i samim aktiviranjem objekata. Unutar Windows registra (Windows Registry) se formira veza izmedju CLSID-a i fizike implementacije klase. Ukoliko proces poziva lokalno dostupni objekat, SCM e proitati lokaciju implementacije iz lokalnog registra, ako se pak radi o udaljenom objektu SCM e kontaktirati middleware vora distribuiranog sistema koji ima definisan dati objekat. SCM udaljenog sistema pronalazi na osnovu svog lokalnog Windows registra implementaciju klase, incijalizuje sam objekat i prosleuje IID deljenog objekta SCM-u koji je zahtevao objekat. Za razliku od CORBA sistema, DCOM ne implementira celu arhitekturu distribuiranog sistema ve je za pojedine delove zaduen operativni sistem (Aktivni direktorijum, LDAP,...) to smanjuje portabilsnot DCOM-a. Kao zatvoreni standard, koga razvija Microsoft i postoji samo na Microsoft Windows familiji sistema, DCOM ne predstavlja dobro reenje za bilo koje sisteme gde se moe dogoditi potreba za podrkom drugih arhitektura.

    Postoje takoe i distribuirani sistemi koji definiu svoje interfejse, arhitekture i

    modele koji su prilagoeniji cilju nego generiki modeli popud CORBA i DCOM arhitektura. Komunikacija u ovakvim modelima se najee obavlja razmenom struktuiranih informacija, poput XML-a, a sama razmena se obavlja putem RPC-a, razmenom kanala, pomou nekog drugog protokola vieg nivoa i sl. Mana ovakvog pristupa dizajnu je potpuna nekompatibilnost objekata koji su pravljeni za gore navedene popularne arhitekture.

    9. Primeri distribuiranih sistema

    Kada elimo da pomenemo neke poznate sisteme u praksi, pored Web-a, treba izdvojiti projekte [email protected] i [email protected] koji obrazuju veliku mreu vorova distribuiranog sistema kako bi koristili resurse svih vorova za obradu naunih rezultata prikupljenih podataka sa radio teleskopa, odnosno za obradu rezultata prouavanja sinteze i uklapanja proteina. [email protected] projekat postoji due vremena i moe se pohvaliti

    Ilustracija 9 Microsoft DCOM specifikacija

  • Dizajn distribuiranih operativnih sistema

    20

    impresivnom injenicom da trenutna zbirna procesorska snaga iznosi oko 15 teraflopsa

    ( 121015 operacija sa pokretnim zarezom u sekundi). Treba navesti i projekat distributed.net, osnovan 1997. godine sa ciljem pruanja kako resursa projektima u razvoju tako i pruanja pomoi u razvoju distribuiranih sistema.

    Popularno korisniko okruenje i razvojna platforma za

    Unix i Linux radne stanice GNOME (Gnom, Gnome engl.) implementira CORBA arhitekturu kao osnovu za kako lokalno distribuirane objekata tako i za pristup i korienje udaljeno distribuiranih objekata to obezbeuje laku saradnju razliitih procesa na vie nivoa u cilju formiranja kvalitetnog i dobro uklopljenog radnog okruenja.

    U popularni distribuirani softver se ubraja i distcc,

    distribuirani prevodilac izvornog koda (kompajler) koji znaajno skrauje vreme potrebno za prevoenje velikih projekata koristei procesorsku snagu vie kompjutera vorova distribuiranog sistema. Odlikuje se izuzetno lakom integracijom zbog potpunome kompatibilnosti sa standardnim lancom alata koji se koriste pri prevoenju izvornog koda (GNU make, GNU C Compiler, automake i autoconf,...).

    Ilustracija 9 Najpopularniji distribuirani sistemi

  • 21

    SEKC I J A 3

    DISTRIBUIRANI

    OPERATIVNI SISTEMI

    I pored velikih istraivanja u ovoj oblasti, naroito u poslednjoj dekadi, distribuirani operativni sistemi koji su danas prisutni ne predstavljaju sistem opte namene koji uspeva da ispotuje sve principe distribuiranih sistema

  • Dizajn distribuiranih operativnih sistema

    22

    Ilustracija 11 Distribuirani operativni sistem

    10. Definicija distribuiranog operativnog sistema

    Krajem prole dekade doivljavamo veliku ekspanziju u broju i veliini kompjuterskih mrea kao i razvoj same kako hardverske arhitekture tako i softverskih modela. Opte prisuran je trend napredovanja mobilnosti, i portabilnosti u softverskim modelima kao i elja za povezivanjem ureaja i resursa na globalne kompjuterske mree.

    Pretee distribuiranih operativnih

    sistema su bili sistemi sa podrkom za vie procesora sa zajednikom memorijom nakon ega su doli mreni operativni sistemi na kojima se izvravaju sloeni distribuirani sistemi uz pomo middleware sloja jer sam OS nema podrku za transaprenciju distribucije. Ukljuivanjem middleware sloja u sam OS dolazimo do distribuiranog operativnog sistema koji implementira transparentnost distribucije i manje ili vie omoguava izvravanje procesa kao na jednoprocesorskom sistemu sa zajednikom memorijom i resursima.

    Distribuirani operativni sistem je

    sistem koji upravlja kolekcijom nezavisnih kompjutera i njihovim resursima inei da se oni korisniku prikazju kao jedan raunarski sistem.

    Iako istraivanja u ovoj oblasti do

    sada imaju velikog uspeha, distribuirani operativni sistemi koji danas postoje ne

    ispunjavaju sve zadatke distribuiranih sistema. Proirivost i transparentnost konkurencije su veliki problemi upravo zbog nepostojanja centralizovanog upravljanja resursima kao u klasinim operativnim sistemima.

    Svaki vor distribuiranog sistema mora imati implementaciju kernela koji e

    upravljati lokalnim resursima obezbeujui njihovu distribuciju na nivou celokupnog sistema svih vorova najee obeleenog kao klaster. vorovi mogu biti isti, kada se govori o homogenom, ali i razliiti kada je re o heterogenom klasteru.

    Za potrebe distribuiranog operativnog sistema koriste se mikrokerneli koji sadre

    minimum koda koje je potrebno izvriti u kernel modu (postavljanja podeavanja nad hardverom, prebacivanje procesora sa procesa na proces, upravljanje MMU procesora, prihvatanje hardverskih prekida itd.) dok se sve ostale celine (upravljanje procesima, memorijom, resursima, komunikacija itd) obavljaju iz procesa pokrenutih u korisnikom modu iz procesa kernela. Prednost mikrokernela je u fleksibilnosti, sami delovi sistema iz korisnikog prostora mogu imati potpuno drugaiju realizaciju na razliitim vorovima, uz zadravanje istog interfejsa komunikacije sa kernelom. Mana mikrokernela je pojava usporavanja usled poveanja komunikacije izmeu delova sistema, to za distribuirane operativne sisteme ne predstavlja veliki gubitak poto se odvijaju u mrenom okruenju gde nesumnjivo postoje mnogo ua uska grla. Druga mana je razbijanje tradicije razvoja sistemskog softvera koji nije u skaldu sa monolitikim kernelima koji se koriste u dananjim

    Ilustracija 10 Vieprocesorski operativni sistem

  • Dizajn distribuiranih operativnih sistema

    23

    Unix sistemima. Distribuirani operativni sistemi pak inae razbijaju stege konzervatizma razvoja te mikrokerneli definitivno predstavljaju najbolje reenje za korienje.

    Distribuirani operativni sistem treba da obavlja sve poslove klasinog operativnog

    sistema (upravljanje memorijom, procesima i resursima) samo u drugaijem okruenju. Osnova svakog distribuiranog sistema je komunikacija sa ostalim vorovima koja se odvija po odreenom aplikativnom protokolu. Uvek treba znati da se distribuirani operativni sistemi izvravaju u mrenom okruenju te je komunikacija esto nepouzdana i prespora. Postoje brojna reenja kako se sigurnost i brzina komunikacije mogu poveati korienjem kvalitetnih aplikativnih protokola koji imaju brzo vreme odziva i dobru kontrolu greaka, koji dobro povezuju i dobro prosleuju poruke vorovima klastera,

    Krajnja reprezentacija distribuiranog operativnog sistema je virtualni sistem (VM

    computer) koji na raspolaganju ima sve resurse klastera i u svakom trenutku moe obezbediti korisniku njihovo korienje

    11. Komponente DOS-a

    Pod komponentama distribuiranog operativnog sistema se pored komponenata klasinog operativnog sistema (upravljanje memorijom, resursima i procesima) ubrajaju i komponenete koje se nalaze u slojevima iznad ili ispod nabrojanih. U ove dodatne, za DOS specifine komponente se ubrajaju model deljenja memorije, model deljenja resursa i procesorskog vremena, kao i komunikacija i sinhronizacija.

    Distribuirani operativni sistem takoe mora implementirati kontrolu greaka u

    sistemu, sigurnosnu zatitu pri pristupu resursima kako na korisnikom tako i na sistemskom nivou, distribuirani sistem datoteka,...

    Da bismo dobili distribuirani operativni sistem opte namene, mora postojati, pored

    ve u sistemu obezbeene transparencije, i dodatni nivo emulacije sistema koji usklauje API sistema (interfejs koji procesi koriste za komunikaciju sa sistemom, potraivanje i oslobaanje memorije i resursa itd) sa POSIX i SysV specifikacijama bilo da se to radi na binarnom nivou (podrka za pokretanje programa kompajliranih za druge sisteme) ili putem specijalnih biblioteka koje ostvaruju kompatibilnost i sa programom se vezuju za vreme prevoenja stvarajui verziju programa za konkretni distribuirani operativni sistem.

    Model deljenja memorije

    Jedan od razloga zato je mnogo tee napraviti distribuirani operativni sistem jeste iz razloga to nije mogue kao kod klasinih operativnih sistema vrlo jednostavno napraviti deljenje memorije gde e biti smeteni podaci o stanju sistema kako softvera tako i hardvera i njegovih kompozitnih delova, potrebni za rad operativnog sistema. Za razliku od toga posedujemo samo razmenu poruka kroz komunikacione mehanizme. Kanjenje takvih poruka u komunikaciji usled zaguenja mree, a pak neophodna komunikacija u realnom vremenu za, na primer blokiranje pojedinih resursa, samo oteava stvar.

    Upravo zbog navedenog problema, pojavili su se razliiti modeli koji pruaju emuliranje deljene memorije unutar klastera. Uz pomo ovakvog dizajna prua se podrka za rad programima koji su pisani za klasine sisteme, a omoguena je i podrka POSIX stadarda.

    Jedan od modela deljenja memorije u DOS okruenju jeste DSM (Distribuited shared memory) i zasniva se na postojeoj implementaciji imaginarnog adresnog prostora u klasinim operativnim sistemima po principima stranienja i segmentacije koji su opisani u odgovarajuem poglavlju ovog rada. DSM prikuplja stvarni fiziki adresni prostor memorije

  • Dizajn distribuiranih operativnih sistema

    24

    svakog vora klastera i organizuje virtualni adresni prostor nad kojim postavlja organizaciju stranienjem. Kada proces koji se izvrava zahteva adresu koja nije prisutna lokalno, lokalni kernel distribuiranog operativnog sistema suspenduje proces, prihvata sadraj stranice i dostavlja je procesu nakon ega ponovo nastavlja sa izvravanjem procesa.

    Usko grlo ovakvog sistema jeste brzina mree. Pristojna ubrzavanja je pak vrlo lako

    postii prostom replikacijom stranica memorije. Naime, nakon to proces zahteva odreenu adresu memorije koja se nalazi u udaljenoj stranici u koju je mogue samo vriti upis, kernel moe izvriti replikaciju te stranice, odnosno lokalno napraviti njenu kopiju. Kako je nad stranicom memorije omogueno jedino itanje, ne dolazimo do problema konkurencije i sinhronizacije, tj. ne moramo pratiti promene nad stranicom. Postoje i modeli kod kojih postoji replikacija svih stranica, kao i heuristiko pronalaenje stranice koja e sledea trebati kako bi se izvrila i njena replikacija pre nego to proces uopte i zahteva uitavanje neke adrese iz te stranice. Kada se radi replikacija svih stranica, na sistemu mora biti definisan efikasan i vrlo brz nain obavetavanja svih vorova da je stranica promenjena kako bi se izbeglo postojanje vie razliitih kopija istog adresnog prostora. Kako bi informacija sigurno stigla, ovo obavetavanje svih vorova mora biti izvreno pre samog upisa. Tada e, u trenutku upisa postojati samo jedna kopija stranice, i to ona u koju se trenutno upisuje promena.

    Odreivanje veliine same stranice,

    kao i kod klasinih operativnih sistema, puno menja ponaanje sistema, ali se ovde to deava na drugaiji nain. Stranice su svakako dovoljno male da su podaci za uspostavljanje komunikacije (zahtevanje i prihvatanje stranice) kao i zaglavlje same poruke vei od stranice. Ukoliko bi stranice bile vee (8, 16 ili 32Kb), a proces pristupao kontinuiranom bloku adresnog prostora (nizovi podataka) bilo bi manje transfera stranica. Meutim, tada postoji vea verovatnoa da e se u adresnom prostoru iste stranice nalaziti podaci vie procesa, pa distribuirani operativni sistem mora vriti vie replikacija i ee se boriti sa viestrukim upisima i problemima konkurencije.

    Iako istraivanja traju due od 15 godina, jo uvek se bije bitka izmeu efikasnosti

    distribuiranja memorije, lakoe implementacije takvog modela ali i brzine izvravanja takvog sistema.

    Model deljenja resursa

    Osnovna uloga distribuiranog operativnog sistema jeste da klaster, bilo da je on otvoren ili zatvoren, predstavi kao koherentni jedinstveni sistem i da procesima kao korisnicima sistema omogui transparentno korienje resursa bez potrebe da procesi poznaju lokaciju resursa koji koriste. Delovi distribuiranog operativnog sistema koji implementiraju pronalaenje resursa se oznaavaju kao podsistemi za imenovanje i lociranje.

    Kako se ne moemo osloniti na fiziku adresu ili na neki fiziki adresni opseg,

    resursu moramo dodeliti virtualno ime kroz sistem imenovanja (engl. naming). Samo ime resursa mora biti jedinstveno unutar distribuiranog operativnog sistema, jer se mora omoguiti jednoznano lociranje fizikog resursa na osnovu imena ime se moe korienje fizike adrese u potpunosti zameniti imenom i time postii transparenciju lokacije.

    Ilustracija 12 Distribuirano straniena memorija

  • Dizajn distribuiranih operativnih sistema

    25

    Resurs koji se imenuje, unutar distribuiranih operativnih sistema, moe biti vor

    klastera, tampa, datoteka u distribuiranom sistemu datoteka, proces, prijavljeni korisnik, dokument, objekat, grafiki prozor na jednom od ekrana prikaza, poruka u mrenoj komunikaciji, mrena konekcija itd... Imenovanje postoji i u klasinim operativnim sistemima, kada se imenuje komunikacioni port, putanja datoteke u sistemu datoteka itd.

    Veini resursa se moe i pristupati,

    tj. mogu se koristiti. Za ove potrebe definiemo adresu take pristupa imenovanog inioca (engl. Access point address) ili krae samo adresu imenovanog inioca. Na osnovu adrese imenovanog inioca, a preko sistema imenovanja i lociranja procesi i korisnici distribuiranog operativnog sistema mogu koristiti interfejs datog distribuiranog resursa, odnosno pristupati i koristiti sam resurs. Imenovani resurs, esto za ime vezuje i vie taaka pristupa, meusobno potupno ravnopravnih.

    Logino je sada postaviti pitanje

    zato razlikovati ime resursa i adresu take pristupa. Odgovor je da se upravo vezivanje resursa (kakvog ga mi vidimo fiziki, tampa) sa posebnim jedinstvenim imenom koje obavija dodeljenu adresu take pristupa preko koje se obavija komunikacija sa resursom kroz namenski interfejs model koji obezbeuje transparentnost lokacije. Resurs e imati stalno ime, uz promenjljivu adresu take pristupa koju je uvek mogue dobiti na osnovu imena resursa i zatim je koristiti.

    Treba imati u vidu da su svi elementi sistema imenovanja virualne adrese i imena

    koje se tek na nivou mikrokernela vora klastera povezuju sa fizikim memorijskim opsegom koji je rezervisan za komunikaciju sa datim fizikim resursom.

    Samo ime resursa moe biti sastavljeno od niza bitova ili karaktera. esto se ime

    gradi u itljivom i razumljivom obliku kako bi se olakao pristup resursima. Na primer, ime datoteke u sistemu datoteka je tipian primer takvog imena.

    Radi breg lociranja fizike adrese imenovanog resursa koriste se razliite tehnike

    grupisanja u logike celine prostore imena, koji se mogu pretraivati efikasno korienjem povezanih lista. Drugi nain ubrzavanja lociranja se zasniva na pamenju lokacije pristupne take jednom ve lociranog resursa, kada se naruava transparencija, pa je neophodan mehanizam obavetavanja kada se dogodi migracija ili relokacija resursa.

    Postoje situacije kada nije neophodno uopte poznavati adresu take pristupa ve na

    vie taaka pristupa koje odgovaraju razliitim resursima postoji jedno ime, a sam distribuirani operativni sistem na osnovu parametara (optereenost resursa, korisnikka ovlaenja procesa i dr.) odreuje sa kojom pristupnom takom e povezati proces koji je zatraio lociranje imenovanog resursa.

    Veliki problem u izradi modela deljenja resursa predstavlja i imenovanje i lociranje privremeno dostupnih resursa kao i mobilnih resursa koji esto menjaju fiziku lokaciju pa su relokacije i migracije este. Opisan koncept modela imenovanja i lociranja moe efikasno da se izbori sa ovim problemom uz dodatnu proveru da li je resurs i dalje dostupan i uklananja imena resursa u sluaju nedostupnosti. Meutim, ovaj koncept ne moe da postigne efikasnost modela u kome je prisutno keiranje lokacija, hijerarhijsko povezivaje, grupisanje resursa u prostore imena itd.

    Ilustracija 13 Sistem imenovanja

  • Dizajn distribuiranih operativnih sistema

    26

    Model deljenja procesorskog vremena

    Distribuirani operativni sistem opte namene mora da ima podrku i za deljenje procesorskog vremena. Za implementaciju ove, najverovatnije najsloenije distribucije, potrebno je izraditi poseban model distribucije na nivou sistema, ali i na nivou upravljanja procesima lokalnog kernela svakog vora.

    Procese koji se brzo izvravaju najee je bolje izvriti lokalno na voru, osim

    ukoliko je potreban intezivni pristup udaljenom resursu kada je proces bolje migrirati na vor koji poseduje resurs koji se koristi jer je lokalna unutar procesorska komunikacija za nekoliko redova veliine bra od komunikacije izmeu vorova, ak i u danas prisutnim veoma brzim LAN okruenjima.

    Korisnik e proces svakako pokrenuti na jednom voru sistema. Zavisno od dizajna

    distribuiranog operativnog sistema, vor e ili krenuti sa izvravanjem procesa ili e proces uvrstiti u centralizovani sistem upravljanja procesa koji e ga rasporediti veoma slino kao i u klasinim operativnim sistemima uz pomo odreenog modela (RoundRobin, Multiple Feedback,...). U drugom metodu, korisnik sa sistemom komunicira preko terminala, unosei naredbe koje sistem izvrava poput mainframe viekorisnikih sistema. Meutim, kako je cilj DOS-a to vea decentralizovanost ime se dobija laka proirivost, drugi metod ne predstavlja dobar izbor, iako je jednostavniji za realizaciju.

    Za koncept distribucije je efektniji pristup pokretanja procesa lokalno kroz

    modifikovani Multiple Feedback algoritam koji forsira krae procese. Ukoliko je trajanje izvravanja due, proces e prelaziti u sledei nivo. Kada doe do kritinog nivoa, proces e prestati sa lokalnim izvravanjem i biti dodeljen upravljanju procesa na nivou distribuiranog operativnog sistema. vor sa najvie neiskorienosti procesorskog vremena e preuzeti proces, odnosno proces e migrirati sa sobom prevlaei i delove deljene memorije koja mu je neophodna za izvravanje. Ukoliko je model distribucije memorije dobro dizajniran, migracija procesa e se svesti na prebacivanje stanja procesora i izmenu liste procesa na jednom i na drugom voru. Pri poetku izvravanja, proces e zahtevati memoriju iz virtuelnog adresnog prostora drugog vora pa e i stranice biti replicirane na novom mestu izvravanja procesa. Proces e se ponovo izvravati na isti nain primenom Multiple Feedback algoritma. Odabir kritinog nivoa za migraciju procesa je jako bitan jer e uz malu vrednost biti previe prebacivanja to je veoma vremenski zahtevna operacija naroito ako postoji veliki memorijski blok koji proces koristi, dok e se uz veliku vrednost izgubiti distribucija tj. nee ni dolaziti do migracije.

    Ako bismo eleli da dodatno unapredimo ovakav model distribucije procesorskog

    vremena, morali bismo uraunati i ostale faktore isplativosti migracije procesa veliinu i lokaciju memorijskog bloka koji proces koristi i resurse kojima proces pristupa ili moe pristupati. Ispitivanje ovih faktora esto zahteva i odreenu heuristiku i pretpostavljanje ta proces moe raditi u narednom ciklusu dodele procesorskog vremena. Tako dobijamo kvalitetan model distribucije gde proces migrira na najrastereeniji vor klastera, najblie korienom resursu, uz lokalno dostupan adresni prostor memorije koju proces koristi pri izvravanju. Meutim, situacija najee nije tako idealna pa je potrebno napraviti kompromis izmeu izvravanja na najrastereenijem procesoru i, na primer, voru gde je lociran resurs koji se koristi to se vri pravilnim odabirom nivoa migracije, nivoa uticaja svakog pojedinanog faktora, predhodnim istorijatom migriranja procesa i drugo.

    Komunikacija

    Radno okruenje distribuiranog operativnog sistema iskljuuje postojanje zajednikog deljenog memorijskog prostora koji se moe iskoristiti za komunikaciju izmeu procesa. Sve to se odvija u distribuiranom operativnom sistemu je praeno veoma intenzivnom komunikacijom izmeu sistemskih procesa na vorovima klastera. Oigledno je da je kvalitet implementirane komunikacije jako bitan za brzinu izvravanja distribuiranog operativnog sistema. Takoe, mreno okruenje u kome se komunikacija odvija, zavisno od

  • Dizajn distribuiranih operativnih sistema

    27

    upotrebljene infrastrukture esto nije potpuno pouzdana pa distribuirani operativni sistem mora imati metode za verifikaciju informacija.

    Prvo to treba odluiti u dizajnu komunikacije distribuiranog operativnog sistema

    jeste koji protokol e se koristi. Protokol treba biti dovoljno portabilan (OSI kompatibilnost), dovoljno visokog nivoa sa mogunostima ispunjenja osobina koje su gore navedene, ali u isto vreme dovoljno pouzdan i, zbog pitanja performansi, redukovan do najmanje mogue mere.

    Vrlo esto korien, a jako efikasan nii protokol komunikacije jeste TCP. On skriva

    omake, izgubljene poruke, duplirane poruke, zakasnele poruke i sl. Specijalnim nainom grupisanja i transporta poruka. TCP stack jeste OSI kompatibilan ali odstranjuje deo OSI slojeva, tako da se sastoji od sloja mrene infrastrukture, mrenog sloja (IP, ICMP, IGMP), transportnog sloja gde je sam TCP protkol i aplikacionog sloja gde se nalaze vii protokoli. Vii protkoli mogu potpuno zanemariti smetnje u komunikaciji. Ipak u sluaju prekida komunikacije, TCP protokol ne moe ponovo pokrenuti komunikaciju ili pronai vor klastera koji poseduje replikaciju stanja sistema i podataka koje je trebalo preneti ve je to zadatak viih protokola kao to je RPC (Remote Procuders Calls).

    O RPC-u (i objektnoj varijanti RMI-u) je ve bilo rei u prikazu distribuiranih

    sistema. Princip rada RPC-a jeste u skrivanju eksplicitne komunikacije, odnosno pruanja mogunosti da pomou posebnih podsistema smetenih unutar kernela i proirenog TCP stack-a procesi mogu pozivati procedure sa drugih vorova klastera na isti nain kao i

    RPC protokol komunikacije Osnova RPC protokola jeste obezbeivanje lakog pozivanja deljenog udaljenog serivsa, na isti nain kao to se obavlja poziv lokalne sistemske procedure (sistemskog poziva). Ulazni podaci na osnovu kojih se izvrava servis se prenose kao parametri poziva udaljene procedure. U lokalnom pozivu sistemskih procedura parametri mogu biti preneti po vrednosti i po referenci, a pored direktnih parametara, koriste se i globalne varijable. Oigledno je da globalne varijable nisu mogue u pozivima udaljenih procedura. Prenos po referenci je, zavisno od modela deljenja radne memorije obino sporiji od prenosa po vrednosti jer je potrebno izvriti dodatne upite kako bi se saznao sadraj referenciranog virtualnog adresnog prostora sa drugog vora.

    Ilustracija 14 Model komunikacije u RPC protokolu

    RPC se ni po emu ne sme razlikovati od obinog sistemskog poziva. Kernel presree poziv i usmerava ga na RPC modul koji od sistema imenovanja (takoe predefinisana udaljena deljena procedura) saznaje adresu na koju treba uputiti poziv, pakuje parametre poziva na osnovu IDL specifikacije deljene procedure i emituje ih ka njoj u klijent-server komunikaciji. Serverski RPC modul prima zahtev, na osnovu IDL-a obrauje zapakovane parametre i poziva ovaj put lokalnu proceduru i hvata rezultat. Ponovo na osnovu IDL-a deljene procedure formira odgovor i povratnu vrednost procedure i vraa je klijentu koji prima odgovor i procesu koji je zahtevao poziv deljene procedure dostavlja povratnu vrednost kao da je procedura izvrena lokalno.

  • Dizajn distribuiranih operativnih sistema

    28

    lokalno dostupne sistemske pozive. RMI za razliku od RPC-a umesto sa procedurama interaguje sa objektima i njihovim metodama. RPC i RMI protokoli se koriste za obavljanje i komunikacije niskog nivoa (u klasinim operativnim sistemima realizovana preko deljene memorije) i meuprocesnom komunikaciju vieg nivoa (eksplicitna takozvana IPC komunikacija).

    Svu komunikaciju u DOS-u moemo podeliti u nekoliko kategorija. To je najpre

    komunikacija izmeu dva vora, ureena po klijent-server modelu. Komunikacija ove vrste zapoinje slanjem zahteva od klijenta ka serveru, a zavrava vraanjem odgovora nakon to server izvri traenu uslugu. Za formiranje zahteva klijent mora znati adresu servera. Adresa moe biti unapred predodreena, ili moe biti promenljiva. U drugom sluaju klijent najpre emituje broadcast paket sa zahtevom usluge koju trai, a server koji tu uslugu prua odgovara sa svojom adresom. Alternativno postoje i modeli sa posebnim serverima zaduenima za adresiranje koji uvaju listu usluga koje serveri pruaju. Sama komunikacija se obavlja u protokolu vieg nivoa, a ukoliko je to RPC, onda klijent poziva proceduru servera ime je obuhvaen celokupni proces.

    Druga vrsta komunikacije je komunikacija sa grupom. Obino je izraena u jedan

    ka ostalima modelu gde se jedan lan grupe obraa svim ostalim lanovima grupe, odnosno obraa se grupi kao virtualnom serveru, dok on preuzima ulogu klijenta. Grupa moe biti dinamina, tj. promenljiva kada je virualizacija grupe neophodna. Adresiranje grupe se moe vriti adresiranjem svakog njenog lana to je relativno sporo i nedovoljno proirivo. Modelu dinamine grupe bolje odgovara broadcast komunikacija kada samo lanovi grupe primaju poruku upuenu svim vorovima klastera. Iako efikasna za realizaciju, ovakav princip komunikacije nepotrebno zaguuje mreu. Trei metod adresiranja, obeleen kao unicast, predstavlja varijaciju broadcast-a kada se poruka na nivou protokola komunikacije upuuje samo lanovima grupe.

    est je sluaj kada u grupi vorova treba izabrati lidera, koji e voditi bilo oporavak

    od havarije ili biti zaduen za koordinaciju grupe i njenu interakciju sa spoljnim lanovima. Termin lider ne treba shvatiti bukvalno, jer u jednom trenutku u grupi moe postojati vie lidera, zaduenih za razliite operacije. Algoritam korien u Amoeba distribuiranom operativnom sistemu je poznat kao pozivni algoritam (engl. Invitation Algorithm), primenjuje se u izboru lidera u grupi vorova koji komuniciraju asihrono. Na poetku izbora svi vorovi imaju jednake anse da postanu lider, to je jedan od osnovnih zahteva potpune distribucije i samim tim i velike otpornosti na greke jer ne postoji predodreeni ili favorizovani lider. Svaki vor pamti informacije o grupi kojoj pripada i lideru te grupe. Najpre svaki vor kreira samostalnu grupu i sebe proglaava liderom. Periodino svaki vor alje poruku ostalim vorovima koji zajedno sa njim treba da oforme grupu proveravajui da li su oni lider svoje pod-grupe. Ukoliko je odgovor potvrdan, vor pauzira aktivnost odreeno vreme koje je proporcionalno veliini njegove grupe, a zatim pokree proceduru sjedinjavanja grupa. U ovoj proceduri, vor poziva ostale lidere da mu se prikljue. Drugi lider po prijemu poziva prosleuje poziv svim svojim lanovima. Svaki vor koji bilo direktno ili indirektno dobija poruku da se prikljui odgovara svojim pristankom. Svaki vor koji je odgovorio da pristupa grupi ne dobije potvrdu o lanstvu u zadatom periodu ekanja (koji zavisi od toga da li je on trenutno lider neke grupe i kolika je ta grupa) on pokree operaciju slanja poziva. Postoji nekoliko uslova kojima se odreuje da navedena procedura uvek rezultuje svim lanovima u grupi i jednim odabranim liderom, odnosno razbijanjem do sada sainjenih pod-grupa i ponovnim pokretanjem procedure.

    Pored izbora lidera u grupi procesa i formiranje samih grupa procesa, u grupi je

    potrebno obezbediti i decentralizovano glasanje kojim procesi mogu doneti zajedniku odluku onda kada je to potrebno. Najee se koristi dvofazni protokol odluivanja, u kome se u prvoj fazi najpre odrava glasanje, a u drugoj izvrava akcija na osnovu rezultata glasanja. Klasina implementacija ovakvog dvofaznog algoritma ide sledeim tokom: u grupi se izborom odreuje lider koji organizuje glasanje, on multicast-uje zahtev za glasanje svim ostalim lanovima grupe. Zatim lanovi obrauju zahtev i odgovaraju organizatoru izbora koji prebrojava glasove i odreuje konanu odluku. U drugoj fazi grupa se obavetava o rezultatima i akcija se preduzima.

  • Dizajn distribuiranih operativnih sistema

    29

    Problem dvofaznog protokola glasanja je oigledan ne postoji kontrola prebrojavanja glasakih listia i kraa na izborima je time omoguena. Ovakvo ponaanje je dodue esto u stvarnosti, ali u distribuiranim operativnim sistemima nije dozvoljeno jer naruava sigurnost sistema. Zato se uvode posmatrai - kontrolori prebrojavanja, ili u boljem sluaju vri se vie prebrojavanja, moda ak i ekstremno kada svaki bira uestvuje u prebrojavanju glasova. Sada, umesto organizatora glasanja postoji distribuirani interfejs glasanja. Proces glasanja se zapoinje i interfejs sistema glasanja formira prostor za uvanje rezultata, i otvara distribuirane procedure za pregled rezultata i slanje rezultata. Nakon toga on pokree vremensko ogranienje u kome se birai moraju javiti. Svaki bira pojedinano proverava da li do sada postoji neki glas prijavljen interfejsu glasanja i ako ne postoji alje glas. Ukoliko ve postoji glas prijavljen interfejsu, bira najpre uporeuje vrednost glasanja sa svojim glasom. Ako se slau, bira ne radi nita, u protivnom oglaava svoj glas ostalim biraima. Kada svi birai dobiju priliku da uporede svoj glas sa prvim sauvanim u interfejsu glasanja (pre isteka vremenskog ogranienja), birai analiziraju sve oglaene vrednosti i utvruju da li postoji kritina veina koja se nije sloila sa prvim glasom. Ako kritina veina postoji, u saradnji sa interfejsom se po utvrenim kriterijumima ponavlja glasanje kako bi se eliminsali ubaeni ili pogreni glasovi pojedinih biraa. Jedini preduslov za uspeno glasanje u ovom algoritmu jeste da veina biraa budu ispravni, to je i logino. Sam algoritam je vrlo uspean i jako dobro se skalira sa porastom broja biraa (priblino ostvaruje idealnu zavisnost O(1)).

    Kada se govori o grekama u komunikaciji mora se imati u vidu da protokoli nieg

    nivoa (TCP na primer) imaju zadatak da obezbede pouzdan transfer poruke meutim u sluaju prekida veze ili havarije transmisija poruka se nikako ne moe obezbediti. Zato protokol vieg nivoa (RPC) i sam model komunikacije u distribuiranom operativnom sistemu mora imati naina da premosti greke nastale usled havarije mree, usled havarije servera i usled havarije klijenta. Kod havarije servera, server moe biti onesposobljen pre primanja zahteva kada klijent (i sistem imenovanja) ne moe da pronade server koji nudi datu proceduru. U takvom sluaju se korisniku i procesu prijavljuje greka. Havarija servera moe nastati i nakon primanja zahteva i tada nastaje problem jer klijent ne moe znati da li je server izvrio operaciju pre havarije ili ne. Ovo postaje naroito opasno u sluaju da operacija poziva druge udaljene procedure ili menja stanje distribuiranog operativnog sistema. Zato se ovakve bitne operacije rade pomou transakcija.

    Transakcije mogu potpuno da zamene princip delimine sinhronizacije, ili da ga u

    blaoj varijanti korienja kvalitativno dopunjuju. Promene koje se vre transakcijama imaju osobinu sve-ili-nita, odnosno ukoliko doe do greke u komunikaciji ni jedna operacija iz tekue sesije nee biti izvrena, odnosno bie sve izvrene ukoliko se transakcija zavri uspeno.

    Kontrola greaka u komunikaciji u distribuiranim operativnim sistemima i distribuiranim sistemima uopte postoji na vie razliitih nivoa. Sam protokol prenosa (TCP, UDP i sl.) ima kontrolu greaka kojom se ostvaruje pouzdanost prenetih poruka i podataka izmeu dva vora. Ukoliko je protokol konekcijski (sesijski) orijentisan, kao to je TCP, onda je zagarantovan i redolsed poruka kao i informacija o prekidu konekcije.

    Ipak, na nekim viim nivoima je potrebno ostvariti potvrdu da li je poruka validno

    obraena. Ovde se dizajneri DOS-a susreu sa klasinim problemom dve armije. Naime, dva generala se moraju dogovoriti o napadu na treeg. Ukoliko napadnu istovremeno, pobedie dok e u protivnom izgubiti. Problem je to je njihova jedina komunikacija nepouzdani glasnik koji se mora provui kroz teritoriju treeg generala. Prvi general je poslao glasnika da obavesti drugog da napad poinje sutradan izjutra i glasnik je stigao do drugog generala. Meutim, drugi general se bojao da prvi nee znati da li je glasnik stigao i da e odustati od napada pa je poslao glasnika nazad da potvrdi da je poruka stigla. Glasnik je ponovo uspeno stigao, ali se sada prvi general bojao da drugi nee znati da je glasnik stigao pa da e odustati od napada. Kao to se vidi, ma koliko puta generali slali glasnika, nikada nee doi u situaciju da su sigurni da e jedan i drugi napasti istovremeno, odnosno nisu uspeli da razmene jednu veoma jednostavnu informaciju. Logino je zapitati se kako e se onda u distribuiranim operativnim sistemima prenositi pokazivai na memorijske strukture, informacije o distribuciji procesa i mnoge druge znatno sloenije informacije.

  • Dizajn distribuiranih operativnih sistema

    30

    Upravo je kontrola greaka u komunikaciji, komponenta protokola vieg nivoa zaduena za uspostavljanje uspene verifikacije primljene i obraene informacije.

    Malo drugaiji je i problem vizantijskih generala. Umesto o dogovoru o vremenu

    napada, n generala moraju razmeniti informacije o broju svojih trupa kako bi se dogovorili o napadu. Meutim, meu njima postoje generali koji ili nemaju sigurnu komunikaciju (glasnik moe biti zarobljen i zamenjen prevarantom koji e lairati informaciju) ili sami generali ele da zbune ostale (neprijateljski proces, ili falian proces). Reenje problema spada u klasine algoritme i moe se pronai obraen na razliite naine. Kao krajnju informaciju svi generali moraju imati podatke o validnom stanju ostalih, odnosno obeleene neispravne podatke. Reenje se svodi na prenos informacija o svim generalima kroz sve generale, i generalno reenje se moe dobiti samo u sluaju da postoji vie od dve treine pouzdanih generala. Konkretno, u distribuiranim operativnim sistemima algoritam reavanja problema vizantijskih generala se esto koristi u sistemima za glasanje, dogovor, komunikaciju unutar grupe i sl.

    Razliiti su scenariji prekida komunikacije. Klijent moe neuspevati da locira server,

    poruka sa zahtevom moe biti izgubljena, server moe napraviti greku prilikom obrade zahteva, poruka sa odgovorom moe biti izgubljena, ili klijent moe naleteti na greku nakon slanja zahteva. Svaki od ovih problema trai razliita reenja. Ponekad je mogue izvriti oporavak od greke ponovnim slanjem zahteva, dok to ponekad nije mogue. Takoe, u nekim situacijama vremensko ogranienje nakon ega se emituje poruka o greci je jedino reenje. Ipak, ponekad je to neprihvatljiva solucija.

    Greke u komunikaciji sa grupom se moraju razloiti na dva dela. Prvi su greke

    koje nastaju u komunikaciji grupe sa spoljnim iniocima, kada se one posmatraju kao greke u klijent-server komunikaciji, a drugo su greke koje nastaju u komunikaciji unutar same grupe bilo da su one vezane za odluivanje i glasanje ili za razmenu informacija. Takoe, unutar same grupe mora u svakom trenutku postojati sinhronizacija, i svaka pojava nesinhronizovanosti grupe pre ili kasnije vodi ka pojavi greke u radu te grupe.

    Sinhronizacija vremena

    vorovi klastera su, kao to je ve nekoliko puta naglaeno nezavisni raunarski sistemi. Kao takvi, svaki vor operie samostalno, pod upravljakom palicom distribuiranog operativnog sistema. Na nivou sistema meutim veina atomskih operacija mora biti izvrena tano odreenim redosledom, u tano odreenom vremenskom trenutku na nivou celokupnog sistema. Upravo obezbeivanje usklaenosti toka vremena na svim vorovima klastera kao i toka komunikacije na nivou distribuiranog operativnog sistema uopte je zadatak sistema za sinhronizaciju.

    U klasinim operativnim sistemima pojam sinhronizacije vremena je potpuno

    nepoznat jer se svaki proces u svakom trenutku moe obratiti kernelu odgovarajuim sistemskim pozivom kako bi dobio informaciju o tanom vremenu. Ukoliko jedan proces zahteva informaciju o vremenu, i odmah zatim drugi proces zahteva informaciju o vremenu, drugo vreme e biti vee od prvog, ba kao to je i realno stanje. U distribuiranim operativnim sistemima ovo nije sluaj jer svaki vor klastera meri sopstveno vreme na nivou hardvera. Kada se prvi proces pokrene na jednom voru i zahteva informaciju o vremenu, nepostoji nikakva garancija da e to vreme biti manje od vremena koje kasnije dobije drugi proces koji je pokrenut na drugom voru klastera.

    Najpre moramo utvrditi kako moe doi do odstupanja u vremenu izmeu razliitih

    vorova klastera. asovnik u svakom voru predstavlja oscilujui kristal sa relativno stalnom frekvencijom (brojem otkucaja). Nakon definisanog broja perioda oscilacije, stalni broja u posebnoj memoriskoj oblasti pod kontrolom BIOS-a se uveava za jedan kvant vrednosti. Unutar BIOS-a se povezuje vrednost memorijske lokacije sa stvarnim datumom i vremenom nakon ega dobijamo vreme izraeno u klasinim jedinicima (godina, mesec, dan, as, minut, sekunda,...). Ipak, broj oscilacija kristala nije isti na svim vorovima

  • Dizajn distribuiranih operativnih sistema

    31

    klastera. Iako naizgled neznatna, nakon kritinog perioda razlika poinje da se intenzivno primeuje ometajui rad distribuiranog operativnog sistema.

    Kao reenje ne moemo koristiti jedan asovnik kome verujemo i to iz dva razloga.

    Jedan je naruavanje autonomnosti svakog vora, a drugi praktina neupotrebljivost takvog pristupa jer bi centralizovani merni asovnik imao preveliko optereenje iz celog sistema, odnosno postojalo bi kanjenje izmeu realnog vremena i informacije koju asovnik prosleuje kao odgovor usled perioda potrebnog za obradu zahteva, pripremanje odgovora i njegovo uspeno slanje do destinacije.

    Ako sinhonizujemo sve asovnike u realnom trenutku T1 na broj otkucaja N1, u

    realnom trenutku T2 svi asovnici vorova bi trebali da pokazuju CTTNN += )( 1212 , gde je C odnos broja otkucaja po jedinici merenja vremena. Praktino, dananji asovnici stvaraju greku tako da N2 nee biti isto na svim vorovima klastera, odnosno broj moe biti manji ili vei zavisno od naina devijacije merenja vremena u samom asovniku. Da bismo ispravili greku, moramo periodino sinhronizovati asovnike sa mernim asovnikom i pri tome formirati takav sistem koji ispravlja dve greke. Prvo, da je od trenutka kada vor poalje informaciju o trenutnom broju otkucaja, do trenutka kada drugi vor informaciju primi, proteklo vreme i drugo da ni po koju cenu ne smemo na bilo kom voru vreme vratiti unazad jer to moe izazvati probleme sa objektima, datotekama i procesima na samom voru i sistemu uopte.

    Kao to se vidi na slici, pretpostavka

    je da e vreme slanja zahteva i vreme slanja odgovora biti isto, te da moemo smatrati da

    ono stoga iznosi 2/)( 12 TT . Kako i T2 i T1 merimo na istom asovniku, iako on nije taan, moemo tano izraunati interval. U ovakvoj postavci nije uraunato vreme obrade zahteva pa dodatno moemo poboljati sistem aljui i vreme obrade uz informaciju o trenutnom broju otkucaja.

    Opisani pristup je vrlo centralizovan, ali veoma pouzdan ukoliko moemo da garantujemo tanost poredbenog asovnika to je lako izvesti sinhronizujui asovnik sa radio signalom sa satelita ili sl. preko komercijalno dostupnih ureaja.

    Alternativno, moemo izbei prisustvo poredbenog asovnika koristei se prosenom

    vrednou. Periodino svaki vor moe upitati ostale vorove klastera trenutno vreme, aljui im svoje trenutno vreme. Na osnovu prikupljenih odgovora vor moe odluiti kako treba da podesi svoj asovnik.

    Tree, u modernim distribuiranim operativnim sistemima takoe prisutno reenje

    jeste korienje logikih asovnika. Pre poetka vremenski kritinog procesa, za potrebe tog procesa vorovi se dogovore o poetku inicijalizacije logikog asovnika za dati proces. Nakon toga, logiki asovnik se aurira na osnovu razlike broja otkucaja izmeu vremena formiranja asovnika i sadanjeg vremena. Usled razliite frekvencije oscilovanja, logiki asovnik se takoe mora aurirati ali je jednostavnije dobiti taniju sinhronizaciju jer je asovnik vezan samo za jedan proces, a ne za ceo vor ili ceo distribuirani operativni sistem. Kontrola greaka

    Do sada je u kontekstu pojedinih komponenti distribuiranog operativnog sistema bilo rei o sistemu za kontrolu i prikrivanje greaka, odnosno tolernaciji greaka. Specifinost greaka u distribuiranim sistemima jeste parcijalna greka, greka samo na jednom delu ili u jednom sloju sistema. Greka moe biti izolovana ili moe voditi krahu

    Ilustracija 15 Kanjenje broja otkucaja u odgovoru

  • Dizajn distribuiranih operativnih sistema

    32

    sistema procesa ili gubitku podataka. Za zadovoljavanje osnovnih principa u dizajnu distribuiranog operativnog sistema, sistem mora imati mogunost da nastavi funkcionisanje i pri takvim neoekivanim situacijama.

    Kao merilo kvaliteta distribuiranog operativnog sistema se uzima dostupnost

    sistema, odnosno verovatnoa da se sistem moe odmah koristiti. Sa druge strane pouzdanost je verovatnoa da e sistem raditi neprekidno. Iako slini, ova dva indikatora nisu isti. Sistem koji svakog sata ne radi jednu milisekundu ima dostupnost od preko 99,999%, ali je jako nepouzdan. Sistem koji svakog januara ne radi dve nedelje ima dostupnost od skromnih 96%, ali visoku pouzdanost. Sigurnost i mogunost popravke su takoe bitni faktori u oceni kvaliteta. Sigurnost obezbeuje da se nita katastrofalno nee dogoditi pri pojavi greke, iako to nikako ne moe biti zagarantovano jer greke u sistemu nisu predvidive.

    Sve mogue greke moemo klasifikovati u prolazne (privremeni gubitak kvaliteta

    transmisije podataka), periodine (lo kontakt u delu sistema) i stalne (havarija koja se manifestuje sve do popravke oteenog dela). Po tipu nastanka greke mogu biti hardverske i softverske. Dalje, po posledicama greke moemo podeliti na one koje dovode do prestanka rada sistema, one koje dovode do neispunjavanja zahteva, greke koje dovode do vremenskih prekoraenja, ali i greke mnogo tee za prepoznavanje kao greke koje dovode do greaka u odgovoru, greke koje dovode do promene stanja sistema (naroito opasne kod distribuiranih sistema datoteka), i na vrhu greke koje dovode do sluajnih posledica, najee nastale usled prepisivanja memorije, pogrene komunikacije, zakazivanjem sistema sigurnosti i slino kada su posledice najgore.

    Klasina kontrola greaka se uglavnom svodi na redundantnost na svim nivoima gde

    moe doi do greke. Na primer, u komunikaciji se pored same poruke dodaje i informacija koja pomae verifikaciji ispravnosti poruke. Ukoliko verifikacija neuspe, zahtevae se ponovno slanje poruke, ili preusmeravanje poruke drugom rutom kako bi se zaobile smetnje. Tako dolazimo do drugog uslova, postojanja fizike redundantnosti. Kao to ovek ima dva oka iako moe videti i sa jednim, Boeing 747 ima etiri motora iako moe da leti sa tri, tako se i