Geavanceerde schaalmethodes voor PaaS providers

Geavanceerde schaalmethodes voor PaaS providers Jeroen Vandensteen

Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Tim Wauters Begeleiders: dr. ir. Gregory Van Seghbroeck, ir. Thomas Vanhove Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2012-2013

Geavanceerde schaalmethodes voor PaaS providers Jeroen Vandensteen

Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Tim Wauters Begeleiders: dr. ir. Gregory Van Seghbroeck, ir. Thomas Vanhove Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2012-2013

Toelating tot bruikleen

De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef 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.

Jeroen Vandensteen 12 augustus 2013

Woord vooraf

Met deze masterproef voltooi ik mijn opleiding master in de ingenieurswetenschappen: computerwetenschappen aan de Universiteit Gent. Deze masterproef werd uitgegeven in 2013 binnen de vakgroep Informatietechnologie (Intec) van Universiteit Gent, die onder andere de onderzoeksgroep Internet Based Communication Networks and Services (IBCN) huisvest. Ik ben al een hele tijd ge¨ınteresseerd in cloud applicaties en systemen en was dan ook erg opgetogen toen bleek dat IBCN heel wat masterproeven begeleidt rond cloudtechnologie. Ik kreeg veel vrijheid in wat ik precies zou onderzoeken. Ik zou dan ook willen beginnen met de vakgroep in het algemeen te bedanken. Graag had ik deze personen in het bijzonder bedankt: De promotoren prof. dr. ir. Filip De Turck en dr. ir. Tim Wauters voor het geven van de

nodige feedback tijdens de presentaties iMinds, voor het ter beschikking stellen van de Virtual Wall waarop alle experimenten

werden uitgevoerd. Maarten De Wispelaere, voor het snel ingrijpen wanneer ik problemen had met de Virtual

Wall En niet in het minst de begeleiders Gregory Van Seghbroeck en Thomas Vanhove, voor de

erg gewaardeerde begeleiding van het begin tot het einde van deze masterproef.

Jeroen Vandensteen augustus 2013

Geavanceerde schaalmethodes voor PaaS providers door Jeroen Vandensteen Masterproef ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2012–2013 Promotoren: prof. dr. ir. F. De Turck dr. ir. T. Wauters Begeleiders: dr. lic. G. Van Seghbroeck ir. T. Vanhove Faculteit Ingenieurswetenschappen en Architectuur Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter

Samenvatting Deze masterproef stelt een nieuw Platform as a Service (PaaS) systeem, genaamd Advanced Scalable Platform (ASP), voor waarbij applicaties kunnen gebruik maken van verschillende schaalmethodes. Met ASP worden dan drie databank multi-tenancy modellen opgezet waarna de performantie vergeleken wordt aan de hand van realistische scenarios. Hiervoor wordt gebruik gemaakt van een webshop. Daarnaast wordt een nieuwe schaalmethode voor application servers (AS) voorgesteld, waarbij de applicatie fijnschaliger wordt geschaald. Met behulp van ASP wordt dan vergeleken hoe deze methode zich zou verhouden ten opzichte van de klassieke schaalmethode, namelijk het dupliceren van de volledige AS.

Trefwoorden cloud, PaaS , schalen, application server, databank

Advanced Scaling Methods for PaaS Providers Jeroen Vandensteen Supervisor(s): prof. dr. ir. Filip De Turck, dr. ir. Tim Wauters  Abstract ─ This article summarizes the master thesis “Geavanceerde schaalmethoden voor PaaS provider”. A new PaaS platform is introduced with support for multiple scaling methods, both for the database servers and for the application servers. The performance of those methods are then evaluated by using the platform. Keywords ─ Cloud, PaaS, scaling, application server, database

I. INTRODUCTION A lot of companies are moving their software to the cloud. The two main reasons are a possible smaller cost and the ability to scale applications with minimum effort. Therefore scaling, higher loads can be easily managed by scaling up or out. But even with this huge interest in cloud technology, little is published about the performance of different ways to scale applications in the cloud. Because of this, the performance of several methods are compared. To compare these methods, a new Platform as a Service (PaaS) system which supports different scaling methods was built and was called Advanced Scalable Platform (ASP). With this set up, three multi-tenancy models for the database are implemented in ASP and tested by simulating realistic scenarios. Also the classical scaling strategy for application servers (AS), which consists of duplicating the AS, is compared to a proposed new strategy. II. THE ADVANCED SCALABLE PLATFORM

with configuration management. With those two elements, virtual machines can be created and configured automatically. This way AS and database servers are created and configured. With different configuration definitions, different scaling methods can be defined. A monitoring service was added to monitor the different virtual instances. Monitoring is important to decide when to scale the different systems, but for this master thesis the service is used to obtain measurements while executing load tests so that different scaling systems can be compared. B. Implementation The system uses Eucalyptus to serve as IaaS. Eucalyptus was chosen because of the compatibility with the Amazon Web Services (AWS) and the ease of setup. The configuration management is handled by Chef. The choice for Chef over Puppet was made because of the flexibility to use Ruby to define the different configurations. Chef also configures the Eucalyptus setup, so that the IaaS itself can be expanded with minimum effort. The AS are using JBoss AS 7.2, because of the available clustering options, while MySQL is used to handle the databases because it is the most widely used database server which is freely available. Zabbix is used as monitoring service, because of the easy installation and the automatic registration of clients. ASP also consists of a frontend, which can be used to create new setups and retrieve information about running configurations. The frontend is built in PHP and uses Chef utilities to interact with the IaaS and the different nodes. III. USE CASE

Figure 1 The architecture of the ASP platform.

A. Overview A new PaaS system, the Advanced Scalable Platform (ASP), was created to be able to scale the deployed applications using different scaling strategies. With this platform, those strategies can be easily compared. An overview of the architecture of ASP is depicted in Figure 1. ASP consists of an Infrastructure as a Service (IaaS) along Jeroen Vandensteen created the master thesis to obtain the academic degree of master of engineering – computer science at Ghent University (UGent), Gent, Belgium. E-mail: [email protected]

Because it is important to test the different strategies with realistic scenario’s, an application was needed which delivers realistic functionalities, but also is easy to understand. Those functionalities can then be used during the tests which execute realistic scenarios. Duke’s Forest, an internet store used as a use case in the Java EE 6 Tutorial, was selected because of its simplicity combined with a complete functionality of a basic web shop. Several scenario’s, such as registering, shopping and consulting already made orders, were created using WebLoadUI. With this software package, load tests can be easily recorded and executed by many virtual concurrent users. IV. SCALING THE DATABASE A. Multi-tenancy models Software providers can sell their product to multiple users, which results in a multi-tenant installation. These applications should use one of the database multi-tenancy models. Three of those models are tested:

  

Shared Nothing: Every user has its own database Shared Instance: The database server is shared among users, but every user has its own database on this server Shared Table: All users use the same database and even the same tables. The owner of a record is identified by an extra database field in every table.

B. Implementation of the models To be able to implement the three models without major adjustments to the application, views and triggers were made in the database so that the application would think the views are his personal tables, while in reality all the different users use the same tables. With those adjustments to the database layout, the three models were implemented by creating Chef scripts which offer the correct database information to the AS. The three models were set up with each three web shops. Those web shops all had their own AS in ASP with the same resources. The database servers of the Shared Nothing setup had one third of the resources compared to the database server of Shared Instance and Shared Table. In this way, each setup uses exactly the same amount of resources. C. Load tests With these setups, three scenarios were run six times with a different amount of concurrent virtual users. All setups were tested by running the scenarios on all shops at the same time. All those tests were repeated three times. First a scenario where users register themselves was run with a constant 8, 16, 32, 64, 128 and 256 concurrent users. Every test was executed for 15 minutes. With a small number of concurrent users, the number of executed scenarios within those 15 minutes is about the same for the different models. But with 64 concurrent users and more, Shared Nothing clearly can handle more scenarios than the two others. A second scenario where people consult their existing orders and get a statistical overview of their spending resulted in approximately the same results. The third scenario simulated a shopping session where the virtual user first registers himself, logs in, looks at different product categories and makes an order with a couple of products. This scenario will cause quite a lot of SQL queries to get all product lists. The tests showed, again, that Shared Nothing performs better than the two other models, but this time Shared Instance clearly outperforms Shared Table. D. Conclusion If the only criterium to choose a database model is performance, Shared Nothing should be used. But it’s clear that also other considerations should be taken into account. For example, only tests were performed with a heavy load on all AS at the same time. When the load would only be put at one AS, one would expect that Shared Instance and Shared Table would outperform Shared Nothing because of the extra resources available to the database server. V. SCALING THE APLLICATION SERVER A. Scaling strategies Currently the most widely used strategy to scale AS is duplicating them as a whole and using a load balancer to divide the requests between them. Another tactic which could result in better performance, is to scale in a more fine-grained

way: Every Enterprise Java Bean (EJB) could be scaled separately by placing them in a cluster, while one or more AS could divide the requests between the EJB’s. To implement this scaling tactic, an advanced clustering algorithm should be used to point out which EJB’s interact frequently, so that closely coupled EJB’s could be placed together. To place and duplicate those EJB’s, a monitoring system should also be setup which can monitor every EJB separately. B. Implementation of these strategies The classical approach was set up by using JBoss mod_cluster, which uses httpd to load balance the requests. One web shop was created on three AS, of which one AS also served as load balancer to distribute the requests among them. The second tactic wasn’t implemented as a whole, because the tasks listed before are too extensive to add to the scope of this master thesis. Instead a setup was made which could be created by the tactic: One EJB, the OrderBean which processes the orders, was duplicated over three AS, of which one also hosted the complete application. C. Load tests When running the test where people check their order statistics, which we used before, the setup which only duplicated the OrderBean clearly outperforms the other set. Another scenario in which people created a PDF of their orders, we see an even bigger increase in performance when using the new tactic. D. Conclusion The proposed tactic clearly has potential when EJB’s are used which have to execute relatively heavy work. In future work the tactic should be implemented fully to really estimate the performance increase, but the initial results show a lot of potential. VI. GENERAL CONCLUSION By creating ASP, it is proven that a PaaS setup could be created in such a way that supports different scaling strategies. The results of the different tests prove that ASP can easily be used to compare different scaling strategies. When choosing a database multi-tenancy model, one should consider that the Shared Nothing setup has a performance advantage when there’s an evenly load between the applications. But one shouldn’t forget to also consider other criteria, as there are: uneven load between applications, simplicity to manage and security. Future work could add these criteria to the comparison. When scaling an AS, one shouldn’t only consider the duplication of the complete AS. The tests clearly showed that scaling small parts of an application can lead to a significant performance increase. It would be interesting to see the proposed scaling implemented in future work.

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding

1

1.1

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2 Technologiestudie

4

2.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

De cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3

Schalen van databanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3.1

Shared Nothing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3.2

Shared Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3.3

Shared Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4

Schalen van applicatie servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.5

IaaS systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.5.1

Eucalyptus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.5.2

OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.5.3

CloudStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.5.4

Nimbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.5.5

OpenNebula

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

14

2.5.6

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

Configuratie management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.6.1

Puppet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

2.6.2

Chef . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

Applicatie Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.6

2.7

INHOUDSOPGAVE

ii

2.7.1

Distributed OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.7.2

Java EE 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.7.3

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3 Architectuur

21

3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.2

Configuratie Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.3

Infrastructure as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.4

Applicaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.4.1

Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.4.2

Databank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4 Use case

29

4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.2

Duke’s Forest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2.1

Opbouw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2.2

Functionaliteiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2.3

Aanpassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5 Implementatie

35

5.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.2

Configuratie Management: Chef . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.2.1

Chef Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.2.2

Chef Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.2.3

Chef Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

IaaS Platform: Eucalyptus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.3.1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.3.2

Installatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.3.3

Gebruik van de IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

Eigen PaaS Platform: ASP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.4.1

Application Server: JBoss AS . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.4.2

Databank server: MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.4.3

Monitoring service: Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.4.4

Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.3

5.4

INHOUDSOPGAVE

5.5

5.6

iii

Hardware: Virtual Wall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.5.1

De opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.5.2

Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

Benchmarking: WebLoadUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

6 Het schalen van databanken

58

6.1

De verschillende modellen implementeren . . . . . . . . . . . . . . . . . . . . . .

58

6.2

Opstelling van de testomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

6.3

Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6.4

Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

6.4.1

Registreren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

6.4.2

Bestellingen bekijken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

6.4.3

Aankopen doen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

6.5

7 Het schalen van de applicatie server

80

7.1

De verschillende modellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

7.2

Opstelling van de testomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

7.3

Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

7.4

Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

7.4.1

Bestellingen bekijken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

7.4.2

Bestellingen in PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91

7.5

8 Conclusie

92

A Errata

97

INHOUDSOPGAVE

iv

Verklarende woordenlijst

API

Application Programming Interface: Een interface die toelaat een computerprogramma te communiceren met een ander programma of bibliotheek

AS

Application Server

ASP

Advanced Scalable Platform, het PaaS systeem dat in deze masterproef ontwikkeld wordt

AWS

Amazon Web Services, een commercile IaaS

Chef cookbook

Een verzameling van scripts en attributen die samen één geheel vormen. Ze kunnen aangeboden worden op de community website van Chef

Chef recipe

Een script dat een Chef node configureert

Chef role

Een opsomming van Chef recipes en attributes, waardoor er een volledige configuratie wordt gedefinierd. Deze role kan dan toegewezen worden aan één of meerdere nodes.

CLC

Eucalyptus Cloud Controller

DB

databank

Deploy

uitrollen van een programma of onderdeel

EJB

Enterprise Java Bean: module met business logic

Elastische adressen

IP

Statische IP adressen die snel toegewezen kunnen worden aan andere instanties wanneer er bijvoorbeeld iets fout loopt. Het IP adres is vastgekoppeld aan de gebruiker van de cloud in plaats van aan een instantie.

IaaS

Hiermee wordt infrastructuur, zoals processorkracht, geheugen, netwerkopslag en netwerkcapaciteit aangeboden als dienst. Klanten kunnen alle type software draaien op deze infrastructuur, inclusief besturingssystemen en eigen applicaties. Ze hebben wel geen invloed op de onderliggende cloudinfrastructuur.

IDE

Integrated Development Environment, een ontwikkelomgeving zoals Netbeans en Visual Studio

JNDI

Java Naming and Directory Interface: een directory service waarmee o.a. EJB’s kunnen worden opgezocht

JSF

JavaServer Faces, het templating systeem van Java EE

INHOUDSOPGAVE

Middleware

v

Software tussen het besturingssysteem en de applicatie. De middleware zal zaken abstraheren, zoals communicatie en data-opslag, zodat de applicatie werkt onafhankelijk van het gebruikte besturingssysteem.

mod cluster

Een Jboss module voor httpd die load balancing voorziet voor Jboss AS

Multi tenancy

Een applicatie op één instantie installeren en aanbieden aan verschillende klanten

NC

Eucalyptus Node Controller

on-premise

Een installatie op locatie van de klant.

PaaS

Hiermee kunnen klanten een eigen gemaakte of gekochte applicaties uitrollen in de cloud, zolang deze applicaties voldoen aan een aantal eisen van de provider. De provider kan eisen stellen aan bijvoorbeeld de programmeertaal en de gebruikte bibliotheken. Opnieuw heeft de klant geen invloed op de onderliggende infrastructuur.

Private cloud

Een cloud van één bedrijf voor intern gebruik

Public cloud

Een cloud die aangeboden wordt aan derden

SaaS

Software die aangeboden wordt over het internet door een SaaS provider. De cloudinfrastructuur waarop de software draait kan niet be\¨ınvloed worden door de klant.

Scale down

Servers weghalen

Scale out

Meer servers inzetten

Scale up

De server van meer resources voorzien

Sharding

Het partitioneren van een databank. Aan de hand van regels wordt bepaald waar de data komt. Door de regels toe te passen, weet men ook welke server de data zal bevatten.

Shared Instance

Verschillende klanten delen een databank server, maar elke klant heeft daarop zijn eigen databank

Shared Nothing

Voor elke klant wordt een aparte databank server opgezet

Shared Table

Verschillende klanten gebruiken dezelfde tabellen op dezelfde databank server

SI

Shared Instance

SN

Shared Nothing

ST

Shared Table

Walrus

De opslagservice van Eucalyptus

INLEIDING

1

Hoofdstuk 1

Inleiding 1.1

Probleemstelling

De laatste jaren is de term “cloud” erg populair. Hij duikt overal op in de media en wordt maar al te graag gebruikt door de marketingafdeling van softwarebedrijven. Heel wat bedrijven verplaatsen hun applicaties naar de cloud en deze trend zal zich blijven voortzetten [Castellina, 2011], [Asheesh Raina, 2012]. Ze doen dit om verschillende redenen: Infrastructuur en allerlei bijhorende diensten uitbesteden aan cloudproviders is geregeld

goedkoper en men moet hierdoor minder expertise in huis hebben Wanneer het aantal simultane gebruikers erg variëerd, bijvoorbeeld bij webwinkels tijdens

de feestdagen, moet men zich normaal voorzien op het maximum aantal gebruikers. In de cloud kan men de capaciteit dynamisch aanpassen. Applicaties kunnen aangeboden worden aan verschillende klanten zonder dat er voor elke

klant een lokale installatie vereist is. Men kan dit doen door ofwel door de lokale installatie te migreren naar de cloud en zo evenveel (virtuele) instanties te behouden, of door instanties op te stellen waarbij elke instantie meerdere klanten zal bedienen. Dit laatste noemt men een multi-tenancy. Wanneer een grotere capaciteit vereist is, kunnen applicaties op een grotere schaal worden ingezet en wanneer het gebruik afneemt, kan men weer resources vrijgeven. Dit noemt men het schalen van een applicatie. Schalen kan door ofwel servers meer (of minder) rekenkracht te geven, wat men scale up(/down) noemt, ofwel door extra (of minder) servers in te zetten, wat gekend is als

1.1 Probleemstelling

2

scale out(/in). Het schalen van een applicatie gebeurt door zowel de application servers (AS) als de databanken te schalen. Voor beide delen zijn er verschillende manieren om dat schalen te bewerkstelligen. Er is echter geen consensus over welke methodes nu best gebruikt worden. De methode die gekozen wordt, heeft nochtans invloed op de architectuur van de applicatie en vormt dus een belangrijke beslissing. Databank servers worden geschaald afhankelijk van het gebruikte multi-tenancy model. Dit zijn modellen waarop de databanken worden opgezet voor de verschillende klanten. Ze verschillen in de hoeveelheid van de architectuur die gedeeld wordt door de verschillende applicaties. Ze zijn onder andere beschreven door IBM [Lau et al., 2012] en anderen [Agrawal et al., 2011], echter ontbreken momenteel concrete cijfers rond performantie. De AS schalen gebeurt op een andere manier. Applicaties worden meestal opgesplitst in verschillende delen die dan op elk op een eigen AS worden uitgerold. Wanneer een AS zwaar belast wordt, wordt deze gedupliceerd. Dit is een best practice die Microsoft aanleert [Microsoft, 2012] en onder andere gebruikt wordt door eBay [Shoup, 2008]. Het is evenwel moeilijk om te bepalen hoe die opsplitsing nu precies moet gebeuren. Snelheidswinst zou mogelijks geboekt kunnen worden als de applicatie fijnmaziger opgesplitst kan worden, waarbij meerdere delen op één applicatie server kunnen gedraaid worden en de verdeling van deze delen dynamisch kan gebeuren. Softwareontwikkelingsbedrijven hoeven zich niet allemaal apart over deze problematiek te buigen, aangezien verschillende providers een Platform as a Service (PaaS) aanbieden. Op dat platform kan je je applicatie aanbieden, waarna het platform ervoor zorgt dat de applicatie automatisch geschaald kan worden. Daarvoor moet de applicatie wel aan enkele best practices voldoen die afhankelijk zijn van de provider. Maar deze providers bieden meestal maar 1 schaalmethode aan, welke zelfs geregeld als bedrijfsgeheim wordt beschouwd. De klant van de PaaS provider heeft hier dus geen invloed op. Of de provider dus een doordachte keuze gemaakt heeft, blijft de vraag.

1.2 Doelstelling

1.2

3

Doelstelling

De doelstelling van deze masterproef is om de verschillende schaalmethodes voor cloudtoepassingen te vergelijken, zodat PaaS providers gefundeerd kunnen kiezen voor een bepaalde opstelling. Deze vergelijking moet zo waarheidsgetrouw mogelijk zijn, om relevant te zijn binnen de industrie. Om deze methodes te vergelijken, is er een multifunctioneel PaaS systeem vereist. Daarom is het ook de bedoeling met deze masterproef een PaaS systeem te ontwikkelen dat de verschillende schaalmethodes kan aanbieden. Het systeem werd Advanced Scalable Platform (ASP) genoemd. Er werd niet gekozen om een bestaand PaaS systeem aan te passen, omdat deze systemen erg complex zijn waardoor goede metingen en eigen aanpassingen moeilijk zijn. Daarom werd een eigen platform ontwikkeld op basis van een Infrastructure as a Service (IaaS) systeem. Zo kunnen verschillende speciale testopstellingen snel opgezet worden en worden de metingen niet verstoord door invloeden van verschillende extra diensten. Eens ASP is opgezet, zal het ingezet worden om verschillende schaalmethodes te vergelijken. Zo zullen er enerzijds 3 verschillende multi-tenancy modellen voor databanken vergeleken worden. Anderzijds zal er ook een geavanceerde schaalmethode voor ASs voorgesteld en ge¨ımplementeerd worden, welke dan vergeleken wordt met de huidige technieken.

1.3

Overzicht

In hoofdstuk 2 worden een aantal begrippen gedefiniëerd en de verschillende technologieën besproken die gebruikt worden in ASP. Ook de verschillende databank multi-tenancy modellen wordt daarin besproken. De gebruikte architectuur wordt in hoofdstuk 3 uiteengezet, waarbij de functionaliteit van elk onderdeel besproken wordt. In hoodfstuk 4 wordt dan de use case besproken die gebruikt zal worden om het platform te testen. De functionaliteiten worden uitgelicht en werking ervan kort besproken. Hoe ASP dan uiteindelijk wordt ge¨ımplementeerd wordt besproken in hoofdstuk 5. ASP wordt dan ingezet in hoofdstuk 6 om de verschillende databank multi-tenancy modellen te vergelijken. Daarna worden twee schaalmethodes vergeleken voor Application Servers in hoofdstuk 7. De conclusies kunnen gevonden worden in hoofdstuk 8.

