What we call Cloud computing today has evolved over many years. It had other names before and many technologies are involved in it. Virtualization, utility computing, and grid technologies are among the most representative.

Cloud offerings can be classified according to the resources they offer ‘as a Service’ (XaaS): Infrastructure as a Service (IaaS) that allows the allocation of virtual machines and storage capacity; Platform as a Service (PaaS) providing users with remote software platforms to run their services; and Software as a Service (SaaS) where applications are moved to the Internet and accessed through web interfaces.

Cloud frameworks on the other hand can be seen as the software environments in which Cloud services can be deployed. Most of the frameworks have automatic and elastic management solutions included: they control the life cycle, placement and Service Level Agreements (SLAs) of a service.

Different frameworks have arisen in the recent past, including commercial proprietary and open frameworks like those developed in the European Commission funded Framework Programme 7 Projects RESERVOIR and SLA@SOI. They consist of similar modules and layers but have different basic architectures. They can be messaging based or client/server, and have a focus on IaaS or SLA management. The different foci leads to different architectures. SLA@SOI targets SLA-driven management, and monitoring the life-cycle of services such as software and infrastructure services. It can also be applied to human-based services. RESERVOIR concentrates on federated clouds, and focuses on the management, interoperability and optimisation within such topologies.

Despite these differences, however, Cloud frameworks typically include a layer to deploy virtual workloads on infrastructure. Allowing frameworks interoperate also enables the use of each other’s unique abilities and functionalities. For example provisioned services could be moved to the Cloud framework which would best fit their needs and their characteristics.

The need to interoperate helps fuel the demand for standards. Only if the frameworks support certain standardized interfaces, can interoperability be achieved. The accompanying paper tries to show the overall setup and ideas behind two Cloud frameworks and includes the description of an upcoming Cloud standard. An architecture which combines all three aspects is also proposed.

Technical Report: Using Cloud Standards for Interoperability of Cloud Frameworks

Design-time prediction, as part of the SLA@SOI framework, aims to estimate performance and reliability indicators of a service infrastructure. This includes estimates of a service’s

• completion time,
• throughput,
• resource utilization, and
• reliability.

The approach provided as part of the prediction architecture is model-based: different models are employed to capture an entire system, i.e. structural aspects such as its service components and allocation to (virtual) machines and behavioral aspects such as usage of services.

What is modeled?

Different roles contribute information to the set of models used to predict a service’s performance. This situation is depicted in Figure 1.

Figure 1: QoS Model and involved roles

• Software providers create abstract models of their service components.  These include information about service interfaces and an abstract behavioral description of how the components use the available hardware and software resources (Service Component Model)
• Infrastructure providers specify the execution environment on an abstract level. Important performance-related information includes processing rates etc. (Infrastructure Model)
• Service customers indicate the intended service usage (e.g., the maximal number of requests per minute). From this information, a model capturing the system usage profile (Usage Model) can be derived.
• Service Providers integrate the separate models and provide the prediction service with an initial allocation of components to nodes (Allocation Model)

And how does the actual prediction work?

Design time prediction is based on the modeled service / usage properties only, i.e. it can be performed before the service is actually deployed and running. The various models are transformed into a format that can be processed by the Palladio Component Model (PCM) framework [1]. This comprehensive framework allows for generation of different analysis models such as stochastic regular expressions or a queuing network, which in turn provide capabilities to derive the desired performance metrics.

What’s the use of QoS prediction in SLA@SOI?

Both the provider and the customer of a service will benefit from the integration of design-time prediction into the SLA management framework.

• Transparency: A priori simulation based on multiple scenarios (allocation / infrastructure / usage) allows the service provider to offer clear and concise statements about the service parameters in an SLA. This helps the customer during the selection process and promotes the negotiation process.
• Flexibility: Multi-round negotiation of an SLA can be assisted by iteratively calling the prediction service with modified inputs. This applies in particular to different usage scenarios provided by the service customer.
• Efficiency: Based on the simulated resource demands, infrastructures can be dimensioned efficiently balancing costs and QoS levels.
• Dependability: Careful modeling of the architecture under study leads to high-quality predictions of its performance and reliability.

