Distribuerade system och realtidssystem Rapport - Designförslag

Transkript

1 Distribuerade system och realtidssystem Rapport - Designförslag Johan Lindbom Byggning Erik Löthman Kristoffer Hellstrand Henrik Jacobsson Rohith Menon

2 Innehållsförteckning Bakgrund...3 Designens olika faser...4 Initieringsfas...4 Kartläggningsfas...4 Genomsökningsfas...4 Avslutningsfas...4 Teknologier...4 Synkronisering...4 Mutual exclusive åtkomst av data...5 Problem som skapas vid konkurrens av resurser:...5 Beslutsfattning...5 Markov beslutsprocess...5 D*...6 Problemhantering...7 Databashantering...7 Locking and distributed database consistency...7 Referenser...9 2

3 Bakgrund Uppgiften, att skapa en design av ett distribuerat system bestående av noder som söker efter ett gemensamt mål och sammankallar övriga noder till platsen där målet hittades, löser vi med hjälp av ett hybridsystem. Systemet består dels av en central server som tar stora kollektiva beslut och dels av individuella noder som ensamma kan ta beslut som bara gäller dem själva. Servern ska agera samordnare och fördela arbetet mellan noderna. Samtliga noder är utrustade med IR-sensorer som möjliggör en enkel avsökning av det omedelbara området runt noden. Problem Vi ställs inför ett flertal problemställningar när det kommer till konstruktion och implementering av vår design. - Implementera smarta sökalgoritmer i den centrala servern eftersom det är tänkt att den ska dela upp olika sökområden för noderna att behandla. - Vad händer om servern slutar fungera? Grundantaganden inför lösningen: Noderna kommer in från en enda punk i rummet I rummet finns endast ett målobjekt som kan triggas målsensorn För att trigga målsensorn måste en nod åkt över målet Noderna är kalibrerade att röra sig exakt och de har känd hastighet Noderna kan när som helst ange sin exakta position i förhållande till norr Noderna har obegränsat med program- och datalagring Vidare antaganden som gruppen tagit beslut om att använda inför lösningen: Den ungefärliga storleken på rummet är känd. All kommunikation anses vara pålitlig Ytan är plan och de är precis motorisk Målet är lika stort som en nods avsökningsområde, dvs. noden lokaliserar målet om majoriteten av målet finns inom avsökningsområdet. All kommunikation anses vara korrekt. 3

4 Designens olika faser Designen av lösningen kan delas upp i 4 faser; Initieringsfasen som är själva startfasen. Kartläggningsfasen som beskriver hur kartan uppkommer. Genomsökningsfasen, den fas som beskriver hur noderna söker igenom sina respektive områden på kartan och till sist avslutningsfasen som är den sista fasen i designen, där det bestäms vad som händer när någon nod hittat målet. Initieringsfas Vid initiering av systemet så anropar varje enhet servern och anmäler sig, med sitt hårdkodade enhetsnummer, till servern som då tilldelar enheten ett identifikationsnummer. Vid varje överföring av information så identifierar enheten sig m.h.a. sitt id nummer. Kartläggningsfas När noderna skickas in i rummet söker de av med IR-sensor för att få en överblick av det synliga rummet från ingångspunkten. Denna bild skickas till servern som beräknar en passande algoritm för att starta genomsökningen av det hittills kartlagda rummet. Överflödiga noder sätts som inaktiva eller skickas till hittills ej kartlagda områden för att starta ny kartläggning där. Genomsökningsfas När servern bestämt sig för vilken algoritm som skall användas skickas noderna ut för att genomsöka det hittills kartlagda rummet. Detta genomförs tills målet hittats. Avslutningsfas Så fort målet hittats av någon nod så skickas denna information ut till alla noder samt serven och alla noder beräknar kortast väg till målet och ansluter runt det funna målet. Teknologier De olika sätt som noderna kan söka av ett område är många och beror på informationen från nodernas IR-sensorer som skickas till servern. Denna information ger en bild av hur det öppna rummet ser ut, och låter servern dela upp avsökningsområden på ett effektivt sätt. Synkronisering Ett system som löser problemet, med distribuerade noder som i realtid avsöker ett område och sammankallar övriga noder vid funnet målobjekt, kräver att någon form av synkronisering finns till hands för att den gemensamma uppgiften ska kunna lösas. I den design som vi föreslår så kommunicerar varje nod sin position till samtliga medverkande noder. Kommunikationen innehåller även information om målet är funnet och sker via broadcast, vilket minskar belastningen på nätverket i jämförelse med nod-till-nod kommunikation. Samtliga noder i vår design ska även ha en lokalt lagrad karta som synkroniseras och uppdateras kontinuerligt. För att vår design ska fungera tillfredsställande så krävs att all synkronisering och kommunikation sker i realtid. Detta för att nya outforskade områden snabbt ska kunna hittas och servern därigenom ska kunna fördela ut nya arbetsuppgifter. Vidare även för att undvika att noder krockar med varandra, men även för att samling runt målet ska kunna ske så fort det påträffas. 4

