Hybrid Clouds for Flexible Batch Workload Processing

Transcriptie

1 Hybrid Clouds for Flexible Batch Workload Processing IWT Proposition Promotoren: Prof. dr. Jan Broeckhove dr. Kurt Vanmechelen Philippe Beckers Onderzoeksgroep Computationeel Modelleren en Programmeren

2 HOOFDSTUK 1 Probleemstelling De digitalisering van de maatschappij heeft er de afgelopen decennia voor gezorgd dat steeds meer bedrijven en instellingen gebruik zijn gaan maken van complexe computersystemen. Deze computersystemen worden vaak gebruikt voor simulaties, modellering en allerlei andere computationeel intensieve applicaties.(hier was iets mis mee, maar ik weet niet meer wat, citaties nodig?) De toenemende complexiteit en populariteit van deze applicaties zorgt voor een constante nood aan capaciteitsuitbreidingen van de gebruikte infrastructuur. Het uitschalen van IT infrastructuur kan op twee manieren, door middel van vertical scaling en horizontal scaling. Bij vertical scaling wordt de hardware van een specifiek systeem vervangen door nieuwere en snellere hardware. Deze vorm van schalen kent echter fysieke beperkingen [1] waardoor deze techniek slechts beperkt toepasbaar is. Bovendien is dit een kostelijke manier van schalen omdat de oude hardware uit gebruik wordt genomen en de nieuwe hardware relatief duur is bij aanschaf en snel zijn waarde verliest. Horizontal scaling is een meer toepasbare manier van schalen waarbij de bestaande infrastructuur uitgebreid wordt door het toevoegen van nieuwe systemen. De fysieke beperking op vertical scaling is niet van toepassing bij horizontal scaling. Bovendien kan de oude hardware nog steeds gebruikt worden waardoor deze techniek een goedkopere oplossing biedt dan vertical scaling. Doordat horizontal scaling meer voordelen kent dan vertical scaling beschikken vandaag de dag de meeste bedrijven en instellingen dan ook over een cluster voor het uitvoeren van computationeel intensieve applicaties. Bij een cluster worden individuele computers met elkaar verbonden via een Local Area Network waardoor ze samen kunnen werken aan hetzelfde probleem. Gebruikers zien deze verzameling computers dan als één enkel systeem waar ze hun applicaties op kunnen uitvoeren. De verdere toepassing van horizontal scaling heeft gedurende de laatste aantal jaren geleid tot de introductie van cloud computing. Cloud computing kent verschillende vormen, waaronder Infrastructure as a Service (IaaS). Hierbij bieden cloud provi-

3 2 Figuur 1.1: Hybrid Clouds kennen een sterke groei. Resultaten van het Private Cloud onderzoek van InformationWeek uit april ders systemen aan die men tijdelijk voor een bepaalde vergoeding kan huren. Deze systemen worden instances genoemd en worden verhuurd op uurbasis door middel van een toegankelijke interface. Door IaaS te combineren met horizontal scaling kan men zeer flexibel en goedkoop extra capaciteit toevoegen aan een cluster. Monitoring software op de bestaande infrastructuur kan de beslissing maken om de rekencapaciteit uit te breiden door tijdelijk externe instances te huren van een cloud provider waardoor het proces van horizontal scaling volledig geautomatiseerd wordt. Bovendien beschikken cloud providers vaak over geavanceerde hardware waardoor ze high-performance instances kunnen aanbieden. Doordat deze high-performance instances enkel op uurbasis betaald moeten worden, wordt de huurder bespaard van de hoge initiële kost bij de aanschaf van de gebruikte hardware. Hierdoor kan de huurder naast horizontal scaling ook op een kostenefficiënte manier gebruik maken van vertical scaling. De combinatie van bestaande infrastructuur en instances in de cloud heeft recent geleid tot het ontstaan van hybrid clouds. Doordat de voordelen van een lokale en externe infrastructuur gecombineerd worden kent dit paradigma een sterke groei [2] (Figuur 1.1). Er zijn al enkele softwarepakketten ontwikkeld [3] die de integratie van een hybrid cloud faciliteren, maar er is nog veel ruimte voor optimalisatie. Bovendien komen bij de configuratie van deze software problemen naar boven die soms zeer moeilijk zijn op te lossen zodat niet elke infrastructuur uitgebreid kan worden met instances in de cloud. Een voorbeeld hiervan is de data stroom tussen de lokale infrastructuur en de externe cloud instances. Traditionele cluster systemen maken gebruik van een Distributed File System om data door te geven over het LAN. De uitbreiding naar de 1

