Prestatie-analyse in een cloud-omgeving

Transcriptie

1 Prestatie-analyse in een cloud-omgeving Glenn Decock Promotor: prof. dr. ir. Lieven Eeckhout Begeleiders: Stijn Polfliet, Frederick Ryckbosch Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen en Architectuur Academiejaar

2 VOORWOORD ii Voorwoord Nu mijn thesis geschreven is, zo komt er ook een einde aan mijn studies. Na zes jaar ingenieursstudies, verdeeld over een vierjarige opleiding tot industrieel ingenieur en een twee jarige masteropleiding tot burgerlijk ingenieur, is het goed geweest. Het is een periode waar ik enorm veel heb geleerd en dit met vallen en opstaan. Het was niet altijd makkelijk maar moeilijk gaat ook. Vele nachtjes doorwerken, afgewisseld met nachten waarin er werd gefeest. Het was het allemaal waard. Deze thesis is dan ook niet zo maar tot stand gekomen. Graag had ik dan ook nog een aantal mensen bedankt: ˆ In de eerste plaats mijn ouders. Zonder hun jarenlange steun zowel op mentaal vlak, toen het iets moeilijker ging, als ook op financieel vlak was dit allemaal niet mogelijk geweest. Ik liet dit misschien niet altijd even hard blijken en daarom via deze weg, bedankt! ˆ Graag had ik ook mijn promotor prof. dr. ir. Lieven Eeckhout en mijn dagelijkse begeleiders dr. ir. Stijn Polfliet en dr. ir. Frederick Ryckbosch bedankt voor de schat aan informatie die ze me bijgebracht hebben. Hun interesse in het onderwerp en de resultaten zorgde telkens voor een boost op de momenten waar nodig. Graag zou ik nog een pak andere mensen bedanken. Ze allemaal bij naam vermelden is onmogelijk maar ze niet bedanken voor hun steun en toeverlaat is ongehoord. Bedankt allemaal. Glenn Decock, juni 2013

3 TOELATING TOT BRUIKLEEN iii Toelating tot bruikleen De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef. The author gives permission to make this master dissertation available for consultation and to copy parts of this master dissertation for personal use. In the case of any other use, the limitations of the copyright have to be respected, in particular with regard to the obligation to state expressly the source when quoting results from this master dissertation. Glenn Decock, juni 2013

4 Prestatie-analyse in een cloud-omgeving door Glenn Decock Scriptie ingediend tot het behalen van de academische graad van Burgerlijk Ingenieur in de Computerwetenschappen: optie Informatie- en Communicatietechnologie Academiejaar Promotor: Prof. Dr. Ir. L. Eeckhout Scriptiebegeleiders: Dr.Ir. S. Polfliet, Dr. Ir. F. Ryckbosch Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Elektronica en Informatiesystemen Voorzitter: Prof. Dr. Ir. J. Van Campenhout Samenvatting Het gebruik van cloud-omgevingen is een hot topic. Een aantal bedrijven maken er al gebruik van of evalueren/bekijken het gegeven om de overstap te maken. Wat vele bedrijven niet weten is wat ze moeten verwachten van deze cloud. De prestaties van instanties/virtuele machines in de cloud worden vaak in nietszeggende abstracte eenheden uitgedrukt. In deze thesis wordt er onderzoek verricht naar de prestatie en prestatievariatie van enkele instantietypes binnen de Amazon Elastic Compute Cloud. Via verschillende benchmarks en een Web 2.0 applicatie zal dit onderzocht worden. Resultaten tonen aan dat de prestatievariatie varieert van 10 tot meer dan 50 procent. Om deze te neutraliseren zal er via een simulator kostbesparingsstrategieën ontwikkeld worden. Deze verhogen de verkregen prestatie en dit tegen een lagere globale kost. Trefwoorden Cloud computing, prestatie-analyse, Amazon Elastic Compute Cloud, virtuele machine