5 Systemet arbetar asynkront, det vill säga ingen gemensam klocka finns. Anledningen är att noderna är strikt indelade i individuella avsökningsområden, vilket medför att endast en nod avsöker ett område vid varje given tidpunkt. Problemet med felande noder som inte kan fortsätta sin sökning löses genom att den felande noden fråntas sitt område och det delas ut till någon annan lämplig nod i systemet. Vi ser det inte som nödvändigt att, i efterhand, veta vid vilken tidpunkt som ett visst område har blivit avsökt. Mutual exclusive åtkomst av data Mutual exclusion innebär att en resurs endast kan användas av en process i taget. Det är viktigt att bara tillåta en process i taget att få tillgång av en kritisk resurs för att alltid få förutsedda resultat. Problem som skapas vid konkurrens av resurser: Om flera noder försöker skriva i samma resurs kan det leda till oförutsedda resultat. Om flera noder vill använda en resurs kan det leda till deadlock I vår design kan det uppstå mutual exclusive åtkomst till data när noderna vill skriva kartan i databaserna. Detta löser man med att låsa delar av databasen när någon nod går in och skriver sin uppdatering av kartan. För den konkurrerande åtkomst som kan inträffa så har vi en FIFO gällande schemaläggnings. Alltså den process/nod som är först får använda resursen först. De andra hamnar på kö i den ordning de kommer. Detta för att slippa starvation av någon process/nod. Mer om databaser finns att läsa under rubriken databashantering. Beslutsfattning Rent generellt så agerar servern auktoritärt i beslut som rör alla enheter i systemet, dock så finns det undantagsfall, som t.ex. att en nod ska finna den kortaste vägen till målet. Servern bestämmer under initieringsfasen hur stort utrymme som en nod ska avsöka. Noderna söker igenom området tills målet hittas eller de tilldelade området är genomsökt. När en nod sökt igenom de områden som den tilldelats söker den sig till närmaste gränsområde som ej är genomsökt. När en nod beger sig till ett gränsområde och finner ett område som är möjligt att avsökas av en enskild enhet så tar noden beslutet direkt att själv avsöka området utan att konsultera servern. Om en nod detekterar målet så sänds ett broadcast om dess position, när informationen når varje individuell nod så beräknas den kortaste vägen att bege sig dit med hjälp av D* algoritmen. Markov beslutsprocess För att agera auktoritärt, ta meningsfulla och effektiva beslut, så nyttjar servern Markovs beslutsprocess. Vilket är en mattematisk modell för att modellera beslutsfattning, som delvis kan vara slumpmässig. Vidare så kan beslutsprocessen utvecklas med egenskapen av lärande, alltså algoritmen belönar för val som ger ett bra resultat. I serverns fall handlar det om att ta bra beslut så att så många noder är aktiva så stor del av tiden som möjligt. Samt att ett så stort område som möjligt avsöks under 5