TECHNOLOGIESTUDIE

4

Hoofdstuk 2

Technologiestudie 2.1

Inleiding

Bij het maken van deze masterproef zijn er enorm veel bronnen geraadpleegd. Dit hoofdstuk geeft een samenvatting van alles wat gelezen is dat toepasselijk is voor het uiteindelijke resultaat. In Sectie 2.2 wordt besproken wat de cloud precies inhoudt en welke voordelen die biedt. Er worden een aantal termen ge¨ıntroduceerd die vaak zullen terugkomen in deze masterproef, waardoor een duidelijke definitie gewenst is. Zoals aangegeven in de inleiding, kunnen databanken op verschillende wijzen opgesteld worden in de cloud. Die verschillende modellen worden besproken in Sectie 2.3. In Sectie 2.4 worden dan weer de best practices besproken rond het schalen van ASs. Om ASP te implementeren was er nood aan een IaaS systeem. Er bestaan verschillende systemen, waardoor het aangewezen was om de verschillende systemen kort te vergelijken. Dit gebeurt in Sectie 2.5. Ook configuration management speelt een belangrijke rol, dus werden twee pakketten vergeleken. Een samenvatting vindt u in Sectie 2.6

2.2

De cloud

De laatste jaren is de term “cloud” erg populair. Toch is het niet altijd even duidelijk wat de cloud precies inhoudt. Voor deze masterproef hanteren we de definities van het National Institute of Standards and Technology (NIST). Deze definieert cloud computing als volgt:

2.2 De cloud

5

“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” [Mell and Grance, 2011] Vrij vertaald wordt dit “een model dat toelaat toegang te krijgen via een netwerk tot een gedeelde pool van configureerbare IT-middelen (bv. netwerken, servers, opslag, applicaties en diensten) die snel kunnen worden bevoorraad en vrijgegeven met minimale inspanning of interactie met de service provider. ” Volgens het NIST bezit dit model vijf essentiële kenmerken, drie servicemodellen en vier deploymentmodellen. Deze 5 karakteristieken zijn: Zelfbediening: Een consument kan zelf zaken als servertijd en netwerk opslag bestellen

zonder dat hiervoor menselijke interactie nodig is met de service provider. Netwerktoegang: Alle functionaliteit is beschikbaar over het netwerk en toegankelijk. Resource pooling: De resources van de provider worden gedeeld om meerdere klanten te

bedienen. Snelle elasticiteit: Functionaliteiten kunnen elastisch voorzien en terug vrijgegeven worden.

Dit zorgt ervoor dat men snel in alle richtingen kan schalen. Afgemeten diensten: Cloud systemen controleren en optimaliseren het verbruik van de

middelen door gebruik te maken van meetsystemen. De 3 servicemodellen zijn Infrastructure as a Service (IaaS), Platform as a Service (PaaS) en Software as a Service (SaaS). IaaS: Hiermee wordt infrastructuur, zoals processorkracht, geheugen, netwerkopslag en

netwerkcapaciteit aangeboden als dienst. Klanten kunnen alle type software draaien op deze infrastructuur, inclusief besturingssystemen en eigen applicaties. Ze hebben wel geen invloed op de onderliggende cloudinfrastructuur. Het aanbieden van virtuele machines, servers, load balancers en opslag zijn voorbeelden van IaaS. Grote IaaS providers zijn Amazon met AWS en Microsoft met Azure PaaS: Hiermee kunnen klanten een eigen gemaakte of gekochte applicaties uitrollen in de

cloud, zolang deze applicaties voldoen aan een aantal eisen van de provider. De provider

2.2 De cloud

6

kan eisen stellen aan bijvoorbeeld de programmeertaal en de gebruikte bibliotheken. Opnieuw heeft de klant geen invloed op de onderliggende infrastructuur. Een PaaS provider kan zo bijvoorbeeld een execution runtime, databank en webserver aanbieden. Google biedt met AppEngine een PaaS aan. SaaS: Software as a Service is software die aangeboden wordt over het internet door een

SaaS provider. De cloudinfrastructuur waarop de software draait kan niet be¨ınvloed worden door de klant. CRM systemen, e-mailprogramma’s en games worden vaak aangeboden als SaaS. Salesforce is bijvoorbeeld een SaaS provider. In Figuur 2.1 wordt gevisualiseerd welke delen de klant zelf moet beheren, en wat door de provider beheerd wordt.

IaaS

PaaS

SaaS

Applicatie

Applicatie

Applicatie

Data

Data

Data

Runtime

Runtime

Runtime

Middleware

Middleware

Middleware

Besturingssysteem

Besturingssysteem

Besturingssysteem

Virtualisatie

Virtualisatie

Virtualisatie

Servers

Servers

Servers

Opslag

Opslag

Opslag

Netwerk

Netwerk

Netwerk

Figuur 2.1: De verschillen tussen de 3 cloud modellen. De gekleurde blokken worden beheerd door de service provider, de andere blokken zijn voor rekening van de klant. (Gebaseerd op het schema van Kevin Remde [Kevin Remde, 2011]) De deployment modellen geven aan wie de cloud infrastructuur beheert: Private cloud: Een bedrijf zet zijn eigen cloud op voor intern gebruik

2.3 Schalen van databanken

7

Public cloud: De cloud wordt aangeboden aan derden Community cloud: Een groep van bedrijven delen een cloud Hybrid cloud: Een samenstelling van twee of meer van voorgaande modellen

Veel bedrijven verplaatsen grote softwareproducten naar de cloud[Castellina, 2011]. De belangrijkste drijfveer is schaalbaarheid om zo meer aanvragen te kunnen verwerken. Schaalvergroting gebeurt door servers meer rekenkracht te geven (scale up), of door extra servers in te zetten (scale out)[Michael et al., 2007]. Scale up is het gemakkelijkste, aangezien er niets gewijzigd moet worden aan de werkwijze van de applicaties. Het probleem is dat er niet oneindig omhooggeschaald kan worden. De krachtigste server wordt steeds bepaald door de huidige techniek, dit in tegenstelling tot uitschalen: in theorie kunnen er oneindig veel servers bijgeplaatst worden. Die schaalbaarheid en beschikbaarheid over het internet maakt het mogelijk één softwareproduct te ontwikkelen en die aan te bieden aan verschillende klanten. Dit noemt men multi-tenancy.

2.3

Schalen van databanken

Wanneer men een applicatie beschikbaar wil stellen voor verschillende klanten, moet hun data van elkaar gescheiden blijven. Dit kan op verschillende manieren. IBM onderscheidt drie multitenancy modellen[Lau et al., 2012, Agrawal et al., 2011], voorgesteld in Figuur 2.2 : 1. Shared Nothing: Er wordt voor elke klant een aparte databank server opgezet. 2. Shared Instance: Verschillende klanten delen databank servers, maar elke klant heeft zijn eigen persoonlijke databank op die servers. 3. Shared Table: Opnieuw worden databankservers gedeeld door verschillende klanten, maar er zal ook gebruik gemaakt worden van dezelfde databank en dezelfde tabellen. Deze modellen hebben elk hun voor- en nadelen met betrekking tot uitvoeren, kosten, time to market en snelheid om te schalen [Osipov et al., 2009], maar concrete cijfers rond performantie ontbreken op dit moment.

2.3 Schalen van databanken

Gebruike r 1

Gebruike r 2

Gebruiker 3

8

Gebruike r 1

Gebruike r 2

Gebruiker 3

Applicatie

Applicatie

Schema

Schema

Schema

Dat abank se rver

Dat abank se rver

Dat abank se rver

(a) Shared Nothing

Schema

Schema

Gebruike r 1

Gebruike r 2

Gebruiker 3

Applicatie

Schema

Schema

Dat abank se rver

Dat abank se rver

(b) Shared Instance

(c) Shared Table

Figuur 2.2: Databank multi-tenancy modellen: Een softwarebedrijf stelt één applicatie aan meerdere gebruikers beschikbaar. De gebruikers kunnen enkel hun eigen data zien.

2.3.1

Shared Nothing

Dit model leunt het sterkst aan bij de klassieke aanpak. Een applictie die niet in de cloud werd aangeboden, werd ge¨ınstalleerd on-premise (bij de klant), wat betekent dat elke klant zijn eigen databank server heeft staan. Het voordeel hiervan is dat de verschillende klanten elkaar op geen elke manier be¨ınvloeden. De belasting van de ene gebruiker zal geen invloed hebben op een andere gebruiker. Door de volledige scheiding is het ook gemakkelijker om de beveiliging op orde te hebben.

2.3.2

Shared Instance

Dit is een voor de hand liggende optie wanneer men naar de cloud verhuist en resources wil delen tussen verschillende klanten. Men neemt één server en plaatst daar verschillende databanken op. De meerderheid van de PHP hosting bedrijven gebruiken dit model, zoals GoDaddy, one.com en Combell. Het voordeel van dit model ten opzichte van Shared Nothing is dat er niet steeds een volledige server opgezet moet worden voor een nieuwe klant. Bij lage belasting op de databanken kan zo een beperkt aantal servers gebruikt worden. Het nadeel is dat er rekening gehouden moet worden met oneven belasting, waarbij enkele klanten soms erg veel resources vragen. Daarom moet er een algoritme gebruikt worden om de resources eerlijk te verdelen, zonder dat er resources ongebruikt blijven.

2.4 Schalen van applicatie servers

2.3.3

9

Shared Table

Shared Table ligt het verst van de klassieke manier om databanken te schalen. Toch wordt het op grote schaal gebruikt, onder andere door grote bedrijven als SalesForce [salesforce.com, 2013] en Google [Angus Kidman, 2007]. Men moet met dit model in de databank op record niveau gaan kijken om te weten tot welke klant deze behoort. Een nadeel van dit model is dat men erg grote tabellen verkrijgt, maar door gebruik te maken van sharding of federating kan men deze grote tabellen opsplitsen en verdelen over verschillende servers. Deze techniek wordt ondersteund en aangeraden door onder andere Microsoft [Cihan Biyikoglu, 2011]. Sharding werkt als volgt: er worden regels opgesteld hoe de data verdeeld wordt over de verschillende databank servers. Zo kan dit per klant opgesplitst worden, wat zou resulteren in een Shared Nothing systeem, of op de eerste letter van de naam van de klant, of misschien aan de hand van de rest na deling door 3 van de id van de klant. Deze opdeling kan dynamisch aangepast worden in onder andere SQL Azure, waardoor er ingegrepen kan worden indien één klant het systeem zwaar belast. Op die manier is deze opstelling zeer flexibel. Een ander nadeel is het feit dat de beveiliging erg ingewikkeld is. De toegangscontrole moet gebeuren op record niveau en wanneer daar iets fout loopt, kan een klant toegang hebben tot data van andere klanten. Waakzaamheid is hier dus erg belangrijk.

2.4

Schalen van applicatie servers

Ook voor applicatie servers zijn er verschillende modellen om een applicatie aan te bieden aan verschillende klanten. Zo onderscheidt IBM volgende modellen [Osipov et al., 2009]: Eén gedeelde applicatie installatie voor verschillende klanten Gemeenschappelijke middleware, maar voor elke klant een aparte applicatie installatie Gemeenschappelijke server, maar voor elke klant aparte middleware en applicatie instal-

latie Elke klant krijgt zijn eigen server met besturingssysteem, middleware en applicatie instal-

latie

2.5 IaaS systemen

10

In deze masterproef wordt enkel het laatste model bekeken. Zo zullen in hoofdstuk 7 twee strategieën vergeleken worden om dit model te schalen. Momenteel worden applicaties meestal opgesplitst in verschillende delen die dan op elk op een eigen application server worden uitgerold. Wanneer er dan een application server zwaar belast wordt, wordt deze gedupliceerd, waarna een load balancer de aanvragen verdeeld. Dit is een best practice die Microsoft aanleert [Microsoft, 2012] en gebruikt wordt door eBay[Shoup, 2008]. Eén van de vier strategien die Randy Shoup aanraadt is “Partitioneer alles”. Elk probleem zou in beheersbare stukken opgedeeld moeten worden. Die opsplitsing kan gemaakt worden op basis van data, belasting en/of gebruikerspatroon. Er zijn twee patronen om de opsplitsing te maken: enerzijds is er functionele segmentatie, anderzijds horizontale opsplitsing. Functionele segmentatie is het opsplitsen van de applicatie in partities van soortgelijke functionaliteit, zoals gebruikersbeheer, administratie en stockbeheer. Met horizontale opsplitsing wordt bedoeld dat elk functioneel segment op meerdere servers wordt geplaatst om zo hogere belasting te kunnen verwerken.

2.5

IaaS systemen

Er zijn redelijk wat verschillende IaaS software pakketten beschikbaar die opensource zijn. Zo is er bijvoorbeeld Eucalyptus, OpenStack, OpenNebula, CloudStack en Nimbus. Al deze pakketten bieden de mogelijkheid om linux servers in een cluster te zetten, waarop dan virtuele machines gedraaid kunnen worden die verbonden zijn met virtuele netwerken en van opslag kunnen worden voorzien. Deze zes pakketten delen hun functionaliteit allemaal ongeveer op dezelfde manier op: Compute: Deze functionaliteit zorgt ervoor dat virtuele machines aangemaakt en beheerd

kunnen worden. Netwerk: Deze service zorgt ervoor dat de virtuele netwerken beheerd kunnen worden. Zo

kunnen elastische IP adressen (statische IP adressen die snel toegewezen kunnen worden aan andere instanties wanneer er bijvoorbeeld iets fout loopt. Het IP adres is vastgekoppeld aan de klant van de provider in plaats van aan een instantie.) gebruikt worden en dergelijke. Opslag: Hiermee wordt er allerlei opslagmogelijkheden voorzien die gebruikt kunnen wor-

den door de virtuele machines. Beheer interface: Deze interface laat toe het geheel te beheren. Er wordt meestal een

2.5 IaaS systemen

11

Application Programming Interface (API) aangeboden, samen met een webinterface die van die API gebruik maakt. Aangezien er werd gekozen om gebruik te maken van Eucalyptus voor deze masterproef, wordt deze uitvoerig besproken, terwijl er van de andere pakketten enkel opvallende verschillen worden aangegeven.

2.5.1

Eucalyptus

Eucalyptus is een open source IaaS platform dat volledig compatibel is met de Amazon Web Services (AWS). Deze bestaat ook uit de 4 grote blokken compute, netwerk, opslag en beheer interface, zoals getoond in Figuur 2.3. De AWS compatibele tools auto scaling, elastic load balancing en cloudwatch zijn pas recent ge¨ıntroduceerd in Eucalyptus 3.3 en werden niet gebruikt in deze masterproef. Eucalyptus was tot in februari 2011 de basis van de Ubuntu Enterprise Cloud (UEC). Canonical, het bedrijf achter Ubuntu, wisselde Eucalyptus echter in voor OpenStack waardoor vanaf Ubuntu 11.04 UEC standaard OpenStack gebruikte. De CEO van Eucalyptus, Marten Mickos, beweerde in mei 2011 dat ze Ubuntu actief zouden blijven ondersteunen [Marten Mickos, 2011], echter bleek vanaf Eucalyptus 3.2, uitgebracht op 26 november 2012, die ondersteuning weg te vallen. Aangezien er ervaring aanwezig was met Ubuntu en er, toen versie 3.2 uit kwam, al scripts gemaakt waren specifiek voor Ubuntu, werd het besturingssysteem waarop gewerkt werd niet meer gewijzigd. Ondertussen zijn er wel handleidingen verschenen om nieuwe versies te compileren en installeren op Ubuntu [Alin Tomescu, 2013a] [Alin Tomescu, 2013b], maar wegens de beperkte voordelen binnen de setting van deze masterproef werd dit niet gedaan. Eucalyptus bestaat uit 6 componenten, weergegeven in Figuur 2.4. Cloud Controller (CLC): Dit is een Java programma dat de AWS Elastic Cloud Computing

(EC2) compatibele SOAP en query interfaces aanbiedt. De CLC zal ook als beheersinterface fungeren en het globale beheer verzorgen van de cloud, zoals authenticatie en rapportage. Men kan met de CLC communiceren door middel van command-line interfaces, zoals euca2ools, of via de webinterface. Walrus: Ook een Java programma dat de tegenhanger is van de AWS Simple Storage

Service (S3). Het kan gebruikt worden om met HTTP PUT/GET requests een Storage-

2.5 IaaS systemen

12

Figuur 2.3: Een overzicht van het Eucalyptus platform. De 4 basiscomponenten zijn compute, opslag, netwerk en beheer interface. Deze laatste is bij Eucalyptus compatibel met AWS. Bron: Eucalyptus.com [Eucalyptus, 2012].

as-a-Service aan te bieden. Walrus bevat ook alle images voor de virtuele machines. Deze images bevatten onder andere het besturingssyteem. Cluster Controller (CC): Dit is een C programma die de front end voorziet van een Euca-

lyptus cluster. De CC communiceert met de Storage Controller (SC) en Node Controller (NC). De CC beheert de verschillende virtuele instanties die draaien op die cluster. Storage Controller: Dit is opnieuw een Java programma, en is het equivalent van de

AWS Elastic Block Store (EBS). De SC communiceert met de CC and NC en beheert de Eucalyptus block volumes en snapshots van virtuele instanties binnen de cluster. De SC maakt gebruik van opslagsystemen zoals lokale opslag, NFS, iSCSI en SAN. VMWare Broker: Deze component is optioneel. Hij biedt een AWS compatibele interface

aan voor VMWare omgevingen en plaatst zich bovenop bestaandse ESX/ESXi hosts. Deze component werd niet gebruikt voor deze masterproef. Node Controller (NC): De NC is geschreven in C en zal de virtuele machines bevatten. De

NC downloadt images van Walrus en maakt dan nieuwe virtuele instanties aan. De NC

2.5 IaaS systemen

13

Figuur 2.4: De zes componenten van Eucalyptus. De bovenste laag zorgt voor het globale beheer, terwijl de middelste laag het beheer regelt op cluster niveau. Het laagste niveau bevat de Node Controllers die de virtuele machines bevatten. Bron: Eucalyptus.com [Eucalyptus, 2012].

kan overweg met verschillende hypervisors: KVM, Xen en VMware. Eucalyptus ondersteunt 4 verschillende manieren om het virtuele netwerk op te zetten, namelijk STATIC, SYSTEM, MANAGED en MANAGED-NOVLAN. Wanneer er gebruik gemaakt wordt van de managed mode, zal Eucalyptus voor alle netwerkmogelijkheden zorgen, zoals elastische IP adressen en VM netwerk isolatie. Managed no-vlan mode is gelijkaardig met managed, enkel zal er hier geen gebruik gemaakt worden van VLANs om de VM’s te isoleren van elkaar. System mode zal er dan voor zorgen dat er gebruik gemaakt wordt van een lokale DHCP server. Eucalyptus zal zich dan niet bezig houden met het netwerk. Als laatste is er de static mode. Deze zorgt ervoor dat Eucalyptus als DHCP server fungeert, maar dit is de enige functionaliteit die ter beschikking wordt gesteld.

2.5.2

OpenStack

OpenStack is een relatief jonge speler. OpenStack werd in juli 2010 opgericht door onder andere Rackspace en NASA. Ondertussen is het uitgegroeid tot het meestgebruikte private IaaS pakket. OpenStack vertoont veel gelijkenissen met Eucalyptus. De globale opzet is vergelijkbaar, met services als nova-compute, nova-network, nova-volume en een dashboard. OpenStack onder-

2.5 IaaS systemen

14

steunt ook bare metal provisioning: het aanbieden van fysieke machines in plaats van virtuele machines. OpenStack is deels compatibel met AWS, maar niet zo ver doorgedreven als Eucalyptus.

2.5.3

CloudStack

CloudStack begon als project van Cloud.com. Het grootste deel van de broncode werd in mei 2010 vrijgegeven, de rest volgde in 2011 nadat het bedrijf werd overgekocht door Citrix. In april 2012 werd het project ingediend en opgenomen bij de Apache Incubator. CloudStack had zijn eerste release binnen het Apache Incubator project in november 2012, maar die versie werd aangeduid door “incubating”. In maart 2013 werd CloudStack een volwaardig Apache project.

2.5.4

Nimbus

Nimbus is een project dat ook AWS compatibel is, maar is gericht op de wetenschappelijke community. Zo heeft het ondersteuning voor batch scheduleres en best-effort allocatie. Omdat het de bedoeling was om real-life situaties na te bouwen, werd hier niet verder naar gekeken.

2.5.5

OpenNebula

OpenNebula positioneert zich als een aanbieder van datacenter virtualisatie, in plaats van een pakket met allerlei andere diensten [Ignacio M. Llorente, 2013]. Aangezien OpenNebula dus niet compatibel is met AWS, zou het moeilijker zijn om de resultaten door te trekken naar de praktijk.

2.5.6

Conclusie

Het was de bedoeling om een IaaS platform te vinden dat gebruikt kan worden in commerciële omgevingen en dat gemakkelijk op te zetten was. Zowel Eucalyptus, OpenStack, CloudStack en Nimbus zijn compatibel met AWS, dus is de link duidelijk met commerciële omgevingen. Toch is de compatibiliteit van Eucalytpus verder doorgedreven dan de andere pakketten. Enkel OpenNebula mist deze compatibiliteit en viel dus af. Het feit dat Nimbus zich richt op de wetenschappelijke community zorgde er voor dat hiervoor niet gekozen werd.

2.6 Configuratie management

15

CloudStack bevond zich nog in de incubating-fase wanneer de keuze gemaakt moest worden. Dit gaf te weinig vertrouwen, waardoor er niet voor dit project werd gekozen. Ook OpenStack viel af, omdat deze moeilijker op te zetten zou zijn [Daniel Kranowski, 2012], [Christine Burns, Network World, 2013]. Uiteindelijk werd er dus gekozen om gebruik te maken van Eucalyptus. Bij de start van deze masterproef was Eucalyptus 3.1 de nieuwste versie. Er werd tijdens het opstellen van deze masterproef nooit ge¨ updatet naar een nieuwere versie, aangezien zoals gezegd de ondersteuning voor Ubuntu wegviel bij nieuwe versies. Dit is geen probleem aangezien de basisfunctionaliteit hetzelfde blijft en de toegevoegde functionaliteit niet noodzakelijk is voor deze masterproef.

2.6

Configuratie management

