introduksjon til distribuerte system (ds) · introduksjon til distribuerte system (ds) inf5040...

INF5040 Høst 2003 1

Olav Lysne, SRL & Ifi/UiO 1

Introduksjon tilDistribuerte System (DS)

INF5040 høst 2003

foreleser: Olav Lysne


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


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


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


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


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


Å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


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


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)


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


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)


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


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)


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


Lokasjonstransparens

Muliggjør at ressurser/komponenter kan aksesseres utenkunnskap om deres lokasjonEksempel: Filsystem-operasjoner i NFSEksempel: Websider (URLer) i wwwEksempel: Tabeller i distribuerte databaser


Andre transparensdimensjoner

SamtidighetstransparensReplikeringstransparensFeiltransparensMigreringstransparensYtelsestransparensSkaleringstransparens

INF5040 Høst 2003 9


Distribusjonstransparens

Aksesstransparens

Aksesstransparens

LokasjonstransparensLokasjonstransparens

Migreringstransparens

Migreringstransparens

Replikeringstransparens

Replikeringstransparens

Samtidighetstransparens

Samtidighetstransparens

Skalerbarhetstransparens

Skalerbarhetstransparens

YtelsestransparensYtelses

transparensFeil

transparensFeil

transparens


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


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)


Design av distribuerteobjekter

INF5040 høst 2003

foreleser: Olav Lysne

INF5040 Høst 2003 11



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



INF5040 Høst 2003 12


Lokale vs distribuerteobjekter

ReferanserAktivisering/deaktiviseringMigreringPersistensLatenstid for metodeanropSamtidighetKommunikasjonSikkerhetMange fallgruber lurer her!!


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


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)


Aktivisering/deaktivisering

RBK:FotballKlubbRBK:FotballKlubbHareide:TrenerHareide:Trener

plasserMålvakt

objektaktivisering

objektdeaktivisering

INF5040 Høst 2003 14


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?


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


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


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


Parallellitet

Utførelse av objekter i OOPSsekvensiellsamtidig (concurrent) m/flere tråder

Distribuerte objekter eksekverer i parallellKan brukes til å akselerere beregningene


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


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?


Oppsummering

Design av distribuerte objekter er forskjellig fra design av program der alle objekter er i samme prosessMange fallgruber!!

introduksjon til distribuerte system (ds) · introduksjon til distribuerte system (ds) inf5040...

Documents