Samenvatting Gedistribueerde Systemen. Dumon Willem

Transcriptie

1 Samenvatting Gedistribueerde Systemen Dumon Willem

2 Hoofdstuk 1 Basis 1.1 Karakterisatie v/e Gedistribueerd Systeem Terminologie Gedistribueerd systeem = software/hardware componenten, netwerk & communicatie, coöordinatie via message passing concurrency, gn globale klok & onafhankelijke failures verz onafh pc s die overkomen als 1 systeem Waarom: prijs/performantie ratio: nt lineaire curve maar stijgt zr snel, meerdere CPU s performantie verdubbelen vr dubbele kost als nt tevl overhead (1 pc 100 pc s datacentrum) zinvol vr bepaalde domeinen (versch geldautomaten met CPUs die netwerken met bank, grafische processing, wrgeven v computer animaties) geografische spreiding: elektronische whiteboards, distributed document systems, audio/video conferencing, , file transfer, gaming betrouwbaarheid: wnnr e machine uitvalt blijft totale systeem intact incrementele groei gebruik v Remote Services: web browsing, remote file acces mobiliteit : laptops, Palms, WAP, phones Gedistribueerde functies: Communicatiestructuur: SW vr ondersteuning v/e groep pc s verbonden via netwerk Netwerkbesturingssysteem: elke pc eigen OS, netwerkbs = aanvulling op lokale Gedistribueerd OS: gemeenschappelijk OS gedeeld dr e netwerk v pc s Gedistribueerd algoritme: verz op elkaar afgestemde algoritmen die gebruik maken v message passing om een bepaald doel samen te bereiken (bvb voorkomen dat versch processen dezelfde resources tegelijkertijd gebruiken = mutual exclusion) Interconnectie v CPU s: Flynn Taxonomy SISD = Single Instruction Stream, Single Data Stream (uniprocessor) SIMD = SI, Multiple Data Stream (arrayprocessor) MIMD = Multiple Instruction Stream, MD (parallel & distributed systems) 1

3 Memory: multiprocessors (shared memory, single virtual address) & multicomputers (private memory, private address space) Interconnection: single network bus / switched Coupling: Tight-coupled (short message delays, high BW, total system reliability) & Loosely-coupled (longer message delays, lower BW, realibility expectations on failures) Focus op switched, loosely-coupled multicomputers Internet = intranets geconnecteerd via backbones, met bep services (WWW, , filetransfer) Intranet = verz LAN s geconnecteerd via backbones, via routers aan internet, eigen security policy & admin Mobile computing = transparante toegang tt intranets, toegang tt lokale resources aan remote site Location-aware computing Ubiquitous computing = kleine computerapparaten overal, communicatie tss apparaten Nieuwe toepassingen: Sensor netwerken, Animaties, Multi-Agent systemen (Robotic Soccer) Grid Computing: pc-kr8 even toegankelijk maken als elektriciteit, open standaarden, pcresources niet geadministreerd Cluster Computing: cluster = set v nodes op 1 locatie, grid = meerdere clusters en andere resources (netw n, opslag) Cloud Computing: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) & Software as a Service (SaaS) Parallel Computing: alle cpu s toegang tt shared memory om info uit te wisselen Distibuted Computing: elke CPU eigen ( distributed ) geheugen, info uitwisselen dr message passing Software design v/e Gedistribueerd Systeem 1. Heterogeniteit: versch nivo s (netw, OS, HW, programmeertalen,...) Middleware: Java RMI, CORBA implementatie v/e hoger nivo API 2. Openheid: open systemen laten uitbreidingen v/h systeem toe zonder onderbrekingen en/of duplicatie v bestaande services door uniform communicatie mechanisme & gepubliceerde en standaard interfaces open systemen met heterogene HW mogelijk 3. Security: aanvallen tgn vertrouwelijkheid/privacy, integriteit v berichten, gebruikersauthenticatie, beschikbrheid (onbevoegd gebruik v bronnen: bestanden & printers, Denial of Service (server blokkeren dr overspoelen met requests & mobiele code k onbevoegde operaties uitvoeren)) 4. Schaalbaarheid: kost resources, performantieverlies, uitputting resources (cf IP-adressen), performantie bottlenecks voorkomen replication & partioneren v data, caching & meerdere servers Schalen met zelfde SW als nu? 5. Optreden v falingen (failures): zijn partieel moeilijk te detecteren/behandelen detecteren (vb checksums), maskeren (vb message retransmission), tolereren (vb browser: server not available), herstellen (vb save & restore state) & redundancy: replicating services 6. Concurrency: versch clients willen simultaan toegang tt gedeelde resource gelijktijdige verwerking (nt triviaal & synchronisatie technieken (vb semaphoren)) 2

4 7. Transparantie: systeem = transparant vr feature als deze nt observeerbaar is vr gebruiker v systeem (vb rlogin: lokaal vs remote computer, Java RMI: lokaal vs remote object, GSM: locatie = transparant & adress: netw-locatie transparant) uniformiteit belangrijk vr gebruiker 1.2 Gedistribueerde Architectuur Modellen 1. Software Layers - Lagenmodel: door met layers & services te werken w complexiteit v/e systeem doorbroken: Layer = groep gerelateerde functionele componenten Service = functionaliteit die aangeboden w a/d volgende layer Oorspronkelijk: layers of modules in 1 enkele computer Nu: services/requests tss processen in dezelfde of versch computers 2. Middleware: Verbergen v heterogeniteit, vrziet abstracter communicatiemodel (remote method invocatie (RMI, CORBA, DCOM), groepscommunicatie, notificatie v events, partitioneren & replication v shared data) & vrziet infrastructurele services (naming, transactions, persistent storage) Verz gereedschappen die voorziet i/e uniforme manier & stijl v toegang tt systeembronnen op alle platforms Biedt programmeurs mogelijkheid om toepassingen te bouwen die er nt all1 hetzelfde uitzien & werken mr ook dezelfde manier vr toegang tt gegevens gebruiken, onge8 locatie ervan Beperking: end-to-end argument (communicatie zovl mog tss eindpt n ); sommige aspecten vereisen echter support o/d applicatie-laag 3. Design: meest evidente aspect v gedistribueerd systeemdesign = verdeling v verantw-h n tss componenten (app ies, servers, andere processen...) & de plaatsing v/d componenten over computers i/h netwerk beïnvloedt rechtstreeks performantie, betrouwbrh & veiligheid v/h systeem 4. Overzicht modellen: Client-Server: clients meestal pc s/werkstations vr 1 gebruiker, bieden eindgebruiker zr gebruiksvriendelijke interface. Elke server verzorgt verz gedeelde gebruikersdiensten vr client, biedt vl clients de mog heid toegang tt zelfde databank te delen & maakt gebruik v/e kr8ig pc-systeem vr beheren v/d databank mogelijk server k ook client zijn v/e andere server (vb webserver = client v fileserver) server & client moeten enkel zelfde communicatieprotocollen gebruiken, rest mag verschillen (vb OS, platform) vb databankserver: transacties (query - respons), server verantw vr onderhoud databank, verbinding server-client via software wrmee verzoeken w verstuurd (vb SQL) One-Tier App ie architectuur: pc verbonden via netwerk aan mainframe dat instaat vr presentatie, processing & data Two-Tier App ie architectuur (a) Thin Client: client enkel verantw vr presentatie (UI) k bottleneck maken v mainframe die alles moet processen (b) Fat Client: client verantw vr presentatie & processing updaten v code in clients zr moeilijk & nt gebruiksvriendelijk want versch systemen mog 3

