Elektroenergetski softverski inženjering

Replikacija i konzistencija

Arhitektura distribuiranih sistema

2017

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 1

Arhitektura distribuiranih sistema

UVOD U KONZISTENCIJU I
REPLIKACIJU

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 2

 Sadržaj

• Osnovne definicije
• Upravljanje replikama
• Tipovi replika
• Protokoli za propagaciju promena u replike
• Modeli konzistencije
• Kontinualna konzistencija
• Konzistentan redosled operacija
• Primeri (Internet, Smart Grid)

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 3

 Zašto replikacija?

• DEF: Replikacija je proces kreiranja namerno repliciranih resursa u DS

• Resursi mogu biti podaci, procesi, dokumenta, hardver, ljudi, itd.
• Primarni ciljevi replikacije su povećanje dostupnosti sistema i poboljšanje
performansi
• Replikacija olakšava postizanje 4. cilja DS, tj. skalabilnosti
• Skalabilnost omogućava proširenje DS na održiv način, npr. bez osetnog negativnog
uticaja na performanse
• Kopiranje podataka blizu procesa koji ih koriste ima pozitivan uticaj na performanse
• Glavni izazov u postupku replikacije je očuvanje konzistencije između replika
• Obezbeđivanje da će replike biti poravnate za očekivano vreme i na očekivan način
• Kada se jedna kopija ažurira, treba da se ažuriraju sve ostale kopije
• Dodatni izazovi su upravljanje replikama (kada i kako slati podatke) i sporedni
efekti tipa povećano zauzeće komunikacionih linkova za prenos podataka
između replika

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 4

Arhitektura distribuiranih sistema

UPRAVLJANJE REPLIKAMA

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 5

 Upravljanje replikama

• U DS gde se primenjuje replikacija obavezno postoji i plan prema kojem se

vrši postavljanje i ažuriranje replika
• Pitanja na koja treba da odgovori plan postavljanja replika su sledeća:
• Gde? – fizička i logička lokacija replika
• Kada? – vreme kreiranja replika (ako replike nisu stalne)
• Ko? – entitet u DS zadužen za kreiranje replika
• Dodatno je potrebno odvojiti razmatranje postavljanja servera replika i
replika podataka
• Ne moraju svi podaci da se repliciraju na sve servere
• Pitanja na koja treba da odgovori plan ažuriranja replika su sledeća:
• Koji mehanizam se upotrebljava za propagaciju promena?
• Šta i gde se propagira?
• Koliko često se propagira?

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 6

 Tipovi replika podataka

• U procesu održavanja i korišćenja replika učestvuju sledeći elementi DS:

• Podaci – mogu da se nalaze na jednom ili više replika
• Serveri – skladišta podataka, kojih može biti jedan ili više
• Korisnici – entiteti koji koriste (potencijalno replicirane) podatke
• Razlikujemo sledeće tipove replika sa stanovišta postavljanja
• Stalne (permanentne) replike
• Server inicirane replike
• Klijent inicirane replike

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 7

 Stalne (permanentne) replike

• Stalne (permanentne) replike čine početni skup replika u distribuiranom

skladištu podataka
• Broj stalnih replika je mali
• Postoji dva tipa stalnih replika skladišta podataka
• Replike locirane na istoj geografskoj lokaciji (cluster)
• Izbor replike je transparentan za klijenta
• Replike locirane na većem geografskom prostoru (mirroring)
• Klijent eksplicitno bira repliku
• Primer:
• Cluster web servera u Google-ovom data centru
• Web serveri za odabrane države, npr. google.rs

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 8

 Server inicirane replike

• Replike se prave dinamički na inicijativu vlasnika skladišta podataka

• Smanjenje opterećenja servera
• Migracija podataka blizu klijentima u skladu sa opterećenjem
• Izazovi:
• Kada i gde napraviti repliku?
• Kada ukinuti repliku zarad oslobađanja računarskih resursa?
• Kako izbeći ukidanje poslednje replike?
• U procesu kreiranja i ukidanja replika pomažu merenja:
• Statistike o izvorima klijentskih zahteva – ovo je dinamički podatak
• Statistike o pristupu (R) pojedinim zapisima u skladištu podataka
• Opterećenje servera, npr. CPU, memorija
• Opterećenje komunikacionih kanala, npr. bandwidth
• Tempo izmena (W) u skladištu podataka, npr. stranice repliciranih Web sajtova
• Dostupan kapacitet komunikacionih linkova za prijem zahteva i propagaciju replika
• Dostupan hardver – da li postoji dostupan hardver?

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 9

 Klijent inicirane replike