5 Performance analysis in a cloud environment Glenn Decock Supervisor(s): Lieven Eeckhout, Stijn Polfliet, Frederick Ryckbosch Abstract This article tries to develop an understanding of the Amazon Elastic Compute Cloud. The subject of the research conducted on this cloud is performance variation. By benchmarking a lot of instances, data will be collected and will be analysed to find this performance variation. Based on this data a simulator is constructed to develop strategies which will tackle the performance variations problems. By using a Web 2.0 application in the cloud, the influence of performance variation on a real application is tested. Keywords Performance analysis, Amazon Elastic Compute Cloud, variation, web 2.0 case study I. INTRODUCTION THE cloud and cloud computing is a hype in the IT nowadays. A lot of big suppliers of cloud services are already widely know by the public. Amazon is the biggest player in public clouds. It delivers the Amazon Elastic Compute Cloud also know as EC2 to the public. While Amazon is one of the biggest, a lot of questions still exist around the cloud and Amazon isn t helping their users at all by using an abstract performance measurement for the instances it delivers. The biggest problem of the cloud comes with the virtualization of the hardware. Suppliers like Amazon promise a certain performance that depends on the instance you as an user hire but the question is whether this performance is equal to the one Amazon promised. Is it possible that there is some variation on this performance and what are the causes of this, if variation exists. These questions are very important for a lot of companies that are willing to make the step towards the cloud. In this extended abstract, these problems have been examined properly and strategies to tackle performance variation will be proposed. Together with all this, a Web 2.0 case study was made to examine the impact of performance variation on a real web application. II. PERFORMANCE ANALYSIS The performance analysis of the Amazon cloud was conducted with benchmarks like DaCapo [1] en UnixBench [2]. A result of 30 UnixBench benchmark scores of 30 different Amazon M1 Large instances can be found in Figure 1. This figure shows two different graphs. One is the score of the benchmark when one process was used, the other is the score when two processes where used. This figure clearly shows that a performance variation exists between different instances of the same type. The difference between the best and the worst performance of an instance is 33 percent. This is caused by the underlying heterogeneous hardware that is used in the Amazon data centers [3], [4]. III. STRATEGIES TO TACKLE PERFORMANCE VARIATION The fact that a performance variation exists can no longer be denied. The above results are clear and strategies to tackle this Fig. 1. UnixBench benchmark score of 30 Amazon M1 Large instances. are necessary. By writing a simulator based upon results that where collected during the performance analysis, it is possible to develop dynamic strategies, test them and compare them without paying anything. The simulator is developed based upon the data of Figure 2. This data was collected during the first performance analysis period ranging from September to December It consist of DaCapo H2 run times of the benchmark that was executed on about 300 different Amazon M1 Small instances. The simulator consists of two major parts. The first part comprises of the optimal cost and the static cost. The optimal cost is the lowest possible cost that is possible based upon the input parameters. These parameters are the number of virtual machines, the amount of workload that needs to be executed in hours, a start-up cost, a boundary that determines what is a good virtual machine and what is bad and a cost per hour for a certain virtual machine type. The optimal cost is calculated as if there was no performance variation, the amount of machines needed multiplied by the workload where the start-up cost has already been added to multiplied by the cost per hour. On the other hand, the static cost is calculated based upon the cumulative distribution. An amount of random points are chosen from this cumulative distribution. The number is based upon the input parameter which is determined by the amount of virtual machines that was needed. These random points correspond to run times of an H2 DaCapo benchmark and these are selected as the execution time. Base upon the difference in percentage between the boundary parameter and this execution time, the variation is determined and the workload in hours is adapted to this. This cost is again the amount of machines needed multiplied by the workload (recalculated workload) where the start-up cost has already been added to multiplied by the cost per hour. The second part comprises the three optimization strategies. These are described in the following subsections. A. The multiply strategy The multiply strategy is a strategy that demands an extra parameter. The multiply factor. This multiply factor multiplies the