6 en så kort tid som möjligt. Det servern gör mer konkret är att den simulerar olika val och beroende på resultatet så väljer servern att ta just ett val i en given situation. Eftersom algoritmen är en lärande process så lär sig alltså servern att snabbt utvärdera de val som har störst sannolikhet att ge bra resultat. Samt att servern blir adaptiv och dynamisk beroende på omgivningen, alltså att den vänjer sig till en given omgivning efter ett tag och kan då snabbare ta bra beslut. Under tiden servern utvärderar olika beslut och dess utfall så bildas en så kallad Markov kedja, alltså en kedja av beslut och händelser, på så sätt så utvärderas huruvida ett beslut leder till ett effektivt slutförande av en uppgift, t.ex. avsökningen av ett givet utrymme. Markovs beslutsprocess modeleras utifrån fyra komponenter. Den första är en uppsättning med tillstånd som noderna kan befinna sig i. Den andra är en uppsättning med olika handlingar som servern kan göra, alltså ta specifika beslut. Den tredje är en funktion för att beräkna sannolikheten att ett givet beslut vid en tidpunkt kommer innebära ett tillstånd i nästa tidsfas. Alltså ett sannolikhetsvärde som beskriver utfallet av ett beslut. Den fjärde och sista komponenten är en funktion för att beräkna belöningen som skall utdelas, alltså vilka kriterier ett bra beslut skall uppfylla. Grundreglerna för alla de fyra komponenterna programmeras in i servern så att den vet hur den tar bra beslut, vilket därefter förädlas av serven på grund av dess lärande egenskap. De två huvudsakliga situationer som servern agerar i är dels att bestämma vart gränsområden skall dras och dels att bestämma hur noder skall avsöka ett givet område. I det först fallet utvärderar servern utfallet av att dra gränsen på olika sätt. Det huvudsakliga sättet som servern utgår ifrån är att dra en så kort gräns som möjligt, t.ex. i dörröppning. Detta för att uppnå så naturliga och geometriskt enkla områden, för i sin tur att förenkla avsökningen. Med geometriskt enkla områden menas ett område som har en så simpel geometrisk representation som möjligt, t.ex. en rektangel. Alternativet är att servern väljer gränsområden som skapar långa och smala områden för avsökning. Detta leder till att avsökningen kommer att bli ineffektiv. Efter att servern tagit beslut om hur gränsområden ska dras så inleder servern arbetet med att utarbeta en så effektiv avsökningsalgoritm som möjligt. Detta beror givetvis på hur området ser ut, men i det generella fallet så kommer området ha en rektangulär form, med eller utan hinder. Sen beror det givetvis på hur många noder som är tillgängliga. Med avsökningsalgoritm menas alltså hur noderna skall genomsöka området, om de skall åka sick-sack eller om de skall åka på bredd. D* När noderna får uppgiften att bege sig till en position beräknas, som tidigare nämnt, den kortaste vägen med hjälp av D*. Vilket är en dynamisk sökningsalgoritm för att finna den bästa vägen, i detta fall den kortaste, till en given position. Algoritmen använder sig av en kostnadsfunktion för att utvärdera varje väg. Den största anledningen till nyttjandet av D* är just den dynamiska aspekten, eftersom under tiden att en nod beger sig till en slutposition kan en annan nod finna en snabbare väg. Vilket direkt utvärderas av noden som kan byta väg. 6