4 3 hybride cloud impliceert echter ook het gebruik van een Wide Area Network (WAN, met het internet als belangrijkste voorbeeld). Verbindingen over een WAN zijn meestal vele malen trager dan die over een LAN. Bovendien zijn er kosten verbonden aan data verkeer over het WAN terwijl dit niet het geval is bij het LAN. De meest gebruikte distributed file systems maken geen onderscheid tussen verkeer over een WAN en verkeer over een LAN, waardoor data verkeer tussen beide infrastructuren vaak traag en kostelijk is. Bovendien is het veranderen van distributed file system een zeer ingewikkeld en risicovol proces waardoor de configuratie van een hybrid cloud sterk wordt bemoeilijkt. Deze problemen zorgen voor een gebrek aan toepasbaarheid van hybrid clouds in de commerciële wereld. Notie computing as commodity naar voor brengen?

5 HOOFDSTUK 2 Doelstelling Het doel van dit onderzoek bestaat uit het opbouwen van een softwarepakket voor de seamless integratie van bestaande infrastructuur met cloud instances. De overstap naar de hybrid cloud introduceert veel nieuwe aspecten en uitdagingen die in dit onderzoek aangepakt worden. Om dit doel te bereiken kan het onderzoek opgedeeld worden in de volgende doelstellingen: 2.1 Data Management Zoals werd aangehaald in de vorige sectie is het aanpakken van data verkeer tussen de lokale en externe infrastructuur een belangrijke uitdaging bij de overstap naar de hybrid cloud. Doordat naast het LAN nu ook rekening gehouden moet worden met verkeer over het WAN wordt network topology een belangrijk aspect bij data management. Concreet wil dit zeggen dat er een onderscheid gemaakt moet worden tussen data verkeer over het LAN en data verkeer over het WAN. Aan de hand van dit onderscheid is het de bedoeling om software te ontwikkelen die op een intelligente manier het dataverkeer kan beheren binnen een hybrid cloud. Hierbij zal er onderzocht worden hoe bestaande data management technieken toepasbaar gemaakt kunnen worden binnen hybrid cloud omgevingen. 2.2 Resource Management Bestaande compute clusters maken gebruik van resource managers zoals Torque voor het beheer van nodes in een cluster. Het managen van dynamische resources in de public cloud introduceert echter veel nieuwe opties voor resource management

6 2.3. SCHEDULING 5 software. Indien de lokale infrastructuur overbelast dreigt te worden kan deze worden uitgebreid met extra instances uit de cloud. Er zal onderzocht worden hoe bestaande resource management software verder uitgebreid kan worden om deze compatibel te maken met public cloud infrastructuur. 2.3 Scheduling Resource management software bevat vaak een scheduling component voor het plaatsen van jobs op nodes in de cluster. Met de uitbreiding naar de hybrid cloud is het van belang ook hier onderzoek te doen naar de nodige aanpassingen. Het gebruik van de public cloud introduceert een nieuw kostenaspect waardoor het belangrijk is om ook dit nieuwe aspect te integreren binnen de schedulers. Het schedulen van jobs in hybrid clouds werd reeds onderzocht binnen de CoMP onderzoeksgroep [4] nog meer referenties?. De toevoeging van parameters zoals data locality en transmission speeds werden echter beschouwd als future work waardoor ze binnen dit onderzoek verder aan bod zullen komen. Door de toevoeging van deze parameters is het mogelijk om de runtime en kost van jobs op public cloud infrastructuur nauwkeuriger in te schatten. Bijgevolg kunnen er accuratere beslissingen gemaakt worden omtrent het plaatsen van workloads op cloud providers. 2.4 Benchmarking Om het resulterende softwarepakket te evalueren zal onderzoek gevoerd worden naar het benchmarken van de software. De noodzaak voor dit onderzoek komt enerzijds door het gebrek aan benchmarking software specifiek gericht op distributed file systems en anderzijds door de nood aan job parameters gebruikt bij scheduling en resource management. Door de implementatie van een goede benchmark kan in de conclusie van het onderzoek op een overzichtelijke en eenvoudige manier een vergelijking gemaakt worden tussen het bekomen softwarepakket en bestaande systemen. Daarenboven zijn de parameters nodig bij scheduling en resource management vaak moeilijk theoretisch te bepalen waardoor een banchmark noodzakelijk is om een accuraat idee te vormen.

