Prestatie-analyse in een cloud-omgeving

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 2012-2013

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

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

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 2012-2013 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

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. I NTRODUCTION HE 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.

T

II. P ERFORMANCE 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. S TRATEGIES 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 2012. 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

Fig. 2. Cumulative distribution of the DaCapo H2 results executed on Amazon M1 Small instances.

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. S IMULATION 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

Fig. 3. The results of a cost simulation.

moment (May 2013) $ 0.065 per hour, per instance. This gives an optimal cost of $ 7.15 . 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. W EB 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 1 2 3 4 5

CPU Intel(R) Xeon(R) CPU E5-2650 Intel(R) Xeon(R) CPU E5645 Intel(R) Xeon(R) CPU E5645 Intel(R) Xeon(R) CPU E5645 Intel(R) Xeon(R) CPU E5-2650

Introduction Q1’12 Q1’10 Q1’10 Q1’10 Q1’12

TABLE I H ARDWARE 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. C ONCLUSION 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

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. R EFERENCES [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,” SIGPLAN Not., vol. 41, no. 10, pp. 169–190, Oct. 2006. [2] UnixBench, “https://code.google.com/p/byte-unixbench/,” april 2013. [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äa¨ 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.

INHOUDSOPGAVE

viii

Inhoudsopgave Voorwoord

ii

Toelating tot bruikleen

iii

Overzicht

iv

Extended abstract

v

Inhoudsopgave

viii

Gebruikte afkortingen

xi

1 Inleiding 1.1 Motivatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Uitdaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Thesis opbouw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Cloud computing 2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . 2.2 Cloud computing . . . . . . . . . . . . . . . . . . 2.3 Het cloud computing model . . . . . . . . . . . . 2.3.1 Essentiële kenmerken . . . . . . . . . . . . 2.3.2 Servicemodel . . . . . . . . . . . . . . . . 2.3.3 Implementatiemodel . . . . . . . . . . . . 2.4 Amazon Web Services . . . . . . . . . . . . . . . 2.4.1 Amazon Elastic Compute Cloud . . . . . . 2.4.2 Virtualisatie . . . . . . . . . . . . . . . . . 2.4.3 Andere . . . . . . . . . . . . . . . . . . . . 2.5 Amazon Elastic Compute Cloud gebruikersmodel 2.5.1 Instantietypes . . . . . . . . . . . . . . . . 2.5.2 Elastic Compute Unit . . . . . . . . . . . 2.6 Aanverwant werk . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

1 1 4 5 6 6 6 7 7 8 9 11 11 12 12 13 14 18 18

INHOUDSOPGAVE

ix

3 Raamwerk prestatie-analyse 3.1 Inleiding . . . . . . . . . . . . 3.2 Java raamwerk . . . . . . . . 3.3 Amazon AMI . . . . . . . . . 3.4 Benchmarking . . . . . . . . . 3.4.1 De DaCapo benchmark 3.4.2 UnixBench benchmark 3.5 Scripts . . . . . . . . . . . . . 3.5.1 Linux Shell script . . . 3.5.2 Python script . . . . .

. . . . . . . . . . . . suite . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

4 Resultaten prestatie-analyse 4.1 Inleiding . . . . . . . . . . . . . . . . . 4.2 Amazon micro instantie . . . . . . . . 4.3 Basisprestatie Amazon small instantie . 4.4 Prestatiebeeld over een volledige dag . 4.5 Homogeen datacenter . . . . . . . . . . 4.6 Amazon large instantie . . . . . . . . . 4.7 Prestatievariatie oorzaken . . . . . . . 4.8 Verificatie van de ECU eenheid . . . . 5 Kostsimulatie 5.1 Inleiding . . . . . . . . . . . . . . . 5.2 Cumulatieve distributie . . . . . . . 5.3 Invalshoek . . . . . . . . . . . . . . 5.4 De optimale kost . . . . . . . . . . 5.5 De doe-niks kost . . . . . . . . . . 5.6 Kostbesparingsstrategieën . . . . . 5.6.1 Vermenigvuldigingsstrategie 5.6.2 Goed-versus-slecht-strategie 5.6.3 Random afsluit strategie . . 5.7 De praktijk . . . . . . . . . . . . . 5.8 Simulatieresultaten . . . . . . . . . 5.8.1 Kleine werklast . . . . . . . 5.8.2 Grote werklast . . . . . . . 6 Web 2.0 casestudie 6.1 Inleiding . . . . . . . . . . 6.2 Web 2.0 . . . . . . . . . . 6.3 Cloudstone . . . . . . . . 6.3.1 Opzet . . . . . . . 6.4 Oude homogene hardware 6.5 Heterogene hardware . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . .

. . . . . .

. . . . . . . . .

21 21 21 23 24 24 26 30 30 31

. . . . . . . .

32 32 33 35 42 43 47 51 51

. . . . . . . . . . . . .

53 53 54 54 56 56 56 57 57 57 58 59 59 60

. . . . . .

62 62 62 64 64 66 68

INHOUDSOPGAVE

6.6

x

Nieuwe homogene hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7 Besluit 73 7.1 Realisaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.2 Toekomstperspectief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

GEBRUIKTE AFKORTINGEN

Gebruikte afkortingen NIST

National Institute of Standards and Technology

ECU

Elastic Compute Unit

RISC

Reduced Instruction Set Computer

SVG

Scalable Vector Graphics

IDE

Integrated Development Environment

XSL-FO

Extensible Stylesheet Language - Formatting Objects

PDF

Portable Document Format

JDBC

Java DataBase Connectivity

HTML

HyperText Markup Language

XML

Extensible Markup Language

SOAP

Simple Object Access Protocol

SSH

Secure Shell

HPC

High Performance Computing

GPU

Graphics Processing Units

CUDA

Compute Unified Device Architecture

GPGPU

General-Purpose computing on Graphics Processing Units

SSD

Solid State Drive

CSV

Comma-Separated Values

API

Application Programming Interface

EBS

Amazon Elastic Block Store

SCP

Secure Copy Protocol

DNS

Domain Name System

IP

Internet Protocol

xi

GEBRUIKTE AFKORTINGEN

PHP

PHP Hypertext Preprocessor

SQL

Structured Query Language

GiB

Gibibyte (230 bytes)

MiB

Mebibyte (220 bytes)

GB

Gigabyte (109 bytes)

MB

Megabyte (106 bytes)

TB

Terabyte (1012 bytes)

SSD

Solid-State Drive

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

SDK

Software Development Kit

AMI

Amazon Machine Images

xii

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

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 2000. 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 e-mail 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.

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.

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-

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.

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-

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.

2.3.1

Essenti¨ ele 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).


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.

2.3.2

Servicemodel

Zoals reeds vermeld bestaat het cloud servicemodel uit drie verschillende modellen. Dit is ook terug te vinden in Figuur 2.1 1 . 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: http://commons.wikimedia.org/wiki/File:Cloud computing nl.svg


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.

2.3.3

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.


10

Figuur 2.2: Overzicht van drie mogelijke cloud implementatiemodellen.

Private cloud: Deze cloud infrastructuur is gebouwd met als doel om enkel en alleen door meerdere gebruikers van één privé-organisatie gebruikt te worden. De infrastructuur kan in het bezit zijn en beheerd worden door de organisatie zelf maar kan evengoed uitbesteed worden aan externen of een mengeling van beide. Community cloud: De community cloud is een private cloud, gebouwd met als doel om exclusief gebruikt te worden door een bepaalde gemeenschap van organisaties met collectieve belangen. De cloud kan in het bezit zijn van en beheerd worden door een van deze maar kan evengoed uitbesteed worden aan externen. Publieke cloud: De cloud infrastructuur in een publieke cloud heeft als doel om gebruikt te worden door de publieke massa. Deze infrastructuur wordt verhuurd door bedrijven zoals Amazon [9], Rackspace [6], Windows [7], Google [8], ... Hybride cloud: Deze cloud infrastructuur is een mengeling van twee of meerdere implementatiemodellen (privaat, community en publiek). Deze implementatiemodellen blijven uniek maar zijn aan elkaar gebonden door zaken zoals infrastructuur en technologie die ervoor zorgen dat er een mogelijkheid bestaat om data over te dragen van de ene cloud naar de anderen.

2.4 Amazon Web Services

2.4

11

Amazon Web Services

Zoals reeds aangegeven in de inleiding is Amazon, meer bepaalde de Amazon Web Services, een cloud leverancier in de markt van IaaS. Volgens Gartner [11] en zichtbaar op Figuur 2.3 is Amazon op 12 oktober 2012 de grootste leverancier van cloud infrastructuur. Deze Amazon Web Services en meer bepaald de Amazon Elastic Compute Cloud (EC2) vormt een belangrijk onderdeel van deze scriptie.

Figuur 2.3: Magic Quadrant voor Cloud IaaS

2.4.1

Amazon Elastic Compute Cloud

De Amazon Elastic Compute Cloud (EC2) is één van vele services die Amazon aanbiedt onder het pakket van de Amazon Web Services. De Amazon Elastic Compute Cloud is dus een service die gebruikers de mogelijkheid aanbiedt om computercapaciteit te huren in de Amazon publieke cloud. Het voordeel van deze service bestaat erin dat via een webinterface de gebruiker de mogelijkheid heeft om op een overzichtelijke manier zijn

2.4 Amazon Web Services

12

gehuurde computercapaciteit te beheren. Zo heeft de gebruiker de mogelijkheid om verschillende alarmsystemen in te stellen en te gebruiken indien er iets misloopt of indien een bepaald bedrag wordt overschreden. Ook biedt Amazon de mogelijkheid aan om de gehuurde computercapaciteit automatisch te schalen op basis van de gebruikerslast. Zo kunnen er interne loadbalancers gebruikt worden als ook gedetailleerde monitoring van de verschillende gehuurde instanties.

2.4.2

Virtualisatie

Virtualisatie is zoals reeds in de inleiding aangegeven een technologie die het mogelijk maakt om meerdere besturingssystemen gelijktijdig op een server te laten draaien. Dit zorgt ervoor dat hedendaagse servers beter gebruik maken van de rekenkracht die ze bezitten en met deze technologie wordt het ook mogelijk gemaakt om veel meer “servers” aan te bieden op een zelfde oppervlakte binnen het datacenter tegen een zelfde energiekost. Virtualisatiesoftware wordt aangeduid met de term hypervisor. De instanties die Amazon aanbiedt zijn eigenlijk niks anders dan zo’n virtuele machines die aangestuurd worden door een hypervisor. XEN De Amazon Elastic Compute Cloud maakt hoofdzakelijk gebruik van de open-source virtualisatiesoftware, hypervisor, XEN. Er bestaan twee verschillende types van hypervisors. XEN [12, 13] is een type-één hypervisor, ook beter bekend als een bare metal hypervisor. Een type-één hypervisor werkt direct op de hardware zoals zichtbaar in Figuur 2.4(a). De hypervisor wordt uitgevoerd in de meest bevoorrechte processor toestand en staat in voor zowat alles. Geheugenbeheer, beveiliging middels isolatie en het plannen van het gebruik van de hardware door de verschillende virtuele machines/instanties. De besturingssystemen die door Xen beheerd worden zijn in feite para-gevirtualiseerde besturingssystemen. Dit betekent dat deze besturingssystemen aangepast worden met specifieke drivers en parameters om te kunnen werken met de Xen hypervisor.

2.4.3

Andere

Naast XEN is VMware ESX [14] nog een bekende type-één hypervisor. Er bestaan ook type twee hypervisors zoals VirtualBox [15] en VMware ESXi [14], deze werken niet direct in op de hardware maar draaien bovenop een besturingssysteem zoals zichtbaar in Figuur 2.4(b). Het besturingssysteem op deze figuur wordt aangegeven met OS, afkorting voor het Engelse öperating system”.

2.5 Amazon Elastic Compute Cloud gebruikersmodel

(a) Hypervisor type-één

13

(b) Hypervisor typetwee

Figuur 2.4: Overzicht van de verschillende types hypervisors.

2.5

Amazon Elastic Compute Cloud gebruikersmodel

De Amazon Elastic Compute Cloud of EC2 bestaat uit verschillende aspecten. Om te beginnen wordt de infrastructuur opgedeeld in verschillende regio’s. Deze zijn op 24 april 2013 de volgende: US East (N. Virginia), US West (Oregon), US West (noord Californië), EU (Ierland), Asia Pacific (Singapore), Asia Pacific (Tokio), Asia Pacific (Sydney) en South America (Soa Paulo). Binnen deze regio’s zijn er vaak nog verschillende zones. Dit zijn in feite zelfstandige datacenters die deel uitmaken van een geheel dat dus wordt aangeduid met een regio.


2.5.1

14

Instantietypes

Binnen zo een regio die hierboven werd voorgesteld worden er instanties aangeboden. Dit zijn dus virtuele machines die binnen een dergelijken regio/zone draaien. Deze worden op hun beurt opgedeeld in verschillende soorten. Op deze manier heeft de eindgebruiker de mogelijkheid om een instantie/virtuele machine te kiezen die voldoet aan zijn eisen. Opmerkelijk is dat niet alle instanties overal beschikbaar zijn. Enige aandacht is dus vereist indien er een speciaal type nodig is. De eerste generatie instanties, de M1, biedt de eindgebruiker een balans van alles aan. De kostprijs van de instanties is laag en deze kunnen gebruikt worden voor allerlei applicaties. Ze bestaat uit: M1 Small Instance. Dit is de standaard instantie en beschikt over 1.7 GiB aan werkgeheugen en één EC2 Compute eenheid (één virtuele kern) aan rekenkracht. Ze voorziet in 160 GB aan lokale opslag en is beschikbaar in zowel een 32-bit als 64-bit platform. M1 Medium Instance. Deze instantie beschikt over 3.75 GiB aan werkgeheugen, twee EC2 Compute eenheden (één virtuele kern) aan rekenkracht, 410 GB aan lokale opslag en terug zowel een 32-bit als 64-bit platform. M1 Large Instance. Deze large instantie beschikt over 7.5 GiB aan werkgeheugen, vier EC2 Compute eenheden rekenkracht (twee virtuele kernen met twee EC2 Compute eenheden aan rekenkracht) en 850 GB lokale opslag. Deze instantie is enkel verkrijgbaar als 64-bit platform. M1 Extra Large Instance. Deze extra large instantie beschikt over 15 GiB aan werkgeheugen, acht EC2 Compute eenheden aan rekenkracht (vier virtuele processorkernen met elk twee EC2 Compute eenheden aan rekenkracht) en 1,6 TB aan lokale opslag. Deze instantie is tevens enkel verkrijgbaar als 64-bit platform.

De tweede generatie instanties, de M3, biedt de eindgebruiker instanties aan die beschikken over meer rekenkracht in vergelijking met de eerste generatie. Deze zijn dus zeer geschikt voor applicaties die net iets meer vragen. Naast de extra rekenkracht beschikken deze ook over een uitgebreider geheugen. M3 Extra Large Instance. Deze bevat 15 GiB aan werkgeheugen en 13 EC2 Compute eenheden aan rekenkracht (vier virtuele processorkernen met elk 3.25 EC2 Compute eenheden aan rekenkracht). Enkel Elastic Block Store (EBS) opslag en beschikbaar als 64-bit platform.


15

M3 Double Extra Large Instance. Deze instantie bevat het dubbel aan werkgeheugen, 30 GiB en het dubbel aan rekenkracht 26 EC2 Compute eenheden verdeeld over acht virtuele processorkernen met elk 3.25 EC2 Compute eenheden aan rekenkracht. Terug enkel EBS opslag en beschikbaar als 64-bit platform.

Amazon biedt de eindgebruiker ook de kans aan om een micro instantie te huren. Deze instantie is speciaal ten opzichte van de andere omdat deze beschikt over de mogelijkheid om extra processorrekenkracht aan te spreken indien nodig. Dit kan in zeer korte periodes waardoor deze instantie geschikt is voor ontwikkeling maar ook voor kleine applicaties die af en toe wat extra rekenkracht nodig hebben. Micro Instance. Beschikt over 613 MiB aan werkgeheugen en de rekenkracht kan tot twee ECUs oplopen indien nodig en dit voor een korte periode. Enkel EBS opslag en deze instantie is beschikbaar zowel als 32-bit als 64-bit platform.