Martin Küster, FZI Forschungszentrum Informatik, Karlsruhe

[1] Becker, Koziolek, Reussner: The Palladio component model for model-driven performance prediction. Journal of Systems and Software Vol. 82 (1): 3-22 (2009)

To provide effective monitoring support when such changes happen it is necessary to be able not only to check whether the monitorability of the required SLA terms and conditions is affected by the changes but also to modify the deployed monitoring infrastructure in order to ensure the continuous execution of the required runtime checks. These capabilities, however, are not offered by existing monitoring environments and approaches. To address this gap, SLA@SOI is developing a novel SLA monitoring framework, called “SLA Management for Monitoring” (SLAM4M). A key characteristic of this framework is the separation of the actual service monitoring from the assessment of SLA monitorability, and the dynamic set up of the monitoring resources (i.e., event captors and monitors) for checking an SLA.

SLA Management for Monitoring: Overview of the new architecture

A key characteristic of the approach underpinning the design of SLAM4M is the distinction between two key layers in service provision, namely the SLA management and service management layers as illustrated in Figure 1. The SLA management layer is concerned with SLA management activities (e.g. SLA specification, negotiation, modification) and the service management layer is concerned with the software stack required for making a service manageable according to an SLA. From a monitoring perspective, the SLA management layer incorporates the mechanisms required for performing the SLA monitorability checks and the dynamic set up of monitoring infrastructures that can enable the monitoring of an SLA whilst the service management layer incorporates the Event Captors and Monitors required for service event capturing and performing the actual SLA checks, respectively. Given this distinction, SLAM4M belongs to the SLA Management layer, as shown in Figure 1.

Fig 1: Scenarios for dynamic setup of monitoring infrastructures

Figure 1 shows the two scenarios for dynamic service monitoring setup in SLAM4M. In the first scenario (see Figure 1a), the managed service is provided with both Event Captor(s) and a local Monitor and has, therefore, both event reporting and SLA checking capabilities. Thus, when it receives an SLA, SLAM4M checks if each guarantee term in it can be monitored locally, according to the capabilities exposed by the Event Captor and the Monitor. In particular, in order for a Guarantee Term to be locally monitored, the Event Captor should be able to provide the required events, while the Monitor should support the language used for expressing the Guarantee Term.

The second scenario (see Figure 1b) applies to the following two cases:

1. The Event captor provides the events required for monitoring a Guarantee Term, but the Monitor does not support the Guarantee Term language; and
2. the managed service has only an Event Captor but no associated local Monitor.

In the second scenario, SLAM4M first assesses if the required events are available from the local event captor of the service and then tries to identify an external monitor that can support the Guarantee Term language. This identification takes place through a monitor registry that is accessible to SLAM4M and, if an appropriate external monitor can be found, SLAM4M submits the guarantee term to the external monitor and instructs the event captor of the service to provide events to this monitor. It should be noted that the external monitor may be available at some URI on the network and, therefore, an engagement protocol and an event communication infrastructure are required for establishing and realizing the communication of events between the service event captor and the external monitor.

In the prototype implementation of SLAM4M, we use a “publish/subscribe” event communication infrastructure designated as “Event Bus” in Figure 1b. More specifically, after locating a Monitor, SLAM4M gets from it a token designating an event channel of interest and uses this token to subscribe the monitor to the Event Bus. The same token is passed to the Event Captor to be used when it publishes events to the bus so that these events can be forwarded to the appropriate monitor.

For more information on our monitoring architecture, please see the accompanying SLA@SOI Technical Article. Additionally, further details including a discussion of the implementation of SLAM4M and some initial experiences are being published in “Dynamic Set Up of Monitoring Infrastructures for Service Based Systems”, at the track on Service Oriented Architectures and Programming at the 25th Annual ACM Symposium on Applied Computing to be held in March 2010.

