Final Year Dissertation

raspgiantsneckServers

Dec 9, 2013 (3 years and 10 months ago)

191 views






Final Year Dissertation

Deliverable one


Autonomous Cloud Brokering


Ryan Gardiner

Computer Science

Heriot
-
Watt University

Supervisor: Prof. Phil Trinder

2




Abstract


Advancements in recent years on grid computing and networking has brought about the conc
ept of
cloud computing. Cloud computing aims to deliver various services to end users over the internet.
There are now many different cloud providers and in years to come the cloud market is set to
expand further.


The objective of this University dissert
ation is to explore how a cloud broker service can manage
available cloud computing environments. Many clouds offer the same or similar services, but offer
varying amounts of resources at different costs. The proposed broker will gather data of the cost
and
performance attributes of different clouds, and then this data will be used to enable Autonomous
Mobile Programs (AMP) to execute across multiple cloud service providers. The data that the
broker holds allows AMPs to decide where best to execute on a c
loud, based on time and cost
considerations. The aim of the broker is to allow AMPs to execute on the cloud that will provide the
fastest execution for the lowest cost, or the lowest costing cloud that will satisfy a maximum
execution time limit.


The proj
ect explores the concept and principles of how an AMP based cloud broker could be
produced. An analysis of current available cloud providers that are potentially suitable for this
project will be carried out. The project also looks at multiple criteria opt
imisation algorithms which
will be used by the AMPs to determine the best available cloud to execute on.





3



Contents

Chapter 1













3


Introduction












3

1.1

Context











3

1.2

Aims and Objectives









4

1.3

Document Structure









4

Cha
pter 2













5


Background












5



2.1 Cloud Computing










5



2.1.1 Introduction to Cloud Computing







5

2.1.2 Concept











6



2.1.3 Cloud Services










7



2.1.4 Classes of Cloud









9



2.1.5 Cloud Middle
-
ware








10



2.1.6 Cloud Providers









12



2.1.7 Cloud Brokers









14



2.2 Autonomous Mobile Programs







15



2.2.1 Concept










15



2.2.2 Mobility










16



2.2.3 AMP Cost Models








16



2.2.4 Mobile Languages








17

Chapter 3












19


System and Experiment Design








19



3.1 Outline










19



3.2 StACC System Architecture







19



3.3 System Architecture and Design







20



3.4 Experiment Design








21



3.4.1 Scenario 1


Time Considerations






21

3.4.2
Scenario 2


Cost Considerations






23

3.4.3 Scenario 3


Time Cost Considerations





26

References












27

Appendices












30


4






Chapter 1


Introduction


1.1

Context

In recent years, cloud computing has taken off as a means of delivering servic
es over the internet.
Cloud computing has become a feasible alternative to traditional hosted solutions, offering benefits
to both end users and cloud providers. There are now many clouds that offer similar services at
varying levels of performance and co
st, and it can be hard to distinguish between the offerings of
multiple cloud providers. This project looks at a way of selecting a cloud based on the performance
and cost requirements of the user, in order to find the best cloud to execute on.

Research in
to mobile agents has spawned a type of autonomous system known as Autonomous
Mobile Programs (AMPs) [13]. These agents are aware of their resource needs and gather
information about the environment in which they execute. Using this information they can
dyn
amically relocate themselves to other network locations, aiming to find the optimal execution
location. AMPs use cost models to work out the best location. Multi
-
objective optimisation
algorithms have been explored and adapted to produce the AMPs cost mode
ls so that they can find
the optimal network location.

This project takes into account previous research and aims to develop a novel broker system for
clouds, using AMPs and multi
-
objective optimisation. The broker will be a prototype and as such
will run
on a single cloud and use computational instances to model other clouds.


5




1.2

Aims and Objectives

This project aims to prototype a cloud selection service that determines the best cloud to execute on,
based on performance and cost requirements. The broker anal
yses the cost and performance
properties of different clouds and then Autonomous Mobile Programs use this data to find the best
cloud to execute on based on the users requirements. A series of experiments will be carried out to
prove the concept of this c
loud broker system.

The objectives of the project are as follows:



to undertake a literature survey on cloud computing, AMPs, Cloud brokering and multi
-

