Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Distribuerede systemer på CBS, 21. september 20...

Kasper Tidemann
September 20, 2016

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

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

Kasper Tidemann

September 20, 2016
Tweet

More Decks by Kasper Tidemann

Other Decks in Education

Transcript

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Bemærk at de nævner clusters of workstations i deres skriv.

    Hvorfor nævner det specifikt workstations, altså almindelige arbejdscomputere?
  9. Clusters er smarte fordi de skalerer, tilsammen er pålidelige og

    er relativt billige at bygge. Det er derfor vi godt kan lide clusters.
  10. Husk at det ikke betyder at alle computere i et

    cluster er pålidelige. Det betyder det netop ikke. Blot lige en påmindelse.
  11. 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.
  12. 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…
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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!
  18. 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!
  19. 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å?
  20. 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?
  21. 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.
  22. Det bringer os videre til det, der sker når man

    oplever meget aktivitet: bursts. Det har I uden tvivl oplevet før.
  23. Den finder ud af hvilken server, der skal modtage en

    forespørgsel. Server 1 Server 2 Server 3 Server 4 Load balancer
  24. 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.
  25. 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.
  26. 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.
  27. 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.
  28. 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.
  29. 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.
  30. 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.
  31. Der må være en, der har et godt bud. Hov,

    jeg nævnte DNS. Hvad er det nu lige at det er?
  32. Man kan nemlig ikke få det hele, når man skal

    skalere et distribueret system. Decide on your availability metrics.
  33. Det hedder også Brewer’s theorem. Der findes et teorem, som

    man ofte støder på i distribuerede systemer. Consistency, Availability & Partition tolerance.
  34. For en god ordens skyld. Consistency = alle data er

    ens. Availability = alle data er tilgængelige. Partition tolerance = alle data kan overleve nedbrud.
  35. 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.
  36. De vil jo gerne vide alt om alle i verden.

    Hvordan gør de det? Hvad er Googles største udfordring?
  37. 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.
  38. 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.
  39. 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.
  40. 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.
  41. 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.
  42. At skalere noget er et spil om procenter. Jo større

    et system, jo mindre chance for nedbrud. %
  43. Det kommer an på hvad der er tale om. Hvordan

    skalerer man så mindre systemer?
  44. 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.
  45. 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.
  46. 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?
  47. 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?