Om een cloud omgeving te beheren, is er nood aan geautomatiseerd configuratie management. Configuratie management zal ervoor zorgen dat de configuratie van alle IT systemen centraal kan gebeuren. Zo kunnen wijzigingen in de configuratie ëën maal worden ingegeven, waarna deze configuratie automatisch zal toegepast worden op alle relevante systemen. Momenteel zijn er 2 grote spelers: Puppet en Chef.

2.6.1

Puppet

Puppet helpt bij het beheer van IT infrastructuur gedurende de hele levenscyclus: van provisioning en configuratie tot het bijwerken van de systemen. Puppet is gemaakt om schaalbaar te zijn[Puppet Labs, ]. Puppet werkt in 4 stappen: 1. Definiëren: de gewenste configuratie beschrijven met behulp van Puppet’s declaratieve configuratie taal. 2. Simuleren: de configuratie uittesten voordat hij gebruikt wordt. 3. Handhaven: Automatisch de configuratie uitrollen en wijzigingen en problemen wegwerken 4. Rapporteren: Elk verschil tussen de gewenste en uiteindelijke configuratie wordt gerapporteerd.

2.6 Configuratie management

16

Puppet maakt gebruik van een eigen taal om de configuraties te beschrijven. Momenteel zijn er meer dan 600 configuratiebestanden te downloaden van Puppet Forge. Om Puppet te gebruiken, moet er een PC aangesteld worden als Puppet Master. Deze kan dan alle andere PC’s configureren. Die andere PC’s worden Puppet Agents genoemd.

2.6.2

Chef

Chef is sterk verwant met Puppet. Chef zal ook systemen configureren van de creatiefase tot de patch rondes. Chef werkt met een Chef Server, die centraal alle configuraties bijhoudt. Daarnaast heb je nodes, dit zijn de systemen die geconfigureerd moeten worden door Chef. Als derde heb je ook nog Chef Workstations. Deze computers hebben een lokale Chef repository en kunnen met Knife de verschillende nodes configureren. Een goed overzicht vind je in Figuur 2.5.

Figuur 2.5: Minimale chef opstelling: Chef Server met alle configuratie-gegevens, de nodes die geconfigureerd worden en het workstation van waaruit alles aangestuurd kan worden. Chef maakt gebruik van Ruby om de configuraties te beschrijven. Zo’n script om iets te configureren wordt een recipe genoemd. Recipes worden gebundeld tot een logisch geheel in een cookbook, welke aangeboden kunnen worden op de Chef community website. Momenteel zijn daar meer dan duizend cookbooks beschikbaar. Een cookbook bestaat naast recipes ook uit templates, dit zijn configuratiebestanden die aangevuld worden door Chef, en attributes, als het ware variabelen die op allerlei niveaus gedefiniëerd kunnen worden. Er bestaan ook roles, dit zijn configuraties die een bepaalde rol beschrijven, door een aantal recipes en attributes op te

2.7 Applicatie Framework

17

lijsten. Een voorbeeld: Men heeft de cookbook MySQL dat men kan downloaden van de Chef community website. Deze cookbook heeft de recipes mysql-client en mysql-server. Er wordt een role aangemaakt “webserver”, waarvan bepaald wordt dat deze de recipes mysql-server en apache2 moet bevatten, samen met het attribute node[mysql][root password] = ’test’. Deze role wordt toegewezen aan een node, waarna apache2 en mysql server automatisch worden geconfigureerd en het root wachtwoord van mysql gelijkgesteld wordt aan test wanneer men chef-client uitvoert. Alle commando’s in de recipes moeten idempotent zijn: Dit wil zeggen dat wanneer een commando ëën of meerdere keren wordt uitgevoerd, het resultaat hetzelfde moet zijn. Dit zodat de recipes opnieuw uitgevoerd mogen worden bij het aanpassen van de configuratie, zonder dat hierdoor iets anders wijzigt dan wat aangepast is. De meeste aangeboden functionaliteit van Chef is al automatisch idempotent. Wanneer bijvoorbeeld het toevoegen van een gebruiker niet idempotent zou zijn, zou bij elke aanpassing van de configuratie alle gebruikers nogmaals worden aangemaakt, wat fouten zou opleveren. Chef-client is de software die op elke node staat. Die moet uitgevoerd worden van zodra er wijzigingen zijn aangebracht aan de configuratie. Er bestaat een chef service die automatisch controleert of er wijzigingen zijn, en indien dit zo is, chef-client uitvoert. Knife is de command line tool die het mogelijk maakt om cookbooks en nodes te beheren. Ook heeft het functionaliteit om systemen te bootstrappen met Chef: Hiermee wordt een ssh sessie opgestart, wordt chef ge¨ınstalleerd en geconfigureerd om met de Chef server te communiceren, worden er automatisch recipes en roles toegekend aan de node en wordt chef-client uitgevoerd. Op die manier kan men met 1 commando een nieuwe computer volledig automatisch geconfigureerd worden. Knife heeft ook verschillende plugins, onder andere Knife Eucalyptus, Knife ec2, Knife OpenStack en Knife Azure om met de verschillende cloud platformen te kunnen communiceren. Met die plugins kan Knife onder andere virtuele instanties starten, bootstrappen en stoppen.

2.7

Applicatie Framework

Om een goede applicatie te schrijven, wordt er meestal gebruik gemaakt van een applicatie framework. Er zijn een aantal populaire frameworks voor webapplicaties, zoals Java EE 6 (Java),


18

MVC (ASP.NET), Rails (Ruby) en Symfony (PHP). Voor deze masterproef werd er gezocht naar een framework dat modulair is en waarvoor er een use case beschikbaar is die enerzijds een beperkte omvang heeft en anderzijds realistische scenario’s kan simuleren. Aangezien er ervaring was met Java, lag Java EE 6 voor de hand. Toch heeft Java een tweede framework die nog meer gericht is op modulair zijn, namelijk OSGi. Daarom werd eerst gekeken of het mogelijk was om met dit framework aan de slag te gaan.

2.7.1

Distributed OSGi

OSGi is een verzameling van specificaties die een dynamisch componenten systeem beschrijven. Ze maken een ontwikkelingsmodel mogelijk waarbij applicaties bestaan uit veel verschillende herbruikbare componenten. Die componenten kunnen hun implementatie verbergen, en kunnen gemakkelijk vervangen worden door een andere compatibele component. Deze componenten worden bundles genoemd. Een bijkomend voordeel is dat er verschillende versies van bundles naast elkaar gedraaid kunnen worden. [OSGi Alliance, ] Er zijn enorm veel OSGi containers beschikbaar: Deze programma’s laten toe OSGi bundles uit te rollen, na eerst alle dependancies opgezocht te hebben. Zo is er Eclipse Equinox, Apache Felix en Knopflerfish. Heel veel Java EE application servers zijn ook opgebouwd uit OSGi bundles, en laten toe OSGi bundles te deployen. Dit is onder andere mogelijk in JOnAS. Eclipse Virgo pakt het dan weer anders aan door Equinox te combineren met Apache TomCat en het Spring Framework. Met Virgo kunnen dus volledige webapplicaties opgebouwd uit OSGi bundles onmiddellijk gedraaid worden. Sinds OSGi 4.2 kunnen ook bundles die op externe servers staan gebruikt worden. Dit wordt beschreven in hoofdstuk 13 van de OSGi 4.2 specificaties [The OSGi Alliance, 2009]. Dit wordt mogelijk gemaakt door de Distribution Provider component. Die maakt lokale proxy’s van de externe bundles aan, die dan op hun beurt de functieaanroepen doen op de externe bundles zelf. Het Apache CXF Distributed OSGi subproject voorziet de ”Reference Implementation”van die Distribution Provider component.[The Apache Software Foundation, a] Er is ook een andere implementatie, namelijk r-OSGi. Deze maakt ook automatisch proxy bundles aan[Rellermeyer et al., 2007]. Beide versies bieden niet onmiddellijk de mogelijkheid om een pool van servers met dezelfde bundles te hebben waarop load balancing kan toegepast worden. Het is mogelijk een bundle op te


19

zoeken in een directory in plaats van een statische link te leggen, maar de keuze welke bundle uit-