George Spanoudakis, School of Informatics, City University London

In SLA@SOI we have identified the following aspects of business that need to be addressed within SLAs:

Functional description: The offered service must be detailed in terms of the features and functionality supported and available to customers.

Business model supported: All the information referring to the selling process must be defined and described in detail, to avoid ambiguity for the customer. The business model description should detail:

• Offer types associated with the Quality of Service supported
• Pricing model
• Billing and payment constraints
• Modification and alteration of prices  if applicable
• Restrictions and constraints

Penalties: Detailed specifications about the penalties incurred when problems arise in the consumption of the service. This information is attached to the guarantee terms definitions that explain in detail how the different agreed terms are used.

Termination clauses: The termination clauses have to be automated and they have to accommodate both parties in the contract. The termination of the SLA can be triggered by certain customer aspects as well as by certain service provider constraints.

Service information events and reports: It must be possible for the final customer to select the kind of information that they wish to obtain automatically. This information is defined in terms of events monitored as well as reports associated with the customer’s service. For instance a customer that uses a storage service may want to know how large their storage consumption is per day. These Key Performance Indicators (KPIs) may not be related to the guarantee terms fulfilled by the SLA.

Support mechanism and contact details: It must be possible to specify the kind of support offered to the customer should they have a problem or inquiry. The support information provided should include timetable details as well as details of the different support channels available.

Disaster recovery and data security in IT Systems: It must be possible to define Backup/Restore policies in order to guarantee the persistence of information, if the service offered to the customer manages and stores data. Also it must be possible to define the security mechanisms that are employed by the service.

Changes to terms in the service: The process to update the service conditions or characteristics must also be considered. It must also be possible to define the mechanism used to inform the customer about such changes.

Customer/Provider requirements and constraints: In many cases, it is necessary for the customers or providers to express some requirements in terms of limits or constraints in the service consumption. Usually these aspects are related to legal constraints to be followed by the customers or providers of one specific country, because they are imposed by the relevant Regulatory Authority. Example constraints include:

• Personal data storage cannot to be stored outside the country
• Maximum prices and/or quality shall apply
• Restrictions in sharing of personal data with third parties associated with the service provider
• The prohibition of delivery advertisement
• Personal data usage restrictions for specific tasks (e.g. data mining)

As we can see, the variety and complexity of business  concerns is both broad and deep. However, we have found that each specific business has their own kind of restrictions and bounds.

In the SLA@SOI project, one of our main aims is to create a business framework that supports the realities of the business world. In our Business Management focus area we are actively researching these aspects, building a strong foundation to support a wide range of grounded, industry-driven use-cases.

Juan Lambea Rueda, Telefónica Investigación y Desarrollo

The full details are presented in an accompanying technical paper,  Challenges in SLA Translation, but the overall framework is illustrated here in Figure 1.

Figure 1: Observables (metrics) and configurables (parameters) in SOA layers, with different types of translations.

The framework distinguishes four main translation types:

• C2C (Configuration to Configuration): this type of translation mostly relates to the dependencies within a layer or between layers. Such dependency graphs are useful in configuration management and problem diagnosis.
• M2C (Metric to Configuration): this type of translation translates higher-level objectives to lower-level system parameters. It can also be referred as “top-down” translation or SLA decomposition. It is useful for sizing and capacity planning, mostly at design time.
• C2M (Configuration to Metric): this type of translation predicts higher-level objectives from lower-level system parameters. It can also be referred as “bottom-up” translation or performance prediction. It is useful both what-if analysis at design time and predictive management at run time.
• M2M (Metric to Metric): this type of translation correlates a high-level metric with lower-level metrics. The translation can go both directions, namely decomposition or prediction, depending on the usage scenario. It is useful for forecasting and problem diagnosis at run time.