6 Fig. 2. Cumulative distribution of the DaCapo H2 results executed on Amazon M1 Small instances. Fig. 3. The results of a cost simulation. amount of virtual machines that was originally demanded. For example if the demand was 10 machines and the multiply factor is 2, 20 machines will be allocated. The 10 machines that where originally demanded and an extra 10. This is because the static cost that was discussed above is calculated based upon the original set of parameters and this machine set is the basis for al the strategies that are developed and tested. After less then one hour of processing workload on all the machines, an evaluation of all the machines is made based upon the boundary parameter and the current execution time. The best machines, for an amount of machines originally needed, are kept and will execute the remainder of the workload. The other machines will be terminated. When using the example, from 20 machines, the best 10 well be kept and the other 10 will be terminated. B. The good versus bad strategy In the good versus bad strategy, the initial amount of machines allocated based upon the parameter and used to calculate the static cost are examined every hour of the workload. Every hour a decision is made based upon the boundary parameter and the execution time (random point of the cumulative distribution) if a machine is good or bad. If it is good it is preserved, if the instance is bad it is terminated and another random point of the cumulative distribution is used. The goal of this strategy is to have all good machines that satisfy the boundary parameter, as fast as possible, taking into account that the examination takes place only once per hour. C. The random strategy The random strategy is really a random one. An amount of random machines are terminated after a certain period and new machines are started (in the simulation new random points are chosen from the cumulative distribution). This strategy is developed to have a strategy that does not take foreknowledge into account and to see the impact of this. IV. SIMULATION AND RESULTS The simulation of which the results are shown in Figure 3, went as follows. An amount of 10 machines with a workload of 10 hours per machine was simulated. A start-up and stop down cost of 15 percent of an hour, nine minutes, was chosen. The price of the Amazon M1 Small instance type was at this moment (May 2013) $ per hour, per instance. This gives an optimal cost of $ The results clearly show that with a good strategy (e.g. the multiply strategy) a lot of money can be saved compared to the static cost. The random strategy does not satisfy the aim because the cost when using this strategy is too high. V. WEB 2.0 CASE STUDY Olio is a Web 2.0 benchmark application which makes it possible to conduct a Web 2.0 benchmark in the cloud. A client machine generates a certain load against a pool of web servers. These web servers conduct their SQL queries against a database and pictures and other static content was put on a separate file storage server. The web servers are Amazon M1 Large instances and the hardware composition of the five web servers that where used can be found in Table I. Server CPU Introduction 1 Intel(R) Xeon(R) CPU E Q Intel(R) Xeon(R) CPU E5645 Q Intel(R) Xeon(R) CPU E5645 Q Intel(R) Xeon(R) CPU E5645 Q Intel(R) Xeon(R) CPU E Q1 12 TABLE I HARDWARE OF THE FIVE WEB SERVERS. The results of the web servers latency times of the tagged event service of the Olio web benchmark application can be found in Figure 4. These results clearly show the impact of the performance variation caused by the hardware. Web servers one and five clearly have higher latency times then servers two, three and four. Depending on the service level agreement that could be offered to customers, this can be come a problem. Normally, high latency times are temporary but with these web servers, the latency times will be consistently high! VI. CONCLUSION The performance analysis shows that a lot of variation in performance exists within a single instance type in the Amazon cloud. This variation, caused by the underlying hardware, can

7 Fig. 4. The latency times of the five web servers. have striking consequences. The results of the Web 2.0 case study illustrate this clearly. By developing strategies which can tackle this problem, a solution is provided to solve partially the problem. By choosing the good instances accurately and terminating the bad ones based upon know information, a higher performance can be achieved together with a cost reduction in the long run. Savings up to eight percent can be achieved with the multiply strategy and up to six percent with the good versus bad strategy. These savings are in comparison to the random static cost. As hardware heterogeneity is a problem that will always exists in data centres, performance variation in the cloud will be too. A good strategy can provide a partial solution but the message remains to be careful when using the cloud. REFERENCES [1] Stephen M. Blackburn, Robin Garner, Chris Hoffmann, Asjad M. Khang, Kathryn S. McKinley, Rotem Bentzur, Amer Diwan, Daniel Feinberg, Daniel Frampton, Samuel Z. Guyer, Martin Hirzel, Antony Hosking, Maria Jump, Han Lee, J. Eliot B. Moss, Aashish Phansalkar, Darko Stefanović, Thomas VanDrunen, Daniel von Dincklage, and Ben Wiedermann, The dacapo benchmarks: java benchmarking development and analysis, SIG- PLAN Not., vol. 41, no. 10, pp , Oct [2] UnixBench, april [3] Benjamin Farley, Ari Juels, Venkatanathan Varadarajan, Thomas Ristenpart, Kevin D. Bowers, and Michael M. Swift, More for your money: exploiting performance heterogeneity in public clouds, in Proceedings of the Third ACM Symposium on Cloud Computing, New York, NY, USA, 2012, SoCC 12, pp. 20:1 20:14, ACM. [4] Zhonghong Ou, Hao Zhuang, Jukka K. Nurminen, Antti Ylä-Jääski, and Pan Hui, Exploiting hardware heterogeneity within the same instance type of amazon ec2, in Proceedings of the 4th USENIX conference on Hot Topics in Cloud Ccomputing, Berkeley, CA, USA, 2012, HotCloud 12, pp. 4 4, USENIX Association.

8 INHOUDSOPGAVE viii Inhoudsopgave Voorwoord Toelating tot bruikleen Overzicht Extended abstract Inhoudsopgave Gebruikte afkortingen ii iii iv v viii xi 1 Inleiding Motivatie Uitdaging Thesis opbouw Cloud computing Inleiding Cloud computing Het cloud computing model Essentiële kenmerken Servicemodel Implementatiemodel Amazon Web Services Amazon Elastic Compute Cloud Virtualisatie Andere Amazon Elastic Compute Cloud gebruikersmodel Instantietypes Elastic Compute Unit Aanverwant werk