objective optimisation



to analyse and identify suitable clouds to use with the broker



to design and cons
truct an AMP cloud broker system to select between alternative clouds

based on current price and performance properties



to perform experiments on this cloud broker system using an available cloud



to investigate suitable multi
-
objective optimisation techni
ques for AMP cloud brokering


1.3

Document Structure

This document contains the initial analysis and planning of the cloud broker system.

Chapter 2 contains a review of technical literature. In this chapter cloud computing is discussed and
key cloud concepts a
re introduced. A background is given to AMPs and code mobility and what the
cost models are for this project.

Chapter 3 closes with the design of the system and experiments. The overall system architecture is
described before a detailed outline of the exp
eriments is shown.

The project timeline is included in the appendix.



6






Chapter 2


Background


2.1

Cloud Computing

This section introduces the concept of cloud computing. Section 2.1.1 starts with an introduction to
cloud computing. In Section 2.1.2 the
concept is outlined before Section 2.1.3 discusses the
different services that are offered by clouds. Section 2.1.4 introduces cloud classes. In Section 2.1.5
virtualization is outlined. Cloud Middle
-
ware is described in Section 2.1.6 before a selection of

available clouds are outlined in Section 2.1.7. Section 2.1.8 describes cloud brokers.


2.1.1

Introduction to Cloud Computing

Cloud Computing refers to a computing environment that provides highly optimised web
-
based
services in an on demand basis. Cloud

providers offer end users cloud services which are accessed
over the internet. In between the providers and users are the cloud brokers, whose aim is to
determine which platform best suits the end users needs [1]. Cloud brokering is a new idea and as
such

is not well developed.

Cloud Computing is a recent concept that has only recently been defined. It is a description of a

7



computer infrastructure that can be utilised in different ways in order to provide services over the
internet. Although there are many

different interpretations of cloud computing, and there is no exact
definition, there are attributes which are common to all cloud services [1]:




Off premise
-

the cloud services are hosted and accessed over the public internet. The end
user is unaware of

the location of their data on the cloud. This means the provider is
responsible for the security of its user’s data as well as the reliability of its service.



Elasticity
-

the cloud model offers the end users a flexible service. This means the service
pro
vision can easily be scaled up or down based on the end user demand.



Flexible Billing
-

due to the elastic nature of the services provided the user only pays for
what they need to use. This removes the traditional approach to computing where end users
wil
l purchase applications and run in house irrespective of the varying nature of the demand.



Universal Access
-

because of the dispersed nature, the services can provide high levels of
resilience, offering an always connected user experience at a low cost o
f delivery.


2.1.2

Concept

Cloud computing refers to both the applications delivered as services over the internet and the
hardware and systems in the data
centers

that provide those services. It has the potential to change
the way hardware and software i
s designed, and more importantly how it is utilised and purchased.

It is made possible by large data centres of tens of thousands of computers
-

constructed and
operated in low cost locations
-

which enable reduction in cost of electricity, network bandwid
th,
software, hardware and the appropriate maintenance required to run such a facility. This decrease in
cost due to economies of scale can be as much as a factor of 7, and these savings can be passed on
to cloud users making cloud services a viable altern
ative to hosted services [2].

As well as cost decreases, cloud computing can offer faster solutions to data processing compared

8



to other services. Batch tasks can be carried out quickly since it costs the same to use 1000 servers
for 1 hour as it does 1 se
rver for 1000 hours.


2.1.3


Cloud Services

C
loud services are broadly divided into 3 categories; Infrastructure as a Service (IaaS), Platform as
a Service (PaaS) and Software as a Service (SaaS). There is a relationship between these 3
categories; their

services differ according to their degree of flexibility and optimisation (figure 2.1).
Typically SaaS offerings are highly standardised and tuned for efficiency, with minimum ability for
the end user to customise. On the other hand IaaS offers users the
ability to customise the service
and host almost any application, but this raises standardisation issues. PaaS is the middle ground
between the other categories, offering flexible frameworks with some degree of customisation [1].
Generally a cloud provider

will offer one of these categories, but there can be cases where a service
does not fall exactly into one category or the other.


Figure 2.1


Software, Platform and Infrastructure Services [1]


Software as a Service