7 HOOFDSTUK 3 Projectbeschrijving Het onderzoek bestaat voornamelijk uit de uitbreiding van bestaande technologiëen in traditionele clusters naar de hybrid cloud. Hierbij worden vier belangrijke aspecten bekeken die uiteindelijk basis vormen voor een softwarepakket specifiek ontworpen voor hybrid clouds. 3.1 Data Management Traditioneel wordt er binnen een cluster gebruikt gemaakt van een distributed file system (DFS) voor het managen van data.(ik gebruik distributed file system al in de vorige secties, is dat een probleem?). Door het gebruik van een DFS is het mogelijk om een abstractielaag te vormen boven het gebruikte netwerk. Applicaties op de cluster kunnen dan via een POSIX-interface (of een variant hierop) gebruik maken van het netwerk zonder dat hiervoor extra complexiteit voorzien moet worden binnen de applicatie. Het overgrote deel van de traditionele clusters maakt enkel gebruik van een LAN voor het verbinden van nodes waardoor bestaande DFS software bijgevolg ontwikkeld is rond het efficiënt gebruik van een LAN. Met de uitbreiding naar een hybrid cloud wordt er echter ook gebruik gemaakt van een WAN verbinding. Omdat er voor het gebruik van een WAN verbinding een prijs wordt aangerekend en deze verbinding meestal enkele malen trager is dan een LAN verbinding is het noodzakelijk om bij de ontwikkeling van een DFS rekening te houden met het verschil tussen beide netwerken. Het aanpassen van de bestaande data management technieken omvat derhalve vooral het geschikt maken van deze technieken voor een WAN. In het kader van een thesis en stage werd reeds in het academiejaar HybridFS ontwikkeld; een file system framework opgebouwd uit modules. Door

8 3.1. DATA MANAGEMENT 7 verschillende DFSs te combineren in één mountpoint kan er binnen HybridFS een onderscheid worden gemaakt tussen verkeer over een WAN en verkeer over een LAN. Deze architectuur zorgt voor een abstractielaag boven de indivuele DFSs zonder dat daarbij de lokale infrastructuur aangepast moet worden. Binnen dit framework werden ook twee modules ontwikkeld die enkele caching algoritmes implementeren. Als eerste module werd een DiskCache ontwikkeld die voor caching op de lokale hard drive zorgt. Door het cachen van veelgebruikte data op de lokale hard drive van nodes wordt de hoeveelheid data die tussen twee clusters passeert verminderd. Aangezien de toegang tot data op de lokale harde schijf meestal vele malen sneller is dan het versturen van dezelfde data over het WAN wordt enerzijds een prestatiewinst geboekt. Anderzijds zorgt de vermindering van het dataverkeer ook voor een vermindering van de data kost op het WAN. De tweede module die werd ontwikkeld implementeert een RAMCache. Bestaande operating systems maken reeds decennia lang gebruik van een gelijkaardige cache voor een snellere toegang tot veelgebruikte data waardoor deze functionaliteit van primordiaal belang is voor een DFS. Doordat HybridFS de basis vormt voor een DFS in de hybrid cloud worden tijdens het onderzoek verder modules ontwikkeld voor de implementatie van de aangepaste technieken. Deze modules kunnen in willekeurige volgorde tussen het mountpoint en elk input DFS naar keuze geplaatst worden door de gebruiker. Tijdens het onderzoek worden de volgende technieken uitgebreid: Distributed Caching De bestaande RAMCache en DiskCache modules binnen HybridFS werden ontwikkeld met als primair doel het leggen van een basis voor een distributed cache. Distributed caching is een uitbreiding van de traditionele cache waarbij data verdeeld wordt over bijvoorbeeld het RAM van verschillende nodes in een netwerk in plaats van over het RAM van enkel de lokale node. Deze doorontwikkeling is een gevolg van de toenemende snelheid van LAN hardware en het goedkoper worden van RAM geheugen. In traditionele clusters wordt een distributed cache vaak gebruikt in combinatie met commodity hardware 1. In dit geval wordt het RAM van de verschillende nodes gecombineerd tot één enkel groot virtueel RAM geheugen waardoor er meer data in de cache geplaatst kan worden. Het opvragen van data via een LAN uit het RAM geheugen van een naburige node is bovendien meestal sneller dan het lezen van de lokale harde schijf waardoor applicaties sneller toegang hebben tot de nodige data [5]. Door een gelijkaardige techniek toe te passen bij hybrid clouds kan naast de beoogde prestatiewinst ook bespaard worden op het dataverkeer tussen de externe en de lokale infrastructuur. Nodes in een cluster kunnen immers de nodige data ophalen uit de cache van een naburige node in plaats van deze data op te moeten halen 1 Hardware die algemeen verkrijgbaar en relatief goedkoop is.