• Kopije se prave dinamički na inicijativu klijenta

• Često se nazivaju keš (client cache)
• Nalazi se na pojedinačnim računarima ili centralnom računaru u mreži (proxy)
• Upotrebljava se kada se keširani podaci retko menjaju u skladištu podataka
• Ima specificirano vremensko trajanje, posle kojeg se obnavlja ili briše
• Prednosti upotrebe klijentskih replika
• Ubrzava se pristup podacima
• Rasterećuje se skladište podataka kojem bi se mnogobrojni klijenti obraćali
• Udaljena skladišta podataka (SP) ne vode brigu o kešu klijenta
• Klijent ga sam održava
• Klijent očitava podatke iz SP i smešta ih u keš
• Problem nastaje kada se podaci promene
• Pogodno je da isti keš deli više klijenata i tada se obično povećava broj
“pogodaka” (engl. cache hit) – traženi podaci se nalaze u kešu

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 10

Arhitektura distribuiranih sistema

ALGORITMI U REPLIKACIJI

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 11

 Klasifikacija replikacija

• Sa stanovišta mogućnosti ažuriranja podataka

• jednosmerna – od osnovnih tabela ka kopijama
• simetrična – dvosmerno
• Sa stanovišta vremena osvežavanja
• sinhrona – odmah se repliciraju podaci – zahteva visoku raspoloživost i
pouzdanost komunikacione opreme
• asinhrona – odložena (po potrebi) replikacija (automatski ili ručno)
• Sa stanovišta načina osvežavanja
• sa brzim osvežavanjem – propagacija promena
• sa kompletnim osvežavanjem – osvežavanje cele replikacione kopije
• Sa stanovišta sinhronizacije operacija osvežavanja
• serijska – isti redosled operacija kao na osnovnim tabelama
• paralelna – dozvoljava se izmena redosleda operacija

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 12

 Asinhrona replikacija

• Asinhrona replikacija uvodi vremensko kašnjenje u ažuriranju delova DS

• Kod asinhrone replikacije može doći do kolizije ažuriranja – kopije istih
podataka mogu biti različito ažurirane u različitim delovim DS
• Kolizija integriteta entiteta – upis na dva mesta istim ključem
• Kolizija brisanja – brisanje na jednom i ažuriranje na drugom mestu
• Kolizija modifikacije – modifikacija istih obeležja na dva mesta
• Može doći do privremene ili trajne globalne nekonzistencije replika
• DEF: Konvergencija podataka je mogućnost vraćanja nekonzistentnih
podataka u konzistentno stanje

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 13

 Asinhrona replikacija – 2

• Asinhrona jednosmerna replikacija

• dozvoljeno ažuriranje podataka samo na jednom mestu
• ne dolazi do kolizija ažuriranja
• nekonzistentnosti su privremene i ograničene trajanjem intervala između dva
osvežavanja replikacionih kopija
• postupci asinhrone jednosmerne replikacije garantuju konvergenciju podataka
• Asinhrona simetrična replikacija
• dozvoljeno ažuriranje istih podataka na više mesta
• može doći do kolizije ažuriranja
• može doći do trajne globalne nekonzistentnosti koja nije ograničena vremenom
osvežavanja replikacionih kopija
• ne garantuje konvergenciju podataka
• mehanizmi garantovanja konzistencije podataka: preventivni i korektivni

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 14

 Prevencija preko prava ažuriranja

• Ekskluzivno pravo ažuriranja

• Tačno jedan proces ima pravo ažuriranja „originala“ i/ili replikacionih kopija
• Nije dozvoljen prenos prava ažuriranja na drugi proces
• Dinamičko pravo ažuriranja
• Tačno jedan proces ima pravo ažuriranja u jednom trenutku vremena
• Dozvoljen prenos prava ažuriranja na drugi proces
• Deljeno pravo ažuriranja
• Ne postoje ograničenja na prava ažuriranja podataka
• Jedino kod deljenog prava ažuriranja može da dođe do nekonzistentnosti

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 15

 Korekcija – otkrivanje kolizija

