Distribuirani sistemi

Konzistentnost i replikacija

Razlozi replikacije
Poveanje pouzdanosti Npr. ako je fajl sistem repliciran, mogue je nastaviti sa radom ako neka kopija bude naruena jednostavnim komutiranjem na drugu kopiju. Poboljanje performansi U sluaju velike geografske razuenosti DS replikacija je poeljna jer smanjuje vreme pristupa podacima (npr. replicirani Web serveri) Replikacija dovodi do problema konzistentnosti

kopija.

Da bi kopije bile usaglaene potrebno je izvriti auriranje

tako da se privremena nekonzistentnost ne primeti; Auriranje kopija dovodi do degradacije performansi, naroito u velikim DS,
Kada i kako e se izvriti auriranje kopija, odreuje cenu replikacije.

Modeli konzistencije
Konzistencija se uvek razamatra u kontekstu read i write operacija
Operacije se mogu obavljati nad deljivim podacima koji mogu biti zapameni u

deljivoj memoriji, deljivoj (distribuiranoj) bazi podataka, ili (distribuiranom) fajl sistemu.
Termin skladite podataka (data store) se koristi za ovakve podatke. Skladite podataka moe fiziki biti distribuirano na vie maina. Usvaja se da svaki proces koji moe da pristupi skladitu podataka ima lokalnu (ili u blizini) kopiju celog skladita. Operacija se oznaava kao write ako menja podatak, u suprotnom se oznaava kao read. Write operacije se prenose (propagiraju) drugim kopijama

Modeli konzistencije (nast.)

Model konzistencije definie pravila po kojima se replicirani

podaci moraju aurirati.

Ako se procesi sloe da potuju odreena pravila, skladite

Pravila definiu redosled operacija. Koriena pravila zavise od aplikacije

podataka garantuje da e funkcionisati korektno.

deljivim podacima

Konzistencija je definisana u kontekstu read i write operacija nad

Striktna Sekvencijalna Kauzalna FIFO

Proces koji obavlja read operaciju oekuje da e dobiti vrednost koja predstavlja rezultat poslednje write operacije U odsustvu globalnog asovnika teko je odrediti koja write operacija je bila poslednja. Zbog toga je potrebno dati druge definicije, to dovodi do niza modela konzistentnosti. Svaki model definie vrednosti koje read operacija nad podatkokm moe vratiti.

Striktna konzistencija
Najjai model konzistencije:

Bilo koja operacija nad podatkom X vraa rezultat poslednje write operacije nad X. Definicija je prirodna i oigledna, ali implicitno usvaja postojanje globalnog vremena, tako da odreivanje poslednje write operacije bude nedvosmisleno.
Jednoprocesorski sistemi tradicionalno podravaju striktnu

konzistenciju.

Npr. Ako u programu stoje naredbe a:=1; a:=2; print(a), rezultat print(a) uvek mora biti 2!.

U sistemu u kome se podaci nalaze na vie maina, kojima

moe pristupati vie procesa, situacija je mnogo sloenija:

Pretpostavimo da proces pi aurira vrednost promenljive x sa 4 na 5 u trenutku t1 i alje novu vrednost svim replikama u grupi (multicast) Proces pj ita (read) vrednost promenljive x u trenutku t2 (t2 > t1). Proces pj treba da proita vrednost 5, bez obzira kolika je razlika (t2-t1).

Striktna konzistencija (nast.)

ta ako je t2-t1 = 1 nsec i koriste se optika vlakna izmedju dve host maine (na

kojima se izvravaju ova dva procesa) koje se nalaze na rastojanju od 3 metra?.

Poruka kojom se zahteva auriranje morala bi da putuje 10 puta bre od brzine svetlosti Po Ajntajnovoj specijalnoj teoriji relativiteta to nije mogue!

Zakljuak: striktnu konzistenciju u distribuiranom sistemu je nemogue postii!

__________________ Oznake:

Problem sa striktnom konzistencijom je to se model zasniva na apsolutnom globalnom vremenu.

Wi(x)a - oznaava da proces i obavlja write nad podatkom x, nakon ega je vrednost x=a Ri(x)b oznaava da proces i obavlja read nad X i dobija vrednost b. Svaki podatak je inicijalno postavljen na NILL

korektno

Nije korektno sa stanovita striktne konzistencije.

Striktna konzistencija (nast.)

Ako je skladite podataka striktno konzistentno, svi upisi

(write) su trenutno vidljivi svim procesima, bez obzira koliko se brzo deavaju dogaaji. Ovakav vid konzistentnosti je praktino nemogue postii u DS. Uvode se slabiji modeli, koji nisu bazirani na apsolutnom vremenu.
Iskustva poakzuju da se programeri mogu izboriti sa slabijim

modelima konzistencije.