Voor de eindgebruikers die zeer werkgeheugen intensieve applicaties in de Amazon Elastic Compute Cloud willen plaatsen bestaan de volgende instanties: High-Memory Extra Large Instance. Bevat 17.1 GiB aan werkgeheugen met 6.5 ECU aan rekenkracht verdeelt over twee virtuele processorkernen met elk 3.25 EC2. Er staat 420 GB aan lokale opslag ter beschikking en deze instantie is enkel verkrijgbaar als 64-bit platform. High-Memory Double Extra Large Instance. Bevat twee keer zo veel werkgeheugen als de vorige instantie, 34.2 GiB. De hoeveelheid rekenkracht is ook verdubbeld naar 13 EC2 Compute eenheden, verdeelt over vier virtuele processorkernen met elk 3.25 EC2 Compute eenheden. Er is 850 GB aan lokale opslag beschikbaar en is enkel als 64-bit platform verkrijgbaar. High-Memory Quadruple Extra Large Instance. Er is 68.4 GiB aan werkgeheugen beschikbaar en 26 EC2 Compute eenheden aan rekenkracht verdeelt over acht virtuele processorkernen elk met 3.25 EC2 Compute eenehden. Opslag wordt voorzien door 1.6 TB aan lokale opslag en beschikbaar als 64-bit platform.

Net zoals er instanties bestaan voor eindgebruikers met een vraag naar veel geheugen bestaan er ook instanties voor eindgebruikers die veel rekenkracht vragen: High-CPU Medium Instance. Deze bevat 1.7 GiB aan werkgeheugen met 5 EC2 Compute eenheden aan rekenkracht verdeelt over twee virtuele processorkernen met 2.5 EC2 Compute eenehden. Er wordt 350 GB aan lokale opslag voorzien. Deze instantie is beschikbaar zowel als 32-bit als 64-bit platform.


16

High-CPU Extra Large Instance. Er is 7 GiB aan werkgeheugen beschikbaar bij deze instantie. De rekenkracht bestaat uit 20 EC2 Compute eenheden verdeelt over acht virtuele processorkernen met elk 2.5 EC2 Compute eenheden. Er is 1.6 TB aan lokale opslag en deze instantie is enkel beschikbaar als 64-bit platform.

Cluster instanties worden ook aangeboden door Amazon. Deze instanties zijn zeer geschikt voor High Performance Compute (HPC) applicaties. Dit zijn applicaties die enorm veel rekenkracht vragen maar ook toegang nodig hebben tot een netwerkaansluiting met hoge doorvoersnelheid om onderling te kunnen communiceren. Er zijn twee instanties die bestaan uit pure rekenkracht en één instantie die voorziet in Graphics Processing Units (GPUs). Dit type instantie is dus zeer geschikt om clusters op te zetten die bestaan uit grafische rekenkracht. Voorbeelden van applicaties die hier voordeel uit halen zijn applicaties die geschreven zijn in de Compute Unified Device Architecture (CUDA) taal. Dit is een General-purpose computing on graphics processing units (GPGPU) technologie die de mogelijkheid aanbiedt om software te ontwikkelen die uitgevoerd wordt op de grafische kaart en dus gebruik kan maken van de mogelijkheid om enorm veel berekeningen parallel uit te voeren. Cluster Compute Eight Extra Large. Deze instantie beschikt over een werkgeheugen van 60.5 GiB. De rekenkracht bestaat uit 88 EC2 Compute eenheden en een lokale opslag van 3.3 TB. Het is een 64-bit platform dat toegang heeft tot een 10 Gigabit Ethernet netwerk. High Memory Cluster Eight Extra Large Het werkgeheugen van deze instantie is 244 GiB groot. De rekenkracht wordt voorzien door 88 EC2 Compute eenheden en er wordt 240 GB aan lokale opslag voorzien. Terug enkel en alleen een 64-bit platform dat op zijn beurt ook toegang heeft tot een 10 Gigabit Ethernet netwerk. Cluster GPU Quadruple Extra Large. Met een werkgeheugen van 22 GiB en 33.5 EC2 Compute eenheden aan rekenkracht is dit een krachtige instantie. Het belangrijkste aspect aan deze instantie zijn de twee NVIDIA Tesla Fermi M2050 GPUs die voorzien in grafische rekenkracht. Samen met 1.6 TB aan lokale opslag is dit de instantie voor grafische cluster berekeningen. Het is een 64-bit platform dat ook toegang heeft tot een 10 Gigabit Ethernet netwerk.

Indien de eindgebruiker applicaties in de Amazon cloud wil plaatsen, die een enorme nood hebben aan een hoge I/O prestatie, vragen deze best onderstaande instantietype aan. Deze biedt namelijk een hoge I/O performantie aan op basis van Solid-State Drive (SSD) opslag.


17

High I/O Quadruple Extra Large. Het beschikbare werkgeheugen van dit type instantie is 60.5 GiB groot. Rekenkracht is beschikbaar als 35 EC2 Compute eenheden en de lokale opslag wordt voorzien door 2 * 1024 GB aan SSD gebaseerde opslag. Het 64-bit platform heeft op zijn beurt ook toegang tot een 10 Gigabit Ethernet netwerk.

Naast al deze verschillende instantietypes biedt Amazon nog een speciaal type instantie aan en dit is een instantie die een enorme hoeveelheid opslag tot zijn beschikking heeft. Dit type instantie is nieuw en geeft duidelijk aan dat de Amazon cloud blijft evolueren en blijft tegemoetkomen aan de eisen van zijn gebruikers. High Storage Eight Extra Large. Dit type instantie bevat 117 GiB aan intern werkgeheugen, een rekenkracht van 35 EC2 Compute eenheden en de mogelijkheid tot het gebruik van 24 * 2 TB aan harde schijven voor lokale opslag. Dit in combinatie met een 64-bit platform en een 10 Gigabit Ethernet netwerk.

Het is duidelijk dat er veel verschillende types aan instanties aangeboden worden die elk hun specifieke eigenschappen hebben waardoor de gebruiker in staat gesteld wordt om een type te kiezen dat zo goed mogelijk past bij zijn noden en wensen. De Amazon cloud omvat nog vele aspecten. Zo worden vele extra features aangeboden zoals cloudwatch die gebruikers instaat stelt om een real-time opvolging te hebben van de gehuurde resources. Het stelt de gebruiker ook instaat om eigen metrieken aan te vragen en te gaan gebruiken. Naast de cloud watch worden er nog zaken zoals automatisch schalen van resources aangeboden samen met de mogelijkheid tot gebruik van een loadbalancer. Echter zijn er nog twee belangrijke aspecten die nog niet ter sprake zijn gekomen. De abstracte eenheid waarin Amazon de prestatie uitdrukt van de geleverde instanties, de Elastic Compute Unit (ECU), is er één van en het gebruikte prijsmodel. Het prijsmodel wordt hier volgend besproken en de betekenis van de ECU eenheid wordt in de volgende sectie besproken. Het prijsmodel van Amazon is zeer specifiek. Elk instantietype heeft een specifieke prijs. Deze prijs wordt be¨ınvloed door de regio waarin de instantie opgestart wordt. Daarbovenop wordt de prijs ook bepaald door het type besturingssysteem dat gekozen word. Zo zal een Windows besturingssysteem steeds iets duurder zijn dan een Linux gebaseerde distributie. Daarnaast bestaan er mogelijkheden om de prijs van je instantie te drukken. Zo kan een instantie een bepaalde periode gereserveerd worden wat ervoor zal zorgen dat de prijs die per uur betaalt moet worden daalt. Voor mensen die niet direct hun resources nodig hebben onder de vorm van instanties bestaat er een spotprijssysteem. Hierbij kan de eindgebruiker gaan bieden op een hoeveelheid resources. Dit systeem werkt zoals een beurs met vraag en aanbod. Eenmaal de prijs geëvenaard wordt die werd ingesteld, wordt

2.6 Aanverwant werk

18

die bepaalde hoeveelheid resources gehuurd aan de geboden prijs. Naast deze kostprijs die steeds per uur bepaald wordt, dit betekent dat indien je maar 10 minuten gebruikt van een instantie je toch het volledige uur zal moeten betalen, worden er nog extra kosten in rekening gebracht voor data transfers en I/O prestaties. Dataopslag is ook nog een extra kost die bovenop de kostprijs van een instantie zal worden aangerekend.

2.5.2

Elastic Compute Unit

De Elastic Compute Unit of de ECU is de abstracte eenheid waarin Amazon de prestatie of rekenkracht van de virtuele processor beschrijft van een aangeboden instantie. Het gebruik van zo’n abstracte eenheid zorgt voor enige verwarring bij de gebruikers daar deze weinig vertelt over de werkelijke prestatie en deze niet toelaat tot vergelijken met hedendaagse servers. Volgens de Amazon documentatie, die online beschikbaar is, komt deze ECU eenheid overeen met een rekencapaciteit geleverd door een 1.0 - 1.2 GHz 2007 Opteron of Xeon processor. Dit komt ook overeen met een Xeon processor uit begin 2006 met een snelheid van 1.7 GHz. Deze zouden zo opgesteld zijn door verschillende benchmarks uit te voeren op deze platformen. Probleem hierbij is ten eerste dat Amazon niks communiceert over de gebruikte benchmarks en bijhorende resultaten en ten tweede dat AMD in die periode geen enkele processor had met zo een snelheid. Opmerkelijk is zelf dat de toenmalige processoren van AMD geen ondersteuning hadden tot het verlagen van de processorsnelheid. Dit zal verder in deze scriptie nog duidelijk worden als er zo’n server uit die periode met een Opteron serverprocessor zal getest worden. Deze verschillende gegevens maken duidelijk dat er nood is aan het bepalen van de prestatie aan de hand van benchmarks die iedereen kan gebruiken en door middel van de resultaten te visualiseren zal het mogelijk worden om de instanties binnen deze cloud te vergelijken met hedendaagse computerhardware.

2.6

Aanverwant werk

De Amazon cloud infrastructuur is reeds vele malen het onderwerp geweest van onderzoek. Allerlei aspecten van de geleverde infrastructuur werden reeds grondig onderzocht. Mayer et al. [16] onderzochten of de dataopslag service, de Amazon S3, voldoet aan de huidige opslag noden voor wetenschappers. Deze genereren namelijk makkelijk gigabytes aan gegevens en deze moeten ergens opgeslagen worden. Uit de paper blijkt dat de S3 service niet echt bruikbaar is voor wetenschappers en hun toepassingen. Een aantal aanbevelingen worden meegegeven voor toekomstige cloud opslag leveranciers. Simson et al. [17] onderzochten opnieuw de S3 service samen met de Elastic Compute Cloud en de Simple Queue Service. In deze paper die toch al een aantal jaren oud is

2.6 Aanverwant werk

19

wordt aangegeven dat de EC2 cloud voldoet aan wat er beloofd wordt. Er wordt gewezen op het makkelijk toegankelijk zijn van de opslagdienst S3 in samenwerking met de EC2. Blijkt wel dat de S3 service soms enorm traag is en dat trage transacties van data beter stopgezet worden en nieuwe worden opgestart. Ook wordt er gewezen op het gevaar van het Service Level Agreement die Amazon aanbiedt. Deze is nogal breed en zorgt ervoor dat Amazon veel macht heeft. Zo kan deze instanties afsluiten in de EC2 cloud zonder er echt een reden voor te hebben en dit op elk moment van de dag. Guohui et al. [18] wordt de impact van virtualisatie op de netwerkprestatie van de Amazon Elastic Compute Cloud onderzocht. Zo worden de wachttijden gemeten van verschillende datapakketjes, de TCP en UDP doorvoersnelheid samen met de hoeveelheid datapakketjes die verloren gaan. De resultaten tonen aan dat er abnormaal hoge wachttijden optreden bij datapakketjes en dat de TCP en UDP doorvoersnelheid absoluut niet stabiel zijn. De oorzaak van dit alles wordt toegewezen aan de virtualisatie die gebruikt wordt binnen deze cloud. Doordat virtuele machines aangestuurd worden door virtualisatiesoftware, hypervisors, zijn deze op bepaalde tijdstippen niet bereikbaar waardoor buffers opgevuld worden en connecties verloren gaan met de gevonden resultaten als gevolg. In Sean et al. [19] wordt de Amazon EC2 onderworpen aan onderzoek om te bepalen of de cloud in staat is om High Performance Computing Applicaties uit te voeren. De resultaten worden vergeleken met een HPC cluster die tot de beschikking stond van de onderzoekers. De resulaten tonen aan dat de cloud niet beschikt over instanties die voorzien zijn van de juiste netwerkconnecties waardoor een cluster die opgesteld wordt met cloud instanties tot wel twintig keer trager zijn dan een typische HPC cluster. De oorzaak zou opnieuw te wijten zijn aan de virtualisaties die gebruikt worden binnen zo een cloud omgeving. Belangrijke opmerking bij deze resultaten is dat in 2013, de paper is van 2010, reeds instanties beschikbaar zijn in de cloud die speciaal voorzien zijn om HPC applicaties te gaan uitvoeren en dat deze beschikken over betere netwerktoegangen dan andere instanties. Om verschillende cloud leveranciers te kunnen vergelijken werd CloudCmp ontwikkeld. Ang et al. [20] geeft hier een beschrijving van en in deze paper wordt de software ook toegepast op de vier bekendste leveranciers: Amazon AWS, Microsoft Azure, Google App Engine en Rackspace. De resultaten tonen aan dat er grote verschillen waarneembaar zijn tussen de vier leveranciers. Dit zowel op vlak van geleverde prestatie als op vlak van kosten. De vraag die natuurlijk gesteld moet worden is hoe belangrijk de resultaten uit de paper zijn daar cloud-omgevingen onderhevig zijn aan upgrades, prijsschommelingen en steeds opnieuw proberen te voldoen aan de huidige marktwensen. Malte et al. [21] heeft op zich niks te maken met echt onderzoek maar gaat over een aantal zonden die onderzoekers maken indien ze onderzoek verrichten op cloud-omgevingen. In deze paper wordt er duidelijk gewezen op het aspect dat de cloud geen homogeen gegeven

2.6 Aanverwant werk

20

is en dat wetenschappelijke cluster dit vaak wel zijn. Er wordt aangehaald dat deze heterogeniteit kan leiden tot prestatievariatie maar de invloed ervan wordt niet onderzocht. Recent zijn er nog twee papers [22, 23] verschenen waarin er opzoek gegaan wordt naar de oorzaken die leiden tot prestatievariatie in de Amazon Elastic Compute Cloud. Zhonghong et al. [22], een paper die werd voorgesteld op de HotCloud conferentie in Boston (USA) op 12-13 juni 2012, wordt er op zoek gegaan naar de hardwareconfiguratie van de Amazon cloud en aan de hand van micro-benchmarks wordt er op zoek gegaan naar de prestatie en prestatievariatie van verschillende instantietypes. Door dit prestatiebeeld te vergelijken met de gebruikte hardwareconfiguratie wordt de conclusie gemaakt dat de oorzaak van prestatievariatie de hardware heterogeniteit is van de Amazon datacenters. Via een kostanalyse wordt er bepaald dat de mogelijkheid bestaat om tot 30 % te besparen indien de juiste instanties gekozen worden uit een verzameling van instanties. Farley et al. [23] die werd gepubliceerd op de ACM Symposium on Cloud Computing, in San Jose Californië op 14-17 oktober 2012, gaat net een stapje verder. Hier wordt terug aangegeven dat de hardware heterogeniteit van de huidige Amazon datacenters leidt tot variatie in prestatie. Via een studie rond “placement gaming”, een studie waarbij er strategieën ontwikkeld worden die eindgebruikers in staat stellen om efficiënter gebruik te maken van de Amazon resources, wordt er een gefundeerd besluit genomen dat eindgebruikers te veel betalen indien ze geen voorzorgsmaatregelen nemen. Het is duidelijk dat er nood is aan een prestatie-analyse van de Amazon Elastic Compute Cloud. De recent gepubliceerde papers ondersteunen dit ten zeerste. Deze papers maken echter enkel gebruik van benchmarks om de prestatievariatie aan te geven in de Amazon cloud. In dit werk wordt er nog een stap verder gegaan. Via een complexere benchmark die ontwikkeld werd om hedendaagse systemen te onderwerpen aan verschillende testen zal er een prestatiebeeld opgesteld en gevisualiseerd worden. Verder zal er via een Web 2.0 casestudie, een 3-tier applicatie in de cloud geplaatst worden en via latentietijden van webservers die deel uitmaken van de applicatieopstelling zal aangetoond worden dat de hardware heterogeniteit wel degelijk invloed heeft op de prestatie en zelfs leidt tot prestatievariaties op applicatieniveau.

RAAMWERK PRESTATIE-ANALYSE

21

Hoofdstuk 3 Raamwerk prestatie-analyse “Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.” H. James Harrington

3.1

Inleiding