5 Multi-Tier App ie architectuur: SW v/d toepassing verdeeld over 3 types machines: gebruikersmachine (= thin client, UI), Middle-Tiermachine (application server, processing, doorgeefstation, omzetten procollen & versch databronnen samenvoegen & integreren) & Backend server (database server) betere performantie & flexibeler communicatie tss 3 partijen: transacties? Service geïmpl dr meerdere servers: ofwel obj n verdelen over versch servers, ofwel kopie op elke host (betere perfomantie, beschikbrh & fout tolerantie) Proxy servers & caches: bestandscache gebruikt vr opslag v recent gebruikte bestandsrecords, consistent als exacte kopie bevatten v externe gegevens, technieken vr bestands-vergrendeling (mutual exclusion, mr 1 client gelijktijdig per bestand) Web Caching Protocol: browser/proxy valideert resource i/d cache dr vgl ing met origineel i/d web-server o/h moment dat e clientrequest toekomt. Web server kent resources approximate expiry time toe, bij webserverresponse w huidige servertijd & expirytime meegegeven browser berekent leeftijd v/e resource Mobiele code: clientrequest krijgt appletcode trug client interageert met applet snelle interactietijd & applets gelimiteerde access tt lokale bronnen (veiligh ) Mobiele agenten = werkend programma (code & data) dat zich verplaatst i/e netw & autonoom taken uitvoert, meestal in opdracht v andere processen flexibel, besparen op communicatiekost evt bedreiging vr veiligheid v/d server, lokale omgeving afschermen (vb crawlers, web servers) & agenten zelf ook kwetsbaar, zonder toegang gn taken afwerken. netwerk pc = OS en app ies at runtime downloaden thin client = UI op client, app ies op remote pc uitvoeren spontane netwerken ivm mobiele toestellen: services ontdekken registration service (services publiek maken) & look-up service (services ontdekken adhv bep vereisten) Client-Server: 1voudig o/t zetten, services & onderhoud centraal slechte schaling, altijd via breedbandverbinding Peer-to-Peer netwerken: alle processen gelijkaardige rol, werken samen om gedistr processen uit te voeren, gn onderscheid client-server, bronnen delen tss groot # versch pc s complex Design Requirements: Performantie: snelle, consistente antw-tijd (caching & replication), throughput & balanceren v workload QoS: betrouwbrh, veiligh & aanpasbaarheid Afhankelijkh n : correcth, veiligh, omgaan met fouten & appl ies moeten k verder werken ook met fouten in HW, SW of netw n Fundamentele eigensch n v gedistribueerde architecturen Architecturen bestaan uit set v processen die onderling communiceren dr sturen v berichten over pc-netwerk, bel eig n : sync, delays, failures, security: Interaction Model: behandelt performantie & plaatsen v tijdslimieten Processen interageren dr sturen v berichten communicatie (information flow) & coördinatie (synch & ordening). 2 belangrijke factoren: 1. performantie v communicatie: comm-kanaal opzetten dmv streams of simpele message passing over netw performantie criteria: latency (= delay tss start transmissie dr ene process & begin ontvangst dr andere), bandbreedte (totale # info dat overgebr8 k w i/e gegeven tijd, comm-kanalen die hetzelfde netw gebruiken moeten beschikbare BW delen) & jitter (variatie in tijd nodig om e serie v berichten over te brengen) 4

6 2. notie v globale tijd: elke pc eigen interne klok, w dr lokale processen gebruikt wnnr 2 processen hun klok lezen op zelfde moment k dit toch verschillen (= computer clock drift: elke computer klok vertoont e verschil met e referentie-klok), zelfs wnnr klokken op zelfde moment geïnitialiseerd w, zal tijd verschillen want drift is verschillend per pc correcties: GPS met accuraatheid v 1µs 2 varianten: 1. Synchrone Gedistr Systemen (moeilijk te verwezenlijken): tijd om executiestap uit te voeren heeft boven- & ondergrens, bericht bezorgen over kanaal k i/e eindige begrensde tijd & elk proces heeft lokale klok met begrensde drift 2. Asynch GS: gn enkele grens op procesuitvoeringssnelheid, delay v berichten & klok drift-rates. Real-Time ordening v events: alle events & volgorde bijhouden (adhv oorspronkelijke tijdstip v event) juiste ordening ook als versch klokken Failure Model: specifieert fouten die k optreden in processen Omission failure: iets verloren gegaan (vb communication omission failure = dropping messages: onvoldoende buffer ruimte in sender/receiver/gateway & network transmission error, send-omission-, receive-omission-failure) Arbitrary failure: proces stuurt willekeurige berichten op willekeurige tijdstippen proces stopt of neemt foute stap, moeilijk te behandelen Figuur 1.1: Omission & Arbitraty failures Timing failure Figuur 1.2: Timing failures 5