U OS i paralelnim sistemima koriste se kritine sekcije i uzajamno iskljuivanje. Nikakve pretpostavke o brzini izvrenja procea se ne mogu uvoditi Ako je potrebno procese sinhronizovati, to mora biti ugraeno u sam program Kritine sekcije omoguavaju da se pristup deljivom resursu linearizuje, tako to e procesi pristupati resursu uzajamno iskljuivo. Ako je potrebno ostvariti odreeni redosled pristupa deljivom resursu to je mogue ostvariti korienjem semafora.

Sekvencijalna konzistencija
Sekvencijalna konzistencija je slabiji model od striktne: Rezultat bilo kog izvrenja je isti kao da su (read i write) operacije svih procesa na skladitu podataka izvrene u nekom sekvencijalnom redosledu i operacije svakog pojedinanog procesa pojavljuju se u ovoj skvenci u redosledu koji je odreen njihovim programom. Def. kae da kada se procesi izvravaju konkurentno na (mogue) razliitim

mainama, bilo koje validno preplitanje read i write operacija je prihvatljivo, ali svi procesi vide isto preplitanje operacija. Ovo smo videli na primeru bankovnog rauna
jedna mogua implementacija je pomou Lamportovih vremenskih markica.
U definiciji se ne spominje vreme, tj. Nema termina poslednja write operacija

Sekvencijalno konzistentno skladite

Naruena sekvencijalna konzistentnost jer svi procesi ne vide na isti nain operacije.

uslovna (kauzalna) konzistencija

Upisi (write) koji su potencijalno uslovljeni moraju se videti u svim

procesima u istom redosledu Konkurentni upisi se mogu videti u razliitom redosledu u razliitim procesima

W(x)aR(x)a, R(x)a W(x)b, W(x)a W(x)b (tj. ova dva upisa su potencijalno uslovljena) W(x)c i W(x)b nisu potencijalno uslovljeni, pa rezultate ovih upisa razliiti procesi mogu videti u razliitom redosledu! ovakvo skladite podataka je uslovno konzistentno, ali ne i sekvencijalno!

uslovna konzistencija (nast.)

a) nije ispotovana uslovna konzistencija b) ispotovana je uslovna konzistencija jer W(x)a i W(x)b nisu medjusobno uslovljeni da bi se implementirala uslovna konzistencija mogu se koristiti vektorski asovnici za uredjenje medjusobno zavisnih dogadjaja

FIFO konzistencija
Upisi koje obavi jedan proces se vide od strane

drugih procesa po redosledu u kome su izdati. ali upisi razliitih procesa mogu se videti u razliitom redosledu u razliitim procesima. drugim reima, ne postoje nikakve garancije o tome kako razliiti procesi vide upise drugih procesa, osim to dva ili vie upisa iz istog izvora moraju stii po redosledu. Jednostavna implementacija:
Svaki proces dodaje poruci auriranja : (proces id, redni broj) Svi ostali procesi primenjuju auriranja po redosledu u kome

su ona obavljena u izvornom procesu.

FIFO konzistencija

Ni jedan od prethodnih modela konzistencije ne dozvoljava ovakav redosled dogadjaja

Repliciranje sadraja i pozicioniranje replika

Kljuno pitanje u DS koji podrava replikaciju je gde, kada i ko moe

obavljati repliciranje i koji se mehanizmi koriste za odravanje konzistencije. Tri tipa replika:
Permanentne replike Replike inicirane od strane servera Replike inicirane od strane klijenta

Logika organizacija tri vrste replika

Permanentne replike
Mogu se posmatrati kao poetni skup replika koje

obrazuju distribuirano skladite podataka.

Broj permanentnih replika je mali.

Primer: Distribucija Web sajta se javlja u dva oblika

Repliciranje fajlova koji ine Web sajt na ogranienom broju servera koji se nalaze na jednoj lokaciji (klaster servera). Kada stigne neki zahtev on se prosleuje jednom od servera, najee po krunom redosledu (round robin) Mirroring Web sajt se kopira na ogranieni broj servera (mirror serveri) koji su geografski dislocirani u Internetu. Klijent odabira jedan od ponuenih mirror servera.

Baze podataka takoe mogu biti replicirane na vie servera koji zajedno formiraju klaster radnih stanica, ili na vei broj geografski distribuiranih sajtova

Replike inicirane od strane servera

Formiraju se na inicijativu vlasnika skladita podataka

da bi se poboljale performanse (vreme odziva) ili rasteretio server ako u nekom trenutku dolazi veliki broj zahteva sa neke udaljene lokacije.

to su privremene replike postavljene u regione iz kojih dolazi

veliki broj zahteva Svaki server vodi rauna o broju pristupa odreenom fajlu i odakle dolaze.

Ako je u odreenom trenutku broj zahteva sa neke lokacije veliki, svrsishodno je instalirati privremene replike u regionima odakle dolaze zahtevi. (Takve replike zovu se i push replike). Web hosting servis nudi relativno statian skup servera u Internetu koji mogu sadrati fajlove i podrati pristup fajlovima koji pripadaju drugom serveru.
Da bi se obezbedile optimalne k-ke Web hosting usluge mogu dinamiki replicirati fajlove na servere gde su ti fajlovi potrebni da bi se poboljale performanse, tj. blie grupi klijenata.

