Distribuerade system Föreläsning 7.

En presentation över ämnet: "Distribuerade system Föreläsning 7."— Presentationens avskrift:

1 Distribuerade system Föreläsning 7

2 Distribuerade system Distribuerade system - grunderna
Vad kan man göra med ett antal datorer sammankopplade med ett nät? Programmeringsmodeller för distribuerade system? Hur fungerar NFS, AFS och andra distribuerade filsystem? Distribuerade system - grunderna Programmeringsmodeller Distribuerade filsystem Kap: , OS Föreläsning 7, Distribuerade system 2

3 Distribuerat system Ett system som består av ett antal datorer
sammankopplade med nätverk har inte fysiskt delat minne samverkar i lösandet av ett problem (fungerar som en enhet) OS Föreläsning 7, Distribuerade system 3

4 Distribuerade system Terminologi Varför? Designmål Nätverk

5 Distribuerade system - lite terminologi
Site – fysisk plats med en eller flera datorer Host – dator på en site Server – dator som har en resurs/tillhanda- håller en tjänst som en annan dator vill använda Klient – datorn som utnyttjar en tjänst hos en server (en dator kan vara både klient och server) OS Föreläsning 7, Distribuerade system 5

6 Distribuerade system – varför? - några viktiga skäl
Resursdelning Ex: printrar, disk, beräkningsresurser, databaser... Uppsnabbning Genom att fördela/flytta beräkningar (kan ses som specialfall av resursdelning) Tillförlitlighet Om en enhet går ned kan kanske en annan ta över Kommunikation Pris-prestanda Inkrementell uppdatering OS Föreläsning 7, Distribuerade system 6

7 Distribuerade system - designmål
Transparens - genomskinlighet – att systemet är distribuerat syns inte för användaren ex: Namntransparens – namnet beror inte på var objektet finns Platstransparens (location transparency) – man behöver inte veta var resurser finns Flyttransparens – användaren märker inte om resurser flyttar Replikationstransparens - användaren behöver inte fundera på om man arbetar men en lokal kopia Samtidighetstransparens - man behöver inte veta om att någon annan använder resurser samtidigt Parallelitetstransparens - man behöver inte veta om att ens program körs parallelt Feltolerans – robusthet Skalbarhet OS Föreläsning 7, Distribuerade system 7

8 Nätverk Att fundera över Namngivning, namnuppslagning ex: DNS
Routingstrategier: statisk, dynamisk Förbindelsestrategi: förbindelseorienterad eller förbindelselös Överföring: pålitlig eller opålitlig Hantering av överlast/kollisioner Robusthet: vad händer om en länk går ned Topologi Kapacitet och QoS parametrar: bandbredd, fördröjning, fördröjningsvariationer Säkerhet Kostnad OS Föreläsning 7, Distribuerade system 8

9 ”Overlay networks” Ett virtuellt/logiskt nät/topologi som kan implementeras i mjukvara ovanpå ett fysikt nät Ex: multicast distributionsträd OS Föreläsning 7, Distribuerade system 9

10 Kommunikation i distribuerade system
Önskade egenskaper Samma metod vid lokal och icke lokal kommunikation (transparens) Stöd för kommunikationsdestinationer som flyttar Pålitlighet, feltolerens och säkerhet Effektivitet Kommunikation kostar Granularitet viktig – helst mycket beräkning i förhållande till kommunikation - flytta mycket data på en gång Replikation - lokala kopior minskar kommunikation - konsistensproblematik OS Föreläsning 7, Distribuerade system 10

11 Namn och adresser Ett namn är en logisk, tillämpningsorienterad beteckning , ex. shell.it.kth.se En adress är det som nätet behöver för att hitta (t.ex. IP adress) Adresser bör inte vara hårdkodade i program Name servers används för översättning mellan logiska namn och adresser (t.ex. DNS – Domain Name System) Ibland kan man fråga efter en viss tjänst (t.ex. AFS) i stället för efter en viss server OS Föreläsning 7, Distribuerade system 11

12 Programmeringsmodeller
Hur hittar man fram till motparten? Sockets Meddelanden RPC Distribuerat delat minne Objektbaserad ”middle-ware”