9 3.1. DATA MANAGEMENT 8 Figuur 3.1: Machine Q in Cluster 2 heeft data uit Page X nodig. Het voorbeeld aan de rechterkant maakt gebruik van de distributed cache, het voorbeeld aan de linkerkant moet de data ophalen over het WAN. van een externe cluster (Figuur 3.1). Een eerste fase in dit onderzoek zal bestaan uit de implementatie van twee distributed caching modules voor HybridFS: 1. Een distributed RAM cache. 2. Een distributed Disk cache. Voor de implementatie van een distributed RAM cache module kan gebruik gemaakt worden van memcached 2. Deze caching software implementeert een distributed object cache in het RAM geheugen. Objecten worden opgeslagen aan de hand van een key in het virtuele RAM waardoor de complexiteit van dit implementatieproces grotendeels wordt gereduceerd tot het bepalen van een goede key. De implementatie van een distributed Disk cache kan gebaseerd worden op een onderliggend DFS. Door de cache op te slagen op een DFS dat gedeeld wordt door verschillende nodes is de data ook meteen beschikbaar voor de andere nodes binnen hetzelfde netwerk. Metadata caching Naast het cachen van data wordt ook gekeken naar het cachen van metadata. De metadata van een bestand bevat informatie over het bestand zoals o.a. de last modification time, file size, ownership en access rights. Hoewel de grootte van deze data slechts een fractie is van de grootte van het bestand worden er doorgaans veel operaties op uitgevoerd. Voornamelijk het opvragen van deze metadata (statoperatie) en het aanpassen van de last modification time nemen een groot deel van het aantal operaties in beslag (citaat nodig?). Het veelvuldig gebruik van metadata operaties in combinatie met de relatief hoge round-trip time (RTT) in een WAN zorgt ook hier voor een nood aan caching. 2

10 3.1. DATA MANAGEMENT 9 Figuur 3.2: Historiek van de huurprijs voor een m1.small instance op Amazon EC Replication Een DFS bevat doorgaans ook een replication algoritme. Dit algoritme voorziet een aantal kopiëen van dezelfde data op verschillende nodes. Deze techniek zorgt ervoor dat als een node wegvalt, de data nog steeds beschikbaar is op een andere node. Aangezien de data bovendien beschikbaar is op verschillende nodes kan er ook in parallel gelezen worden, wat de doorvoersnelheid ten goede komt. Deze techniek wordt reeds decennia lang toegepast binnen DFSs waardoor er in dit onderzoek enkel gekeken hoeft te worden naar de toepassing van de techniek in een hybrid cloud. In een hybrid cloud heeft replication enkele nieuwe voordelen. Het dynamische karakter van een public cloud heeft tot gevolg dat instances regelmatig worden toegevoegd en verwijderd uit het systeem. Hierdoor is het cruciaal dat er tijdens deze wijzigingen geen data verloren gaat. Als voorbeeld kan gekeken worden naar het gebruik van spot instances op Amazons Elastic Compute Cloud (Amazon EC2). Bij deze instances kan een gebruiker zelf de maximum huurprijs bepalen voor een bepaalde instance type. De aangerekende prijs is afhankelijk van de globale vraag naar dit instance type en indien de maximum prijs wordt overschreden worden de instances van de gebruiker meteen uitgeschakeld. De gemiddelde prijs voor een spot instance ligt over het algemeen veel lager dan bij de equivalente reserved instances waardoor de spot market een populaire oplossing biedt voor kostenbesparingen [6]. Deze dynamische prijs vertoont echter hoge pieken op bepaalde momenten (Figuur 3.2) waardoor instances op een onverwacht moment kunnen worden afgesloten door de cloud provider. Om efficient en betrouwbaar gebruik te kunnen maken van spot instances is het dus noodzakelijk om een vorm van redundantie te voorzien bij het opslaan van data. De huidige replication algoritmes zijn niet voorzien op het plotseling afsluiten van een groot deel van de cluster. Om dit probleem op te lossen is er replication nodig tussen de clusters onderling. Als tweede extra voordeel kan gedacht worden aan het klaarzetten van data. Resource management software bepaalt op welke cluster een workload geplaatst wordt. Indien deze software op voorhand weet welke data deze workload nodig heeft kan er ook al begonnen worden met het overzetten van de nodige data naar de target