7 Failures maskeren: mogelijk betrouwbare services te bouwen met componenten die onderhevig zijn aan failures, kennis v bep failures v/e component k e andere service toelaten om deze failure te maskeren (verstoppen of omzetten nr e failure v/e ander type). vb: replication als 1 crasht nt alles crasht, checksum: zet arbitrary om in omission (maskeren corrupte berichten) & procescrash maskeren dr proces te herstellen met externe info (vb status vr crash) Security Model: bespreekt mogelijke bedreidingen vr processen & communicatiekanalen, veiligheid v/e gedistr syst k bekomen w dr beveiligen v processen & kanalen die gebruikt w vr interactie & dr obj n die ze bevatten te beveiligen tgn nt bevoegde toegang (dmv access rights, identiteit altijd nagaan & rechten checken, zowel client die server nagaat als server die client nagaat) De vijand modelleren: k berichten met valse source genereren, berichten kopiëren en herzenden, DoS & mobiele code Encryptie, authenticatie, identiteit kennen v/d principal wrvoor proces w uitgevoerd 1.3 TCP/IP Protocol = verz regels & formaten nodig vr comm tss processen met welbepaald doel, omvat specificatie v/e sequentie v berichten die uitgewisseld moeten w & formaat v/d data, w geïmpl dr gekoppelde softwaremodules in zender & ontvanger & laten toe dat versch SW componenten v/h gedistr syst onafh k geïmp w i versch programeertalen op pc s met mogelijk versch data representaties Layer: levert service naar bovenliggende layer & breidt service v onderliggen layers uit Open System Interconnectie (OSI) Model: frameworks wrin protocollen k gedefinieerd w, gn definitie vr e bep protocol Figuur 1.3: OSI vs DoD Model Fysieke laag: fysieke interface tss zendapparaat & transmissiemedium of netwerk, houdt rekening met kenmerken medium, aard signalen & overdr8snelheid Netwerklaag: uitwisseling v gegevens tss eindsysteem & netwerk, specifieke software = afh v/h type netw & versch standaarden (Circuit-, Packet Switching & LAN = ethernet) Internetlaag: procedures nodig om data door versch gekoppelde netw n te laten passeren, w gebruikt vr padbepalings-f tie & in routers Transportlaag: garandeert dat alle geg s bij toepassing o/d bestemming arriveren & dat geg s in juiste volgorde arriveren (mst toegepaste protocol = TCP) Applicatielaag: logica nodig vr ondersteuning v verschgebruikerstoepassingen (vb bestandsoverdracht) IPv6 = functionele verbeteringen tov IPv4: ontworpen vr hoger wordende snelheden v netw n & vr mix v data (stilstaand & bewegend bld), 128bits adres ipv 32bits 6

8 Transport Control Protocol TCP: betrouwbaar end-to-end delivery protocol, basisidee = Zender zendt pakket Ontvanger stuurt bij ontvangst ACK Wnnr zender gn ACK ontvangt, herstuurt hij het pakket Flow control: zorgen dat snelle zender ontvanger niet vooruitloopt # verstuurde pakketten na elke round trip time (RTT) = 1 window, als gn verloren pakketten window +1 per RTT wel verloren pakketten: window gehalveerd per RTT TCP gebruiken als alle pakketten moeten toekomen & delay nt uitmaakt , web browsing (meerdere TCP connecties per pagina) & file downloads CONS, error-checks vertragen overdr8 & stream based User Datagram Protocol UDP: gn garantie ivm aankomst/volgorde, enkel inhoud, CLNS, packet based, wel snelle zend rate Real Time app ies cf VoIP 1.4 Interprocess Communication Middleware = RMI & RPC, request/reply protocol, (un)marshalling & external data representation. Zit tss app ie -laag & UDP/TCP Karakteristieken: zenden/ontvangen omvat synch & datarepresentatie, zenden = bericht aan remote queue toevoegen, ontvangen = v lokale queue halen Synchroon: zowel send als receive zijn blocking: send w8 op corresponderende receive & receive w8 op aankomst bericht, vr elk bericht synch Asynch: send = non-blocking, receive k blocking of non-bl zijn: non-blocking = niet w8en, buffer k in 8rgrond gevuld w ontvanger o/d hoogte brengen. Java mbv multithreads = 1voudiger dan inkomend bericht uit control flow halen Bestemmingen: bericht nr IP & poort (= bestemming binnen pc) sturen poort: 1 receiver, meerdere zenders mogelijk, meerdere poorten per proces mogelijk, transparantie k voorzien w door ondermeer name server/binder & location-independent identifiers mappen nr locaties proces: single entry point per proces vr alle messages mailbox: k vele receivers hebben & message queue Betrouwbaarheid: failures mogelijk (corrupted messages, duplicated messages, omission: loss of messages, messages out of order, receive-process failure) betrouwbare communicatie = nt-beschadigd bericht, in juiste volgorde, zonder duplicaten perfecte betrouwbare communicatie k vaak nt gegarandeerd w Sockets: eindpunt vr comm tss 2 processen: poort + inetadres, receive-methode bevat ook poort & inetadres v zender om te k antw en, poort duidt app ie aan, inetadres (IP) duidt hostsystemen aan 1. Streamsockets: werken met TCP, geeft een verbindingsgerichte, betrouwbare gegevensoverdracht (alle blokken gegarandeerd afgeleverd in juiste volgorde) communicatiekanaal gecreëerd tss sockets: client zendt request tt communicatie nr Server-poort Server accepteert request typisch creëert Server e nieuwe thread die verdere comm afhandelt. berichtgrootte: app ie k zelf kiezen hoeveel data o/d stream k geschreven w, de onderliggende implementatie v TCP beslist hoeveel data gecollecteerd w vraleer te zenden 7

9 berichten: acknowledgement scheme & retransmitting, flow control, duplicatie & volgorde, synch semantics (non-blocking send, uitgezonderd vr flow control (als buffers v zender/ontvanger vol) & blocking receive) gebruikt als betrouwbare message service: garantie op integriteit, geldig (checksums, sequence numbers, timeouts & heruitzending) HTTP, FTP, SMTP wel gn betrouwbare communicatie als verbroken connecties overhead vgl met UDP: buffering, connectie opzetten = extra berichten, zenden = ACK trugsturen, overhead aanvaardbr als slechts enkel bericht versturen 2. Datagram sockets: werken met UDP, bezorging gegarandeerd: berichten: gelimiteerde pakketgrootte (IP laat slechts groottes toe < 2 16, meeste omgevingen laten slechts <2 13 (8kB), grotere pakketten w getrunceerd) & gn conversie bit transmission non-blocking send & blocking receive time-outs: gebruiker k e timeout specifiëren o/d receive operatie receive from any: receive geeft poort + inetadres v zender (sockets k ook gebonden w aan remote (IP-adres + poort)) onbetrouwbare berichten service: verloren, verkeerde volgorde, duplicaten maar gn beschadigde berichten advh checksum enkel inhoud gegarandeerd, transport nt gebruik als occasionele fouten aanvaard overhead vr betrouwbare message delivery: opslaan v state info (source & destination), extra berichten die verzonden moeten w & latency vr de zender Data representatie: nt alle pc s representeren nummers op zelfde manier (big-endian littleendian), progr-nivo: info in data structuren info in berichten = sequentie v bytes Marshalling = info omzetten nr externe datarepresentatie, transmissie data, converteren nr lokale vorm bij ontvangst = unmarshalling info w in formaat v zender doorgestuurd + indicatie v gebruikte formaat vb: CORBA CDR (Common Data Repres = binair formaat, externe data representatie vr gestructureerde & primitieve data types & ondersteunt versch programeertalen), Java Object Serialisatie (binair formaat, obj n omgezet nr extern formaat, type info meegestuurd & all1 Java) & XML (txt-formaat vr gestructureerde data, data vrstellen in web based client server app ies & type info meegestuurd (namespaces)) CORBA = Common Object Request Broker Architecture: ORB = client helpen methode aanroepen in remote object (lokaliseren, activeren & request communiceren) 8