13 Att hitta motparten - att skicka meddelande till en process
Hur hittar man den process man vill sända meddelandet till? IP-adress identifierar ett nätverksinterface En process kan lyssna på en port TCP och UDP headrarna har portnummer OS Föreläsning 7, Distribuerade system 13

14 Meddelandesändning - via ETH, TCP/IP
Sändare Mottagare Skicka meddelande till IP-adress + portnr Lyssnar på (läser från) TCP portnr Nätverkskod: Bygg TCP/IP paket Ta reda på över vilket nätverksinterface det ska skickas Ta reda på ETH-adress till nästa hop Nätverkskod: Skala av ETH och IP headrar och se att de var adressared till den här maskinen Skicka upp meddelandet till port ETH interface ETH interface ETH IP TCP portnr payload OS Föreläsning 7, Distribuerade system 14

15 Kopiering - kan sänka prestanda rejält
För mycket kopiering kan sänka prestanda Ett vanligt fall: 1. Kärnan kopierar från sändarens adressrymd till en buffert i OS-kärnan 2. Kärnan kopierar till ett minne på nätverkskortet 3. Nätverket kopierar till mottagarens nätverkskort 4. Mottagarens kärna kopierar till buffert i kärnan 5. Mottagarens OS-kärna kopierar till mottagarens adressrymd OS Föreläsning 7, Distribuerade system 15

16 Sockets - abstrakt nätverkskontakt
En abstrakt datatyp för kommunikation Sändare och mottagare skapar var sin socket Anger protokoll: vanligast TCP eller UDP Mottagaren lyssnar på sin socket genom systemanropet listen Sändaren kopplar upp sin socket till mottagarens genom ett connect systemanrop Resultatet blir något som kan liknas vid en pipe mellan de två processerna OS Föreläsning 7, Distribuerade system 16

17 Meddelandesändning Primitiverna är vanligtvis Destinationer kan vara
send(destination, message) receive(buffer) Destinationer kan vara processidentifierare (maskin.pid) problem vid omstart med ny pid mailboxar (maskin.mb) oberoende av pid ger bättre transparens, många kan läsa portar (maskin.port) oberoende av pid, endast en process äger porten OS Föreläsning 7, Distribuerade system 17

18 Blockerande eller icke-blockerande
Skall meddelandesändningsprimitiverna vara blockerande eller icke-blockerande? Hur länge skall man blockera Ex: send till dess meddelandet skickats eller till dess mottagaren tagit emot meddelandet? Till stor del beror det på hur man vill hantera buffertar Icke-blockerande send – man får inte skriva över send-bufferten Icke-blockerande receive: kan vara bra om man vill polla om det kommit meddelanden Delvis hänger detta också ihop med synkronisering OS Föreläsning 7, Distribuerade system 18

19 Pålitlighet Meddelanden kan komma bort på vägen
någon router går ner brist på mellanlagringskapacitet vid trafikstockning Pålitlig meddelandesändning kan åstadkommas genom kvittens vid mottagande av meddelande time-out om kvittens ej inkommit efter viss tid vid sändning paritet/checksummor används ofta för att skydda data från fel OS Föreläsning 7, Distribuerade system 19

20 Klient-server kommunikation
Klienter skickar meddelanden med begäran Servrar utför begäran och skickar svar Klienter är normalt blockerade mellan begäran och svar (dvs. i hög grad synkron kommunikation) Begäran kan motsvara systemanrop Läsa och skriva filer Starta processer Klienter vet inte nödvändigtvis var servrar finns Platstransparens OS Föreläsning 7, Distribuerade system 20

21 Vad händer om - man tappar bort begäran/svar eller vid en krasch
Klientens begäran försvinner på vägen eller svaret kommer inte tillbaka inom rimlig tid Timeout: Skicka om begäran Problem: Klienten kan få två svar Servern kan få två begäran Vad händer om servern kraschar efter att ha fått begäran? Begäran utförs delvis Begäran utförs inte Vad händer om klienten kraschar efter att ha sänt begäran? Ta hand om, städa bort, ”föräldralösa” begäran/svar Ex: inkarnationsnummer för klienten OS Föreläsning 7, Distribuerade system 21