9 INHOUDSOPGAVE ix 3 Raamwerk prestatie-analyse Inleiding Java raamwerk Amazon AMI Benchmarking De DaCapo benchmark suite UnixBench benchmark Scripts Linux Shell script Python script Resultaten prestatie-analyse Inleiding Amazon micro instantie Basisprestatie Amazon small instantie Prestatiebeeld over een volledige dag Homogeen datacenter Amazon large instantie Prestatievariatie oorzaken Verificatie van de ECU eenheid Kostsimulatie Inleiding Cumulatieve distributie Invalshoek De optimale kost De doe-niks kost Kostbesparingsstrategieën Vermenigvuldigingsstrategie Goed-versus-slecht-strategie Random afsluit strategie De praktijk Simulatieresultaten Kleine werklast Grote werklast Web 2.0 casestudie Inleiding Web Cloudstone Opzet Oude homogene hardware Heterogene hardware

10 INHOUDSOPGAVE x 6.6 Nieuwe homogene hardware Besluit Realisaties Toekomstperspectief

11 GEBRUIKTE AFKORTINGEN xi Gebruikte afkortingen NIST ECU RISC SVG IDE XSL-FO PDF JDBC HTML XML SOAP SSH HPC GPU CUDA GPGPU SSD CSV API EBS SCP DNS IP National Institute of Standards and Technology Elastic Compute Unit Reduced Instruction Set Computer Scalable Vector Graphics Integrated Development Environment Extensible Stylesheet Language - Formatting Objects Portable Document Format Java DataBase Connectivity HyperText Markup Language Extensible Markup Language Simple Object Access Protocol Secure Shell High Performance Computing Graphics Processing Units Compute Unified Device Architecture General-Purpose computing on Graphics Processing Units Solid State Drive Comma-Separated Values Application Programming Interface Amazon Elastic Block Store Secure Copy Protocol Domain Name System Internet Protocol

12 GEBRUIKTE AFKORTINGEN xii PHP SQL GiB MiB GB MB TB SSD TCP UDP SDK AMI PHP Hypertext Preprocessor Structured Query Language Gibibyte (2 30 bytes) Mebibyte (2 20 bytes) Gigabyte (10 9 bytes) Megabyte (10 6 bytes) Terabyte (10 12 bytes) Solid-State Drive Transmission Control Protocol User Datagram Protocol Software Development Kit Amazon Machine Images

13 INLEIDING 1 Hoofdstuk 1 Inleiding A person who never made a mistake never tried anything new. Albert Einstein 1.1 Motivatie De cloud en cloud computing zijn buzzwords die gebruikt worden voor zowat alles dat verbonden is met Internet. Velen maken er zelfs al gebruik van zonder er echt bewust van te zijn. Applicaties zoals webmail van Hotmail en de bestandsdienst Dropbox zijn maar enkele voorbeelden. Tegenwoordig wordt het woord en de technologie voor zowat alles gebruikt. De populariteit stijgt gestaag maar is het een coup d état of eerder een lege doos? Om hier verder te kunnen op ingegaan is het belangrijk te begrijpen dat de cloud en cloud computing eigenlijk zo nieuw niet zijn, zoals beschreven door James Bond, een technologie expert van Hewlett Packard Enterprise Systems [1]. Het basis concept waar de cloud op gebaseerd is, is het mainframe. Voor de toekomstige ingenieurs in de IT industrie is het concept mainframe wel gekend maar velen zijn er nog nooit mee in aanraking gekomen. Oudere ingenieurs daarentegen zullen dit fenomeen wel nog goed kennen. Het was een centraal computerplatform dat alle computerresources bevat en waar gebruikers op aangesloten zijn via terminals. Een dergelijke terminal was niks anders dan een toetsenbord en een scherm waar de gebruiker commando s kon ingegeven en deze werden dan uitgevoerd op het mainframe platform. Indien het concept, volgens James Bond, van het mainframe vervangen wordt door de cloud en de terminals door de gebruikers die interageren met de cloud kan er ingezien worden dat de gedachte achter de cloud toch niet zo een nieuw gegeven is. Daarentegen bestaan mainframes nog steeds en worden ze nog altijd gebruikt. Getuige daarvan is de lijst aan vacatures die