Software as a Service is the common na
me for applications that are hosted by service providers and

9



made available to consumers over a network (usually the internet) on demand. Since the
applications are run on the provider's infrastructure the services can be centrally managed and
updated. Thi
s eliminates the need for companies to install and run the applications on their own
infrastructure and simplifies the process of updating and patching software. Administration is also
managed by the provider, giving them centralized control over versionin
g, so the consumer does not
have to worry about compatibility issues as everyone will get the same version of the product that is
being provided. Salesforce is one of the most popular SaaS providers and is discussed in more detail
in Section 2.1.6


Infrast
ructure as a Service

Infrastructure as a Service is providing computer infrastructure to consumers. This infrastructure is
often a virtualized environment, and is accessed by the consumer over the internet. Rather than
investing in high cost servers, netwo
rk hardware, data storage and the software required to run and
manage these systems, clients buy these resources from a provider as a service. This type of service
will be the most useful for this project as it will allow the creation of virtual machine in
stances on
which programs can be run to perform experiments. Two examples of this type of service, Amazon
Elastic Compute and St. Andrews Collaboration Cloud, are detailed in Section 2.1.6


Platform as a Service

This service is the provision of platforms f
or building and running custom applications without the
cost of buying and managing the underlying hardware and software layers. A platform is provided
to support the complete software development life cycle from the design stage to testing and
deployment.

Various tools and services are provided to assist in the development process such as
team collaboration services, security and storage. This is provided over the internet meaning that
development can take place anywhere. Microsoft and Google are the big n
ames offering cloud

10



services in this category. More information is given in Section 2.1.6 about these companies' cloud
offerings.


2.1.4

Classes of Cloud

Clouds can be deployed in alternative ways depending on their intended use. Each class of cloud
has
different security and management issues associated with them as described below [3].


Private Cloud

This class of cloud is one which is available only to one organisation. Users of a private cloud are
given access to virtual computing resources from withi
n the organisation via a web
-
based portal.
The cloud is managed internally by the organisation itself and therefore it has control over security
and the location of it’s' data.


Public Cloud

Public clouds make resources available to the general public ove
r the internet. A public cloud
provider allows access to their service on a pay
-
as
-
you
-
go basis where the user can choose the
resources they require according to their needs. In this case the security is managed by the cloud
provider and so the user has le
ss control over their data.


Community Clouds

Community clouds are created by organisations with similar requirements and intentions. The
infrastructure is shared between the organisations which spreads the cost but means security can be
more of an issue s
ince there are more users able to access data.


Hybrid Clouds


11



A Hybrid Cloud combines resources from at least two or more clouds, as shown in figure 2.2. The
clouds remain unique entities but transfer data between themselves through standardised or
proprie
tary technologies that allows portability of data and applications.


F
igure 2.2
-

Hybrid Cloud

For the purpose of this project, the class of cloud that is used is not critical since there will be no
sensitive data involved. The only constraint is that the

cloud will need to be accessible from within
Heriot
-
Watt University.


2.1.5

Cloud Middle
-
ware

This section discusses some of the underlying technologies of clouds. Virtualisation is a key
concept which is used in all clouds to provide elastic resourcing. Eucal
yptus is a means of creating a
cloud, which makes use of virtualisation to add more computing instances when required the user.


Virtualization

Allowing virtual machines (VMs) to run on physical servers is a key feature required to make cloud
computing fea
sible. High flexibility is possible due to the ability to add more VMs when demand

12



goes up and remove them when demand goes down, without affecting other VMs. The cloud
provider has the flexibility to modify the resources assigned to virtual cloud nodes, s
uch as RAM,
disk space, CPU speed etc. This provides the user with the illusion of infinite capacity as the
virtualization of the cloud hides the implementation of how the resources are shared. Running many
VMs on a single hardware server also allows the p
rovider to utilise more of the server capacity [4].
This project will make use of virtual machines on an IaaS cloud to run Java programs as part of the
experiments to test the broker system.


Eucalyptus

This project will involve simulating different cloud
s in order for the proposed broker system to be
tested. There are many available cloud providers that offer access on a pay as you go basis but
Eucalyptus makes it possible to set up a cloud on available infrastructure, which is suitable for the
purpose of