22 Semantik och tillståndslösa servrar
Semantik på begäran Vill normalt ha ”exactly once” Kan få: ”at least once” ”at most once” Tillståndslös server Om servern inte har något tillstånd så Mindre problem med omstart av server Mindre problem om klienten tvingas till omsändningar Sidoeffektsfria begäran (idempotenta) Vilken semantik är bäst i det fallet? OS Föreläsning 7, Distribuerade system 22

23 Remote Procedure Call - fjärrproceduranrop (~1985-86)
Programmeringsteknik för klient-server- kommunikation Tag fasta på analogin mellan Proceduranrop och Att skicka ett request till en server som utför det och skickar tillbaka ett svar OS Föreläsning 7, Distribuerade system 23

24 Steg i ett remote procedure call
Klienten gör ett proceduranrop till en stubprocedur Klientens stubprocedur skickar en begäran till servern och väntar sedan på ett svar På serversidan finns också en stubprocedur som anropas när en begäran anländer Serversidans stubprocedur anropar koden i servern som behandlar begäran När begäran är behandlad skickas svaret tillbaka till klientsidan Klientens stubprocedur returnerar till klienten OS Föreläsning 7, Distribuerade system 24

25 Utför begäran: returnera
RPC Sändare Mottagare Klient: Anropa stub- procedur Utför begäran: returnera svaret till stubben stub stub Stub-procedur: Packa parametrar Anropa servern Mottagarsidan: Skicka upp meddelandet till port och anropa stubprocedur i servern ETH interface ETH interface ETH IP TCP portnr payload OS Föreläsning 7, Distribuerade system 25

26 Stubprocedurer Automatgenereras från gränssnitts- beskrivning som programmeraren skriver Gränssnittsbeskrivningen definierar Datatyper för parametrar Speciella datatyper för arrayer/vektorer av bestämd storlek Procedur/funktions parametrar och returvärden (jfr. Funktionsprototyper i C) OS Föreläsning 7, Distribuerade system 26

27 Parameteröverföring i RPC
Olika fysiska adressrymder Alla parametrar värdeöverförs Hur hanterar man Länkade strukturer Dynamiskt allokerade strukturer Vektorer i t.ex. C Hur hantera olika datarepresentation Teckenrepresentation: ASCII, UTF-8 Heltal: little endian, big endian (eller 8, 16, 32, 64 bitar) Flyttal: IEEE, Cray OS Föreläsning 7, Distribuerade system 27

28 Marshalling - att packa parametrar
RPC-systemet måste packa parametrarna på ett format som bägge sidor förstår Sk. ”kanonisk” representation Sköts normalt helt transparent OS Föreläsning 7, Distribuerade system 28

29 Distribuerat delat minne

30 Distribuerat delat minne - ett sätt att åstadkomma det
Man kan använda virtuellminnessystemet för att emulera delat minne Skrivbara sidor finns i högst ett minne Om en CPU vill läsa/skriva en adress som tillhör en sida i en annan CPUs minne blir det pagefault Vid pagefault där sidan finns i annat minne hämtas den Konsistensproblematik vid uppdateringar (skrivningar) Men: sidor som endast läses kan finnas i flera minnen OS Föreläsning 7, Distribuerade system 30

31 Var implementeras distribuerat delat minne?
Applikation Run-time system Operativ- Hårdvara Delat minne Dator 1 Dator 2 Applikation Run-time system Operativ- Hårdvara Delat minne Dator 1 Dator 2 Applikation Run-time system Operativ- Hårdvara Delat minne Dator 1 Dator 2 OS Föreläsning 7, Distribuerade system 31

32 Falsk delning -false sharing
Uppstår när två CPUer vill skriva till två olika variabler som råkar ligga på samma sida/samma cache linje Vanligare vid större sidor/cache linjer ”Egentligen” borde det inte hända ty CPUerna delade inga data Händer till viss del i alla cachar i multiprocessorer OS Föreläsning 7, Distribuerade system 32

33 Progambaserat delat minne
... ännu ett nytt ämne

34 CORBA Idén är att anropa metoder hos objekt som (kanske) lagras på andra maskiner Fungerar även om arkitekturer osv. är olika Påminner om Sun RPC Man skriver en gränssnittsfil ungefär som i RPC Stubbar genereras Varje maskin har en Object Request Broker Objekten är stationära Problem om alla vill använda samma objekt OS Föreläsning 7, Distribuerade system 34

