Distribuerade system

Vår 2021

Översikt

15-440 är en introduktionskurs i distribuerade system. Tyngdpunkten kommer att ligga på tekniker för att skapa funktionella, användbara och skalbara distribuerade system. För att göra frågorna mer konkreta innehåller kursen flera flerveckorsprojekt som kräver betydande design och implementering

Målen för den här kursen är tvåfaldiga. För det första att studenterna ska få en förståelse för de principer och tekniker som ligger bakom utformningen av distribuerade system, t.ex. låsning, samtidighet, caching, prefetching, schemaläggning och kommunikation över nätverket. För det andra ska studenterna få praktisk erfarenhet av att utforma, genomföra och felsöka riktiga distribuerade system.

De viktigaste ämnena i denna kurs är följande:

• Resursbrist, schemaläggning, och samtidighet
• Kommunikationsfördröjning och bandbredd
• Namngivning
• Abstraktion och modularitet
• Imperfekt kommunikation och andra typer av fel
• Skydd mot oavsiktlig och illvillig skada
• Optimism
• Konsensus
• Användning av instrumentering, övervakning och felsökningsverktyg vid problemlösning.
• Utformning, genomförande och felsökning av omfattande programmeringsprojekt som omfattar ovanstående teman

Bedömning

Alt kursarbete görs individuellt. Det finns inga team eller projektpartners. För de personliga kurstillfällena (före COVID och förhoppningsvis även efter COVID) baserades utvärderingen på projekt (45 %), problemställningar (20 %), halvtidsprov (15 %) och slutprov (20 %). På grund av COVID-kraven kommer tentamen att ersättas av kumulativa problemställningar i samband med kursutbudet våren 2021. Dessa är som prov med öppna böcker, men utan tidspress. Som namnet antyder omfattar de allt material som behandlats i klassen fram till dess. Vi kallar de andra problemuppsättningarna för aktuella problemuppsättningar eftersom de fokuserar på ämnen. Så utvärderingen våren 2021 kommer att se ut på följande sätt (alla vikter är ungefärliga, inom ett intervall på 5 %):

• 45 % för 4 projekt, lika viktad
• 20 % för 4 aktuella problemuppsättningar, lika viktad
• 15 % för kumulativ problemuppsättning i mitten av terminen
• 20 % för slutlig kumulativ problemuppsättning.

Lärandemål

Vi förväntar oss att studenterna ska få en djup förståelse, ett flytande resonemang och praktiska implementeringsfärdigheter för följande centrala systemkoncept inom distribuerade system:

1. • Kommunikation och fjärrproceduranrop
   • Kontrollsemantik och språkbegränsningar
   • Exakt en gång, högst en gång, at-least-once
   • Serialisering och de-serialisering
   • End-to-end-argument och dess tillämpning på verkliga system
   • Integrering med threading
   • Automatisering av operationer
2. • Data caching and one-kopia-semantik
   • Konsistensprotokoll för cacheminnet och kompromisser vid genomförandet
   • Ursprunget till tids- och rumslig lokalitet
   • Mätetal för cachekvalitet
   • Applikationsspecifika konsistensprotokoll
   • Prefetching: Fördelar och risker
   • Extraktion av tips
   • Buffer bloat
3. • Fel i distribuerade system: ursprung och empiriska studier
   • Fail fast and Byzantine failures
   • Fundamental limits of failure resilience
4. • Feltolerans: Atomtransaktioner; ACID-egenskap
   • Uppdragsutmaningar
   • Skuggning, intentionslistor och write-ahead-loggning
   • Skillnader i fysisk loggning och loggning av operationer
   • Nested transactions
   • Distributed transactions
5. • Consensus och blockchain: enhällighet (tvåfasig överföring)
   • Majoritet (val av ledare, Paxos)
   • Byzantine (single-shot och Dolev-Strong)
   • State machine replication and Streamlet
   • Bitcoin

6. Gemensamma programmeringsparadigmer som Map-Reduce, MPI och GraphLab