this project since it is a simulation and there are limited funds available. The university
of St. Andrews have set up a cloud on their infrastructure using Eucalyptus (Section 2.1.6), and this
will be the cloud that the prototype broker will be developed

to run on.

Eucalyptus is not a cloud itself, but a means of creating clouds on computer clusters. It allows
clouds to be set up on networks varying in size from small home networks to large scale networks
used by businesses or academic institutions. Eucal
yptus is

open
-
source so any interested body can
add to the framework to enhance its features.

A Eucalyptus cloud allows the implementation of clouds that provide Infrastructure as a Service [5].
Users can set up instances of virtual machines on the cloud a
nd then utilise them as required.

Once a Eucalyptus environment has been set up, users can manage and maintain their VM instances
using tools (e.g. euca2ools [6]) specifically developed for this purpose. The VMs can then be used
to run programs on the clo
ud. Users of Eucalyptus interact with the system using similar tools and
interfaces that are used to interact with other IaaS clouds, such as Amazon EC2, which introduces a

13



level of interoperability between Eucalyptus clouds and Amazon Web Services.


2.1.6


Cloud Providers

This section looks at available clouds and their suitability to this project. There are many cloud
providers offering their particular version of services that fall into the categories in Section 2.1.3.
Listed below are some of the popul
ar clouds that are available.


Google

Google App Engine is a platform that allows the development and hosting of web applications
which can be deployed on Google's cloud infrastructure. The platform makes it easy for developers
to build, maintain and scale

their applications as traffic and storage needs change. It removes many
of the system administration concerns and ensures that applications run quickly, securely, and
without interference from other apps on the system [8].

Google App Engine supports apps

written in several programming languages. It uses a Java runtime
environment allowing development in any language that uses a JVM based interpreter or compiler.
It also features a Python runtime environment.

The platform is set up so that developers only
pay for what they use. The resources an application
uses are measured and billed, and there are no set up charges or recurring fees.


Microsoft Azure

The Windows Azure Platform is Microsoft's cloud service. Like Google App Engine, it is a platform
as a ser
vice, offering a means of software development on Microsoft's cloud using their .NET
framework. SDKs have also been released for Java and Ruby, allowing applications to be built in
these languages and deployed on the cloud.

Windows Azure has
three core co
mponents, namely Compute, Storage and Fabric. Compute is the

14



provision of computation, Storage the access to scalable data storage, and Fabric is the physical
architecture of the cloud [9]. One of the main advantages of Azure is that it integrates with the

popular IDE Microsoft Visual Studio.


SalesForce

Salesfore.com is arguably the best known SaaS provider. It provides Customer Relationship
Management software which allows organisations to interact and communicate more effectively
with their customers and

other organisations [10].

Salesforce services are available in over 20 languages and can be accessed from many different
internet enabled devices including mobile phones. Users are able to customise what they see and
configure data types to shape the serv
ice to their needs.


Amazon

Amazons' cloud services are titled Amazon Elastic Compute Cloud (EC2) from Amazon Web
Services (AWS) [7]. Amazon EC2 offers computing infrastructure over the internet. It sells various
configurations of computing instances as v
irtual machines, and also offers storage capacity. Each
instance can be set up by the user and there are options to run a number of different operating
systems depending on the user’s needs.

The computing capacity is resizable, and creating new instances o
f VMs takes minutes, allowing
users to quickly scale capacity up and down as computing requirements change.
Users are billed on
a pay
-
as
-
you
-
go basis for the instances they require, with higher costs for configurations with more
memory or faster processor
speed.

Although EC2 is an example of IaaS, and therefore is a potential option for this project, it requires a
credit card to be activated in order to use the service. Due to this charge to use the cloud it will not
be suitable for this project.


15




St. Andre
ws Collaboration Cloud (StACC)

StACC is an academic cloud environment that has been implemented by the computer science
department of St. Andrews University. Set up in 2009, it is built on the Eucalyptus software
framework (as discussed in Section 2.1.5) a
nd is one of the first of its kind in the UK [11]. The
cloud has been set up as an initiative into research and teaching in cloud computing and to provide
means of performing software experiments. StACC aims to provide guidance to businesses and
organisati
ons that are interested in moving their IT systems onto the cloud.