14 1.1 Motivatie 2 beschikbaar zijn op verschillende jobsites. Samen met de cloud en cloud computing kwam virtualisatie. Dit is toch wat iedereen denkt maar virtualisatie is al meerdere tientallen jaren [2] een gekende technologie en werd veelvuldig gebruikt op de mainframes uit de jaren 80. De inhoud van het begrip is niet veranderd. De technologie zorgt ervoor dat er meerdere besturingssystemen met verschillende gebruikers gelijktijdig lopen op eenzelfde hardwareplatform, zoals bijvoorbeeld een server. De details van deze technologie zullen later besproken worden. In de jaren 80 kwam er een verschuiving in de IT-industrie die zich vooral doorzette in de jaren 90 en Gedistribueerde systemen maakten een opmars waarbij er een verzameling aan losse servers in een datacenter werd geplaatst en waarop dan specifieke alleenstaande software werd geïnstalleerd. Zo had elk bedrijf een specifieke server voor samen met een webserver,... Het probleem hierbij was dat er een enorme ruimte nodig was om al deze servers te plaatsen en dat servers verspreid raakten over meerdere datacenters waardoor er specifieke maatregelen getroffen moesten worden voor beveiliging en dergelijke. Het gebruik van deze gedistribueerde servers werd mogelijk gemaakt door de snelgroeiende computertechnologie en miniaturisatie van die tijd. Deze snelgroeiende markt en technologie had ook een keerzijde. Door de steeds stijgende capaciteit van de servers was er ook een enorme groei aan weggegooide resources. Ten eerste door inactiviteit maar vooral door het feit dat de toenmalige servers zo gedimensioneerd werden dat ze in alle omstandigheden voldoende capaciteit of overschot hadden om toekomstige groei of gebruik op te vangen. Deze verspilling van resources leidde tot een enorme stijging van de kosten voor de bedrijven. Het management van de verschillende servers over verschillende datacenters zorgde op zijn beurt voor een complex gegeven dat zich dan ook weerspiegelde in de kosten. Het gebruik van zoveel verschillende servers zorgde er ook voor dat de datacenters steeds meer servers per rack gingen plaatsen waardoor er stroomproblemen ontstonden. Een oplossing om de groeiende nood aan servers op te vangen was echt nodig. Algemeen wordt aanvaard dat de geschiedenis zich vaak herhaalt en dit is niet anders in de IT-industrie. Met het introduceren van de cloud en cloud computing stapte men af van het gedistribueerde gegeven, werd er overgestapt naar een centraal gegeven en werd virtualisatie terug van onder het stof gehaald. Specifieke datacenters werden ontwikkeld. Deze datacenters zijn voorzien van benodigdheden zoals snelle internetconnecties en andere aspecten en ze worden volgestouwd met servers waar nu via de virtualisatietechniek tientallen servers op draaien daar waar er vroeger maar één op draaide. Samen met een maatschappij waarin er steeds meer bedrijven hun IT-infrastructuur zelf niet meer willen beheren door de complexiteit en de nood aan snelle internetverbindingen die vaak niet aanwezig zijn vormt dit het ideale klimaat voor de cloud.

15 1.1 Motivatie 3 Een coup d état? Engineeringnet schreef hier recent nog een artikel over [3]. Daar waar bedrijven vroeger hun computercapaciteit perfect moesten dimensioneren biedt de cloud de ultieme oplossing. De cloud bevat immers onbeperkte opslagcapaciteit die tot iedere werknemer zijner beschikking staat, waar dan ook ter wereld, en dit op elk uur van de dag. Samen met de onuitputtelijke hoeveelheid rekenkracht die aanspreekbaar is lijkt dit de oplossing voor alle problemen. Niks is minder waar. De cloud staat nog steeds in zijn kinderschoenen. Samen met het introduceren van dit gegeven doken er namelijk nieuwe problemen op. Sommige bedrijven plaatsen data in de cloud maar verwachten dat deze dan ook 24/7 beschikbaar is maar cloud-leveranciers kunnen dit niet altijd garanderen [4]. Andere bedrijven durven geen data in de cloud plaatsen omdat deze niet zeker meer zijn over de beveiliging van de gebruikte cloud-omgeving. Maar de technologie biedt ook vele voordelen, vooral richting applicatieontwikkelaars. Waar applicaties die in een beginfase verkeren weinig tot geen werklast te verduren krijgen, kan dit snel evolueren naar een enorme werklast in de toekomst. Via de schaalbaarheid die mogelijk gemaakt wordt door de virtualisatietechnieken in de cloud moeten de applicatieontwikkelaars de werklast niet echt meer inschatten. De gebruikte computerresources kunnen immers, indien deze dienst geleverd wordt door de leverancier, automatisch meeschalen met de te verwerken werklast. Een ander probleem dat bestaat bij gebruik van de cloud is dat de cloud veel te snel te populair is geworden waardoor velen er gebruik van willen maken maar weinigen de expertise hebben. Verder in dit werk zal immers duidelijk worden dat de gehuurde capaciteit bij cloud-leveranciers niet altijd is wat het zou moeten zijn en dat de gebruiker van de diensten eigenlijk te veel betaalt voor wat hij krijgt indien er geen specifieke voorzorgsmaatregelen getroffen worden. Maar is de cloud en cloud computing dan een lege doos aan het worden? Dat zeker niet. In een maatschappij die in een economische crisis verkeert en een wereld die stilaan de gevolgen begint te voelen van de klimaatwijziging past de cloud perfect. In de eerste plaats doordat er veel minder computerresources verspild worden. Dit komt de gebruiker goed uit want deze zal minder betalen daar hij enkel betaalt voor wat hij werkelijk verbruikt. De niet gebruikte resources op hun beurt kunnen dan gebruikt worden door andere gebruikers. In de tweede plaats omdat de cloud efficiënter gebruik maakt van energie. Aangezien vroeger maar één softwarepakket werd uitgevoerd op een server zal er in de cloud meerdere besturingssystemen onder de vorm van virtuele machines inwerken op één server. Voor eenzelfde energieverbruik wordt er dus meer prestatie geleverd. Dit fenomeen kan alleen maar positief aanvaard worden.