Additionally, we have also identified and described the fundamental research challenges that need to be addressed to turn the vision of holistic and transparent SLA translation into reality. These research challenges are

• Realistic workloads and usage patterns
• Tradeoff-analysis for scalable approaches
• Innovation and integration of methodologies
• Model integration and transformation
• The definition of layers and layer interfaces
• Business values and reference benchmarks

To found out more about this proposed conceptual framework and these research challenges, please see the accompanying technical paper, Challenges in SLA Translation.

Hui Li, SAP Research

The scenario that presented in this article assumes that a client company has a contract with a financial service provider to provide processed market data for the company’s internal use; this may be in the provision of additional services to other users.

In the Financial Live Trading System scenario there are five actors:

1. the Financial Service Customer who is the consumer of the processed market data;
2. the Financial Service Provider who sells processed financial or market data to a collection of customers;
3. the Software Provider that provides software via a licensing agreement to business organisations;
4. the Compute Provider that provides hosting and compute capabilities to customers; and
5. the Data Provider that provides a feed of up-to-date market data and financial information.

A Live Trading System processes live market data from the Data Provider using compute resources hosted by the Compute Provider, running software from the Software Provider to supply processed data to the customer. A Trading System demands a high availability of resources. Non-availability of resources means an absence in market trading which, in turn, can lead to missed opportunities. Security is of paramount importance. In addition, regulatory issues exist within institutions that place restrictions on the accessibility of spatial information across their distributed enterprises.

As described in the above figure, Financial Service Provider supplies the trade data from the Live Trading System to the Financial Service Customer. The business SLA is agreed offline between the Financial Service Customer and Financial Service Provider. In order to meet the business SLA requirements, the Financial Service Provider need to establish separate SLAs with the Software Provider, Compute Provider and Data Provider. These SLAs need to be monitored and observed carefully.

Two of the critical customer requirements in the above scenario are the high availability of compute resource and legislation compliances. If one of the compute resources provided by the Compute Provider fails, the Financial Service Provider has to switch to a backup resource or look for another computer provider which must also satisfy other regulatory requirements in a fast, efficient and accurate manner.

In the current implementation, this usually means a significant down time and potentially a breach of the SLA agreements with the Financial Service Customer. In our proposed SLA-focus solution, the failure of the compute resource will be detected and the discovery of new compute resource that satisfy the regulatory requirements will be performed automatically. A new SLA with the new Computer Provider is established and the software is deployed in a very fast and automated manner. The data feed or necessary calculation may then be restarted at the new compute resource. From the SLA point of view, this would only affect the customers in terms of a very short delay. Potential penalties due to the violation or breaching of SLA are reduced significantly.

Differently from other software systems, the problem is not the capability of controlling how the different service instances are activated and deactivated, but it is about the non-functional issues and the supervision of the service level agreements (SLAs) established with the different partners.
This problem has some key peculiarities. In many cases, the services we would like to utilize are not (fully) under our control. We may have cases in which we own the composition, which is the actual service we want to manage, but we have no complete access to (some of) the partner services. Moreover, the multi-tenancy implicit in service-centric applications requires that the same service (or service composition) be managed in different ways for the different users. The problem is intrinsically hierarchical: the effects on complete processes (i.e., service compositions) must be properly reflected on the single services that constitute the assembly, and also on the infrastructure on which they both —single services and compositions— are executed.

These characteristics have already motivated significant research efforts and standards (like Web Service Distributed Management), but we claim that none of provided solutions is able to address the problem completely and homogeneously. Our proposal is to build on top of existing standards and try to provide a holistic solution to distributed service management. First of all, we think that the interfaces provided to fully control the behavior of services must be extremely rich, and allow users to control the inner details of the services. We assume that some key features must be mandatory, while others could be optional. For example, mandatory features may be the possibility to start, stop, and suspend the execution of a given service instance, or even to monitor its basic behavior. On the other hand, more advanced capabilities, like security issues, SLA enforcement, fine-grained annotations and probing, and deep control of associated physical resources, may be optional and provided by some services in particular contexts (e.g., the services in the same domain as the user’s one).