Access to the StACC cloud is possible using euca2ools, allowing users with internet access to
remotely log into the cloud and instantiate VMs to use for software experiments.

StACC allows
the implementation of Infrastructure as a Service clouds, which was highlighted as a
suitable service type in Section 2.1.3. Access to StACC is free since it is an academic cloud. For the
purpose of this project this cloud will be used in order to set up t
he environment required to run the
proposed experiments on. (See Chapter 3 with experiment plan)


2.1.7

Cloud Brokers

Cloud brokers are an intermediary between providers and end users. As shown in Section 2.1.6,
there are now many clouds available and man
y of them offer very similar services at different
prices. Cloud brokers aim to assist users in choosing the best cloud platforms and services based on
a user’s requirements and budget.

There are 3 main classifications of cloud brokers [12]:




Added Value S
ervice Brokers. These brokers enhance existing service providers’ platforms
by offering add
-
on functions on top of services from other cloud providers. These are
typically security, administration, identity management and other common functions across

16



diff
erent application requirements. This combination provides a completed service to the
end user. These brokers are commonly referred to as Cloud Service Intermediaries.



Connect Brokers


These brokers join together multiple services to create the complete en
d
user application. These offer seamless interoperability with integrated data security. These
are commonly referred to as aggregate brokers.



Choice Brokers


There are many cloud providers that offer similar services. The choice
broker analyses the availa
ble providers and offers the best options to the user based on their
needs.


The broker proposed in this project falls into the choice broker category. It is concerned with the
cost and performance characteristics of available clouds and will attempt to op
timise execution
location based on time and cost limits set by the user.



2.2

Autonomous Mobile Programs

This section looks at code mobility, mobile agents and specifically Autonomous Mobile Programs.
Section 2.2.1 outlines the concept of AMPs and how t
hey differ from other mobile agents. In
Section 2.2.2 the concept of code mobility is described. Section 2.2.3 looks at AMP cost models.
Mobile languages are discussed in Section 2.2.4.


2.2.1


Concept

This project looks at Autonomous Mobile Program (AMP)
technology and how it could be used as
part of the cloud broker system. The use of AMPs is what will allow fragments of code to move
between clouds. Autonomous Mobile Programs are mobile agents which are aware of their

17



processing needs and are sensitive to

the environment in which they execute. They are able to
dynamically relocate themselves to minimise processing time depending on varying loads on
executing environments [13].

AMPs use local and external information regarding load on the current executing
environment to
determine whether they should continue to execute where they are or move to a different location.
AMPs differ from other mobile agents in that rather than relying on some external system, they
make the decisions themselves on when and where
to move according to the information they
gather about the environment [14].


2.2.2


Mobility

Code mobility is the concept of running code which can dynamically change the bindings between
code fragments and the location where they are executed [15]. This
project is concerned with code
mobility since it will involve moving programs between different clouds in order to find the best
cloud. There are two classifications of code mobility:



Strong code mobility is the ability to move both code and execution stat
e as well as data
from one location to another. Since the execution state is transferred it is possible for the
code to continue executing on the new location from the point it was at before it moved.



Weak code mobility is the ability to move just the code

and data. In this case it is possible
that execution would have to be restarted on the destination location since there is no
information about what the state was before migration.


2.2.3


AMP Cost Models

AMPs have cost models which are used to determine
when and where to move according to
conditions specified by the programmer (such as total execution time or cost of execution)
[14]
.

The main rule which an AMP looks at to determine whether it should move to a different location is

18



whether execution time a
t the current location (Th) exceeds execution time on the next location
(Tn) and the communication delay between the two locations (Tcomm). If it does then the AMP
moves i.e.

T
h
> T
n
+
T
comm

For the experiments of this project the following two equations a
re needed. Before the AMP is
initialised the user will provide some requirements. Either time or cost limit will be supplied and the
AMP will then select the clouds which are within this limit and choose the best one. If a time limit
is supplied the follow
ing equation is used:

Tex = |Tmax(Tn + Tcomm)

or if there is a money limit:

Cex = |Cmax(Tn ∙ cn + Tcomm ∙ ccomm)