16 1.2 Uitdaging 4 De huidige markt van cloud-leveranciers wordt gedomineerd door een aantal grote spelers zoals Amazon [5], Rackspace [6], Windows Azure [7] en Google App Engine [8]. Dit zijn zeker geen nobele onbekenden meer bij het grote publiek. In dit werk zal er dan ook gebruik gemaakt worden van een van deze spelers namelijk Amazon. Amazon biedt onder zijn Amazon Web Services namelijk de Amazon Elastic Compute Cloud (EC2) [9] aan. 1.2 Uitdaging Het is duidelijk dat de IT-industrie nog voor grote uitdagingen zal te komen staan met de cloud. Zoals reeds aangegeven is één ervan het opleiden van mensen tot experten of mensen voorzien van correcte onafhankelijke informatie rond de cloud en de werking ervan. Er zijn ook vele onduidelijkheden rond de beveiliging van de cloud en de bedrijfszekerheid. Ook zal het een uitdaging vormen om de exacte kostbesparing te bepalen indien er gebruik gemaakt wordt van de cloud want vaak is het nu zo dat er geen exacte opmetingen gemaakt worden van het huidige verbruik terwijl dit in de cloud een exacte afmeting is van wat er wordt verbruikt. Een andere onduidelijkheid bestaat erin hoe applicaties omgezet moeten worden naar cloud toepassingen. Voor vele bedrijven zal de uitdaging erin bestaan om een soort tussenoplossing uit te werken waarin ze deels gebruik maken van de eigen infrastructuur en deels van de cloud-infrastructuur voordat ze volledig kunnen overstappen. En wat dan met de data lock-in, wat met de geleverde prestaties binnen de cloud en hoe verhouden die zich tot hedendaagse servers,... Het is duidelijk dat er nog veel vraagtekens zijn. Indien er specifiek gekeken wordt naar de Amazon cloud dan is het niet duidelijk wat de typische prestatie van een bepaalde instantie die wordt aangeboden nu juist is. Dit gegeven wordt dan nog eens versterkt doordat Amazon gebruik maakt van een abstracte eenheid voor de prestatie. Het bepalen en visualiseren van deze prestatie zal dan ook de eerste echt uitdaging worden in deze scriptie. Op basis van deze resultaten zal het dan mogelijk zijn om een basisprestatie te bepalen en kan er gekeken worden of er prestatievariaties optreden binnen een bepaalde instantiefamilie. Indien zo n prestatievariaties zouden optreden zal er getracht worden de oorzaken te bepalen. Eenmaal de oorzaken gekend zijn kan er op basis van deze kennis getracht worden om oplossingen te ontwikkelen die de prestaties zo hoog mogelijk proberen te krijgen tegen een zo laag mogelijke globale kost. Om de invloed van de ontdekte prestatievariaties, als deze al optreden, beter te kunnen begrijpen zal er een webapplicatie in de cloud geplaatst worden met een 3-tierarchitectuur. Deze IT-architectuur bestaat uit een presentatielaag, businesslogicalaag en een datalaag. Dit betekent dat een client, de presentatielaag, een verzameling van webservers aan-