• Postupak korekcije nakon detekcije kolizije ažuriranja se sprovodi na

• polaznom serveru gde je nastala promena
• ciljnom serveru na koji se promena propagira
• Svaka otkrivena kolizija se evidentira
• Mehanizmi za razrešavanje kolizija
• kolizija integriteta entiteta – generiše se nova vrednost ključa ili se stornira
naredba
• kolizija brisanja – stornira se naredba
• kolizija modifikacije – izbor vrednosti koja će se uzeti je administrativna odluka.
Moguća pravila: prepiši, odbaci, zapiši aritmetičku sredinu, itd.

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 16

 Tipovi propagacije promena

• Promena izazvana operacijom upisa se propagira u replike

• Propagacija obaveštenja o nastalim promenama
• Navodi se koji deo (opisa) podatka je promenjen
• Osvežavanje se inicira pristupom zastarelim podacima
• Radi dobro kod velikog broja promena, tj. kada je odnos operacija čitanja i
ažuriranja (Read/Write = R/W) mali
• Može da optereti mrežu – zbog velikog broja dojava
• Prenose se podaci sa kopije na kopiju
• Korisno je kada je odnos R/W velik, npr. velik broj klijenata i retke izmene
• „Beleži“ promenjene podatke i njih šalje u replike
• Pogodno je pakovanje više promena u jednu poruku
• Prenose se operacije (koje prave izmene) sa kopije na kopiju
• Slanje operacija koje će u kopijama izazvati istu promenu podataka
• Prenose se i parametri operacija
• Kod složenih operacija nekad je jednostavnije preneti rezultate, tj. podatke

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 17

 Push/Pull protokoli propagiranja promena

• U zavisnosti od odnosa broj operacija čitanja i upisa se bira model

propagiranja promena: push, pull ili lease (hibridni model)
• Push model ili server-based protokol
• Šalje promene u replike nakon izmena, na zahtev replike gde se izmena vrši
• Primenjuje se kada se zahteva visok stepen konzistencije, npr. identične replike
• Efikasan kada je R/W odnos visok u svakoj replici
• Pull model ili client-based protokol
• Promene se propagiraju u replike na njihov zahtev
• Efikasan je za mali R/W odnos
• U lease modelu server obećava klijentima (tj. replikama) da će im poslati
promene za zadato vreme propagacije
• Kada lease istekne, klijent ga obnavlja ili nastavlja sa pull modelom
• Ako je trajanje „pretplate“ malo, onda replike mogu fino podešavati tempo
dobijanja izmena – optimizacija zadatog vremena propagacije

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 18

 Epidemic protokol propagiranja promena

• Akcenat je na minimalnom broju poruka koji

se razmenjuje
• Tipično, sve promene se pakuju u jednu
poruku i šalju drugom serveru
• Princip – poput širenja zaraze
• A push promene ka B
• A bira B na slučajan način
• A pull promene od B
• Kombinacija Push-Pull modela
• Slabost ovog algoritma je da neke replike
mogu da ostanu “nezaražene”

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 19

 Raspodela opterećenja

• Engl. Load Sharing and/or Load Balancing

• DEF: Ukoliko se u DS primenjuje replikacija nekog resursa, onda se
ravnomerno opterećenje replika ostvaruje algoritmima za raspodelu
opterećenja
• Uvođenje replikacije resursa u DS je preduslov za deljenje opterećenja
• Raspodela opterećenja u DS se vrši na:
• Procesi
• Komunikacioni linkovi
• Više fizičkih/virtuelnih računara (npr. klaster)
• Unutar računara na procesorima ili uređajima
za skladištenje podataka
• Primeri u DS gde se primenjuje raspodela
opterećenja: „farme“ web servera, DNS serveri,
baze podataka

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 20

 Raspodela opterećenja – Round robin

• DEF: Round-robin (RR) omogućava raspodelu