Opmeten of beter gezegd het bepalen van de prestatie van de verschillende types aan virtuele machines die aangeboden worden door Amazon, is de eerste stap in een proces om beter te begrijpen hoe de cloud werkt. Zoals reeds aangegeven in het vorige hoofdstuk over cloud computing maakt Amazon gebruik van een eigen prestatiemaatstaf voor hun virtuele machines in de cloud. Deze abstracte eenheid, de ECU eenheid of Elastic Compute Unit, zegt eigenlijk zeer weinig. Om die eerste stap te kunnen zetten, het opmeten van de prestaties van verschillende instanties binnen de Amazon cloud is er een raamwerk nodig om op een automatische manier verschillende benchmarks uit te voeren op een verzameling van instanties die automatisch gealloceerd zullen worden. Deze software stelt in staat om de eerste omzetting naar bruikbare data mogelijk te maken en dit reeds in de cloud.

3.2

Java raamwerk

Om automatisch en snel verschillende en meerdere benchmarks te kunnen uitvoeren op verschillende instanties op hetzelfde moment werd er een Java raamwerk geschreven. Figuur 3.1 toont een schematische weergave van dit gegeven.

3.2 Java raamwerk

22

Figuur 3.1: Componentendiagram voor het Java raamwerk.

Om eerst terug te komen op de extra functionaliteit die niet verwerkt werd in het uiteindelijke raamwerk. Dit is het databanksysteem. Via dit systeem moet het mogelijk zijn om dynamisch informatie te verzamelen over de gebruikte instantie. Hardware-informatie en benchmarkresultaten en extra zaken kunnen op een overzichtelijke manier opgeslagen worden waar later statistieken kunnen uitgehaald worden. Via een aantal parameters die gezet werden in het raamwerk en dan een export naar een jar bestand werd het raamwerk ontplooid en uitgevoerd. Het raamwerk bestaat uit een aantal grote componenten die allemaal ondergebracht werden in de applicatielogica. De console is de grootste en deze maakt op zijn beurt gebruik van componenten zoals Secure Shell (SSH), Secure Copy Protocol (SCP) en bestandsverwerking. De Linux commando’s zoals het SSH commando werden allemaal voorzien in Java code. Op deze manier is het mogelijk om van op afstand, op een automatische manier, in te loggen op de gehuurde instanties en daar commando’s af te vuren zonder enige menselijke tussenkomst. Via het SCP commando kunnen er dan bestanden afgehaald worden en overgezet worden op een lokale server. Om de Amazon instanties te kunnen aanspreken vanuit de Java code is de Amazon Software Development Kit (SDK) nodig. Een SDK is een verzameling van code en componenten die ontwikkelaars in staat stellen om op een makkelijkere manier applicaties te ontwikkelen. Bij Amazon in het bijzonder zorgt de SDK ervoor dat er makkelijk cloud-applicaties ontwikkeld kunnen worden die via een API, instanties dynamisch kunnen aanspreken. De SDK voorziet namelijk in code die het mogelijk maakt om op een

3.3 Amazon AMI

23

abstracte manier een bepaalde regio aan te spreken en daar een gekozen instantie in los te laten. Het publiek DNS adres kan opgevraagd worden en vanaf dat moment kan je met de verkregen instantie alles doen dat mogelijk is via de online webpagina. Via de console kunnen er parameters ingesteld worden die bepalen hoeveel instanties aangevraagd worden en van welk type deze moeten zijn. Via de bestandsverwerkingscomponent worden zoals reeds aangegeven de publieke DNS adressen opgevraagd en weggeschreven die op hun beurt dan gebruikt zullen worden om de instanties aan te spreken. Voor het gebruik van het raamwerk zijn er nog drie zaken nodig. Dit zijn de benchmarks, de Amazon Machine Images (AMIs) en de scripts die geschreven werden om de benchmarks op een gecontroleerde manier te kunnen uitvoeren. Wat een AMI is wordt besproken in de volgende sectie en in de daarop volgende sectie zullen de verschillende benchmarks besproken worden die gebruikt werden gedurende de onderzoeksperiode. Op basis van deze benchmarks werden er scripts geschreven. Dit zijn stukjes code die het mogelijk maken om taken en procedures automatisch te laten verlopen. Er werden zo’n scripts geschreven op basis van Unix Shell en op basis van de scripting taal Python. Deze worden verder ook besproken.

3.3

Amazon AMI

Amazon biedt verschillende instanties aan zoals vermeld in het vorige hoofdstuk. Maar naast zo een instantie is er nog een besturingssysteem nodig om deze instantie te kunnen gebruiken. Deze worden aangeboden onder AMIs. Vele voor geconfigureerde serverbesturingssystemen worden aangeboden zoals Ubuntu server, Windows server en anderen. Naast deze kale besturingssystemen worden er ook AMIs aangeboden met vooraf ge¨ınstalleerde software pakketten zoals een CentOS (een Linux server distributie) met een Nginx webserver reeds voor ge¨ınstalleerd. Er zijn meer dan 2000 verschillende AMIs beschikbaar maar Amazon biedt de gebruikers ook de mogelijkheid aan om zelf zo’n AMIs te maken. In het geval van dit werk is dit zeer handig omdat op deze manier specifieke AMIs gemaakt kunnen worden die voorzien zijn van de juiste benchmarks en hun instellingen. Op deze manier wordt het dan mogelijk gemaakt om op meerdere machines op hetzelfde moment, met dezelfde instellingen, dezelfde benchmark te gaan uitvoeren. Elke eigen ontwikkelde AMI, en de AMIs die voorzien worden door Amazon, is voorzien van een code die dan opgegeven kan worden in het raamwerk waardoor deze configuratie geplaatst en uitgevoerd wordt in de cloud. Naast dit gegeven bestaat er de mogelijkheid om eigen virtuele-machineafbeeldingen in de cloud te importeren. Zo wordt het mogelijk gemaakt om bestaande machines met specifieke instellingen ook onder te brengen in de cloud. Dit gegeven verlaagt de drempel

3.4 Benchmarking

24

voor bedrijven om de overstap naar een cloud omgeving te maken. Deze kunnen namelijk, indien ze zelf reeds van virtualisatie gebruik maken, snel overstappen naar de Amazon cloud. De mogelijkheid bestaat ook om de virtuele machineafbeeldingen terug uit de cloud te exporteren. Zelfs VMware vSphere images kunnen in de Amazon cloud geplaatst worden. Dit wordt mogelijk gemaakt via een speciale connector. Van deze mogelijkheden is er geen gebruik gemaakt in de cloud maar voor toekomstige gebruikers kan dit gegeven wel belangrijk zijn, het verlaagt immers de lock-in.

3.4

Benchmarking

De Elastic Compute Unit (ECU), de abstracte eenheid die gebruikt wordt door Amazon om de prestatie aan te geven van een instantie, is zoals duidelijk werd in hoofdstuk twee een prestatiemaat die weinig tot niks zegt. Om de prestatie in beeld te brengen met het Java raamwerk werd er daarom beroep gedaan op benchmarks. Deze benchmarks zijn vrij te verkrijgen op het Internet waardoor het mogelijk wordt voor andere om deze ook te gebruiken en hun resultaten te gaan vergelijken met deze die in het volgende hoofdstuk worden opgenomen. Door gebruik te maken van zo’n benchmarks zal het ook mogelijk worden om de basisprestatie van verschillende instanties te bepalen. Deze basisprestatie is nodig opdat het mogelijk zou worden om prestaties van Amazon instanties onderling te vergelijken. Eenmaal een basisprestatie voor een bepaald type is opgesteld wordt het mogelijk om procentuele verschillen op te stellen tussen die basisprestatie en een bepaalde virtuele machine van het zelfde type waardoor het mogelijk wordt om de prestatieverschillen in kaart te brengen. Algemeen werden er twee verschillende benchmark suites gebruikt. De DaCapo en de UnixBench suite. Deze worden in de volgende secties besproken.

3.4.1

De DaCapo benchmark suite

De DaCapo benchmark suite [24, 25] is een benchmark suite die volledige geschreven is op basis van de programmeertaal Java. Het bestaat uit een aantal open-source applicaties met niet-triviale geheugen toegangspatronen. Deze applicaties werken sterk in op allerlei aspecten van het systeem waardoor ze een ideale benchmark zijn om recente systemen te testen. De initiële suite was een samenwerking tussen een achttal instituten en is een samenvatting van een vijftal jaar onderzoekswerk. De eerste versie kwam uit in 2009 na drie jaar ontwikkeling. De suite bestaat uit de volgende verschillende applicaties:

3.4 Benchmarking

25

Avrora: Deze applicatie simuleert een aantal programma’s die op een netwerk van AVR microcontrollers worden uitgevoerd. Een AVR microcontroller is een 8 bit-RISC-microcontroller die werd ontwikkeld door Atmel in het jaar 1996. Batik: Deze applicatie genereert een aantal Scalable Vector Graphics (SVG) afbeeldingen die gebaseerd zijn op de unit test van Apache batik. Eclipse: Voert een aantal niet grafische prestatie testen uit. Deze zijn onderdeel van de Eclipse Integrated Development Environment (IDE). Fop: Deze applicatie neemt een Extensible Stylesheet Language - Formatting Objects (XSL-FO) bestand en construeert hieruit een Portable Document Format (PDF) bestand. H2: Deze applicatie voert een Java DataBase Connectivity (JDBC) benchmark uit in het geheugen. Er worden een aantal banktransacties uitgevoerd. Jython: Dit voert de pybench [26] Python benchmark uit. Luindex: Maakt gebruik van Lucene [27] om een verzameling van documenten te indexeren. Deze zijn de werken van William Shakespeare en de King James bijbel. Lusearch: Maakt opnieuw gebruik van Lucene. Deze applicatie gaat opzoek in de werken van William Shakespeare en de King James bijbel naar kernwoorden. Pmd: Deze applicatie gaat opzoek naar een aantal programmeerproblemen in de broncode van een set van Java classes. Sunflow: Een ray tracing programma die een verzameling van afbeeldingen gaat renderen. Tomcat: Voert een set van databank queries uit op een Tomcat server. Deze queries vragen een aantal webpagina’s op en controleert de inhoud ervan. Tradebeans: Deze voert de DayTrader [28] benchmark uit van Apache via Java Beans naar een Geronimo [29] back-end. In het geheugen zit de H2 databank. Tradesoap: Deze voert opnieuw de DayTrader benchmark uit maar nu via Simple Object Access Protocol (SOAP) naar een Geronimo back-end. In het geheugen zit opnieuw de H2 databank. Xalan: Dit is de laatste applicatie en deze zet een Extensible Markup Language (XML) bestand om naar een HyperText Markup Language (HTML) pagina.

3.4 Benchmarking

26

De DaCapo benchmark suite is zo opgebouwd dat er een keuze gemaakt moet worden welk van bovenstaande applicaties uitgevoerd zal worden. Eenmaal uitgevoerd is de output van de benchmark altijd een uitvoeringstijd. Hoe lager de uitvoeringstijd van de applicatie, hoe beter de server/computer/virtuele instantie is. Verschillende van bovenstaande applicaties werden gebruikt. Hoofdzakelijk werd er gebruik gemaakt van de Luindex om het prestatiebeeld te bepalen van de micro instantie. Daarnaast werden de H2 en de Tradesoap applicatie gebruikt om de zwaardere instanties, de instanties die meer ECU eenheden aan prestatie geven, te testen. Dit zal allemaal duidelijk worden in het volgende hoofdstuk waar de resultaten besproken worden van de verschillende experimenten die werden uitgevoerd.

3.4.2

UnixBench benchmark

De DaCapo benchmark suite is zoals reeds aangegeven een volledig Java gebaseerd benchmark suite. Om de resultaten van deze benchmark te kunnen verifiëren werd er ook gebruik gemaakt van de micro-benchmark UnixBench. Deze micro-benchmark werd geschreven in de programmeertaal C en is de verderzetting van de originele Byte Unix benchmark suite. Deze is ge¨ updatet en aangepast over de jaren heen door verschillende mensen. Het begon allemaal in 1983 aan de Monash universiteit in Australië. Het was destijds een simpele applicatie dat op zijn beurt later werd aangepast door Byte Magazine, Jon Tombs, Ben Smith, Rick Grehan, en Tom Yager. De test maakt het mogelijk om de resultaten van systemen op basis van Unix te gaan vergelijken met een verzameling van gekende resultaten. Die resultaten zijn afkomstig van een SPARCstation 20-61 met een score van 10. Grote updates werden later nog toegevoegd door onder andere David C. Niemi en Ian Smith De benchmark richt zich op verschillende aspecten van een systeem. Het creëren van processen, het testen van de verwerkingscapaciteit van een systeem en andere. De volledige test werkt dus in op een grote hoeveelheid van functionaliteiten maar elk programma op zich werkt enkel in op een specifiek aspect. Dit is met andere woorden zeer onnatuurlijk voor de huidige systemen maar kan een goede indicatie geven van wat een systeem kan en kan zeker gebruikt worden om verschillende machines onderling te vergelijken waardoor het een bruikbare benchmark is voor dit werk. De benchmark bestaat uit volgende delen: Dhrystone: Dhrystone [30] is een benchmark dat oorspronkelijk werd ontwikkeld door Reinhold Weicker in het jaar 1984. Deze wordt gebruikt om de prestatie van een systeem te testen en te vergelijken op basis van een test dat inwerkt op ”string handling”. Deze benchmark wordt sterk be¨ınvloed door zowel de hardware

3.4 Benchmarking

27

als de software. Zowel de compiler, link-editor en de verschillende programmeercode optimalisaties hebben een invloed op de uiteindelijke resultaten maar ook hardware aspecten zoals cache geheugen en wachttijden. Whetstone: Whetstone [31] voorziet in een mengeling van verschillende gehele getallen en drijvende komma operaties. Het heeft hierdoor het karakter van een wetenschappelijke applicatie. Een verzameling van verschillende C functies zoals sin, cos, log, ... worden gebruikt maar ook toegangen tot verschillende rijen, conditionele takken en het oproepen van procedures komen aanbod. Execl Throughput: Deze simpele test meet het aantal execl oproepen die per seconde kunnen worden uitgevoerd. Execl is onderdeel van de exec verzameling van functies. Deze zorgen ervoor dat het huidig procesbeeld volledig wordt vervangen door het programma dat als argument werd meegegeven aan de functie. Een nieuw proces wordt dus niet aangemaakt waardoor het procesidentificatienummer blijft behouden maar waardoor zaken zoals de data en de stapel wel gereset worden. Belangrijk bij het gebruik van deze functies is dat geopende bestanden, open blijven. File Copy: Deze meet de snelheid waarmee data van het ene bestand naar een ander bestand verzet kan worden gebruikmakende van verschillende buffergroottes. Gedurende een vastgestelde tijdsperiode zal er gemeten worden hoeveel data gelezen, geschreven of gekopieerd kan worden. Pipe Throughput: Een “pipe” is een typisch Unix vorm van communicatie tussen verschillende processen. Door het opmeten hoeveel keer een proces 512 bytes aan data kan schrijven naar een “pipe” en terug kan lezen van deze “pipe” wordt er een score bepaald. Pipe-based Context Switching: Dit programma meet het aantal keer dat twee verschillende processen een geheel getallen, dat elke keer verhoogt wordt door elk proces, naar elkaar kan gecommuniceerd worden via een “pipe”. Het test programma maakt een kind proces aan dat dan de bi-directionele “pipe” communicatie verzorgt. Process Creation: Deze test verzorgt een meting van hoeveel keer een proces een kindproces kan forken en reapen dat op zijn beurt direct stopt. Het genereren van een proces zorgt er telkens voor dat er een proces controle block wordt aangemaakt en het zorgt voor het alloceren van een hoeveelheid geheugen. Shell Scripts: De shell script test meet het aantal keer per minuut een proces een set van een aantal gelijktijdige kopieën van een bepaald shell script kan uitvoeren. Dit script is een verzameling van transformaties die uitgevoerd worden op een data bestand.

3.4 Benchmarking

28

System Call Overhead: Deze test schat een kost om de kernel aan te spreken van het besturingssysteem. Het meet dus de overhead van een systeemoproep. Het programma voert telkens het getpid commando uit wat op zijn beurt de identificatie van een proces teruggeeft. De kost wordt geschat op basis van de uitvoeringstijd.

Bij gebruik van deze benchmark is er geen mogelijkheid om te kiezen welke applicatie van de suite gestart wordt. Als de benchmark gestart wordt, dan worden de verschillende applicaties na elkaar doorlopen en uitgevoerd. Op basis van alle resultaten wordt er een eindscore bepaald van het geteste systeem. Indien de benchmark ziet dat het systeem meerdere processorkernen bevat zal de benchmark eerst uitgevoerd worden met één proces per applicatie, zoals bij elke run. Erna wordt de benchmark opnieuw uitgevoerd en ditmaal met X processen waarbij X dan overeenstemt met het aantal processorkernen die het systeem op dat moment bezit. De eindscore wordt uiteindelijk in een html bestand omgezet waarbij er een overzicht gegeven wordt van de individuele scores per applicatie samen met een totaal score van het systeem. In Figuur 3.2 is zo een overzicht weergegeven.

