Fog computing tillhandahåller en distribuerad infrastruktur i utkanten av nätet, vilket resulterar i låg latent access och snabbare svar på ansökningar. Omputeringskraven för mobila användare fortsätter att öka, eftersom dator- och kommunikationskapaciteten hos smarta och bärbara enheter och system i fordon fortsätter att förbättras. Många applikationer förlitar sig på fjärrresurser för att avlasta och slutföra uppgifter, främst genom användning av en storskalig datoranläggning som finns i ett datacenter. Sådana molnsystem kan också stödja applikationer genom att lagra data M A R C H /A P R I L 2 0 1 7 I E E E C LO U D CO M P U T I N G 2 7 och bearbeta uppgifter som avlastas av mobila eller fasta enheter. Med ökande fokus på Internet-of-Things (IoT), otaliga enheter utspridda och anslutna till Internet, producerar och konsumerar data kräver skalbar resurshantering på aldrig tidigare skådade nivåer. 1 Datadynamiken och heterogeniteten till följd av denna förväntade explosionsexpansion av anslutna enheter, vanligen kallade Big Data, kräver också nya bearbetningsmodeller och infrastrukturer för att stödja dess huvudsakliga dimensioner: datavolym, hastighet och variation. En viktig aspekt av denna nya era är att både dataförbrukning och produktion är kraftigt fördelade och i nätets kanter (dvs. Närmre eller vid slutanvändarenheter). Medan den centraliserade datacentermodellen för molndata kan hantera många typer av applikationer och stora mängder data, är dess infrastruktur och nätverksanslutning till kanten inte utformade för att hantera detta Big Data fenomen. I detta sammanhang är dator- och datahanteringsmodeller som stöder datorkapacitet i nätets utkanter nu föremål för betydande forskning. Mobila moln, fordonsnätverk och dimdata är exempel på nya distribuerade datormodeller som utnyttjar kantkapaciteten närmare dataproduktionen. Med data som också produceras i utkanten kan både datagenerering och konsumtion förekomma på många olika platser och tider. I detta sammanhang kan olika tillämpningar ha olika krav, särskilt när det gäller svarstid. För närvarande är applikationer ofta beroende av molnet för att ha data och bearbetningsstöd, vilket kanske inte är lämpligt för lägre latenskrav. Dessutom, utförande av applikationer i molndatacenter tar inte hänsyn till användarens rörlighet, och data eller behandling av en ansökan kan ske på en geografiskt avlägsen datacenter. Å andra sidan, i ett distribuerat datorscenario vid nätets kanter, kan datadistribution och behandling upprätthållas närmare användaren, minska nätverkstrafiken till datacenter och förbättra applikationens svarstider till följd av lägre nätlatens eller fördröjning. Detta dokument diskuterar problemet med resursfördelning med tanke på den hierarkiska infrastrukturen som består av kantkapacitet och molndatacenter, analysera programklasser tillsammans med olika schemaläggningspolicyer. För att ta itu med denna utmaning inför vi ett antal schemaläggningsmetoder som tar hänsyn till användarens rörlighet och kantdatorkapacitet, inom ramen för en Fog Computing-infrastruktur. 1 Vi diskuterar fördelarna med att kombinera applikationsklasser med schemaläggningspolicyer i scenarier som illustrerar dessa schemaläggningsmetoder, särskilt i samband med användarrörlighet. I nästa avsnitt presenteras den dimdatamodell som behandlas i detta dokument och därefter diskuteras därmed tillhörande arbete. Därefter introducerar vi ansökningsmodellen och två exempeltillämpningar, som används i utvärderingen vidare i dokumentet. Därefter presenterar vi olika fördelningspolicyer och simuleringsresultat. Sedan diskuterar vi resursfördelningsutmaningar för dimdata. Användarprogram som får tillgång till det publika molnet gör det genom en åtkomstpunkt som gör det möjligt för datautbyte via stamnätet att nå molndatacentret. Med införandet av datorkapacitet i utkanten av nätet kan dessa åtkomstpunkter utvidgas till att även tillhandahålla data- och lagringstjänster: molnen. Figur 1 illustrerar molnmolnskonceptet inom dimmans hierarkiska infrastruktur. Denna dimdataarkitektur presenterar en hierarkisk, dubbelriktad datorinfrastruktur: kantenheter kommunicerar med moln och molnmoln kommunicerar med moln. Cloudlets kan också kommunicera med varandra för att utföra data- och processhantering för att stödja tillämpningskrav, och för att utbyta dimstyrning/hanteringsdata (såsom användarenhet och applikationstillstånd). I dimma databehandling, bearbetning och lagring kapacitet är ett hopp bort från produktionen/konsumtionen av data, som kan gynna olika typer av applikationer • Applikationer med låga latens krav, såsom fotgängare och trafiksäkerhet, övervakning, applikationer för syn, hörsel, eller rörelsehindrade användare, onlinespel, förstärkt verklighet, och taktil databehandling kan dra nytta av lägre latens på grund av en enda humleanslutning till en cloudlet. • Applikationer som för närvarande förlitar sig på molnet kan också dra nytta av lägre förseningar och svarstider när man antar en dimbaserad distribution om deras data och behandling utförs av en närliggande cloudlet. Detta kan också minska datatrafiken till molnet. • Råa data som samlas in av många enheter ofta inte behöver överföras till molnet för långsiktig lagring: data kan behandlas, filtreras, eller aggregeras för att extrahera kunskap och producera reducerade datamängder, som i sin tur ska lagras, eller det kan behandlas och användas direkt till andra kantenheter i den så kallade sensor / aktuator loopen. I båda fallen kan dimdataparadigmet minska nätverkstrafiken från kanten till datacenter. Cloudlets kan ge minskad latens och hjälpa till att undvika/minska trafikstockningar i nätets kärna. Detta kommer dock till ett pris: det behövs mer komplexa och sofistikerade resursförvaltnings- och planeringsmekanismer. Detta medför nya utmaningar att övervinna, t.ex. att dynamiskt bestämma vad, när och var (enhet/fog/moln) ska utföra behandlingen av förfrågningar för att uppfylla deras kvalitet på tjänsterna. Med smarta och bärbara anordningar måste sådana mekanismer dessutom införliva datakällornas rörlighet och sänkor i dimman. Traditionell resursförvaltning och schemaläggningsmodeller för distribuerade system tar inte hänsyn till rörlighet och aktualitet för dataproduktion och -konsumtion i resurshanterings- och tilldelningsprocessen. Schemaläggning av fogdata måste föra användarna till resursfördelningspolicyerna för att upprätthålla fördelarna med dimdatorns närhet till användaren. Resurshantering och schemaläggning inom dimdata är ett nytt ämne som kombinerar aspekter från sensornätverk, cloud computing, mobil databehandling och genomträngande datafält. I dimma beräkning, sensorer och andra enheter genomträngande närvarande vid kanten av dimman generera data och konsumera data som måste behandlas med molnen och molnen. Vart och ett av dessa fält har en uppsjö av litteratur, väldokumenterad av forskare. 3, 4, 5 Fog computing har diskuterats som en plattform för att ge stöd för Internet of Things (IoT) och analys. Bonomi m.fl. diskutera många aspekter av en diminfrastruktur, inklusive samspelet mellan dimma och molnsystem. Författarna hävdar att dimma databehandling kan bättre adressera applikationer och tjänster som inte passar bra i molnet, såsom låg-latens eller geo-distribuerade program. I detta dokument främjar vi denna diskussion genom att införa strategier som kan antas i närvaro av olika tillämpningsklasser. En programmeringsmodell har föreslagits för att stödja dimdatatillämpningar, som omfattar händelsehanterare och ett programprogrammeringsgränssnitt (API). 6 Programmeringsmodeller kompletterar det presenterade arbetet, eftersom de förlitar sig på programplaneringsstrategier för att avgöra var de funktioner som skapas av användarna ska fördelas. GigaSight är en virtuell maskinbaserad molnbaserade infrastruktur som används för att stödja videolagringsanalys vid kanten. 7 En motivering till förslaget är att undvika överväldigande storstadsnätverk med en stor mängd videoströmmar som skickas till molnleverantörer. GigaSight program kan dela molnen med andra typer av program, där en korrekt resursfördelning kan förbättra prestanda. Jennings och Stadler 3 diskuterar resurshanteringsmål och utmaningar inom cloud computing. Många aspekter täcks av dem, bland annat resurshanteringsfunktioner och resursallokering i nätverk, som också är relevanta för dimdata. Kantanordningar i dimman medför särskilda egenskaper som måste beaktas, bland vilka tillämpningskrav och rörlighet diskuteras i resten av detta dokument. Multi-moln är plattformar som aggregerar dataresurser från olika molnleverantörer. Medan multi-moln kan hjälpa till att minska latenser till slutanvändarna, de kan inte ge riktigt låga latenser som de som förespråkas av dimma dator med sin 1-hop bort cloudlet infrastruktur. Den hierarkiska kombinationen av dimma och moln (stå ensamma eller federerade) ger därför fortfarande fördelar när det gäller latens och nätverkstrafik. Europeiska institutet för telekommunikationsstandarder (ETSI) har lanserat initiativet Mobile-Edge Computing (MEC) för att skapa standarder för mobila datorplattformar, efter att ha föreslagit en plan 9 och även dokument med tekniska krav, terminologi och tjänstescenarier. En första specifikation förväntas levereras i slutet av 2016. När det gäller resursfördelning och schemaläggning är det viktigt att avlasta beslut i mobila enheter. 5 Kosta m.fl. presentera ThinkAir, ett ramverk för att avlasta mobila applikationer till molnet. 10 ThinkAir kan parallellisera utförandet med hjälp av virtuella maskiner, uppnå förkortade utförandetider och energiförbrukning i den mobila enheten. I ett dimdatascenario bör de avlastade modulerna fördelas enligt tillämpningskraven, vilket vi diskuterar vidare i detta dokument. Dimarkitekturen är hierarkisk, där beslut om bearbetnings- och lagringsplats omfattas av tillämpningsbegränsningar och användarens geolokalisering. Medan den förra kan specificeras på olika sätt, som i form av kvalitet på tjänsten (QoS) begränsningar, den senare beror på mänskliga (eller andra autonoma system) beteende. I slutändan bestämmer användarens beteende tid och position för en datorenhet, som tillsammans med QoS-begränsningar kan användas för att skapa programklasser som är relevanta för resurshantering och schemaläggning i en dimdatormiljö. Genom att erkänna olika programklasser kunde man använda olika schemaläggningsprinciper, algoritmer eller mekanismer för att hantera varje klass. För att illustrera hur resurshantering i dimma dator kan gynna applikationer genom att överväga geolokalisering och olika programklasser, identifierar vi två typer av appar: nära realtid och delay-tolerant. För det förra beskriver vi det elektroencefalografiska (EEG) traktorstrålspelet; för det senare ett program för videoövervakning/objektspårning. I EEG traktorstrålspelet (EEGTBG) försöker spelarna samla föremål genom att koncentrera sig på dem. En spelare som har en bättre koncentration på ett objekt kan locka det mot sig själv. Snabb bearbetning och låga svarstider som uppnås av edge computing-enheter kan ge spelarna en sann online-upplevelse i realtid. EEGTBG-applikationen har 5 moduler EEG-sensor, display, klient, koncentrationsräknare och koordinator. EEG-headsetet känner av användarens koncentration och strömmar rådata till klientmodulen. Kundmodulen filtrerar/ vidarebefordrar konsekventa data till koncentrationsräknaren, som beräknar användarens koncentrationsnivå. Koncentrationsnivån skickas till klientmodulen, som uppdaterar speldisplayen till spelaren. Koordinatormodulen samlar och distribuerar uppmätt koncentration mellan spelare. EEG-sensorn, displayen och klientmodulerna placeras i den mobila enheten (t.ex. smartphone). Koncentrationskalkylatorn och koordinatormodulerna kan placeras i molnen eller i ett molndatacenter. Programmet för videoövervakning/objektspårning (VSOT) bygger på en uppsättning distribuerade intelligenta kameror som kan spåra rörelser med 6 moduler (se figur 2): kamera, rörelsedetektor, objektdetektor, objektspårare, användargränssnitt och panor, lutning och zoomstyrning (PTZ). Kameran strömmar video till rörelsedetektormodulen, som filtrerar inkommande ström och vidarebefordrar video där rörelse detekterades till objektdetektormodulen. Objektdetektormodulen identifierar de rörliga objekten, skickar objektidentifikation och positionsinformation till objektspåraren, som i sin tur beräknar den önskvärda PTZ och skickar kommandot till styrmodulen PTZ. Vi anser att rörelsedetektorn och styrmodulerna för PTZ alltid placeras i kameran, medan användargränssnittet alltid finns i molnet. Objektdetektorn och objektspåraren är de två moduler som ska placeras genom beslutspolicyer i ett moln eller i ett molndatacenter. Båda applikationerna -EEGTBG och VSOT - kan installeras i en diminfrastruktur för att dra nytta av lägre latens på grund av användning av cloudlets. VSOT kan arbeta tillfredsställande under datacentral- distans latenser (> 100 millisekunder). Å andra sidan kan större förseningar i EEGTBG påverka spelarnas uppfattning i realtid, vilket gör spelet overkligt och försämrar dess spelbarhet. Vi anser att VSOT 30 och EEGTBG tillhör två olika typer av tillämpningar (fördröjningskänsliga och fördröjningstoleranta) som kan dra nytta av en dimdatainfrastruktur. Med den snabba användningen av mobila (smarta) enheter måste infrastrukturen för dimdata kunna tillgodose varierande krav i molnen, samtidigt som den förlitar sig på elasticitet i molndatasystem för att avlasta bearbetning och/eller lagring vid behov. Detta scenario illustreras i figur 3, där tre moln är anslutna till en gateway som ger tillgång till ett moln-baserat datacenter. För illustrationsändamål, låt oss anta att Cloudlet 2 ligger i en stadskärna och det stöder ett antal smarta kameror som kör VSOT-programmet. Låt oss också anta att de två andra molnen ligger längs en stig mellan förorterna och stadens centrum. Under rusningstid (till exempel) brukar användare gå mot centrum, och därmed Cloudlet 2 kommer att få mer belastning från inkommande användare. I vårt scenario kännetecknas denna belastning av EEGTBG-spelare med sina smarta telefoner. Om många EEGTBG-spelare flyttar till den region där Cloudlet 2 ligger kan det bli överbelastat (processor, lagring och/eller nätverk). I idealfallet bör Cloudlet 2 ha tillräcklig kapacitet för att hantera lasten från alla sina användare, inklusive de ytterligare EEGTBG-användare som rör sig mot sin region. Men under många timmar på dagen detta moln skulle underutnyttjas av VSOT-applikationen ensam, vilket skulle innebära lågt resursutnyttjande och onödig energiförbrukning, förutom potentiella drifts- och underhållskostnader. För att undvika sådant avfall i resursanvändning kan Cloudlet 2 planeras för att stödja efterfrågan på applikationer i den lägre delay-klassen, och samtidigt köra andra program när det är möjligt. Därför bör resurshanteringsstrategier för att fördela resurser mellan molntjänster och molntjänster kunna hantera varierande efterfrågan samtidigt som hänsyn tas till tillämpningars egenskaper och användares rörlighet. Olika tillämpningskrav tillsammans med dimmans mobila karaktär kräver en förbättrad policy som kan optimera resursutnyttjandet och erbjuda servicekvalitet i enlighet därmed. Vi illustrerar hur tre olika schemaläggningsstrategier kan påverka applikationers servicekvalitet i en dimmetisk Concurrent, First Come-First Servering (FCFS) och Delayy-priority-strategier. Jämförelsen är avsedd att visa hur prioriteringen av applikationer med låga fördröjningar (fördröjningsprioritet) skulle förbättra tillämpningen jämfört med vanliga resursdelningstekniker (konkurrent och FCFS). Dessa algoritmer bör köras i en cloudlet när en ny ansökan begäran anländer, besluta om var denna begäran ska köras: i cloudlet eller i molnet. Detta beslut kan baseras på både nuvarande cloudlet-belastning (t.ex. Processorn) och kraven på begäran (t.ex. fördröjning), som beskrivs nedan • Konkurrent strategi: ansökningar som anländer till en cloudlet helt enkelt tilldelas en sådan cloudlet, oavsett kapacitet eller nuvarande användning. • Första Come-First Serverad (FCFS) strategi: förfrågningar serveras i ordningen för deras ankomst, tills det inte finns några fler datorresurser tillgängliga. För enkelhetens skull, vi bara överväga CPU kapacitet, men flera kriterier beslutsfattande ofta beaktas i schemaläggning litteratur. När cloudlet blir full (dvs., återstående CPU-kapacitet är mindre än tillämpningskrav), program börjar schemaläggas för utförande vid molndatacentret. • Försening-prioritering: program som kräver lägre fördröjning är schemalagda först; nästa klass av ansökningar är planerad i molnet tills det inte finns någon CPU-kapacitet tillgänglig, och de återstående program är schemalagda i molnet. Strategierna implementerar en kombinationsmekanism för modulen som beskrivs i algoritmen Edge-ward, 11 där moduler i samma applikation grupperas för att placeras på samma enhet. I denna sammanfogningsmekanism flyttas även alla moduler av samma slag till samma enhet när en modul flyttas till en annan enhet.  För att utvärdera de olika strategierna i ett dimdatascenario utförde vi simuleringar med iFogSim. IFogSim valdes eftersom det körs på toppen av den väletablerade CloudSim simulator, som har använts och testats i stor utsträckning, och det är en simulator som tillåter hierarkisk sammansättning av kantenheter, moln och moln, också stödja mätning av programförseningar. Utvärderingen syftar till att analysera ansökningarnas prestanda i form av förseningar samt att bedöma hur fördelningspolicyn påverkar nätverkstrafiken. Vi har satt upp scenariot som beskrivs i figur 3 med fyra VSOT-tillämpningar som körs i Cloudlet 2 och tolv EEGTBG-programanvändare i cloudlets 1 och 3. Inledningsvis spelar sex EEGTBG-användare spelet på platser nära Cloudlet 1 och andra sex spelare är närmare Cloudlet 3. Vi flyttar EEGTBG spelare en efter en till Cloudlet 2, efterliknar en mobilitet beteende, för att bedöma eventuell kvalitet på servicedegradering till följd av dålig resursallokering. Eftersom EEGTBG har låga latenskrav anser vi att en spelare i en cloudlet endast spelar mot spelare i samma cloudlet. Resultat visade fokus på analysen av Cloudlet 2, som tar emot program från rörliga användare. Varje cloudlet hade en bearbetningskapacitet på 4000 MIPS (miljoner instruktioner per sekund) och var ansluten till porten genom en länk med 10.000 Kbps bandbredd och fyra millisekunder latens. Länken mellan porten och molnet hade 10.000 Kbps bandbredd och 100 millisekunder latens. Mobila enheter och kameraenheter kopplades till molnen genom en länk med 10.000 Kbps bandbredd och två millisekunders latens. Schemaläggning beslutsfattandet sker innan programmet körs, vilket innebär att den faktiska CPU-kapacitet som används av varje programmodul inte är exakt känd vid schemaläggningstidpunkten. Vid schemaläggningstid, strategier måste kontrollera om en cloudlet har tillräckligt med fri CPU-kapacitet för att hantera varje programmodul. I scenariot vi övervägde, varje modul behövde, under genomförandet, högst den CPU kapacitet som visas i tabell 1. Under utförandet använder varje program vid en given tidpunkt CPU-kapacitet som beror på interaktionen mellan dess moduler (dvs. hur mycket data det tar emot från/skickar till andra moduler, vilket utlöser CPU-intensiva åtgärder). Dessa uppskattningar kommer från ansökan beskrivning, som modellerar ansökan som en riktad graf, eller arbetsflöde, med dess attribut, som allmänt finns i schemaläggning litteratur. 11,12 Exakt uppskattning är dock en utmanande fråga och det är ett fokus för forskning i sig. För vissa tillämpningar är indataegenskaper (t.ex. video- eller bildkvalitet) och historiska data bra indikatorer för att uppskatta framtida prestanda, medan andra program uppvisar oförutsägbart beteende och uppskattar sin framtida prestanda inte ger mycket exakta resultat. Varje program har en processloop bland sina moduler som måste utföras för att visa resultaten. Fördröjningen i slingan är den tid det tar för en applikationsslinga att köra. I VSOT-applikationen börjar denna loop med kamerasensorerna som producerar videoströmmen, går igenom rörelsedetektorn, objektdetektorn, objektspårningen och slutligen PTZ-kontrollen, och mäter hur lång tid det tar för ett objekt att upptäckas, spåras och kameran justeras för att få bättre bilder av detta objekt. I EEGTBG-applikationen består slingan av EEG-sensoröverföringen till mobiltelefonen, kundval av konsekventa avläsningar, koncentrationsräknaren, klienten igen och displayen. Detta mäter den tid som tagits mellan den avkännda koncentrationsnivån och visningen av aktuell spelstatus för användaren. Figur 4 visar fördröjningen av programslingorna VSOT och EEG-BTG för de tre olika schemaläggningsstrategierna beroende på antalet användare som har flyttat från cloudlets 1 och 3 till Cloudlet 2. När bara en EEGBTG-spelare har flyttat till Cloudlet 2, har alla tre strategierna samma resultat för båda programmen. När den andra spelaren flyttade till Cloudlet 2, börjar olika schemaläggningsstrategier påverka programmen på olika sätt. VSOT-slingan fördröjs med konkurrent- och Delayprioritetsstrategierna, samtidigt som en låg fördröjning bibehålls med FCFS-strategin. Detta innebär att schemaläggning med hjälp av den Konkurrenta strategin medför resurs I E E C LO U D CO M P U T I N W W. CO M P U T E R. O R G /C LO U D CO M P U T I N G innehåll till Cloudlet 2, med VSOT-applikationen upplever en mycket hög fördröjning i sin kontroll slinga, vilket resulterar i kvalitet på tjänsten nedbrytning och därav följande program missuppfos, vilket undviks av FCFS genom att flytta EEGTBG moduler till molnet. Å andra sidan flyttar Delay-priority VSOT-moduler till molnet som ett resultat av den högre prioritet EEGTBG-applikationen ankomst, vilket ökar VSOT-slingan fördröjning till en acceptabel nivå på cirka 200 millisekunder samtidigt som EEGTBG förseningar så lägre som möjligt.
Dessutom undersöker Bittencourt REF schemaläggningsalgoritmer för dimdata med tanke på programmets prestanda som utförs av användarens rörlighet.
Mobility-Aware Application Scheduling in Fog Computing
{'venue': 'IEEE Cloud Computing', 'journal': 'IEEE Cloud Computing', 'mag_field_of_study': ['Computer Science']}