opterećenja između korisnika usluga DS uvođenjem
vremenskih prozora kratkog trajanja (tzv. kvantum)
u kojima se resursi DS (npr. procesor) ciklično
dodeljuju korisnicima
• U opštem slučaju su svi korisnici istog prioriteta i
redom dobijaju resurse DS
• Round-robin DNS
• Domain Name System zapis za određeni domen (npr.
www.blic.rs) se podesi da pokazuje na više IP adresa
• Klijenti biraju neku od dostupnih IP adresa
• Primeri: raspodela opterećenja na CPU, slanje
saobraćaja kroz deljeni komunikacioni kanal

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 21

 Napredna raspodela opterećenja

• Napredni algoritmi za raspodelu opterećenja koriste razne metrike u DS u

procesu odabira resursa koji će opslužiti određene zahteve korisnika
• Moguće statičke metrike koje se koriste od strane ovih algoritama:
• Geografska lokacija resursa
• Hardverske mogućnosti resursa, npr. broj jezgara CPU i raspoloživa radna memorija
• Status resursa (ON/OFF) – utvrđuje mehanizmom prozivanja (engl. polling)
• Moguće dinamičke metrike koje se koriste od strane ovih algoritama:
• Prioritet zahteva
• Opterećenje raspoloživih resursa, npr. servera, komunikacionih kanal, itd.
• Najkraće vreme odgovora na zahteve u (kratkoročnoj) prošlosti
• Broj aktivnih zahteva koje resurs opslužuje
• Hitnost i/ili bliskost vremena do kojeg zahtev mora da se obradi
• Primeri: FIFO, zahtev sa najbližim „rokom“ prvo, najkraće proračunato vreme
trajanja obrade, geografski najbliži, itd.

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 22

Arhitektura distribuiranih sistema

MODELI KONZISTENCIJE

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 23

 Konzistencija

• DEF: DS je konzistentan kada su replike poravnate

• U opštem slučaju je „sistem“ konzistentan kada ne sadrži kontradikcije
• Konzistencija se razmatra na sledećim tipovima skladišta podataka:
• Deljena memorija
• Deljena baza podataka
• Deljeni fajl sistem
• Skladište podataka u DS može biti distribuirano na većem broju fizičkih ili
virtuelnih računara
• U opštem DS replikacija je „šira“ od podataka, i može da se odnosi i na
procese (tj. programe koji se izvršavaju), ljudske resurse koji mogu izvršavati
određeni tip posla u DS, dokumenta (kao podtip podataka), itd.
• Tipovi operacija nad resursima u DS:
• Čitanje – pristup bez izmene – nije potrebna replikacija
• Pisanje – pristup sa izmenom sadržaja – potrebna replikacija

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 24

 Model konzistencije

• DEF: Model konzistencije je dogovor između korisnika i vlasnika skladišta

podataka, koji propisuje način rada kako skladišta, tako i korisnika
• Ako korisnik poštuje propisana pravila pristupa
• Skladište podataka će biti konzistentno
• Kada proces A pristupa entitetu E u distribuiranom sistemu, onda očekuje
da pristup ostvari sa ažurnim E, tj. da je na njemu primenjena hronološki
poslednja operacija pisanja
• Izazov: ako ne postoji globalni časovnik u DS, onda je otežano određivanje
poslednje operacije pisanja
• Osnovni modeli konzistencije
• Kontinualna konzistencija
• Konzistentan redosled operacija

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 25

 Modeli kontinualne konzistencije

• Postoje razni modeli kontinualne konzistencije u kojima se postavljaju različiti

ciljevi koje treba da zadovolji sistem propagacije izmena:
• Dozvoljene razlike u numeričkim vrednostima između replika
• Razlika se izražava apsolutno (0.01$), ili relativno (0.1%)
• Primer: vrednosti merenja u sistemu za nadzor se stalno menjaju zbog prisutnog šuma,
ali merni uređaji imaju konačnu tačnost
• Primer: vrednosti akcija na različitim berzama
• Maksimalno dozvoljena odlaganja osvežavanja podataka
• Definiše se period u kome se smatra da je replika konzistenta iako se tokom tog perioda
događaju promene vrednosti
• Primer: merenja se očitavaju brže nego što je klijentu potrebno
• Dozvoljene razlike u redosledu operacija
• Definiše se maksimalan dozvoljen broj privremenih zapisa (promena) u serveru koji
čekaju na sinhronizaciju sa serverima ostalih replika
• Conit = consistency unit – jedinica konzistencije, npr. vrednost jednog merenja
• Koristi se za merenje konzistencije
• Merenje dozvoljava formiranje gore navedenih kriterijuma

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 26

 Konzistentan redosled operacija

