Information Technology Reference
In-Depth Information
5. Component Startup and Shutdown depen-
dencies: The inter-relationships between
components may require some components
to be made available before others and con-
figuration data may be dependent on specific
deployment instances. Similarly terminating
applications may require specific undeploy-
ment dependencies to be taken into account.
In our example we may wish to deploy the
database before the web server.
6. Component customization: The service
manifest or definition language should serve
as a template for provisioning instances of
particular components. Multiple instances
of web servers for example may be created
from a same basic template and virtual image
and may require instance specific configu-
ration data, such as dynamically allocated
IP addresses. The manifest language must
provide constructs to support the automatic
generation of instance specific values.
7. Security and access policies: The manifest
should provide means of specifying security
policies. We may consider authenticating the
actual submission of the description itself for
deployment but must also take into account
security requirements once the service has
been deployed, such as the use of particular
certificate files for using or managing the
application service.
8. Quality of service requirements: When
leasing third-party resources, failures of
these resources to meet a particular level
of performance may lead to financial losses
for the service provider. The service pro-
vider can mitigate these risks through the
establishment of Service Level Agreements
(SLA). SLAs specify acceptable thresholds
of performance and reliability as well as
penalties, most likely in the form of financial
compensation that will be incurred should the
quality of service fall below acceptability.
SLAs related to our example may deal with
access time, specific hardware provisioning,
or elasticity response time.
Finally, we must also consider the openness and
platform independent nature of the service defini-
tion language. If a service provider has prepared
his application for use on Amazon EC2, shifting
this to another provider such as GoGrid is not a
straightforward endeavor. In order to facilitate the
transition from one cloud provider to another, it is
desirable for the manifest language to be specified
in a standard way that is free of platform specific
concerns. This provides an opportunity for scaling
across multiple providers and generally avoids
vendor lock-in.
2.2.2 Adapting Standards for the
Cloud: The OVF Experience
We have examined a number of software architec-
ture description languages, standards and existing
commercial offerings in order to identify a suitable
language for the definition of application services
deployed on an open IaaS cloud. In particular we
describe here the Open Virtualization Format
(OVF), a DMTF standard backed by VMWare,
Citrix and many other IT vendors (DMTF, 2010).
We will cover here how the language can be
adapted and extended in order to support cloud
computing capabilities, focusing primarily on
elasticity and service level objectives description.
OVF allows multiple virtual machines to be
packaged as a single entity containing an OVF
descriptor, along with any resources which may
be referred to in the descriptor, such as virtual
disk, ISO images, etc., and finally X.509 certifi-
cate files to ensure integrity and authenticity. It
is the OVF descriptor that we will focus on here.
It is an XML document composed of three main
parts: a description of the files included in the
overall architecture (disks, ISO images, etc.),
meta-data for all virtual machines included, and
a description of the different virtual machine
systems. The description is structured into vari-
Search WWH ::
Custom Search