This distinction between mandatory and optional features allows us to distinguish among at least three types of services (w.r.t. to management). Black-box services are those that only provide the basic features and allow the user to interact with them as if they were black boxes. Grey-box services provide some optional capabilities, but they do not provide complete access and freedom to the user, while white-box services implement the complete management API and allow the user to fully oversee and control the execution of service instances.

Since services can be composed, another important aspect is the composition of the different management capabilities. When we think of management features, the capabilities offered by the composition must be suitably supported by those provided by the single services. This is why the actual composition of the management APIs seems to be a promising research problem.

All these elements must be provided to the user seamlessly and homogeneously. Since some of the management capabilities offered by the different services may have a big impact on their performance, we also need the capability to switch them on and off on demand. Indeed, the more management is required, the slower a service becomes. Thus the fine-tuning of these additional features, w.r.t. their actual behavior, is mandatory to offer a usable solution.
These are some of the key challenges we foresee for the complete and effective management of services and service compositions. These are also the underpinnings of our work in the project and we hope to be able to provide useful solutions that fit well in the global SLA@SOI infrastructure.
Luciano Baresi and Sam Guinea

Multi-Layer Monitoring Architecture

The distributed multi-layer monitoring architecture may be comprised of as many layers as necessary to support the monitoring of the underlying infrastructure. However, these layers have been divided into three logical layers, according to their primary purpose, amount of input and output events, and degree of processing. The lowest layer of the hierarchy, the data collection layer (L0), is mainly used for the collection of raw input data. Basic filtering and pre-processing of collected information can also be applied at L0 to reduce network traffic. However, processing on Layer 0 should be kept to a minimum to limit the monitoring resource usage. The second logical layer is the event evaluation layer (L1) that supports the integration of monitors into a cascade of increasingly more complex monitors, ranging from simple metric checks to composed monitors. Composed monitors re-use other monitoring agents to process complex rules, e.g. monitoring of an entire cluster, taking the relationship between nodes in a cluster into account. The top-most layer, named the service layer (L2), configures as well as defines the meaning of monitoring events generated in lower layers of the architecture. The architecture prevents top-level monitors from connecting to data collection layer and bypassing the event evaluation layer. L2 layer is a collection of conceptually similar functions that provide services used by any service dealing with infrastructure and receives inputs from layers below it.

The following subsections describe the logical layers of the architecture in further detail.

Data Collection Layer (L0)

Layer 0 represents the data-collecting monitoring agents producing low-level and (mostly) unprocessed events. These agents are wrappers around specialized data collectors, like Ganglia 4 or Munin 4 at the infrastructure layer. They can even use probes into Virtual Machine Monitor (xentop), /proc, kernel, or middleware components (web server, application server, database). Data collection monitors support three types of operation, timed push, conditional push and pull. Timed push publishes configured metrics in uniformly timed intervals regardless of the value change since the last published value. Agents support an arbitrary number of timed pushes, i.e. different metrics can be requested at different intervals. Conditional push provides a basic mechanism for the reduction of network load. Metric values are pushed on the channel only when the last published value is exceeded by specified threshold value or percentage. Agents from higher layers can also opt to query metrics from data collectors only when needed in their own calculations. For this purpose, L0 agents also support metrics to be pulled on request. Each agent can be configured to work in one or more of these modes simultaneously.

Evaluation Layer (L1)

The event evaluation layer is a dynamic network of distributed agents. A dedicated infrastructure node may be used to deploy these agents to reduce the overhead of nodes offered to customers/users. Agents are all subscribed to a single configuration channel to which monitoring requests are published by service layer monitors. Monitoring requests are represented as rules that L1 monitors are expected to validate. Every L1 monitor can verify whether it supports validation of requested rules and whether it has sufficient resources to accept additional monitoring. Agents willing to start monitoring solicited rules notify the requester that, based on these responses, decides which monitor to send configuration to. It is also possible to select several monitors for the same validation rule.