11 3.1. DATA MANAGEMENT 10 Figuur 3.3: Voorbeeld van een race condition waarbij twee processen op hetzelfde moment dezelfde data proberen aan te passen. cluster. Hierdoor staat de nodige data reeds klaar bij de aanvang van de applicatie waardoor deze sneller kan beginnen Distributed Locking Een derde belangrijk onderdeel binnen data management is het managen van locks. Bij het gedistribueerd uitvoeren van een applicatie bestaat de mogelijkheid dat verschillende processen op hetzelfde moment dezelfde data aanpassen. Om het ontstaan van race conditions (Figuur 3.3) tegen te gaan wordt er doorgaans gebruik gemaakt van file locking. In moderne DFSs zoals GPFS van IBM [7] wordt gebruik gemaakt van een hiërarchisch locking mechanisme. Deze manier van locking voorkomt dat een proces een groot bestand volledig locked hoewel er slechts een klein deel van het bestand wordt aangepast. In eerste instantie wordt er een lock verkregen op het gehele bestand. Indien een tweede proces een lock wil verkrijgen op andere data binnen hetzelfde bestand wordt de lock opgesplitst in twee delen: een lock voor het eerste deel van het bestand en een lock voor het tweede deel van het bestand. Deze locks kunnen dan wederom op dezelfde manier gesplitst worden waardoor het mogelijk is om race conditions te vermijden zonder dat er prestatieverlies is bij het locken van grote bestanden. Daarenboven is dit een gedecentraliseerde manier van lock management waardoor er geen nood is aan een master-slave configuratie wat eventueel een bottleneck kan vormen. In een hybrid cloud moeten er locks uitgedeeld worden tussen de verschillende clusters in plaats van tussen de verschillende nodes binnen een cluster. Indien een applicatie gebruik maakt van data op een andere cluster moet deze data gelocked worden om te voorkomen dat twee clusters dezelfde data aanpassen. Om dit te bekomen kan best een algoritme analoog aan de bestaande locking algoritmes onderzocht worden zodat er wederom geen prestatieverlies optreed bij het locken van grote bestanden. Lock management hangt ook deels samen met het cachen van data. Indien een proces of cluster een lock bezit op een bepaald stuk data kan deze data gecached