35 Globe Forskningssystem som skall skala till väldigt många maskiner
Stöd för Replikering av objekt (om man vill) Olika objekt har olika konsistenskrav Objekten innehåller flera delobjekt för: Kontroll koordinerar de olika delarna Replikering håller reda på replikering Säkerhet vem får göra vad, kryptering Kommunikation protokoll Semantik gör själva jobbet, den del programmeraren måste tillhandahålla OS Föreläsning 7, Distribuerade system 35

36 Globe Man kan ha olika konsistenskrav för olika objekt
Vissa objekt är endast läsbara Vissa objekt måste vara sekventiellt konsistenta Vissa objekt måste bara vara rimligt aktuella Inte bara läsningar och skrivningar Vissa metoder kanske gör read-modify-write vilket de kan göra på ett effektivt sätt om det görs lokalt hos objektet OS Föreläsning 7, Distribuerade system 36

37 Distribuerade operativsystem - på vilken nivå stöds distribuering
Nätverksoperativsystem Distribuerat operativsystem

38 Nätverksoperativsystem
Stödjer att användaren utnyttjar nätverk på ett icke transparent sätt Användaren måste vara medveten om att det finns andra resurser i nätet t.ex. andra datorer Typiskt stöds: remote inloggning: ex. telnet filöverföring: ex. ftp Ofta relativt enkelt att implementera/lägga till sådan funktionalitet till existerande OS Många OS i den här kategorin: de flesta UNIX-varianter, Windows OS Föreläsning 7, Distribuerade system 38

39 Distribuerat operativsystem
Tillåter användaren att använda resurser på andra datorer på samma sätt som lokala resurser, dvs. transparent Data migrering – vid access av data på andra datorer, t.ex. filer, överförs det helt eller delvis till den lokala datorn Beräkningsmigrering – en beräkning kan utföras på en annan dator Processmigrering – en process kan helt eller delvis flyttas/utföras på en ann dator Lastbalansering Uppsnabbning Tillgång till speciell hård- eller mjukvara Dataaccess Fortfarande mest ett forskningsområde... OS Föreläsning 7, Distribuerade system 39

40 Distribuerade filsystem
Namngivning Cachning Tillstånd hos servern NFS och AFS

41 Distribuerade filsystem
Mycket vanliga nuförtiden NFS från Sun AFS från CMU och ... Filerna lagras på en annan dator (filservern) än den där programmen som använder filerna körs (klienten) Många klienter kan dela på samma filserver Olika delar av filsystemet (volymer) kan lagras på olika servrar OS Föreläsning 7, Distribuerade system 41

42 Namngivning Fysisk adress Montering Logisk adress
OS Föreläsning 7, Distribuerade system 42

43 Namnrymden i ett DFS Fysisk: maskinnamn.filnamn
en nameserver omvandlar maskinnamn till nätadress dålig plats- och flyttransparens då alla processer måste känna till maskinnamn Ex. URL i www: OS Föreläsning 7, Distribuerade system 43

44 Namnrymden i ett DFS Montering:
monteringsprotokollet använder ofta fysiska namn delvis transparent (klientprocesser behöver ej veta maskinnamn) filsystemet kan se olika ut från olika klienter används t.ex. i NFS från Sun OS Föreläsning 7, Distribuerade system 44

45 Namnrymden i ett DFS Logisk: namnrymden ser ut som i ett centraliserat system en distribuerad databas håller reda på var delträd (volymer) finns volymers plats ändras sällan god transparens men komplicerad implementation används t.ex. av AFS OS Föreläsning 7, Distribuerade system 45

46 Prestandahöjare Cachning Replikering

47 Filcachning i DFS Användning av filer på filserver kan vara långsam pga. fördröjningar i nät överbelastad server med många klienter Klienter kan cacha (delar av) filer för snabbare åtkomst i huvudminnet (buffercachen) på lokal disk (t.ex. i AFS) OS Föreläsning 7, Distribuerade system 47

48 Filcachning i DFS, konsistensproblem
Lokala kopior Skriver Läser Fil på server OS Föreläsning 7, Distribuerade system 48

49 Fildelningssemantik Problemet Semantiker Sekvensiell Session Immutable