Service Layer (L2)

Every request for monitoring has to enter through one or more service layer (L2) monitors that form the boundary of the entire monitoring architecture. These monitors’ activities are composed according to the users’ requests. Each L2 monitor implies a certain configurations of the L1 monitors, which are managed dynamically. Users of L2 monitors may be infrastructure providers, service providers or even service customers requiring immediate notification that the agreement was breached. Events from L1 monitors are used as triggers for execution of required actions. Examples of service layer tasks are:

• Auditing task – logging and monitoring customer’s usage of resources.
• Accounting task – producing information used for billing.
• Autonomous management – providing self re-organization of the infrastructure in order to improve the utilization without breaking any SLA.
• Notification task – may be used to notify various stakeholders (service provider, customer) of a broken rule.
• Historical information repository task – is used to store various monitoring information, ranging from raw data about infrastructure and/or services to events raised by different monitors.

So what’s in OVF? First of all, OVF is XML, so obviously hierarchical in nature. At the core of OVF is the Envelope element and it is this element that contains:

• References – this is a list of external files that are required to satisfy the OVF package. An OVF package does not need local virtual disks or remote ISO files to operate. They can be supplied within the OVF document by using the “ovf:href” attribute of a File element within the Reference section.
• Core Meta-data – this is a list of what are known as Sections. Section elements that are allowed at this level are:
  • NetworkSection – each OVF envelope can have only one or opt not to include the section (zero-or-one). It is here where textual names are given to networks. These work as logical grouping identifiers. Here the attribute of Network, name is required.
    
  • DiskSection – each OVF envelope can have only one or opt not to include the section (zero-or-one). This is a listing of disks used within the OVF document. Each disk can be referred throughout an OVF document by the mandatory “diskId” attribute. Here other attributes include:
    • fileRef – this is an optional reference to virtual disk content
    • capacity – this is required and is the virtual disks maximum capacity
    • capacityAllocationUnits – units in which space is allocated and is optional. By default it is bytes but this can be specified to any unit as listed in the DMTF DSP0004 specification.
    • format – this is a URI that points to a description of the virtual disk format in use
    • populatedSize – this is the estimated populated (space used) size of disk in bytes and is optional
    • parentRef – a reference to a parent disk and is optional
  • DeploymentOptionSection – each OVF envelope can have only one or opt not to include the section (zero-or-one). This section lists a set of configuration options for the contained resources within the OVF document. Each configuration has a textual identifier (e.g. ovf:id”large VM”) which can be related to a particular configuration within the VirtualHardwareSection. A default configuration can be specified by setting ‘ovf:default=”true”‘.
    
• Virtual Machine Specification – the specification of virtual machines in OVF can be presented either as singular or multiple virtual machine specifications. This allows for not only the simple but complex multi-tier applications. A VirtualSystem element represents one virtual machine. A VirtualSystemCollection element represents a list of both VirtualSystems and VirtualSystemCollections. We’ll look further into these two types later.
• Message Bundles – this is a list of message resource bundles for zero or more locales, used for the purpose of localisation and is denoted by the element of Strings

Common Sections of VirtualSystem and VirtualSystemCollection

There are three common Sections used in both VirtualSystem and VirtualSystemCollection:

• AnnotationSection – this section contains any number of user-defined annotations that are relevent to the particular entity. These can be pieces of information that are displayed when opening an OVF document.
• ProductSection – this section specifies product information for an appliance, such as:
  • Product – name of product
  • Vendor – name of product vendor
  • Version – product version, short form
  • FullVersion – product version, long form
  • ProductUrl – URL resolving to product description
  • VendorUrl – URL resolving to vendor description
  • AppUrl – experimental: URL resolving to deployed product instance
  • Icon – experimental: display icon for product
  • Property – this is a property bag of name/value pairs that allow for additional configuration parameters specific to the particular product. These entries are required to specify the type of the value entered (using CIM types DSP0004) and can be flagged if they can be configured by the user at installation time (using the “userConfigurable” boolean attribute).