3.4 Benchmarking

29

Figuur 3.2: Overzicht van de weergave van de resultaten bepaald door de Unixbench benchmark.

3.5 Scripts

3.5

30

Scripts

Om de benchmarks op een automatische manier te kunnen uitvoeren, zonder enige tussenkomst, werden er scripts geschreven. Een script kan gezien worden als een opeenvolging van code die een taak of procedure voorstelt. Het zijn deze scripts die via de SSH implementatie van het Java raamwerk worden aangeroepen en die ervoor zorgen dat de juiste benchmarks met de juiste parameters worden uitgevoerd. Zo een script maakt het ook mogelijk om reeds een eerste selectie te maken uit de verkregen benchmark data en deze data om te zetten naar een bruikbaar formaat. Dit script, geschreven in de Python taal, zal verder besproken worden. Eerst volgt de beschrijving van het Linux Shell script.

3.5.1

Linux Shell script

Bij het starten van eender welk eigen geschreven script zal er steeds gekeken worden of er nog oude data op de te testen machine beschikbaar is en deze zal verwijderd worden. In totaal moeten er vier verschillende bestanden verwijdert worden. Het logbestand test.log dat alle benchmark informatie zal bevatten en cpu.log waarin de hardware-informatie zal weggeschreven worden samen met de bestanden data.csv en cpu info.txt die de uiteindelijke bruikbare data bevatten. Het volgende onderdeel van zo’n script bestaat erin om de hardware-informatie te verzamelen in een apart bestand. Het Linux commando cat print het opgevraagde bestand, hier cpuinfo af in de Shell zelf. Om dit te vermijden wordt de output opgevangen in een bestand, cpu.log. Het cpuinfo bestand is een bestand dat het Linux gebaseerde systeem gebruikt om het type van processor te gaan identificeren. Op dit logbestand zal later nog een bewerking uitgevoerd worden want deze bevat te veel informatie. c a t / proc / c p u i n f o >> cpu . l o g 2>&1 Het volgende aspect van het script bestaat erin om de benchmark zelf uit te voeren. Via de volgende lijn code, dat zichtbaar is hieronder worden verschillende zaken uitgevoerd. Zo zal er een uitvoeringstijd bijgehouden worden van de volledige benchmark terwijl de Java virtuele machine de benchmark aan het uitvoeren is. In dit geval is dit de H2 applicatie. De 200 staat voor het aantal keer de benchmark zal uitgevoerd worden en opnieuw wordt de data opgevangen in een log bestand, hier test.log. / u s r / b in / time −f ” s y s t e e m t i j d %e ” j a v a −j a r dacapo −9.12−bach . j a r −n ” 200 ” h2 >> t e s t . l o g 2>&1 Om alle verzamelde data direct in de cloud te verwerken tot een bruikbaarder formaat werd een Python script geschreven. De logbestanden bevatten immers veel te veel infor-

3.5 Scripts

31

matie die niet relevant is voor het onderzoek. Het is tenslotte enkel de uitvoeringstijd van de benchmark die van belang is. Hoe het script werkt en wat het doet wordt in volgende sectie beschreven.

3.5.2

Python script

Python wordt gebruikt als scripttaal voor het schrijven van een script dat het mogelijk maakt om de logbestanden met de benchmarkdata en processorinformatie reeds te verwerken in de cloud tot een bruikbaarder formaat. Van al de data in de benchmark logbestanden zijn immers enkel de uitvoeringstijden van de benchmark belangrijk. Deze worden dan ook uitgefilterd uit dit bestand waarbij de eerste 20 uitvoeringstijden weggelaten worden omdat deze dienen als opwarming voor de Java virtuele machine. De uitgefilterde waarden worden in een een Comma-Separated Values (csv) bestand geplaatst. De volledige tijd die besteed werd aan het uitvoeren van de benchmark wordt ook nog uit dit logbestand gefilterd en weggeschreven naar hetzelfde Comma-Separated Values (csv) bestand. Voor de processorinformatie worden het model uit het logbestand gefilterd samen met de snelheid en de cachegrootte. Deze laatste waarde zal uiteindelijk nergens gebruikt worden in deze scriptie.

RESULTATEN PRESTATIE-ANALYSE

32

Hoofdstuk 4 Resultaten prestatie-analyse “There is no such thing as failure. There are only results.” Tony Robbins

4.1

Inleiding

In dit hoofdstuk worden de resultaten besproken van de verschillende experimenten die uitgevoerd werden gedurende de onderzoeksperiode. Elk experiment zal apart besproken worden. Het doel is in de eerste plaats om de basisprestatie te bepalen van een aantal verschillende instanties. Deze instanties zijn de t1 micro, m1 small en m1 large. De t1 micro instantie werd gekozen omdat deze een apart gegeven is. Dit zal verder duidelijk worden wanneer de resultaten van deze instantie besproken worden. Dan werd de keuze gemaakt voor de m1 small omdat Amazon deze instantie aanbiedt als de standaard instantie en omdat hedendaagse servers bestaan uit multi-core processoren, processors met meerdere rekenkernen, wordt de m1 large instantie ook onderzocht. Op basis van de gevonden basisprestatie zal er dan gekeken worden of er prestatievariaties optreden binnen eenzelfde type. Procentuele verschillen zullen opgesteld kunnen worden. Op basis van deze kan dan beslist worden of deze relevant zijn en of er op zoek gegaan moet worden naar de oorzaak van deze variaties. In een laatste experiment zal er getracht worden om de Amazon Elastic Compute Unit of ECU eenheid te onderzoeken. Met hardware die dateert uit de periode die Amazon vermeld in de documentatie van deze eenheid en die beschikbaar is in het serverpark van ELIS, de vakgroep voor Elektronica en Informatiesystemen, zal er een poging ondernomen worden om de beschrijving van de Amazon ECU eenheid te verifiëren.

4.2 Amazon micro instantie

4.2

33

Amazon micro instantie

Zoals reeds vermeld in Hoofdstuk 2 is de prestatie geleverd door de micro instantie variabel. De specificaties van de instantie zijn opgenomen in Tabel 4.1. Deze instantie is de goedkoopste instantie die aangeboden wordt door Amazon. Wanneer een gebruiker van de Amazon cloud een account aanmaakt beschikt deze een jaar lang over een maandelijkse gratis hoeveelheid aan micro instantie uren. In totaal is er 750 uur beschikbaar voor een Linuxserver micro-instantie en evenveel voor een Windowsserver micro-instantie. Dit betekent dat er gedurende 12 maanden een gratis micro-instantie van elk platform gebruikt kan worden. Dit is ideaal voor nieuwe gebruikers die ervaring willen opdoen met de cloud en de instanties binnen deze cloud. Onderdeel Processor Virtuele processorkern Geheugen Platform

Beschrijving Tot twee ECU eenheden aan rekenkracht (korte periodes) 1 615 MiB 32-bit of 64bit

Tabel 4.1: Specificaties van de Amazon Micro instantie

Het voornaamste doel van deze micro-instantie is een instantie te voorzien die de mogelijkheid bezit tot het gebruiken van extra processorcyclussen wanneer deze nodig zouden zijn. De prestatie op zo’n moment kan oplopen tot wel twee ECU eenheden maar dit voor een zeer korte periode. Het gebruik van de processor mag maar zelden aantikken tot 100 procent. Dit is immers het moment waarop de extra cyclussen aan rekenkracht voorzien zullen worden. Figuur 4.1 bevestigt Amazon’s beweringen rond de micro-instantie. De figuur is een momentopname. De Luindex benchmark van de DaCapo suite werd gedurende een bepaalde periode uitgevoerd en van die resultaten werd er een selectie afgebeeld. Op de x-as staat de tijd uitgedrukt in milliseconden en op de y-as de uitvoeringstijd van de benchmark in milliseconden. Hoe kleiner de uitvoeringstijd, hoe beter de micro instantie presteerde op dat moment. De figuur toont duidelijk aan dat er extra processorcyclussen aangeleverd worden in korte periodes. De uitvoeringstijden zakken immers in die korte periodes, wat dus een beter prestatie oplevert en dus bevestigd dat er meer rekenkracht was op dat moment. Belangrijk om op te merken is dat de Luindex geen processorintensieve benchmark is. Indien de H2 applicatie van de DaCapo benchmark suite gebruikt, een rekenintensieve applicatie, wordt het prestatiebeeld uit Figuur 4.2 verkregen. In Figuur 4.2 wordt er aangetoond dat de aangeleverde hoeveelheid extra processorcy-

4.2 Amazon micro instantie

34

Figuur 4.1: Selectief prestatiebeeld van een Amazon Micro instantie

clussen duidelijk niet constant is en dat de periodes van extra cyclussen ook niet even groot zijn. Dit prestatiebeeld toont aan dat enkel een beperkte set van applicaties echt voordeel kunnen halen bij gebruik van dit soort instantie. De gebruikte benchmark applicatie, H2 van de DaCapo suite, is veel rekenintensiever waardoor het gemiddelde verbruik aan rekenkracht tegen de 100 procent aanleunt. Zoals reeds aangehaald zijn het enkel applicaties die zeer af en toe een piek hebben in hun verbruik aan processorrekenkracht die voordeel kunnen halen uit de korte periode aan extra cyclussen. Omdat het prestatiebeeld van de micro instantie zoveel variatie bevat veroorzaakt door de variabele prestaties die reeds beloofd worden door Amazon, zal er hier niet verder gezocht worden naar prestatievariatie en de oorzaken van dit gegeven. Dit is immers zo goed als onmogelijk doordat de periode van extra processorcyclussen random aangeleverd wordt gedurende de tijd en indien er gedurende een bepaalde periode meer nood is aan het extra gegeven zal de periode korter worden en zal de tijd tussen twee periodes van extra cyclussen ook gaan variëren. De hoeveelheid aan extra processorcyclussen op zijn beurt is ook nog eens bepaald door de belasting van de hardware zelf. Deze opmerkingen zijn allemaal zichtbaar in Figuur 4.2. Op deze figuur is er ook een moment waarop de benchmark zich zeer slecht gedraagt. De uitvoeringstijd stijgt bijna met 100 procent voor een zeer korte periode. De oorzaak van dit gegeven is niet duidelijk. Bij het bepalen van de prestatie van een M1 Small instantie is er ook zo een verschijnsel. Er zal daar even stil gestaan worden bij de mogelijke oorzaken van dit gegeven.

4.3 Basisprestatie Amazon small instantie

35

Figuur 4.2: Prestatiebeeld van een Amazon micro instantie

4.3

Basisprestatie Amazon small instantie

De Amazon m1 small instantie is de standaard instantie die aangeboden wordt door Amazon. Indien de micro-instantie die toch wel een speciaal gegeven is binnen de cloud niet in aanmerking wordt genomen is dit de goedkoopste instantie met constante prestatie. De specificaties van deze worden opgenomen in Tabel 4.2. Onderdeel Processor Virtuele processorkern Geheugen Platform I/O prestatie

Beschrijving 1 ECU eenheid 1 1.7 GiB 32-bit of 64bit gematigd

Tabel 4.2: Specificaties van de Amazon m1 small instantie

In een eerste experiment was het doel om de basisprestatie te bepalen van de m1 small instantie. Om de resultaten die opgenomen zijn in Figuren 4.4, 4.5 en 4.6 goed te kunnen begrijpen moet dit experiment eerst grondig besproken worden. In de periode van oktober 2012 tot december 2012 werden verscheidene instanties aangevraagd in de Amazon cloud. In totaal werden er meer dan 300 instanties gealloceerd met allemaal dezelfde AMI. Op deze manier werd telkens dezelfde benchmark uitgevoerd met exact dezelfde parameters. De benchmark die gebruikt werd in dit experiment is de


36

DaCapo H2. De instanties werden telkens per 10 aangevraagd en dit telkens in de Ireland regio, de enigste regio binnen Europa. Via de Amazon API die aangesproken wordt met het Java raamwerk is het niet mogelijk om een zone te bepalen waar de instanties gestart moeten worden. Dit is een beperking die volledig te wijten is aan Amazon. Op deze manier werden de machines compleet random aangevraagd. De resultaten zullen net zoals het experiment per 10 worden gevisualiseerd. Per aangevraagde instantie zal er een boxplot voorzien worden die de resultaten van die specifieke machine zullen visualiseren. Zo een boxplot is terug te vinden in Figuur 4.3. De grafieken van Figuren 4.4, 4.5 en 4.6 bestaan telkens uit 10 zo’n boxplots of ook wel gekend als doosdiagrammen. Elke boxplot visualiseert de resultaten van de uitgevoerde benchmark op die bepaalde instantie. De resultaten zijn de verschillende uitvoeringstijden van de gebruikte benchmark. Indien de boxplot van Figuur 4.3 doorlopen wordt van onder naar boven dan begint dit met het minimum. De afstand tussen het minimum en het 10 percentiel wordt aangegeven met de onderste verticale streep. Het gedeelte tussen het 10 percentiel en het 50 percentiel wordt aangegeven met de gele kleur. Dit is het onderste deel van het vierkantje. Het bovenste gedeelte van het vierkantje of het groene gedeelte is de afstand tussen het 50 percentiel en het 90 percentiel. Daarbovenop staat er terug een verticale streep die de afstand aangeeft tussen het 90 percentiel en het maximum.

Figuur 4.3: Boxplot visualisatie van benchmarkresultaten.

Concreet wil dit zeggen dat de 10 procent laagste waarden van alle waarden onder het vierkantje liggen begrenst door het minimum en dat de 10 procent grootste waarden boven het vierkantje liggen begrenst door het maximum. Het vierkantje zelf bevat dus 80 procent


37

van alle waarden, hier uitvoeringstijden van de benchmark opgedeeld in twee delen die telkens 40 procent voorstellen. De scheidingslijn tussen beide is het 50 percentiel. Dit is ook de mediaan. Door deze manier van voorstellen kunnen de prestaties van verschillende instanties of virtuele machines op een grafische manier vergeleken worden.


Figuur 4.4: Boxplot grafiek met 10 prestatieresultaten van Amazon M1 small instanties.

38


39

Figuur 4.5: Boxplot grafiek met 10 prestatieresultaten van Amazon M1 small instanties met een grote uitschieter.


40

Figuur 4.6: Boxplot grafiek met 10 prestatieresultaten van Amazon M1 small instanties zoals een gebruiker dit zou verwachten.


41

In Figuur 4.4 worden de resultaten van zo een bepaalde test grafisch weergegeven. Bij het bekijken van deze resultaten is het direct duidelijk dat de geleverde prestaties van de verschillende virtuele machines gedurende de periode september-december 2012 niet constant waren. Een gebruiker van de Amazon cloud diensten zou eerder een resultaat zoals Figuur 4.6 verwachten waarbij elke machine een gelijkaardig prestatiebeeld heeft. Dit was inderdaad mogelijk maar zeer uitzonderlijk. Het was zelfs zo erg dat er uitschieters bij zaten van machines die een afwijking van 50 procent en meer hadden zoals machine acht, weergegeven in Figuur 4.5. De vraag die nu natuurlijk gesteld moet worden is hoe bepaald kan worden dat die machine een afwijking heeft van 50 procent en ten opzichte van wat is die 50 procent dan. Om te antwoorden op die vragen werd een cumulatieve distributie gemaakt van de uitvoeringstijden van een verzameling van benchmarkresultaten.

Figuur 4.7: Cumulatieve distributie van de verzameling van resultaten van de DaCapo H2 benchmark uitgevoerd op de Amazon M1 Small instantie.

In Figuur 4.7 is deze cumulatieve distributie terug te vinden. Deze werd gemaakt met 30.000 resultaten van de DaCapo H2 benchmark. Op de figuur is zichtbaar dat 50 procent van de resultaten een uitvoeringstijd van minder dan 11 seconden bezit en dat ongeveer 30 procent een uitvoeringstijd van 10 seconden of minder bezit. Samen met vele plots zoals

4.4 Prestatiebeeld over een volledige dag

42

