Distribuerede systemer på CBS, 21. september 2016 - skaberbarhed

Slides til undervisningen i distribuerede systemer på CBS d. 21. september 2016 omhandlende skalerbarhed.

Transcript

1. Velkommen til min undervisning. Distribuerede systemer på CBS, september 2016, diverse papers
2. kt@tdmn.co. Skriv til mig, hvis I har brug for hjælp.
3. Her ses kernen i Mac OS X 10.11.6.
4. Her ses kernen i Mac OS X 10.12.
5. Hvilket programmeringssprog skal man vælge til klienten? Det er et godt spørgsmål!
6. Der findes jo et kæmpe udvalg af programmeringssprog - ovenstående er slet ikke dem alle.
7. Hvis jeg skulle vælge… Bum, bum, bum.
8. Vi skal tale om skalering. Et emne som bør optage alle, der laver services, der bruges af mange. Og så er det et buzzword.
9. Cluster-Based Scalable Network Services, Lessons from Giant-Scale Services og The Google File System. Sådan. Tre artikler, som vi skal tale om i dag - to af dem er fra Berkeley-universitetet.
10. Hvad er skalering? Kom med et par friske bud!
11. Den korte version. Scalability, a computer's or network's ability to function as the number of users increases.
12. Det er for så vidt et generelt begreb, der fx også dækker virksomheder, trafik og meget mere. Tænk fx på ringbanen, som er skalering af den offentlige transport.
13. Et citat fra 1965 af Fernando J. Corbató og Victor A. Vyssotsky. Such systems must run continuously and reliably 7 days a week, 24 hours a day and must be capable of meeting wide service demands. Because the system must ultimately be comprehensive and able to adapt to unknown future requirements, its framework must be general, and capable of evolving over time.
14. Hvornår har I sidst oplevet noget, der ikke fungerede? Prøv at tænke over det.
15. Når noget skalerer, så fungerer den samme service på den samme måde når antallet af brugere og udbuddet af hardware stiger. Og det foregår som minimum lineært.
16. Når en service er tilgængelig, så skal den være det hele tiden på trods af fejl i hardware eller software. Hvis en service går ned, så er den jo ikke tilgængelig - available - mere.
17. Når en service skal kunne betale sig, så skal det ikke koste en milliard at udvide med flere servere. Det er også en skaleringsparameter.
18. Bemærk at de nævner clusters of workstations i deres skriv. Hvorfor nævner det specifikt workstations, altså almindelige arbejdscomputere?
19. Det her er ikke et cluster of workstations.
20. Det her er heller ikke et cluster of workstations.
21. Tænk på hvordan det var engang og hvordan det er nu. Mainframe Cluster
22. Clusters er smarte fordi de skalerer, tilsammen er pålidelige og er relativt billige at bygge. Det er derfor vi godt kan lide clusters.
23. Husk at det ikke betyder at alle computere i et cluster er pålidelige. Det betyder det netop ikke. Blot lige en påmindelse.
24. Couch? Cluster of unreliable commodity hardware.
25. Sidstnævnte ord er interessante at bide mærke i. To summarize, clusters have significant advantages in scalability, growth, availability, and cost. Although fundamental, these advantages are not easy to realize.
26. Jeg nævnte Folding@home sidst.
27. Hvis alt er godt med clusters, hvorfor så ikke bruge dem til alle systemer? Et relevant spørgsmål. Der må jo være en bagside af medaljen…
28. Det kan være besværligt at vedligeholde et cluster, fordi man skal holde styr på mange servere. Eller administrere et cluster, med andre ord.
29. Det er ikke altid muligt at have en hel service (system) spejlet på hver enkelt server i et cluster. Dermed kan man tvinges til at opdele sit cluster, så forskellige servere har forskellige opgaver.
30. Det er ofte en udfordring for alle servere i et cluster at blive enige om en værdi, en fælles sandhed. Det er en udfordring at skabe shared state, som der står i artiklen.
31. Soft state kunne fx være logging af hændelser med henblik på genskabelse af selvsamme ved fejl. Soft state, which can be regenerated at the expense of additional computation or file I/O, is exploited to improve performance; data is not durable.
32. Fault-tolerance er et centralt begreb i distribuerede systemer. Det er evnen til at håndtere fejl, når tingene går ned. For det gør de - ofte!
33. At være fejltolerant, så at sige, handler om at spejle data flere forskellige steder og dermed gøre data tilgængeligt fra forskellige kilder. Det er evnen til at håndtere fejl, når tingene går ned. For det gør de - ofte!
34. Hvordan gør man data tilgængeligt fra forskellige kilder? Det kan fx gøres via sharding eller replication. Og hvad går det så ud på?
35. Okay, okay. De er jo ikke dødsfjender, men de repræsenterer forskellige tilgange. vs.
36. Vi kan ikke gå videre uden at vende Amazon.
37. Hvorfor tror I at Amazon har servere, som I kan leje? Prøv lige at tænke over det en gang. De sælger jo bøger og film og så videre?
38. Det er på grund af julen - hvor hyggeligt!
39. 100.000.000.000 rækker i deres database. Puha. Amazon har købt meget udstyr - og har været nødt til at skifte fra SQL til NoSQL.
40. Det bringer os videre til det, der sker når man oplever meget aktivitet: bursts. Det har I uden tvivl oplevet før.
41. Tænk på Billetnet eller ticketmaster, som jo købte dem.
42. I kender det også fra SKAT og deres hjemmeside.
43. Load balancing. SKATs løsning er et udtryk for et forsøg på at skabe balance i tingene.
44. Den finder ud af hvilken server, der skal modtage en forespørgsel. Server 1 Server 2 Server 3 Server 4 Load balancer
45. Caching er kunsten at gemme noget, som man sender til andre uden at opdatere det hver gang. facebook og jeres venner derinde er et godt eksempel på det.
46. Man kan cache stort set alt, fx blogindlæg, udregninger af visninger på YouTube eller bankinformationer. Det er normal praksis ikke at lave SQL-kald i en database ved hvert page load.
47. Jeg er gået ind på cbs.dk her.
48. Jeg er gået ind på cbs.dk her.
49. Jeg er gået ind på cbs.dk her.
50. Husk i øvrigt at Internettet jo bare er det her.
51. Pause.
52. Det skal vi tale om nu. Giant-scale services.
53. Google er et godt eksempel.
54. facebook er også.
55. Vidste I i øvrigt at det oprindelige facebook-logo er lavet af en dansker?
56. Overordnet set. Når vi taler om giant-scale services, så består de ofte af klienter, et netværk, load balancers, servere og fysiske datalag.
57. Det betyder at de helst ikke må gå ned. Hvordan undgår man så det? Vi er afhængige af giant-scale services hver dag og vi er afhængige af at de fungerer som de skal.
58. Hvis der er 2 milliarder mennesker om 1 server hos facebook, så bliver det stramt. Skalering går blandt andet ud på at fordele forespørgsler, så der ikke kun er en enkelt server, der laver det hele.
59. Husk at en algoritme er en måde at gennemløbe data på. Round-robin-algoritmen blev for alvor populær med DNS-systemet, som gjorde sit indtog i 1995.
60. Hvad er det nu de er for nogle størrelser? Lad os lige tale om algoritmer.
61. Metoderne til afvikling af noget, der er scheduleret. First-In-First-Out er den mest simple form for scheduling, hvor instruktioner afvikles i den rækkefølge, som de modtages i. Shortest-Remaining-Time afvikler instruktioner, der tager kortest tid, først. Det kan resultere i starvation af længerevarende processer. Round-Robin giver alle instruktioner en del af den samlede CPU- tid. Hvis en instruktion ikke når at blive færdig indenfor tidsrammen, så går turen videre til den næste.
62. Der må være en, der har et godt bud. Hov, jeg nævnte DNS. Hvad er det nu lige at det er?
63. DNS beror på store mængder caching og load balancing. www.cbs.dk 130.226.47.28
64. Prøv at skrive dk. i jeres browser.
65. Man kan nemlig ikke få det hele, når man skal skalere et distribueret system. Decide on your availability metrics.
66. Det hedder også Brewer’s theorem. Der findes et teorem, som man ofte støder på i distribuerede systemer. Consistency, Availability & Partition tolerance.
67. For en god ordens skyld. Consistency = alle data er ens. Availability = alle data er tilgængelige. Partition tolerance = alle data kan overleve nedbrud.
68. Man kan ikke få det hele… Hvilket kunder altid gerne vil.
69. Det er klogt at tage højde for at verden ikke er perfekt. High availability betyder at et distribueret system er bygget til at fejle.
70. Vi skal tilbage til Google.
71. De vil jo gerne vide alt om alle i verden. Hvordan gør de det? Hvad er Googles største udfordring?
72. Her bruger man låsemekanismer i mindre systemer, men i større… Det er et problem når der er flere, der gerne vil gemme noget data på samme tid det samme sted.
73. Hov, hvad er race conditions? GFS provides an atomic append operation called record append. In a traditional write, the client specifies the offset at which data is to be written. [..] In a record append, however, the client specifies only the data. GFS appends it to the file at least once atomically (i.e., as one continuous sequence of bytes) at an offset of GFS’s choosing [..]. This is similar to writing to a file opened in O_APPEND mode in Unix without the race conditions when multiple writers do so concurrently.
74. Nu kører det stærkt! Eller. Race conditions opstår når der går kuk i hvilke værdier, der er tilgængelige hvornår.
75. Fx master og chunk operations. Google File System bygger på en lang række koncepter, der kombineres med hinanden for at skabe en løsning.
76. Det svarer fuldstændig til at I mister hukommelsen og genfinder den ved at læse jeres dagbog. Bemærk at de nævner fast recovery som noget, der sker på baggrund af data, der er gemt et sted.
77. Apache Hadoop er meget populært i big data-kredse.
78. At skalere noget er et spil om procenter. Jo større et system, jo mindre chance for nedbrud. %
79. Det kommer an på hvad der er tale om. Hvordan skalerer man så mindre systemer?
80. Kan man skalere en bærbar computer?
81. Og hvad med en server?
82. Det er den ene type. Vertikal skalering er når man opgraderer en computer ved at give den en større processor, mere hukommelse og så videre.
83. Det er den anden type. Horisontal skalering er når man opgraderer en service ved at sætte to eller flere servere sammen i et cluster.
84. Et trickspørgsmål? Hvis en klient læser data fra fire database-servere, som er spejlet, går det så hurtigere end hvis der kun var en database-server?
85. Endnu et trickspørgsmål? Hvis en klient skriver data til fire database-servere, som er spejlet, går det så hurtigere end hvis der kun var en database-server?
86. Og igen. Kan man blive ved med at skalere vertikalt?
87. Og et sidste. Kan man blive ved med at skalere horisontalt?
88. For en god ordens skyld. Opsummering.
89. Jeg glæder mig til at se jer næste gang. Tak for i dag!