If there are a range of clouds that satisfy the requirements then the AMP must decide which one to
choose. If the user supplies a time limit th
en the AMP will select the cloud with the lowest cost. If
the user supplies a money limit then the AMP will select the cloud with the lowest execution time.


2.2.4


Mobile Languages

There are many languages that have been designed for developing mobile pro
grams, for example
JavaGo [16] or Java Voyager [17]. The following properties are typical of mobile languages of
today [14]:





Programmer is in control of mobility
-

The language should provide suitable mechanisms
and abstractions that allow the programmer

to express mobility.



Strong or Weak mobility
-

As stated above, strong mobility is where the code and execution
state are migrated whereas with weak mobility only the code is migrated. At least one of
these two kinds should be supported by the language.


19





I
mplicit or Explicit mobility


Implicit mobility is where an executing thread is
automatically transferred from one location to another. This is typically used in small
systems. With Explicit mobility, the programmer controls the placement of active
comput
ations.



Location awareness
-

In a mobile language, the mobility of code will usually happen when
the program needs to access resources that are not in the same location as that in which the
program started running. Thus, the programmer must be able to expl
icitly say where the
computation must be moved to. This notion of location does not need to be restricted to the
name of machines in a network; it can be related to the names of resources that the
programmer wants to access.



Architecture Independent
-

Mobi
le languages must be able to communicate code between
machines of different architectures and operating systems. The usual approach for achieving
this is compiling programs into architecture
-
independent byte
-
code.




20







Chapter 3


System and Experiment Des
ign

This section describes the design of the broker, the experiment apparatus and the design of the
experiments that will be performed. Section 3.1 describes the architecture of the cloud that will be
used to perform the experiments. Section 3.2 gives deta
ils on how the components of thebroker
system will be arranged on the cloud . Section 3.3 outlines the experiments that will be carried out
once the broker has been developed.


3.1


StACC System Architecture

The broker will be developed to run on the StACC

cloud (Section 2.1.6), which has been set up
using Eucalyptus. Using euca2ools, virtual machine instances can be created and associated IP
addresses. The operating system on each instance will be CentOS. These instances will be used to
host Java programs

that will simulate the broker system. There are a number of different
configurations that each instance can be created with, as shown in figure 3.1. For this project all
instances will use the same configuration. In addition to the computational instances
, a storage
volume will be created. This will be used to hold an SQL database.




21



3.2


System Architecture and Design


Overall Architecture

The proposed prototype cloud broker system will be a Java program that maintains a cloud data
table and allows the in
stantiation of AMP programs. The program will be deployed on a
computational instance on the StACC cloud. This instance will be known as the Control Instance,
and the program will be known as the External Broker.

The cloud data table will be used to store
information on the available clouds and the cost and
performance attributes associated with them. This table will be called the Market Blackboard, and
will be set up by the user via the control instance. The Control Instance will be able to access the
mark
et blackboard in order to add or edit clouds, as well as query it to display information to the
user.

To model clouds that can be used for the execution of AMPs, separate computational instances will
be used. Each instance will run a Java program that will

communicate with the Control Instance.
This program will be known as the load server. It will maintain information about the number of
AMPs on each location and will be able to query requests the Market Blackboard in order to gain
information about other
available clouds. This information will be used to simulate the movement
of AMPs between the different clouds. Figure 3.2 illustrates the structure of the system.


22




Figure 3.2 System Architecture


3.3


Experiment Design

This section outlines the experiment
s for the broker system. These experiments aim to show that the
broker system can successfully distribute AMPs in order to achieve minimum execution time or
cost.

3.3.1


Scenario1


Time considerations

The purpose of this experiment is to show that the br
oker system will successfully choose the fastest
location which will allow the quickest execution time of an AMP. In the first two experiments the
communication time will be the same for all locations, and in the third experiment the effect of
changing the

communication time will be

analysed
. An AMP will move if the time to execute on the
current location is greater than the time to execute on the next location plus communication delay:

i.e. if

Th

>

Tn

+ Tcomm.



23



Cloud Name

Speed GHz

Cost per GHz/h

Comms Co
st

Comms Time (s)

No. Amps

Euc1

1

0.25

0

5

0

Euc2

3

0.25

0

5