10 Hoofdstuk 2 Remote Communication 2.1 Communicatie patronen Client Server Communicatie Request/Reply Protocol: synchroon, connectie nt altijd nodig, gn flow control, evt. (un)marshalling TCP vaak overkill: reply = enkel ACK = redundant, grootte datapakket gelimiteerd, ontime communicatie verbinding leggen = overkill, gn stream/flow control nodig UDP met geschikte bufferlengte Failure Model: omission failures, gn volgorde time-outs, gn dubbele requests & history v berichten zodat herzenden volledige operatie herdoen vb HTTP: content negotiation, password style authentication, connectie openen request reply sluiten. Get, Head, Post, Put, Delete, Options, Trace RPC exchange protocols: R = Reply, RR = Request/Reply & RRA = Request/Reply/Ack Groepscommunicatie multicast = bericht v/e bepaald proces w nr elk proces behorende tt groep processen gestuurd nuttig als fault tolerance gebaseerd op replicated services, zoeken v discovery services in spontane netwerken, betere performantie dmv replicated data & propagatie v event notifications IP Multicast: multicast groep gespecifieerd dr klasse D inetadres: 1 e 4 bits = 1110 dynamisch membership enkel via UDP op app ie -nivo bijvoegen a/d groep dr socket a/d groep te hangen, mbv Session Directory programma (ook opstarten groep) multicast routers & Time To Live TTL multicast adres allocation permanent/tijdelijk varianten: reliable multicast, totally ordered multicast 9

11 2.2 Remote Procedure Call RPC Gedistr Object systemen: obj n mappen op gedistr services, services modelleren als obj n location & access transparancy (zelfde methodes lokaal als remote), overerving & polymorfisme gedistr object = interface + service implementatie die 1 of meerdere interfaces impl zelfde als gwne obj n : k gebruikt w als parameter & return value, k geactiveerd w, subklassen mogelijk & synchroon geactiveerd MAAR state access enkel via methoden gn constructors invocation: maybe, at-least-once & at-most-once transparantie: verstoppen (un)marshalling, message passing, locatiebepaling & contacteren v remote-object latency, failures parameter passing: by reference ipv by value nieuwe exception types implementatie adhv Object Bus = Stubs (vervangen remote object, voeren RPC s uit, stub in client = proxy, stub in server = skeleton) & Broker (= middlewarelaag, verdeelt invocations) Comm-module: voert request/reply protocol uit volgens juiste semantiek (at-most-once,...) Remote Reference module: verantw vr local/remote object references (adressen geven) Servant: instantie v klasse v/e remote object, handelt remote request af (in server) Figuur 2.1: Implementatie RPC 2.3 Remote Method Invocation RMI Proxy lokaal object mr forward alle berichten nr remote object, zorgt vr transparantie nr client & verzorgt (un)marshalling Server heeft e dispatcher & skeleton vr elke klasse v/e remote object: dispatcher ontvangt request, kiest juiste methode i/d skeleton adhv/d methodid skeleton unmarshalt request & activeert juiste methode i/d servant dynamische proxies/skeletons: interfaces mss nt beschikbaar bij compilen dynamische invocatie via generieke dooperation & dynamisch downloaden v klassen in clients & servers andere: Binder (cf RMIRegistry name server vr RMI), Persistent Object Stores, Location Sevices & Distributed garbage collection (vb remote algoritme dat lease time v object bijhoudt, als client lease time nt vernieuwt wordt obj-referentie verwijderd, coöperatie met lokale GC) 10

12 2.3.1 Java RMI Figuur 2.2: Implementatie RMI RMIRegistry: simpele naming service aan serverzijde, client k zo referentie nr serverobject bekomen Java.RMI.Naming: naming class, methodes om referenties in RMIRegistry op te slaan/af te halen void rebind(string name, Remote obj): gebruikt dr server om remote object te registeren void bind(string name, Remote obj): alternatief void unbind(string name, Remote obj): binding verwijderen Remote lookup(string name): dr client om remote object op te zoeken, referentie w teruggegeven Corba RMI Object Management Group OMG: non-profit org, gesponsord dr 500 org ies, aanpak tt standardisatie, globale doel = theorie & impl v object-technologie promoten vr ontwikkeling v gedistr syst n Common Object Request Broker Architecture: taal onafh & platform afh (ORB impl vr elk nieuw platform vereist) A homogenous view on a heterogeneous world Figuur 2.3: Corba architectuur Interface Definition Language IDL: beschrijft ifaces v lokale obj n op taalonafh manier, w gecompileerd naar bepaalde taal dr IDL compiler, uitkomst hiervan gwn compileren = obj n, clients moeten zich hieraan houden om met serverobj te k comm n 11

13 architectuur, incl services (Naming, Notification, Event - & Security Service) CDR: externe date representatie Internet InterORB Protocol IIOP = protocol wrmee ORB s communiceren over TCP app ie initialiseert ORB en hft interne Object Adapter (reference count, lifetime, policies) Object = programmeerentiteit bestaande uit identiteit, interface en implementatie (defineert de operaties die de IDL ondersteunt) Servant = implementatie v/e object Client = entiteit die operatie invokeert Object Request Broker ORB: Object bus, middleware: transformatie v procesdata v/nr byteinfo die verstuurd w over netw (marshalling/serialization) adhv IDL vorm v gwn object met methodes, e lokaal obj maakt verbinding met ORB wrdoor zijn methodes remote accessible w, ORB verkrijgt adres vr dit (nu remote) obj & zorgt vr interactie tss versch app ies in client/server. voordelen: statische/dynamische method invocations, high-level language binding, zelfbeschrijvend (Interface Repository), lokaal/remote transparantie, ingebouwde security/transacties, polymorfe berichten & coëxistence met bestaande systemen, transparantie nr hostlocatie, OS & programmeertaal onderdelen: ORB kern, IDL, taalmappings, iface repository, proxies/skeletons, dynamische invocatie & dispatch, object adapters & IIOP IDL stubs: statische iface v object services (gedefinieerd adhv IDL), proxy vr remote server obj n IDL Skeleton: statische ifaces vr elke geëxporteerde service (dr server), skeletons gecreëerd dr IDL compiler, zend method invocations nr servant, unmarshalt arg s v requests & marshalt exceptions/resultaten in reply Dynamic Invocation Interface DII: API vr dynamische constructie v object invocations, als client nts weet over object dat het wil invokeren, lijst v parameters marschallen, functie w benoemd en request for service verstuurd naar object server. methoden ontdekken die pas at-runtime k toegepast w, ondernemen v remote call & opvangen v resultaten. Interface Repository: bevat type informatie over alle geregistreerde interfaces (+ ondersteunde methodes & vereiste parameters), raadplegen wnnr client gn proxy bevat vr remote referentie v/e obj. Repository ID = type identifier v/e iface Dynamic Skeleton Interface DSI: run-time binding mechanisme vr servers die methode calls moeten opvangen v componenten die gn IDL-gebaseerde stubs hebben, inspecteert inhoud v/e request om doelobject te vinden, de opgeroepen methode & de bijhorende arg s The Object Adapter OA: behandelt services requests vr server obj n (cf remote reference & dispatcher module) via skeleton biedt run-time environment om server obj n (servants) te instantiëren, requests door te geven & object Id s toe te kennen (de)activeert servants wnnr nodig performantie 12

