Distribuert system
Begrepet distribuert system , i informasjonsteknologi , indikerer generisk en type informasjonssystem som består av et sett med sammenkoblede prosesser der kommunikasjon kun skjer gjennom utveksling av passende meldinger . [1] Hver node i systemet utfører et sett med komponenter som kommuniserer med hverandre ved hjelp av et programvarelag kalt mellomvare som lar brukeren oppfatte systemet som en enkelt enhet. Begrepet prosess indikerer generelt enhver enhet som er i stand til å kommunisere med en hvilken som helst annen prosess og utføre en distribuert algoritme . I motsetning til en tradisjonell algoritme, er det også nødvendig å inkludere i definisjonen av distribuert algoritme meldingene som utveksles mellom de ulike prosessene, siden de også er essensielle i utførelse og avslutning av algoritmen. Distribuerte systemer oppstår både fra økonomiske og teknologiske behov.
Beskrivelse
Definisjon
Det er flere (mer eller mindre likeverdige) definisjoner av et distribuert system, inkludert:
- «Et distribuert system er et stykke programvare som sikrer at et sett med datamaskiner fremstår som et enkelt sammenhengende system for brukerne av systemet» ( Maarten van Steen , 2016). [2]
- "Et distribuert system består av et sett med autonome datamaskiner, koblet til hverandre via et nettverk og en distribusjonsmellomvare, som lar datamaskiner koordinere sine aktiviteter og dele systemressurser, slik at brukere oppfatter systemet som en enkelt integrert datatjeneste"( Wolfgang Emmerich , 1997). [3]
- "Et distribuert system er et system der feil på en datamaskin du ikke engang visste eksisterte kan gjøre datamaskinen din ubrukelig" ( Leslie Lamport , 1987). [4]
Funksjoner
Blant egenskapene til et distribuert system kan vi nevne:
- Eksternt : komponentene i et distribuert system må kunne behandles på samme måte enten de er lokalt eller eksternt.
- Konkurranse : det er mulig å utføre to eller flere instruksjoner samtidig på forskjellige maskiner; det er ingen verktøy som lar deg administrere synkronisering på en enkel måte (som låser og semaforer i samtidig programmering på multicore).
- Fravær av en global tilstand : det er ingen måte å bestemme den globale tilstanden til systemet ettersom avstanden og heterogeniteten til systemet ikke tillater å definere systemets tilstand med sikkerhet. Mangelen på en global klokke, i denne sammenheng, gjør det umulig å perfekt synkronisere klokkene til alle prosesser, og dette gjør det umulig å bestille, på en presis og entydig måte, alle hendelsene som skjer i systemet. Dette resultatet skyldes de strukturelle forskjellene, for det meste elektroniske, til de forskjellige enhetene for å generere klokkesignalet inne i mikroprosessorene. Forskjeller også på grunn av fysiske parametere som temperaturen knyttet til enheten, brukstilstanden eller enhetens alder.
- Delvis funksjonsfeil : Hver komponent i systemet kan slutte å fungere korrekt uavhengig av de andre komponentene i systemet; dette må ikke kompromittere funksjonaliteten til hele systemet. Prosessfeil kan være av ulike slag, men typisk kan de grupperes i to kategorier: krasjfeil og bysantinske feil. I det første tilfellet har vi at krasjprosessen plutselig slutter å fungere, mens i det andre tilfellet er det generelt umulig å gjøre noen antagelser om årsaken eller virkningene av feilen. I sistnevnte tilfelle er faktisk oppførselen til prosessen som mislykkes på en bysantinsk måte typisk vilkårlig.
- Heterogenitet: et distribuert system er heterogent i både maskinvare- og programvareteknologi . Det er realisert i alle sammenhenger som kommunikasjonsnettverk , nettverksprotokoll , programmeringsspråk , applikasjoner, etc.
- Autonomi : et distribuert system har ikke et enkelt punkt hvorfra det kan kontrolleres, koordineres og administreres. Samarbeid må oppnås ved å sende meldinger mellom de ulike komponentene i systemet og administreres gjennom delings- og tilgangspolicyer som må følges strengt.
- Evolusjon : et distribuert system kan endre seg vesentlig i løpet av livet, både fordi miljøet endres og fordi teknologien som brukes endres. Målet er å imøtekomme disse endringene uten for store kostnader.
- Å være synkron eller asynkron. Denne forskjellen er viktig siden noen problemer innen distribuerte systemer kan løses eller ikke på grunnlag av disse egenskapene. Et distribuert system sies å være synkront når det er mulig å beregne følgende egenskaper, ellers sies det å være asynkront:
- Maksimum og minimum tidsintervall for en prosess for å utføre en instruksjon.
- Det maksimale tidsintervallet for å sende en melding fra kilden til destinasjonen.
- Og det maksimale avviket til verdien av hver lokal klokke (klokkedriftshastighet) med hensyn til sanntid.
Ikke-funksjonelle krav
Realiseringen av et distribuert system innebærer behov for å vurdere andre aspekter, i tillegg til de som er beskrevet ovenfor, som ikke er strengt relatert til systemspesifikasjonene, men som brukes som retningslinjer for design og vedlikehold av distribuerte systemer. Disse aspektene er de ikke-funksjonelle kravene som et distribuert system må oppfylle:
- Åpen : den må støtte portabiliteten av utførelse og interoperabilitet i henhold til kjente og anerkjente standarder både for ikke å knytte systemet til en enkelt leverandør og for å få det til å utvikle seg (ved å legge til nye komponenter).
- Integrert : den må inkorporere forskjellige systemer og ressurser i seg selv uten å måtte bruke ad-hoc-verktøy.
- Fleksibel : den må gi muligheten til å integrere eldre systemer internt og for å kunne håndtere endringer under kjøring ved å rekonfigurere dynamisk.
- Modulær : hver komponent skal være autonom og ha en viss grad av interoperabilitet med resten av systemet.
- Støtte til sammenslutningen av systemer: den må gjøre det mulig å koble sammen forskjellige systemer både fra et administrativt og arkitektonisk synspunkt, for å fungere og tilby tjenester på en sammenhengende måte.
- Skalerbar : det vil si muligheten til å levere samme ytelse, når det gjelder gjennomstrømning og latens, med hensyn til brukere til tross for økt driftsbelastning på systemet. Med økt belastning kan vi mene topper i belastningen på ressurstilgang på grunn av økningen i brukere av systemet som følge av utviklingen i forretningssammenheng.
- QoS : gi tjenester med tids-, tilgjengelighets- og pålitelighetsbegrensninger selv i nærvær av delvise funksjonsfeil som alltid kan oppstå i et distribuert miljø. Denne kvaliteten oppfylles ikke av et sentralisert system som er spesielt intolerant overfor funksjonsfeil.
- Trygg : Uautoriserte brukere må ikke ha tilgang til systemet.
- Gjennomsiktig : de må maskere detaljene og forskjellene i den underliggende arkitekturen, noe som muliggjør enkel planlegging og programmering. Denne åpenheten trenger imidlertid ikke å være total siden den som designer/programmerer et distribuert system må vite at han jobber med eksterne komponenter.
Eksempler
En annen typisk anvendelse av distribuerte systemer er distribuerte datasystemer ( klyngedatamaskiner ) lokalt eller geografisk (f.eks. for distribuert databehandling ) innenfor et datasystem og koblet til hverandre via et lokalt eller geografisk nettverk . Et annet eksempel på et distribuert system er selve Internett , som strekker seg over hele verden, inkludert ressurser som er fysisk svært fjernt fra hverandre, der prosesser med ulike funksjoner og koblet sammen av ulike typer nettverk utveksler informasjonsmeldinger basert på ulike kommunikasjonsprotokoller .
Økonomiske behov
Bedriftsbehov
Markedsøkonomien består av mange og hyppige oppkjøp, integrasjoner, bedriftsfusjoner og nedbemanning . Bedriftenes behov er å kunne utføre disse operasjonene raskt og effektivt ved å integrere, for eksempel i en selskapsfusjon, forskjellige systemer i et enkelt system som er i stand til å administrere begge systemene til de to selskapene eller, ved nedbemanning, opprettholde et visst nivå av integrasjon med resten av selskapene i konsernet i en slags sammenslutning av systemer som kompliserer ledelsen ved å gi for eksempel ulike nivåer av tilgang til systemet: innen selskapet, innenfor forbundet og utenfra .
Markedsbehov
I tillegg til forretningsbehov lar distribuerte systemer deg fremskynde prosessen med å lage og sette et produkt på markedet. Faktisk må markedet redusere Time To Market (tiden for å komme til det endelige produktet) så mye som mulig, og passere gjennom de ulike fasene som unnfangelse, design og konstruksjon. Under implementeringsfasen er det mulig at en funksjon kan implementeres ved å bruke hyllekomponenter (pre-eksisterende komponenter) som imidlertid har forskjeller i både maskinvare og programvare. Distribuerte systemer lar deg integrere hyllekomponenter slik at de samarbeider til tross for implementeringsforskjeller.
Nettverksbehov
Utbredelsen av internett gjorde at ulike tjenester kunne nås av et stort antall brukere gjennom nettverket. En tjeneste kan derfor ha belastningstopper (flere brukere ber om tilgang til denne tjenesten samtidig) kanskje etter positiv annonsering . Hvis tjenesten tilbys ved hjelp av et sentralisert system, vil en stor datakapasitet være nødvendig for å håndtere den store mengden forespørsler; distribuerte systemer lar deg fordele arbeidsmengden på flere datamaskiner for å gjøre tjenesten skalerbar etter hvert som nettverket vokser.
Teknologiske behov
Utviklingen av informasjonsteknologi har alltid vært basert på utviklingen av maskinvareteknologier. Hvert år er det en økning i ytelsen som en maskin kan tilby. Noen empiriske lover beskriver dette fenomenet ved å bruke det både på utviklingen av fysiske komponenter ( Moores lov ) og på veksten av verdien av et nettverk i henhold til lovene til Sarnoff, Metcalfe og Reed . Denne utviklingen har ført til etableringen av metoder for utvikling av komplekse programvaresystemer som kan utnytte disse stadig mer avanserte komponentene best mulig.
Samtidig programmering
Konseptet med et distribuert system kan reduseres til det med samtidig programmering som gjør at arbeidsmengden til en enkelt maskin kan deles på tvers av alle kjernene den gjør tilgjengelig. Tror faktisk at de fleste programmer, til tross for bedre maskinvare, ikke kjører på kortere tid fordi de ikke er skrevet for å tilpasse seg forbedringen av prosessorer.
Integrasjon
Når et system vurderes, er det bygd opp av forskjellige komponenter som har forskjellige egenskaper og ytelser (heterogent system); når du ønsker å øke ytelsen til et system er det mer praktisk å integrere nye komponenter (med høyere ytelse) i stedet for å oppdatere eller gjenoppbygge systemet fra bunnen av. Et distribuert system lar deg ha forskjellige komponenter både fra maskinvare- og programvaresynspunkt. For å integrere ulike systemer ble RM-ODP-standarden introdusert for å løse kommunikasjonsproblemer; denne modellen tar sikte på å abstrahere og standardisere konseptet portabilitet og transparens i et distribuert system ved å inkorporere og utvide ISO/OSI-modellen , ved å bruke sistnevnte som en metode for kommunikasjon mellom heterogene komponenter.
Merknader
- ^ Coulouris et al. , s. 1 .
- ^ Van Steen, Tanenbaum, 2016 , s. 2 .
- ^ Wolfgang Emmerich, Distributed System Principled ( PDF ) , på www0.cs.ucl.ac.uk , University College London , 1997. Hentet 11. august 2018 ( arkivert 28. januar 2018) .
- ^ Leslie Lamport, Distribution ( PDF ) , microsoft.com , Microsoft , 28. mai 1987. Hentet 11. august 2018 ( arkivert 11. august 2018) .
Bibliografi
- George Coulouris, Jean Dollimore, Tim Kindberg, Distributed Systems , 3rd ed., Addison-Wesley, 2001 [1988] , ISBN 0-201-61918-0 .
- ( EN ) Maarten van Steen og Andrew S. Tanenbaum, A brief introduction to distributed systems ( PDF ), 16. august 2016, DOI : 10.1007 / s00607-016-0508-7 . Hentet 11. august 2018 ( arkivert 11. august 2018) .
- ( EN ) Referansemodellen for åpen distribuert prosessering , ISO / IEC 10746-1,2,3,4
Relaterte elementer
Eksterne lenker