eindelijk gebruikt wordt, moet gemaakt worden in het programma zelf[The Apache Software Foundation, b Wat wel mogelijk is, is het automatisch downloaden en lokaal deployen van dependencies, onder andere met Apache Ace. Er is zelfs een uitgebreid framework, OSGi4C, die andere parameters mee neemt bij de beslissing welke bundle-implementatie het interessantst is, zoals geheugengebruik[Schmidt et al., 2009]. De distributie van bundles gebeurt bij OSGi4C via P2P. Om toch load balancing toe te passen op extern gedeployde bundles, zou men DNS load balancing kunnen toepassen[Koschel et al., 2011]. Een andere mogelijkheid zou zijn om een load balancing bundle te maken. Door die vergaande splitsing in OSGi applicaties, zou het interessant zijn om de verschillende componenten apart te schalen. Echter werd er geen use case gevonden die zowel volledig met OSGi is opgebouwd, een realistische use case is, en stabiel is. Momenteel wordt OSGi vooral gebruikt in middleware en dergelijke, zoals het PaaS systeem WSO2.

2.7.2

Java EE 6

Java EE 6 is een erg compleet framework. Zo is er ondersteuning voor onder andere authenticatie, geautomatiseerde koppelingen met databanken, batch processen en templating systemen. Business logica wordt verwerkt door Enterprise Java Beans (EJB). Dit zijn herbruikbare modules die ook vanop afstand kunnen worden aangesproken. Ze kunnen bijvoorbeeld met behulp van JavaServer Pages gebruikt worden in webpagina’s, of met behulp van JaxRS kunnen ze ter beschikking gesteld worden als REST API. Er zijn vier soorten EJB’s: Stateful Session Bean: bij elke oproep wordt gekeken door wie de oproep is gedaan. Tijdens

een sessie zal telkens hetzelfde object gebruikt worden, maar dit object zal nooit gebruikt worden voor andere sessies. Daarom kunnen er gegevens opgeslagen worden specifiek voor die sessie. Een winkelmandje kan bijvoorbeeld voorgesteld worden doro een Stateful Session Bean. Stateless Session Bean: Hiermee wordt geen state bijgehouden. Elk object kan slechts 1

simultane gebruiker worden gebruikt. Het object kan wel hergebruikt worden door een andere gebruiker indien op een ander ogenblik de Bean bevraagt. Wanneer een object toch


20

simultaan bevraagd wordt, zal er een nieuw object worden aangemaakt om de aanvraag te kunnen beantwoorden; Singleton Session Bean: Hierbij wordt er één object bijgehouden binnen de Java Virtual

Machine (JVM). Hierdoor worden de gegevens gedeeld over de gehele applicatie, gelijk wie de bean oproept. Message Drive Bean: Deze objecten worden niet getriggerd door methode-oproepen, maar

door berichten. Deze Beans kunnen zich registreren voor berichten met behulp van de Java Message Service (JMS). Data wordt in Java EE 6 voorgesteld door Entities, die door de Java Persistence API gekoppeld worden met een databank. Webpagina’s worden dan weer opgesteld met een templating systeem genaamd JavaServer Pages (JSP).

2.7.3

Conclusie

Distributed OSGi staat nog in zijn kinderschoenen, en een interessante use case werd niet gevonden. Dit in tegenstelling tot Java EE 6, die zich al bewezen heeft. Java EE 6 voldoet aan alle eisen die gesteld werden voor het applicatie framework: Het is een framework dat vaak gebruikt wordt in commerciële omgevingen, het is modulair door het gebruik van EJB’s, en er zijn use cases te vinden waarmee realistische scenario’s zijn te modelleren. Daarom wordt dit framework ook gebruikt in deze masterproef

ARCHITECTUUR

21

Hoofdstuk 3

Architectuur 3.1

Inleiding

Het doel van deze masterproef is om de verschillende schaalmethodes die PaaS providers kunnen gebruiken te vergelijken. Hiervoor moet er eerst een systeem zijn waarop al deze methodes kunnen worden ge¨ımplementeerd. Aangezien we de testen willen draaien in een zo realistisch mogelijke setting, ligt het voor de hand een PaaS systeem op te zetten. Maar, zoals gezegd, werd er gekozen om niet met een bestaand PaaS systeem aan de slag te gaan, maar om een eigen PaaS systeem, genaamd Advanced Scalable Platform (ASP), te bouwen. Omdat ASP van nul is opgebouwd, kunnen er op alle plaatsen aanpassingen doorgevoerd worden en metingen worden verricht. Ingrijpen in reeds bestaande PaaS systemen zou een enorme kennis vereisen van het systeem, terwijl ook verschillende extra services die meegeleverd worden, metingen kunnen be¨ınvloeden. PaaS providers zouden dan ASP kunnen gebruiken op hun systemen. Klanten van de provider kunnen dan hun applicatie uitrollen na het kiezen en configureren van de schaalmethode. Deze klanten kunnen hun applicatie dan aan 1 of meerdere gebruikers aanbieden. Met een gebruiker wordt hier een bedrijf bedoeld dat de software wilt gebruiken. Wanneer men een webshop aanbiedt, wordt hier met gebruiker de winkeluitbater bedoeld, ook al heeft die winkeluitbater zelf gebruikers van zijn webshop. Deze laatste zullen hier webshop-bezoekers genoemd worden. De klant is hier dan de software-ontwikkelaar die zijn software bij de PaaS provider plaatst. Omdat de naamgeving soms verwarrend kan overkomen, wordt ze samengevat in Figuur 3.1.

3.2 Configuratie Management

22

PaaS Pro vider

KLANT So ftware o ntwikkelaar biedt websho p-software aan

GEBRUIKER Bedrijf dat websho p wil

WEBSHOP-BEZOEKER Perso nen die aanko pen do en via de webwinkel

Figuur 3.1: De benaming van de verschillende belanghebbenden

Op ASP moeten verschillende applicaties kunnen draaien. Daarvoor zijn er ASs en databankservers nodig die automatisch geconfigureerd worden naar wens van de klant. Het automatisch configureren wordt gedaan met behulp van configuratie management, dat besproken wordt in sectie 3.2. Omdat we snel en automatisch nieuwe servers willen inzetten, is er nood aan een IaaS systeem. Hierop kunnen dan virtuele machines worden gemaakt die ingezet worden als applicatie- of databankserver. Meer over IaaS vindt u in sectie 3.3. Hoe die ASs en databankservers dan exact worden ingezet en hoe daarop applicaties worden uitgerold, wordt besproken in sectie 3.4. Figuur 3.2 geeft een high-level overzicht van de complete architectuur.

3.2

Configuratie Management

Configuratie management is erg belangrijk om een complexe architectuur beheerbaar te houden. Het kan op verschillende vlakken ingezet worden: De IaaS configureren en beheren: Op die manier moet niet elk onderdeel afzonderlijk

geconfigureerd worden en kan de IaaS gemakkelijk uitgebreid worden met extra nodes.

3.2 Configuratie Management

23

Applicaties Applicaties Applicaties

Applicatio n Applicatio n Servers Applicatio n Servers Servers

Databank Databank Servers Databank Servers Servers

Mo nito ring Server

Co nfiguratio n Management

IaaS

Hardware

Figuur 3.2: De verschillende blokken van de architectuur De verschillende virtuele instanties beheren die opgezet worden voor de PaaS. Zo kunnen

er volledig geautomatiseerd nieuwe virtuele instanties aangemaakt worden, die dan zonder enige input worden geconfigureerd tot een applicatie server of databank server. Wanneer er specifieke informatie over klanten aan de Chef node worden toegevoegd, wordt die automatisch geconfigureerd naar wens van de klant. Ondersteunende diensten zoals monitoring systemen. Deze diensten zijn niet verplicht,

waardoor ze niet opgenomen zijn in de architectuur. Bij faling van een node, kan de configuratie opnieuw toegepast worden en zo de node

herstellen. Bij hardwareproblemen kan de configuratie overgezet worden naar een nieuwe node. Gebruik maken van configuratie management heeft een aantal voordelen ten opzichte van het gebruik maken van aangepaste images: Images updaten is vrij omslachtig: Ze moeten eerst worden gemount, dan geconfigureerd

en daarna ge¨ upload. Updates toepassen op gecentraliseerde configuratie is daarentegen gemakkelijk. Configuratie management zorgt voor centraal beheer, hierdoor blijft het overzicht bewaard

als er honderden verschillende configuraties gebruikt worden. Daardoor is het mogelijk per klant wijzigingen aan te brengen in de configuratie, terwijl het beheren van tientallen

3.3 Infrastructure as a Service

24

images al vrij veel werk vergt. Er zijn wel een aantal images beschikbaar, maar deze zullen meestal niet voldoen aan

de eisen. Hierop verder bouwen is ingewikkelder dan verder bouwen op de duizenden bestaande configuratiepakketten.

3.3

Infrastructure as a Service

Om alle onderdelen van ASP te plaatsen, werd er gekozen om een IaaS te gebruiken. Dit heeft verschillende voordelen: De fysieke infrastructuur wordt geabstraheerd: Er moet geen rekening gehouden worden

met welke hardware er beschikbaar is en er kunnen gradueel servers bijgeplaatst of vervangen worden, zonder dat daarvoor ingrijpende veranderingen nodig zijn in het systeem. Elke klant die gebruik maakt van ASP kan zijn eigen afgeschermde virtuele instanties

hebben. De beveiliging wordt zo verschoven van de configuratie van de applicatieserver en databankserver naar de configuratie van de IaaS. Op deze manier kunnen klanten elkaar ook niet nadelig be¨ınvloeden op vlak van prestaties. De invloed hiervan op vlak van performance wordt later in deze masterproef nog onderzocht. Wanneer er zich hardwarematige problemen zouden voordoen, is het gemakkelijk om een

recente snapshot van een virtuele machine te starten op een ander deel van het systeem. Zo wordt de down time veel kleiner bij storingen. Elke virtuele instantie kan afzonderlijk gemonitord worden. Dit maakt het gemakkelijker

om te beslissen of er geschaald moet worden.

3.4

Applicaties

Zoals gezegd zijn er om een applicatie van een klant uit te rollen ASs en databankservers nodig. In deze masterproef richten we ons op Java EE 6 programma’s, omdat deze vaak gebruikt worden in grote bedrijven. De meeste technieken zijn evenwel ook toe te passen op platformen als bijvoorbeeld die van Microsoft.

3.4 Applicaties

25

Er werd ook gekeken naar OSGi applicaties, aangezien OSGi ervoor zorgt dat elke applicatie in veel kleine modules wordt opgedeeld. Het zou dan interessant zijn om de verschillende modules apart te schalen. Maar na een aantal applicaties te bekijken, zoals iDempiere, bleken er nog geen interessante of stabiele use cases te bestaan. Momenteel wordt OSGi vooral gebruikt in middleware en dergelijke, zoals het PaaS systeem WSO2. De applicatie zal met behulp van het configuratie management automatisch worden uitgerold: de applicatie zal toegewezen worden aan één of meerdere ASs en een databank server, waarna deze automatisch op die systemen geconfigureerd zullen worden.

3.4.1

Application Server

Om de applicaties van de klanten te kunnen draaien, is er een application server (AS) nodig. Deze zal een framework ter beschikking stellen, met ondersteuning voor bijvoorbeeld beveiliging, databank verbindingen, fail-over en load balancing. De voorgestelde architectuur gaat er vanuit dat elke klant minstens één eigen virtuele instantie heeft met daarop enkel de application server. Bij het bespreken van het schalen van de applicatie server, zullen er meerdere virtuele instanties worden ingezet. In deze masterproef bespreken we echter niet het geval waarbij één applicatie server meerdere applicaties aanbiedt. Wanneer de belasting van de applicatie zo groot is dat er meerdere AS nodig zijn, kunnen deze AS op verschillende manieren worden opgesteld. Zoals al gezegd in hoofdstuk 2 wordt momenteel de applicatie server bij hoge load gedupliceerd en geclusterd. Een load balancer zorgt er dan voor dat beide AS evenredig belast worden, terwijl het clustering mechanisme er voor zorgt dat sessie-data bekend is voor elke AS. Dit model wordt weergegeven in Figuur 3.3. De load balancer kan in één of meerdere applicatie server instanties ge¨ıntegreerd worden, of kan een in een aparte virtuele instantie worden ondergebracht. Deze kan uiteraard ook gedupliceerd worden zodat er geen single point of failure is. Echter wordt er vermoed dat er prestatiewinst mogelijk is door de applicatie op een fijnschaligere manier te schalen, namelijk op het niveau van EJB’s. Hierbij zou niet de volledige applicatie gedupliceerd worden, maar slechts een beperkt aantal EJB’s. Figuur 3.4 toont hoe deze opstelling er uit zou zien. EJB’s kunnen dan in een cluster gezet worden, waardoor aanvragen verdeeld worden onder de EJB’s. Vaak opgeroepen EJB’s, of EJB’s die taken uitvoeren die veel resources

3.4 Applicaties

26

Lo ad balancer

Applicatie

Applicatie

Applicatie

Applicatio n Server

Applicatio n Server

Applicatio n Server

Application Server Instance



Figuur 3.3: De klassieke manier om AS te schalen

nodig heeft van de AS zouden zo vaak gedupliceerd worden, terwijl lichtere EJB’s slechts één of enkele malen aanwezig zouden zijn. Een systeem die dit toelaat, zou gebruik moeten maken van een geavanceerd clusteringsalgoritme dat EJB’s die vaak met elkaar interageren identificeert. Zo zouden die EJB’s altijd samen op AS kunnen geplaatst worden. Ook zou er een monitoring systeem nodig zijn die de EJB’s elk apart in de gaten houdt, opdat beslist kan worden welke EJB geschaald moet worden.

Applicatie EJB1 EJB1 pro xy EJB2

EJB2 EJB2 pro xy

EJB1

EJB3

EJB3 EJB3 pro xy

JBo ss AS

JBo ss AS

JBo ss AS

Application Server Instantie



Figuur 3.4: De fijnschaligere schaalmethode voor AS

3.4 Applicaties

27

AS

AS

Applicatio n Server VM


Databank AS

Databank


Databank VM

Databank Databank

X3

AS

Databank


Databank VM

AS


Databank VM

(a) Shared Nothing

AS

AS



(b) Shared Instance

(c) Shared Table

Figuur 3.5: Databank multi-tenancy modellen gebruikt in deze masterproef: Bij Shared Nothing heeft elke klant één databank server, terwijl er bij Shared Instance en Shared Table één databank server gedeeld wordt.

3.4.2

Databank

Applicaties maken gebruik van applicatie data en gebruikersdata. Applicatie data is bijvoorbeeld de vertalingen en menu-structeren. Data die wordt ingegeven door de gebruiker valt onder gebruikersdata, zoals producten in een webshop, klantgegegevens en bestellingen. Het is duidelijk dat gebruikersdata niet gedeeld mag worden tussen verschillende gebruikers. Al deze data worden opgeslagen in een databank, welke op verschillende manieren kan worden aangeboden. In Sectie 2.3 werden al 3 modellen ge¨ıntroduceerd. Deze modellen worden voor deze masterproef aangepast zodat er nooit een databankcluster vereist is. Deze opstellingen worden voorgesteld in Figuur 3.5: Shared Nothing: Elke applicatie zijn eigen virtuele instantie met daarop een databank. Shared Instance: Er wordt 1 grote databankserver opgezet, op welke dan voor elke klant

1 databank wordt aangemaakt. Shared Table: Ook hierbij wordt er gebruik gemaakt van 1 grote databankserver, maar

hier worden voor elke klant ook dezelfde databank en tabellen gebruikt. Elke record bevat een veld dat aangeeft bij welke klant die hoort. Sharding wordt niet meegenomen in de vergelijking, aangezien deze op heel veel verschillende manieren opgesteld kan worden. Zo is Shared Table een geval van sharding waarbij elke gebruiker op dezelfde server werkt en Shared Nothing het geval waarbij er gesplitst wordt op basis van de

3.4 Applicaties

28

gebruiker en wordt elke gebruiker op een aparte server gezet. Sharding zal meestal met minder extreme opsplitsingen werken, maar door de extreemste modellen met elkaar te vergelijken, kan er mogelijks beter onderzocht worden welke sharding strategieën efficiënt zijn.

USE CASE

29

Hoofdstuk 4

Use case 4.1

Inleiding

Om de verschillende strategieën te testen die mogelijk zijn binnen ASP, werd er naar een applicatie gezocht waarmee alle doelstellingen bereikt kunnen worden. Er werd dus gezocht naar een zo realistisch mogelijke use case zodat de resultaten onmiddellijk relevant zijn. Eerst werd er gekeken naar verschillende Enterprise Resource Planning (ERP) en Customer Relationship Management (CRM) systemen, zoals Openbravo, JFire, ADempiere en iDempiere. Deze zouden een realistische belasting opleveren voor de applicatie en databank servers en voorzagen in heel wat diverse functionaliteiten. Echter werd vlug duidelijk dat deze software pakketten erg complex zijn. Zo bleek het erg moeilijk om de pakketten aan te passen of uit te breiden en waren er erg veel dependencies tussen de verschillende modules. Dit alles maakt het ook erg moeilijk om het systeem goed genoeg te vatten om zo correcte metingen te kunnen uitvoeren. Daarom werd naar een andere use case gezocht met een doorzichtigere architectuur die toch gebruik maakt van het Java EE framework. Uiteindelijk werd er voor Duke’s Forest gekozen, een project dat deel uit maakt van de The Java EE 6 Tutorial. Duke’s forest is een internetwinkel, waardoor er onmiddellijk realistische scenario’s beschikbaar zijn, terwijl de applicatie toch een beheersbare grootte heeft. De applicatie wordt in de volgende Sectie uit de doeken gedaan. In Sectie 4.2.1 wordt de opbouw van de applicatie besproken, in Sectie 4.2.2 worden de gebruikte functionaliteiten bekeken en in Sectie 4.2.3 worden dan de aanpassingen beschreven die gedaan zijn voor deze masterproef.

4.2 Duke’s Forest

4.2

30

Duke’s Forest

Duke’s Forest is een internetwinkel die, zoals gezegd, gebruikt wordt als use case in The Java EE 6 Tutorial. Het maakt dus zoals verwacht gebruik van het Java EE 6 framework. Een internetwinkel is een ideale use case, aangezien die vaak gebruikt worden en zowel door kleine als grote organisaties wordt ingezet. Figuur 4.1 toont een screenshot van de winkel.

4.2.1

Opbouw

Het project bestaat uit verschillende onderdelen, om zoveel mogelijk functionaliteit van het framework te tonen. Zo is er een webwinkel, een webapplicatie om de de verzending van de bestellingen te regelen en een betalingsservice. Voor deze masterproef werd enkel de functionaliteit gebruikt die een klant van de webshop nodig zou hebben, aangezien dit het deel is waar schalen erg belangrijk is. Daarom wordt er enkel gebruik gemaakt van de Duke’s Store package. Deze bestaat uit een web interface, Enterpise Java Beans (EJB) en Entities. De EJBs zullen de onderdelen zijn die dynamisch geschaald worden in hoofdstuk 7.

4.2.2

Functionaliteiten

De webshop heeft onder andere volgende functionaliteiten: Registreren en inloggen Aankopen doen Uw aankopen bekijken

Deze functionaliteiten zullen gebruikt wanneer de verschillende schaalmethodes vergeleken worden. Daarom worden ze hieronder elk apart besproken.

Registreren en inloggen 1. Surfen naar de homepage, index.xhtml wordt gerendered 2. Klikken op ”Register”, customer/Create.xhtml wordt gerendered 3. Formulier met klantgegevens verzenden

4.2 Duke’s Forest

31

Figuur 4.1: Screenshot van de J2EE use case “Duke’s Forest”: Deze webwinkel zal gebruikt worden om de verschillende schaalmethodes te vergelijken.

Duke's Store Web interface JavaServer Faces

Enterprise Java Beans

Entities Java Persistence API

Figuur 4.2: Architectuur van de Java EE 6 use case “Duke’s Forest”: De webinterface verzorgt de webpagina’s, de EJBs zorgen voor de interactie tussen de webpagina’s en de entities. Die entities worden m.b.v. het JPA framework uit de databank gehaald.

4.2 Duke’s Forest

32

(a) POST request naar customer/Create.xhtml (b) Gaat naar de CustomerController create functie waar het wachtwoord gehasht wordt. (c) De UserBean maakt een nieuwe klant aan (d) De customer/Create.xhtml pagina wordt getoond met de melding dat de klant succesvol is geregistreerd 4. Gebruikersnaam en wachtwoord invullen bovenaan de pagina en verzenden (a) POST request naar customer/Create.xhtml (b) Gaat naar de UserController login functie, waar de gebruikersnaam en wachtwoord gecontroleerd worden binnen het security domain van de J2EE container. (c) Indien de gegevens correct zijn, wordt het volledige User model opgehaald via de UserBean. (d) De gebruiker wordt doorverwezen naar index.xhtml

Aankopen doen 1. Registreren en inloggen zoals hierboven besproken. 2. Klikken op “List Products”, dit geeft een lijst met categorieën (a) product/ListCategory.xhtml wordt gerendered (b) Hiervoor worden de categorieën opgehaald met de functie getItems van de CategoryController, die de CategoryBean aanroept. 3. Een categorie aanklikken (a) product/List.xhtml?categoryId=ID wordt gerendered (b) De ProductController haalt de producten op uit de categorie door de ProductBean op te roepen. 4. Bij een product op “Add to basket”klikken (a) POST request met daarin de productid (b) De functie addItem van ShoppingCart wordt aangeroepen

4.2 Duke’s Forest

33

(c) Een conversation wordt opgestart, waardoor het winkelmandje bewaard blijft (d) Het product wordt opgehaald met de ProductBean en wordt in het winkelmandje geplaatst 5. Op “Checkout”klikken (a) POST request met als GET parameter de conversation-id (cid) (b) De functie checkout van ShoppingCart wordt aangeroepen (c) Een nieuwe CustomerOrder wordt aangemaakt, en per product een OrderDetail. Die customerorder wordt dan met zijn OrderDetails bewaard door de OrderBean (d) Er wordt een melding weergegeven dat de aankoop gelukt is.

Uw aankopen bekijken 1. Inloggen zoals hierboven besproken 2. Klikken op “Orders” (a) order/MyOrders.xhtml wordt gerendered (b) De orders worden opgehaald doormiddel van de CustomerOrderController, die de OrderBean aanroept. (c) De orders worden opgehaald uit de databank zonder de OrderDetails.

4.2.3

Aanpassingen

Om een nog zwaardere belasting te verkrijgen op de databank servers, zijn er nog een aantal extra functionaliteiten toegevoegd. Ook zijn enkele pagina’s toegevoegd om ingewikkelde POST requests af te handelen met een simpele GET request. Dit zijn de wijzigingen: order/MyOrders.xhtml toont ook een lijst met de som van prijs van de aankopen, gegroe-

peerd per maand. order/MyOrdersPDF.xhtml zal ook de OrderBean vragen een PDF te maken met het

overzicht van de bestellingen. Deze PDF wordt opgeslagen in een tijdelijke map, en wordt onmiddellijk terug verwijderd.

4.2 Duke’s Forest

34

product/Checkout.xhtml werd toegevoegd, waarmee met een simpele GET request het

huidige winkelmandje wordt ingediend. De conversation-id moet wel als GET parameter toegevoegd worden. product/View.xhtml werd aangepast zodat het product dat bekeken wordt ook automa-

tisch wordt toegevoegd aan het winkelmandje. Op deze manier hoeft er opnieuw geen POST request meer te gebeuren om producten toe te voegen aan het mandje.

IMPLEMENTATIE

35

Hoofdstuk 5

Implementatie 5.1

Inleiding

De proefopstelling bevat heel wat verschillende lagen. Zoals aangegeven in de architectuur is ASP van de grond af aan opgebouwd. Op deze manier kan er ingegrepen worden op alle niveaus. Zo kunnen er gemakkelijk nieuwe testopstellingen opgezet worden zonder restricties en kunnen er op alle niveaus meetwaarden verzameld worden. De opbouw van de implementatie wordt weergegeven in Figuur 5.1. Chef wordt gekozen als configuratie management pakket. Hoe Chef opgesteld wordt, staat in de volgende sectie. Als IaaS pakket wordt er voor Eucalyptus gekozen. Die opstelling wordt door middel van Chef gedaan. Hoe dit in zijn werk gaat, staat in sectie 5.3. De daaropvolgende sectie gaat over de implementatie van ASP. Die bestaat uit verschillende onderdelen, zoals application servers, waarvoor JBoss AS gebruikt wordt, databank servers met MySQL, een monitoring service, aangedreven door Zabbix en een zelfgemaakte frontend. Daarna wordt besproken hoe de verschillende opstellingen kunnen getest worden met WebLoadUI. Dit alles draait op de hardware van de Virtual Wall. Op het einde van dit hoofdstuk wordt nog kort besproken welke aanpassingen er nodig zijn om dit allemaal ge¨ımplementeerd te krijgen op de Virtual Wall.

5.2 Configuratie Management: Chef

36

Applicaties Applicaties Duke's Fo rest

Applicatio n Applicatio n Servers Servers JBo ss

Databank Databank Servers Servers

Zabbix

Eucalytpus

Virtual Wall

Figuur 5.1: De verschillende blokken van de architectuur

5.2

Configuratie Management: Chef

Zoals gezegd werd er gekozen om Chef te gebruiken voor het configuratiebeheer. Dit omdat er heel gemakkelijk eigen recipes kunnen gemaakt worden in Ruby en er al ervaring met Ruby was. De cookbooks en roles die gebruikt zijn voor deze masterproef worden later nog besproken in de secties waarin ze toegepast worden. Er werd gekozen om de klassieke Chef opstelling te gebruiken, met een Chef Server en een Chef Workstation. Deze twee systemen worden automatisch geconfigureerd met bash scripts, terwijl de overige systemen door Chef geconfigureerd kunnen worden. Op de Chef Server worden alle configuratiegegevens, cookbooks en roles bewaard. Vanop de Chef Workstation wordt de volledige testopstelling beheerd. Hierop worden de Chef tools genstalleerd, zoals Knife. Doordat de overige systemen beheerd worden door Chef, blijf het overzicht behouden over de complexe opstelling. Vooral de flexibiliteit is een noodzaak om een dergelijke architectuur te onderhouden.

5.2.1

Chef Server

Zoals hierboven aangegeven, zal de Chef Server alle data bewaren over de configuratie: node attributes, cookbooks, roles... Wanneer een beheerde node dan Chef Client opstart, zal deze contact opnemen met Chef Server om deze gegevens op te halen. Deze computer wordt geconfigureerd door middel van het installChefServer.sh script. De installatie kan volledig geautomatiseerd worden met behulp van debconf-set-selections. De validatie sleutel die aangemaakt wordt tijdens de installatie moet gebruikt worden wanneer er

5.2 Configuratie Management: Chef

37

interactie is met de Chef Server. Deze wordt daarom gekopieerd naar een map die toegankelijk is voor de Chef Workstation. Ook wordt er een API client aangemaakt met Knife, die daarna gebruikt zal worden door de Chef Workstation. Het script bevat nog heel wat andere zaken om alles compatibel te houden met de Virtual Wall, maar dit wordt besproken in sectie 5.5.

Chef Server: Co o kbo o ks, roles, no des, clients, databags, alle attributes

Chef Client

Chef Server

No des

Co nfiguratio n management: Knife

Git repository: co o kbo oks, roles

Wo rkstatio n

Figuur 5.2: Chef opstelling: Chef Server met alle configuratie-gegevens en Chef Workstation die een node configureert met Knife.

5.2.2

Chef Workstation

De Workstation zal dan zoals hierboven aangegeven met behulp van Knife communiceren met de Chef Server. Zo kunnen er bijvoorbeeld nieuwe cookbooks ge¨ upload worden en node attributes aangepast worden. Het is ook vanaf deze computer dat de bootstraps zullen gebeuren. Zo worden de systemen zonder enige interactie geconfigureerd naar gelang hun toegewezen roles. Deze computer wordt ook met een script geconfigureerd, met de toepasselijke naam installChef-

5.3 IaaS Platform: Eucalyptus

38

Workstation.sh. De Chef Workstation wordt daarmee ge¨ınstalleerd met het installatiescript dat Opscode, het bedrijf achter Chef, ter beschikking stelt. Daarna worden nog een aantal extra gems ge¨ınstalleerd die nodig zijn voor Knife Eucalyptus, de plugin van Knife die functionaliteit voor Eucalyptus toevoegt. Met dit script wordt ondertussen ook de frontend ge¨ınstalleerd. Op de Chef Workstation is een lokale Git repository aanwezig, met daarin alle cookbooks en roles. Deze worden dan ge¨ upload naar de Chef Server met de commando’s knife cookbook upload -a knife role from file / path / to / role . rb Bij het bootstrappen met Chef moeten wel 2 zaken opgemerkt worden: De login-shell mag niet tcsh zijn, aangezien die geen multi-line commando’s ondersteunt.

Tijdens het bootstrappen wordt hiervan gebruik gemaakt bij het doorgeven van de commando’s. Chef bootstrap ondersteunt standaard geen CentOS distributies. Hiervoor is een bestaand

bootstrap script aangepast.

5.2.3

Chef Client

Nodes die beheerd worden door chef, bevatten Chef Client. Deze wordt ge¨ınstalleerd tijdens het bootstrappen. Op dat moment worden ook roles en cookbooks gekoppeld aan de node. Wanneer er later attributes van een node, een role of een cookbook worden aangepast, zal Chef die wijzigingen doorvoeren op de node. Dit gebeurt automatisch indien de chef-client service draait, maar wegens het vrij hoge geheugenverbruik wordt in deze implementatie chef-client handmatig opgeroepen.

5.3 5.3.1

IaaS Platform: Eucalyptus Overzicht

Het IaaS platform wordt opgezet met Eucalyptus 3.1. Dit was de nieuwste versie toen het IaaS platform voor het eerst werd opgezet en zoals opgemerkt in Sectie 2.5.1, kan er niet eenvoudig ge¨ upgraded worden naar een nieuwere versie. Er werd gekozen voor Eucalyptus omdat deze volledig compatibel is met de Amazon Web Services. Hierdoor kunnen de testopstellingen die


39

gemaakt zijn, nagebouwd worden in de Amazon cloud en is het resultaat van deze thesis sneller toepasbaar in commerciële toepassingen. De opstelling bestaat uit twee grote delen: Enerzijds heb je de PrivateCloudController, die het IaaS platform beheert, anderzijds zijn er de NodeControllers, waarop de virtuele instanties draaien. Voor de NodeControllers werd er gebruik gemaakt van servers met vier Intel Xeon E5520’s en 12 GB geheugen. Anderzijds wordt de ChefWorkstation ook ingezet om als DNS server dienst te doen voor de virtuele instanties. Dit is gevisualiseerd in Figuur 5.3. Hieronder wordt eerst beschreven hoe dit ge¨ınstalleerd wordt, daarna volgt een sectie hoe dit systeem gebruikt kan worden.

5.3.2

Installatie

Zoals hierboven gesteld, bestaat de opstelling uit twee type systemen: één PrivateCloudController en verschillende NodeControllers. De PrivateCloudController bevat zowel de Eucalyptus Cloud Controller, Cluster Controller en Walrus, terwijl de NodeControllers enkel de Eucalyptus Node Controller bevatten. Deze elementen, besproken in Sectie 2.5.1, worden allemaal ge¨ınstalleerd en geconfigureerd door Chef. De cookbook die hiervoor is aangemaakt, is gebaseerd op de Eucalyptus 2 cookbook van Nat Lownes, maar is aangepast zodat hij compatibel is met Eucalyptus 3 en de Virtual Wall. De Cloud Controller krijgt de role Eucalyptus toegewezen, samen met de recipes eucalyptus::cloud controller install en eucalyptus::storage install, terwijl de Node controllers de role Eucalyptus samen met de recipe eucalyptus::node controller install krijgt toegewezen. Een voorbeeld hoe de Eucalyptus role kan aangepast worden aan de omgeving wordt getoond in Codefragment 5.1. Een aantal zaken zijn nog niet in de cookbook geplaatst, maar worden nog manueel gedaan, zoals het ophalen van de authenticatiesleutels, het toevoegen van images en het toevoegen van de firewall regels. Die firewall regels zorgen ervoor dat de PrivateCloudController ook gebruikt kan worden als gateway voor alle virtuele instanties. Op deze manier kunnen alle virtuele instanties zowel interne als externe machines bereiken.


40

Codefragment 5.1: Local Eucalyptus Role name " eucalyptus " overr id e _ at t r i bu t e s ( : euca = > { : install = > {: version = > " 3.1.4 " } , : user = > ' eucalyptus ' , : hypervisor = > ' kvm ' , : cluster_name = > ' cluster1 ' , : front_end = > ' nodea ' , : compute_nodes = > % w ( node1v -1 node1v -2 ) , : s t o ra g e _c o n tr o l le r s = > % w ( nodea ) , : walruses = > % w ( nodea ) , : instance_path = > " / var / lib / eucalyptus / instances " , : nc = > { : work_size = > 105000 , : cache_size = > 20480 }, : network = > { : front_end = > { : pub_interface = > ' eth0 ' , : priv_interface = > ' eth4 ' , }, : node = > { : pub_interface = > ' eth0 ' , : priv_interface = > ' eth4 ' , }, : vnet = > { : mode = > ' STATIC ' , : netmask = > ' 255.255.255.0 ' , : broadcast = > ' 10.1.1.255 ' , : router = > ' 10.1.1.4 ' , : dns = > ' 10.1.1.3 ' , : public_ips_start = > ' 10.1.1.150 ' , : public_ips_end = > ' 10.1.1.200 ' } }, # make sure your keys are formatted correctly here . # 64 chars / line : ssh_private_key = > " ----- BEGIN RSA PRIVATE KEY - - - - [ PrivateKey ] ----- END RSA PRIVATE KEY - - - - - " , : ssh_public_key = > " ssh - rsa ... [ Public Key ] " } ) Zoals aangegeven in Sectie 2.5.1 ondersteunt Eucalyptus vier netwerktypes. De testopstelling


41

gebruikt de STATIC methode, aangezien deze gemakkelijk in te stellen is door de beperkte functionaliteit, terwijl er geen extra services toegevoegd moeten worden aan de testopstelling. De DNS server die toegevoegd is, is niet noodzakelijk, maar wordt enkel gebruikt omdat er zo met subdomeinen naar applicaties kan verwezen worden en het die dus niet wijzigen indien een virtuele machine vervangen wordt. Die DNS server wordt opgezet tijdens het uitvoeren van installChefWorkstation.sh. Als hypervisor wordt er KVM gebruikt. KVM kan enkel gebruikt worden indien de processor virtualisatie instructies ondersteund. Voor Intel is dit de Intel VT extensie, voor AMD de AMDV extensie. Deze moeten ook ingeschakeld worden in de BIOS en enkele kernelmodules moeten geladen worden. Voor Intel processors is dit kvm en kvm-intel, terwijl dit voor AMD processors kvm en kvm-amd wordt. Nadat deze modules zijn ingeladen moet ook libvirt-bin herstart worden. De cookbook is aangepast zodat automatisch de correcte modules worden ingeladen en libvirtbin herstart wordt, maar veronderstelt wel dat de functionaliteit aanwezig is en ingeschakeld is in het BIOS. Een andere pitfall: standaard maakt Eucalyptus 3.1 geen gebruik van de Virtio netwerk driver. Wanneer deze niet is ingeschakeld, zijn de netwerksnelheden van de virtuele instanties erg laag. Na het inschakelen door USE VIRTIO NET op 1 te zetten in eucalyptus.conf krijgt men veel betere prestaties. Deze instelling wordt standaard gebruikt vanaf Eucalyptus 3.3. De virtuele instanties die draaien op de IaaS zijn gebaseerd op een CentOS 6.3 image die ge¨ updatet is en een aantal extra packages bevat. Op die manier kunnen nieuwe instanties vlug ge¨ınstantieerd en gebootstrapt worden. Toch werden de images zo klein mogelijk gehouden, om een zo klein mogelijke overhead te creëren. Er werd geen gebruik gemaakt van Ubuntu Server Images, omdat deze incompatibel waren met Eucalyptus 3.1. In Eucalyptus 3.2 zouden die zonder aanpassingen moeten werken. CentOs 6.3 gebruikt standaard nog Ruby 1.8. Chef ondersteunt die nog, maar momenteel staat er nog een bug open die het verhindert om nodes te bootstrappen met Ruby 1.8. Er is al een fix beschikbaar, maar die zal pas in Chef 11.6.0 gebruikt worden. Daarom moet in knife.rb de variabele knife[:bootstrap version] op 11.4.2 vastgezet worden, totdat de nieuwe versie beschikbaar is.

5.4 Eigen PaaS Platform: ASP

5.3.3

42

Gebruik van de IaaS

Om de cloud te beheren zijn er enkele authenticatiesleutels nodig en moeten enkele shell variabelen ingesteld worden. De sleutels kunnen samen met het bestand eucarc, dat de variabelen bevat, opgevraagd worden met het commando sudo / usr / sbin / euca_conf -- get - credentials admin . zip Wanneer men die zip uitpakt, en source eucarc uitvoert, kan men de verschillend eucacommando’s uitvoeren, zoals euca-describe-availability verbose

Geef de beschikbare resources weer

euca-create-keypair

Maak een sleutelpaar aan, om hiermee later in virtuele instanties te kunnen inloggen

euca-run-instances

Maak een nieuwe virtuele instantie aan, aan de hand van een image

euca-terminate-instances

Stop en verwijder de opgegeven virtuele instanties

euca-describe-instances

Toon alle virtuele instanties

euca-describe-images

Toon alle beschikbare images.

Wanneer men een nieuwe instantie aanmaakt, moet men een keypair opgeven, waarmee dan ingelogd kan worden op de instantie. Omdat er bij deze opstelling altijd hetzelfde sleutelpaar gebruikt wordt, is er een bash alias aangemaakt sshi die overeen komt met ssh -i

$experiment folder/my-keypair.private. Een andere tip is het uitschakelen van het opslaan van host keys binnen de IP range van de virtuele instanties. Tijdens het starten en stoppen van virtuele instanties, zullen namelijk IP adressen die eerst vrijgegeven zijn, terug toegewezen worden aan nieuwe instanties. Wanneer men dan ssh’t naar die instantie, zal de host key aanwezig in .known hosts foutief zijn.

5.4 5.4.1

Eigen PaaS Platform: ASP Application Server: JBoss AS

De testopstelling vereist een Application Server die Java EE applicaties kan draaien. Er is gekozen voor de JBoss Application Server wegens de schaalbaarheid, kleine overhead en on-


43

dersteuning voor clustering. Deze AS heeft zich ook al bewezen in commerciële omgevingen, waardoor we opnieuw de resultaten onmiddellijk zullen kunnen relateren aan real-life situaties. De AS wordt ge¨ınstalleerd door middel van een cookbook die geschreven is voor deze masterthesis. Deze downloadt JBoss, plaatst die in een gekozen map en wijzigt de configuratie naar gelang de gekozen instellingen. Er wordt telkens gebruik gemaakt van aparte virtuele instanties om JBoss te draaien. Die maken we aan door met Knife een nieuwe instantie aan te maken met de appserver role: knife euca server create -r ' role [ appserver ] ' -I [ IMAGE ] -- flavor [ TYPE ] -- ssh - key my - keypair -d centos6 - gems -N [ NODENAME ] -i / path / to / my - keypair . private Waarbij [IMAGE] het identificatienummer is van de image die gebruikt moet worden als basis en [TYPE] aangeeft wat voor virtuele instantie moet aangemaakt worden op vlak van cpu cores, geheugen en harde schijf grootte. Dit type hangt af van de test, en zal bij elke test vermeld worden. De appserver role bevat ook de dukesforest::appserver recipe, die de MySQL driver installeert, de datasource configureert aan de hand van de node attributes en de WAR bestanden van Duke’s Forest deployt. Indien er een andere applicatie moet ge¨ınstalleerd worden, moet gewoon naar een ander recipe verwezen worden. Aangezien er in de Java EE 6 Tutorial met GlassFish wordt gewerkt, waren er een aantal aanpassingen noodzakelijk in Duke’s Forest om het uit te rollen op JBoss. Zo moest bijvoorbeeld het security domain aangegeven worden in jboss-web.xml en werd de datasource gedefinieerd met jboss-cli in plaats van gebruik te maken van het glassfish-resources.xml bestand.

5.4.2

Databank server: MySQL

Als databankserver werd MySQL gebruikt. Opnieuw werd er gekozen voor een gratis te gebruiken pakket dat gebruikt wordt in commerciële omgevingen. Er is al een MySQL cookbook beschikbaar, dus deze werd dan ook gebruikt. Ook hier wordt Knife gebruikt om virtuele instanties te starten en te bootstrappen met een database-instance role, deze keer met dit commando: knife euca server create -r ' role [ database - instance ] ' -I [ IMAGE ] -- flavor [ TYPE ] -- ssh - key my - keypair -d centos6 - gems -N [ NODENAME ] -i / path / to / my - keypair . private


44

Ook deze role bevat een dukesforest recipe, namelijk de dukesforest::database recipe. Deze zal kijken naar welke clients er in zijn node attributes aanwezig zijn en zal aan de hand van die gegevens de correcte mysql gebruikers en databanken aanmaken.

5.4.3

Monitoring service: Zabbix

Er is gekozen om Zabbix te gebruiken als monitoring service, aangezien deze een eenvoudige gebruikersinterface heeft, ondersteuning biedt voor MySQL monitoring en de mogelijkheid biedt om clients automatisch te laten registreren. Met Zabbix kunnen gedetailleerde gegevens verzameld worden tijdens de benchmarks die dan achteraf uit zijn databank gehaald kunnen worden. Om een vlug overzicht te krijgen, kunnen er grafieken van de verschillende parameters opgevraagd worden in de eenvoudige webinterface. Figuur 5.4 geeft een custom screen aan van Zabbix met enkele grafieken. Er wordt één virtuele instantie gebootstrapt met een Zabbix server. Daarna registreren alle virtuele instanties die een Zabbix agent bevatten zich bij die server. Daarom werd de Zabbix recipe toegevoegd aan zowel de appserver als de databank-instance role. De Zabbix server haalt dan volgende gegevens minstens één keer per minuut op van de Zabbix agents: CPU load: De gemiddelde CPU load over één en vijf minuten Vrij geheugen: Het fysieke geheugen dat momenteel vrij is netwerk throughput: Aantal bps per seconde (gemiddeld over de voorbij minuut), apart

voor het in- en uitgaand verkeer aantal queries per seconde (MySQL): gemiddeld over een halve minuut. Wordt ook apart

geregistreerd voor SELECT, INSERT en UPDATE paramters aantal table locks per seconde (MySQL): gemiddeld over een halve minuut JBoss Heap gebruik (AS): Het momenteel gebruik van de volgende onderdelen:

– Survivor space 0 – Survivor space 1 – Eden Space


45

Clo ud Co ntro ller Bind DNS Server Virtual instances

Cluster Contro ller

Walrus

Wo rkstatio n

No de Co ntrollers

Netwo rking (gateway)

Private Clo ud Co ntro ller

Figuur 5.3: Opstelling van de IaaS: De Private Cloud Controller bevat alles om de cloud te beheren en opslag aan te bieden, terwijl de Node Controllers de virtuele instanties huisvesten. De virtuele instanties maken via de Cloud Controller verbinding met internet, terwijl ze de ChefWorkstation als DNS server gebruiken.

Figuur 5.4: Custom Screen van Zabbix, waarin enkele grafieken zijn geplaatst. Dit maakt het mogelijk de verschillende systemen te monitoren tijdens de testen.


46

– Old Space Voor de MySQL metrieken moest een extra bestand worden geactiveerd, terwijl voor de JBoss metrieken een eigen extensie geschreven is die gebruik maakt van jstat. Deze zijn toegevoegd aan de Zabbix cookbook.

5.4.4

Frontend

De frontend is waar ASP aangedreven kan worden. De huidige functionaliteit beperkt zich momenteel tot een overzichtspagina met alle applicaties die momenteel opgesteld zijn en de mogelijkheid nieuwe opstellingen op te starten. Het maakt gebruik van PHP, bash en knife om de systemen te beheren. Figuur 5.5 toont hoe de frontend er momenteel uit ziet. Als men een Shared Nothing configuratie start met de frontend, zullen de stappen, weergegeven in Figuur 5.6, uitgevoerd worden: 1. In de frontend wordt Shared Nothing geselecteerd en wordt een naam en wachtwoord ingegeven. Voor testdoeleinden kan ook dezelfde opstelling meerdere keren gestart worden. 2. Wanneer het formulier verzonden wordt, wordt met PHP een bash script aangeroepen. Deze zal met behulp van Knife twee virtuele instanties starten en bootstrappen, één met de applicatie role en één met de database role. SharedNothing.sh is toegevoegd als voorbeeld in Codefragment 5.2. De andere scripts zijn analoog. 3. De Cloud Controller zal dan twee instanties starten, Chef zal genstalleerd worden op die instanties door het bootstrap script, waarna automatisch de instanties geconfigureerd worden aan de hand van hun Chef role. 4. Nadat deze twee instanties ge¨ınitialiseerd zijn, worden de IP adressen opgehaald en worden die samen met de configuratiegegevens van de webshop gekoppeld aan de Chef nodes door middel van het addClient.rb script, weergegeven in Codefragment 5.3. 5. Daarna worden de instanties opnieuw geconfigureerd met de specifieke configuratiegegevens, wat resulteert in een werkende webshop. Het adres waarop de webshop bereikbaar is, kan men vanaf dan vinden op de overzichtspagina van de frontend.


Figuur 5.5: Opzetten van een Shared Nothing optelling met behulp van de frontend

47


48

5. Because o f the new no de attributes, the servers get co nfigured correctly

Private Cloud Inst ance Chef Server: Co o kbo o ks, roles, no des, clients, databags, alle attributes

Database Instance

Clo ud Co ntro ller

Cluster Contro ller

Chef Server

Walrus

3. Beide instanties wo rden aangemaakt en gebo o tstrapt m.b.v. knife

Private Cloud Inst ance Applicatio n Server Instance

Netwo rking

4. De configuratiegegevens van de websho p wo rden to egevo egd aan de no de attributes

Private Clo ud Co ntro ller

Co nfiguratio n management: Knife

2. Start een nieuwe databank en applicatie server instantie met de co rrecte Chef ro les

Apache: PaaS Fro ntend Wo rkstatio n 1. Add Shared No thing websho p

Figuur 5.6: Opzetten van een Shared Nothing optelling met behulp van de frontend


49

Codefragment 5.2: SharedInstance.sh: Start een Shared Instance setup # !/ bin / bash # Get all variables CLIENT = $ 1 PASSWORD = $ 2 IMAGE = ` cat $ e x p e r im e n t _ f o l d e r / stdimage ` source $ e x p e r im e n t _ f o l d e r / eucarc # Bootstrap DB and AS with correct role in parallel knife euca server create -r ' role [ database - instance ] ' -I $ IMAGE -- flavor c1 . medium -- ssh - key my - keypair -d centos6 - gems -N db_ $ CLIENT -i $ e x p e r im e n t _ f o l d e r / my - keypair . private & knife euca server create -r ' role [ appserver ] ' -I $ IMAGE -- flavor c1 . xlarge -- ssh - key my - keypair -d centos6 - gems -N app_ $ CLIENT -i $ e x p e r im e n t _ f o l d e r / my - keypair . private & wait # Update node attributes of AS and DB knife exec scripts / addClient . rb db_ $ CLIENT app_ $ CLIENT $ CLIENT $ PASSWORD # Run chef - client on AS and DB knife ssh name : db_ $ CLIENT -a ipaddress -x root -i $ e x p e r im e n t _ f o l d e r / my - keypair . private " sudo chef - client " knife ssh name : app_ $ CLIENT -a ipaddress -x root -i $ e x p e r im e n t _ f o l d e r / my - keypair . private " sudo chef - client " Codefragment 5.3: AddClient.rb: Steek alle gegevens, zoals het IP van de databank server en het wachtwoord in de node attributes require ' chef / knife ' require ' chef / shef / ext ' abort ( " usage : ./ bin / knife exec #{ ARGV [1]} DB - node App - node client - username client - password " ) unless ARGV [5] begin nodeDB = nil nodeAPP = nil client = nil # get DB node nodes . find (: name = > ARGV [2]) . each do | n | nodeDB = n end if ( nodeDB == nil ) puts " Couldn ' t find DB node : #{ ARGV [2]} " exit 1 end


50

# get AS node nodes . find (: name = > ARGV [3]) . each do | n | nodeAPP = n end if ( nodeAPP == nil ) puts " Couldn ' t find APP node : #{ ARGV [3]} " exit 1 end ipDB = nodeDB [ ' ipaddress ' ] dbname = ARGV [6] ? ARGV [6] : " dukesforest " # Gather client settings client = { " name " = > ARGV [4] , " password " = > ARGV [5] , " dbhost " = > ipDB , " dbname " = > dbname } nodeDB . normal [ ' dukesforest ' ][ ' clients ' ][ ARGV [4]] = client nodeAPP . normal [ ' dukesforest ' ][ ' clients ' ][ ARGV [4]] = client nodeDB . save nodeAPP . save exit 0 rescue = > e puts " Error encountered when adding client #{ ARGV [4]}: #{ e . inspect } " puts e . backtrace . inspect end exit 0 Het opzetten van andere modellen verloopt gelijkaardig, enkel moet er bij Shared Instance en Shared Table eerst een databank server apart opgesteld worden en dan de naam van deze server meegegeven worden bij het maken van een nieuwe instantie. Eventueel mogelijke uitbreidingen zijn het toelaten om applicaties te stoppen of te schalen. Ook kan momenteel enkel de Duke’s Forest applicatie gestart worden, maar het toevoegen van functionaliteit om een eigen WAR file te uploaden samen met een Chef cookbook zou weinig extra werk vergen. Doordat er gebruik gemaakt is van Chef en Eucalyptus, is het gemakkelijk om de frontend later uit te breiden.

5.5 Hardware: Virtual Wall

5.5

51

Hardware: Virtual Wall

5.5.1

De opstelling

De hele opstelling werd uitgevoerd op de Virtual Wall van iMinds. Deze Virtual Wall is een testbed bestaande uit 200 general purpose computers, gebaseerd op emulab. Op dit testbed kunnen experimenten gedefinieerd worden waarbij computers een OS toegewezen kunnen krijgen die dan kunnen opgesteld worden in een impaired netwerk. Er is voor de Virtual Wall gekozen omdat het mogelijk is om erg snel een groot netwerk aan te leggen met tientallen nodes, om zo een groot PaaS platform te kunnen simuleren. Anderzijds blijft er de mogelijkheid om alles kleinschalig te testen. Het besturingssysteem dat gebruikt werd is Ubuntu 12.04. Daarvoor is gekozen omdat er hiermee al ervaring was en de grote community die ondersteuning biedt. De fysieke opstelling op de Virtual Wall wordt voorgesteld in Figuur 5.7.

5.5.2

Pitfalls

Tijdens het maken van de opstellingen, zijn er geregeld problemen opgedoken. Hieronder worden er een aantal opgelijst, zodat deze problemen in de toekomst gemakkelijk verholpen kunnen worden. De Virtual Wall maakt het ook mogelijk om images te maken van de verschillende opstellingen. Eerst werd er dus gedacht om voor de Chef Server en Chef Workstation een image aan te maken die al volledig geconfigureerd werden. Dit is echter niet praktisch, aangezien er tijdens de installatie van Chef een nieuwe gebruiker wordt aangemaakt, die niet meegenomen werd in de image. Daarom werd er gekozen voor geautomatiseerde installatiescripts, die besproken werden in Sectie 5.2. Waar goed op gelet moet worden bij het gebruik van de Virtual Wall is dat er een proxy nodig is om verbinding te maken met het internet. Deze moet in de volgende plaatsen ingesteld worden:

5.5 Hardware: Virtual Wall

52

knife.rb http_proxy " http :// proxy . atlantis . ugent . be :8080" https_proxy " http :// proxy . atlantis . ugent . be :8080" no_proxy "10.* , *. test , *. ilabt . iminds . be " knife [: bootstrap_proxy ] = " http :// proxy . atlantis . ugent . be :8080" knife [: bo ot st ra p_ no _p ro xy ] = "10.* , *. test , *. ilabt . iminds . be " /etc/apt/apt.conf Acquire :: http :: Proxy " http :// proxy . atlantis . ugent . be :8080"; /etc/wgetrc http_proxy = http :// proxy . atlantis . ugent . be :8080 https_proxy = http :// proxy . atlantis . ugent . be :8080 Git kan geconfigureerd worden met dit commando: / usr / bin / git config -- global http . proxy http :// proxy . atlantis . ugent . be :8080 Om een gem te installeren, moet de proxy meegegeven worden met het --http-proxy argument. Het vervelende is dat deze proxy niet gebruikt mag worden bij lokale URL’s. Knife heeft hiervoor de variabele no proxy en knife[:bootstrap no proxy], maar dit werkt niet bij alle commando’s. Daarom werden sommige cookbooks aangepast met extra instructies om geen proxy te gebruiken. Het werken met de Virtual Wall heeft als voordeel dat de home directory standaard gemount wordt op een persoonlijke NFS map. Op die manier wordt automatisch de Knife configuratie, de Chef authenticatiesleutels en de Eucalyptus configuratie gedeeld over alle computers. Dit is een ideale opstelling wanneer er slechts één project tegelijk loopt. Bij het uitvoeren van de testen werden er echter 3 opstellingen naast elkaar gebruikt. Hierdoor werden configuratiebestanden overschreven, aangezien dezelfde home directory gebruikt wordt. Dit is opgelost door de configuratiebestanden te plaatsen in de NFS map van het experiment zelf. Tijdens de installatiescripts worden de variabelen $experiment en $experiment folder aangemaakt, zodat men gemakkelijk aan de verschillende configuraties kan. Het enige configuratiebestand dat wel nog in de home directory staat, is knife.rb, maar dat wordt automatisch aangepast zodat de laatstgenoemde variabelen gebruikt worden. Ook moet men weten dat de Virtual Wall standaard maar een deel van de harde schijf formateert. Hierdoor is er snel plaats te kort op de CLC met zijn images en de NCs met de virtuele instanties.

5.6 Benchmarking: WebLoadUI

53

Daarom zal de cookbook ook een tweede partitie aanmaken en daarop enkele mappen mounten, waaronder /tmp. Een laatste pitfall is het netwerkgedeelte: De Virtual Wall stelt de netwerk interfaces in door gebruik te maken van een hack in /etc/network/interfaces. Hierdoor is het niet mogelijk dit bestand aan te passen. Dit is de reden dat de netwerk bridge die nodig is voor de Node Controllers wordt aangemaakt door een script dat gebruik maakt van brctl. Deze bridge moet bij elke reboot uitgevoerd worden, aangezien /etc/network/interfaces niet aangepast mag worden. Een ander probleem is het feit dat de namen van de netwerk interfaces kan veranderen. Dit wordt opgelost door in het script eerst met behulp van ifconfig te kijken welke interfaces een IP adres hebben binnen het gewenste subnet. Het script wordt getoond in Codefragment 5.4. Codefragment 5.4: setupBridge.sh export interface = ` ip addr show | grep 10.1.1 | cut -d " " -f11 ` # Down ethX sudo ifconfig $ interface down # Create bridge sudo brctl addbr br0 sudo brctl addif br0 $ interface # Set IP , netmask , ... sudo ifconfig br0 ` ifconfig $ interface | grep ' inet addr :10.1.1 ' | cut -d : - f2 | awk ' { print $ 1 } ' ` netmask 255.255.255.0 broadcast 10.1.1.255 # Up ethX and br0 sudo ifconfig $ interface 0.0.0.0 promisc up sudo ifconfig br0 up

5.6

Benchmarking: WebLoadUI

De doelstelling van deze masterproef is om de modellen te testen met realistische scenario’s. Bij de testopstelling worden evenveel Windows instanties toegevoegd als er applicaties zijn ingezet. Daarop wordt WebLoadUI van SmartBear ge¨ınstalleerd, die het toelaat op een snelle manier website-scenario’s op te nemen, die dan later door meerdere gelijktijdige virtuele bezoekers opnieuw uitgevoerd kunnen worden. Hierbij worden niet enkel de requests naar de webpagina’s uitgevoerd, maar worden ook de bijhorende figuren, css stylesheets en javascript bestanden


54

gedownload. De mogelijkheid bestaat om tussen de verschillende requests een random think time toe te voegen. Dit voorziet een random pauze tussen twee opeenvolgende requests. De lengte van die pauze is uniform verdeeld. Door variërende pauzes toe te voegen, komt de belasting beter overeen met werkelijke belasting. Ook is er altijd een deel van de benchmarks random, om zo het cachen van resultaten tegen te gaan. De interface van WebLoadUI wordt weergegeven in Figuur 5.8 Om een realistische opstelling te verkrijgen, wordt er voordat de benchmarks gestart worden, random data toegevoegd aan de databank. Generatedata.com stelt een open source script ter beschikking waarmee gemakkelijk random data kan gegenereerd worden. Eerst wordt een datastructuur gedefiniëerd, waarna er een gekozen aantal random records geëxporteerd kan worden in verschillende formaten, waaronder SQL. Op deze manier werden 500 gebruikers aangemaakt, met een e-mailadres met een oplopend nummer, random naam en adres en een constant wachtwoord. Ook zijn er 2000 producten aangemaakt waarvoor er telkens één van de tien categorieën wordt gekozen met behulp van een uniforme distributie. Ook worden er 50 000 bestellingen toegevoegd, die random (opnieuw uniform verdeeld) werden toegewezen aan de zojuist aangemaakte gebruikers. Zo krijgen die gebruikers gemiddeld elk 100 bestellingen. Ook worden er 500 000 producten toegewezen aan de bestellingen, opnieuw door middel van een uniform verdeelde distributie. Zo krijgt elke bestelling gemiddeld 10 producten. In WebLoadUI werden enkele benchmarks opgesteld, gebruik makende van de functionaliteiten besproken in Sectie 4.2.2. In die sectie werd besproken hoe de verschillende requests intern afgehandeld werden, terwijl hieronder de requests opgesomd worden samen met een beschrijving van hun deels random inhoud. Registreren: Er is een lijst met 20 000 verschillende e-mailadressen gegenereerd door

WebLoadUI. Elke virtuele webshop-bezoeker pakt zo telkens een nieuw e-mailadres uit de lijst om zich te registreren. De overige data wordt constant gehouden, om zo gemakkelijk de aangemaakte records te kunnen identificeren. GET index . xhtml # Homepage POST Create . xhtml ( email , wachtwoord , naam , adres ) # Registreer


55

Bestellingen bekijken: Er wordt random (uniform verdeeld) een van de 500 gegeneerde

e-mailadressen gekozen om in te loggen om dan zijn bestellingen te bekijken. GET index . xhtml # Homepage POST index . xhtml ( email , wachtwoord ) # Inloggen GET MyOrders . xhtml Aankopen doen: Dit is de meest uitgebreide benchmark. Hier registreert een webshop-

bezoeker zich met een e-mailadres uit een andere lijst met 20 000 verschillende e-mailadressen. Vijf keer wordt dan een random productcategorie (uniform verdeeld tussen 1 en 10) bekeken en een random product toegevoegd aan zijn winkelmandje (uniform verdeeld tussen 1 en 2000). Uiteindelijk wordt de bestelling dan uitgevoerd. GET index . xhtml # Homepage POST Create . xhtml ( email , wachtwoord , naam , adres ) # Registreer POST index . xhtml ( email , wachtwoord ) # Inloggen GET MyOrders . xhtml 5. times ( GET List . xhtml ( categorie - id ) # Productcategorie bekijken GET View . xhtml ( product - id ) # Product toevoegen aan mandje ) GET Checkout . xhtml # Bestelling uitvoeren Bestellingen in PDF: Er wordt random (uniform verdeeld) een van de 500 gegeneerde

e-mailadressen gekozen om in te loggen om dan een PDF te genereren met daarin een lijst van al zijn bestellingen. Deze PDF wordt in een tijdelijke map opgeslagen, om dan onmiddellijk weer verwijderd te worden. GET index . xhtml # Homepage POST index . xhtml ( email , wachtwoord ) # Inloggen GET MyOrdersPDF . xhtml De random think time werd zo ingesteld dat die uniform verdeeld was tussen 0 en 5 seconden. Dit is vrij laag voor een webshop, vaak wordt er langer bij een pagina stil gestaan om bijvoorbeeld de info over het product te lezen. De reden dat dit laag gehouden is, is dat een lagere think time voor meer requests per seconde zorgt, zonder dat hiervoor extra threads nodig zijn in WebLoadUI. Het toevoegen van extra virtuele gebruikers, en dus threads, zorgde voor een groter geheugengebruik van WebLoadUI, en aangezien de Load Testers draaien op Windows 7 32 bit doken er geregeld out-of-memory fouten op bij testen met meer dan 256 concurrente gebruikers. Opdat een applicatie gebruiksvriendelijk zou zijn, moeten de pagina’s binnen een beperkte tijd geladen zijn. Robert Miller geeft aan dat wanneer er een simpele aanvraag wordt gedaan, er bin-


56

nen de twee seconden antwoord moet komen om gebruiksvriendelijk over te komen.[Miller, 1968] Daarom wordt een scenario als gefaald aanzien van zodra de eerste byte meer dan twee seconden op zich laat wachten. Om de volledige pagina te laden, zetten we een limiet van 5 seconden, aangezien het niet als storend over komt als een figuur wat langer op zich laat wachten. Een vervelende eigenschap van WebLoadUI is dat er geen onderscheid kan gemaakt worden tussen fouten als gevolg van het overschrijden van de tijdslimieten en harde fouten. We nemen die fouten dan ook samen in de resultaten.


57

Chef Server

Clo ud Co ntro ller

Chef Wo rkstatio n

Virtual instances Lo ad Testers No de Co ntrollers

Figuur 5.7: De fysieke opstelling op de Virtual Wall.

Figuur 5.8: De interface van WebLoadUI, tijdens een load test.

HET SCHALEN VAN DATABANKEN

58

Hoofdstuk 6

Het schalen van databanken 6.1

De verschillende modellen implementeren

Zoals er al in de literatuurstudie werd vermeld zijn er verschillende databank modellen die gebruikt kunnen worden om een applicatie aan te bieden aan verschillende gebruikers. In Sectie 3.4.2 werden dan de drie meest verschillende opstellingen besproken: Shared Nothing, Shared Instance en Shared Table. Om deze opstellingen automatisch te kunnen opzetten werd een nieuwe cookbook aangemaakt voor Duke’s Forest. Deze bestaat uit twee recipes: dukesforest::appserver en dukesforest::database, waarvan al gesproken werd in Sectie 5.4. Om deze recipes een applicatie te laten uitrollen voor een gebruiker, moeten zowel de applicatie server als de databank server een node attribute hebben met de volgende structuur: client = { " name " = > < NAAM > , " password " = > < WACHTWOORD > , " dbhost " = > < DATABANK SERVER IP > , " dbname " = > < DATABANK NAAM > } node [: dukesforest ][ clients ][ < NAAM >] = client Hierbij zullen en <WACHTWOORD> gebruikt worden als gebruikersnaam en wachtwoord voor de databank, waarbij uniek is per gebruiker. De andere twee parameters spreken voor zich en zullen bepalen welk van de drie modellen geconfigureerd wordt: Shared Nothing: is uniek voor elke gebruiker

6.1 De verschillende modellen implementeren

59

Shared Instance: is gelijk voor elke gebruiker,

terwijl uniek is voor elke gebruiker Shared Table: zowel als zijn gelijk

voor elke gebruiker Nu moet er uiteraard voor Shared Table nog een onderscheid gemaakt worden tussen de records van de verschillende gebruikers. Er werd gekozen om de tabelstructuur als volgt aan te passen: elke tabel kreeg de prefix “all” en een kolom “instance” erbij met daarin de naam van de gebruiker (). Daarnaast werd voor elke tabel een MySQL view aangemaakt waarmee de oorspronkelijke tabel gefilterd wordt weergegeven: enkel de records waarbij de instance-kolom overeenkomt met de gebruikersnaam worden getoond. Deze views krijgen dezelfde naam als de oorspronkelijke tabel, maar dan zonder de prefix. Ze kunnen gemakkelijk aangemaakt worden in MySQL. Een voorbeeld: CREATE VIEW CATEGORY AS SELECT * from all_category WHERE INSTANCE = substring_index ( user ( ) , ' @ ' , 1 ) ; Hiermee kan de applicatie al data ophalen zonder dat er enige wijziging nodig is in de code. Enkel wanneer er data wordt toegevoegd, wordt de instance-kolom nog niet ingevuld. Dit wordt opgelost met behulp van MySQL triggers: CREATE TRIGGER ` CATEGORY_INSTANCE_INSERT ` BEFORE INSERT ON ` all_category ` FOR EACH ROW SET NEW . INSTANCE = substring_index ( user ( ) , ' @ ' , 1 ) ; Omdat het niet de bedoeling was om de performantie van triggers en views van MySQL te meten, is er besloten om dit systeem toe te passen voor elk model. Bij Shared Instance en Shared Nothing voegt dit geen functionaliteit toe, aangezien er dan in elke databank slechts data zit van één gebruiker, maar het zorgt ook niet voor problemen. Op die manier kan elk model eerlijk vergeleken worden. Deze views en triggers zijn dan ook een belangrijk onderdeel van het dukesforest::database recipe. In pseudocode doet deze het volgende: node . dukesforest . clients . each do | name , client | db = new Database ( name ) # tabellen , views en triggers toevoegen db . createConnection ( rootUser ) . execute ( " create . sql " )

6.2 Opstelling van de testomgeving

60

user = new DatabaseUser ( name , client [: password ]) user . addRights ( db ) # Data invoeren , zoals categorieen etc db . createConnection ( user ) . execute ( " insert . sql " ) end Het dukesforest::appserver recipe werkt in pseudocode als volgt: JBoss . addDriver ( MySQL ) JBoss . addDe ployme ntWARs ( warfiles ) node . dukesforest . client . first do | name , client | ds = JBoss . addDatasource ( client [: dbhost ] , client [: dbname ] , name , client [: password ]) JBoss . addSec urityD omain ( ds , security - queries ) end Met deze twee recipes kan Duke’s Forest uitgerold worden volgens de drie modellen. Het is zelfs mogelijk om gecombineerde opstellingen te maken: een opstelling waarbij twee gebruikers in een Shared Table opstelling werken op een databank server, die ondertussen ook gebruikt wordt door een andere gebruiker in een Shared Instance omgeving is perfect mogelijk.

6.2

Opstelling van de testomgeving

Om deze drie modellen te vergelijken, werden er telkens drie applicaties per model opgestart binnen ASP. Deze applicaties kregen elk een eigen virtuele instantie met drie cores en 1,5 GB geheugen om de AS op te draaien. Dit zijn met opzet vrij krachtige machines om ervoor te zorgen dat de AS niet telkens de bottleneck zou zijn tijdens het testen van de databank modellen. JBoss werd geconfigureerd zodat de heap grootte constant 1303 MB is, terwijl de maximum grootte van de permanent generation heap op 256 MB werd ingesteld. Dit zijn de parameters die gebruikt worden in de standaard JBoss EAP installatie, en bleken voldoende om onze applicatie zwaar te kunnen belasten. Naast die applicatie servers werden ook de databank servers opgesteld, afhankelijk van het gekozen model. Voor Shared Nothing werden drie aparte virtuele instanties opgezet, elk met één core en 386 MB geheugen. Voor Shared Table en Shared Instance werd één server aangemaakt met drie keer het aantal cores en geheugen als bij Shared Nothing: drie cores en 1158 MB geheugen dus. Op deze manier worden er even veel resources gebruikt voor alle 3 de modellen.

6.3 Benchmarks

61

JBo ss EAP 6 .2

JBo ss EAP 6 .2

Zabbix Agent

Zabbix Agent

Applicatio n Server Instance


JBo ss EAP 6 .2

JBo ss EAP 6 .2

Zabbix Server

Zabbix Agent Mo nito ring Server

MySQL


MySQL

Zabbix Agent

Zabbix Agent


JBo ss EAP 6 .2

Database Instance

X3

(a) Shared Nothing


Databank Instance

Databank Instance JBo ss EAP 6 .2

Zabbix Agent MySQL

JBo ss EAP 6 .2

Zabbix Agent

Zabbix Agent



(b) Shared Instance

(c) Shared Table

Figuur 6.1: Testopstellingen voor de databankmodellen

De opstelling wordt gevisualiseerd in figuur 6.1

6.3

Benchmarks

De load tests beschreven in Sectie 5.6 worden uitgevoerd als volgt (in pseudocode): for ( benchmark in [ ' Register ' , ' CheckOrders ' , ' Shop ' ]) do concurrent_users = 8 while concurrent_users <= 256 do executeBenchmark ( benchmark , concurrent_users , 15. minutes ) wait (20. minutes ) if benchmark == ' Register ' then removeNewUsers () concurrent_users *= 2 end wait (1. hour ) end Waarbij executeBenchmark telkens concurrent users virtuele webshop-bezoekers het gekozen scenario laat uitvoeren. Wanneer een bezoeker een scenario voltooid heeft, wordt die vervangen door een nieuwe bezoeker. Indien concurrent users dus gelijk is aan acht, is men zeker dat er tijdens de test ten allen tijde acht gebruikers de webshop aan het gebruiken zijn. Test wezen uit dat de JBoss AS er maximum een kwartier over deed om terug in regime te verkeren na een zware test. Voor de zekerheid werd er dus 20 minuten pauze gehouden tussen de testen.

6.4 Resultaten

6.4

62

Resultaten

Om de verschillende databank multi-tenancy modellen te vergelijken, werden de benchmarks uitgevoerd die beschreven zijn in Sectie 5.6. Om het volledige systeem te belasten, werden telkens drie Load Testers tegelijk ingezet die elk één AS belasten met dezelfde benchmark. Zo werd elke benchmark 3 keer gelijktijdig gedraaid op elke AS, wat resulteerde in 9 testresultaten per benchmark per opstelling. In deze sectie wordt vaak gebruik gemaakt van boxplots. Boxplots die in deze masterproef gebruikt worden moeten als volgt ge¨ınterpreteerd worden: de middelste lijn geeft de mediaan weer, terwijl de box het 25e en 75e percentiel aanduidt. De whiskers tonen dan het 5e en 95e percentiel.

6.4.1

Registreren

Eerst wordt gekeken hoeveel keer het scenario kan voltooid worden binnen één kwartier. In Figuur 6.2 zien we in het begin voor elk model bijna een verdubbeling in het aantal scenario’s wanneer we het aantal simultane bezoekers verdubbelen. Vanaf 128 simultane bezoekers zien we dat er fouten optreden bij Shared Instance en Shared Table. Deze fouten zijn te wijten aan het feit dat de eerste byte van het antwoord er langer dan twee seconden over doet, of dat de pagina na vijf seconden nog steeds niet volledig is geladen. Wanneer we het aantal simultane bezoekers nog verhogen, is te merken dat er niet meer scenario’s kunnen uitgevoerd worden binnen een kwartier. Shared Nothing kan duidelijk een groter aantal registreer scenario’s aan dan de andere twee modellen. Als we dan kijken hoeveel tijd nodig is om een pagina te laden, zien we bij 8 simultane bezoekers weinig verschil tussen de modellen, maar het verschil groeit naarmate het aantal simultane bezoekers toeneemt. Dit is duidelijk te zien in Figuur 6.3. Bij 128 simultane bezoekers worden net geen 75% van de pagina’s geladen binnen één seconde. Bij Shared Table zijn langere laadtijden op te merken, maar toch wordt meer dan 75% van de pagina’s geladen binnen twee seconden. De laadtijden van Shared Instance nog een stuk hoger, waarbij meer dan helft van de pagina’s er langer dan 2 seconden over doet om geladen te worden. Aangezien het verschil duidelijk te merken is bij 128 simultane gebruikers, wordt er dieper ingegaan op dit geval. De metingen van de AS worden weergegeven met boxplots in Figuur 6.4

6.4 Resultaten

63

Aantal uitgevoerde scenario's: Registreren 8000

7000

6000

5000

4000 Gemiddelde van Err 3000

Gemiddelde van OK

2000

1000

0 SN

SI 8

ST

SN

SI 16

ST

SN

SI 32

ST

SN

SI 64

ST

SN

SI 128

ST

SN

SI

ST

256

Databankmodel Aantal simultane bezoekers

Figuur 6.2: Het aantal registreer scenario’s dat uitgevoerd werd binnen één kwartier. SN staat voor Shared Nothing, SI voor Shared Instance en ST voor Shared Table.

6.4 Resultaten

64

Registreren, 8 simultane bezoekers


200

150

125

Page Load time (ms)

Page Load time (ms)

150

100

100

75

50

50 25

0

SN

SI

0

ST

SN

SI

Databank model

ST

Databank model Highcharts.com

Highcharts.com



5k

10k

4k

Page Load time (ms)

Page Load time (ms)

7.5k

3k

2k

5k

2.5k 1k

0k

SN

SI

0k

ST

SN

Databank model

SI

ST


Highcharts.com

Figuur 6.3: De laadtijd van de webpagina’s bij het registreren

en de metingen van de DB servers zijn te zien in Figuur 6.5. Bij de AS is het netwerkverkeer lager bij Shared Instance aangezien er minder scenario’s verwerkt worden. Toch is de processor belasting hoger bij Shared Instance. De heap space verschilt licht, maar zou geen probleem mogen vormen doordat er genoeg geheugen beschikbaar is gesteld. Bij de DB servers merken we dat Shared Table en Shared Instance een hogere processorbelasting hebben, een hoger netwerkverkeer te verwerken krijgen en ongeveer drie keer zo vaak bevraagd worden in vergelijk met Shared Nothing. Dit is te verwachten, aangezien er nu van drie ASs aanvragen komen. Aangezien er minder scenario’s verwerkt konden worden bij Shared Instance, is het in- en uitgaand netwerkverkeer wel lager dan bij Shared Table. Wat vreemd is, is dat het Shared Instance model een hogere processorbelasting heeft, en ook meer last had van table locks waarop gewacht moest worden. Dit eerste lijkt niet de bottleneck geweest te zijn, aangezien nog niet de helft van de capaciteit gebruikt wordt, maar dit tweede is wel opmerkelijk. Er worden namelijk geen tabellen gedeeld tussen de gebruikers, dus zou men eerder bij Shared Table een hoger aantal table locks verwachten.

6.4 Resultaten

65

AS: Processor belasting (avg 1 min)

AS: Gebruik heap space JBoss

1.25

600

500

Gebruik heap space (MB)

CPU load

1

0.75

0.5

0.25

400

300

200

100

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com

(a) De CPU load van de AS

(b) De JBoss heap space die in gebruik is

AS: Inkomend netwerkverkeer

AS: Uitgaand netwerkverkeer

1,000

6k

5k

Bandbreedte (Kbps)

Bandbreedte (Kbps)

800

600

400

200

0

4k

3k

2k

1k

SN

SI

0k

ST

Databank model

SN

SI

ST


(c) Inkomend netwerkverkeer bij de AS

Highcharts.com

(d) Uitgaand netwerkverkeer bij de AS

Figuur 6.4: De meetgegevens van de AS bij 128 simultane bezoekers die het Registreer scenario uitvoeren.

6.4 Resultaten

66

DB: Processor belasting (avg 1 min)

DB: Beschikbaar geheugen

0.4

1,000

Beschikbaar geheugen (MB)

800

CPU load

0.3

0.2

0.1

600

400

200

0

SN

SI

0

ST

SN

SI

Databank model

ST


(a) De CPU load van de DB servers

Highcharts.com

(b) Beschikbare geheugen van de DB servers

DB: Inkomend netwerkverkeer

DB: Uitgaand netwerkverkeer

350

400

300

Bandbreedte (Kbps)

Bandbreedte (Kbps)

300 250

200

150

200

100 100 50

0

SN

SI

0

ST

SN

Databank model

SI

ST


(c) Inkomend netwerkverkeer bij de DB servers

Highcharts.com

(d) Uitgaand netwerkverkeer bij de DB servers DB: Aantal table locks waarvoor gewacht moet worden 2.5

DB: Aantal queries 150

2

Aantal locks (locks/s)

Aantal queries (qps)

125

100

75

1.5

1

50 0.5 25 0 0

SN

SI

SN

SI

ST

Databank model

ST

Highcharts.com


(f) Aantal table locks waarop gewacht moet (e) Aantal SQL queries per seconde worden per seconde

Figuur 6.5: De meetgegevens van de DB servers bij 128 simultane bezoekers die het Registreer scenario uitvoeren.

6.4 Resultaten

6.4.2

67

Bestellingen bekijken

Ook hier starten we met het aantal keer dat het scenario kan voltooid worden binnen één kwartier. In Figuur 6.6 zien we opnieuw in het begin voor elk model bijna een verdubbeling in het aantal scenario’s wanneer we het aantal simultane bezoekers verdubbelen. Vanaf 128 simultane bezoekers stopt deze trend en beginnen er fouten op te treden. De fouten die hier optreden zijn ook allemaal te wijten aan het overschrijden van de maximum laadtijd van het scenario, en zijn dus eigenlijk ook succesvolle scenario’s. Shared Nothing presteert hier opnieuw beduidend beter. Wanneer we de laadtijden van de pagina’s bekijken, weergegeven in Figuur 6.7, zien we dat die beduidend langer zijn dan bij het registreer scenario. Bij 128 gebruikers zien we opnieuw dat Shared Nothing een veel lagere laadtijd heeft dan Shared Table en Shared Instance, maar meer dan de helft van de pagina’s heeft er al meer dan twee seconden voor nodig. Na het bekijken van de gedetailleerde testresultaten blijkt dat de meeste tijd verloren gaat aan het opzetten van een nieuwe verbinding. Eens de verbinding is opgesteld, blijken de requests snel beantwoord te worden. Aangezien het verschil opnieuw opvalt bij 128 simultane gebruikers wordt dit aantal ook gebruikt bij de volgende grafieken. De metingen van de AS worden weergegeven met boxplots in Figuur 6.8 en de metingen van de DB servers in Figuur 6.9. Ook hier zijn er zoals verwacht weinig verschillen tussen de metingen bij de AS. Enkel valt een hoger gebruik van de heap space bij Shared Instance op. Er is niet meteen een verklaring voor te vinden, het zou kunnen dat de garbage collector het nodig acht om minder grondig te werk te gaan. Bij de metingen van de databank server valt er opnieuw weinig op te merken dat niet te verklaren is door ofwel de drie maal zo hoge belasting bij Shared Table en Shared Instance, of doordat die modellen drie maal zoveel geheugen ter beschikking krijgen. Wel valt op dat de Shared Table en Shared Instance modellen een stabieler aantal queries per seconde te verwerken krijgen. Dit valt te verklaren doordat de random think time minder invloed heeft op de load bij meer verbindingen. Het feit dat Shared Nothing grote uitschieters kent bij het in- en uitgaand verkeer is waarschijnlijk te wijten aan een korte interventie tijdens één van de testen.

6.4 Resultaten

68

Aantal uitgevoerde scenario's: Bestellingen bekijken 9000

8000

7000

6000

5000

4000 Gemiddelde van Err Gemiddelde van OK

3000

2000

1000

0 SN

SI

ST

SN

SI

8

ST

SN

16

SI

ST

SN

32

SI

ST

SN

64

SI

ST

128

SN

SI

ST

256


Figuur 6.6: Het aantal scenario’s dat uitgevoerd werd binnen één kwartier waarbij de bestellingen opgevraagd worden Mijn bestellingen, 8 simultane bezoekers

Mijn bestellingen, 32 simultane bezoekers

1,750

1,500

1,250

Page Load time (ms)

1,250

1,000

750

1,000

750

500

500 250

250

0

SN

SI

0

ST

SN

SI

Databank model

ST


Highcharts.com



10k

40k

8k

Page Load time (ms)

30k

Page Load time (ms)

Page Load time (ms)

1,500

6k

4k

20k

10k 2k

0k

SN

SI

0k

ST

Databank model

SN

SI

ST


Figuur 6.7: De laadtijd van de webpagina’s bij het bekijken van de bestellingen

Highcharts.com

6.4 Resultaten

69



1.75

1,500

1.5


1,250

CPU load

1.25

1

0.75

0.5

1,000

750

500

250

0.25

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com





2,500

30k

25k

Bandbreedte (Kbps)

Bandbreedte (Kbps)

2,000

1,500

1,000

500

0

20k

15k

10k

5k

SN

SI

0k

ST

Databank model

SN

SI

ST



Highcharts.com


Figuur 6.8: De meetgegevens van de AS bij 128 simultane bezoekers die het scenario uitvoeren waarbij de bestellingen worden bekeken.

6.4 Resultaten

70

DB: Beschikbaar geheugen 1,000

0.8

800


CPU load

DB: Processor belasting (avg 1 min) 1

0.6

0.4

600

400

0.2

200

0

SN

SI

0

ST

SN

SI

Databank model

ST



Highcharts.com

(b) Beschikbare geheugen van de DB servers DB: Uitgaand netwerkverkeer

2,500

25k

2,000

20k

Bandbreedte (Kbps)

Bandbreedte (Kbps)


1,500

1,000

15k

10k

500

0

5k

SN

SI

0k

ST

SN

Databank model

SI

ST



Highcharts.com

(d) Uitgaand netwerkverkeer bij de DB servers DB: Aantal table locks waarvoor gewacht moet worden

DB: Aantal queries


400


300

200

0

100

SN 0

SN

SI

SI

ST

Databank model

ST

Highcharts.com



Figuur 6.9: De meetgegevens van de DB servers bij 128 simultane bezoekers die het scenario uitvoeren waarbij de bestellingen worden bekeken.

6.4 Resultaten

6.4.3

71

Aankopen doen

In Figuur 6.10 wordt het aantal uitgevoerde “Aankopen doen” scenario’s weergegeven. Hier stijgt het aantal uitgevoerde scenario’s niet evenredig met het aantal simultane bezoekers. Een duidelijke aanwijzing dat dit een zware test is. Bij 256 merken we veel fouten bij Shared Instance en Shared Nothing. Deze zijn deze keer niet te wijten aan de lange laadtijd, maar zijn verbindingen die niet geaccepteerd worden, of waarbij er een time-out optreedt. Bij Shared Table treden ook enkele time-outs op, maar toch aanzienlijk minder. Wat onmiddellijk opvalt is het feit dat Shared Table nu telkens minder goed presteert, behalve wanneer er echte fouten beginnen op te treden bij de andere 2 modellen. Wanneer we de laadtijden van de pagina’s bekijken, is te zien dat deze met weinig simultane bezoekers dicht bij elkaar liggen. Dit wijzigt wel wanneer het aantal simultane bezoekers stijgt. Zo is er een duidelijk langere laadtijd bij Shared Table bij 128 simultane bezoekers. Wat ook opvalt, is dat voor dit scenario er voor elk model grote uitschieters zijn in laadtijd. Bij Shared Table duurde het zelfs eens meer dan 200 seconden voor een pagina geladen werd bij slechts 32 simultane bezoekers. WebLoadUI toont aan dat de lange laadtijden veroorzaakt worden doordat het erg lang duurt voordat de eerste byte ontvangen wordt. De tijd dat het duurt om een verbinding op te zetten heeft deze keer geen belangrijke invloed. Aangezien 128 simultane bezoekers het kantelpunt lijkt te zijn, en er bij 256 bezoekers zaken fout lopen, worden beide hieronder uitgebreider bekeken. De metingen van de AS is te vinden in Figuur 6.12, terwijl de metingen van de DB servers in Figuur 6.13 en 6.14 staan. Bij 256 simultane gebruikers is duidelijk te zien dat de processors van de AS zwaar belast worden. De andere gegevens zijn vrij gelijkaardig voor Shared Nothing en Shared Table. Voor Shared Instance zijn er merkwaardige metingen. Na dit nagekeken te hebben, bleek dat de zabbix agent af en toe niet bereikbaar was tijdens de testen. Blijkbaar dat er te weinig resources beschikbaar waren om de meetgegevens op te halen. Als er gekeken wordt naar de metingen aan de kant van de databank server, valt op dat de processor belasting bij elk model erg beperkt is. Ook is er duidelijk geen gebrek aan geheugen. Vreemd genoeg worden er bij de Shared Instance opstelling minder queries uitgevoerd dan bij Shared Table. Dit kan bij het geval van 256 simultane bezoekers deels verklaard worden doordat er minder uitgevoerde scenario’s werden uitgevoerd, maar het verschil lijkt groter dan dat. Na het nakijken van de logs blijkt dat tweemaal één van de drie AS tijdelijk onbereikbaar werd

6.4 Resultaten

72

Aantal uitgevoerde scenario's: Aankopen doen 450

400

350

300

250

200 Gemiddelde van Err Gemiddelde van OK

150

100

50

0 SN

SI

ST

SN

SI

8

ST

SN

16

SI

ST

SN

32

SI

ST

SN

64

SI

ST

128

SN

SI

ST

256


Figuur 6.10: Het aantal scenario’s waarbij aankopen worden gedaan dat uitgevoerd werd binnen één kwartier Shoppen, 8 simultane bezoekers

Shoppen, 32 simultane bezoekers

8k

250k

200k

Page Load time (ms)

4k

150k

100k

2k 50k

0k

SN

SI

0k

ST

SN

SI

Databank model

ST


Highcharts.com



400k

400k

300k

300k

Page Load time (ms)

Page Load time (ms)

Page Load time (ms)

6k

200k

100k

0k

200k

100k

SN

SI

0k

ST

Databank model

SN

SI

ST


Figuur 6.11: De laadtijd van de webpagina’s tijdens het winkelen

Highcharts.com

6.4 Resultaten

73



0.8

1.75

1.5 0.6

CPU load

CPU load

1.25

0.4

1

0.75

0.5 0.2 0.25

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com

AS: Beschikbaar geheugen

125

125

100

100




75

50

25

75

50

25

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com


1,500

1,500

1,250

1,250




1,000

750

500

250

0

1,000

750

500

250

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com



12.5k

6k

5k

Bandbreedte (Kbps)

Bandbreedte (Kbps)

10k

7.5k

5k

2.5k

0k

4k

3k

2k

1k

SN

SI

0k

ST

SN

SI

Databank model

ST


Highcharts.com



1,250

3,000

2,500

Bandbreedte (Kbps)

Bandbreedte (Kbps)

1,000

750

500

250

0

2,000

1,500

1,000

500

SN

SI

0

ST

Databank model

SN

SI

ST


Highcharts.com

Figuur 6.12: De meetgegevens van de AS bij 128 (links) en 256 (rechts) simultane bezoekers die aankopen doen.

6.5 Conclusie

74

tijdens de testen wanneer er meer dan 64 simultane gebruikers werden ingezet. Hierdoor werden ook geen queries doorgestuurd naar de databankserver, wat het lager aantal queries verklaart. Omdat de resultaten van Shared Table significant lager liggen in vergelijking met de andere twee modellen, wordt ook het geval met 16 simultane bezoekers beter bekeken. Daar is het verschil namelijk het grootst. De meetgegevens aan de kant van de AS staan in Figuur 6.15, terwijl die van de kant van de databankserver in Figuur 6.16 staan. Onmiddellijk valt op dat er grotere processorbelasting is bij de AS van Shared Table. De verschillen in het netwerkverkeer kunnen niet onmiddellijk verklaard worden. Aan de databankzijde valt op dat de Shared Instance opstelling meer data ontvangt en verstuurt, aangezien die meer queries verwerkt. Het netwerkverkeer van Shared Table ligt in de buurt van dat van Shared Nothing, terwijl dit bij gelijk aantal scenario’s drie keer zo hoog zou moeten zijn. Er moet bij Shared Table wel soms gewacht worden op een table lock, maar dit is nooit meer dan 1 keer per seconde en gebeurt slechts zelden.

6.5

Conclusie

Het blijkt erg moeilijk te zijn om realistische scenario’s te creëren met één AS zonder dat deze zelf de bottleneck wordt. Toch zijn er een aantal opmerkelijke dingen op te merken: Shared Nothing presteert het best in elke test. Vooral het feit dat deze opstelling beter

presteert dan Shared Instance is merkwaardig. Er is namelijk extra overhead aanwezig van extra besturingssystemen. Shared Table presteert beduidend minder goed als er veel of zware queries gebruikt worden.

Dit was te merken bij het opvragen van de bestellingen en het winkelen waarbij veel producten werden opgevraagd. De databank servers hebben een invloed op de laadtijd, ook al worden ze, gemiddeld over

1 minuut, niet zwaar belast. Voor verder onderzoek zouden de uitvoeringstijden van de verschillende queries gelogd moeten worden. Voor deze masterproef werden enkel de ”slow queries”gelogd. Dit zijn standaard queries die er langer dan 10 seconden over doen. Echter bleek geen enkele test ooit een slow query te veroorzaken. Dit zou het gemakkelijker maken om de oorzaken te vinden waarom de laadtijden

6.5 Conclusie

75



0.7

0.3

0.6

0.25

0.5

CPU load

CPU load

0.2 0.4

0.3

0.15

0.1 0.2 0.05

0.1

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com


1,000

1,000

800

800




600

400

200

0

600

400

200

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com



1,250

2,000

1,000

Bandbreedte (Kbps)

Bandbreedte (Kbps)

1,500

750

500

1,000

500 250

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com


15k

15k

12.5k

12.5k

Bandbreedte (Kbps)

Bandbreedte (Kbps)


10k

7.5k

5k

2.5k

0k

10k

7.5k

5k

2.5k

SN

SI

0k

ST

Databank model

SN

SI

ST


Highcharts.com

Figuur 6.13: De meetgegevens van de DB servers wanneer 128 (links) en 256 (rechts) simultane bezoekers aankopen doen. Deel 1

6.5 Conclusie

76

DB: Aantal queries

DB: Aantal queries

300

1,000

800



250

200

150

100

600

400

200

50

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com

DB: Aantal SELECT queries

DB: Aantal SELECT queries

200

350

300



150

100

250

200

150

100 50 50

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com

DB: Aantal INSERT queries

DB: Aantal INSERT queries

3.5

1.25

3



1 2.5

2

1.5

0.75

0.5

1 0.25 0.5

0

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com

DB: Aantal table locks waarvoor gewacht moet worden



DB: Aantal table locks waarvoor gewacht moet worden

0

SN

SI

ST

0

SN

Databank model

SI

ST


Highcharts.com

Figuur 6.14: De meetgegevens van de DB servers wanneer 128 (links) en 256 (rechts) simultane bezoekers aankopen doen. Deel 2

6.5 Conclusie

77

AS: Gebruik heap space JBoss 1,250

0.8

1,000


CPU load

AS: Processor belasting (avg 1 min) 1

0.6

0.4

0.2

0

750

500

250

SN

SI

0

ST

SN

Databank model

SI

ST


Highcharts.com





30k

2,500

2,000

Bandbreedte (Kbps)

Bandbreedte (Kbps)

25k

20k

15k

10k

1,000

500

5k

0k

1,500

SN

SI

0

ST

Databank model

SN

SI

ST



Highcharts.com


Figuur 6.15: De meetgegevens van de AS bij 16 simultane bezoekers die aankopen doen.

6.5 Conclusie

78

DB: Beschikbaar geheugen 1,000

1

800


CPU load

DB: Processor belasting (avg 1 min) 1.25

0.75

0.5

0.25

600

400

200

0

SN

SI

0

ST

SN

SI

Databank model

ST



Highcharts.com

(b) Beschikbare geheugen van de DB servers



7k

100k

6k

Bandbreedte (Kbps)

Bandbreedte (Kbps)

80k 5k

4k

3k

60k

40k

2k 20k 1k

0k

SN

SI

0k

ST

SN

Databank model

SI

ST



Highcharts.com

(d) Uitgaand netwerkverkeer bij de DB servers DB: Aantal table locks waarvoor gewacht moet worden 1.25

DB: Aantal queries 1,500

1



1,250

1,000

750

0.75

0.5

500 0.25 250 0 0

SN

SI

SN

SI

ST

Databank model

ST

Highcharts.com



Figuur 6.16: De meetgegevens van de DB servers bij 16 simultane bezoekers die aankopen doen.

6.5 Conclusie

79

precies verschillen. Het is gissen wat precies de oorzaak is dat Shared Nothing beter presteert in vergelijking met Shared Instance. Mogelijk kan MySQL beter een cache bijhouden van 1 databank dan verschillende databanken, of zorgt een apart besturingssysteem er voor dat de TCP verbindingen beter beheerd kunnen worden. Dat Shared Table minder goed presteert, was te verwachten, aangezien er bij elke operatie gebruik gemaakt moet worden van veel grotere tabellen. Maar Shared Table heeft het voordeel dat het door middel van sharding gemakkelijk kan omgezet worden in Shared Nothing. Alle records van een gebruiker worden dan verplaatst naar een andere databankserver. Op die manier is het mogelijk een erg flexibele opstelling te hebben zonder veel resources nodig te hebben. Om een goede beslissing te maken over welk databank systeem gekozen moet worden, moeten nog een aantal andere zaken onderzocht worden. Zo is er in deze masterproef enkel getest met een even grote belasting van alle gebruikers. Het zou interessant zijn om de modellen te vergelijken wanneer slechts één klant plots het systeem zwaar belast. Men zou dan veronderstellen dat Shared Instance en Shared Table voordeel hebben ten opzicht van Shared Nothing doordat deze meer resources ter beschikking hebben.

HET SCHALEN VAN DE APPLICATIE SERVER

80

Hoofdstuk 7

Het schalen van de applicatie server 7.1

De verschillende modellen

In hoofdstuk 3 werd al aangegeven dat applicaties meestal in grote delen worden opgesplitst. Zo zijn bij Duke’s Forest bijvoorbeeld de verzending en betaling elk in een aparte applicatie ondergebracht. Deze kunnen dan afzonderlijk geschaald worden wanneer ze zwaar belast worden. Dit gebeurt dan normaal door de applicatie server te dupliceren, die in een cluster te plaatsen zodat de sessies gerepliceerd worden over alle AS, waarna er een load balancer wordt ingezet om de aanvragen te verdelen over de verschillende servers. Dit model is ge¨ımplementeerd door gebruik te maken van JBoss mod cluster. Het wordt gevisualiseerd in Figuur 7.1. Een dergelijke opstelling kan snel opgesteld worden met de zelfgemaakte dukesforest-mod-cluster::appserver recipe. Die recipe, zal mod cluster installeren, configureren en opstarten. Wanneer mod cluster correct geconfigureerd is, zal die automatisch de verschillende JBoss AS op het netwerk ontdekken door middel van broadcast berichten. Hierdoor kan ook gemakkelijk een extra AS ingezet of verwijderd worden, zonder dat hiervoor een wijziging nodig is in de configuratie. Aangezien elke node met dezelfde hardware wordt uitgerust en dezelfde applicatie draaien, wordt mod cluster zo ingesteld dat de aanvragen evenwichtig verdeeld worden over de drie AS. Er wordt echter vermoed dat wanneer een applicatie fijnschaliger geschaald wordt, er een prestatiewinst verkregen kan worden. Hoe dit in zijn werk zou gaan, werd besproken in Sectie 3.4.

Echter was het niet mogelijk om alle onderdelen die nodig zijn om een dergelijk

7.1 De verschillende modellen

81

httpd met mo d_cluster

Duke's Sto re JBo ss AS Applicatio n Server

Duke's Sto re JBo ss AS

Applicatio n Server

Duke's Sto re JBo ss AS Applicatio n Server

Figuur 7.1: Met behulp van mod cluster worden de aanvragen verdeeld over de drie AS.

systeem te implementeren, zoals het identificeren van EJB’s die vaak met elkaar interageren en het monitoren van aparte EJB’s, te bouwen binnen het bestek van deze masterproef. Om toch de mogelijke prestatiewinst van deze opstelling te bekijken, werd een opstelling opgezet die mogelijk gemaakt kan worden door dit systeem. Die opstelling wordt gevisualiseerd in Figuur 7.2. Zo werd de OrderBean, de EJB die alle acties rond bestellingen afhandelt, gedupliceerd over meerdere AS. Dit werd bekomen door eerst van de OrderBean een interface af te leiden, waarna de OrderBean beschikbaar kon worden gesteld aan externe applicaties met behulp van de @Remote annotatie. Hierdoor kan de EJB opgevraagd worden met behulp van JNDI, wat zal resulteren in een proxy-object dat de OrderBeanInterface implementeert. In plaats van de EJB te injecteren met de @EJB annotatie, werd een OrderBeanAccessor klasse gemaakt die de OrderBean opvraagt met behulp van een context lookup waarbij de JNDI string ejb:/dukes-store//OrderBean!com.forest.ejb.OrderBeanInterface wordt gebruikt. De OrderBean werd ook geclustered met de @Clustered annotatie. Op deze manier hoeft er maar een verbinding opgesteld te worden met één AS met deze EJB. Die AS zal dan de clustertopologie doorgeven aan de AS die de aanvraag doet. Vanaf dan kan er geloadbalanced worden tussen de verschillende EJB’s. Zelfs wanneer de AS waarmee eerst verbinding werd gelegd zou wegvallen, zou de clustertopologie toch nog steeds bijgehouden en bijgewerkt worden door contact te leggen met de andere leden van de cluster. Het grote voordeel van een cluster die zichzelf onderhoudt, is dat er dynamisch onderdelen kunnen worden toegevoegd, zonder dat hiervoor

7.1 De verschillende modellen

82

aanpassingen vereist zijn. Load balancing binnen de cluster wordt toegepast door een ClusterNodeSelector, welke per applicatie is in te stellen. Deze kan zelf aangemaakt worden, waardoor informatie kan opgevraagd worden van monitoring services en dergelijke. Voor deze masterproef werd een RoundRobinClusterNodeSelector ge¨ımplementeerd, welke er voor zal zorgen dat elke AS evenveel requests krijgt naar de EJB.

Duke's Sto re

Duke's Sto re

Duke's Sto re

OrderBeanInterface

OrderBeanInterface

OrderBeanInterface

OrderBean

OrderBean

OrderBean

JBo ss AS

JBo ss AS

JBo ss AS

Applicatio n Server

Applicatio n Server

Applicatio n Server

Figuur 7.2: Enkel de OrderBean wordt geloadbalanced door deze in een extern toegankelijke cluster te plaatsen. Zoals gezien kan worden, werd de OrderBean niet uit de Duke’s Store applicatie gehaald. Om een EJB apart te deployen of uit te schakelen binnen de AS is het noodzakelijk dat de EJB uit de applicatie wordt gehaald en in een aparte JAR of EAR package wordt gestoken. Aangezien er niet dynamisch EJB’s worden in- of uitgeladen tijdens de testen van deze masterproef, is dit hier niet gedaan, hoewel dit perfect mogelijk is. De moeilijkheid daarvan is dat er veel aandacht moet gaan naar dependencies. Indien deze schaalmethode succesvol zou blijken, zouden IDE’s refactoring-systemen moeten aanbieden waardoor de EJB’s gemakkelijk in een aparte JAR of EAR worden aangeboden, samen met hun dependencies. Tijdens het opstellen werden 2 merkwaardigheden opgemerkt rond het clusteren in JBoss: Wanneer er een verbinding met de lokale AS gebruikt wordt om een remote EJB te laden,

wordt de EJB als lokaal aanzien en wordt er geen rekening gehouden met de clustering. Wanneer men een andere AS als startpunt gebruikt, wordt de clustertopologie wel correct doorgestuurd en worden alle AS, inclusief de lokale, gebruikt.

7.2 Opstelling van de testomgeving

83

Wanneer een remote EJB bij elke oproep opnieuw opgezocht wordt met behulp van JNDI,

zal de cluster-topologie verloren gaan. Men kan dus best per applicatie eenmalig een EJB proxy aanmaken, die dan de clustertopologie zal onthouden. Daarom werd de OrderBeanAccessor klasse gemaakt. Om deze opstelling geautomatiseerd te kunnen uitrollen, werd de dukesforest-clustered-ejb cookbook opgesteld. De appserver recipe daarvan zal een gebruiker aanmaken binnen JBoss die gebruikt zal worden om met de cluster te communiceren. Voor die gebruiker wordt er ook een security realm aangemaakt. Ook wordt er gezocht naar een tweede AS, waarvan het IP adres dan gebruikt wordt om een verbinding te definiëren die dan later gebruikt zal worden om de clustertopologie op te halen. De overige stappen zijn gelijk aan de dukesforest::appserver recipe, behalve dat de applicatie die gebruikt wordt, aangepast is zodat de OrderBean een geclusterde remote EJB is.

7.2

Opstelling van de testomgeving

In de testopstelling werden voor elke applicatie drie AS ingezet. Elke AS werd uitgerust met 1 GB geheugen en 1 CPU core. De minimum en maximum heap space voor JBoss werd beperkt tot 512 MB en de permanent generation heap tot 128 MB. Op die manier is er al vlug nood aan het verdelen van de HTTP requests onder de verschillende AS. Naast die drie AS kreeg elke applicatie één grote databankserver met 1,5 GB geheugen en 3 CPU cores. Zo zou de databank server geen bottleneck mogen vormen tijdens het testen van de AS.

7.3

Benchmarks

Er werd voor elke applicatie één load tester met WebLoadUI ingezet. Daarmee werden 2 benchmarks uitgevoerd, namelijk de bestellingen bekijken, zoals ook werd gebruikt in het vorige hoofdstuk, en het maken van een PDF met een overzicht van de bestellingen. Beide benchmarks zijn beschreven in Sectie 5.6. Dit zijn twee benchmarks die gebruik maken van de OrderBean, waarbij de eerste erg leunt op de databank wegens de statistieken over de bestellingen die opgehaald worden, terwijl de andere erg leunt op de AS aangezien er een PDF wordt aangemaakt die dan wordt weggeschreven op de harde schijf.

7.4 Resultaten

84

Opnieuw werd elke benchmark een kwartier gedraaid met 8, 16, 32, 64, 128 en 256 simultane bezoekers, met daartussen telkens een pauze van 20 minuten. Deze complete cyclus werd per benchmark 3 keer doorlopen.

7.4 7.4.1

Resultaten Bestellingen bekijken

Ook hier wordt eerst gekeken hoeveel keer het scenario kan voltooid worden binnen het kwartier. In Figuur 7.3 wordt dit weergegeven. Opnieuw kan opgemerkt worden dat in het begin het aantal uitgevoerde scenario’s verdubbelt bij het verdubbelen van het aantal simultane bezoekers. Vanaf 32 simultane bezoekers merken we echter dat die verdubbeling bij mod cluster stopt, terwijl dit bij de geclusterde OrderBean pas vanaf 128 simultane bezoekers is. Bij 128 simultane bezoekers worden plots heel wat verbindingen geweigerd bij gebruik van mod cluster. Bij de optelling met de geclusterde bean is dit pas bij 256 simultane gebruikers. De laadtijden van de pagina’s werden ook in kaart gebracht. In Figuur 7.4 is te zien dat de laadtijden bij lage belasting zo goed als gelijk zijn. Echter zorgt de mod cluster opstelling voor enkele uitschieters wanneer er meer simultane bezoekers gesimuleerd worden. Het is deze keer interessant om dieper in te gaan op de meetgegevens van zowel de testen met 64 als die met 128 simultane bezoekers, aangezien er bij beide iets opmerkelijks voordoet: Bij 64 stopt mod cluster met mee te schalen met het aantal simultane bezoekers, terwijl dit bij de geclusterde EJB zich pas voordoet bij 128 simultane bezoekers. De gegevens van de AS zijn te vinden in Figuur 7.5. Bij de opstelling met mod cluster wordt er een onderscheid gemaakt tussen de AS die zowel de load balancing doet als de applicatie aanbiedt (aangeduid met mod cluster LB) en de andere twee AS die enkel de applicatie aanbieden (aangeduid met mod cluster). Bij Clustered EJB wordt het onderscheid gemaakt tussen de AS die de volledige applicatie aanbiedt, hier webserver genoemd, en de andere 2 AS waarbij enkel de OrderBean gebruikt wordt. Het valt op dat mod cluster er beter in slaagt de processorbelasting gelijk te verdelen onder de AS. Bij de geclusterde OrderBean moet de webserver naast één derde van de OrderBean requests ook nog alle andere zaken afhandelen, zoals de JSF pagina’s renderen. Wanneer het netwerkverkeer bekeken wordt, is het duidelijk dat mod cluster veel dataverkeer vraagt. Dit kan

7.4 Resultaten

85

Aantal uitgevoerde scenario's: Mijn bestellingen 10000 9000 8000

Uitgevoerde scenario's

7000 6000 5000 4000

Gemiddelde van Err

3000

Gemiddelde van Ok

2000 1000

8

16

32

64 Schaalmethode Aantal simultane bezoekers

128

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

0

256

Figuur 7.3: Het aantal scenario’s dat uitgevoerd werd binnen één kwartier bij het uitvoeren van het scenario waarbij de reeds ingediende bestellingen worden opgevraagd

7.4 Resultaten

86



1,750

2,000

1,500

Page Load time (ms)

Page Load time (ms)

1,500 1,250

1,000

750

1,000

500 500 250

0

mod_cluster

0

Clustered EJB

mod_cluster

Schaalmethode

Clustered EJB

Schaalmethode Highcharts.com

Highcharts.com



20k

25k

20k

Page Load time (ms)

Page Load time (ms)

15k

10k

15k

10k

5k 5k

0k

mod_cluster

0k

Clustered EJB

Schaalmethode

mod_cluster

Clustered EJB


Highcharts.com


niet verklaard worden door verkeer van en naar de bezoeker, aangezien de clustered EJB opstelling meer scenario’s afhandelt en die minder netwerkverkeer verwerkt. Het verkeer moet dus te maken hebben met status-updates over de cluster. Wat ook nog opvalt is het geheugengebruik: De opstelling met mod cluster heeft meer vrij geheugen ten opzichte van de opstelling met de geclusterde EJB’s. Dit is opmerkelijk aangezien de op de mod cluster opstelling een extra httpd proces draait.

7.4.2

Bestellingen in PDF

In Figuur 7.6 wordt weergegeven hoeveel scenario’s uitgevoerd werden. Opnieuw kan opgemerkt worden dat in het begin het aantal uitgevoerde scenario’s verdubbelt bij het verdubbelen van het aantal simultane bezoekers en ook hier stopt deze trend vanaf 32 simultane gebruikers bij de mod cluster opstelling, terwijl dit pas bij 64 simultane bezoekers gebeurt voor de geclusterde bean opstelling. Bij 128 simultane bezoekers worden soms verbindingen geweigerd of HTTP code 500 terug gegeven bij gebruik van mod cluster. Het wegvallen of afwijzen van verbindingen gebeurt ook bij de geclusterde bean opstelling, maar hierbij doet zich dat pas voor bij 256 simultane bezoekers.

7.4 Resultaten

87



6

20

5 15

CPU load

CPU load

4

3

10

2 5 1

0

mod_cluster

mod_cluster LB

Clustered EJB

0

Clustered EJB Web Server

mod_cluster

mod_cluster LB

Type AS

Clustered EJB

Highcharts.com

Highcharts.com



500

400

400




Type AS

300

200

300

200

100

100

0

mod_cluster

mod_cluster LB

Clustered EJB

0


mod_cluster

mod_cluster LB

Type AS

Clustered EJB

Highcharts.com


500

500

400

400




300

200

100

0

300

200

100

mod_cluster

mod_cluster LB

Clustered EJB

0


mod_cluster

mod_cluster LB

Type AS

Clustered EJB

Highcharts.com

Highcharts.com


15k

12.5k

10k

Bandbreedte (Kbps)

Bandbreedte (Kbps)

12.5k

10k

7.5k

5k

7.5k

5k

2.5k

2.5k

mod_cluster

mod_cluster LB

Clustered EJB

0k


mod_cluster

mod_cluster LB

Type AS

Clustered EJB

Highcharts.com

Highcharts.com


25k

30k

25k

Bandbreedte (Kbps)

20k

Bandbreedte (Kbps)


Type AS


15k

10k

5k

0k


Type AS


0k


Type AS Highcharts.com

20k

15k

10k

5k

mod_cluster

mod_cluster LB

Clustered EJB


Type AS

0k

mod_cluster

mod_cluster LB

Clustered EJB



Highcharts.com

Figuur 7.5: De meetgegevens van de AS bij 64 (links) en 128 (rechts) simultane bezoekers die het hun bestellingen bekijken.

7.4 Resultaten

88

Aantal uitgevoerde scenario's: PDF met bestellingen 12000

Uitgevoerde scenario's

10000

8000

6000

4000

Gemiddelde van Err Gemiddelde van Ok

2000

8

16

32

64 Schaalmethode Aantal simultane bezoekers

128

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

Clustered EJB

mod_cluster

0

256

Figuur 7.6: Het aantal scenario’s dat uitgevoerd werd binnen één kwartier bij het uitvoeren van het scenario waarbij de reeds ingediende bestellingen worden opgevraagd

7.4 Resultaten

89

Bestellingen in PDF, 8 simultane bezoekers


2,000

6k

5k

Page Load time (ms)

Page Load time (ms)

1,500

1,000

4k

3k

2k

500 1k

0

mod_cluster

0k

Clustered EJB

mod_cluster

Schaalmethode

Clustered EJB


Highcharts.com


30k

30k

25k

25k

Page Load time (ms)

Page Load time (ms)


20k

15k

10k

5k

0k

20k

15k

10k

5k

mod_cluster

0k

Clustered EJB

Schaalmethode

mod_cluster

Clustered EJB


Highcharts.com


De laadtijden van de pagina’s worden ook deze keer weergegeven met behulp van boxplots. In Figuur 7.7 is te zien dat de laadtijden bij lage belasting zo goed als gelijk zijn, enkel is er een grotere variatie bij de mod cluster opstelling. Bij 128 simultane gebruikers zien we echter dat de laadtijden voor mod cluster een pak hoger zijn dan die van de andere opstelling. Deze keer wordt er dieper ingegaan op de tests met 64 en 128 simultane bezoekers. De gegevens van de AS zijn te vinden in Figuur 7.8. Bij de opstelling met mod cluster wordt er een onderscheid gemaakt tussen de AS die zowel de load balancing doet als de applicatie aanbiedt (aangeduid met mod cluster LB) en de andere twee AS die enkel de applicatie aanbieden (aangeduid met mod cluster). Bij Clustered EJB wordt het onderscheid gemaakt tussen de AS die de volledige applicatie aanbiedt, hier webserver genoemd, en de andere 2 AS waarbij enkel de OrderBean gebruikt wordt. Hier is te zien dat in dit scenario de processorbelasting veel beter verdeeld wordt bij de geclusterde EJB opstelling dan bij het vorige scenario. Dit komt doordat de OrderBean nu veel te doen heeft, die gaat namelijk de PDF genereren. Waarom de CPU load zo hoog is ten opzichte van mod cluster is niet helemaal duidelijk.

7.4 Resultaten

90



25

40

20

CPU load

CPU load

30

15

20

10

10 5

0

mod_cluster

mod_cluster LB

Clustered EJB

0


mod_cluster

mod_cluster LB

Type AS

Clustered EJB

Highcharts.com

Highcharts.com


1,500

1,500

1,250

1,250




1,000

750

500

250

0

1,000

750

500

250

mod_cluster

mod_cluster LB

Clustered EJB

0


mod_cluster

mod_cluster LB

Type AS

Clustered EJB

Highcharts.com



500

500

400

400





300

200

100

0


Type AS

300

200

100

mod_cluster

mod_cluster LB

Clustered EJB

0


mod_cluster

mod_cluster LB

Type AS

Clustered EJB



Highcharts.com



8k

15k

12.5k

Bandbreedte (Kbps)

Bandbreedte (Kbps)

6k

4k

10k

7.5k

5k

2k 2.5k

0k

mod_cluster

mod_cluster LB

Clustered EJB

0k


mod_cluster

mod_cluster LB

Type AS

Clustered EJB

Highcharts.com

Highcharts.com


40k

40k

30k

30k

Bandbreedte (Kbps)

Bandbreedte (Kbps)


20k

10k

0k


Type AS

20k

10k

mod_cluster

mod_cluster LB

Clustered EJB


Type AS

0k

mod_cluster

mod_cluster LB

Clustered EJB



Highcharts.com

Figuur 7.8: De meetgegevens van de AS bij 64 (links) en 128 (rechts) simultane bezoekers die een PDF genereren met hun bestellingen.

7.5 Conclusie

7.5

91

Conclusie

In dit hoofdstuk werd gesteld dat er een mogelijke snelheidswinst zou kunnen geboekt worden indien er op de schaal van EJB’s wordt geschaald. Met de twee voorbije testen is het erg duidelijk dat er voordelen zijn verbonden met het dupliceren van EJB’s in plaats van volledige applicaties in een cluster te steken. Zeker bij EJB’s die intensief gebruikt kunnen worden, kan het voordelig zijn deze te load balancen. Bij het bekijken van reeds gevoerde bestellingen konden met de geclusterde EJB opstelling meer dan twee keer zoveel scenario’s worden afgewerkt als de opstelling met mod cluster. Bij het maken van een PDF werden zelfs meer dan 3 keer zoveel scenario’s uitgevoerd. Uiteraard is hier een ideaal geval voorgesteld waarbij enkel de OrderBean werd geclustered en ook enkel scenario’s werden gebruikt die pagina’s bevatten waarin de OrderBean wordt gebruikt. De resultaten geven aan dat het interessant zou zijn om een compleet systeem op te stellen waarbij EJB’s automatisch en dynamisch verdeeld worden over AS. Het feit dat EJB’s al in een cluster kunnen geplaatst worden die zichzelf automatisch aanpast naargelang er AS bijkomen of weggaan, maakt het een interessante piste om op verder te bouwen. Het maken van een dergelijk systeem heeft wel heel wat voeten in de aarde: Zo zal er een clusteringsalgoritme moeten gevonden worden die de EJB’s identificeert die veel met elkaar communiceren en moet er een systeem uitgedacht worden om EJB’s afzonderlijk te monitoren zonder dat dit een grote overhead tot gevolg heeft. Daarmee zouden dan goede beslissingen gemaakt kunnen worden over welke EJB’s geschaald moeten worden, en welke EJB’s best bij elkaar worden gehouden. Ook zou er best ondersteuning komen in IDE’s om EJB’s gemakkelijk te extraheren uit projecten, samen met hun dependencies. Daarnaast zou JBoss ook aangepast moeten worden opdat er geen externe verbinding vereist is om de eerste communicatie te starten met een EJB cluster. Het maken van dit systeem zou dus heel wat werk vergen, maar de resultaten geven aan dat dit een enorme snelheidswinst zou kunnen opleveren.

CONCLUSIE

92

Hoofdstuk 8

Conclusie In deze masterproef werd een PaaS systeem, Advanced Scalable Platform (ASP) ontwikkeld dat gebruikt kan worden om verschillende opstellingen te testen. Dit platform werd ontwikkeld met behulp van Eucalyptus, een IaaS pakket, in combinantie met Chef, die alle configuratie op zich neemt. Dit systeem heeft als voordeel erg flexibel te zijn. Door zijn relatieve eenvoud kunnen er gemakkelijk aanpassingen gedaan worden. Ondanks zijn eenvoud, is door het maken van een frontend bewezen dat dit systeem in principe zou uitgebouwd kunnen worden tot een bruikbaar product. Met ASP werd dan enerzijds het schalen van databanken bekeken en anderzijds het schalen van applicatie servers. Om verschillende testen uit te voeren, werd er eerst een use case uitgezocht. Met Duke’s Forest werd een realistische use case gevonden. Met deze use case werden dan benchmarks geschreven die realistische scenario’s emuleren, zoals aankopen doen in de webwinkel. Bij het openstellen van een applicatie aan meerdere gebruikers, moet er een multi-tenancy model gekozen worden. In deze masterproef werd de performantie vergeleken van drie modellen, namelijk Shared Nothing, Shared Instance en Shared Table. De performantie werd gemeten door telkens een opstelling te maken waarbij elke applicatie drie gebruikers had. De applicatie van de drie gebruikers werd dan gelijktijdig getest aan de hand van de benchmarks. Shared Nothing bleek onder die omstandigheden best te presteren, terwijl Shared Table duidelijk leidt onder het feit dat er altijd met grote tabellen gewerkt moet worden. Echter moet gezegd worden dat performantie zeker niet het enige selectiecriteria is bij het kiezen voor een multi-tenancy omgeving. Zo heeft Shared Nothing bijvoorbeeld het voordeel de gege-

CONCLUSIE

93

vens van de klanten heel duidelijk te scheiden, terwijl Shared Table en Shared Nothing voordeel zullen behalen wanneer de belasting tussen de gebruikers niet evenredig is. Het gebruik van sharding om Shared Table omgevingen te partitioneren kan ook een zeer interessant model zijn. Dit model werd echter niet getest omdat hier erg veel mogelijkheden voor zijn. Verder onderzoek zou hier mee aan de slag kunnen gaan. Na het schalen van de databanken, werd een schaalmethode voorgesteld voor AS. Deze methode schaalt op het niveau van EJB’s en dupliceert die over verschillende AS. Zwaar belaste EJB’s zouden zo op veel AS terecht komen, terwijl andere misschien slechts op één AS geactiveerd zijn. Om dit systeem te implementeren zouden er echter nog heel veel ondersteunende systemen moeten worden uitgewerkt, wat buiten het bestek van deze masterproef viel. Daarom werd er één opstelling gemaakt die door dit systeem opgesteld zou kunnen zijn. Zo werd één EJB geclustered en verdeeld over verschillende AS, terwijl de overige zaken uitgevoerd werden door slechts één AS. Deze opstelling werd vergeleken met het klassieke systeem waarbij AS in hun geheel gedupliceerd worden, waarbij er een load balancer wordt ingezet die de requests verdeeld. Wanneer de twee opstellingen werden vergeleken, werd duidelijk dat het systeem waarbij de EJB is gedupliceerd veel beter presteert in de testen. Dit nodigt dus uit om het syteem in verder onderzoek effectief te implementeren, waarna het duidelijk zou worden welke snelheidswinst geboekt kan worden in andere scenario’s. Nu het hele platform is opgezet, is er ruimte voor uitbreiding. Zo zou het interessant zijn om ASP eens in te zetten zonder gebruik te maken van virtualisatie. Zo zou de prestatie-impact van virtualisatie in concrete cijfers kunnen worden omgezet. Zoals ook al gezegd zou het interessant zijn om sharding toe te voegen aan het systeem, samen met een dynamisch systeem om EJB’s te schalen. Ook kan ASP uitgebreid worden zodat het compatibel wordt met de auto scaling functionaliteit van Eucalyptus. Op die manier kan opnieuw een zeer realistisch scenario concreet getest worden. Het is duidelijk dat de resultaten van deze masterproef slechts een deel zijn van het hele cloudverhaal. Toch geven de resultaten al antwoord op enkele vragen, en kunnen ze een richting geven voor verder onderzoek, terwijl het ASP systeem kan gebruikt worden als basis om grotere testen op te stellen.

BIBLIOGRAPHY

94

Bibliography [Agrawal et al., 2011] Agrawal, D., Das, S., and El Abbadi, A. (2011). Big data and cloud computing: current state and future opportunities. In Proceedings of the 14th International Conference on Extending Database Technology, page 530533. [Alin Tomescu, 2013a] Alin Tomescu (2013a). How to compile and install eucalyptus 3.2.0 on ubuntu 12.04 from GitHub sources (cloud-in-a-box). http://alinush.org/2013/02/19/howto-compile-and-install-eucalyptus-3-2-0-on-ubuntu-12-0412-10-from-github-sources-cloud-ina-box/. [Alin Tomescu, 2013b] Alin Tomescu (2013b). How to compile and install eucalyptus 3.3.0 on ubuntu 13.04 from GitHub sources (cloud-in-a-box). https://alinush.org/2013/07/21/how-tocompile-and-install-eucalyptus-3-3-0-on-ubuntu-13-04-from-github-sources-cloud-in-a-box/. [Angus Kidman, 2007] Angus Kidman (2007). How google keeps its database ticking. ZDNet. [Asheesh Raina, 2012] Asheesh Raina, L. F. W. (2012). Market trends: Application development software, worldwide, 2012-2016. Technical report, Gartner. [Castellina, 2011] Castellina, N. (2011). SaaS and cloud ERP trends, observations, and performace 2011. [Christine Burns, Network World, 2013] Christine Stack

wars:

OpenStack

v.

CloudStack

Burns, v.

Network

eucalyptus

World -

network

(2013). world.

http://www.networkworld.com/supp/2013/enterprise3/060313-ecs3-open-stack-269899.html. [Cihan Biyikoglu, 2011] Cihan tenant

database

Biyikoglu

model

made

(2011). easy

Moving with

sql

azure

to

multi-

federations.

http://blogs.technet.com/b/kevinremde/archive/2011/04/03/saas-paas-and-iaas-oh-myquot-cloudy-april-quot-part-3.aspx.

BIBLIOGRAPHY

95

[Daniel Kranowski, 2012] Daniel Kranowski (2012).

CloudStack vs OpenStack vs eucalyp-

tus: IaaS private cloud brief comparison. http://www.slideshare.net/bizalgo/cloudstack-vsopenstack-vs-eucalyptus-iaas-private-cloud-brief-comparison. [Eucalyptus, 2012] Eucalyptus

(2012).

The

eucalyptus

cloud.

http://www.eucalyptus.com/eucalyptus-cloud/iaas. [Ignacio M. Llorente, 2013] Ignacio M. Llorente (2013). Eucalyptus, CloudStack, OpenStack and OpenNebula: a tale of two cloud models. http://blog.opennebula.org/?p=4042. [Kevin Remde, 2011] Kevin Remde (2011). SaaS, PaaS, and IaaS.. oh my! (”Cloudy april” part 3). http://blogs.technet.com/b/kevinremde/archive/2011/04/03/saas-paas-and-iaas-ohmy-quot-cloudy-april-quot-part-3.aspx. [Koschel et al., 2011] Koschel, A., Schneider, T., Westhuis, J., Westerkamp, J., Astrova, I., and Roelofsen, R. (2011). Providing load balancing and fault tolerance in the OSGi service platform. In Proceedings of the 13th WSEAS international conference on Mathematical and computational methods in science and engineering, page 426430. [Lau et al., 2012] Lau, C., Birsan, V., and Madapusi, B. (2012). Convert single-tenant applications into multi-tenant applications. http://www.ibm.com/developerworks/cloud/library/cltenantconversion/index.html. [Marten Mickos, 2011] Marten

Mickos

(2011).

Ubuntu,

linux,

and

eucalyptus.

http://www.eucalyptus.com/blog/2011/05/11/ubuntu-linux-and-eucalyptus. [Mell and Grance, 2011] Mell, P. and Grance, T. (2011). The NIST definition of cloud computing. http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf. [Michael et al., 2007] Michael, M., Moreira, J. E., Shiloach, D., and Wisniewski, R. W. (2007). Scale-up x scale-out: A case study using nutch/lucene. In Parallel and Distributed Processing Symposium, 2007. IPDPS 2007. IEEE International, page 18. [Microsoft, 2012] Microsoft (2012).

Developing applications for the cloud, 2nd edition.

http://msdn.microsoft.com/en-us/library/ff966499.aspx. [Miller, 1968] Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I, AFIPS ’68 (Fall, part I), pages 267–277, New York, NY, USA. ACM.

BIBLIOGRAPHY

96

[OSGi Alliance, ] OSGi Alliance. The OSGi architecture. [Osipov et al., 2009] Osipov, C., Goldszmidt, G., Taylor, M., and Poddar, I. (2009). Develop and deploy multi-tenant web-delivered solutions using IBM middleware: Part 2: Approaches for enabling multi-tenancy.

http://www.ibm.com/developerworks/webservices/library/ws-

multitenantpart2/. [Puppet Labs, ] Puppet Labs. Puppet labs: IT automation software for system administrators. [Rellermeyer et al., 2007] Rellermeyer, J. S., Alonso, G., and Roscoe, T. (2007). Building, deploying, and monitoring distributed applications with eclipse and r-OSGI. In Proceedings of the 2007 OOPSLA workshop on eclipse technology eXchange, page 5054. [salesforce.com, 2013] salesforce.com (2013).

Record-level access:

Under the hoods.

http://www.salesforce.com/docs/en/cce/record access uth/salesforce record access under the hood.pd [Schmidt et al., 2009] Schmidt, H., Elsholz, J. P., Nikolov, V., Hauck, F. J., and Kapitza, R. (2009). OSGi 4C: enabling OSGi for the cloud. In Proceedings of the Fourth International ICST Conference on Communication System software and middleware, page 15. [Shoup, 2008] Shoup, R. (2008). eBays architectural principles. [The Apache Software Foundation, a] The Apache Software Foundation. Apache CXF – distributed OSGi. [The Apache Software Foundation, b] The Apache Software Foundation. Apache CXF – DOSGi discovery demo page. [The OSGi Alliance, 2009] The OSGi Alliance (2009). pendium.

OSGi service platform service com-

ERRATA

97

Bijlage A

Errata Pagina

Opmerking

iv

API: Application Programming Interface: een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel (meestal in de vorm van bibliotheken).

27

Bij Shared Instance wordt vermeld dat er één databank is per klant. Dit klopt echter niet, er is namelijk een aparte databank voor elke gebruiker. Bij Shared Table zal er een veld gebruikt worden dat aangeeft bij welke gebruiker de record hoort, niet bij welke klant.

84

De titel van de grafiek moet zijn “Aantal uitgevoerde scenario’s: Bestellingen bekijken”.

Geavanceerde schaalmethodes voor PaaS providers

Recommend Documents