14 geeft elk CORBA object unieke naam deel v remote object referentie CORBA object = geregistreerd via OA, die via object table CORBA obj n mapt nr servants Portable Object Adapter POA laat app ies & servants toe v ORB s geïmpl dr versch ontwikkelaars Implementation Repository: verantw vr activeren v geregistreerde services op aanvraag & lokaliseren v aanwezige actieve services, OA-naam gebruikt, entry bevat OA-naam, pad nr object impl, hostname & poortnummer server General Inter-ORB Protocol GIOP: CDR, specificaties vr request/reply proctol onafh v OS. = IIOP request/reply als over TCP 13

15 Hoofdstuk 3 Gedistribueerd Procesbeheer 3.1 Procesmigratie = overbrengen v voldoende hoeveelh procestoestand v/d ene nr de andere pc om dat proces uit te voeren o/d doelpc. 1. Argumenten: Delen v belasting, afweging overhead winst Prestatie v communicatie: processen die intensief met elkr communiceren k nr zelfde knooppt w verplaatst, maar voert proces gegevensanalyse uit op 1 bestanden > proces zelf proces nr bestandlocatie verplaatsen Beschikbaarheid: als langdurig proces wil overleven, mogelijk verplaatsen (geplande uitschakeling systeem, gemelde storingen) Gebruik v speciale mogelijkheden: HW of SW v bep knooppt nodig 2. Mechanismen: begin migratie: wie begint = afh v doel: module v OS begint als verdelen v belasting = doel, module mt proces/process n onderbreken, signaliseren & communiceren met andere modules proces begint als doel = bep HW/SW/bronnen gebruiken, proces k zichzelf migreren & mt o/d hoogte zijn v gedistr systeem wat migreren: proces nt kopiëren, enkel procesbeeld (= minstens procescontroleblok PCB, 1voudig te verplaatsen) proces verwijderen & opnieuw creëren, koppelingen mt andere processen bijwerken, adresruimte v proces verplaatsen: eager-all : voll adresruimte overgezet gn enkel spoor v proces op oud syst als adresruimte zr groot & proces grootste deel nt nodig onnodige belasting pre-copy : proces ng steeds uitgevoerd op bronknooppt terwijl adresruimte w gekopieerd gewijzigde pagina s ng eens kopiëren, proces minder lang bevroren & minder lang w8en op uitvoering tijdens migratie eager-dirty : all1 pagina s in hoofdgeheugen & gewijzigde overzetten extra s op aanvraag overzetten & bronpc voortdurend betrokken bij levenscyclus v proces copy-on-reference : pag s all1 overgezet als ernr w verwezen laagste overhead & snel flushing : pag s v proces w gewist uit geheugen v bronpc dr vuile pag s nr hdd te schrijven & nodige pag s w bij bronpc v/d hdd gehaald als nodig ipv uit hoofdgeh gn pag s v gemigreerde proces mr in geh v bronpc geheugenblok direct vr andere process n gebruiken 14

16 berichten & signalen: mechanisme nodig om uitstaande berichten & signalen tijdelijk o/t slaan, nadien naar nieuwe bestemming sturen, evt tijdje info over doorsturen op bronpc bewaren vb migratie (OS AIX v IBM): (a) proces besluit te migreren selecteert doelpc & verstuurt taakbericht (b) ontvangstzijde: kernelserverproces creëert kindproces & geeft info dr nr bronpc (c) nieuw proces haalt gegevens over v oude pc (d) oorspr proces w ingelicht als migratie voltooid, zend voltooiingsbericht nr nieuw proces & vernietigt zichzelf 3. Onderhandelen over migratie Migratiestrategie, scheduling op lange termijn & geheugentoewijzing = verantwh v hulpprogramma Starter, elk Starter-proces bestuurt cluster & 2 Starter-processen moeten het eens zijn over migratiebeslissing 4. Ontruiming Stel pc nt gebruikt processen migreren nr die pc gebruiker meld aan processen lozen om antwoordtijd te garanderen aan gebruiker processen trug migreren nr bronpc 5. Preëmptief - nt preëmptief: preëmptieve procesoverdr8 bij gedeeltelijk uitgevoerde processen & als enkel creatie v proces al voltooid, rest ng nt nt-preëmptieve procesoverdr8 als uitvoering ng nt gestart (gn procestoestand emigreren), nuttig vr verdelen v belasting reageert trager op veranderingen v systeembelasting 3.2 Gedistribueerde globale toestanden OS k onmogelijk huidige toestand v alle processen in gedistr.syst. kennen proces k huidige toestand v alle processen op lokale systeem kennen & externe processen kennen all1 info over toestand via berichten (= info uit verleden!) Voorbeeld slides! termen: Kanaal = tussen 2 processen als deze berichten uitwisselen Toestand v/e proces = reeks berichten die via kanalen dr proces zijn verstuurd & ontvangen Momentopname = snapshot: registreert toestand v/e proces Globale toestand = gecombineerde toestand v alle processen Gedistribueerde momentopname = verz momentopnames, 1 per proces globale toestand = consistent als procestoestand (snapshot) wrin de ontvangst v/e bericht is vastgelegd, het versturen v dat bericht is vastgelegd i/d procestoestand v/h proces dat het bericht hft gestuurd vb slides: inconsistent omdat M 3 ng nt is verstuurd bij snapshot S A maar wel ontvangen w bij S c (fig a), consistent omdat M 3 wel al verstuurd bij S C (fig b, ontvangst ng nt geregistreerd bij S A mr nt belangrijk) Algoritme vr gedistr. momentopname: alg v Chandy & Lamport elementen: processen (p, q,...) met inkomende & uitgaande kanalen, markeerberichten = markers & 2 soorten regels (ontvangen & zenden v markers) start: bep proces start dr zichzelf te registreren & marker te sturen nr alle uitgaande kanalen 15