17 1.3 Thesis opbouw 5 spreekt, de businesslogicalaag, die op hun beurt de databanken aanspreken, de datalaag. Deze verschillende lagen draaien elk op aparte servers. Vandaar de 3-tierarchitectuur omdat er drie lagen van servers ontstaan. Op basis van deze opstelling in de cloud zal het mogelijk worden om per webserver de antwoordtijden van de verschillende aanvragen te bepalen en deze onderling te vergelijken in de hoop zo te kunnen aantonen dat prestatievariatie van instanties binnen de cloud invloed heeft op de uitvoering van echte applicaties binnen deze cloud. 1.3 Thesis opbouw Dit eerste hoofdstuk gaf een algemene inleiding van deze thesis. Meer achtergrond informatie rond cloud computing en de Amazon Elastic Compute Cloud, dat een onderdeel is van de Amazon Web Services, is terug te vinden in Hoofdstuk 2. Op het einde van dit hoofdstuk worden er ook een aantal artikels beschreven die de nood schetsen voor dit werk. Het bevat ook recent gepubliceerd werk waarin reeds oorzaken van prestatievariatie en oplossingen beschreven worden. In Hoofdstuk 3 wordt het gebruikte raamwerk dat ontwikkeld werd om een prestatieanalyse van de Amazon cloud mogelijk te maken beschreven. In Hoofdstuk vier worden dan de resultaten van de verschillende experimenten die uitgevoerd werden in de Amazon cloud met dit raamwerk besproken. Uit deze resultaten zal blijken dat er veel prestatievariatie optreedt binnen deze cloud en logischer wijze zal er dan ook getracht worden om strategieën te ontwikkelen die een oplossing aanbieden om prestatievariatie te beperken. Deze strategieën zullen ontwikkeld worden met een simulator en deze worden beschreven in Hoofdstuk 5. In Hoofdstuk 6 volgt er een Web 2.0 casestudie waarin er opzoek gegaan wordt naar de impact van de verschillende problemen van de Amazon cloud op een echte webapplicatie. Specifiek wordt er gekeken hoe prestatievariatie binnen de Amazon cloud invloed heeft op de antwoordtijden van een echte applicatie. In het laatste hoofdstuk wordt dit onderzoekswerk afgesloten met een besluit waarin alle realisaties nog eens beschreven worden en waarin een toekomstperspectief opgesteld wordt.

18 CLOUD COMPUTING 6 Hoofdstuk 2 Cloud computing A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn t see the clouds at all - he s walking on them. Leonard Louis Levinson 2.1 Inleiding In het volgende hoofdstuk volgt een uiteenzetting van begrippen rond cloud computing en hun betekenis. Dit is een zeer handig gegeven daar deze begrippen universeel zijn en door zowat iedereen gebruikt worden binnen deze wereld. Verder volgt er een beschrijving van de Amazon Elastic Compute Cloud en aspecten die belangrijk zijn als er gesproken wordt over dit fenomeen. In het laatste stuk van dit hoofdstuk wordt het gerelateerde werk besproken. Zoals duidelijk zal worden werd reeds veel onderzoek verricht in de Amazon cloud. Maar eerst en vooral wordt er gestart met de definitie van wat cloud computing nu exact is. 2.2 Cloud computing De definitie voor het Cloud Computing model werd opgesteld door het National Institute of Standards and Technology (NIST). Dit instituut valt onder de bevoegdheid van de Amerikaanse overheid en heeft als doel om standaarden te ontwikkelen in de wetenschap zoals eenheden,... De definitie [10] luidt als volgt: cloud computing is een model dat het mogelijk maakt om op een handige manier, op aanvraag, toegang te verkrijgen tot een gedeelde verzameling van configureerbare computerresources. Deze resources kunnen snel aangevraagd of vrijgegeven worden en dit met minimale interactie met de leverancier en met enig be-

19 2.3 Het cloud computing model 7 heersgemak. Wie echter vandaag rond zich heen kijkt weet dat er veel meer diensten beschikbaar gemaakt worden onder de term cloud en cloud computing dan diegene die beschreven worden met deze definitie. Deze trend is op dit moment wel aan het afvlakken, nu de hype stilaan bij iedereen bekend is. Omdat het belangrijk is om het begrip cloud computing beter te begrijpen en om Amazon in dit verhaal te kunnen kaderen zal er in het volgende deel dieper ingegaan worden op een aantal essentiële kenmerken van cloud computing, samen met nog een aantal modellen die automatisch gekoppeld kunnen worden aan dit begrip. 2.3 Het cloud computing model Het model, cloud computing, bestaat uit vijf essentiële kenmerken, drie servicemodellen en vier implementatiemodellen. Deze definities zijn van essentieel belang want ze zijn algemeen aanvaard en worden dan ook overal gebruikt als men spreekt over cloud computing Essentiële kenmerken Hieronder is een lijst van de essentiëlen kenmerken opgesomd waarin elk kenmerk op zijn beurt nog wat verder beschreven wordt. ˆ Zelfbediening, op aanvraag: Een gebruiker kan zonder enige vorm van menselijke interactie op een zelfstandige en automatische manier, computerresources, aanvragen en gebruiken. ˆ Breedbandige toegang tot het netwerk: De resources zijn allemaal te benaderen over Internet en dit door middel van standaard mechanismen zoals Secure Shell (SSH). Op deze manier is het mogelijke om de verzameling resources te benaderen gebruik makende van een heterogene infrastructuur (laptops, workstations, smartphones, tablets,...). ˆ Verzameling van resources: De resources die aangeboden worden door de leverancier zijn gebundeld opdat deze aanspreekbaar zouden zijn door meerder gebruikers. Afhankelijk van de noden van die gebruikers worden op een dynamisch manier, virtuele and fysieke resources toegewezen. Belangrijk is dat een gebruiker geen kennis heeft over de exacte locatie van de gebruikte resources maar dat er vaak de mogelijkheid bestaat om toch enige voeling te hebben over een locatie door op een hogere, abstracte laag, toch een locatie te definiëren (bv. een land waar het datacenter zich bevindt).