12 3.2. RESOURCE MANAGEMENT 11 worden zolang het proces of de cluster de lock bezit. Pas bij het unlocken van data hoeft de cache gesynchroniseerd te worden. Dit maakt het mogelijk om met het behulp van een callback mechanisme de het cachen van data verder te optimaliseren door enkel data weg te schrijven bij het unlocken van de data. Een gelijkaardig algoritme werd reeds bedacht bij de ontwikkeling van AFS [8, 9]. 3.2 Resource Management Het dynamische karakter van public clouds staat toe om on-the-fly instances toe te voegen aan of te verwijderen uit de externe infrastructuur. Het tweede aspect dat onderzocht wordt betreft het managen van deze dynamische resources binnen de public cloud. Het gebruik van public cloud infrastructuur introduceert hoofdzakelijk de volgende nieuwe opties: Het opstarten van nieuwe instances. De beschikking over verschillende instance types. Het afsluiten van ongebruikte (of idle) instances. Indien er extra capaciteit nodig is voor het uitvoeren van een applicatie kan de resource manager extra capaciteit voorzien door nieuwe instances op te starten. Deze instances moeten nadien ook beheerd worden door de resource manager, er moet een afweging gemaakt worden tussen het draaiende houden van deze instances en het terug afsluiten van idle instances. Het afsluiten en terug opstarten van instances vergt enige tijd waardoor het interessant kan zijn deze instances draaiende te houden voor een toekomstige applicatie. Deze afweging wordt gemaakt op basis van de resterende workload in de queue en de kost om deze instances draaiende te houden. In samenspraak met de scheduler (Sectie 3.3) wordt er ook een beslissing gemaakt over het aantal nieuwe instances dat opgestart moet worden. Door de heterogeniteit van de aangeboden instances bestaat eveneens de keuze tussen het opstarten van verschillende instance types. Vermits de kost stijgt met het aantal gereserveerde instances en afhankelijk is van het instance type wordt er eveneens een maximumbudget voorzien binnen de resource manager. 3.3 Scheduling Indien een bepaalde applicatie wordt uitgeschaald naar de public cloud moet de scheduler bepalen hoeveel instances er nodig zijn om de applicatie efficiënt uit te voeren. Deze efficiëntie belichaamt twee waarden:

13 3.3. SCHEDULING 12 Kost Elke instance die opgestart wordt heeft een bepaalde huurprijs. Hoe meer instances er gebruikt worden, hoe hoger de prijs die betaald wordt. Het gebruiken van extra instances zorgt er echter ook voor dat de applicatie sneller loopt waardoor de totale tijd dat instances in gebruik zijn daalt. Sommige applicaties hebben minder baat bij parallellisatie waardoor het bepalen van het aantal instances nauw verband houdt met de parallelliseerbaarheid (bestaand woord?) van de applicatie. Performantie Applicaties kunnen gebonden zijn aan een deadline. In dit geval heeft de resource manager een minimum aantal instances dat opgestart moet worden om de deadline te halen. Naast het aantal resources bepaalt de scheduler ook welk type instance gebruikt zal worden voor de applicatie. Hierbij wordt gebruik gemaakt van het profiel van de applicatie. Workloads met een hoog geheugengebruik kunnen bijvoorbeeld best geplaatst worden op instances met een groot RAM geheugen en een minder krachtige CPU. Omgekeerd kunnen rekenintensieve applicaties best geplaatst worden op instances met een krachtige CPU. Een onderzoek omtrent het kostenefficiënt schedulen van jobs in hybrid clouds werd zoals eerder vermeld reeds onderzocht binnen de CoMP onderzoeksgroep. Door de toevoeging van extra parameters zoals data locality, transmission speeds, cache state enz. kan de onderzochte scheduler verder uitgebreid worden. De toevoeging van data locality stelt de scheduler beter in staat een beslissing te maken over op welke cluster een bepaalde workload geplaatst wordt. In combinatie met de hoeveelheid benodigde data en de transmission speed kan de scheduler beter inschatten of het nuttig is om de applicatie op een externe cluster te plaatsen. Indien de kost en delay van het verplaatsen van de data naar de externe cluster te hoog is kan beslist worden om de applicatie op de cluster te plaatsen waar de data zich bevindt en in de plaats daarvan een andere applicatie op de externe infrastructuur te plaatsen. Ook het kennen van de cache state van een bepaalde cluster helpt met het maken van een accurate scheduling beslissing. Afhankelijk van waar de applicatie wordt geplaatst is er echter ook een kost verbonden aan het uitvoeren van de applicatie. Om gebruikers niet ongewild te laten betalen moet de gebruiker de optie krijgen om te aan te geven of de applicatie in de externe cluster mag geplaatst worden. Naast deze optie is het ook nuttig om een schatting te maken van de kosten die gepaard gaan met het uitvoeren van de applicatie in de cloud. Deze informatie wordt eveneens bepaald door de scheduler aan de hand van de eerder vermelde parameters.