Figuren 4.4, 4.5 en 4.6 kan er besloten worden dat de 10 seconden grens met 10 procent afwijking de grens is die goed en slecht bepaalt. Dit wil zeggen dat als er 10 procent afwijking getolereerd wordt, de grens op 11 seconden komt te liggen waardoor 50 procent van de machines die werden gealloceerd gedurende de periode september-december 2012 goed was. Dit betekent ook dat 50 procent slecht was en zoals duidelijk is op de cumulatieve distributie, Figuur 4.7, kunnen er enorme uitschieters zitten in deze slechte machine. Zeker als er gekeken wordt naar de 10 procent slechtste resultaten. Hiermee kan verklaard worden hoe de afwijking van 50 procent en meer van machine acht uit Figuur 4.5 bepaald werd. Het is duidelijk dat er wel degelijk variatie in prestatie binnen een bepaald instantietype bestaat binnen de Amazon cloud en dat dit ook geregeld voorkomt. Het is zelfs zo dat als er variatie in prestatie optreedt, deze variatie enorme proporties kan aannemen met afwijkingen in het slechtste geval van 50 procent en meer. Dit stemt overeen met de resultaten die recent werden gepubliceerd in [22, 23]. In deze fase van het onderzoek werd er niet gekeken naar de onderliggende hardware platformen die Amazon gebruikte om de small instanties te virtualiseren en die volgens de papers de oorzaken zijn van deze afwijkingen. De hardware heterogeniteit kan echter het verschil verklaren tussen de 2 hellende vlakken in de cumulatieve distributie, maar niet de uitschieters.

4.4

Prestatiebeeld over een volledige dag

Voorgaand experiment is een momentopname van de prestatie van een Amazon m1 small instantie. Daar de resultaten afhankelijk kunnen zijn van het tijdstip waarop de instantie werd aangevraagd en de benchmark werd uitgevoerd werd er een nieuw experiment opgesteld. In dit nieuw experiment wordt de DaCapo H2 benchmark gedurende een periode van 24 uur uitgevoerd op de aangevraagde m1 small instanties. Het resultaat van zo een 24 uur durende benchmark periode is terug te vinden in Figuur 4.8. Op de x-as van deze figuur wordt de tijd weergegeven en de y-as bevat de uitvoeringstijd in milliseconden. Met de kennis die reeds werd verzameld in het vorige experiment, kan gezien worden dat deze instantie een goede instantie was. De uitvoeringstijden van de gebruikte benchmark liggen immers rond de 10 seconden. De resultaten weergegeven in deze figuur tonen aan dat er weinig tot geen variatie is gedurende de dag. Wel is er een uitschieter zichtbaar op de figuur tussen 13 uur en 14 uur. Deze duurt een vijftal minuten. De oorzaak hiervan is onduidelijk maar indien er gekeken wordt naar Figuur 4.9 wat de grafische weergave is van een andere instantie die gealloceerd werd op het zelfde moment als de instantie van Figuur 4.8 dan is deze uitschieter ook daar zichtbaar. Deze is zelfs zichtbaar in alle 10 de instanties die op hetzelfde moment gealloceerd werden voor dit experiment. De kans dat

4.5 Homogeen datacenter

43

de oorzaak veroorzaakt werd door Amazon is groot. Naar de oorzaak zelf is het natuurlijk gissen. Updates binnen het datacenter kunnen hier aan de basis liggen of live migraties van de verschillende machines of nog andere niet gekende mogelijke oorzaken.

Figuur 4.8: Prestatiebeeld gedurende 24 uur van een Amazon M1 Small instantie

Figuur 4.9: Tweede prestatiebeeld gedurende 24 uur van een Amazon M1 Small instantie

4.5

Homogeen datacenter

In de papers geschreven door Zhonghong et al. [22] en Farley et al. [23] werd het duidelijk dat de grootste oorzaak van de prestatievariatie, die reeds gevisualiseerd werd in het eerste beschreven experiment, veroorzaakt werd door de onderliggende gebruikte hardware in de cloud. Om dit te verifiëren werd er een nieuw experiment opgezet die opnieuw de Amazon m1 small instanties ging onderwerpen aan benchmarks. De aanleiding van dit nieuw experiment bestaat erin dat er in de voorgaande experimenten geen data bijgehouden werd


44

met betrekking tot de onderliggende hardware. Op deze manier is het nu mogelijk om de invloed te onderzoeken van de hardware en is het ook mogelijk om te kijken binnen een bepaald hardwareplatform, binnen eenzelfde instantietype, of er nog prestatievariatie optreed. Voor dit experiment zijn er een aantal nieuwe zaken die besproken moeten worden. Zo is er deze keer geen gebruik gemaakt van één DaCapo benchmark applicatie maar twee en werd de UnixBench benchmark toegevoegd. De reden waarom er twee DaCapo applicaties gebruikt worden ligt in de aard van de applicaties. Naast de H2 applicatie werd nu ook de Tradesoap toegevoegd omdat deze geheugenintensiever is en een langere uitvoeringstijd heeft. De volgorde van uitvoeren is de volgende. Eerst wordt de H2 applicatie een aantal keren uitgevoerd waarna de UnixBench doorlopen wordt. Om te eindigen volgt de Tradesoap applicatie die op zijn beurt een aantal keren wordt doorlopen. De reden om een tweede benchmark toe te voegen bestaat erin om nadien te kunnen bepalen of de verkregen resultaten niet onderhevig zijn aan de gebruikte benchmark. Figuur 4.10 geeft de UnixBench benchmark resultaten terug van 30 m1 small instanties. Opvallend hierbij is dat deze resultaten verrassend gelijk zijn, op twee machines na. Deze twee machines hebben een hogere score waardoor ze dus een betere prestatie leveren. In totaal is er 15 procent afwijking tussen de laagste score en de hoogste score. Dit is vrij beperkt en de oorzaak hiervan is zoals reeds aangegeven ontstaan door de twee afwijkende machines.

Figuur 4.10: UnixBench benchmark scores voor 30 m1 small instanties.

In Figuur 4.11 worden deze twee machine weggefilterd. In dit geval worden enkel machines van het hardware platform Intel Xeon E5-2650 overgehouden. De procentuele afwijking tussen de scores bedraagt nu maar vier procent meer wat eigenlijk te verwaarlozen is, zeker als de resultaten die reeds besproken werden bekeken worden. De resultaten


45

van dit nieuw experiment zijn verbluffend en spreken de oude resultaten compleet tegen. Om die reden is het belangrijk om het meest voorkomende hardware platform, Intel Xeon E5-2650, eens beter te bekijken. Het wordt al snel duidelijk dat dit een vrij recente en nieuwe processor. Deze werd door Intel ge¨ıntroduceerd in het eerste kwartaal van 2012. Hierdoor kan er met enige zekerheid gesteld worden, samen met resultaten van experimenten die nog zullen volgen, dat Amazon hardware-upgrades aan het doorvoeren was. Deze hardware-upgrades zorgen ervoor dat de geleverde prestaties van de instanties veel stabieler zijn en dat de prestatievariatie herleid wordt tot een minimum. Dat er wel degelijk een hardware-upgrade doorgevoerd wordt zal ook nog duidelijk worden in het Hoofdstuk 6, waar het nieuwe Intel Xeon E5-2650 platform zichtbaar zal worden binnen de m1 large instantietype ook. Omdat de verkregen resultaten benchmark afhankelijk kunnen zijn volgen hier nog de resultaten van de H2 DaCapo benchmark die ook op deze instanties werd uitgevoerd. In Figuur 4.12 is de gemiddelde uitvoeringstijd uitgezet voor de 30 machines. Het patroon is hier veel grilliger maar de uiteindelijke afwijking tussen de laagste en de hoogste gemiddelde uitvoeringstijd is 13 procent. Indien opnieuw enkel het Intel Xeon E5-2650 platform bekeken wordt, 28 machines, wordt Figuur 4.13 verkregen. De procentuele afwijking tussen de laagste en de hoogste score bedraagt nu 12 procent. Dit is opmerkelijk want bij de UnixBench benchmark van Figuur 4.11 was dit maar vier procent meer. Hierbij is het duidelijk dat er enige voorzichtigheid moet ingebouwd worden als er resultaten besproken worden want deze zijn wel degelijk, zij het in beperkte mate, benchmark afhankelijk. Om zeker te zijn dat de resultaten die verkregen werden voor de m1 small instantie in dit nieuwe experiment correct zijn werd het nog eens over gedaan met 10 nieuwe m1 small instanties. Het resultaat, voor de UnixBench benchmark, is zichtbaar in Figuur 4.14. De procentuele afwijking tussen de laagste score en de hoogste score bedraagt één procent en het verkregen hardware platform was enkel het Intel Xeon E5-2650 platform.


46

Figuur 4.11: UnixBench benchmark scores van het Intel Xeon E5-2650 platform.

Figuur 4.12: Gemiddelde uitvoeringstijd van de DaCapo H2 benchmark uitgevoerd op 30 machines.

4.6 Amazon large instantie

47

Figuur 4.13: Gemiddelde uitvoeringstijd van de DaCapo H2 benchmark voor de 28 machines van het Intel Xeon E5-2650 platform.

Figuur 4.14: UnixBench benchmark scores voor 10 m1 small instanties.

4.6

Amazon large instantie

Zoals reeds aangegeven werd er bewust gekozen om de prestatie-analyse ook uit te voeren op een multi-core instantie in de cloud. Daar zo een instantie dichter aanleunt bij de werkelijkheid, waar hedendaagse servers voorzien zijn van meerdere processorkernen, is deze keuze te verantwoorden. De specificaties van dit type zijn opgenomen in Tabel 4.3.


Onderdeel Processor Virtuele processorkern Geheugen Platform I/O prestatie EBS-optimalisatie

48

Beschrijving 4 ECU eenheden 2 7.5 GiB 64bit gematigd 500 Mbps

Tabel 4.3: Specificaties van de Amazon m1 large instantie

De gebruikte werkwijze bij dit experiment is net dezelfde als deze die toegepast werd tijdens het homogeen datacenter experiment. Er werden drie benchmarks uitgevoerd waarvan twee uit de DaCapo suite komen, de H2 en Tradesoap, en de derde is de UnixBench benchmark. Zoals reeds aangegeven bij de beschrijving van de UnixBench benchmark zal deze benchmark bij dit experiment automatisch tweemaal uitgevoerd worden. De eerste keer met één proces en de tweede keer met evenveel processen als er processorkernen aanwezig zijn. In dit geval zijn er twee processorkernen aanwezig dus zal de benchmark uitgevoerd worden met twee processen. In totaal werden er 30 instanties aangevraagd en de UnixBench benchmark score voor deze 30 machines is terug te vinden in Figuur 4.15.

Figuur 4.15: UnixBench benchmark score voor 30 Amazon m1 large instanties

Op deze Figuur 4.15 zijn er twee grafieken zichtbaar die de scores aangeven van de instanties. De bovenste grafiek is de score indien er twee processen werden gebruikt en de onderste grafiek geeft de score aan indien er maar één proces werd gebruikt. Het is een duidelijk gegeven dat prestatievariatie iets is dat ook optreedt bij duurdere


49

instantietypes. Het procentuele verschil tussen de laagste en de hoogste score bij gebruik van één proces is 21 procent en bij gebruik van twee processen is dit zelfs 33 procent.

Figuur 4.16: UnixBench benchmark score voor negen machines van het Intel Xeon 5507 platform.

Indien er een bepaald hardware platform uitgefilterd wordt uit Figuur 4.15, wordt Figuur 4.16 verkregen. Deze grafiek geeft de UnixBench benchmark score voor negen machines weer van het Intel Xeon 5507 platform. Indien er gekeken wordt naar de scores in Figuur 4.15 en vergeleken wordt met de uitgefilterde scores in Figuur 4.16 dan is het duidelijk dat dit het zwakste hardware platform is dat verkregen werd gedurende dit experiment. Zo is nog maar eens duidelijk aangetoond hoe onderliggende hardware invloed uitoefent op de prestaties van de aangeboden instanties. Indien de laagste score vergeleken wordt met de hoogste score binnen dit Intel Xeon 5507 platform dan is er een procentueel verschil zichtbaar van 3 procent. Dit is verwaarloosbaar en kan veroorzaakt zijn door de benchmark zelf of door de invloed van andere instanties die op dat moment op dat bepaald platform actief zijn. Om nogmaals aan te tonen dat het procentuele verschil ook be¨ınvloed wordt door de benchmark zelf, wordt in Figuur 4.17 de gemiddelde uitvoeringstijd van de DaCapo Tradesoap benchmark uitgezet voor dezelfde 30 machines van Figuur 4.15. Het procentuele verschil hier tussen de hoogste en de laagste uitvoeringstijd bedraagt 38 procent. Indien hetzelfde Intel Xeon 5507 platform uitgefilterd wordt, wordt Figuur 4.18 verkregen. Het procentuele verschil hier bedraagt 7 procent.


50

Figuur 4.17: Gemiddelde uitvoeringstijd van de DaCapo Tradesoap benchmark voor 30 Amazon m1 large instanties.

Figuur 4.18: Gemiddelde uitvoeringstijd van de DaCapo Tradesoap benchmark voor negen machines van het Intel Xeon 5507 platform.

4.7 Prestatievariatie oorzaken

4.7

51

Prestatievariatie oorzaken

Door verschillende experimenten uit te voeren werd duidelijk dat prestatievariatie een algemeen feit is dat zichtbaar is bij meerdere instantietypes. De resultaten van het laatste experiment dat uitgevoerd werd met m1 small instanties toont wel aan dat er gewerkt wordt om dit fenomeen te beperken of zelfs volledig weg te werken. De belangrijkste oorzaak van prestatievariatie binnen een bepaald instantietype is de heterogeniteit van de onderliggende hardware. De resultaten van de verschillende experimenten bevestigen dit, samen met de recente gepubliceerde papers. De verschillende uitgevoerde experimenten in dit werk tonen ook aan dat de resultaten benchmark-afhankelijk kunnen zijn. De ene benchmark zal een groter prestatieverschil opleveren dan de andere. Dit wordt veroorzaakt door de aard van de gebruikte benchmark. Het is ook zo dat indien er een bepaald hardwareplatform uit de behaalde resultaten wordt gefilterd er nog steeds enige vorm van prestatievariatie aanwezig is. Dit is vaak klein en verwaarloosbaar. De oorzaak hiervan kan te wijten zijn aan de gebruikte benchmark maar kan evengoed veroorzaakt worden door de invloed van andere instanties die op dat moment actief zijn op die bepaalde hardware. Dit is in de praktijk niet aantoonbaar daar Amazon geen functionaliteit aanbiedt om te controleren hoe zwaar de onderliggende hardware belast wordt of dat er niet gecontroleerd kan worden hoeveel actieve virtuele machines er zijn op een bepaalde server.

4.8

Verificatie van de ECU eenheid

ELIS, de vakgroep voor Elektronica en Informatiesystemen van de Universiteit Gent, bezit een eigen serverpark. In dit serverpark is er een machine beschikbaar met een Dual-Core AMD Opteron(tm) Processor 2212 HE 2.0 Ghz. Deze processor dateert uit 2006, begin 2007. Dit komt ongeveer overeen met de processor die gebruikt werd bij het bepalen van de prestatie van de abstracte ECU eenheid die Amazon gebruikt. Amazon beweert immers volgens de definitie van deze eenheid uit de documentatie dat de prestatie ongeveer overeenkomt met een AMD Opteron processor met een snelheid van 1.0-1.2 Ghz uit 2007. Belangrijk natuurlijk om op te merken is dat er zo geen processor beschikbaar was in die periode en dat de toenmalige processors de mogelijkheid niet hadden om de kloksnelheid te verlagen. Om dit gegeven te controleren zal het prestatie-analyse script dat gebruikt werd in de cloud ook uitgevoerd worden op deze server. De bepaalde gebruikte server uit het ELIS serverpark bevat meerdere processoren maar het is mogelijk om verschillende processorkernen niet te gebruiken om zo een single core processor te simuleren. Dit werd dan natuurlijk ook toegepast zodat de server maar toegang heeft tot één processorkern.

4.8 Verificatie van de ECU eenheid

52

De gemiddelde uitvoeringstijd voor de DaCapo H2 benchmark op deze bepaalde server met instellingen zo dat er maar één processorkern gebruikt wordt is 7150 ms. Deze uitvoeringstijd is natuurlijk voor een processor die werkt aan een kloksnelheid van 2.0 Ghz. Daar deze niet beschikt over de mogelijkheid tot het verlagen van de processorsnelheid wordt er een lineaire berekening gemaakt. Dit is misschien kort door de bocht maar het is enkel om een indicatie aan te geven. Indien de kloksnelheid gedeeld wordt door twee wordt er 1.0 Ghz verkregen en zou de uitvoeringstijd 14300 ms kunnen bedragen (gemiddelde uitvoeringstijd maal twee). Indien de uitvoeringstijd omgerekend wordt naar een processor met een snelheid van 1.2 Ghz wordt een uitvoeringstijd van 11916 ms verkregen. Indien het resultaat verkregen voor een processor met een kloksnelheid van 1.2 Ghz bekeken wordt, een uitvoeringstijd van 11916 ms, en dit wordt vergeleken met de resultaten uit de cloud, Figuur 4.7, dan wordt het duidelijk dat de geleverde prestatie in de cloud door een Amazon m1 small instantie in 70 procent van alle gevallen beter is dan de prestatie geleverd door de processor met een snelheid van 1.2 Ghz.