20 2.3 Het cloud computing model 8 ˆ Snel expanderen: De resources kunnen op een snelle, vaak automatische manier, uitbreiden of inkrimpen op basis van de noden van de applicatie/gebruiker. De gebruiker heeft het gevoel dat de hoeveelheid resources oneindig zijn en dat hij op elke gewenst moment, om het even welke hoeveelheid resources tot zijn beschikking heeft. ˆ Gemeten dienst: Leveranciers van cloud computing systemen voorzien in een automatisch, vaak op een abstracte basis, meetsysteem afgestemd op de aard van de diensten. Het basis idee van dit systeem is dat je enkel betaalt voor wat je werkelijk verbruikt. Het verbruik kan zowel gecontroleerd als beperkt worden en dit op een transparante, begrijpbare manier voor zowel de gebruiker als de leverancier van de resources Servicemodel Zoals reeds vermeld bestaat het cloud servicemodel uit drie verschillende modellen. Dit is ook terug te vinden in Figuur Door het algemeen succes van de cloud zijn er reeds vele varianten van deze servicemodellen beschikbaar maar algemeen gezien vormen de volgende drie de basis van allen. ˆ Cloud Software as a Service (SaaS): Het cloudmodel software as a service voorziet de gebruiker van software dat beschikbaar gesteld wordt in de cloud. De gebruikte cloud infrastructuur hiervoor is een collectie van zowel hardware en software die het mogelijk maakt om de vijf essentiële kenmerken van cloud computing tegemoet te komen. De applicaties zijn bereikbaar via talloze mogelijkheden zoals webbrowsers, mobiele applicaties,... Belangrijk hierbij is dat de software voor elke gebruiker dezelfde is op enkele gebruikersinstellingen na. Dit betekent dat de gebruiker geen invloed heeft op de gebruikte technologie, onderliggende software of gebruikte infrastructuur. Indien de gebruiker meer invloed wil uitoefenen op gebruikte software moet deze overstappen op het volgende servicemodel. ˆ Cloud Platform as a Service (PaaS): Het cloudmodel platform as a service biedt de gebruiker meer mogelijkheden aan dan de cloud software as a service. De gebruiker heeft de mogelijkheid om een voorgeconfigureerd platform te gaan gebruiken dat aangeboden wordt door de leverancier, waarop de gebruiker dan zijn eigen applicaties kan gaan draaien. Op deze manier heeft de gebruiker de volledige controle over zijn of haar applicatie. Ook biedt dit platform de mogelijkheid om applicatie specifieke instellingen te maken aan het hostplatform. Indien de gebruiker 1 Bron: computing nl.svg

21 2.3 Het cloud computing model 9 Figuur 2.1: Overzicht van de cloud servicemodellen. meer inspraak wil, zoals de keuze van het gebruikte besturingssysteem of gebruikte infrastructuur of... zal deze moeten overstappen op het volgende servicemodel. ˆ Cloud Infrastructure as a Service (IaaS): Het cloudmodel infrastructure as a service biedt de gebruiker de hoogste graad van vrijheid. De gebruiker kiest de infrastructuurresources zoals opslag, netwerk en processorcapaciteit. Op deze infrastructuur kan dan indien gewenst een eigen gekozen besturingssysteem gedraaid worden met daarop eigen gekozen software waarop de verschillende applicaties dan draaien. Belangrijk is dat de gebruiker de onderliggende cloud infrastructuur zelf niet kan beheren en controleren. De gebruiker kan er enkel gebruik van maken Implementatiemodel Zoals reeds aangeven zijn er vier mogelijke implementatiemodellen beschikbaar voor een cloud infrastructuur. De publieke cloud, de private cloud, de community cloud en de gemengde of hybride cloud. Drie van deze vier zijn terug te vinden in Figuur 2.2.