Hybrid Clouds for Flexible Batch Workload Processing
Promotoren: Prof. dr. Jan Broeckhove dr. Kurt Vanmechelen
Philippe Beckers Onderzoeksgroep Computationeel Modelleren en Programmeren
HOOFDSTUK
1
Probleemstelling
1.1 Scaling 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, modelleringen en allerlei andere computationeel intensieve applicaties. 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 ?? 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 vaak heel 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. Deze manier van schalen heeft geen last van de fysieke beperking die vertical scaling kent. Bovendien kan de oude hardware nog steeds gebruikt worden waardoor deze techniek een goedkopere oplossing biedt dan vertical scaling. Doordat deze manier van schalen meer voordelen kent dan vertical scaling beschikken vandaag de dag de meeste bedrijven en instellingen dan ook over een cluster voor het draaien 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 ’e´en enkel systeem waar ze hun applicaties op kunnen draaien.
1.2. CLOUD COMPUTING
2
1.2 Cloud Computing De verdere toepassing van deze technieken 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 providers 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 zeer 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.
1.3 Hybrid Clouds Door de bestaande infrastructuur met instances in de cloud uit te breiden wordt een hybrid cloud gevormd. De ontwikkeling van hybrid clouds staat echter nog in de kinderschoenen. Er zijn al enkele softwarepakketten ontwikkeld ?? 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. 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. Met de uitbreiding naar de hybride cloud komt ook het Wide Area Network (WAN, met het internet als belangrijkste voorbeeld) in beschouwing. Verbindingen over een WAN zijn enkele orders 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 (ook wel network topology genoemd) 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¨ele wereld. 1. Hitoriek schetsen 1.1. Beginnen met nood aan parallelisatie en horizontal scaling 1.2. Clusters (vermelden dat ze duur zijn. Iets in de zin van ¨enige limiet op rekenkracht is beschikbaar budget”, maar dan iets genuanceerder) 1.3. Cloud computing (commodity hardware ook even vermelden) 1.4. Hybrid clouds
1.3. HYBRID CLOUDS
3
2. Huidige staat van hybrid clouds schetsen 2.1. Amazon EC2 2.2. Interface van Amazon EC2 op Linux, code kan instances starten 2.3. Huidige testresultaten (climate change model paper vermelden) 2.4. Duidelijk maken dat Hybrid Clouds ”the way to go”zijn. 3. Probleem: Bijna geen research over data transfer in hybride cluster settings 3.1. Weinig distributed file systems compatibel met hybride setting 3.2. Moeilijke configuratie, want DFS zit diep in de configuratie van een cluster 3.3. Data optimalisatie is belangrijk want het beinvloed de totale kost en efficientie (efficiente vaag houden, meer uitdiepen in volgende sectie) 3.4. Moeilijk om verschillende DFSen te vergelijken (ie geen benchmarking voor hybride setting) 4. Huidige staat van HybridFS schetsen 4.1. Framework dat verschillende DFSen kan combineren. Vormt extra laag. 4.2. Notie van netwerktopologie zonder van DFS te veranderen op hoofdcluster. 4.3. Betere efficientie
HOOFDSTUK
2
Doelstelling
2.1 HybridFS In het kader van een thesis en stage werd reeds in het academiejaar 2012-2013 HybridFS ontwikkeld. HybridFS is een file system framework opgebouwd uit enkele modules dat specifiek is gericht op data verkeer in hybrid clouds. Door verschillende distributed file systems te combineren in ´e´en mountpoint kan er een onderscheid worden gemaakt tussen verkeer over een WAN en verkeer over een LAN zonder daarbij het distributed file system op de lokale infrastructuur aan te moeten passen. Bovendien zorgt de modulaire opbouw er voor dat er eenvoudig modules geschreven kunnen worden die dit data verkeer optimaliseren. Zo werden er in het onderzoek twee caching modules geschreven om het data verkeer over de WAN link te minimaliseren. Een eerste doelstelling voor dit onderzoek bestaat erin HybridFS uit te breiden met nieuwe modules om zo data verkeer in hybrid clouds verder te optimaliseren. Hierbij kunnen huidige technieken in distributed file systems zoals replication en locking aangepast worden aan hybrid clouds. Verder kan er ook nog onderzoek gedaan worden naar de ontwikkeling van technieken uit andere domeinen zoals distributed caching en scheduling en deze toepasbaar te maken binnen hybrid clouds.
2.2 Combinatie met bestaande software Na de voltooiing van HybridFS is het ook nuttig om een combinatie te vormen met bestaande software voor clusters. Hierbij kan worden gedacht aan de integratie met resource managers zoals Torque. Resource managers worden zeer vaak gebruikt
2.3. BENCHMARKING
5
om workloads te verdelen over een cluster. Een belangrijk deel van het onderzoek bestaat uit de presentatie van de hybride cloud aan de gebruiker. Door middel van de integratie met resource managers kan de gebruiker bijvoorbeeld de optie krijgen om zijn workload in de cloud te draaien als er niet genoeg capaciteit is op de lokale infrastructuur. Een andere doelstelling bestaat uit de integratie met een specifieke cloud provider. De Universiteit Antwerpen beschikt reeds over een testbudget bij Amazons’ Elastic Compute Cloud (Amazon EC2). Amazon stelt de software en een API ter beschikking om het huren van instances volledig te automatiseren. Daarbij komen ook aspecten zoals het gebruik van spot instances en reserved instances aan bod.
2.3 Benchmarking Als laatste doelstelling wordt de verkregen performantie van het ontwikkelde systeem onderzocht. Wegens het gebrek aan benchmarking software specifiek ontwikkeld voor distributed file systems zal er een benchmarking software ontwikkeld moeten worden. Naast de synthetische tests die reeds beschikbaar zijn in traditionele benchmarks kan er ook gekeken worden naar de hoeveelheid verkeer over het WAN. Het onderzoek naar deze benchmarking software zal dan ook leiden tot een betere beeldvorming van welk type applicaties geschikt zijn voor hybrid clouds. 5. HybridFS 5.1. Notie van netwerktopologie opent vele mogelijkheden 5.2. Modulaire approach van HybridFS maakt het mogelijk extensies te schrijven. 5.3. Uitwerken van HybridFS tot software die gebruikt kan worden in clusters 6. Uitbreiding van HybridFS naar een groter framework zoals Hadoop 6.1. Combinatie met batch queue software 6.2. Integratie met specifieke cloud providers zoals Amazon EC2 7. Benchmarking 7.1. Flat benchmarks zoals bonnie++ zeggen weinig 7.2. Benchmarking methode en applicatie ontwikkelen om performantie van een DFS in een hybride setting te testen
HOOFDSTUK
3
Projectbeschrijving
Zoals eerder aangegeven zal het onderzoek bestaan uit drie grote onderdelen.
3.1 HybridFS uitbreiden Het eerste deel van het onderzoek zal de uitbreiding van HybridFS onder de loep nemen. Het HybridFS framework is ontwikkeld met modulariteit als primair doel, waardoor het gemakkelijk is om de functionaliteit ervan uit te breiden. Hoewel er veel mogelijke modules zijn die geschreven kunnen worden zijn er enkele kandidaten die in een hybride setting zeer interessant zijn.
3.1.1 Distributed Caching De grootste winst in een hybrid cloud kan geboekt worden door middel van een slim en uitgebreid caching mechanisme. In de eerste versie van HybridFS zijn reeds modules aanwezig voor het lokaal cachen van data op de hardeschijf en in het RAM geheugen. De DiskCache heeft als hoofddoel de hoeveelheid data over het WAN drastisch te verminderen door externe bestanden bij te houden op de lokale hardeschijf. Hierdoor moet er bij het herhaaldelijk lezen van een file niet steeds data verstuurd worden over het WAN waardoor de data cost verminderd wordt. Bovendien is lokale opslag meestal sneller dan een WAN wat ook de performantie ten goede komt. Naast het cachen van reads zal de DiskCache nieuwe data schrijven op de lokale hardeschijf in plaats van het externe file system. Door deze writes enkel te synchroniseren met het externe file system wanneer dit nodig is wordt eveneens de hoeveelheid data die over het WAN beperkt. De RAMCache voorziet dezelfde functionaliteit maar heeft als primair doel het verbeteren van de snelheid. Belangrijke stukken data (pages) worden bijgehouden in het RAM waardoor deze snel toegankelijk zijn voor applicaties. Het systeem is analoog aan de file system cache gebruikt in
3.1. HYBRIDFS UITBREIDEN
7
Cache Example.png
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. Linux systemen, maar bevat optimalisaties voor hybrid clouds waardoor bestanden sneller synchroniseren. Deze caching algoritmes kunnen uitgebreid worden met distributed caching algoritmes zoals memcached [REFERENTIE NAAR MEMCACHED?]. Indien een page niet gevonden kan worden in de lokale cache kan er eerst gezocht worden naar een kopie bij een naburige node in plaats van de data van de externe site op te halen (Figure 3.1). Deze aanpak biedt naast een significante performantiewinst ook een vermindering van het verkeer over het WAN. Er is reeds onderzoek geweest naar het gebruik van distributed caching bij Hadoop/MapReduce door gebruik te maken van memcached [? ]. Daaruit werd geconcludeerd dat distributed caching een aanzienlijke snelheidswinst kan geven aan MapReduce. Door een gelijkaardige techniek toe te passen bij HybridFS kan naast de beoogde performantiewinst ook bespaard worden op het dataverkeer tussen de externe en de lokale infrastructuur.
Semantiek De implementatie van een distributed cache heeft tot gevolg dat er ook onderzoek gedaan moet worden naar de resulterende semantiek van het file system. De aanwezigheid van een cache zal immers voor een delay zorgen tussen bijvoorbeeld een schrijfactie en het daadwerkelijk wegschrijven van de data naar storage. Op clusterniveau is dit niet zo cruciaal daar het meestal de bedoeling zal zijn om een applicatie op ´e´en enkele cluster te draaien, niet op meerdere clusters tegelijk. Hierdoor is het minder belangrijk dat de externe cluster beschikt over een recente versie van de data en kunnen er dus wederom optimalisaties gemaakt worden voor de WAN link. Het is wel belangrijk een solide semantiek te voorzien tussen de nodes binnen ´e´enzelfde cluster. Een goede startplaats voor dit onderzoek zijn de algoritmes die gebruikt worden in GPFS van IBM [? ] in combinatie met een callback mechanisme zoals in AFS [? ? ]. GPFS gebruikt een algoritme waarbij een bepaalde node eigenaar kan zijn van een stuk bestand. Deze node kan dan zelf andere nodes aanduiden die eigenaar worden van een stukje van deze data wat resulteert in een hierarchische
3.1. HYBRIDFS UITBREIDEN
8
en gedecentraliseerde structuur. Vooral de gedecentraliseerde structuur is hier een voordeel omdat er dan geen master-slave architectuur moet voorzien worden in HybridFS. Bovendien kan dit gecombineerd worden met het callback mechanisme dat ge¨ıntroduceerd werd in AFS. Dit callback mechanisme kan andere nodes waarschuwen wanneer er een nieuwere versie beschikbaar is van de data of wanneer een node een stuk data uit de cache verwijderd.
Metadata Het gedistribueerd cachen van de metadata van bestanden is ook een belangrijk aspect in dit deel van het onderzoek. Het merendeel van de file system calls bestaat uit metadata operaties. Alhoewel deze operaties nooit even intensief zijn als leesen schrijfoperaties zorgen ze echter wel voor vertragingen daar ze afhankelijk zijn van de round trip time. Indien er veel metadata operaties gebeuren over een WAN zullen deze operaties tesamen een lange tijd in beslag nemen. Voorbeelden hiervan zijn het opvragen van de metadata (stat) en het aanpassen van de last modification timestamp. Het aanpassen van de timestamp heeft enkel nut wanneer de data ook effectief wordt weggeschreven uit de cache. Door het aantal timestamp updates te verminderen zullen de meeste stat operaties dan ook telkens dezelfde informatie bevatten waardoor ook deze informatie zeer geschikt is om te cachen.
3.1.2 Replication Ook de implementatie van replication algoritmes is een nuttige tak in dit onderzoek. Replication algoritmes voorzien een aantal kopi¨een van dezelfde data op verschillende nodes. Deze techniek zorgt er voor dat als een node wegvalt, de data nog steeds beschikbaar is op een andere node. Daarboven kan er gelezen worden van verschillende nodes tegelijk waardoor de troughput van de data wordt verhoogd. Deze techniek wordt al jaren als standaard gezien in een distributed file system en heeft ook zijn toepassing in een hybride cloud. De replication algoritmes die aanwezig zijn in de distributed file systems die reeds draaien op de clusters kunnen blijven gebruikt worden. Het doel is om replication te onderzoeken tussen verschillende clusters in plaats van tussen verschillende nodes. 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 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 interessante oplossing biedt voor kostenbesparingen. Deze dynamische prijs vertoont echter hoge pieken op willekeurige momenten waardoor instances op een onverwacht moment kunnen worden afgesloten (Figuur 3.2). 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 replication algoritmes in de huidige distributed file systems zullen niet helpen wanneer een hele cluster bestaat uit spot instances. Om dit probleem op te lossen is er replication nodig tussen de clusters onderling. Er zal dan een afweging gemaakt moeten worden
3.1. HYBRIDFS UITBREIDEN
9
Instances Pricing History.png
Figuur 3.2: Historiek van de huurprijs voor een m1.small instance op Amazon EC2. tussen de prijswinst bij het gebruik van spot instances en de kost om data te replicaten over de WAN link. Als extra toepassing kan gedacht worden aan het klaarzetten van data. Indien een queue manager op voorhand al weet welke applicatie er op de externe cluster gedraaid zal worden kan er ook al begonnen worden met het overzetten van de nodige data naar de externe cluster. Hierdoor kan de applicatie vrijwel meteen beginnen zonder eerst nog te moeten wachten op de nodige data. Hiervoor is echter wel integratie vereist met een queue manager, iets wat samenhangt met hoofdstuk 3.2.
3.1.3 Overige componenten Endpoints Buiten de bovengenoemde componenten zijn er ook nog secundaire componenten die onderzocht kunnen worden in dit onderdeel. Momenteel biedt HybridFS enkel een POSIX endpoint aan, dit zou eventueel uitgebreid kunnen worden met een HadoopFS endpoint of een eigen endpoint. Verschillende endpoints bieden verschillende optimalisaties voor applicaites. Zo is bijvoorbeeld het Google File System [? ] zeer geschikt voor het appenden aan files. De auteurs zijn tijdens hun onderzoek tot de conclusie gekomen dat de meeste mutaties van een bestand veroorzaakt worden door het toevoegen van data aan het einde van een file, niet het overschrijven van data op een willekeurige locatie in het bestand. Met dit in het achterhoofd hebben ze de interface van GoogleFS daar dan ook op afgestemd, iets wat aan de basis ligt van Hadoop. Het implementeren van interfaces maakt het ook gemakkelijker om bestaande applicaties te runnen op HybridFS zonder dat deze dan moeten worden aangepast aan een POSIX endpoint. Er kan ook onderzocht worden of er nood is aan een nieuwe interface gebaseerd op POSIX maar met specifieke optimalisaties voor distributed file systems in hybrid clouds. Het nut van het onderzoek naar een goede interface wordt bevestigd door de auteurs van Ceph. Ceph is een distributed file system dat metadata en data apart behandeld om zo de efficientie van hun file system te verhogen. Tijdens de ontwikkeling van Ceph werd duidelijk dat deze hogere efficientie ook een nieuwe interface nodig heeft [? ]. Daarop hebben de auteurs hun interface gebaseerd op aangepaste versie van POSIX die ontwikkeld werd door de HPC gemeenschap [? ].
3.2. FRAMEWORK
10
Scheduling De architectuur van HybridFS voorziet een lijst met file systems die in een bepaalde volgorde staan. Een intressante denkpiste is om deze volgorde dynamisch te maken zodat HybridFS zelf beslist welk file system de beste keuze is voor een bepaalde operatie. Zo zou er bijvoorbeeld door HybridFS bepaald kunnen worden welk file system lokaal is, en welke van de externe file systems het snelste is. Met deze informatie kan dan ook beslist worden welk file systems eventueel een cache nodig hebben en welk juist niet. Hierdoor kan de configuratie van HybridFS volledig geautomatiseerd worden waardoor de drempel om naar de hybride cloud over te stappen wordt verlaagd tot enkel de installatie van HybridFS.
3.2 Framework Het tweede deel van het onderzoek bestaat uit het bouwen van een framework rondom HybridFS. Bij de overstap naar een hybride cloud architectuur komt niet enkel data transfer kijken, waardoor HybridFS dus geen complete oplossing bied op dit vlak. Een gelijkaardig onderzoek werd ook gedaan bij de ontwikkeling van HadoopFS en MapReduce tot het Hadoop framework [? ]. Dit onderzoek is wat Hadoop zo succesvol heeft gemaakt, het bied een bijna compleet framework voor distributed computing op commodity hardware in clusters. Door een framework te bouwen rond HybridFS kan dit principe ook toegepast worden bij hybride clusters.
3.2.1 Batch Queues In eerste instantie zal een koppeling gemaakt moeten worden met een batch queue scheduler zoals Torque. Deze software staat in voor het verdelen van workloads over de beschikbare nodes. Als een gebruiker de cluster wilt gebruiken voor een applicatie zal deze scheduler bepalen wanneer en waar de applicatie zal runnen. Indien de cluster niet beschikbaar is zou de gebruiker moeten kunnen kiezen om de applicatie op de externe cluster uit te voeren, mits een kleine extra kostprijs. 8. HybridFS 8.1. Meerdere endpoints buiten enkel POSIX 8.2. Caching 8.2.1. Bestaande caching algoritmes verbeteren (limitaties opsommen) 8.2.2. Distributed caches (RAM en Disk) 8.3. Replication 8.3.1. Wanneer data terug schrijven van externe naar hoofdcluster? 8.3.2. Compatibiliteit met spot instances (volatiele nodes) die kunnen wegvallen 8.3.3. Op voorhand al data overzetten van lokale naar externe cluster 8.4. Distributed locking 8.5. Security 8.6. Scheduling 8.6.1. Momenteel hebben FS een vaste volgorde 8.6.2. Dynamische volgorde adhv latency of load of ... ?
3.2. FRAMEWORK
11
9. Framework 9.1. Batch queue frameworks 9.1.1. Studie naar beschikbare batch queues eventueel compatibel met hybride clouds 9.1.1.1. Dynamisch nodes toevoegen is vereiste 9.1.2. Onderscheid tussen workloads op lokale en externe infrastructuur 9.1.2.1. Extra betaling noodzakelijk voor externe infrastructuur 9.2. Integratie met Amazon EC2 9.2.1. Software voor het automatisch aanmaken en aflsuiten van nodes 9.2.2. Softwarematig managen van cost (spot instances ed?) 9.2.3. Voorgeconfigureerde images maken 10. Benchmarking 10.1. Concurrent access testen (zonder caches) 10.1.1. Tijd meten 10.1.2. Traffic over WAN meten 10.2. Caching performance 10.2.1. Reeds ingelezen data opnieuw inlezen 10.2.2. Proberen de gezamelijke cache-grootte van de cluster te bepalen (ie, geeft verschil weer tussen local en distributed caches) 10.3. Metadata performance 10.3.1. Proberen opsporen van eventuele bottleneck
HOOFDSTUK
4
Planning
TODO
HOOFDSTUK
5
Applications
11. Collaboratie tussen bedrijven 11.1. Clusters tijdelijk samenvoegen 12. UA-verhaal 12.1. Betere QoS op bestaande cluster voorzien, mits kleine extra kost voor de gebruiker 13. Hybride cloud voor kleine bedrijven 13.1. Websites en backups gemakkelijk uitbreiden naar de cloud 13.2. Minder IT personeel en infrastructuur nodig binnen bedrijf 14. Benchmark voor distributed file systems 14.1. synthetische benchmark waarden specifiek voor distributed file systems
Bibliografie