7. (Endast om tiden tillåter det):
   • Hög tillgänglighet: röstbaserat bevarande av semantik med en kopia
   • Taxonomi för replikeringsstrategier: pessimistiska och optimistiska strategier
   • Läs-skriv- och skriv-skriv-konflikter
   • Server-klient- och peer-to-peer-strategier
   • Caching och frånkopplad drift; Lösning av konflikter
   • Utnyttjande av låg bandbredd för att förbättra tillgängligheten

Kurslogistik

Professorer

Undervisningsassistenter

Föreläsningar

• Torsdagar och torsdagar, kl. 10:40-12:00
• Zoomlänkar och videoinspelningar: På Canvas-sidan för denna kurs
• Ingen lektion: Tisdag 23 februari (rastdag), torsdag 15 april (vårkarneval)
• Sista lektionen: Tisdag 23 februari (rastdag), torsdag 15 april (vårkarneval): Torsdag 6 maj

Recitationer

• Tid: Onsdagar 19:00 – 19:50 (sektion A), 20:00 – 20:50 (sektion B)
• Zoomlänkar och videoinspelningar: På Canvas-sidan för denna kurs

Kursanteckningar

Vi kommer att placeras i kursens AFS-område på:

Läroböcker och valfri läsning

Det finns inga obligatoriska läroböcker. Här är tre bra referenser för valfri läsning:

• ”Distributed Systems: Principles and Paradigms” av Andrew S. Tanenbaum och Maarten Van Steen, Third (2017) Edition, Prentice Hall
• ”Guide to Reliable Distributed Systems” av Kenneth P. Birman, Springer
• Foundations of Distributed Consensus and Blockchains av Elaine Shi (2020, bokmanuskript)

I länken ”Readings” högst upp på den här webbsidan finns dessutom några specifika valfria läsningar som vi kommer att nämna vid olika tillfällen under föreläsningarna. pdf:erna av dessa valfria läsningar finns tillgängliga på denna kurswebbplats.

Kurspolicy

Förutsättningar

Då den här kursen har en stor projektkomponent måste du vara duktig på C och Java-programmering på UNIX-system. Det krävs att du har läst 15-213 och fått ”C” eller högre eftersom många av de programmeringskunskaper du kommer att behöva lärs ut i den kursen. Om du fick ett C i 15-213 måste du träffa din studievägledare för att diskutera din bakgrund innan du tar 15-440, och kanske ta ytterligare en kurs för att vässa dina systemkunskaper.

Policy om akademisk integritet

Carnegie Mellon Universitys policy om akademisk integritet gäller för den här kursen. Alla studenter förväntas noggrant läsa igenom denna policy och följa den för alla aspekter av kursen.

Riktlinjer för samarbete:

• Studenterna uppmuntras att prata med varandra, med assistenterna, med lärarna eller med någon annan om någon av uppgifterna. Eventuell hjälp måste dock begränsas till att diskutera problemet och skissa på allmänna lösningar.
• Varje student måste skriva ut sina egna lösningar på problemuppsättningarna. Alla projekt måste göras individuellt.
• Det är förbjudet att konsultera en annan students lösning, och inlämnade lösningar får inte kopieras från någon källa. Dessa handlingar utgör fusk.
• Om du har några frågor om huruvida någon aktivitet skulle utgöra fusk är du välkommen att fråga lärarna.

Riktlinjer för delning: Du får inte lämna ut arbete som du utför under 15-440 till andra studenter i framtida kurser eller för användning i framtida kurser (precis som du inte får använda arbete som utförts av studenter som gått kursen tidigare).

Inspelningar

För våren 2021 kommer Zoom-sessioner av varje föreläsning och recitation att spelas in av CMU Computing Services och läggas ut på Canvas-sidan för den här kursen. Alla andra inspelningar är förbjudna.

Limit för användning av TA-tid