KOSTSIMULATIE

53

Hoofdstuk 5 Kostsimulatie “Competition is the keen cutting edge of business, always shaving away at costs.” Henry Ford

5.1

Inleiding

Daar gebruikers een vaste prijs betalen voor een bepaalde instantietype wordt er verwacht dat de geleverde prestatie van de gehuurde instantie ook altijd constant is. Niks is minder waar. Door verschillende experimenten die uitgevoerd werden en waarvan de resultaten zich in het vorige hoofdstuk bevinden werd er aangetoond dat prestatievariatie wel degelijk een voorkomend feit is en dat dit zelfs geregeld optreedt. Henry Ford, pionier in de auto-industrie, wist duidelijk al wat belangrijk is in de economie. De enige manier om competitief te zijn is te besparen op kosten. Dit feit was toen al duidelijk en is in de huidige maatschappij nog belangrijker met de heersende economische crisis. Bedrijven hebben veel over om te besparen en dit is dan ook het gegeven van dit hoofdstuk. Het doel bestaat erin om de kosten, indien er gebruik gemaakt wordt van de cloud en er prestatievariatie optreedt binnen deze cloud, zo laag mogelijk te houden en de verkregen prestatie zo hoog mogelijk. Om een antwoord te kunnen formuleren op dit gegeven wordt in dit hoofdstuk een kostsimulator uitgewerkt. Deze kostsimulator zal ervoor zorgen dat, op basis van reeds verzamelde data, dynamische kostbesparingsstrategieën ontwikkeld kunnen worden.

5.2 Cumulatieve distributie

5.2

54

Cumulatieve distributie

Belangrijk voor een simulator is de data waarmee deze werkt. Opdat het duidelijk zou zijn van welke data de simulator gebruik maakt werd deze nog eens gevisualiseerd in Figuur 5.1. Deze cumulatieve distributie is dezelfde als diegene die werd opgenomen in het vorige hoofdstuk. Deze bevat een 30000 tal waarden, die uitvoeringstijden zijn van de DaCapo H2 benchmark en die verkregen werden met Amazon m1 small instanties.

Figuur 5.1: Cumulatieve distributie van de verzameling van resultaten van de DaCapo H2 benchmark uitgevoerd op de Amazon M1 Small instance.

Deze cumulatieve distributie is de data waarmee de simulator aan de slag zal gaan. Om het random karakter van de cloud te simuleren zal de simulator immers willekeurig punten kiezen op deze distributie en deze punten zullen dan de prestatie bepalen van de instanties die gesimuleerd worden.

5.3

Invalshoek

Op basis van de data waaruit de cumulatieve distributie van Figuur 5.1 werd opgebouwd, werd een kostsimulator in Java geschreven. Het doel van dit gegeven is zoals reeds aangegeven een stuk software te hebben waarmee dynamische kostbesparingsstrategieën ontwikkeld kunnen worden.

5.3 Invalshoek

55

De software is op te delen in twee delen. Er is het basis deel dat bestaat uit een reeks input parameters waarmee zowel de optimale kost als de doe-niks kost bepaald worden en er is het tweede deel dat bestaat uit de ontwikkelde dynamische strategieën. De input parameters die nodig zijn om een simulatie te maken zijn: de input dataset, de kostprijs per uur van een bepaalde Amazon instance (hier prijs van de m1 small instantie), een hoeveelheid instanties, een werklast uitgedrukt in uren, een opstart en afsluit kost die procentueel ingegeven wordt en een grens (uitvoeringstijd van de gebruikte benchmark) die goed en slecht bepaalt. Op basis van de hoeveelheid instanties worden evenveel random punten gekozen uit de dataset van de cumulatieve distributie. Dit simuleert het random gedrag waarmee instanties verkregen worden binnen de Amazon cloud. Deze gekozen punten, uitvoeringstijden van de DaCapo H2 benchmark uitgevoerd op de m1 small instantie, bepalen de prestatie van de instantie. Op basis van de opgegeven grens die goed en slecht bepaalt wordt de prestatieafwijking bepaald. Indien het gekozen punt onder de grens ligt is dit een goede instantie en is de grens de gebruikte uitvoeringstijd. Echter indien een punt boven deze grens ligt zal het procentuele verschil met de grens bepaald worden en zal deze de prestatieafwijking bepalen. De werklast die uitgedrukt wordt in uren zal omgezet worden naar een hoeveelheid jobs die uitgevoerd moeten worden. Dit wordt bepaald door de gekozen grens. Deze is immers een uitvoeringstijd van de gebruikte DaCapo H2 benchmark. De totale te verwerken werklast wordt omgezet naar een tijd in minuten. Via de grens wordt bepaald hoeveel benchmarks per minuut kunnen uitgevoerd worden en deze twee getallen bepalen dan de verzameling van jobs die verwerkt moeten worden per instantie. Indien er prestatievariatie optreedt bij een bepaalde instantie zal deze via deze manier van werken minder jobs kunnen verwerken gedurende een volledig uur. Dit wordt dan berekend aan de hand van de bepaalde procentuele afwijking ten opzichte van de opgegeven grens. Met het ontwikkelen van de dynamische kostbesparingsstrategieën zal getracht worden deze prestatieafwijking te beperken. In die zin dat er een poging ondernomen word om de prestatie te verhogen en de globale kost te doen dalen. Om te kunnen bepalen of een ontwikkelde strategie een verbetering oplevert, wat betekent dat de globale kost gedaald is zal er in de eerste plaats twee verschillende basiskosten bepaalt worden. De optimale kost is de laagst mogelijke globale kost die verkregen kan worden met de set van input parameters. Samen met deze kost wordt ook de doe-niks kost bepaald die de globale kost weergeeft indien er geen kostbesparingsstrategie wordt toegepast. In volgende secties wordt er nog meer uitleg voorzien bij deze kosten.

5.4 De optimale kost

5.4

56

De optimale kost

De optimale kost is de laagst mogelijke globale kost die realiseerbaar is op basis van een gegeven set inputparameters. Bij het bepalen van deze kost wordt er geen rekening gehouden met prestatievariaties. De kost wordt bepaald met het idee dat elke instantie die gesimuleerd wordt een goede instantie is. Hij wordt bepaald door de hoeveelheid machines te vermenigvuldigen met de werklast waar de opstart kost en afsluit kost per machine wordt bijgeteld. Dit getal wordt dan vermenigvuldigd met de kostprijs per uur van de Amazon m1 small instantie.

5.5

De doe-niks kost

De doe-niks kost is zoals reeds aangegeven de globale kost indien er geen kostbesparingsstrategie werd toegepast. Dit is dus de gesimuleerde kost die de klant betaalt, op basis van de set input parameters, indien deze gebruik maakt van Amazon m1 small instanties in de cloud. De prestaties van de instanties worden afgebakend door de willekeurige gekozen punten op de cumulatieve distributie. Gegeven dit punt en de grensparameter die goed en slecht bepaalt (zoals reeds aangegeven is dit een uitvoeringstijd van de DaCapo H2 benchmark) wordt het procentueel verschil opgesteld. Deze wordt in rekening gebracht bij het bepalen van de uiteindelijke globale kost. Per instantie apart wordt de kost opgesteld zodat er rekening gehouden kan worden met de specifieke afwijking per instantie en de globale kost is dan de som van deze afzonderlijke kosten.

5.6

Kostbesparingsstrategie¨ en

Het ontwikkelen van kostbesparingsstrategieën is het tweede deel van de geschreven simulator. In feite worden hier vervangstrategieën ontwikkeld. Dit betekend dat er getracht zal worden om de globale kost te doen dalen door strategisch instanties af te sluiten en nieuwe te gaan opstarten in de hoop dat deze betere prestaties leveren. Op deze manier kan de prestatie verhoogd worden en door de hogere prestatie zal de werklast sneller kunnen afgehandeld worden waardoor de globale kost moet dalen. Twee van de drie vervangstrategieën of kostbesparingsstrategieën werden ontwikkeld, rekening houdende met kennis die reeds verzameld werd in dit werk. Dit zal verduidelijkt worden in de beschrijving van deze. De laatste strategie, de random afsluit strategie, maakt geen gebruik van een soort voorkennis. De reden om zo een strategie te proberen ontwikkelen is dat er niet altijd voorkennis beschikbaar is van de gebruikte instanties. De werking van de verschillende strategieën worden in volgende secties besproken.

5.6 Kostbesparingsstrategieën

5.6.1

57

Vermenigvuldigingsstrategie

De vermenigvuldigingsstrategie maakt gebruik van één extra parameter, een vermenigvuldigingsparameter. Deze parameter zorgt ervoor dat de hoeveelheid instanties die gealloceerd worden overeenstemt met de originele hoeveelheid vermenigvuldigt met deze parameter. Indien er origineel 10 instanties aangevraagd werden en de vermenigvuldigingsfactor bedraagt twee dan zullen er in totaal 20 instanties beschikbaar zijn, de 10 originele en 10 extra instanties. Dit betekent dat de 10 instanties die gebruikt worden om de doe-niks kost te bepalen ook worden gebruikt samen met 10 nieuwe instanties. Deze worden terug gesimuleerd door random punten te nemen op de cumulatieve distributie. Met deze verzameling instanties zal er werklast verwerkt worden. Op deze manier zal er gedurende een klein uur werklast verwerkt worden door tweemaal zoveel instanties als origineel gepland was. Net voordat er één uur verlopen is zullen de beste instanties (diegene met de beste prestatie) behouden worden, net zoveel als er origineel aangevraagd zouden worden. De andere worden afgesloten. De resterende hoeveelheid werklast wordt per machine verwerkt en de kost wordt bepaald rekening houdende met alle factoren zoals extra instanties die aangevraagd werden en mogelijks nog procentuele afwijkingen die kunnen voorkomen in de verzameling van beste instanties. De strategie stopt indien de werklast volledig werd verwerkt.

5.6.2

Goed-versus-slecht-strategie

In de goed-versus-slecht-strategie zal er elk uur opzoek gegaan worden naar de beste en de slechte instanties. Dit op basis van de grensparameter die werd opgegeven. Er worden niet meer instanties gealloceerd dan oorspronkelijk gepland maar de slechte instanties zullen elk uur afgesloten worden. Een hoeveelheid nieuwe instanties die overeenkomt met de hoeveelheid die werd afgesloten zal opnieuw worden aangevraagd. Dit betekent, in deze simulator, dat er opnieuw random een hoeveelheid punten zal gekozen worden op de cumulatieve distributie die dan op hun beurt de uitvoeringstijd en de bij gekoppelde prestatie zullen bepalen van deze nieuwe instanties. Om de kost te bepalen zal elke instantie die opgestart wordt natuurlijk in rekening gebracht worden en zal er bij elke opgestarte instantie rekening gehouden worden met de opstart en afsluit kost. Deze simulatie stopt opnieuw nadat de werklast werd verwerkt.

5.6.3

Random afsluit strategie

De random afsluit strategie is de enige strategie die werd ontwikkeld en getest met de simulator waarbij er geen rekening gehouden wordt met de verzamelde kennis die verkregen werd door de verschillende experimenten en waarvan de resultaten werden opgenomen

5.7 De praktijk

58

in dit werk. De strategie gaat zoals zijn naam al doet vermoeden random te werk. Er kunnen twee verschillende parameters ingesteld worden. De hoeveelheid instanties die random moeten afgesloten worden en de periode van herhalen. Dit betekent bijvoorbeeld als de periode van herhalen ingesteld wordt op twee en het aantal af te sluiten instanties op vijf, dat de strategie elke twee uur random vijf instanties zal afsluiten om dan op zijn beurt vijf nieuwe instanties te alloceren. Dit alloceren werkt terug zoals bij de andere strategieën. Er worden vijf punten random gekozen op de cumulatieve distributie en deze bepalen de nieuwe prestatie van de instantie. De variatie wordt zoals voorheen bepaald door het procentuele verschil te bepalen met de opgegeven grens en deze in rekening te brengen bij het verwerken van de opgegeven werklast. De strategie stopt wanneer elke machine zijn opgegeven werklast heeft uitgevoerd.

5.7

De praktijk

In de praktijk is het natuurlijk niet echt wenselijk om elke instantie te onderwerpen aan een serie van benchmarks vooraleer deze te gebruiken. Dit is natuurlijk wel perfect mogelijk voor een enorm grote werklast waarbij een 20-tal minuten benchmark niks uitmaakt ten opzichte van de te verwerken werklast. Bij een werklast die niet al te groot is zal dit natuurlijk wel gaan doorwegen. Daarom is het ook nodig om eens na te denken wat er in de praktijk zou moeten gebeuren opdat de verkregen prestatie zo hoog mogelijk zou zijn en de kost zo laag mogelijk. Welke strategie er dan aangewezen is in de praktijk indien er geen benchmarking mogelijk is van de aangevraagde instanties is niet direct duidelijk. De oplossing kan echter gevonden worden in een semi-optimale praktische strategie. Start een hoeveelheid instanties en bekijk de prestatie na 1 uur op basis van een gekozen prestatiemaat zoals hoeveelheid verwerkte data, aantal verwerkte jobs, aantal iteraties die een algoritme kon doorlopen,... Bepaal de mediaan. Elke instantie met een prestatie die bijvoorbeeld 10 procent hoger ligt dan deze mediaan wordt aangeduid als slecht. Deze instanties kunnen dan afgesloten worden en evenveel instanties worden opnieuw aangevraagd. Op deze manier is de strategie bestand tegen prestatievariaties op korte termijn maar ook op lange termijn daar deze strategie elk uur herhaald kan worden gedurende de volledige tijd die nodig is om een bepaalde werklast te verwerken.

5.8 Simulatieresultaten

5.8

59

Simulatieresultaten

Het aantal mogelijkheden dat te simuleren is, is eindeloos met de geschreven simulator. Vele verschillende combinaties van parameters zijn mogelijk. Om die reden zullen er twee simulaties beschreven worden in dit werk. De eerste simulatie die beschreven wordt is een simulatie met een kleine werklast en een klein aantal benodigde instanties. De tweede simulatie daarentegen is een simulatie met dubbel zoveel instanties en een grotere werklast. Bij de beschrijving van de resultaten van deze experimenten zal de kracht van de ontwikkelde kostbesparingsstrategieën duidelijk worden. Elk resultaat die hier werd opgenomen berust op 10.000 waarden. Dit betekent dat gegeven de set input parameters, de simulatie 10.000 keer werd uitgevoerd.

5.8.1

Kleine werklast

Figuur 5.2: Resultaten van een simulatie die uitgevoerd werd met de Java simulator.

De resultaten in Figuur 5.2 werden verkregen met volgende input parameters. Er werden in totaal 10 instanties aangevraagd die elk een werklast van 10 uur moeten verwerken. De opstart en afsluitkost is 15 procent van een uur of negen minuten. Dit getal is bepaald op basis van ervaring die verkregen werd gedurende de vele experimenten in de cloud. Het is dus een geloofwaardige waarde. De huidige kostprijs voor een m1 small instantie is $ 0.065 . De grens die goed en slecht bepaald is 10 seconden, wat te verantwoorden is aan de hand van de resultaten uit het vorige hoofdstuk. De extra inputparameter voor de vermenigvuldigingsstrategie is twee en de extra parameters voor de random afsluit strategie zijn drie en twee wat betekent dat er alle twee uren, drie machines random afgesloten


60

zullen worden en in hun plaats komen er dan drie nieuwe instanties die gealloceerd worden op de bekende manier. De optimale kost met deze set input parameters is $ 7.15 . De resultaten weergegeven in Figuur 5.2 spreken voor zich. De vermenigvuldigingsstrategie en de goed-versus-slecht-strategie gedragen zich goed. Indien er gekeken wordt naar de mediaan dan levert de vermenigvuldigingsstrategie en besparing op van 8 procent en de goed-versus-slecht-strategie 6 procent. De random strategie daarentegen gedraagt zich veel minder. Deze strategie is slechter omdat de kost van het opstarten en afsluiten van de instanties in rekening gebracht wordt maar niets extra in de plaats verkregen wordt.

5.8.2

Grote werklast

