Distribuerede systemer, CBS, 8. oktober 2015

Slides til forelæsningen om arkitektur i distribuerede systemer på CBS d. 8. oktober 2015 kl. 08:00.

Transcript

1. Arkitektur Distribuerede systemer på CBS, oktober 2015 De rigtige papers omkring distribuerede systemer
2. speakerdeck.com/kaspertidemann Mine slides til undervisningen ligger på Speaker Deck.
3. Vi starter lige et andet sted. Vi skal nemlig gennemgå en række papers.
4. Vi starter med en gammel kending, som vi har talt om før. papers( ); Leslie Lamport
5. Teori om generaler, angreb og forrædere. Det er for så vidt en god metafor, selvom den er noget krigerisk.
6. En gruppe generaler med en eller flere forrædere i geledderne! Byzantine Generals’ Problem
7. Ready, set, war! Alle loyale generaler skal være enige om en slagplan. Forrædere må ikke spolere planen.
8. Ergo: for at undgå det, så skal der etableres et beslutningsdygtigt flertal. Beslutningsdygtigt flertal A small number of traitors can affect the decision only if the loyal generals were almost equally divided between the two possibilities.
9. Det stødte vi også på under sidste forelæsning - et quorum. 2/3.
10. Når en general er loyal, så godtager han kun beskeder fra andre loyale. Udfordringer Det nytter ikke at hver general sender samtlige beskeder til alle andre uden videre, for beskederne kan jo forfalskes - og det skaber et værre rod. Derfor er hovedreglen: for hver besked fra en loyal general, der skal alle andre loyale generaler bruge samme besked.
11. Hvad er en consensus vector så? Interactive consistency Når hver proces har sin egen værdi, og når alle processer kommunikerer med hinanden for at afgøre hvilken værdi, der er den korrekte. Der er tale om en række private værdier, der udveksles for at finde en offentlig værdi i den givne consensus vector.
12. En majority-algoritme til at finde ud af hvilken værdi, der er korrekt. majority(v1, …, vn-1)
13. Ofte implementeres en majority-algoritme alene med basis i forekomster. Kort om majority-algoritmer Forekomster Valg af den forekomst af en værdi, der optræder flest af. Sandsynlighed Valg af den værdi, der forekommer mest sandsynlig. Tillid Valg af den værdi, der optræder hos flest med den største tillid. Type Valg af den værdi, der passer med den type som er anvendt.
14. Når vi taler om algoritmer, så er der forskel på dem teoretisk og i praksis (implementeret). Det er blot for at understrege hvad “implementeret” dækker over.
15. En gruppe generaler med en eller flere forrædere i geledderne! Hvis der ingen forrædere er - Klar? - Yes! - Så pyt, da.
16. Når der ingen forrædere er, er tilliden i systemet total. Ingen forrædere, total tillid Hvis der ingen forrædere er, så sender generalen sin besked til alle løjtnanter, som læser beskeden og handler derefter. OM(0) Hvis en løjtnant ingen besked modtager, så falder han tilbage og angriber ikke (fallback policy).
17. Når der er forrædere, er tilliden i systemet begrænset. Flere forrædere, begrænset tillid Hvis der er forrædere, så sender generalen sin besked til alle løjtnanter, som sender beskeden til hinanden. Hvis v er den oprindelige besked og v1 = v2 = v, men v3 = x, så er majority(v, v, x) = v. OM(m) hvor m > 0
18. Ham til højre har ikke rent mel i posen. Ikonografisk v v x v
19. Endelig har vi signed messages, der kan afsløre når noget ikke stemmer overens. Det kan være simple sets med tal, der angiver en signatur.
20. v1 = v Signaturer angrib : 0 angrib : 0 : 1 fald tilbage : 0 fald tilbage : 0 : 2
21. Altså signing via v : i : j og så fremdeles, som afslører hvem der snyder hvem. Det er samtidig en kausalitetsbetragtning.
22. Det er dyrt både i tid og ressourcer at sende alle de beskeder. Første citat af Leslie Achieving reliability in the face of arbitrary malfunctioning is a difficult problem, and its solutions seems to be inherently expensive.
23. Teorien siger altså at der ingen vej er udenom, hvis det skal være godt. Andet citat af Leslie The only way to reduce the cost is to make assumptions about the type of failure that may occur. However, when extremely high reliability is required, such assumptions cannot be made, and the full expense of a Byzantine Generals solution is required.
24. Det betyder at konsensus er dyrt, tager tid og kræver ressourcer. Det kommer ikke uden sin pris, når det bliver implementeret.
25. Jo mere trafik, jo mere diskplads, jo mere CPU-tid, des flere penge til Amazon og Linode. Eller hvem man nu bruger som udbyder. Det kunne også være egne servere.
26. Pause.
27. Så er det på med en snak om konsensus. papers( ); Guerraoui et al.
28. Hey, vi skal tale om transaktioner igen. Og rækkefølgen af dem i distribuerede systemer.
29. Atomic Broadcast Problem er et konsensus-problem. Atomic Broadcast Problem … er et Agreement Problem, der opstår når deltagere i et distribueret system har modtaget en række operationer at udføre, men ikke er enige om rækkefølgen. At vi kender til en rækkefølge er jo netop det, der gør en serie operationer transaktionelle.
30. Processer kan enten være gode, altså til at regne med, eller dårlige, altså det modsatte. Sådan definerer Guerraroui et al. processer i et distribueret system.
31. Der er to primitiver, den ene er propose(), den anden er decide(). En proces kan enten
32. Egenskaber ved Tre vigtige egenskaber Termination Enhver god proces opnår på et tidspunkt enighed (decide()). Agreement Der er ikke to gode processer, der er uenige (decide() != decide()). Validity Hvis en proces beslutter noget, så er det resultatet af en anden proces.
33. Uniform Consensus er når to processer ikke beslutter noget forskelligt. Altså ingen divergerende
34. Rækkefølgen i den form for konsensus, som de taler om i vores paper. Rækkefølge 1. En proces sender en beslutning til afstemning hos alle andre processer. 2. Processen afventer enten ja, nej eller intet svar alt efter omstændighederne. 3. Hvis alle andre processer vender tilbage med et ja, så foretages et commit.
35. Bemærk udtrykket “før eller siden”, der dækker over eventual consistency. Failure detection Strong completeness er når alle dårlige processer før eller siden bliver opdaget af de gode processer. Weak accuracy er når en god proces aldrig bliver mistænkeliggjort af en anden god proces.
36. Det var jo det vi gennemgik til første forelæsning. Omkring heartbeating Note that, in practice, strong completeness can be easily satisfied using "I am alive" messages and timeouts.
37. For overhovedet at tale om konsensus, så antager vi at kommunikationskanalerne fungerer som de skal. Quasi-reliable vs. stubborn channels, der kun sender seneste nyt.
38. Kort og godt. Crash med og uden recovery Hvis konsensus opnås før eller siden, så er spørgsmålet hvorvidt vi kan vente på en proces, der er gået nedenom og hjem. Hvis vi ikke kan det, så er der tale om no recovery. Hvis vi godt kan vente på at processen genskaber sig selv, så er der tale om recovery.
39. Tilbage til logikken omkring genskabelse af transaktioner. Omkring recovery To be able to restore their state when recovering from crashes, processes need to be provided with some sort of stable storage.
40. Og endelig skal vi tale om Raft-algoritmen - den læsevenlige Paxos. papers( ); Ontaro & Ousterhout
41. Tro mig, Paxos er tung læsning. Prøv selv kræfter med den, hvis det er. Først og fremmest: Paxos Paxos er en protokol til distribuering af et system, som er opfundet af - surprise! - Leslie Lamport. Paxos udstikker en række retningslinjer for hvorledes deltagere skal opføre sig for at kunne håndtere nedbrud og opnå konsensus. Paxos er temmelig langhåret læsning.
42. *zzzzzz* Meget teoretisk læsning er sådan, synes jeg.
43. Om lidt kommer der et billede fra Stanford. Om forfatterne Diego Ontaro og John Ousterhout var begge studerende på Stanford University, og de var trætte af al den tunge læsning. Derfor besluttede de sig for at skrive en letvægtsudgave af Paxos, som mundede ud i Raft. Raft er en algoritme til at opnå konsensus via en log, der er replikeret.
47. Joint consensus kaldes også for transitional configuration. Det som Raft bygger på Strong leader Der er altid kun én leder, som sender beskeder ned i rækkerne. Leader election Der foretages valg af en ny leder via tilfældige timers. Joint consensus Clusterets konfiguration kan ændre sig løbende og uden nedbrud.
48. Sådan kort fortalt. Rækkefølge 1. Der vælges en leder, der har ansvaret for den replikerede log her og nu. 2. Lederen modtager operationer til loggen, som så sendes til deltagerne. 3. Deltagerne sørger for at udføre de givne operationer og afspejle resultaterne i deres individuelle state machines.
49. Replicated state machines 1. <operation> 2. <log> 3. <afspejl> 3. <afspejl> Hvordan replikering af state foregår i Raft.
50. En deltager i Raft kan enten være en leder, følger eller kandidat. Ja, eller leader, follower eller candidate.
51. Det har en ret politisk orienteret klang med terms og elections. Er lederen altid den samme? Nej, der skiftes mellem lederen løbende. Forløb i Raft opdeles i terms, der følger en nummerserie. Hver term begynder med en election mellem en række candidates baseret på first-come-first- serve.
52. Heartbeats - der har vi dem igen. Er lederen altid den samme? Nej, for lederen kan jo gå ned af den ene eller anden årsag. Lederen bevarer sin autoritet ved at udsende heartbeats til alle followers, så de ved at lederen stadig er der.
53. Optimistic failure handling. Failure handling Hvis en leder fejler, så afsluttes den nuværende term og en ny påbegyndes med en election. Hvis en følger fejler, så forsøger lederen at sende opgaven om og om igen indtil den er løst - lidt i tråd med recovery-delen af den tidligere konsensus-algoritme.
54. Se mere på http://raftconsensus.github.io Der ligger en visualisering af Raft lavet i JavaScript - ret nifty!
55. Se mere på http://raft.github.io/ Der kan man se Raft visualiseret (dog ikke i Safari).
56. Pause.
57. Spørgsmål til kravspecifikationen. Der er et par detaljer, som jeg gerne vil lægge vægt på.
58. Det handler om distribuerede systemer. Det handler det her om først og fremmest - ikke om et Snake-spil.
59. Klienter og servere. I skal demonstrere viden indenfor den hyppigst anvendte model.
60. Hvad er HTTP? Det skal I fx kunne sige noget om.
61. Blocking og non-blocking. Synkron og asynkron kommunikation - husk det med sockets og “interaktionsmodeller”.
62. Domain Name System. Hvordan virker det egentlig?
63. Offentlige og private nøgler i kryptering. Man kan kryptere med en offentlig og privat nøgle, og læse med den offentlige.
64. Flaskehalse? Sådan helt generelt i et system, der er distribueret.
65. Angreb! Denial of Service, maskering, tampering og så videre.
66. Udvekslingsformater. JSON og XML, for eksempel.
67. Hvordan ser en URL ud? Altså fx protokol://brugernavn:password@adresse/ressource/id.
68. Message queues. Hvordan fungerer sådan en? Hvorfor er den smart?
69. Direkte og indirekte kommunikation. USB-kabler versus publish-subscribe. Ja, eller alt muligt andet.
70. Opsummering. For god ordens skyld.
71. Tak for i dag! For spørgsmål, skriv til mig på kt@tdmn.co.