• Model konzistentnog redosleda operacija je osnova za brojne modele

konzistencije među kojima su:
• Sekvencijalna konzistencija obezbeđuje da se sve operacije pisanja svuda vide
u istom redosledu
• To ne mora biti prema apsolutnom vremenu nastanka operacija
• Često se implementira u praksi
• Uzročna (kauzalna) konzistencija obezbeđuje da operacije koje potencijalno
zavise jedna od druge moraju biti primenjene prema zahtevanom redosledu
• Npr. primena operacije B zavisi od (prethodne) uspešne primene operacije A
• Za operacije koje nisu zavisne redosled primene u replikama nije bitan
• „Labaviji” od sekvencijalnog modela konzistencije
• Još slabiji modeli konzistencije se odnose na serije read i write operacija koje
su omeđene operacijama na sinhronizacionim promenljivima (poput
zaključavanja)

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 27

Arhitektura distribuiranih sistema

ALGORITMI I KONZISTENCIJA

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 28

 Distribuirana transakcija

• (Najčešći) Cilj: atomsko ažuriranje podataka ili konfiguracije celog ili dela DS
• Atomsko = podatke promeniti kod svih ili kod nikoga
• Učesnici: procesi i skladišta podataka
• Osnovne pretpostavke:
• Procesi i komunikacioni kanali nisu pouzdani
• Transakcija se primenjuje u celosti na svim elementima ili nigde
• Učesnici transakcije formiraju usmereno stablo
• Postoji koordinator primene transakcije
• Osnovni način rada:
• Koordinator direktno ili indirektno kontaktira sve elemente
• Koordinator u dva ili više koraka izdaje komande na osnovu kojih elementi
primenjuju nove podatke ili ih odbacuju
• Primeri: 2 phase commit (2PC), 3 phase commit (3PC)

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 29

 Distribuirana transakcija

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 30

 2PC – Faza pripreme

• Primena distribuirane transakcije preko 2 Phase Commit (2PC) se sastoji od

dve faze: priprema i realizacija
• Koordinator transakcije ima sledeće zadatke
• šalje svim ostalim serverima poruku tipa PREPARE i očekuje njihove odgovore
• u slučaju poništavanja šalje svim serverima ROLLBACK i poništava transakciju u
celini
• Proces P primi poruku PREPARE
• utvrđuje da li se njegov deo transakcije može potvrditi i šalje odgovor tipa
ROLLBACK ili PREPARED
• ako dobije poruku tipa ROLLBACK, onda poništava svoj deo transakcije i šalje
potvrdu da je u tome uspeo

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 31

 2PC – Faza realizacije

• Na fazu realizacije završetka globalne transakcije se prelazi ako koordinator

dobije pozitivan odgovor (PREPARED) od svih servera u stablu
• Zadaci koordinatora u fazi realizacije:
• šalje se svim procesima poruka COMMIT
• ako dobije pozitivne odgovore od svih onda potvrđuje transakciju u celini
• ako dobije ijedan negativan odgovor, šalje svim procesima poruku ROLLBACK i
poništava transakciju u celini

• Komande:
• PREPARE – priprema primene
• ROLLBACK – otkazivanje primene
• COMMIT – primena

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 32

 2PC – Analiza

• Dobre strane:
• Atomičnost
• Mali broj tipova poruka i razmenjenih poruka
• Loše strane:
• Ispad koordinatora
nemogućnosti završavanja transakcije i podaci i/ili
konfiguracija mogu da ostanu u nekonzistentnom stanju
• Trajni ili privremeni otkaz resursa DS obuhvaćenih globalnom transakcijom

beskonačno odlaganje na odgovor
resursi DS su zaključani (zauzeti) i druge
transakcije ne mogu da im pristupe
• Trajni ili privremeno gubitak poruke

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 33

 2PC – Mehanizmi za oporavak