7 Problemhantering Om servern skulle råka ut för något problem och måste startas om eller den drabbas av driftstopp har varje nod möjlighet att lösa uppgiften med att söka igenom rummet på egen hand utan serverns hjälp. Om servern skulle gå ned detekteras detta av noderna genom att en ACK-timer går ut, att ACK-timern går ut innebär att de tar så lång tid för servern att skicka ett svar om att den tagit emot information som noden skickat att server räknas som offline. I detta fall kommer inte nodernas genomsökning av rummet avslutas utan då kommer noderna att fortsätta med sin uppgift men utan serverns koordinerade funktion och kommer därför att ha en långsammare genomsöknings tid. Om en nod skulle gå ned eller få så stora problem att den inte kan fortsätta sin uppgift skall noden starta om systemet för att se om detta löser problemet, hjälper inte detta sätts noden ur spel och en annan nod tilldelas den trasiga nodens avsökningsområde. Noden betraktas nu som ett hinder och måste samlas in manuellt för reparation efter genomsökningsuppgiften är löst Databashantering Locking and distributed database consistency I ett traditionell centraliserat system skulle en systemkrasch i den centrala noden göra hela databasen onåbar för alla användare. Systemet är även starkt begränsad av prestandan hos central noden vid utförandet av beräkningar. En distribuerad databas å andra sidan är ett decentraliserat system som fördelar dess arbetsbelastning till olika noder som inte är nära sammanbundna. En sådan databas system kan fortsätta fungera trots en icke fungerande central nod (dock med lägre effektivitet). I vårt system finns datan som bygger upp kartan över sökområdet replikerad i flera olika noder. Den distribuerade databasen måste satisfiera två krav, data concurrency och data consistency. I systemet som vi designar kan de kraven översättas till följande: Data consistency: Varje nod har en överensstämmande bild av hur kartan ser ut, inklusive förändringar som noden själv och andra noder har gjort. Data concurrency : Flera noder ska kunna nå informationen i databasen samtidigt. Som nämnt ovan finns den distribuerade kartan replikerad i varje nod. Det förutsätter att när kartan uppdateras så kommer uppdateringen propageras till alla noder så att alla har samma karta, d.vs. man garanterar data consistency i systemet. För att tillfredsställa kravet av data concurrency måste man implementera en distribuerad concurrency control algoritm. En sådan algoritm är Locking. Locks (eller lås) används när flera noder vill ha tillgång till databasen samtidigt. En enskild nod kan endast modifiera de delar av databasen den har applicerat ett lås på. Noden har ensamrätt till de låsta delarna av databasen tills låset är upphävt. Det finns många Locking algoritmer, den vi har valt att använda är 2-phase locking. 2-phase locking möjliggör dead-lock avoidance i ett distribuerat system genom att tvinga en process att frigöra alla resurser den har tagit i anspråk, ifall den processen inte lyckas få tag på alla de 7

8 resterande nödvändiga resurserna från en annan process. Det innebär att ingen process behåller viktiga resurser i väntan på att en annan process blir klar med sina resurser. 2-phase locking är generellt sett inte så bra att använda i en hard-realtime system då man inte kan garantera tillgång till resurser inom en finit tid, vilket kan leda till process-starvation. Som tidigare nämnts är det viktigt att man har data consistency i systemet. Man vill inte att en uppdatering ska ske i endast en kopia av kartbilden. En uppdatering av kartan måste vara korrekt i alla kopior eller så måste uppdateringen avbrytas. De replikerade kartorna måste föra någon typ av dagbok där de berättar vad de har gjort för ändringar och när, på så sätt kan de krascha och starta om utan att man får ickeöverensstämmande data. Noden gör en back-track för att hitta senaste ändringen som implementerades innan krashen och synkroniserar sin logg med den hos de andra noderna. När det är dags att skriva data till databasen som bygger upp kartan används återigen två faser. Startfasen: Noden skriver ner sitt tillstånd i loggen och skickar informationen till andra noder och begär att de skriver informationen och skickar en respons. Insamlingsfasen: Noden samlar in och loggar responsen från de andra noderna. Om alla noder är redo att skriva, skickar noden ett commit meddelandet till alla. Noderna sänder informationen lokalt till sin databas och skickar sedan en avklarat meddelandet till sändarnoden. När sändarnoden samlar in responsen från de andra noderna kan den inte vänta för evigt. Det blir därför nödvändigt att implementera en timeout i startfasen. 8

9 Referenser Performance Evaluation of Locking Protocol for Distributed Information Processing Raymond HL Tsoi GrWith University Computing and Information Technology C. C. Chau Division of Technology City University of Hong Kong Real-Time Lock-Based Concurrency Control in Distributed Database Systems Ozgiir Ulusoy, Geneva G. Belford Department of Computer Science University of Illinois at Urbana-Champaign otes on Two Phase Locking and Commit Protocols Dr. Arnold Neville Pears Uppsala University, Uppsala Department of Information Technology Handbook of Markov Decision Processes Methods and Applications Eugene A. Feinberg SUNY at Stony Brook, USA Adam Shwartz Technion Istrael Institute of Technology, Haifa, Israel 9