Om de echte kracht van de strategieën aan te tonen werd in deze tweede simulatie de hoeveelheid machines en werklast verhoogd. Er werden in totaal 20 instanties aangevraagd die elk een werklast van 24 uur moeten verwerken. De opstart en afsluitkost is 15 procent van een uur of negen minuten. Zoals aangegeven bij de vorige simulatie berust deze keuze op opgedane ervaring. De huidige kostprijs voor een m1 small instantie is hier ook $ 0.065. De grens die goed en slecht bepaalt is opnieuw 10 seconden. De extra inputparameter voor de vermenigvuldigingsstrategie is terug twee en de extra parameters voor de random afsluit strategie zijn acht en vijf wat betekent dat er om de vijf uur, acht instanties random afgesloten zullen worden en in hun plaats komen er dan acht nieuwe instanties die gealloceerd worden op de bekende manier. De optimale kost hier bedraagt $ 32.50.

Figuur 5.3: Resultaten van een simulatie die uitgevoerd werd met de Java simulator.


61

De resultaten in Figuur 5.3 zijn indrukwekkend. De vermenigvuldigingsstrategie en de goed-versus-slecht-strategie gedragen zich zo goed dat ze zo goed als in alle gevallen onder de doe-niks kost blijven. Het is zelfs zo dat alle resultaten van beide strategieën niet veel of helemaal niet verschillen van de optimale kost. Indien er naar de mediaan gekeken wordt dan doet de vermenigvuldigingsstrategie het 10 procent beter dan de doe-niks kost en de goed-versus-slecht-strategie 9 procent. Hiermee wordt nog maar eens aangetoond hoe belangrijk het is om een goede kostbesparingsstrategie toe te passen indien er gebruik gemaakt wordt van de cloud en wat zo een strategie kan opleveren. De random strategie gedraagt zich hier ook slecht maar dit ligt in de lijn van de verwachtingen. Het is duidelijk dat indien er voorkennis beschikbaar is, de vermenigvuldigingsstrategie en de goed-versusslecht-strategie de strategieën zijn die toegepast moeten worden met de voorkeur voor de vermenigvuldigingsstrategie die altijd net iets betere resultaten oplevert dan de goedversus-slecht-strategie.

WEB 2.0 CASESTUDIE

62

Hoofdstuk 6 Web 2.0 casestudie “As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications.” Dave Parnas

6.1

Inleiding

Het onderwerpen van de verschillende Amazon instanties aan benchmarks en de behaalde resultaten die opgenomen zijn in dit werk is reeds een mooi gegeven. Met deze resultaten kan er aangetoond worden dat prestatievariatie een feit is waar rekening mee gehouden moet worden bij gebruik van de Amazon cloud. Met de ontwikkelde strategieën uit het vorige hoofdstuk kan er wel voor gezorgd worden dat deze prestatievariatie op lange termijn beperkt wordt. In dit laatste hoofdstuk wordt er nog een stapje verder gegaan. Daar in hoofdstuk drie gewerkt werd met benchmarks zal er in dit hoofdstuk gewerkt worden met een Web 2.0 applicatie. Deze applicatie zal in de cloud geplaatst worden en er zal onderzocht worden of de invloed van de onderliggende hardware op de gebruikte instanties, de oorzaak van de prestatievariatie, ook zichtbaar wordt bij gebruik van zo een webapplicatie. Het doel is om, aan de hand van een vergelijking van antwoordtijden van verschillende webservers, de invloed van de hardware die de oorzaak van prestatievariatie is opnieuw aan te tonen.

6.2

Web 2.0

Web 2.0 [32] is de opvolger van Web 1.0. Het is het web waarin de gebruikers de interactie aan gaan met dit web. De term werd bedacht door Tim O’Reilly, een fervent aanhanger van vrije software. De basisidee van Web 2.0 is dat het web bestaat uit een verzameling

6.2 Web 2.0

63

van services en dat deze steeds ge¨ updatet worden en beter worden naarmate het aantal gebruikers ervan stijgt. Het mooiste en bekendste voorbeeld van dit gegeven is Wikipedia1 . Wikipedia, een online gratis encyclopedie, bestaat uit informatie die door de gebruikers werd aangeleverd. Naarmate Wikipedia meer en meer gebruikt werd, werd er ook steeds meer en meer informatie toegevoegd aan deze online encyclopedie. Andere voorbeelden kunnen terug gevonden worden in Figuur 6.1 2 .

Figuur 6.1: Overzicht van een aantal Web 2.0 websites.

Om deze interactie met het web mogelijk te maken werd er afgestapt van de statische HTML pagina’s. Nieuwe technologieën werden ontwikkeld. JavaScript is zo’n technologie die het mogelijk maakt om dynamische HTML pagina’s op te bouwen met informatie specifiek voor een bepaalde eindgebruiker. PHP is ook zo’n technologie. Het is een scripttaal die webservers instaat stelt dynamisch HTML pagina’s te genereren. Dit zijn maar enkele hedendaagse technologieën, er zijn nog vele andere ter beschikking. 1 2

http://www.wikipedia.org/ http://elrincondelainformaticaa.blogspot.be/

6.3 Cloudstone

64

Om het Web 2.0 gedrag te kunnen simuleren werd er een Web 2.0 benchmark applicatieplatform gekozen. Cloudstone is zo’n platform.

6.3

Cloudstone

Cloudstone [33] is een multi-platform benchmark raamwerk die het mogelijk maakt om een Web 2.0 applicatie op te zetten en dit aan de hand van meerdere hedendaagse webtechnologieën. Als Web 2.0 applicatie maakt het platform gebruik van Olio. Olio3 is een raamwerk dat een evenementenwebsite simuleert waarbij gebruikers de interactie aangaan met de applicatie die voorzien wordt door de website. Van de drie verschillende implementaties die beschikbaar zijn werd de PHP versie gebruikt voor de casestudie. De reden voor deze keuze is het veelvuldig voorkomen van PHP bij interactieve websites. Naast Olio die voorziet in de webapplicatie maakt Cloudstone gebruik van het Faban 4 raamwerk als werklastgenerator. Met dit raamwerk wordt het mogelijk gemaakt om op één server een werklast te genereren die bestaat uit een verzameling van gelijktijdige gebruikers. Alle machines die gebruikt worden in een bepaalde set-up zijn voorzien van een Faban implementatie. Deze implementatie is overal dezelfde en moet een kopie zijn van diegene die zich als master zal gedragen. De master in de implementatie is diegene die de werklast van gelijktijdige gebruikers zal genereren. De kopieën op hun beurt zijn slaven van deze master implementatie. De master bestaat uit een webinterface waar allerlei parameters zoals aantal gelijktijdige gebruikers kunnen opgegeven worden samen met de IP-adressen van de webservermachines, databanken, cacheservers en bestandslocatie die deel uitmaken van de opstelling.

6.3.1

Opzet

Een benchmark opstelling werd in de Amazon cloud geplaatst. Deze opstelling wordt weergegeven op Figuur 6.2. De eerste server in deze opstelling fungeert als eindgebruiker. Zoals reeds aangegeven zal de Faban master implementatie op deze server ervoor zorgen dat er een werklast van een aantal gelijktijdige eindgebruikers gesimuleerd zal worden. De Amazon instantie die voor deze server gebruikt werd is een Amazon M1 Large instantie. De gegenereerde aanvragen van deze gesimuleerde verzameling gebruikers wordt op zijn beurt verwerkt door een cluster van webservers. Op de bijgevoegde figuur zijn er drie zichtbaar, in de gebruikte opstelling zijn er in totaal vijf machines gebruikt. Deze vijf machines zijn allemaal identieke machines en worden voorzien door Amazon M1 Large 3 4

http://incubator.apache.org/olio/ http://faban.org/

6.3 Cloudstone

Figuur 6.2: Overzicht van de werking van de Web 2.0 benchmark Cloudstone.

65

6.4 Oude homogene hardware

66

instanties. Op deze instanties draait een Ubuntu serverbesturingssysteem met daarop een Nginx webserver samen met een PHP-server en APC implementatie die dienst doet als cache. Elke webapplicatie bevat op de een of andere manier wel een databank. Bij de Olio applicatie is dit niet anders. De cluster van webservers voeren hun Structured Query Language (SQL) zoekopdrachten uit op een MySQL databank. Deze databank wordt op zijn beurt ook voorzien door een Amazon M1 Large instantiee. Een hedendaagse applicatie bevat vaak ook foto’s en andere inhoud die door gebruikers worden gegenereerd. Daar Olio dit ook bevat is er een bestandsserver voorzien. Dit is een aparte server maar principieel is dit niet nodig. De reden waarom dit wel zo gekozen werd bestaat erin dat er een mogelijke invloed zou zijn op de antwoordtijden van de webservers. De bestandsserver moet namelijk maar één keer voorzien worden waardoor één van de webservers anders belast zou worden dan de vier andere. Deze extra belasting zou invloed kunnen hebben op de antwoordtijden van die bepaalde webserver en om dit te vermijden wordt de bestandsserver op een aparte server gedraaid. Verschillende experimenten met Cloudstone hebben aangetoond dat een m1 small instantie voldoende was.

6.4

Oude homogene hardware

Net zoals bij het bepalen van de prestatie van verschillende instanties werden ook hier verschillende experimenten uitgevoerd, en dit met het CloudStone raamwerk. In een eerste experiment bestond de hardwarematige samenstelling van de vijf verschillende webservers uit dezelfde hardware. Dit is terug te vinden in Tabel 6.1. De werklastgenerator produceerde een werklast bestaande uit 2000 gelijktijdige gebruikers. De instellingen van de generator waren zodanig dat er een aanlooptijd van 15 minuten werd gebruikt, waarna er een 15 minuten lange benchmark werd uitgevoerd en nadien een uitlooptijd van terug 15 minuten. Webserver 1 2 3 4 5

Intel(R) Intel(R) Intel(R) Intel(R) Intel(R)

CPU Xeon(R) Xeon(R) Xeon(R) Xeon(R) Xeon(R)

CPU CPU CPU CPU CPU

E5645 E5645 E5645 E5645 E5645

Introductiedatum Q1’10 Q1’10 Q1’10 Q1’10 Q1’10

Tabel 6.1: Hardwarematige samenstelling van de vijf webservers gebruikt in het eerste experiment.

6.4 Oude homogene hardware

67

De antwoordtijden voor de PHP code die de bestandsdienst afhandelt is terug te vinden in Figuur 6.3. Deze resultaten zijn opnieuw gevisualiseerd, zoals eerdere resultaten in dit werk, met boxplots of doosdiagrammen. De gebruikte manier van visualiseren is dezelfde als voorheen. Indien de boxplot doorlopen wordt van onder naar boven dan begint dit met het minimum. De afstand tussen het minimum en het 10 percentiel wordt aangegeven met de onderste verticale streep. Het gedeelte tussen het 10 percentiel en het 50 percentiel wordt hier aangegeven met de orange kleur. Dit is het onderste deel van het vierkant. Het minimum en de waarden tot aan het 50 percentiel zijn niet echt zichtbaar omdat 50 procent van alle aanvragen voor dit bepaalde PHP script een latentietijd bevat met een waarde enorm dicht bij de 0 seconden. Het bovenste gedeelte van het vierkantje of het gele gedeelte is de afstand tussen het 50 percentiel en het 90 percentiel. Daarbovenop staat er terug een verticale streep die de afstand aangeeft tussen het 90 percentiel en het maximum.

Figuur 6.3: Overzicht van de antwoordtijden van de bestandsdienst van de vijf webservers gebruikt in het eerste experiment.

Op deze Figuur 6.3 is het duidelijk dat de vijf webservers zich gelijkaardig gedragen. Ongeveer 90 procent van alle antwoordtijden zitten rond de 0.1 seconde of lager. In Figuur 6.4 zijn de resultaten opgenomen voor de gelabelde evenementendienst. De resultaten in deze figuur zijn afkomstig van hetzelfde experiment. Op beide figuren zijn de maximum waarden van de antwoordtijden niet zichtbaar. Deze nemen waarden aan van 15 tot 60 seconden. De resultaten in Figuur 6.4 wijken wel enigszins iets af met de resultaten van Figuur 6.3. De kans is groot dat dit komt doordat deze dienst iets meer resources vraagt waardoor de antwoordtijden grotere waarden aannemen.

6.5 Heterogene hardware

68

Figuur 6.4: Overzicht van de antwoordtijden van de gelabelde evenementendienst van de vijf webservers gebruikt in het eerste experiment.

6.5

Heterogene hardware

In een tweede experiment dat werd uitgevoerd met het CloudStone raamwerk werd er op zoek gegaan naar m1 large instanties die gebruik maakten van heterogene onderliggende hardware. De hardware matige samenstelling van de vijf webservers is terug te vinden in Tabel 6.2. Hierin kan gezien worden dat webserver één en webserver vijf een ander hardware platform hebben. Dit is opnieuw de Intel Xeon E5-2650 die ook reeds opdook bij de prestatie-analyse van de m1 small instanties. Daar werd reeds aangehaald dat dit een nieuw platform is waardoor er met zekerheid mag besloten worden dat Amazon een algemene hardware upgrade heeft doorgevoerd in de datacenters in de Ireland regio.

6.5 Heterogene hardware

Webserver 1 2 3 4 5

69

CPU Introductiedatum Intel(R) Xeon(R) CPU E5-2650 Q1’12 Intel(R) Xeon(R) CPU E5645 Q1’10 Intel(R) Xeon(R) CPU E5645 Q1’10 Intel(R) Xeon(R) CPU E5645 Q1’10 Intel(R) Xeon(R) CPU E5-2650 Q1’12

Tabel 6.2: Hardwarematige samenstelling van de vijf webservers gebruikt in het tweede experiment.

Figuur 6.5: Overzicht van de antwoordtijden van de bestandsdienst van de vijf webservers gebruikt in het tweede experiment.

De resultaten van dit tweede experiment zijn terug te vinden in Figuren 6.5 en 6.6. Indien de resultaten van de bestandsdienst van dit tweede experiment vergeleken worden met die in Figuur 6.3 waar de resultaten werden opgenomen voor dezelfde dienst maar dan voor het eerste experiment dan kan er opgemerkt worden dat webservers één en vijf in het tweede experiment antwoordtijden hebben die duidelijk hoger zijn. Dit zijn ook de twee webservers die een afwijkend hardware platform hebben. Hiermee is nogmaals aangetoond hoe de onderliggende hardware invloed uitoefent op de prestatie van de instantie en dat die invloed ook zichtbaar wordt op applicatieniveau.

6.6 Nieuwe homogene hardware

70

Indien er gekeken wordt naar de gelabelde evenementendienst dan wordt hetzelfde effect zichtbaar. Webservers één en vijf hebben hier duidelijk antwoordtijden die tot twee maal zo hoog zijn als diegene die opgetekend werden in experiment één, zichtbaar in Figuur 6.4. Opnieuw zijn de maximum waarden van de antwoordtijden zo hoog dat deze niet zichtbaar zijn op beide figuren. Deze bedragen opnieuw tussen de 15 en 60 seconden.

Figuur 6.6: Overzicht van de antwoordtijden van de gelabelde evenementendienst van de vijf webservers gebruikt in het tweede experiment.

6.6

Nieuwe homogene hardware

Daar er in het eerste experiment enkel gebruik gemaakt werd van een ouder hardwareplatform en het in het tweede experiment duidelijk werd dat Amazon de hardware-upgrade ook aan het doorvoeren is in de duurdere instanties werd een derde en laatste experiment opgezet op basis van dit nieuwe hardware platform. Opnieuw werden er vijf webservers opgenomen in dit experiment, de gebruikte onderliggende hardware waaruit deze bestaan is terug te vinden in Tabel 6.3. Dit zijn allemaal webservers die gebruik maken van het nieuwe hardwareplatform. Het doel van dit derde experiment bestaat erin om te kijken hoe de gebruikte applicatie zich gedraagt gebruikmakende van dit nieuwe hardware platform. Het is namelijk zo dat indien er gekeken wordt naar de resultaten in hoofdstuk vier, de resultaten die


71

gevonden werden gedurende de verschillende experimenten, dat de verkregen prestatie van de m1 small instantie gebruikmakende van dit nieuwe hardwareplatform lager is dan de prestatie verkregen met het oude platform. Bij de bespreking van die resultaten werd er niet stil gestaan bij dit fenomeen maar hier wordt er een experiment opgezet om aan te tonen dat dit fenomeen ook optreedt bij de m1 large instantie. Webserver 1 2 3 4 5

Intel(R) Intel(R) Intel(R) Intel(R) Intel(R)

CPU Xeon(R) CPU Xeon(R) CPU Xeon(R) CPU Xeon(R) CPU Xeon(R) CPU

E5-2650 E5-2650 E5-2650 E5-2650 E5-2650

Introductiedatum Q1’12 Q1’12 Q1’12 Q1’12 Q1’12