Replike inicirane od strane servera (nast.)

Gde i kada replike treba kreirati ili obrisati? Algoritam dinamike replikacije uzima dve stvari u obzir: broj obraanja fajlu i odakle dolaze zahtevi. Za svakog klijenta, C, server moe odrediti koji je najblii server u Web hosting servisu.

Ako dva klijenta, C1 i C2, imaju isti najblii server P, svi zahtevi za pristup fajlu F u serveru Q, od strane C1 i C2 se jedinstveno registruju u serveru Q: cntQ(P,F), tj. kao da dolaze od servera P. Ako je broj obraanja fajlu F na serveru Q vii od praga replikacije rep(Q,F) donosi se odluka da se izvri replikacija fajla F na server P.

Replike inicirane od strane servera (nast.)

Kada broj obraanja fajlu F na serveru P padne ispod praga

del(P,F), fajl moe biti uklonjen sa servera P, pod uslovom da to nije posledja (jedina) kopija tog fajla.
Na taj nain se broj replika redukuje. Vodi se rauna da bar jedna replika svakog fajla postoji.

Ako je broj zahteva za pristup nekom fajlu izmeu praga

brisanja i praga replikacije, fajl samo moe migrirati sa jednog servera na drugi

Serverski inicirane replike se najee koriste kao

read-only kopije za klijente. Permanentne replike su jedine koje se mogu menjati da bi se sitem odrao konzistentnim.

Replike inicirane od strane klijenta

Vanu klasu replika ine replike inicirane od strane klijenta.
Poznate su pod nazivom klijent ke. Ke je lokalna memorija koja se koristi od strane klijenta da privremeno zapamti kopiju podataka koje je klijent upravo zahtevao (i dobio). Ke moe biti lociran na klijent maini ili na posebnoj maini u okviru klijentovog LANa. Upravljanje keom je u potpunosti preputeno klijentu. Skladite podataka iz koga su podaci preuzeti nema nikakvu obavezu u odravanju konzistencije kea.
Klijent moe uz uee skladita utvrditi da li je kopija ustajala ili vaea.

Klijentski ke se koristi da bi se smanjilo vreme pristupa.

Kada klijent eli da pristupi nekim podacima, on se povezuje na najbliu kopiju skladita podataka, odakle uzima podatke koje eli da proita ili gde smeta podatke koje je modifikovao. Ako je u pitanju samo itanje podataka klijentu se moe omoguiti da zapamti podatke u ke. Sledei put kada klijent zatrai itanje istih podataka, moe ih preuzeti iz svog lokalnog kea. Ovo funkcionie dobro sve dok se replicirani podaci ne promene

Distribucija auriranja
Ako se podaci na nekoj kopiji (replika) promene, i ostale

kopije se moraju aurirati da bi sistem ostao konzistentan (usaglaen). ta se propagira kod auriranja?
Samo obavetenje o obavljenom auriranu
Svodi se na invalidaciju ostalih kopija
Prednost: mali saobraaj kroz mreu Protokoli sa invalidacijom dobro funkcioniu kada je broj auriranja mnogo vei od broja itanja (mnoga auriranja mogu biti obavljena lokalno, bez ponovne invalidacije) .

Podaci koji su aurirani

Aurirani podaci se prenose replikama.
Dobro funkcionie kada je odnos itanje-upis relativno visok (tj. broj itanja je mnogo vei od broja upisa).

Operacija koje su izazvale auriranje.

Ne prenose se podaci, ve operacije koje svaka replika treba da obavi (ovakav prilaz poznat je pod nazivom aktivno repliciranje)
Auriranja esto mogu biti obavljena uz minimalni saobraaj Zahteva vie procesorskog vremena, naroito ako su operacije kompleksne.

Ko inicira auriranje?
Auriranje inicirano od strane servera (push prilaz) Auriranje se prenosi replikama na inicijativu servera, mada replike to nisu zahtevale. Ovaj prilaz se koristi izmeu permanentnih i serverski iniciranih replika, tj. kada je potrebno ostvariti visok nivo konzistencije.
Auriranje na zahtev klijenta (pull prilaz) Server ili klijent zahtevaju od drugog servera da mu prosledi auriranje ako je postojalo.
Npr. uobiajena strategija koja se primenjuje kod Web keeva, je prvo provera da li su keirani podaci jo uvek validni.
Kada ke primi zahtev za itanjem podataka koji se jo uvek nalaze u keu, on prvo kontaktira originalni Web server da proveri da li su podaci u meuvremenu bili modifikovani (klijent proziva server da bi ustanovio da li su podaci bili modifikovani). Ako su podaci bili modifikovani, prenose se sa servera u ke, a zatim prosleuju klijentu