• Automatski oporavak od greške u transakciji

• moguć u slučaju kratkotrajnih zastoja
• komponenta ispada se vrati u zadovoljavajuće kratkom vremenu
• globalno uništavanje transakcije i njeno ponovno pokretanje (opciono)
• nastavak transakcije od mesta gde je prekinuta
• Unilateralni (nasilni) završetak nerazrešenog dela transakcije
• vrši se ručno od strane administratora u cilju oslobađanja zaključanih resursa
• rizik dovođenja DS u nekonzistentno stanje
• Dovođenje DS u konzistentno stanje nakon unilateralnog završetka nakon
vraćanja komponente ispada
• globalno storniranje unilateralno završene transakcije i, eventualno, njeno
ponovno pokretanje
• lokalno storniranje potvrđenog dela transakcije
• ponovno pokretanje lokalnog dela transakcije

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 34

 3PC

• Algoritam primene globalne transakcije u tri faze je otporniji na ispad

koordinatora tokom faze primene (tj. druge faze 2PC)
• Engl. Three Phase Commit – 3PC
• Pretpostavke:
• Proces P je koordinator distribuirane transakcije
• Ostali procesi formiraju usmereni, aciklični matematički graf
• Način rada:
• Proces P šalje poruku PROVERA i čeka potvrdu od svih podređenih procesa.
Transakcija se prekida ako se ne prime sve potvrde za zadato vreme (timeout)
• Po prijemu svih potvrda P šalje poruku PRIPREMA svim podređenim procesima.
Transakcija se nastavlja ako se ne dobiju sve potvrde za zadato vreme.
• Po prijemu svih potvrda ili isteka timeout-a P šalje poruku PRIMENA. Po
prijemu svih potvrda se transakcija primenjuje. Ako na nekom podređenom
procesu dođe do isteka timeout-a, transakcija se prekida.

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 35

 3PC

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 36

Arhitektura distribuiranih sistema

REPLIKACIJA I KONZISTENCIJA NA
INTERNETU

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 37

 Replikacija i konzistencija (1)

• Replikacija web hosting sistema, tj. servera HTTP dokumenata

• #1: estimacija opterećenja
• #2: detekcija anomalija, tj. kada i kako kreirati/ukloniti replike?
• #3: implementacija mera, tj. izmene u replikama
• Merila koja se uzimaju u obzir tokom estimacije opterećenja:
• Kašnjenje akcija, npr. vreme HTTP Get zahteva
• Dostupni propusni opseg i opterećenje komunikacionih kanala
• Prostorna udaljenost – uglavnom se meri u hop-ovima, tj. broj rutera na putanji
kroz Web
• Konzistencija replika, tj. koliko često i zbog čega se razlikuju replike
• Finansijska metrika, tj. cena koštanja skladištenja, procesiranja i slanja
dokumenata
• Odlučivanje je npr. moguće na osnovu periodičnog očitavanja metrika

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 38

 Replikacija i konzistencija (2)

• Mogući tipovi anomalija koje utiču na odlučivanje o tome da se replike

uvedu ili ukinu:
• Postepeni porast ili pad interesovanja za određeni Web sadržaj u nekom delu
sveta
• Flash crowd = pojava naglog porasta interesovanja za određeni Web sadržaj,
npr. određena Web stranica
• 3 mere koje je moguće implementirati:
• Izmena lokacije replika
• Izmena politike koja upravlja nivoom konzistencije replika
• Izmena politike preusmeravanja zahteva klijenata (kada? kako?)
• 3 načina preusmeravanja klijentskih zahteva
• TCP handoff, tj. predaja TCP konekcije – uglavnom u klasterima
• DNS redirekcija – preusmeravanje na repliku što „bliže“ korisniku
• HTTP redirekcija – server preusmeri klijenta na drugi dokument kroz odgovor
na Get komandu

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 39

 Content Delivery Network

Tradicionalni pristup CDN pristup

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 40

Arhitektura distribuiranih sistema

REPLIKACIJA I KONZISTENCIJA U
SMART GRIDU

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 41

 Replikacija i dostupnost