Tabel 6.3: Hardwarematige samenstelling van de vijf webservers gebruikt in het derde experiment.

De resultaten van dit derde experiment zijn opgenomen in Figuren 6.7 en 6.8. Indien deze vergeleken worden met de resultaten in Figuren 6.3 en 6.4 dan wordt het duidelijk dat de geleverde prestatie van de m1 large instantie lager uitvalt met dit nieuwe hardwareplatform. De antwoordtijden, indien er gekeken wordt naar 90 procent van de waarden, nemen grotere waarden aan. De bekomen waarden zijn nog steeds aanvaardbaar maar het is opmerkelijk hoe eenzelfde applicatie, met dezelfde instellingen en gebruikmakende van hetzelfde type instantie, zich anders gaat gedragen. Wat wel opvalt aan deze nieuwe resultaten in dat de geleverde prestatie constant is daar dit met de oude hardware niet het geval was, getuige webserver vijf in Figuur 6.4. Deze webserver had toen antwoordtijden die bijna dubbel zo groot waren als de anderen die gebruikt werden in dit experiment. De oorzaak hiervan kan zijn dat deze webserver, instantie, op een druk bezette onderliggende server inwerkte waardoor de geleverde prestatie lager uitviel dan zijn collega’s. Nog een opmerkelijk feit indien alle resultaten vergeleken worden verkregen door de drie verschillende experimenten is dat de geleverde prestatie van het nieuwe hardware platform in een gemengde opstelling (experiment 2) slechtere prestaties oplevert dan wanneer deze in een opstelling zitten met homogene hardware. Naar de oorzaak hiervan is het gissen. Dit kan te wijten zijn aan de belasting van de onderliggende hardware op het moment van testen of door de werklastverdeler die gebruikt wordt door Faban. Het kan zijn dat deze niet goed overweg kan met de heterogene prestaties van de verschillende webservers.


72

Figuur 6.7: Overzicht van de antwoordtijden van de bestandsdienst van de vijf webservers gebruikt in het derde experiment.

Figuur 6.8: Overzicht van de antwoordtijden van de gelabelde evenementendienst van de vijf webservers gebruikt in het derde experiment.

BESLUIT

73

Hoofdstuk 7 Besluit “He did not arrive at this conclusion by the decent process of quiet, logical deduction, nor yet by the blinding flash of glorious intuition, but by the shoddy, untidy process halfway between the two by which one usually gets to know things.” Margery Allingham

7.1

Realisaties

Het begrijpen van de cloud is belangrijker en belangrijker aan het worden. Daar dit gegeven wint aan populariteit is het van beduidend belang dat dit gegeven geen zwarte doos wordt. In deze thesis werd daarom getracht om een prestatiebeeld te bepalen en te visualiseren van de Amazon Elastic Compute Cloud. Belangrijk om weten is dat de resultaten die in dit werk behaald werden resultaten zijn van een momentopname. Het is gevaarlijk om op basis hiervan algemene conclusies te produceren. Getuige zijn daar de resultaten die werden behaald met de m1 small instantie waarbij in de eerste onderzoeksperiode enorme prestatievariaties werden waargenomen en in de tweede onderzoeksperiode waren deze zo goed als volledig verdwenen. Een hardware upgrade doorgevoerd door Amazon ligt hieraan de basis. Hiermee wordt nog maar eens duidelijk hoe de cloud blijft evolueren. Niettegenstaande deze gegevens kan er toch getracht worden om een aantal feiten te formuleren in conclusies. Hardware heterogeniteit zal altijd een probleem zijn dat zal optreden in datacenters. Het is nu eenmaal onmogelijk bij falen van een aantal machines, een volledig datacenter te gaan vervangen en te voorzien van nieuwe hardware. Na verloop van tijd zullen verschillende hardwareplatformen zichtbaar worden in de datacenters en deze hebben ontegensprekelijk, zoals de resultaten opgenomen in dit werk aangeven, invloed op de prestaties die geleverd worden door de virtuele machines die inwerken op deze.

7.2 Toekomstperspectief

74

De uitgevoerde prestatie-analyse waarvan de resultaten werden opgenomen in het derde hoofdstuk tonen aan dat indien er prestatievariatie optreedt deze een dimensie kan aannemen van wel 50 procent en meer. Door gebruik te maken van de voorgestelde kostbesparingsstrategieën kan daar wel een gedeeltelijke oplossing voor worden aangeboden. Het cruciaal besluit hierbij is dat de gebruiker van de cloud indien deze geen voorzorgen neemt, bijvoorbeeld onder de vorm van vervangstrategie¨ n (kostbesparingsstrategieën), op het einde van de rit te veel zal betalen voor de verkregen prestaties. Aan de hand van de uitgevoerde Web 2.0 casestudie werd het ook duidelijk dat prestatievariatie impact heeft op het gedrag van een echte applicatie in de cloud. Wel opvallend is dat een hardware upgrade die uitgevoerd werd in de datacenters van de cloud niet altijd leidt tot betere prestaties maar er kan wel besloten worden dat de geleverde prestatie over verschillende instanties van hetzelfde type constanter werd. De resultaten in Hoofdstuk 5 tonen dit aan.

7.2

Toekomstperspectief

Cloud computing, is het een coup d’état of is het een lege door aan het worden. Dit was reeds het onderwerp van de inleiding van dit werk en het moet niet onder stoelen of banken gestoken worden dat de cloud meer en meer een belangrijkere rol zal gaan spelen binnen de IT industrie. Vele bedrijven staan aan de zijlijn te wachten terwijl ze zich aan het voorbereiden zijn om de sprong te wagen. Cloud leveranciers proberen zo gestaag mogelijk in te spelen op de noden en wensen van hun klanten, getuige zijn daar de vele e-mails die verkregen werden van Amazon gedurende de onderzoeksperiode waarbij er prijzen werden aangepast en nieuwe instanties gelanceerd werden. Omdat de cloud een blijvend evoluerend gegeven is zal er steeds een nood bestaan om dit item te blijven onderzoeken. Zo kan er in de Amazon cloud nog onderzocht worden of de opgegeven prestatie wel evenredig schaalt met het aantal ECU’s. Daar is in dit werk niet echt rekening mee gehouden. Dit zou in feite moeten maar het is natuurlijk geen zekerheid. Ook kan er gekeken worden of de prestatie die belooft wordt over verschillende instantietypes dezelfde is. Een High-Memory Double Extra Large Instance heeft bijvoorbeeld 13 ECU’s aan rekenkracht en een M3 Extra Large Instance ook maar leveren beide instanties dezelfde prestatie als deze onderworpen worden aan een analyse. Ook bestaat de mogelijkheid om in de toekomst een analyse te maken van de volledige cloud in plaats van een analyse van een bepaald deelaspect.

7.2 Toekomstperspectief

75

Er mag dan wel een hardware-upgrade zijn doorgevoerd, hardwareheterogeniteit zal steeds een blijvend gegeven zijn binnen de cloud. Na verloop van tijd zullen opnieuw machines beginnen te falen en vervangen worden door nieuwe exemplaren. Het is dus van groot belang dat de gebruiker continu zijn instanties blijft monitoren en strategieën tot zijn beschikking heeft die om kunnen met dit gegeven.

BIBLIOGRAFIE

76

Bibliografie [1] James Bond. The evolution http://mycloudblog7.wordpress.com/, april 2013.

to

cloud

computing.

[2] Jeff Daniels. Server virtualization architecture and implementation. Crossroads, 16(1):8–12, September 2009. [3] Engineeringnet. De cloud: Toekomst of luchtkasteel? www.engineeringnet.be, maart 2013. [4] Nicole Perlorth. Amazon cloud service goes down and takes popular sites with it. The New York Times, oktober 2012. [5] Amazon. http://aws.amazon.com/, mei 2013. [6] Rackspace. http://www.rackspace.com/cloud, mei 2013. [7] Microsoft Windows Azure. http://www.windowsazure.com/en-us/, mei 2013. [8] Google. https://developers.google.com/appengine, mei 2013. [9] Amazon Elastic Compute Cloud (Amazon EC2). http://aws.amazon.com/ec2/. [10] Mark L. Badger; Timothy Grance; Robert Patt-Corner; Jeffrey M. Voas;. Cloud Computing Synopsis and Recommendations. NIST, 2012. [11] Gartner. http://www.gartner.com, oktober 2012. [12] Xen. http://xen.org/, mei 2013. [13] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. Xen and the art of virtualization. SIGOPS Oper. Syst. Rev., 37(5):164–177, October 2003. [14] VMware. http://www.vmware.com/, mei 2013. [15] Oracle VM VirtualBox. https://www.virtualbox.org/, mei 2013.

BIBLIOGRAFIE

77

[16] Mayur R. Palankar, Adriana Iamnitchi, Matei Ripeanu, and Simson Garfinkel. Amazon s3 for science grids: a viable solution? In Proceedings of the 2008 international workshop on Data-aware distributed computing, DADC ’08, pages 55–64, New York, NY, USA, 2008. ACM. [17] Simson L. Garfinkel. An evaluation of amazon’s grid computing services: Ec2, s3 and sqs. Technical report, Center for, 2007. [18] Guohui Wang and T. S. Eugene Ng. The impact of virtualization on network performance of amazon ec2 data center. In Proceedings of the 29th conference on Information communications, INFOCOM’10, pages 1163–1171, Piscataway, NJ, USA, 2010. IEEE Press. [19] Sean K. Barker and Prashant Shenoy. Empirical evaluation of latency-sensitive application performance in the cloud. In Proceedings of the first annual ACM SIGMM conference on Multimedia systems, MMSys ’10, pages 35–46, New York, NY, USA, 2010. ACM. [20] Ang Li, Xiaowei Yang, Srikanth Kandula, and Ming Zhang. Cloudcmp: comparing public cloud providers. In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, IMC ’10, pages 1–14, New York, NY, USA, 2010. ACM. [21] Malte Schwarzkopf, Derek G. Murray, and Steven Hand. The seven deadly sins of cloud computing research. In Proceedings of the 4th USENIX conference on Hot Topics in Cloud Ccomputing, HotCloud’12, pages 1–1, Berkeley, CA, USA, 2012. USENIX Association. [22] 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, HotCloud’12, pages 4–4, Berkeley, CA, USA, 2012. USENIX Association. [23] 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, SoCC ’12, pages 20:1–20:14, New York, NY, USA, 2012. ACM. [24] The Dacapo benchmark suite. http://www.dacapobench.org/, april 2013. [25] 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.

BIBLIOGRAFIE

78

Moss, Aashish Phansalkar, Darko Stefanović, Thomas VanDrunen, Daniel von Dincklage, and Ben Wiedermann. The dacapo benchmarks: Java benchmarking development and analysis. SIGPLAN Not., 41(10):169–190, October 2006. [26] Python. april 2013.

http://svn.python.org/projects/python/trunk/tools/pybench/readme,

[27] Apache Lucene. http://lucene.apache.org/core/, april 2013. [28] Apache. https://cwiki.apache.org/gmoxdoc20/daytrader.html, april 2013. [29] Apache. http://geronimo.apache.org/, april 2013. [30] Reinhold P Weicker. Dhrystone: a synthetic systems programming benchmark. Communications of the ACM, 27(10):1013–1030, 1984. [31] Sam Harbaugh and John A Forakis. Timing studies using a synthetic whetstone benchmark. ACM SIGAda Ada Letters, (2):23–34, 1984. [32] Tim O’Reilly. What is web 2.0: Design patterns and business models for the next generation of software. MPRA Paper 4578, University Library of Munich, Germany, March 2007. [33] W. Sobel, S. Subramanyam, A. Sucharitakul, J. Nguyen, H. Wong, S. Patil, A. Fox, and D. Patterson. Cloudstone: Multi-platform, multi-language benchmark and measurement tools for web 2.0. 2008.

LIJST VAN FIGUREN

79

Lijst van figuren 2.1 2.2 2.3 2.4

Overzicht van de cloud servicemodellen. . . . . . . . . . . . Overzicht van drie mogelijke cloud implementatiemodellen. Magic Quadrant voor Cloud IaaS . . . . . . . . . . . . . . Overzicht van de verschillende types hypervisors. . . . . .

3.1 3.2

Componentendiagram voor het Java raamwerk. . . . . . . . . . . . . . . . 22 Overzicht van de weergave van de resultaten bepaald door de Unixbench benchmark. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 4.2 4.3 4.4 4.5

Selectief prestatiebeeld van een Amazon Micro instantie . . . . . . . . . . . Prestatiebeeld van een Amazon micro instantie . . . . . . . . . . . . . . . . Boxplot visualisatie van benchmarkresultaten. . . . . . . . . . . . . . . . . Boxplot grafiek met 10 prestatieresultaten van Amazon M1 small instanties. Boxplot grafiek met 10 prestatieresultaten van Amazon M1 small instanties met een grote uitschieter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boxplot grafiek met 10 prestatieresultaten van Amazon M1 small instanties zoals een gebruiker dit zou verwachten. . . . . . . . . . . . . . . . . . . . . Cumulatieve distributie van de verzameling van resultaten van de DaCapo H2 benchmark uitgevoerd op de Amazon M1 Small instantie. . . . . . . . . Prestatiebeeld gedurende 24 uur van een Amazon M1 Small instantie . . . Tweede prestatiebeeld gedurende 24 uur van een Amazon M1 Small instantie UnixBench benchmark scores voor 30 m1 small instanties. . . . . . . . . . UnixBench benchmark scores van het Intel Xeon E5-2650 platform. . . . . Gemiddelde uitvoeringstijd van de DaCapo H2 benchmark uitgevoerd op 30 machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gemiddelde uitvoeringstijd van de DaCapo H2 benchmark voor de 28 machines van het Intel Xeon E5-2650 platform. . . . . . . . . . . . . . . . . . UnixBench benchmark scores voor 10 m1 small instanties. . . . . . . . . . UnixBench benchmark score voor 30 Amazon m1 large instanties . . . . .

4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 9 . 10 . 11 . 13

34 35 36 38 39 40 41 43 43 44 46 46 47 47 48

LIJST VAN FIGUREN

80

4.16 UnixBench benchmark score voor negen machines van het Intel Xeon 5507 platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.17 Gemiddelde uitvoeringstijd van de DaCapo Tradesoap benchmark voor 30 Amazon m1 large instanties. . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.18 Gemiddelde uitvoeringstijd van de DaCapo Tradesoap benchmark voor negen machines van het Intel Xeon 5507 platform. . . . . . . . . . . . . . . . 50 5.1 5.2 5.3 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8

Cumulatieve distributie van de verzameling van resultaten van de DaCapo H2 benchmark uitgevoerd op de Amazon M1 Small instance. . . . . . . . . 54 Resultaten van een simulatie die uitgevoerd werd met de Java simulator. . 59 Resultaten van een simulatie die uitgevoerd werd met de Java simulator. . 60 Overzicht van een aantal Web 2.0 websites. . . . . . . . . . . . . . . . . . Overzicht van de werking van de Web 2.0 benchmark Cloudstone. . . . . Overzicht van de antwoordtijden van de bestandsdienst van de vijf webservers gebruikt in het eerste experiment. . . . . . . . . . . . . . . . . . . . Overzicht van de antwoordtijden van de gelabelde evenementendienst van de vijf webservers gebruikt in het eerste experiment. . . . . . . . . . . . . Overzicht van de antwoordtijden van de bestandsdienst van de vijf webservers gebruikt in het tweede experiment. . . . . . . . . . . . . . . . . . . . Overzicht van de antwoordtijden van de gelabelde evenementendienst van de vijf webservers gebruikt in het tweede experiment. . . . . . . . . . . . Overzicht van de antwoordtijden van de bestandsdienst van de vijf webservers gebruikt in het derde experiment. . . . . . . . . . . . . . . . . . . . Overzicht van de antwoordtijden van de gelabelde evenementendienst van de vijf webservers gebruikt in het derde experiment. . . . . . . . . . . . .

. 63 . 65 . 67 . 68 . 69 . 70 . 72 . 72

LIJST VAN TABELLEN

81

Lijst van tabellen 4.1 4.2 4.3

Specificaties van de Amazon Micro instantie . . . . . . . . . . . . . . . . . 33 Specificaties van de Amazon m1 small instantie . . . . . . . . . . . . . . . 35 Specificaties van de Amazon m1 large instantie . . . . . . . . . . . . . . . . 48

6.1

Hardwarematige samenstelling van de vijf webservers gebruikt in het eerste experiment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Hardwarematige samenstelling van de vijf webservers gebruikt in het tweede experiment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Hardwarematige samenstelling van de vijf webservers gebruikt in het derde experiment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.2 6.3

Prestatie-analyse in een cloud-omgeving

Recommend Documents