• EulaSection – this section contains the legal terms for using VirtualSystem/VirtualSystemCollection. This license should be shown during the deployment of the OVF package.

VirtualSystem

A VirtualSystem is the element that describes one virtual machine. Contained in the VirtualSystem are a number of Sections, including the shared Sections of VirtualSytem and VirtualSystemCollection, that are specific to the element:

• VirtualHardwareSection – each VirtualSystem can have only one or opt not to include the section (zero-or-one). The VirtualHardwareSection has an attribute “ovf:transport” that is required. This attribute describes how environment document information can be communicated to the guest software. A VirtualHardwareSection consists of the following elements:
  • System – this element identifies the hypervisor/virtualisation technology that is to be used with the particular VirtualSystem. An enumeration of these types can be found in DSP1042 (for example vmx-4 corresponds to VMWare’s 4th generation virtual hardware).
  • Items – there can be multiple Items in this section. Each item represents a virtual hardware component (e.g. Memory, CPU). The actual type information for each virtual hardware component can be found in DSP1042 in the CIM_ResourceAllocationSettingData class.

  A very interesting aspect is use of Ranges within the VirtualHardwareSection. This allows for minimum and maximum ranges for hardware specifications. For example using Ranges an OVF document can describe that a provider should run a particular appliance with a minimum of 1GB of RAM yet allow the usage of RAM expand and grow to a maximum of 4GB. This allows OVF explicitly capture aspects of elasticity that is core to cloud infrastructure.

• OperatingSystemSection – each VirtualSystem can have only one or opt not to include the section (zero-or-one). This section details the type of operating system installed on the virtual system. The valid operating systems that can be specified here can be found in the CIM_OperatingSystem.OsType.
• InstallSection – each VirtualSystem can have only one or opt not to include the section (zero-or-one). If this section is specified then it signals that the virtual machine needs to be booted once in order to install and/or configure the guest software. The attribute “ovf:initialBootStopDelay” specifies a delay to wait before stopping the machine after configuration is complete. If there are many VirtualSystems with this section it is allowable to run these boot phases concurrently.

VirtualSystemCollection

A VirtualSystemCollection is the element that allows one or many virtual machines in different logical grouping. This element is a list of VirtualSystems and/or VirtualSystemCollections, supporting multi-tier applications and allowing for flexible grouping. Contained in the VirtualSystemCollection are a number of Sections, including the shared Sections of VirtualSytem and VirtualSystemCollection, that are specific to the element:

• VirtualSystemCollection – each VirtualSystemCollection can have many or opt not to include the section (zero-or-many).
  • Or:
• VirtualSystem – each VirtualSystemCollection can have many or opt not to include the section (zero-or-many).
• ResourceAllocationSection – each VirtualSystemCollection can have only one or opt not to include the section (zero-or-one). This describes all resource allocation requirements of a VirtualSystemCollection. This could be used perhaps where a number of appliances are to be executed on the same physical host.
• StartupSection – each VirtualSystemCollection can have only one or opt not to include the section (zero-or-one). This section specifies how a virtual machine collection is powered on and off and the sequence in which each VM should be powered on/off.

Summary

The Open Virtualisation Format is a great step forward in beginning to provide standards in the area of virtualisation. It defines a means to fully describe single or multiple virtual machines. It is also extensible, a very important aspect for SLA@SOI and supports multi-tier applications and the declarative ordering of machines within a multi-tier configuration.

OVF does not however define a standard means in which the virtual disk should be formatted as and the layout of such disks, their endian-ness etc. This requires some recipients of OVF packages to carry out a lengthy process of disk image conversion before the disk images can be utilised. Although, virtual disks, ISO images and other File types can only be pointed using “http” or “https”. This might work for many cases but for infrastructure providers wanting to integrate OVF into their provisioning system, this may require an extension as it might be the case (e.g. in the case of Amazon EC2 AMI identifiers) that appliances and ISOs are pointed to by a unique identifier.