För att vara rättvis mot alla, särskilt när det finns en lång kö av studenter som väntar på en TA:s uppmärksamhet, kommer det att finnas en gräns på 10 minuter för alla konsultationer. Om en student inte är klar efter 10 minuter måste han/hon gå tillbaka till slutet av kön innan han/hon får mer tid med assistenten. Var förberedd innan du träffar en assistenthandledare. Om du behöver hjälp med att hitta ett fel, begränsa och förenkla problemet innan du träffar TA:n.

Piazzapolicy

Denna kurs använder sig av webbplatsen Piazza för att besvara frågor: här är Piazza-sidan för denna kurs.

Tänk på Piazza som att räcka upp handen i klassen och ställa en fråga. Ingen fråga är för dum för att ställa, så var inte rädd. För varje person som ställer en fråga finns det förmodligen många andra för vilka samma fråga redan har dykt upp eller snart kommer att dyka upp. Svaret på din fråga kan vara till nytta även för dem. Dessutom finns det kanske några personer som din fråga inte har dykt upp hos dem. Genom att ställa frågan hjälper du dem att se en subtilitet som de kanske inte har sett tidigare. Direkt e-post till instruktörerna kommer inte att besvaras.

Vi förväntar oss alltid att du använder ditt goda omdöme i dina inlägg på Piazza (frågor såväl som svar på frågor från medstudenter). En del av inlärningsprocessen är att kämpa med materialet tills du kommer fram till den rätta insikten för att du ska förstå det. Om du skriver för mycket detaljer som svar på en begäran om hjälp kan det försämra inlärningen. Å andra sidan är det ibland bra att få en knuff i rätt riktning när man inte lyckas ta sig ur en rutin. Och självklart ska missförstånd om uppgiften eller tillgängliga verktyg snabbt hjälpas åt. Använd ditt bästa omdöme när du skriver på Piazza-webbplatsen, som om du samarbetade med dina vänner personligen. Några grova riktlinjer:

Exempel på bra saker att posta och besvara:

• Missförstånd om uppgiften
• Förtydliganden om kraven
• Bugs i specifikationen för uppgiften eller referensimplementationen eller testerna
• Små, detaljerade frågor om hur systemanrop, funktioner osv. fungerar.
• Saker som ser ut att höra hemma i en FAQ för uppgiften

Exempel på dåliga saker att skriva eller besvara:

• Mer än några rader kod
• Djupgående förklaringar av hur ditt system fungerar
• Frågor om det bästa tillvägagångssättet för att bygga upp systemet på en hög nivå
• Frågor om ditt betyg

Vi förväntar oss att du har gjort en rimlig ansträngning för att tänka själv innan du postar en piazza-fråga. Detta gäller särskilt när det gäller felsökning av din kod. Har du försökt med man-sidorna? Har du gjort en Google-sökning efter eventuellt relevanta resurser? Har du tittat på de tidigare frågor som folk redan ställt och på de svar som givits? Har du satt in printf:s och försökt förstå vad som händer med din kod?

Använd inte autolab som ett verktyg för felsökning. Vi förväntar oss att du har gjort rimliga ansträngningar för att få din kod felsökt innan du skickar in den till autolab. Att skapa testfall och stresstesta din kod är en del av vad ett projekt handlar om. Om du inte gör den ansträngningen missar du en viktig del av inlärningsmöjligheterna i kursen. Att lämna in autolab bör vara det sista steget i en process där du har testat, felsökt och förbättrat din kod i största möjliga utsträckning. Att skicka en autolab-dump i ett piazza-inlägg och säga ”snälla hjälp” är ett grovt brott mot piazzas etikett.

Privata inlägg på Piazza stöds inte. Detta är ett principbeslut för den här klassen. Kom ihåg att inlägg på piazza liknar att räcka upp handen och ställa en fråga. Andra studenter drar nytta av att du ställer frågan och ser lärarens svar. Vi tillåter att dina inlägg är anonyma för dina medstudenter om du så önskar. Detta är redan en högre grad av integritet än vad som är möjligt när du ställer en fråga i klassrummet. För de verkligt sällsynta tillfällen då du behöver göra en privat förfrågan som inte har med kursinnehållet att göra har en särskild privat sändlista skapats.