17 2 regels: markering ontvangen (vb p ontvangt marker v q over kanaal c) & wnnr versturen i f ( p h e e f t z i j n s t a a t nog n i e t g e r e g i s t r e e r d ) p r e g i s t e e r t z i j n s t a a t S p ; p r e g i s t r e e r t de t o e s t a n d v/h inkomend kanaal c a l s l e e g ; p s t u u r t de marker door naar a l l e buren v i a uitgaande kanalen ; p a c t i v e e r t het ontvangen v markers over andere kanalen else p r e g i s t r e e r t de t o e s t a n d v/h kanaal c a l s de r e e k s v b e r i c h t e n ontvangen vanaf S p end i f Algoritme eindigt bij bep proces als marker via alle inkomende kanalen ontvangen 3.3 Gedistribueerde mutual exclusion proces tijdelijk privilege geven (privilege = recht om gedeelde resource te gebruiken) 1. Concepten: dwingend: slechts 1 proces v alle processen met kritieke sectie (KS) vr gedeelde bron/object w tegelijkertijd i/d KS toegelaten veiligheid: (a) proces dat stopt in zijn nt-ks moet dat doen zonder andere processen te verstoren (b) proces dat toegang wenst tt zijn KS mag nt w vertraagd gn deadlock & uithongering levendigheid: als gn enkel proces in zijn KS elk proces dat toegang tt KS verzoekt krijgt zonder vertraging toegang orde & fairness: (a) gn veronderstellingen gebruiken over relatieve snelheden v processen of # processen (b) proces bevindt zich slechts beperkte tijd in zijn KS 2. versch benaderingen vr gedistr algoritmen: gecentraliseerd: 1 centraal knooppt vr toewijzen v toegang tt alle gedeelde obj n all1 centrale knooppunt neemt beslissingen over toewijzen v systeembronnen alle benodigde info w verzameld i/h centrale knooppt, incl info over identiteit & locatie v alle systeembronnen & toewijzingsstatus v elke systeembron overzichtelijk & 1voudig te constateren of wederzijdse uitsluiting nageleefd als centrale knooppt problemen wederzijdse uitsluiting (tijdelijk) nt nageleefd gedistribueerd voorwaarden: alle knoopptn bevatten gemiddeld dezelfde hoeveelh info elk knooppt ziet maar deel v/h totale systeem & moet obv die info beslissingen nemen (want info soms ng onderweg dus info in knooppt nt volledig) alle knoopptn zelfde verantwrdelijkh vr uiteindelijke beslissing uitvallen v/e knooppt leidt doorgaans nt tt uitvallen v totale systeem gn globale, gemeensch klok vr reguleren v tijdstippen wrop gebeurtenissen plaats vinden 3. Gebeurtenissen rangschikken: tijdsrangschikking v gebeurtenissen = belangrijk vr wederzijdse uitsluiting & deadlocks beperking: gn gemeensch klok of synchr-manier v lokale klokken 16

18 mogelijks vertraging tss tijdstip wrop gebeurtenis zich voordeed & tijdstip wrop gebeurtenis w waargenomen (o/e ander systeem) gebrek in synchr k leiden tt verschillen i/h lezen v/d klok op uiteenlopende syst n event (gebeurtenis) = actie die plaatsvindt o/e lokaal systeem (vb proces betreedt/vrlaat KS) maar process n communiceren dmv berichten events koppelen aan berichten Tijdstempeling: events i/e gedistr.syst. gebruikt w gerangschikt & fysieke klokken w nt elk systeem i i/h netwerk beschikt over lokale teller C i, functioneert als klok bericht = (m, T i, i): message + tijdstempel v bericht (= C i ) + id v zender per verzonden bericht (dr systeem i) C i + + (vóór verzending) bij ontvangen bericht (in systeem j) C j = max[c j, T i ] berichten zelfde tijdstempel ordenen op locatie (i < j) Algoritme werkt ondanks verschillen in overdr8stijden tss systemen toegepaste volgorde komt per definitie nt over1 met chronologische volgorde MAAR volgorde bij elk proces wel zelfde 4. Gedistribueerde wachtrij: Systeem bestaat uit N knooppt n (allemaal uniek nr & netw volledig gemaasd), elk knooppt bevat 1 proces dat wederzijdse uitsluiting aanvraagt Berichten w in zelfde volgorde ontvangen als verstuurd & w binnen bep tijd afgeleverd Alle locaties beschikken over kopie v dezelfde w8rij Proces neemt pas toewijzingsbeslissing obv eigen w8rij als het bericht heeft ontvangen v alle andere knoopptn om er zeker v te zijn dat gn ouder bericht, dan bericht bovenaan eigen wachtrij, nog onderweg is Versie 1 = Lamport: array q met 1 vermelding per locatie: q[j] bevat altijd bericht v P j, j=1..n 3 soorten berichten: (Request, T i,i), (Reply,T j,j),(release,t k,k) Algoritme: Stap 1: (Request, T i,i) door P i, neemt dit op in eigen array q[i] & verstuurt bericht nr alle andere processen Stap 2: P j ontvangt bericht, stelt q[i]=(request, T i,i). Als q[j] gn verzoekbericht bevat stuurt P j (Reply,T j,j) naar P i (waardr gn oudere verzoekberichten onderweg zijn bij een beslissing) Stap 3: P i heeft toegang tt de bron als q[i] het oudste verzoekbericht bevat (in elk proces zelfde mutual exclusion) & alle andere berichten in q zijn jonger dan bericht in q[i] ( P i = o/d hoogte v alle verzoeken) Stap 4: P i geeft bron vrij door bericht (Release,T i,i), dit w opgenomen in q[i] Stap 5: P j ontvangt (Release,T i,i) & vervangt q[i] Stap 6: P i ontvangt (Reply,T j,j) & vervangt q[j] eerlijk, mutual exclusion, gn starvation & gn deadlock. 3*(N-1) berichten Versie 2 = Ricart & Agrawala: elimineren v Release-berichten Stap 1: P i stuurt (Request,T i,i) & set q[i] Stap 2: P j ontvangt (Request,T i,i) regels: A. als P j in KS: stel reply uit B. als P j nt w8 op toegang tt KS: (Reply,T j,j) sturen C. als P j w8 op toegang tt KS & verzoek is ouder: stel reply uit en set q[i] D. als P j w8 op toegang tt KS & verzoek is jonger: (Reply,T j,j) sturen & set q[i] 17

