Distribuerade system Föreläsning 7
Distribuerade system 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: 8.2-8.3, 10.6.4 system 2
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) system 3
Distribuerade system Terminologi Varför? Designmål Nätverk
Distribuerade system - lite terminologi Site fysisk plats med en eller flera datorer Host dator på en site Server dator som har en resurs/tillhandahå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) system 5
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 system 6
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 system 7
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 system 8
Overlay networks Ett virtuellt/logiskt nät/topologi som kan implementeras i mjukvara ovanpå ett fysikt nät Ex: multicast distributionsträd system 9
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 system 10
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 system 11
Programmeringsmodeller Hur hittar man fram till motparten? Sockets Meddelanden RPC Distribuerat delat minne Objektbaserad middle-ware
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 system 13
Meddelandesändning - via ETH, TCP/IP Sändare Skicka meddelande till IP-adress + portnr Lyssnar på (läser från) TCP portnr Mottagare Nätverkskod: Nätverkskod: ETH interface Bygg TCP/IP paket Ta reda på över vilket nätverksinterface det ska skickas Ta reda på ETH-adress till nästa hop ETH IP TCP portnr payload Skala av ETH och IP headrar och se att de var adressared till den här maskinen Skicka upp meddelandet till port ETH interface system 14
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 system 15
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 system 16
Meddelandesändning Primitiverna är vanligtvis 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 system 17
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 sendbufferten Icke-blockerande receive: kan vara bra om man vill polla om det kommit meddelanden Delvis hänger detta också ihop med synkronisering system 18
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 system 19
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 system 20
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 system 21
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? system 22
Remote Procedure Call - fjärrproceduranrop (~1985-86) Programmeringsteknik för klient-serverkommunikation Tag fasta på analogin mellan Proceduranrop och Att skicka ett request till en server som utför det och skickar tillbaka ett svar system 23
Steg i ett remote procedure call 1. Klienten gör ett proceduranrop till en stubprocedur 2. Klientens stubprocedur skickar en begäran till servern och väntar sedan på ett svar 3. På serversidan finns också en stubprocedur som anropas när en begäran anländer 4. Serversidans stubprocedur anropar koden i servern som behandlar begäran 5. När begäran är behandlad skickas svaret tillbaka till klientsidan 6. Klientens stubprocedur returnerar till klienten system 24
RPC Sändare Klient: Anropa stubprocedur Utför begäran: returnera svaret till stubben Mottagare stub stub Stub-procedur: Mottagarsidan: Packa parametrar Anropa servern Skicka upp meddelandet till port och anropa stubprocedur i servern ETH interface ETH IP TCP portnr payload ETH interface system 25
Stubprocedurer Automatgenereras från gränssnittsbeskrivning 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) system 26
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 system 27
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 system 28
Distribuerat delat minne
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 system 30
Var implementeras distribuerat delat minne? Dator 1 Dator 2 Dator 1 Dator 2 Dator 1 Dator 2 Applikation Applikation Applikation Applikation Applikation Applikation Run-time system Operativsystem Delat minne Run-time system Operativsystem Run-time system Operativsystem Delat minne Run-time system Operativsystem Run-time system Operativsystem Delat minne Run-time system Operativsystem Hårdvara Hårdvara Hårdvara Hårdvara Hårdvara Hårdvara system 31
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 system 32
Progambaserat delat minne... ännu ett nytt ämne
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 system 34
Distribuerade operativsystem - på vilken nivå stöds distribuering Nätverksoperativsystem Distribuerat operativsystem
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 system 38
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... system 39
Distribuerade filsystem Namngivning Cachning Tillstånd hos servern NFS och AFS
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 system 41
Namngivning Fysisk adress Montering Logisk adress system 42
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: www.imit.kth.se/courses/2g1504 system 43
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 system 44
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 system 45
Prestandahöjare Cachning Replikering
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) system 47
Filcachning i DFS, konsistensproblem Lokala kopior Skriver Läser Fil på server system 48
Fildelningssemantik Problemet Semantiker Sekvensiell Session Immutable
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? system 50
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 system 51
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 system 52
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 lient 1 ändrar och skriver tillbaka? Klient 2 ändrar och skriver tillbak system 53
Cachekonsistensmekanismer Write-through Varje skrivning skrivs direkt till server Delayed write Ger inte i sig sekvensiell semantik Mycket nättrafik Ä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 system 54
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 system 55
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 system 56
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) system 57
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 :-) system 58
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 system 59
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 system 60
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 system 61
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 system 62
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 system 63
Med eller utan tillstånd Fördelar för tillståndslös filserver Fördel för filserver med tillstånd Feltolerans Open/close behövs ej Mindre minnesbehov för servern Inga begränsningar på antal öppna filer Inga problem om klienten kraschar Kortare meddelanden från klienten Kan ge bättre prestanda Readahead möjligt Lättare att koordinera idempotenta operationer Enklare att låsa filer system 64
NFS arkitektur kärna systemanrop kärna virtuellt filsystem (v-noder) lokalt filsystem ex. UFS NFS- klient buffert cache disk nätinterface drivrutin drivrutin virtuellt filsystem (v-noder) NFS- server lokalt filsystem ex. UFS buffert cache nätinterface disk drivrutin drivrutin system 65
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 system 66
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) system 67
Andrew File System - AFS Vice (AFS-server) kärna systemanrop systemanrop kärna virtuellt filsystem (v-noder) lokalt filsystem ex. UFS Venus (AFS- Klient) virtuellt filsystem lokalt filsystem ex. UFS buffert cache buffert cache disk nätinterface drivrutin drivrutin nätinterface disk drivrutin drivrutin system 68
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 system 69
Mer om distribuerade system Master program: Software Engineering of Distributed Systems (SEDS) Kurser: ID2201, ID2203, ID2210, ID2220 system 69