Troels Thorsen, - 1
Contents 1 Architectures for Distributed Systems 4 1.1 Software arkitektur.......................... 4 1.2 Centraliseret............................. 4 1.3 Decentraliseret............................ 4 1.4 Layers/Tieres............................. 4 1.5 Overlay-netværk........................... 4 2 Remote Procedure Call + RMI 4 2.1 Communication............................ 4 2.2 How RPC works........................... 5 2.3 Java RMI............................... 5 3 Naming 5 3.1 Flat naming.............................. 5 3.2 Structured naming.......................... 5 3.3 Attribute-based naming....................... 5 3.4 Mobility problem........................... 5 4 Clock Synchronization (physical time) 6 4.1 Time skew............................... 6 4.2 Christensens algorithm........................ 6 4.3 Berkley time............................. 6 4.4 NTP.................................. 6 5 Logical Clocks (Lamport + Vector) 6 5.1 Lamport clocks............................ 6 5.2 Vector Clocks............................. 6 6 Mutual Exclusion and Election 7 6.1 Mutual exclution........................... 7 6.2 Election................................ 7 7 Data-Centric Consistency (Models + Implementations) 7 7.1 Replication.............................. 7 7.2 Consistenct models.......................... 7 8 Client-Centric Consistency (Models + Implementation) 8 8.1 Consistency levels.......................... 8 8.2 Replica management......................... 8 9 Reliable Client-Server Communication 9 9.1 Two-army problem.......................... 9 9.2 OSI stack............................... 9 9.3 Communication types........................ 9 9.4 RPC.................................. 9 9.5 Printing Example........................... 9 Side 2 af 12
10 Reliable Group Communication 10 10.1 Reliable Multicasting......................... 10 10.2 Scaleability.............................. 10 10.3 Atomic multicast........................... 10 10.4 Virtual synchrony.......................... 10 11 Byzantine Agreement 10 11.1 Two army problem.......................... 10 11.2 Agreement in faulty systems..................... 10 11.3 Protokollen.............................. 11 12 Distributed Commit 11 12.1 Two-Phase Commit......................... 11 12.2 Problemer i 2PC........................... 11 12.3 Threee-Phase Commit........................ 11 12.4 Problemer i 3PC........................... 12 Side 3 af 12
1 Architectures for Distributed Systems 1.1 Software arkitektur Layered beskeder propageres ned gennem et lag af komponenter Object komponenter representeres af objecter og forbindes i en graf EventBus beskeder sendes over en bus Data-centered kommunikation gennem et centralt delt lager 1.2 Centraliseret Er en client/server organisation. Fx HTTP.. FTP 1.3 Decentraliseret Alle nodes er lige. Fx chordnetværk 1.4 Layers/Tieres Layers Lagene er logiske; det er hvad vi kender fra software-arkitektur. Fx OSI modellen Tiers Double-tired multi-tired System-arkitektur (det fysiske aspekt af computere) Fx 3-tired webapp: [LoadBalancer ] front appserver Database (3 ting for forskellige servere) 1.5 Overlay-netværk Hvordan man skaber en virtuel sammenhæng af peers på et netværk. Structured peers: Chord-netværk Unstructured peers: Torrent-netværk.. Superpeers 2 Remote Procedure Call + RMI 2.1 Communication In general messageparsing. HTTP TCP IP Ethernetlayer router (unpackes to IP and delegates) Side 4 af 12
2.2 How RPC works Parameterpassing Tag eksempel med incr(i,i) for Call By value, reference og copy/restore for at vise forskellen Marshalling Message broking. Man har et opstilling som alle er enige om, som man oversætter fra og til. 2.3 Java RMI Parameterpassing i RMI CB value: Serializable CB Reference: interfacet Remote Garbage collection 3 Naming Vi vil gerne have fat i resurser; spørgsmålet er så hvordan vi navngiver det. 3.1 Flat naming Tilfældigt navn. Filnavn inode. For at få fat i navnet skal man have et opslagsværk. e.g. en tabel. Brug enten ARP eller et directory som eksempel. 3.2 Structured naming DNS som eksempel. Her er to måder at slå op på: iterativ vs rekursiv. Evt snak om cache poisoning. 3.3 Attribute-based naming Her får man objekter baseret ud fra deres attributter. Man kan få brugeren ud fra deres mail i stedet for deres userid. Lidt som forspørgsler fra SQL. 3.4 Mobility problem Forwarding pointers Homebased approach Tidligere connected access point sender beskeden til enheden og sender derefter en besked tilbage til senderen om at access pointet er ændret. Side 5 af 12
4 Clock Synchronization (physical time) 4.1 Time skew Man får timeskew da amn bruger billigt hardware i form af krystaller. Man skal afgøre hvor stort skew der er tilladt for applikationen, og sørge for synkronisering når skewed overstiger. 4.2 Christensens algorithm Man spørger en (korrekt) central server om tid (GPS) Man sætter lokal til til serverens + RTT/2 (RoundTripTime) Det antages at transport til og fra serveren har samme latancy 4.3 Berkley time Elect en master (med en election algoritme) masteren trækker tiden fra andre peers med christians algoritme. tages hensyn til RTT Der masteren udregner gennemsnittet og sender forskellen tilbage til de andre peers. Grunden til at det er forskellen og ikke den absolutte tid, er for at undgå problemer med RTT 4.4 NTP Cristensen med 5 tries, og så et gennemsnit. 5 Logical Clocks (Lamport + Vector) 5.1 Lamport clocks Happens-before relation Total ordering Global counter using logical clocks 5.2 Vector Clocks Partial ordering between processes (Causal communication) Detection of causality violations Side 6 af 12
6 Mutual Exclusion and Election 6.1 Mutual exclution Centralized lad én peer administrere ressourcer og adgang til dem. Decentralised ligesom centralized, resurser er blot spredt ud som disjoint set over alle peers: DHT af resourses. Distributed Man spørger alle om det er OK at tage en ressource. Token ring peers administreres i en ring, en token sendes rundt, den med en token har ret til resursen (election algortime ved lost token: vigtigt at der kune indsættes én ny) 6.2 Election Det bliver brugt hvis det i systemer skal bruges én og kun en, til at gøre et bestemt job. E.g. oprette en ny token. Bullying algorithm man opdager at der ingen konge er. Derefter spørger man alle med højere id om de er oppe, er de ikke det udnævner man sig selv. Ring algorithm En token sendes rundt, hvi en token indeholder et ID, der er lavere end ens eget, overskriver man med sit eget, hvis den indeholder et ID der er lig ens eget, er man konge. Wireless Opbygger netværket vha MST-lignende algoritme Sender info tilbage til root-noden, som bestemmer den største. Large enviroments - super peer Even distribution (ring topology: use most significant bits of id) 7 Data-Centric Consistency (Models + Implementations) 7.1 Replication Reasons: performance, reliability, availability Propagation 7.2 Consistenct models Continuous consistency Man definere hvor meget replikas må afvige (enheden hedder en conit). Man har 3 metrics at bruge: numerisk afvigelse (kan være antal operation en replika er foran), staleness: Hvor lang tid siden er der opdateret og afvigelse i operationers orden. Side 7 af 12
Replikering sker når et vist antal conits overstiges. Consistent ordering sequential consistency (sekvensiel orden pr. proces) causal consistency (operationer der potentielt har noget med hinanden at gøre, kommer i samme rækkefølge) Entry consistency Låse objekter før der skrives. Sikre at entries er konsistente Eventual consistency Updates propagere ned i replikas før eller siden 8 Client-Centric Consistency (Models + Implementation) Authenticated users ser deres ting up to date. 8.1 Consistency levels Monotonic reads man læser det man har skrevet eller nyere Monotonic write en skriving fra en process er færdig før den næste skrivning fra samme process begynder. (sekevensielt pr process) Read your writes en process ser sin tidligere skrevet værdi (ikke som i monotonic, hvor man kan se nyere, andre kan have skrevet) Write follow reads hvis man læser, og derefter skriver til et object x, vil man skrive til den læste, eller en nyere version 8.2 Replica management Replica placement Replica types Permanent replicas (Mirrors) Server initiated (CDNs, dynamic scaling) Client initiated (caching) Invalidate (tell replicas that data is updated, they delete their data and takes the new on request (typical for caching, no duplication - no faulttolerance) ) Propagate the whole newly updated object Propagate only the changes Content distribution Side 8 af 12
9 Reliable Client-Server Communication 9.1 Two-army problem To hære er blevet enige om at angribe, det skal bare blive enige om hvornår. Problemet består i at modstanderen kan hugge meddeleren når de kommunikerer. Der er derfor ingen af dem der er sikre på at den anden har hørt dens go. 9.2 OSI stack Det er let at skifte komponenter ud, hvilekt sikre højere transportsikkerhed. 9.3 Communication types Transient (HTTP) Persistent (E-Mail) Asynkron Synkron 9.4 RPC Marshalling, serialization Synkron / asynkron RMI Faliure cases: Unable to locate server (not much to do) Request message lost (retransmission) Server Crash (Crash after execution, crash before execution) Solutions: At most one OR at least once executed. Lost Reply (sequence number on requests) Client crashes (Orphans, expiration and reincarnation) 9.5 Printing Example Eksempler på hvor den kan crashe, og hvad man kan gøre for at løse det. Konklusion: Der er ikke nogen perfekt måde at gøre det på. Completion Message (M) Print the text (P) Crash (C) Side 9 af 12
10 Reliable Group Communication 10.1 Reliable Multicasting Basic: Send en besked til alle, og vent på ACK, gensend hvis ingen ACK NACK: Non-Hierarchical Feedback Control, beskeder sendes ud med inkrementerende ID, man man modtager en besked, der har et ID der er mere end 1 højere end sidst modtaget besked, sendes en supress message til alle andre peers. Hierarchical Feedback Control (Coordinators and dynamic tree structures) 10.2 Scaleability Også kendt som non-hierarchical feedback control 10.3 Atomic multicast En besked som bliver multicasted bliver enten modtaget af alle eller ingen. Måske er der en messageordering (FIFO (for each process), Unordered, Causally (blogpost), Totally) 10.4 Virtual synchrony Ping eller heartbeats for crash detection request viewupdate 11 Byzantine Agreement 11.1 Two army problem To generaler skal blive enige om et tidspunkt de skal angribe på Uden en ack fra den anden, tør den ene ikke angribe Problemet opstår ved: Har den anden modtaget min ack? 11.2 Agreement in faulty systems Are possible if we have one of these: Bounded delay - solved by using timeouts to see failures. Ordered multicasting - reliable group communication examples Synchronous, ordered processes - solved by obscure algorithm involving lots of messages Side 10 af 12
11.3 Protokollen Alle sender deres valg ud Man modtager, og putter ind i en receive vektor. Denne vektor sender man ud til de andre Man modtager vektorer fra alle Man skal nu regne en resultatvektor: Du har n vektorer. Du tager den første ingang i alle disse (dog ikke den første vektor) vektorer, og tager majoriteten af disse svar. Det svar bliver så den første ingang i din resultatvektor (.. Du fortsætter så videre for alle indgange) Du har n vektorer. Du tager den n te indgang i alle disse (dog ikke den n te vektor) vektorer, og tager majoriteten af disse svar. Det svar bliver så den n te indgang i din resultatvektor 12 Distributed Commit 12.1 Two-Phase Commit Hovedproblemet er dårlig håndtering af koordinatorcrash. Described by finite-state machine 12.2 Problemer i 2PC Process: Init: timeout abort Process: Ready: Enten Vent på koordinator kommer op igen eller Spøg en anden process hvor han er; hvis han er i: Init: er kun sket hvis koordinatoren er død mens den multicastede: Vi aborter Ready: Kontakt en ny. Hvis alle er i ready, kan vi ikke komme til en konklusion - Problemet med 2PC Commit eller abort: do that Koordinator: Wait: timeout abort 12.3 Threee-Phase Commit View from participant Correctness (Abort and Commit cannot be achieved at a time) Side 11 af 12
12.4 Problemer i 3PC Process: Init: abort, da koordinator nok er død Process: Ready/pre-commit: Enten: Ven på koordinator kommer op igen, eller Spørg andre: Init: er kun sket hvis koordinatoren er død mens den multicastede: Vi aborter Ready Commit- precommit eller abort: do that Koordinator: Wait: Abort, da en process er død Koordinatoer: Pre-commit: Commit; en process er død, men er i readycommit, da han har voted for commit. Recovery sørger for at han eventually comitter. Side 12 af 12