14 3.4. BENCHMARKING Benchmarking Het onderzoek naar een geschikte benchmark heeft zoals eerder vermeld in sectie 2.4 twee voordelen. Het evalueren van het bekomen softwarepakket enerzijds en het bepalen van job parameters anderzijds. Bestaande flat benchmarks zoals bonnie++ 3 zijn niet geschikt voor de evaluatie van het bekomen softwarepakket en de vergelijking met vorige oplossingen. De hoofdreden hiervoor is dat er in deze benchmarks geen tests voorzien zijn specifiek voor DFSs. Factoren die belangrijk zijn bij het evalueren van een DFS zoals netwerkverkeer, distributed access, caching enz. worden doorgaans niet getest. Het meten van het netwerkverkeer is noodzakelijk voor het bepalen van de data cost in een hybrid cloud. Het testen van distributed access is eveneens een sleutelaspect om bijvoorbeeld het locking mechanisme te kunnen evalueren. Caching tests zijn van primordiaal belang wanneer een DFS beschikt over een vorm van distributed caching. Ondanks deze gebreken worden deze flat benchmarks nog steeds vaak gebruikt bij de evaluatie van DFSs omdat ze een soort standaard zijn geworden. Door de ontwikkeling van een synthetische benchmark kan hierdoor op dezelfde manier een betere vergelijking gemaakt worden met andere systemen. Deze benchmark bevat enkele parameters om specifieke workloads na te bootsen: Input data Een set bestanden die reeds aanwezig zijn. Deze bestanden worden gebruikt als input data voor een applicatie. De toevoeging van deze parameter stelt de gebruiker in staat een onderscheid te maken tussen applicaties met input data reeds aanwezig op de cluster en applicaties met input data op een externe locatie. Output data De grootte en locatie van de output geschreven door de nagebootste applicatie. Dit is de data die achterblijft na het uitvoeren van de applicatie. Temporary data Grootte en locatie van eventuele tijdelijke data die gebruikt wordt tijdens het uitvoeren van de applicatie. Deze data wordt verwijderd na het uitvoeren van de applicatie. Read size Twee gemiddelde groottes voor leesoperaties. Eén waarde voor leesoperaties op de input data en de andere voor leesoperaties op de temporary data. Write size Twee gemiddelde groottes voor schrijfoperaties. Eén waarde voor schrijfoperaties op de input data en de andere voor schrijfoperaties op de temporary data. Read frequency Bepaalt wat de verhouding is tussen het aantal rekentaken en leesoperaties. Ook hier worden twee waarden gebruikt voor respectievelijk de input data en temporary data. 3

15 3.4. BENCHMARKING 14 Write frequency De verhouding tussen rekentaken en schrijfoperaties. Ook hier worden twee waarden gebruikt voor respectievelijk de input data en temporary data. Deze parameters stellen de benchmark in staat een accurate en afstelbare simulatie te vormen voor applicaties. Een hoge read en/of frequency is typisch voor een dataintensieve applicatie. Rekenintensieve applicaties worden gesimuleerd door een lage read frequency. Grote read en/of write sizes simuleren sequentiële leesoperaties, kleine read size simuleren random access. Het gebruik van temporary data zorgt voor tests die analoog zijn aan de bestaande benchmarks. Om metingen uit te voeren is eveneens een monitoring component nodig in de benchmark. Deze component zorgt voor het meten van het o.a. het netwerkverkeer, het aantal gebruikte instances, belasting per node, etc. nodig voor het rapporteren van de resultaten. Deze component is eveneens bruikbaar voor het meten van applicaties opgegeven door de gebruiker in plaats de simulatie van de benchmark. Deze monitoring component stelt de gebruiker in staat accuraat en eenvoudig de parameters te bepalen die nodig zijn voor de scheduler en resource manager.

16 HOOFDSTUK 4 Planning TODO