50 Fildelningssemantik vid cachning
Cachning hos klienterna ställer till problem filen kan ha ändrats hos servern olika cachar kan innehålla olika data När skall en klient tala om för servern att klienten har ändrat i sin cache? om ingen annan klient är intresserad behöver man ej göra det efter varje ändring När skall en klient få ny version av fil från servern? OS Föreläsning 7, Distribuerade system 50

51 Sekvensiell semantik - UNIX-semantik
Sekventiell konsistens innebär att det (logiskt sett) bara finns en kopia av varje fil exakt samma som vid centraliserat system kallas även Unix-semantik eller remote-access svårt att implementera effektivt OS Föreläsning 7, Distribuerade system 51

52 Sessionssemantik Sessionssemantik innebär att varje klient som har filen öppen logiskt sett har en lokal kopia ändringar görs till den lokala kopian vid close() skrivs kopian tillbaka till servern kallas även upload/download lätt att implementera AFS har ungefär sessionsemantik, men inte riktigt OS Föreläsning 7, Distribuerade system 52

53 Immutable Icke-muterbara filer innebär att filer inte ändras, utan varje ny version ersätter den gammla (”write-once”) varje verson har ett nummer ganska likt sessionssemantik Version 1 Klient 1 Klient 2 Version 2 Version 3 ? Klient 2 ändrar och skriver tillbaka Klient 1 ändrar och skriver tillbaka OS Föreläsning 7, Distribuerade system 53

54 Cachekonsistensmekanismer
Write-through Varje skrivning skrivs direkt till server Ger inte i sig sekvensiell semantik Mycket nättrafik Delayed write Ändringar skrivs periodvis t.ex. efter 30sek Minskad nättrafik Semantik? Används av AFS Write-on-close Sessionssemantik Centraliserad kontroll En felpunkt Dålig skalbarhet Enkel semantik OS Föreläsning 7, Distribuerade system 54

55 Att upprätthålla Unix-semantik - ex. på centraliserad kontroll
Kan åstadkommas med cachekonsistens-protokoll Klienterna har tokens som ger rätt att använda lokal kopia flera klienter kan ha lästokens till samma fil om en klient har skrivtoken till en fil får inga andra klienter ha några tokens till den filen om man ej har token får man ej göra lokala operationer även om man har filen i cachen servern håller reda på alla tokens den delat ut OS Föreläsning 7, Distribuerade system 55

56 Att upprätthålla Unix-semantik - ex. på centraliserad kontroll
Om en klient vill läsa en fil måste servern återkalla eventuellt utdelat skrivtoken klient med skrivtoken ger ifrån sig detta tillsammans med alla nya data som den skrivit med hjälp av skrivtokenet servern uppdaterar filen med dessa nya data och skickar ändringarna eller hela filen till klienten som ville läsa Om en klient vill skriva till en fil måste servern återkalla alla andra tokens OS Föreläsning 7, Distribuerade system 56

57 Filreplikering Filreplikering innebär att filer (eller volymer) lagras på mer än en filserver Förbättrar prestanda och feltolerans lasten kan fördelas på flera servrar man kan använda en (geografiskt) närliggande server om en server är nere kan man komma åt sina filer från en annan om en server brinner upp finns filer kvar på andra servers (kontinuerlig backup) OS Föreläsning 7, Distribuerade system 57

58 Filreplikering Det är lätt att replikera volymer som ej får skrivas (finns i AFS) Bra för saker som sällan ändras, t.ex. koden till systemprogram Man får dock inte kontinuerlig backup Svårt (men bra ur prestanda/säkerhetssynpunkt) att replikera skrivbara volymer Knepigt att upprätthålla konsistens Visst vore det bra om ens hemkatalog alltid var tillgänglig :-) OS Föreläsning 7, Distribuerade system 58

59 Filreplikering och skrivning
Lösning 1: Se till att alla servrar har samma data Skriv alltid till alla servrar (som lagrar den volymen) Läs från vilken server som helst Enkelt men skrivningar blir långsamma och det blir problem om någon server är nere Skrivningar blir inte möjliga då, ty alla servrar svarar inte OS Föreläsning 7, Distribuerade system 59

60 Filreplikering och skrivning
Lösning 2: Skriv till några servrar, läs från några servrar Välj två tal S och L och läs alltid från minst L servrar och välj senaste version (lagra versionsnummer för alla filer) skriv till minst S servrar med nytt versionsnummer S och L måste uppfylla S+L > antal servrar S+S > antal servrar OS Föreläsning 7, Distribuerade system 60

