introduksjon til distribuerte system (ds) · introduksjon til distribuerte system (ds) inf5040...
TRANSCRIPT
INF5040 Høst 2003 1
Olav Lysne, SRL & Ifi/UiO 1
Introduksjon tilDistribuerte System (DS)
INF5040 høst 2003
foreleser: Olav Lysne
Olav Lysne, SRL & Ifi/UiO 2
Hva er et distribuertsystem?
Definisjon [Coulouris & Emmerich] Et distribuert system består av maskinvare- ogprogramvare-komponenter lokalisert i et nettverk avdatamaskiner som kommuniserer og koordinerer sine aksjoner kun ved å sende meldinger.
Definisjon [Lamport]Et distribuert system er et system som hindrer deg i å få gjort noe arbeid når en maskin du aldri har hørtom før, feiler.
INF5040 Høst 2003 2
Olav Lysne, SRL & Ifi/UiO 3
Konsekvenser av distribuertesystem
Komponenter feiler uavhengig av hverandre– “delvis feiling” & ufullstendig informasjon
Upålitelig kommunikasjon– Tap av forbindelse og meldinger. Bitfeil i meldinger.
Usikker kommunikasjon– Mulighet for uautorisert avlytting og modifikasjon av meldinger
Kostbar kommunikasjon– Kommunikasjon mellom datamaskiner har vanligvis lavere båndbredde,
høyere latenstid, og koster mer, enn mellom uavhengige prosesser i samme maskin.
Samtidighet– komponenter eksekverer i samtidige prosesser som leser og
oppdaterer delte ressurser. Krever koordinering (samtidighetskontroll)Ingen global klokke
– vanskeliggjør tett koordinering
Olav Lysne, SRL & Ifi/UiO 4
Krav som leder tildistribuerte system
ressurs deling– muligheten til å benytte tilgjengelig ressurser hvor som helst
åpenhet– et åpent system kan utvides og forbedres inkrementelt
skalerbarhet– betjene flere brukere, gi kortere svartider
feiltoleranse– opprettholde tilgjengelighet selv i tilfeller der komponenter har liten
pålitelighet
heterogenitet– nettverk og maskinvare, operativsystem, programmeringsspråk,
implementasjon av forskjellige utviklere
INF5040 Høst 2003 3
Olav Lysne, SRL & Ifi/UiO 5
Ressursdeling
Muligheten til å benytte tilgjengelig maskinvare, programvare eller data hvor som helst i systemetRessursforvaltere (managers) kontrollerer aksess, tilbyrskjema for navngiving, og kontrollerer samtidighetEn ressursforvalter er en programvaremodul somforvalter en ressurs av en bestemt type.Ressursdelingsmodell beskriver hvordan
ressurser gjøres tilgjengeligressurser kan brukestjenesteyter og bruker interagerer med hverandre
Olav Lysne, SRL & Ifi/UiO 6
Ressursdelingsmodeller
Klient-tjener ressursmodellTjenerprosesser opptrer som ressursforvaltere, og tilbyrtjenester (samling prosedyrer).Klientprosesser sender forespørsler til tjenere
Objekt-basert ressursmodellEnhver entitet innen en prosess modelleres som et objekt med et meldingsbasert grensesnitt som gir adgang til detsoperasjoner.Enhver delt ressurs modelleres som et objekt
INF5040 Høst 2003 4
Olav Lysne, SRL & Ifi/UiO 7
Åpenhet
Et åpent DS kan utvides og forbedres inkrementeltKrever en uniform interprosessmekanisme og at komponentgrensesnitt offentliggjøres (f.eks. gjenstandfor standardisering)
IETF RFC: Protokollspesifikasjon (www.ietf.org)OMG: grensesnittspesifikasjoner m.m. (www.omg.org)
Nye komponenter må kunne integreres med (virkesammen med) eksisterende komponenter
Olav Lysne, SRL & Ifi/UiO 8
Samtidighet
Komponenter i DS eksekverer i samtidige prosesserKomponenter aksesserer og oppdaterer delte ressurser(f.eks. variable, databaser, device drivere)Integriteten til systemet kan brytes hvis samtidigoppdatering ikke koordineres
tapte oppdateringerinkonsistent analyse
Bevaring av integritet krever samtidighetskontroll hvorsamtidig aksess til samme ressurs synkroniseres
INF5040 Høst 2003 5
Olav Lysne, SRL & Ifi/UiO 9
Skalerbarhet
Et system er skalerbart hvis det forblir effektivt når det eren betydelig økning i mengden ressurser og antallbrukere.
Internett: antall brukere og tjenester har vokst enormt
Skalerbarhet betegner altså et systems egnethet til å handtere en økende last i fremtidenKrav om skalerbarhet leder ofte til en distribuertsystemarkitektur (flere maskiner)
Olav Lysne, SRL & Ifi/UiO 10
Skalerbarhet : utfordringer
Kontrollere kostnader (ressurser)Et system med n brukere er ressurs-skalerbarhet dersom antallressurser som kreves for å underholde dem er høyst O(n)
Kontrollere ytelsestap (når mengden data øker)Et system er ytelses-skalerbart dersom tiden det tar å aksesserehierarkisk ordnede data er høyst O(log n) der n er mengden data
Hindre at systemet slipper opp for programvareressurser:Dimensjonere datastrukturer o.l. slik at systemet kan handterefremtidige krav (vanskelig - jfr IP adresser)
Unngå ytelsesflaskehalserkrever desentraliserte algoritmer (partisjonering, caching ogreplikering)
INF5040 Høst 2003 6
Olav Lysne, SRL & Ifi/UiO 11
Feilhandtering
Maskinvare, programvare og nettverk feiler!!DS må opprettholde tilgjengelighet selv i tilfeller dermaskinvare/programvare/nettverk har liten pålitelighetFeil i distributerte system er partiell
gjør feilhandtering spesielt vanskeligMange teknikker for å handtere feil
Deteksjon av feil (sjekksum o.l)Maskering av feil (retransmisjon i protokoller, replikering …)Tolerere feil (som i web-lesere)Gjenoppretting (“recovery”)Redundans (replikere tjenester på feil-uavhengige måter)
Olav Lysne, SRL & Ifi/UiO 12
HeterogenitetVariasjon og forskjeller som må handteres
nettverk– Internett-protokollen er implementert over mange ulike nettverk
maskinvare– forskjeller i data representasjon til datatyper på forskjellige
prosessoreroperativsystem– API til samme protokoll og tjeneste varierer
programmeringsspråk– forskjellig representasjon av tegnsett og datastrukturer
implementasjon av forskjellige utviklere– sikre at ulike programmer kan kommunisere
• krever enighet om en rekke ting (jfr standarder)
INF5040 Høst 2003 7
Olav Lysne, SRL & Ifi/UiO 13
Transparens
Transparens skjuler konsekvensene avdistribusjonTransparens har forskjellige dimensjoner [ODP]Disse representerer ulike egenskaper et distribuert system kan ha (målestokk for å vurdere design av et system)
Olav Lysne, SRL & Ifi/UiO 14
Aksesstransparens
Muliggjør at lokale og fjerne ressurser/komponenter kanaksesseres ved bruk av identiske operasjonerEksempel: Filsystem-operasjoner i NFSEksempel: Navigering i wwwEksempel: SQL-spørringer i distribuerte databaser
Komponenter som ikke har transparent aksess kan ikkeenkelt flyttes fra en maskin til en annen.
INF5040 Høst 2003 8
Olav Lysne, SRL & Ifi/UiO 15
Lokasjonstransparens
Muliggjør at ressurser/komponenter kan aksesseres utenkunnskap om deres lokasjonEksempel: Filsystem-operasjoner i NFSEksempel: Websider (URLer) i wwwEksempel: Tabeller i distribuerte databaser
Olav Lysne, SRL & Ifi/UiO 16
Andre transparensdimensjoner
SamtidighetstransparensReplikeringstransparensFeiltransparensMigreringstransparensYtelsestransparensSkaleringstransparens
INF5040 Høst 2003 9
Olav Lysne, SRL & Ifi/UiO 17
Distribusjonstransparens
Aksesstransparens
Aksesstransparens
LokasjonstransparensLokasjonstransparens
Migreringstransparens
Migreringstransparens
Replikeringstransparens
Replikeringstransparens
Samtidighetstransparens
Samtidighetstransparens
Skalerbarhetstransparens
Skalerbarhetstransparens
YtelsestransparensYtelses
transparensFeil
transparensFeil
transparens
Olav Lysne, SRL & Ifi/UiO 18
Mål for distribuert mellomvareHøste fordelene ved distribuerte systemSkjule konsekvenser av distribusjon (transparens)Realisere portabilitet og interoperabilitet
Distribuerteapplikasjonerog tjenester
DISTRIBUERT MELLOMVAREPlattformUavhengig grensensitt
PlattformAvhengig grensensitt
. . .Plattform1
Plattform2
Plattformn
- transaksjonsorientert (ODTP XA) - meldingsorientert (IBM MQSeries) - fjerne prosedyrekall (X/Open DCE)- objekt-basert (CORBA, COM, Java)
INF5040 Høst 2003 10
Olav Lysne, SRL & Ifi/UiO 19
OppsummeringDistribuert system:
maskinvare- og programvare-komponenter lokalisert i et nettverk avdatamaskiner som kommuniserer og koordinerer sine aksjoner kun vedå sende meldinger
Konsekvenser av distribuerte systemKomponenter feiler uavhengig av hverandreUsikker kommunikasjon (sikkerhet)Ingen global klokke
Krav som ressursdeling, åpenhet, skalerbarhet, feiltoleranse ogheterogenitet kan tilfredstilles av distribuerte systemMål for distribuert mellomvare
Høste potensielle fordeler av distribuerte system uten å måttebetale for alle dens utfordringer og problemer (transparens)
Olav Lysne, SRL & Ifi/UiO 20
Design av distribuerteobjekter
INF5040 høst 2003
foreleser: Olav Lysne
INF5040 Høst 2003 11
Olav Lysne, SRL & Ifi/UiO 21
Design av distribuerteobjekter
Mange har erfaring med design av lokaleobjekter som alle er lokalisert i kjøretidsomgivelsen til et OO programmeringsspråkDesign av distribuerte objekter er forskjellig! I det følgende: Diskutere de viktigste forskjellene
Olav Lysne, SRL & Ifi/UiO 22
Design av distribuerteobjekter
INF5040 Høst 2003 12
Olav Lysne, SRL & Ifi/UiO 23
Lokale vs distribuerteobjekter
ReferanserAktivisering/deaktiviseringMigreringPersistensLatenstid for metodeanropSamtidighetKommunikasjonSikkerhetMange fallgruber lurer her!!
Olav Lysne, SRL & Ifi/UiO 24
ObjektreferanserReferanser til objekter i OOPS er vanligvis pekeretil primærlageradresser
noen ganger kan de endres til referanser (C++)andre ganger ikke (Smalltalk, Java)
Referanser til distribuerte objekter er mer kompleks
lokasjonsinformasjonsikkerhetsinformasjonreferanse til objekttype
Referanse til distribuerte objekt er større (f.eks. 350 byte i Orbix)
INF5040 Høst 2003 13
Olav Lysne, SRL & Ifi/UiO 25
Aktivisering/deaktiviseringObjekter i OOPS er i primærlageret i tiden fra de opprettes til de slettesDette passer ikke alltid like bra for distribuerteobjekter
antall objekterobjekter kan brukes over lang tidnoen tjenermaskiner må tas ned av og til uten at applikasjonene stoppes
Distribuerte objektimplementasjoner blirlest inn i primærlageret (aktivisering)fjernet fra primærlageret (deaktivisering)
Olav Lysne, SRL & Ifi/UiO 26
Aktivisering/deaktivisering
RBK:FotballKlubbRBK:FotballKlubbHareide:TrenerHareide:Trener
plasserMålvakt
objektaktivisering
objektdeaktivisering
INF5040 Høst 2003 14
Olav Lysne, SRL & Ifi/UiO 27
Aktivisering/deaktiviseringSpørsmål som oppstår:
“oppbevaringssted” for implementasjoner (“repository”)assosiasjon mellom objekter og prosessereksplisitt vs implisitt aktiviseringnår deaktivisere objekter?hvordan handtere samtidige anrop
Hvem bestemmer svarene på spørsmålene over?Designer?Programmerer?Administrator?
Olav Lysne, SRL & Ifi/UiO 28
PersistensTilstandsløse vs tilstandsfulle objekterTilstandsfulle objekter må lagre sin tilstandmellom
objekt-deaktivisering ogobjekt-aktivisering
i et persistent lagerKan oppnås bl.a. ved
lage ekstern representasjon for filsystemavbilde til relasjonsdatabaseobjekt database
Avgjøres ved objekt design
INF5040 Høst 2003 15
Olav Lysne, SRL & Ifi/UiO 29
Objekters livsløpObjekter i OOPS lever i én virtuell maskinDistribuerte objekter kan opprettes på forskjelligemaskinerDistributerte objekter kan kopieres eller flyttes(migreres) fra en maskin til en annenFjerning av objekter ved “søppelsamling” ervanskelig i en distribuert omgivelse
Java RMI: “reference counting”Jini: “leases”
Livsløp må vurderes ved design av distribuerteobjekter
Olav Lysne, SRL & Ifi/UiO 30
Latenstid til anropÅ utføre et lokalt metodeanrop krever noenhundre nanosekunderEt fjernt metodeanrop krever mellom 0.1 og 10 millisekunder, eller mer⇒ grensesnitt til distribuerte objekter måkonstrueres på en slik måte at
metoder utfører større prosesseringsoppgaverde ikke krever svært hyppige anrop
INF5040 Høst 2003 16
Olav Lysne, SRL & Ifi/UiO 31
Parallellitet
Utførelse av objekter i OOPSsekvensiellsamtidig (concurrent) m/flere tråder
Distribuerte objekter eksekverer i parallellKan brukes til å akselerere beregningene
Olav Lysne, SRL & Ifi/UiO 32
Kommunikasjon
Metodekall i OOPS er synkroneAlternativer for distribuerte objekter:
synkrone kall (“synchronous requests)enveis-kall (“oneway requests”)utsatt synkrone kall (“deferred synchronous requests”asynkrone kall (“asynchronous requests”)
Hvem avgjør for hvert kall?designer av tjeneren?designer av klienten?
Hvordan dokumentere?
INF5040 Høst 2003 17
Olav Lysne, SRL & Ifi/UiO 33
SikkerhetSikkerhet i OO applikasjoner kan handteres påsesjonsnivåObjekter i OOPS trenger ikke skrives på en bestemtmåteFor distribuerte objekter
Hvem utsteder metodekallet?Hvordan kan vi vite at klienten er den han hevder å være?Hvordan kan vi avgjøre om vi skal innvilge klienten rettentil å bruke tjenesten?Hvordan kan vi bevise at vi har levert tjenesten for seinere å kunne kreve betaling for bruk av tjenesten?
Olav Lysne, SRL & Ifi/UiO 34
Oppsummering
Design av distribuerte objekter er forskjellig fra design av program der alle objekter er i samme prosessMange fallgruber!!