0

Euc3

2.5

0.25

0

5

0

Euc4

1.5

0.25

0

5

0

Initial Cost Table


Set up x clouds and populate Cost Table so that the cost of each cloud and communications are the
same for all clouds. The only
value that varies is the speed of each location.


1) Single AMP (communication time is the same)

Deploy a single AMP. Since all the communication times are the same the AMP should move to the
location with the highest speed as this offers the lowest execut
ion time. Change the speed of one of
the lower locations so that it is the fastest and the AMP should relocate to this location.


Cloud Name

Speed GHz

Cost per GHz/h

Comms Cost

Comms Time (s)

No. Amps

Euc1

1

0.25

0.5

5

0

Euc2

3

0.25

0.5

5

1

Euc3

2.5

0.2
5

0.5

5

0

Euc4

1.5

0.25

0.5

5

0

Expected Cost Table with singe AMP


2) Multiple AMPs (communication time is the same)

Deploy multiple AMPs. Again all the communication times are the same so the AMPs should move
to the location where execution will be fas
test. It would be expected that they would all move to the
fastest location, but at a certain point (when there are a few AMPs on the fastest cloud) it would be

24



better for an AMP to move to the next fastest location to avoid all AMPs in the one place.


Clo
ud Name

Speed GHz

Cost per GHz/h

Comms Cost

Comms Time (s)

No. Amps

Euc1

1

0.25

0.5

5

0

Euc2

3

0.25

0.5

5

2

Euc3

2.5

0.25

0.5

5

1

Euc4

1.5

0.25

0.5

5

0

Expected Cost Table with multiple AMPs


3) Multiple AMPs (communication time varies)


Deploy multip
le AMPs. The speed and cost values for each location will be the same as before
however in this experiment the communication time for each location will be changed. This will
affect the overall execution time and therefore the distribution of the AMPs.


Cl
oud Name

Speed GHz

Cost per GHz/h

Comms Cost

Comms Time (s)

No. Amps

Euc1

1

0.25

0.5

15

0

Euc2

3

0.25

0.5

50

2

Euc3

2.5

0.25

0.5

5

1

Euc4

1.5

0.25

0.5

30

0

Expected Cost Table with multiple AMPs and varying communication times


3.4.2


Scenario 2


Cos
t Considerations

The purpose of this experiment is to show that the broker system will choose the cheapest location
to execute on. This will not take into account the speed of the location


simply the location with
the lowest cost will be chosen. The comm
unications cost will vary for each location which will

25



affect the total cost and therefore which is the cheapest location. In the first two experiments the
communication time will be the same for all locations, and in the third experiment the effect of
cha
nging the communication time will be analysed. An AMP will move if the cost to execute at the
current location is greater than the cost to execute at the next location plus the cost to communicate
there, i.e. if Ch > Cn + Comm


Cloud Name

Speed GHz

Cost p
er GHz/h

Comms Cost

Comms Time (s)

No. Amps

Euc1

1

0.1

0.25

5

0

Euc2

3

1.5

0.45

5

0

Euc3

2.5

0.35

0.5

5

0

Euc4

1.5

0.25

0.75

5

0

Initial Cost Table


Set up the clouds as in scenario 1, but change the value of the cost for execution per GHz hour and
th
e communication cost to each location. The AMPs will now look for the cheapest location to
execute on.


1) Single AMP (communication time is the same)

Deploy a single AMP. The AMP will look at the values in the Cost Table and move to the location
with the
lowest cost. If the values are changed and another location becomes cheaper the AMP will
move to that location.


Cloud Name

Speed GHz

Cost per GHz/h

Comms Cost

Comms Time (s)

No. Amps

Euc1

1

0.1

0.25

5

1

Euc2

3

1.5

0.45

5

0


26



Euc3

2.5

0.35

0.5

5

0

Euc4

1
.5

0.25

0.75

5

0

Expected Cost Table with singe AMP


2) Multiple AMPs (communication time is the same)

Deploy multiple AMPs. Again the AMPs will move to the location that offers lowest cost. If the
values are changed then the distribution of the AMPs will

adapt accordingly.


Cloud Name

Speed GHz

Cost per GHz/h

Comms Cost

Comms Time (s)