17 HOOFDSTUK 5 Toepassingsmogelijkheden 5.1 Algemene economische toepasbaarheid De toenemende adoptie van cloud computing is aanwezig in een zeer groot deel van het bedrijfsleven. De complexiteit van de integratie met public cloud infrastructuur is echter vrij hoog. Deze complexiteit vormt in vele gevallen het doorslaggevende argument [10] om de overstap naar de cloud uit te stellen of af te lasten. Dit onderzoek verlaagt deze complexiteit waardoor meer bedrijven de overstap kunnen maken naar een hybrid cloud. Dit aspect vormt in grote mate een voordeel voor kleinere bedrijven. Het onderhouden van een IT-afdeling binnen een klein bedrijf kan grote kosten met zich meebrengen. Door het outsourcen naar de cloud vallen belangrijke taken zoals het onderhouden van hardware, updaten van software, verkrijgen van licenties, enz. in de handen van de cloud provider. Hierdoor is het mogelijk een IT infrastructuur uit te bouwen met minder personeel, waardoor kleinere bedrijven zich meer kunnen focussen op hun core-business. 5.2 Collaboratie tussen bedrijven In de onderzoekswereld wordt er vaak door verschillende instanties of bedrijven tijdelijk samengewerkt aan een gemeenschappelijk computationeel project. Dit onderzoek stelt deze bedrijven in staat tijdelijk op een eenvoudige manier hun infrastructuur te delen voor het project. Het opzetten van een tijdelijke hybrid cloud zou zonder een geschikt softwarepakket meestal als te complex worden geacht. Bovendien

18 hoeven er weinig of geen veranderingen te gebeuren aan de bestaande infrastructuren waardoor na de voltooiing van het project de software simpelweg terug verwijderd kan worden. 5.3 Uitbreiding van de CalcUA De CalcUA is de rekencluster die gebruikt wordt binnen de Universiteit Antwerpen voor het uitvoeren van computationeel intensieve applicaties. Het uitbreiden van deze cluster met nieuwe hardware is een dure onderneming. Bovendien kent de CalcUA veel drukke en rustige periodes in respectievelijk de examenperiodes en vakanties. Door deze cluster uit te breiden naar de cloud kunnen kleinere rekentaken op drukke periodes eenvoudig op externe infrastructuur geplaatst worden zonder dat daarbij de lang-lopende applicaties op de lokale infrastructuur onderbroken moeten worden. 5.4 Benchmarking van DFSs Het onderzoek naar de ontwikkeling vaan benchmark specifiek ontworpen voor DFSs stelt toekomstige onderzoekers in staat hun methodes te testen zonder daarbij zelf testapplicaties te moeten improviseren of zoeken. Indien deze benchmark wordt gebruikt in meerdere onderzoeken is het bovendien gemakkelijker om de resultaten van verschillende onderzoeken met elkaar te vergelijken.

19 Bibliografie [1] Adve et al., Parallel computing research at illinois, tech. rep., University of Illinois at Urbana-Champaign, November [2] D. Hilley, Cloud computing: A taxonomy of platform and infrastructure-level offerings, tech. rep., Georgia Institute of Technology, [3] B. Sotomayor, R. Montero, I. Llorente, I. Foster, and F. de Informatica, Capacity leasing in cloud systems using the opennebula engine, Cloud Computing and Applications, vol. 2008, [4] R. Van den Bossche, K. Vanmechelen, and J. Broeckhove, Cost-optimal scheduling in hybrid iaas clouds for deadline constrained workloads, in 2010 IEEE 3rd International Conference on Cloud Computing (CLOUD), pp , IEEE, [5] S. Zhang, J. Han, Z. Liu, K. Wang, and S. Feng, Accelerating MapReduce with Distributed Memory Cache. Parallel and Distributed Systems (ICPADS), [6] M. Mattess, C. Vecchiola, and R. Buyya, Managing peak loads by leasing cloud infrastructure services from a spot market, in th IEEE International Conference on High Performance Computing and Communications (HPCC), pp , [7] F. R. H. Schmuck, Gpfs: A shared-disk file system for large computing clusters, in Proceedings of the FAST 02 Conference on File and Storage Technologies., (Monterey, California, USA), pp , USENIX, January [8] J. H. Howard et al., An overview of the andrew file system. Carnegie Mellon University, Information Technology Center, [9] M. L. Kazar et al., Synchronization and caching issues in the Andrew file system. Carnegie Mellon University, Information Technology Center, 1988.

20 [10] C. Babcock, Cloud implementation costs, complexity surprise companies, tech. rep., InformationWeek, February 2013.