A Service Level Agreement (SLA) is a representation of all those features that a user should expect to receive by a service. By features here we refer not only to the functionality delivered by the service, but also to the quality that the user experiences. As a matter of fact, SLAs are typically associated with Quality of Service (QoS), but in a formal representation it is reasonably expected to find the service description as well.

Given the definition above, SLAs may be represented in various ways; SLA@SOI considers only their electronic representation for purposes of automated management by means of machine-readable documents. In a direct analogy with contracts as known from traditional business, we commonly refer to SLAs in our context as electronic contracts. As a consequence of this analogy, the following important questions come up:

1. What are the legal implications of electronic contracts, when it is software that is making the decisions?
2. What is the language that an electronic contract is written?
3. How is electronic contract negotiation happening?
4. How can the terms of the contract be expressed in uniform, commonly understood ways?

With regard to legal implications, it is clear that machines and software cannot be held accountable in the case of penalties, or more severe breach of contract. Therefore, it is commonly accepted that a formal (non-electronic) contract negotiated between humans needs to be in place, governing all automated interactions between software entities. This contract will have to define what are the purposes of the automated SLAs, the capabilities and administrative boundaries of the negotiating software entities, acceptable terms and penalties, and in general all those business and technical characteristics that apply to the automated interactions. Therefore, a framework contract must be in place to reflect accountability and responsibilities of involved business parties.

This contract will probably have to also define the language in which SLAs are negotiated and established. Just like typical business contracts which may be written in English, German, French or any other language, electronic contracts have to be expressed unambiguously in a commonly agreed machine-readable language. A few efforts on this front have taken place in the past, such as WSLA [1] and SLAng [2], but the only standardised such language which is also actively maintained, is WS-Agreement [3]. WS-Agreement is developed by the Open Grid Forum’s [4] GRAAP Working Group [5]. It defines the necessary building blocks for establishing a contract, currently in the form of a single-round negotiation without counter-offers: One party makes an offer, and the other party simply accepts or rejects it.

Although currently not a part of the standardised protocol, multi-round negotiation is in the works and will be made available soon in an amendment of the standard. This extension is a simple series of agreement template exchanges, each template defining candidate terms to be agreed and the acceptable ranges for these terms. When both involved parties agree on a template, then an offer is made by one of the two parties. Renegotiation is still not addressed but will probably take the same form.

Having defined in complete a signalling protocol for the establishment of SLAs, the question of proper definitions for terms comes up. WS-Agreement does not go into this area, which is domain-specific and cannot be addressed uniformly except for specific common definitions for terms such as cost/price, re-negotiation policies, etc. Therefore, domain-specific languages have to be agreed and implemented by WS-Agreement users, or existing languages can be reused. For instance, infrastructure provisioning requests may be addressed by embedding OVF [6] requests in WS-Agreement offers; for Grid storage reservations, SRM [7] can be used as a term language; for job submission, JSDL [8] is a typical candidate. WS-Agreement’s extensible characteristics allow the inclusion of any language deemed appropriate.

The above points address SLAs as documents/contracts. In next posts of the SLA@SOI blog, we will address in more detail the business-logic side of establishing agreements, such as offer optimisation, service provisioning, agreement persistency, monitoring, violation management, etc.

[1] http://www.research.ibm.com/wsla/
[2] http://doi.ieeecomputersociety.org/10.1109/FTDCS.2003.1204317
[3] http://www.ogf.org/documents/GFD.107.pdf
[4] http://www.ogf.org/
[5] https://forge.gridforum.org/projects/graap-wg
[6] http://en.wikipedia.org/wiki/Open_Virtualization_Format
[7] http://en.wikipedia.org/wiki/Storage_Resource_Manager
[8] http://www.gridforum.org/documents/GFD.56.pdf