No. Amps

Euc1

1

0.1

0.25

5

3

Euc2

3

1.5

0.45

5

0

Euc3

2.5

0.35

0.5

5

0

Euc4

1.5

0.25

0.75

5

0

Expected Cost Table with multiple AMPs



3) Multiple AMPs (communication t
ime varies)

Deploy multiple AMPs. The communication cost values for each location will be the same as before
however in this experiment the communication time for each location will be changed. This will
affect the overall cost to execute on each location
and therefore the distribution of the AMPs.


Cloud Name

Speed GHz

Cost per GHz/h

Comms Cost

Comms Time (s)

No. Amps

Euc1

1

0.1

0.25

1000

0

Euc2

3

1.5

0.45

5

3

Euc3

2.5

0.35

0.5

50

0

Euc4

1.5

0.25

0.75

80

0


27






3.4.3


Scenario 3


Time and Cost Consider
ations

This experiment extends the ideas tested in scenarios 1 & 2. The AMPs will take into account the
speed and the cost of each cloud in order to find the best one to execute on. In this scenario the user
will define either time or cost limits for the A
MP. The AMP will then work out the range of clouds
that could possibly satisfy this constraint and then select the optimal cloud from this list.


Cloud Name

Speed GHz

Cost per GHz/h

Comms Cost

Comms Time (s)

No. Amps

Euc1

1

0.1

0.25

1000

0

Euc2

3

1.5

0.4
5

5

0

Euc3

2.5

0.35

0.5

50

0

Euc4

1.5

0.25

0.75

80

0

Initial Cost Table


Set up the cloud to contain locations with varying speed and costs as well as communication time
and cost. Before the execution starts the user will define either maximum price tha
t is allowed to be
spent on the AMP execution or maximum time during which the AMP must be executed.


28




References



[1]

John Rhoton,
Cloud Computing Explained
, Recursive Press, 2010





[2]

Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Ra
ndy Katz,



Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei


Zaharia, Above the Clouds: A Berkeley View of Cloud Computing





[3]

Peter Mell and Tim Grance,

The NIST Definition of Cloud Computing



Version 15, 10
-
7
-
09



[4
]

Robert Stewart,

Performance and Programmability Comparison MapReduce



Query Languages: Pig, Hive, JAQL & Java,
Meng Dissertation March 2010





[5]

Daniel Nurmi, Rich Wolski, Chris Grzegorczyk



Graziano Obertelli, Sunil Soman, Lamia Youseff, Dmitrii Z
agorodnov,

The Eucalyptus Open
-
source Cloud
-
computing System,
Computer Science
Department University of California, Santa Barbara





[6]

Eucalyptus
Euca2ools User Guide



http://open.eucalyptus.com/wiki/Euca2oolsGuide_v1.3



[7]

Amazon Elastic Compute Cl
oud (Amazon EC2)


29





http://aws.amazon.com/ec2/



[8]

Google App Engine



http://code.google.com/appengine/



[9]

David Chappell,
Introducing Windows Azure,
March 20
09






[10]

Salesforce CRM



http://www.salesforce.com/uk/



[11]

StACC
-

Collaborative Research in Cloud Computing



http://www.cs.st
-
andrews.ac.uk/stacc



[12]

What is a Cloud Broker?



http://www.lt
ech.com/cloud/cloud
-
brokers



[13]


Xiao Yan Deng, Phil Trinder and Greg Michaelson,
Autonomous Mobile Programs,
Research Paper, Heriot
-
Watt University





[14]

Xiao Yan Deng, Greg Michaelson, Phil Trinder,
Cost
-
driven Autonomous Mobility,



Phd Thesis, H
eriot
-
Watt University, June 2007



[15]

Alfonso Fuggetta, Gian Pietro Picco, Giovanni Vigna,
Understanding Code Mobility,

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 24, NO. 5, MAY
1998


30




[16]

JavaGo



http://homepage.mac.com/t.sekiguchi/javago/



[17]

Recursion Software Voyager



http://www.recursionsw.com/Products/voyager.html


31



Appendices

Project Timeline



The timeline for this project is illustrated as a Gantt chart as shown above. Thi
s details the proposed
development time scale and shows key deadlines.