Elektroenergetski softverski inženjering Tolerantnost na otkaze Arhitektura distribuiranih sistema 2018 Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 1
Sadržaj Uvod u otkaze u distribuiranim sistemima Osnovni pojmovi Otkazi Tipovi, uzroci, skrivanje Ispad procesa (servis, klijent) ili komunikacionog kanala Algoritmi i otpornost na otkaze: Detekcija otkaza Oporavak od otkaza Detekcija mrtvih petlji Primeri: Internet, Smart Grid Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 2
Arhitektura distribuiranih sistema OSNOVNE DEFINICIJE Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 3
Osnovni pojmovi 1 DEF: Otkaz(engl. fail)je prekid neke usluge (servisa) u DS Npr. ispad servisa DEF: Greška(engl. error) jedeo stanja DS koji može dovesti do otkaza Npr. gubitak paketa na komunikacionom kanalu DEF: Uzrok greške (engl. fault) dovodi do pojave greške Npr. delimično oštećenje kabla kroz koji je realizovan komunikacioni kanal DS tolerantan na otkaze ima adekvatnu kontrolu uzroka grešaka, tj. maksimalno je otporan na njih Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 4
Osnovni pojmovi 2 DEF: DS je dostupan(available, accessible) kada pruža sve predviđene usluge Osobina DS je da može da bude delimično dostupan Ispad u ne-distribuiranim sistemima (često) dovodi do potpune nedostupnosti DEF: Raspoloživost (availability) je mera dostupnosti DS Npr. DS radi radnim danima, ali ne radi vikendom = 5/7 raspoloživost Raspoloživost sistema sa meri u devetkama, npr. 99.99% raspoloživost DEF: Pouzdan (reliable) DS radi kontinualno bez pojave greške Sistem koji ima ispad jednom dnevno u trajanju od 5 minuta je 0.9965 (tj. dve devetke) dostupan ali nepouzdan jer ima ispad svaki dan DEF: U bezbednom(safe) DS delimičan otkaz ne dovodi do katastrofe Npr. kritičan otkaz u nuklearnom postrojenju može dovesti do katastrofe ukoliko ne postoje odgovarajuće procedure i mere bezbednosti DEF: Održiv (maintainable) DS je moguće (dovoljno brzo) oporaviti nakon delimičnog i/ili potpunog otkaza Teži se ka tome da se u DS ugrade mehanizmi za automatskioporavak Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 5
Otkazi u distribuiranim sistemima DEF: Otkaz dovodi do ispada procesa ili komunikacionog kanala, odnosno narušavanja konzistentnosti podataka u DS Osobina DS je postojanje delimičnog otkaza, koji nastaje kada deo sistema (npr. komponenta, integritet podatka) zakaže Otkaz dela sistema može loše uticati na rad ostatka sistema, ali za neke delove je potpuno nebitan DEF: DS koji je u stanju da se automatski oporavi od delimičnog otkaza je tolerantan na otkaze (eng. fault tolerant) Pretpostavke koje treba da važe nakon (delimičnog) automatskog oporavka DS Pretpostavka I: nisu ozbiljno narušene performanse sistema Pretpostavka II: sistem nastavlja sa radom i pruža barem delimične usluge koje su (barem privremeno) prihvatljive za korisnike Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 6
Arhitektura distribuiranih sistema OTKAZI Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 7
Tipovi uzroka Uzrok greške (fault) dovodi do greške (error), a greška do (delimičnog ili potpunog) otkaza (fail) u DS Tipovi uzroka spadaju u sledeće grupe Prolazni desi se jednom i nestane Prevazilaze se ponavljanjem akcija, npr. ponovno slanje paketa kroz komunikacioni kanal Povremeni dese se sa vremena na vreme Teško se otkrivaju Često koštaju puno resursa, npr. u inženjer danima Trajni postoje dok se ne sprovede postupak oporavka Npr. nevalidni podaci, otkaz hardvera Uzrok greške je često u ljudskom elementu Pogrešno unet podatak usled neodgovornosti ili nedovoljnog treninga uzrok je neodgovornost, odnosno manjak treninga Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 8
Tipovi grešaka u DS DS se sastoji od opreme, ljudi, dokumenata, procesa i komunikacionih kanala Ljudske greške Greške u upravljanju elementom DS, npr. pogrešno unet podataka, slanje robota u provaliju, uzrokovanje pada letelice i sl. Nepoštovanje (pisanih) procedura Greške u fizičkoj opremi Pregrevanje usled neodgovarajućeg dizajna opreme Greške u (softverskim) procesima Nenamerna greška u izvornom kodu procesa, npr. neadekvatna validacija, pisanje van granica bafera Greške na komunikacionim kanalima Gubitak paketa, npr. usled preopterećenja komunikacionog kanala Oštećenje paketa, npr. usled zračenja pored fizičkog medijuma Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 9
Tipovi otkaza 1 Ispad servisa(crashfailure) = element DS postane privremeno nedostupan, iako je do tog trenutka radio pouzdano Otkaz koji je moguće detektovati = servis otkaže i prestane da pruža usluge na način koji ostale komponente DS mogu da detektuju Tihi ispad servisa = ostali elementi DS nisu svesni ispada servisa Otkaz tipa izostanak odgovora(omission failure) = servis ne odgovori na zahtev Servis ne primi zahtev Server ne uspe da obradi zahtev, npr. usled preopterećenja Server ne pošalje odgovor, npr. zbog interne greške Vremenski otkaz(timingfailure) = odgovor na zahtev se kreira izvan predviđenog vremenskog okvira Ako se odgovor pošalje prebrzo, može da dođe do greške u klijentu Najčešće greške ovog tipa su zakasneli odgovori, tj. neadekvatne performanse DEF: U DS otpornom na vremenske otkaze se definišu (barem) najveća dopuštena vremena za izvršavanje pojedinih akcija (timeout) Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 10
Tipovi otkaza 2 Nevalidan odgovor (response failure) = izlaz servisa je nevalidan Npr. slanje pogrešnog rezultata funkcije Npr. pogrešna tranzicija stanja servisa nakon prijema neočekivanog ulaza Arbitraran, ili Vizantijski otkaz je najteži tip otkaza u kojem element DS u slučajnom vremenskom trenutku pređe u neočekivano stanje i generiše neočekivani izlaz Jako otežana detekcija, npr. proces nije ispao, ali generiše nevalidne poruke Često imaju povremeni uzrok, tj. dešavaju se u slučajnim vremenskim trenucima Ime na osnovu Lamport-ovog rada iz 1982. godine "The Byzantine Generals Problem Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 11
Tipovi skrivanja otkaza DEF: Ključna tehnika otpornosti na otkaze je replikacija, tj. uvođenje planirane redundanse, tj. višestrukih kopija elemenata DS Redundantni podaci omogućavaju oporavak nakon prijema podataka sa greškom Npr. ekstra bitovi za oporavak Teoretski omogućava oporavak i kod stalnih grešaka Vremenska redundansapodrazumeva da se akcije po potrebi mogu ponoviti Npr. ponavljanje zahteva kada se ne dobije odgovor od servisa Omogućava otpornost na prolazne greške Fizička redundansa = postojanje više kopija ljudstva, hardvera ili softvera Replikacija hardvera gde je omogućena automatska detekcija ispada i prelazak na rezervu Replikacija procesa (tj. softvera), npr. grupa procesa sa detekcijom ispada i preuzimanjem uloga Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 12
Arhitektura distribuiranih sistema OTKAZI U CENTRALIZOVANIM DS Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 13
Najčešći otkazi u centralizovanom DS Klijent ne može da locira server Npr. ispad komunikacionog kanala i/ili servisa Zahtev klijenta se izgubi Npr. privremeni ispad kom. kanala Server otkaže nakon prijema zahteva Npr. neočekivane vrednosti ulaza ili preopterećenje Odgovor servera se izgubi Npr. privremeni ispad kom. kanala, slično gubitku zahteva Npr. pogrešno podešen firewall koji blokira odgovore Klijent otkaže nakon slanja zahteva Asinhroni zahtev = klijent nastavi sa radom i naiđe na grešku koja prouzrokuje ispad Sinhroni zahtev = mala verovatnoća ispada klijenta Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 14
Otkaz servera 1 Akcije koje servis preduzima tokom prijema zahteva od klijenta Prijem zahteva (Z) Obrada zahteva, npr. štampanje dokumenta (O) Slanje odgovora, tj. potvrde klijentu (P) Nakon prijema Z, servis može da uradi sledeće: P pa O odmah vrati odgovor (npr. kada obrada dugo traje), ili O pa P da prvo završi obradu i da tek onda pošalje odgovor Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 15
Otkaz servera 2 Otkaz server (krah = K) može da se desi u bilo kojoj fazi Z K (O/P) Z O K (P) Z P K (O) Akcije u zagradama, npr. (O) označavaju operacije koje se ne mogu izvršiti Klijent ne može da zna da li je obrada završena ako se desi K Klijent može (ali ne mora!) da ponovo pošalje zahtev nakon detekcije otkaza servera Moguće višestruko izvršavanje obrade Moguće beskonačno ponavljanje neuspešnih zahteva Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 16
Otkaz klijenta Akcije koje klijent preduzima su: Slanje zahteva na server (Z) Čekanje na odgovor (O) Ako klijent otkaže nakon slanja zahteva, onda nije poželjno da se zahtev izvrši Zahtev koji je klijent poslao pre otkaza se zove siroče(orphan) Potencijalni problemi zbog otkaza klijenta Bespotrebno izvršavanje akcija koje troše sistemske resurse Moguće zaključavanje resursa, npr. zapisa u bazi podataka, koji se naknadno neće otključati U slučaju statefulservera će stanje klijenta biti očuvano, npr. sesija klijenta može biti očuvana i nakon ispada Izazov: detektovati otkaz klijenta i obrisati njegovo stanje na serveru Brisanje stanja klijenta je deo oporavka: automatsko (poželjno) ili ručno Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 17
Otkaz komunikacionog kanala Otkaz komunikacionog kanala dovodi do gubitka jedne ili više poruka koje su trebale biti razmenjene Transmission Control Protocol (TCP) omogućava održavanje pouzdanih point-to-point komunikacionih kanala Koristi potvrđivanje prijema (ACK) U nedostatku potvrde prijema radi re-transmisiju U slučaju ispada TCP komunikacionog kanala je potrebno uraditi: Obavestiti obe strane o ispadu Ponovo kreirati komunikacioni kanal U malim grupama procesa (npr. 5 članova) se održavaju komunikacioni kanali između svih procesa, tj. stvara se mesh mreža U velikim grupama procesa je održavanje direktnih veza između svih procesa članica otežano Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 18
Arhitektura distribuiranih sistema ALGORITMI PROVERA INTEGRITETA PORUKA Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 19
Provera ispravnosti poruka DEF: Provera ispravnosti poruka poslatih kroz komunikacione kanale DS se omogućava primenom kodova za detekciju grešaka Omogućavaju detekciju grešaka nastalih u prenosu poruka komunikacionim kanalima usled šuma CRC = CyclicRedundancyCheck Ciklična provera zasnovana na redundansi Check provera ispravnosti poruka Redundancy dodatni podaci pored same poruke Cyclic algoritmi bazirani na cikličnim kodovima Kod CRC-a se ulazni digitalni podatak, tj. niz bitova, deli sa polinomom koji se opiše binarnim brojem x³+x+1 = 1011 Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 20
Arhitektura distribuiranih sistema ALGORITMI U DETEKCIJI OTKAZA Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 21
Osnovne definicije 1 Tipovi ispada na koje je potrebno ugraditi otpornost u DS: Ispad ljudskog elementa, npr. otkaz, bolest, odlazak u penziju Ispad opreme Ispad procesa Vizantijski otkaz je podvrsta i njegova detekcija je otežana Ispad komunikacionog kanala DS otporan na otkaze treba da automatski konvergira ka stabilnom stanju nakon jednog ili više ispada sa spiska iznad Poželjno je da bude podržan automatski i potpun oporavak Ukoliko to nije moguće, ručni oporavak, npr. administrator poravna nekonzistentne podatke i pokre replike DEF: Proces je u vizantijskom otkazu ako generiše izlaze koji nisu u skladu sa njegovom specifikacijom Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 22
Osnovne definicije 2 Konfiguracija DS se sastoji od Konfigurisani broj i tipovi procesa i komunikacionih kanala Konfiguracija svakog procesa, npr. konfiguracioni fajlovi, (lokalne) baze podataka Konfiguracija treba da bude poravnata sa sistemskom arhitekturom DS Stanje DS se sastoji barem od sledećih elemenata Stanje svakog procesa Stanje komunikacionih kanala, tj. poruke u njima u trenutku formiranja stanja DS Tipovi skladišta za čuvanje konfiguracije i stanja DS su: Radna memorija računara (RAM) briše se restartom računara Trajno skladište podataka, npr. hard disk. Od otkaza pojedinačnih hard diskova se štitimo uvođenjem (hardverske) redundanse i replikacije podataka Eksterni medijumi za čuvanje stanja DS, npr. magnetna traka (više TB kapaciteta), optički medijumi (DVD, Blueray) Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 23
Detekcija otkaza DEF: Detekcija otkaza omogućava da grupa procesa detektuje procese (u grupi) koji su otkazali Mehanizmi koji omogućavaju detekciju otkaza: Aktivno = Svaki član grupe periodično šalje poruku I am alive Pasivno = Članovi grupe se periodično međusobno ping -uju Timeout= maksimalno vreme koje sme da protekne u pasivnom mehanizmu detekcije otkaza od trenutka slanja ping -a nekom procesu do prijema odgovora Izazov: ispad komunikacionog kanala može dovesti do pogrešnih odluka, npr. funkcionalan proces se proglasi otkazanim zbog gubitka poruke Kako razlikovati otkaz komunikacionog kanala od otkaza servisa? Pogrešne odluke je moguće izbeći u većim grupama procesa Potencijalno rešenje problema je ograničeno ponavljanje poruka Split-brain problem = zbog ispada komunikacionog linka veći broj procesa preuzme ulogu primarne prelike i odgovara na zahteve klijenata Relevantan i u kontekstu osnovne asinhrone, jednosmerne replikacije (!) Najveća verovatnoća split-brain-a u malim grupama, npr. grupa od dva člana Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 24
Centralizovana detekcija otkaza DEF: Centralizovani postupak detekcije ispada procesa se realizuje na procesu koordinatoru koji periodično proziva sve procese i/ili kojem se svi procesi periodično javljaju Eng. watchdog = pas čuvar nadzire status procesa u grupi i preduzima konfiguracijom zadate akcije ako detektuje ispad Način rada: Koordinator, tj. watchdog periodično poziva procese Ako odgovor nekog procesa ne stigne za predefinisano vreme (zadato u konfiguraciji), onda se proglašava da je ispao Nakon detekcije ispada procesa, koordinator proverava da li je ispad kritičan preduzima predviđene operacije, npr. po potrebi (kontrolisano) spušta i ostale procese i pristupa oporavku sistema Prednosti: Mogućnost detekcije većeg broja ispalih procesa Pouzdana detekcija i oporavak (npr. restart ispalih procesa) Mane: relativno velik broj poruka, ispad koordinatora se mora detektovati na drugi način, npr. eksterni sistem za nadzor stanja tog procesa Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 25
Distribuirana detekcija otkaza DEF: Detektor otkaza je dodatna komponenta procesa P u distribuiranom sistema koja omogućava detekciju otkazanih procesa Način rada: Detektori otkaza kreću sa pretpostavkom, npr. da su svi procesi ispravni Kada proces P primi (kontrolnu ili osnovnu) poruku od procesa Q, taj proces se proglašava ispravnim Ako proces P ne primi nijednu poruku od Q do isteka konfigurisanog timeout-a, onda se Q označava sumnjivim Q se proglašava otkazanim kada P formira konsenzus sa ostalim procesima Ispravan rad detektora otkaza zavisi od minimalnog i maksimalnog kašnjenja poruka na komunikacionim kanalima Detektora otkaza je jako tačan (stronglyaccurate) ako se ispravni procesi nikad ne označavaju sumnjivim Detektor otkaza je slabo tačan(weekly accurate) ako postoji ispravan proces koji nikad neće biti proglašen sumnjivim od strane nekog procesa Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 26
Algoritam konsenzusa 1 U grupi ravnopravnih procesa je potrebno implementirati algoritam konsenzusa koji će omogućiti nesmetan rad DS nakon ispada procesa Uglavnom se razmatra binarni algoritam konsenzusa, gde procesi donose odluku tako što biraju vrednosti 0 ili 1 Zahtevane karakteristike algoritma konsenzusa za detekciju pada procesa: Završetak: na kraju izvršavanja algoritma svi procesi donose odluku (0 ili 1) Dogovor: svi korektni procesi donose istu odluku Validnost: ako svi procesi biraju istu inicijalnu vrednost odluke (0 ili 1), onda se svi korektni procesi odlučuju za istu tu vrednost Ovim se izbegavaju trivijalna rešenja da svi procesi donose odluku 0, odnosno 1 Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 27
Algoritam konsenzusa i vizantijski otkaz Zahtevane karakteristike algoritma konsenzusa za detekciju vizantijskog otkaza: Završetak: na kraju izvršavanja algoritma svi procesi donose odluku (0 ili 1) Dogovor: svi korektni procesi donose istu odluku Validnost: ako svi korektniprocesi biraju istu inicijalnu vrednost odluke (0 ili 1), onda se svi korektni procesi odlučuju za istu tu vrednost Pretpostavke: Vizantijski ispad nije opservabilan, tj. proces u vizantijskom otkazu može da generiše ispravan odgovor tokom izvršavanja algoritma konsenzusa Procesi su ili korektni ili vizantijski od starta Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 28
Arhitektura distribuiranih sistema ALGORITMI U OPORAVKU OD OTKAZA Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 29
Oporavak i stanje DS DEF: Oporavak je proces u kojem se proces vraća u validno stanje nakon otkaza Tipovi oporavka DS Oporavak unazad (backward recovery) na osnovu poznatog, ranijeg stanja DS Oporavak unapred (forward recovery) je moguć ako su poznati svi mogući tipovi grešaka u DS i razvijene su adekvatne mere za njihovo prevazilaženje Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 30
Checkpoint DEF: Checkpointje snimak celokupnog ili delimičnog stanja DS u određenom vremenskom trenutku Omogućava oporavak unazad (backward recovery) Možemo ga posmatrati kao jedan bekap stanja DS, tzv. distribuirani presek stanja DS (distributed snapshot) Moguć prevod na sprski: presek stanja DS Izazov: snimanje checkpoint-a u složenim DS je zahtevan proces Svaki checkpoint zauzima puno prostora u trajnom skladištu podataka Postupak kreiranja checkpoint-a može uticati na performanse DS Tipovi kreiranje checkpoint-ova Nezavisni elementi DS kreiraju svoje lokalne checkpoint-e u nezavisno konfigurisanim vremenskim trenucima Koordinisani svi činioci DS koordinisano kreiraju checkpoint Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 31
Beleženje poruka DEF: Beleženje poruka (message logging) je mera koja omogućava restauraciju stanja DS nakon otkaza nekog elementa Beleže se sve poruke koje utiču na stanje DS Pretpostavljamo da je ponašanje DS determinističko, tj. da nakon prijema poruke P u stanju S1 sistem uvek prelazi u stanje S2 Stanja S1 i S2 su globalna Poruka je stabilna ako je snimljena na lokalno, trajno skladište podataka Poruke koje utiču na stanje DS treba da budu stabilne Procesi ne nastavljaju sa radom dok poruke nisu snimljene Proces siroče (orphan process) je proces koji je preživeo otkaz drugog elementa DS (npr. procesa) od kojeg zavisi Tokom oporavka se beleženje poruka koristi u kombinaciji sa checkpointima Krene se od poslednjeg checkpoint-a i ponovo se šalju sve snimljene poruke Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 32
Arhitektura distribuiranih sistema ALGORITMI ZA DETEKCIJU MRTVIH PETLJI Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 33
Detekcija mrtvih petlji (deadlock) DEF: Beskonačno odlaganje se javlja kada zadatak čeka na događaj koji se ne desi, tako da on čeka, čeka (tzv. komunikacioni deadlock) DEF: Deadlockse javlja kada dva zadatka X i Y žele ekskluzivan pristup resursima A i B, ali zahteve ispostavljaju u suprotnom redosledu. X nakon odobrenja pristupa A čeka na odobrenje za B, ali ga ne dobija jer je Y već zauzeo taj resurs (B) i neće ga osloboditi jer čeka da se oslobodi A. Cilj: detekcija mrtvih petlji i beskonačnog odlaganja u DS Učesnici: procesi i komunikacioni kanali DS Pretpostavke: Moguće je kreiranje preseka stanja (tzv. snapshot) DS Moguć je povratak u prethodno, validno stanje DS (npr. restartom procesa) Osnovni način rada: Analiza snapshot-a DS i identifikacija petlji u grafu čekanja Detektovane petlje se prekidaju restartom procesa učesnika Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 34
Graf čekanja Osnovne pretpostavke: U sistemu se održava dinamički, usmereni graf čekanja, u kojem su čvorovi elementi DS (procesi i resursi), a grane opisuju zavisnosti tipa blokira ga Samo neblokirani čvorovi mogu da odobravaju pristup Osnovni način rada: Proces P traži pristup resursu R kreira se grana u:p-r Proces Q traži pristup resursu R kreira se grana v:q-r P dobija pristup R grana u se briše, i dodaje se grana w:q-p P završi obradu na R grana w se briše Q dobija R i R zavisi od Q grana v se briše, grana y:r-q se dodaje Q završi obradu na R grana y se briše grafčekanja je prazan Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 35
Bracha-Toueg algoritam Pretpostavke: U sistemu se kreira graf čekanja Način rada: Zasnovan je na statičkoj analizi trenutnog stanja (snapshot) grafa čekanja Iterativno se identifikuju neblokiraničvorovi i algoritam skida njihove grane iz grafa čekanja Ako se algoritam završi sa praznim grafom čekanja, onda nema mrtvih petlji Ako se algoritam završi tako da ne može da ukloni nijednu dodatnu granu, a skup grana grafa čekanja nije prazan, onda postoje mrtve petlje Komande: REQUEST zahtev za pristup GRANT dozvoli pristup Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 36
Arhitektura distribuiranih sistema OTKAZI NA INTERNETU Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 37
Otpornost infrastrukture Internet infrastruktura se sastoji od rutera i komunikacionih kanala koji ih povezuju Ako se modelira kao matematički graf, onda su ruteri čvorovi, a kom.kanali grane grafa Autonomni sistemi (AS) imaju veći broj fizičkih komunikacionih veza ka drugim AS Veće kompanije, čije poslovanje zavisi od dostupnosti Internet komunikacija takođe imaju veći broj zakupljenih linija, često od različitih pružaoca usluga Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 38
Otpornost u nalaženju putanja Nalaženje putanja (tzv. rutiranje) se vrši u ruterima (tzv. Layer 3 uređaji) Na 3. OSI nivou (Network), odnosno Na 2. TCP/IP nivou (Internet) Border Gateway Protocol (BGP) i rukovanje ispadima: Osnovni mehanizam otpornosti na otkaze je tzv. multihoming, tj. postojanje više statičkih veza između AS. Otpornost na jednostruke ispade čvorova ili grana je automatski. U slučaju većih ispada (više čvorova i/ili grana) se vrši koordinisan, ručni oporavak. Open Shortest Path First (OSPF) i rukovanje ispadima: Održava tri tabele: Neighbor, Topology, Routingpreko više tipova paketa o statusu linkova i o topologiji Kada izostane poruka o statusu linka, ponovo kreira gore navedene tabele Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 39
TCP i otpornost na otkaze TCP ima ugrađen mehanizam za retransmisiju paketa Dupack ako poruka 100 nije primljena, onda šalje Acksa prvom sledećom primljenom porukom, npr. primi 101, šalje Ackza 101 i 100. Pošiljalac ponovo šalje 100 kada primi 3 Ackza tu poruku (tri zbog mogućih promena redosleda poruka). Timeout pošiljalac definiše i postavlja vremenski period u okviru kojeg očekuje da primi Ack. Ako ne primi Ack, ponovo šalje. Brojač se resetuje za svaki Ack TCP checksum je relativno slab mehanizam za proveru integriteta poruka Integritet se često proverava preko Cyclic Redundancy Check (CRC) na L2 Osnovni TCP nije otporan na ispad servera U trenutku ispada servera se TCP konekcija prekida Ukoliko je postoji rezervni server, otvara se nova TCP konekcija Problem: osnovni TCP nema mehanizam za preuzimanje postojeće TCP konekcije Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 40
UDP i otpornost na otkaze User Datagram Protocol (UDP)ne poseduje ugrađene mehanizme za detekciju i oporavak od gubitka paketa UDP aplikacije treba da budu otporne na određen nivo gubitka, grešaka ili duplikacije UDP može (ali ne mora) da generiše checksumu pseudo zaglavlju za proveru integriteta poruke Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 41
Arhitektura distribuiranih sistema OTKAZI U SMARTGRIDU Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 42
Otpornost infrastrukture Rezerva proizvodnje Upetljan prenos Slabo upetljana distribucija Zaštitna oprema Frekvencija Napon Struje kvara Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 43
Replikacija i otpornost na otkaze Primarni cilj replikacijeresursa u kritičnim infrastrukturama je povećanje dostupnosti preko povećanja nivoa otpornosti na otkaze Često je cilj postizanje nivoa dostupnosti 99,99%(ili više) na godišnjem nivou Sekundarni cilj replikacije je dostizanje adekvatnog nivoa performansi Class Availability Annual Downtime Continuous 100% 0 Fault Tolerant 99.999% 5 minutes Fault Resilient 99.99% 53 minutes High Availability 99.9% 8.3 hours Normal Availability 99-99.5% 44-87 hours Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 44
Nivoi replikacije 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 bladeservera) 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, replikacijau rezervni kontrolni centar Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 45
Sistemska arhitektura otporna na otkaze Production (Core) Operator Workstations 10 GPS Training Workstations Instructor 1 Student 5 Switch Switch OASyS RT SCADA (DNP3+ ICCP) Hot & Standby ADMS RT Servers Hot & Standby ADMS Simulation Servers Standalone 2 DMS Calculation Engine High-Performance Cluster 2 RT Historian Hot & Standby Windows HA cluster Domain Controllers OASyS/ ADMS Simulator Server OASyS RT/ ADMS RT Server Historian Corporate User Workstations 50 Data replication Access Services (DMZ) PI Server Firewalls Routers WAN Switch QA & Test Switch OASyS RT SCADA (Replica) ADMS RT Replica Web Server Standalone Load balancing Data replication ADMS Historian Standalone ADMS RT Simulation Standalone 2 Integration & RCS Standalone Domain Controllers OASyS RT SCADA (Replica) ADMS QA Test Server ADMS QA Dev Server Development Stations 4 Web users 500 Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 46
Rezime Uvod u otkaze u distribuiranim sistemima Osnovni pojmovi Otkazi Tipovi, uzroci, skrivanje Ispad procesa (servisa, klijent) ili komunikacionog kanala Oporavak od otkaza Stanje DS Checkpoint Beleženje poruka Primeri na Internetu i u SmartGridu Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 47
Elektroenergetski softverski inženjering Hvala na pažnji! Tolerantnost na otkaze Primenjeno softversko inženjerstvo Arhitektura distribuiranih sistema - 2018 48