För förfrågningar som verkligen behöver vara privata Skicka e-post till [email protected] och en av lärarna kommer att svara. E-post till denna lista som rör kursinnehåll (t.ex. förtydliganden av kursmaterial) kommer att ignoreras; du bör ställa sådana frågor på Piazza.

Policy för sena inlämningar

För projekt:

• Varje student kommer att ha fem sena dagar att använda under hela terminen. Dessa sena dagar är avsedda för att ta hänsyn till semestrar, resor, intervjuer, förkylning och andra liknande situationer. Det står dig fritt att använda dem av vilken anledning som helst, utan att be om lov från lärarna. Du kan använda högst två förseningsdagar på en och samma förfallodag (dvs. för projekt med flera kontrollpunkter kan du använda upp till två förseningsdagar för varje kontrollpunkt). Senarelagda dagar tillämpas automatiskt i kronologisk ordning, så du kan inte välja att skjuta upp användningen av en senarelagd dag för en framtida uppgift med högre vikt.

• En senarelagd dag = (0,24] timmar efter förfallodagen, två senarelagda dagar = (24, 48] timmar efter förfallodagen osv.

• Om du använder alla senarelagda dagar kan du lämna in sena inlämningsuppgifter med en straffavgift på 15 % per dag, i upp till två dagar. Med andra ord, om du har använt alla dina förseningsdagar kan du fortfarande lämna in under de två följande dagarna, med en straffavgift på 15 % för var och en av dessa dagar (betalningsfria dagar).

• Du kan inte kombinera förseningsdagar och betalningsfria dagar för att lämna in mer än två dagar för sent.

För problemställningar: Inga sena inlämningar accepteras, med eller utan påföljd. Se till att lämna in i tid.

Stilguide för projekt

Förutom att testa kodens funktionalitet kommer vi också att reservera en del av varje projekts poäng för dess stil och läsbarhet. Det viktigaste är en konsekvent och läsbar stil. Vi vill främst se att du har valt en stil som är läsbar och rimlig, och att du använder samma stil konsekvent i hela projektet. använd sunt förnuft: ha inte 500 tecken långa kodrader, namnge inte dina variabler foo (om det inte är vettigt i sitt sammanhang) och undvik att blanda fallkonventioner slumpmässigt.

Vi kommer att leta efter följande saker:

Dokumentation Bra dokumentation är viktig: för dig själv i framtiden, för andra som underhåller koden och i detta sammanhang för de betygsättare som kommer att titta på din kod. Känn inte att du behöver dokumentera varje kodrad (eftersom bra kod på sätt och vis också bör vara självdokumenterande), men det brukar vara bra att belysa den allmänna användningen och syftet med varje funktion, liksom stora eller komplexa kodblock. Det är också bra att inkludera en filhuvudrubrik i varje fil, där man beskriver hur filen passar in i projektets struktur som helhet. Vitrymd Var konsekvent. Använd inte tabulatur med 2 mellanslag på vissa ställen och 4 på andra. Var rimlig och använd vitrymden för att se till att din kod är läsbar. Linjelängd Vi kommer att vara rimliga när det gäller linjelängd, så länge du är konsekvent och dina gränser är rimliga (500 tecken är det inte… 80 eller 120 tecken är vanligt förekommande och accepterat). Variabelnamn Variabelnamnen bör ge en tydlig indikation på vad de representerar eller hur de används. Död/testkod Försök att inte lämna in kod som är översållad med utskriftsdeklarationer för felsökning eller stora kommenterade delar av koden. Det försämrar läsbarheten och distraherar från den kod som faktiskt kommer att köras i produktionen. Design Försök att utforma din kod och dina projekt på ett sådant sätt att de är någorlunda modulära. 5000-linjiga funktioner är i allmänhet ett tecken på dålig utformning och kommer att ge dig huvudvärk senare.

Här finns en stilguide från Google som kan vara till hjälp.

Välbefinnande

Här finns några tips för välbefinnande.