19 Stap 3: P i heeft toegang tt bron (= k KS betreden) als elk ander proces heeft geantwoord Stap 4: P i verlaat KS stuur uitgestelde replies eerlijk, mutual exclusion, gn deadlock & gn starvation. 2*(N-1) berichten elk proces moet andere processen kennen & betrouwbare communicatie vereist 5. Doorgeven v tokens: Token = object dat op 1 moment slechts dr 1 proces in bezit k zijn, proces dat token heeft k KS betreden zonder toestemming. Als KS verlaten token doorgeven aan ander proces token[k] = tijdstempel v laatste keer dat token P k bezocht request[k] = tijdstempel v laatste verzoek dr P k Stappen: Stap 1: token initieel willekeurig toegekend Stap 2: toegang tt KS dr P i als i over token beschikt, als nt over token beschikt request nr alle processen Stap 3: P j verlaat KS token toekennen aan ander proces request doorlopen in volgorde j+1,j+2,...,1,2,...,j = ring based token nr proces P k wrvoor request[k] > token[k] N-1 berichten vr requests + 1 bericht om token door te geven = N berichten voldoet aan vw 1 & 4 v voorwaarden om gedistr algoritme te zijn 6. Voting algoritme v Maekawa: communicatie met slechts deelverz v alle processen moet volstaan proces dat in KS wil gaan, moet voldoende stemmen verz n voting set: V i = voting set vr P i i,j: V i V j V i = K P j zit in M voting sets optimale oplossing: K N & M = K B i j i n i t i a l i s a t i e s t a t e := RELEASED; voted := FALSE; P i w i l toegang t t KS s t a t e := WANTED; r e q u e s t s t u r e n naar a l l e p r o c e s s e n i n (V i P i ) ; wachten t t (# r e p l i e s = (K 1)) ; s t a t e := HELD; P j k r i j g t een r e q u e s t v P i i f ( s t a t e = HELD or voted = TRUE) queue r e q u e s t v P i zonder t e antwoorden else s t u u r antwoord naar P i voted := TRUE; end i f a l s P i z i j n KS v e r l a a t s t a t e := RELEASED; M u l t i c a s t r e l e a s e naar a l l e p r o c e s s e n i n (V i P i ) ; P j ontvangt een r e l e a s e v P i i f ( r e questqueue!= l e e g ) remove 1 e u i t queue ( s t e l P k ) s t u u r r e p l y naar P k voted := TRUE; else voted := FALSE; end i f 18

20 deadlock mogelijk Lamport tijdstempel toevoegen aan requests, laagste tijdstempel w 1 st geprocessed, om toegang te krijgen tt KS 2* N berichten, bij verlaten KS N berichten Crash v proces in andere voting set k getolereerd w, betrouwbare communicatie vereist 3.4 Gedistribueerde deadlock 1. Voorwaarden: Wederzijdse uitsluiting: systeembron k mr dr 1 proces tegelijk w gebruikt Vasthouden & wachten: proces k toegewezen systeembronnen vasthouden terwijl het w8 o/h toewijzen v andere bronnen Geen preëmptieve onderbreking: proces k nt w gedwongen systeembron o/t geven Cirkelvormig wachten: gesloten cirkel v processen, waarbij elk proces minstens 1 bron vasthoudt die nodig is vr volgende proces i/d cirkel 2. vb: Phantom Deadlock: 3 processen w8en op elkaars bronnen, P 3 geeft zijn bron vrij en stuurt bericht daarvoor, maar vraagt ook de bron v P 1. vrijgeefbericht w 1st ontvangen gn probl request-bericht w 1st ontvagen deadlock echte deadlock want gn globale toestand 3. Deadlock voorkomen: cirkelvormig w8en vrkomen dr lineaire rangschikking v brontypen te definiëren, is bron R toegewezen proces k enkel bronnen die volgen i/d rangschikking op R aanvragen nadeel: bronbehoefte moet vooraf gekend zijn vasthouden & w8en vrkomen dr te eisen dat e proces alle benodigde systeembronnen in 1x opvraagt & proces te laten w8en tt dat alle aanvragen gelijktijdig toegekend k w nadeel: bronbehoefte moet vooraf gekend zijn 4. Deadlock vermijden: tijdstempels gebruiken vr transacties oud proces (O) & jong proces (Y) Figuur 3.1: Wait/Die vs Wound/Wait elk knooppunt moet globale toestand v systeem i/d gaten houden controleren o/e veilige globale toestand moet wederzijds exclusief zijn controleren of het veilig is verzoek toe te kennen vereist extra verwerkingskr8 vr gedistr syst met groot # processen & systeembronnen 5. Deadlock detectie: elke locatie heeft all1 info over de eigen systeembronnen deadlock heeft mogelijk betrekking op gedistribueerde systeembronnen Centraal beheer: 1 locatie verantw vr deadlockdetectie Hiërarchisch beheer: deadlock w ontdekt op knooppt dat dient als gemeenschappelijk vertakkingspunt vr locaties wrtoe systeembronnen behoren die het conflict veroorzaken Gedistribueerd beheer: alle processen werken samen bij deadlockdetectie 19

21 vb: elke transactie j heeft 4 parameters: T i = unieke identificatie v/d transactie Held by(t i ) = nil als transactie in uitvoering of gereed. zo niet = id v transactie die beschikking heeft over object dat T i nodig heeft Wait for(t i ) = nil als T i nt w8 o/e andere transactie. Anders = id v transactie die als 1e staat i/e geordende lijst v geblokkeerde transacties ( Held by(t i )!!) Request Q(T i ) = w8rij v alle uitstaande requests vr obj n vastgehouden dr T i, indeling (D k,t k ) met T k = object dat D k wenst 6. Deadlock bij berichtencommunicatie: Wederzijds wachten: deadlock treedt op bij berichtencommunicatie wnnr alle leden v/e groep processen w8en o/e bericht v/e ander proces i/d groep & er gn berichten onderweg zijn Afhankelijkheidsverz DS(P i ) = alle processen wrvan P i e bericht verw8 deadlock i/d verz S als (a) alle processen in S zijn gestopt in afw8ing v berichten (b) S bevat de afhankelijke verzameling v alle processen in S (c) gn berichten onderweg tss leden v S deadlock als de opvolgers v 1 v/d leden v S zelf ook deel uitmaakt v S, cf figuur 3.2 Figuur 3.2: geen resp wel deadlock bij berichtencommunicatie Niet-beschikbare berichtenbuffers: 3.5 Elections betrekking op toewijzen v buffers vr berichten die onderweg zijn, komt vl vr in datanetwerken vb directe deadlock: bufferruimte vr A zit vol met pakketten vr B en omgekeerd & gn v/d 2 accepteert berichten omdat buffers vol nt toestaan buffer gebruikt vr 1 verbinding vb indirecte deadlock: buffers vol met berichten vr volgende node i/d rij gestructureerde bufferpool gebruiken = hiërarchisch (buffer vullen adhv # hops al afgelegd, alles vol tem k hops = gn berichten aanvaarden die < k hops gedaan hebben) election algortime = proces kiezen uit groep v processen o/e bepaalde rol te spelen, versch processen k gelijktijdig de stemming starten hoofddoel = unieke keuze maken & proces met grootste identifier kiezen id moet uniek zijn & moet k geordend w (vb proces-id, proces kiezen met laagste belasting id = < 1 load, i > zelfde load = ordenen adhv proces-id) P i heeft variabele elected i, initieel = (ng nt geset) & requirements: E1 (safety): e deelnemend proces P i elected i = of elected i = P met P proces met hoogste identifier 20

22 E2 (liveness): alle processen nemen deel a/d verkiezing & uiteindelijk moet elk proces elected kiezen of crashen Bully election: elk proces heeft identifier, proces k falen tijdens election, elk proces k election starten (initiator), betrouwbare communicatie & proces weet welke processen hogere identifier hebben doel: proces met hoogste identifier dat ng actief is moet dr ieder proces als coördinator gekozen w 3 soorten berichten: election: gestuurd dr initiator nr elk ander proces met hogere identifier response: antw op election coördinator bericht: verstuurd dr proces dat verkozen is tt coordinator nr alle processen met lager id gecrasht proces dat w heropgestart stuurt election bericht, onafh v wel/geen coördinator (= BULLY) proces dat election bericht (v processen met lager id) ontvangt stuurt reply en start zelf election om te kijken of er gn processen zijn met hogere id of hemzelf initiator: als gn reply ontvangen binnen (2T tr + T pr ) zelf coördinator (T tr = tranmissietijd, T pr = tijd nodig om bericht te processen) als reply ontvangen is er proces met hogere identifier als gn coördinator bericht ontvangen na bep tijd nieuwe election opstarten Ring based election: nodes in ring verbonden, betrouwbare communicatie in wijzerzin, elk proces k election beginnen 1. initieel elk proces gemarkeerd als nt-participerend 2. initiator markeert zichzelf als participerend dr identifier in election bericht te plaatsen nr buurman zenden 3. bij buurman: ontvangen id > eigen id doorsturen & zichzelf op participerend zetten ontvangen id < eigen id & ontvanger participerend eigen id in election bericht, doorsturen & zichzelf op participerend zetten ontvangen id < eigen id & ontvanger = participerend bericht nt doorsturen ontvangen id = eigen id coördinator zichzelf op nt-participerend zetten & elected bericht nr buurman sturen 4. elected bericht ontvangen zichzelf op nt-participerend zetten & elected i op id v coördinator zetten & doorsturen (als nt zelf coördinator) 21

23 Hoofdstuk 4 Shared Data 4.1 Transacties doel: synchr ie op hoger niveau brengen transactie = set v operaties die logisch gezien bij elkaar horen, atomair Begin transaction markeer de start End transaction markeer het einde & poging tot commit (= transactie effectief uitvoeren) Abort transaction kill transaction & herstel originele toestand (= startsituatie) Read data - write data Statements, procedure calls,... complexiteit: mr dan sequentie v operaties specifieer welke operaties deel uit maken v/d transactie transactie moet telkens correct uitgevoerd w, zelfs wnnr vl transacties samen op zelfde data uitgevoerd w transacties nooit partieel uitgevoerd, maar atomair zakelijke transacties moeten bij wet op papier bekrachtigd w, elektronische ook! transactie systemen zijn veeleisend: high throughput, snelle responstijd, highly available Database Managementsysteem DBMS: verantw vr lezen v & schrijven nr databank nood aan gelijktijdigh: terwijl databank iets uit geheugen haalt k CPU SQL-statements v andere transacties parsen & compileren Eigenschappen: Eig. 1 = Atomair: transactie = enkelvoudig, nt opdeelbaar wnnr ze ofwel volledig uitgevoerd, ofwel nt uitgevoerd w alles of niets als transactie T commits gebruiker k zkr zijn dat alle acties v T o/d databank uitgevoerd w transactie T k onderbreken (abort) of onderbroken w gebruiker k zeker zijn dat de acties die eventueel al ondernomen w ongedaan w gemaakt alsof T nooit opgestart w local recovery = verantw vr elimineren v partiële resultaten 22

24 Eig. 2 = Consistent: wnnr bij begin transactie db = consistent, na toepassing transactie db = consistent, verantw v/d app ie transactie k fouten introduceren systeem moet integriteitschecks voorzien & k transactie verwerpen Eig. 3 = Isolation = serialiseerbrh: gebruikers k 1 transacties gelijktijdig comitten, mr elke gebruiker denkt dat zijn transactie geïsoleerd gebeurd DBMS laat meerdere transacties gelijktijdig toe op dezelfde data CPU blijft draaien & meer transacties/tijds1heid Concurrency Control Protocol: schedule v orders die serializable is (netto effect v transacties in bep volgorde sequentieel verwerken = gelijk) Eig. 4 = Durability: garantie dat eens transactie T uitgevoerd, resultaten zijn blijvend optreden v/e failure na commit mag gn effect hebben o/d resultaten v transactie bij optreden failures: global recovery procedure opstarten: Server Crash: databank opnieuw consistent brengen transacties ng in executie ongedaan maken Disk Crash: replicatie backups & mirrors 4.2 Concurrency control Meerdere transacties gelijktijdig k uitvoeren transacties schedulen zodat effect op gedeelde data serieel equivalent zijn (serializability) = steeds sequentiële volgorde v transacties vinden zodat effect op data hetzelfde is toestand v data mag nt i/e vorm zijn die nt dr sequentieel toepassen v/d transacties te bereiken is (vb 2 transacties die data gelijktijdig wijzigen) Concurrency control = proces dat verantw is vr genereren v serializable schedule Lost update problem: 2 bankrekeningen, 2 transacties die geld gelijktijdig toevoegen incorrect omdat update v 1e transactie overschreven w door 2de transactie. Inconsistent retrievals: 2 bankrekeningen, totaal v allemaal berekenen en erna ng 100 bijzetten bij 1 v/d 2 Serial equivalence: 1e transactie doet alles op bep rekening, vr 2de transactie iets erop doet serieel equivalente transacties als alle paren v conflicterende operaties v/d 2 transacties op alle obj n in dezelfde volgorde w uitgevoerd obj n in zelfde volgorde benaderen Figuur 4.1: Read & Write operation conflict regels dirty read: T2 leest data in, voordat T1 zijn operaties gecommit heeft op die data (door isolatie-eigensch) T1 & T2 aborten = cascading aborts read/write conflict (unrepeatable reading): T1 leest 2x zelfde data uit, mr tss deze 2 reads wijzigt T2 de data overwriting uncommited values: T1 past data aan, T2 past data aan vr T1 commit, net alsof T1 nt heeft plaatsgehad 23