61 Tillstånd hos servern eller ej?
Om servern kommer ihåg saker mellan uppdrag (requests) kallas den stateful annars stateless Tillstånd som kan kommas ihåg: Vilka klienter som har vilka filer öppna Vilka klienter som cachar filer (tokens) Protokollet mellan server och klient blir olika Om servern är stateless måste klienter skicka all info, t.ex. läs/skrivposition OS Föreläsning 7, Distribuerade system 61

62 Tillstånd hos servern eller ej?
Problem med tillstånd om servern går ner Info, t.ex. filoffset, försvinner för klienter med öppna filer Konsistensinformation (vilka klienter som har lokala kopior av delar av filer) försvinner Problem med tillstånd om klienten går ner Tillståndsinformation ligger kvar på server och kan ej tas bort (minnesläckor) Filer kan bli evigt öppna OS Föreläsning 7, Distribuerade system 62

63 Tillstånd hos servern eller ej?
Många problem kan lösas med leases, som är information med bäst-före datum Fungerar bra för tokens eftersom en klient alltid kan fråga igen om dess token gått ut Servern kan kasta info om tokens efter en viss tid vilket sparar minne Bäst-före datum väljs så att om servern kraschar och startar om så hinner alla tokens den delat ut bli för gamla Fungerar mindre bra för filoffset och dylikt OS Föreläsning 7, Distribuerade system 63

64 Med eller utan tillstånd
Fördelar för tillståndslös filserver Fördel för filserver med tillstånd Feltolerans Kortare meddelanden från klienten Open/close behövs ej Kan ge bättre prestanda Mindre minnesbehov för servern Readahead möjligt Inga begränsningar på antal öppna filer Lättare att koordinera idempotenta operationer Inga problem om klienten kraschar Enklare att låsa filer OS Föreläsning 7, Distribuerade system 64

65 virtuellt filsystem (v-noder)
NFS arkitektur kärna systemanrop virtuellt filsystem (v-noder) lokalt filsystem ex. UFS NFS- klient buffert cache disk drivrutin nätinterface NFS- server kärna OS Föreläsning 7, Distribuerade system 65

66 NFS - detaljer (i princip) Tillståndslös server
Montering i filsystemet Överför data i 8KB block Read-ahead på serversidan Konsistens problematiken Timer på block i lokala block cachen hos klienten 3 sek för data 30 sek för directory information När en fil öppnas som finns i block cachen frågas alltid servern om den har en nyare kopia Modifierade block skrivs till servern när filen stängs och Var 30:e sekund skrivs alla modifierade block till servern OS Föreläsning 7, Distribuerade system 66

67 Ett litet problem Vad gör man om en server som håller ett monterat filsystem går ned I tidernas begynnelse – man väntade till dess man fått svar! Nu: Time-out på operationer Auto-montering (filsystemen monteras vid behov) OS Föreläsning 7, Distribuerade system 67

68 Andrew File System - AFS
Vice (AFS-server) kärna systemanrop systemanrop kärna virtuellt filsystem (v-noder) virtuellt filsystem lokalt filsystem ex. UFS Venus (AFS- Klient) lokalt filsystem ex. UFS buffert cache buffert cache disk drivrutin nätinterface drivrutin nätinterface drivrutin disk drivrutin OS Föreläsning 7, Distribuerade system 68

69 AFS - detaljer Filer cachas lokalt i /cache
Modifieringar skrivs normalt bara tillbaka till servern när filen stängs – sessionssemantik Venus kan tala om för Vice att den vill veta om någon annan accessar filen Om så meddelar Vice när någon accessar filen och Venus invaliderar den lokala kopian och skriver tillbaka ändringarna till Vice Tillåter mer hanterliga skyddsmekanismer än UFS Användardefinierade grupper och utökade ACL:er Underlättar för systemadministratören att flytta, kopiera volymer av filer och directoryn Skalar bättre än NFS OS Föreläsning 7, Distribuerade system 69

70 Mer om distribuerade system
Master program: Software Engineering of Distributed Systems (SEDS) Kurser: ID2201, ID2203, ID2210, ID2220 OS Föreläsning 7, Distribuerade system 69