• Primarni cilj replikacije resursa u kritičnim infrastrukturama je povećanje

dostupnosti
• Sekundarni cilj replikacije je dostizanje adekvatnog nivoa performansi
• Nivoi replikacije u okviru Smart Grid sistema:
• Kontrolni centri – više kontrolnih centara, tj. zgrada, između kojih treba da postoji
propisana geografska udaljenost (npr. 80 km) – uvode se za rešavanje otpornosti na
ispade usled elementarnih nepogoda ili drugih katastrofa
• Infrastruktura – duplirana komunikaciona infrastruktura između i unutar kontrolnog
centra, tj. duplirana mrežna oprema (svič, ruter, firewall) i kabliranje
• Servisi – na dupliranom hardveru (npr. dva odvojena blade servera) se izvršavaju
duplirani servisi unutar kontrolnog centra – ovim se postiže otpornost na ispad
hardvera ili servisa
• Podaci – podaci se čuvaju na više mesta, npr. čuvanje podataka na diskovima u
odgovarajućoj RAID konfiguraciji, replikacija u rezervni kontrolni centar
• Često se primenjuju posebni servisi za replikaciju podataka unutar i između
kontrolnih centara

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 42

 Primeri replikacije

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 43

 Konzistentnost podataka

• Uglavnom se primenjuju tehnike ažuriranja podataka koje su najmanje

podložne pojavi nekonzistentnih podataka, tzv. razilaženja replika
• Sinhrona i jednosmerna replikacija podataka (tj. ne obaveštenja/operacija)
• Do narušavanja konzistentnosti replika ipak može doći usled
• Ispad (procesa) izvora/odredišta podataka
• Ispad procesa za replikaciju podataka
• Ispad komunikacionih kanala
• Konvergencija podataka se postiže:
• Uvođenjem bafera za privremeno čuvanje podataka ili operacija kod
kratkotrajnih ispada. Baferi imaju ograničenu veličinu i prepune se i krenu sa
odbacivanjem starijih podataka.
• Ažuriranja cele i većeg dela replike kod dužih ispada. Rešava problem
prepunjavanja bafera.
• U nekim situacijama je automatska konvergencija nemoguća i pribegava se
ručnom poravnanju replika (npr. ispad procesa u drugoj fazi 2PC)

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 44

 Konzistentnost konfiguracije

• Nadzor i upravljanje Smart Grid sistema se vrši preko različitih procesa koji
su integrisani u jedinstven informacioni sistem
• Konfiguracija se sastoji od:
• Verzije softvera
• Konfiguracione datoteke servisa,
• Mrežni model elektroenergetskog sistema,
• Prikazi sistema, konfiguracija tačaka koje se nadziru (npr. ON/OFF status
prekidača, analogna vrednost merenja napona)
• Promena konfiguracije takvog IS se često mora vršiti sinhrono, tj. da se nova
konfiguracija primeni u svim procesima ili nigde
• Sinhronizovanu promenu konfiguracije je moguće uraditi primenom 2PC

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 45

 Konzistentnost planiranih radova

• Planirani radovi su npr. radovi na širenju energetske infrastrukture, zamena

transformatora, zamena vodova/kablova
• Konzistentnost izvođenja planiranih radova u više faza uz maksimalno
poštovanje principa podele odgovornosti:
• Korisnik A napravi plan radova (npr. redosled ON/OFF operacija rasklopa)
• Korisnik B proveri i odobri/odbije kreiran plan
• Korisnik C izvrši rad preko sistema za kontrolu i nadzor
• Nijedan korisnik nema sva
prava za kreiranje,
odobravanje i izvršavanje
planiranih radova

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 46

 Rezime

• Osnovne definicije
• Upravljanje replikama
• Tipovi replika
• Protokoli za propagaciju promena u replike
• Modeli konzistencije
• Kontinualna konzistencija
• Konzistentan redosled operacija
• Primeri:
• Replikacija i konzistencija na Internetu
• Replikacija i konzistencija u Smart Gridu

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 47

Elektroenergetski softverski inženjering

Hvala na pažnji!

Primenjeno softversko inženjerstvo – Arhitektura distribuiranih sistema - 2017 48