With cloud-based services becoming ever more significant, the opportunity for machine-readable SLAs to solve key challenges for both customers and service providers has become ever more obvious. Rather than have to settle on the nearest offering and support model that providers happen to provide, customers can negotiate personalised SLAs allowing them to purchase the precise service level they require. This negotiation can even be automatic, and span multiple providers. On the provider side, all individual SLAs can be automatically monitored, comprehended and managed, allowing efficiencies previously considered infeasible to be embraced.

Announcing the publication of its most recent results, and launching an updated version of its open source framework, the SLA@SOI project has delivered an extensive list of assets. These include

• Publication of an SLA-enabling reference architecture suitable for both new and legacy infrastructures
• Definition of a flexible, extensible SLA model for describing arbitrary SLAs
• Development of an open source framework of tools and components to help implement SLA-aware solutions
• Release of an SLA-enabled open reference case to demonstrate the concepts in a retail scenario
• Integration of machine-readable SLAs into four grounded industry use cases covering ERP hosting, Enterprise IT, Service Aggregation and eGovernment scenarios – all of them demonstrating significant business value gains
• Significant progress in several important open standards including OGF’s OCCI and WS Agreement, and W3C’s USDL

The relevance of this research has been validated by the extensive interest in the results of the project by industrial partners participating in the project, by independent SMEs engaged in cloud computing, and in the other organisations in Europe and beyond that are looking to build on the results of SLA@SOI in the development of the Future Internet.

Dr. Wolfgang Theilmann, SAP Research, the project coordinator, found the SLA@SOI project to be “a great experience, seeing how the concept of SLAs allowed us to create a highly harmonized view on the full management lifecycle for services – across really diverse partners with complementary but highly distinct perspectives.”

The Industrial Director of the consortium, Mr. Joe Butler, Intel Labs Europe, noted the “important opportunity to bring together four very diverse application domains, taking a structured approach to the specification and assessment of a novel technology development, namely the SLA framework. The resulting analysis of business impact potential, while proving the benefits of automated SLA-based service management, also provides a substantial reference point in assessing the impact of the SLA framework in other, and more general domains”.

Ms. Jessica McCarthy, the Exploitation Manager of the project, explained that “SLA@SOI indeed covers the complete value chain for realizing dependable cloud services. It addresses the main levels of the cloud concept, namely infrastructure, platform, and software as a service, but also extends this to higher abstractions such as human-based business services. It also addresses key areas of engineering support, actual operation, and consulting, thus providing a comprehensive result set to cover the complete commercialization spectrum. Initial external exploitation opportunities are already being pursued by project partners, and we are aware of a growing number of third-parties working to embed SLA@SOI results in the European economy.”

Full details of the project including links to the open source contributions, academic publications and demonstration videos can be found at the project website http://www.sla-at-soi.eu.

SLA@SOI Final Press Release (PDF)

SLA@SOI Studio

• Introduction

www.youtube.com/watch?v=H8Bys29z9Z8

• Developing an SLA Manager

www.youtube.com/watch?v=jk1FvqPHSo0

SLA@SOI Monitoring

• Monitorability and the Everest Monitoring Engine

www.youtube.com/watch?v=gdATDjEKFJ0

SLA@SOI Open Reference Demonstrator

• Negotiation Scenario

www.youtube.com/watch?v=W81H9C_Iuzs

• Create Agreement Scenario

www.youtube.com/watch?v=0bOu96VPNjI

• Software Violations Scenario

www.youtube.com/watch?v=vJV6pvkGRvk

SLA@SOI Enterprise IT Use-Case

• Investment Governance

www.youtube.com/watch?v=PvBlcZhddk4

• Infrastructure Scheduler

www.youtube.com/watch?v=0f0beXDND7c

• Infrastructure Reporting

www.youtube.com/watch?v=FL0l2h_K53s

• Acceptable Service Violations

www.youtube.com/watch?v=pjS_cLO7Sio

• Availability Restrictions

www.youtube.com/watch?v=8fXoxJ6HZr8

Several hundred visitors from the technical press, analyst organisations, industry, academia and government were introduced to the SLA@SOI project, the consortium, the SLA model it developed, the OCCI standard it helped drive, and were walked through the application of SLA@SOI in our Enterprise IT use case.

The Dependable Cloud at Research@Intel Day 2011, featuring SLA@SOI

Partnerships with other open cloud-related projects were also explained, and it proved a very useful event for identifying further opportunities for collaboration.

A busy but stimulating two days. For more information on the event including videos and press material please see http://blogs.intel.com/research/2011/06/researchintel_2011.php. The latest videos of the SLA@SOI Enterprise IT use case demo are also now available online.

Hosted by Custon, a Dutch company dedicated to performance on demand, and co-organised by SLA@SOI, it featured insightful presentations from and engaging discussions with large-scale industry (HP, SAP, Intel), consultants (Gartner), research (SLA@SOI, Contrail), SMEs (GPI, Sensible Cloud, 2E2, ING) and academia (Fontys).

At a key phase in the adoption of cloud, the conference explored the strategic relevance of cloud computing, customer needs, solutions and best practice. Future trends and priorities were also addressed.

For details of the agenda please see our dedicated conference page. All presentations are now available online here.

Including learnings from SLA@SOI contributed by Mike Nolan, the SLA@SOI Enteprise IT use case lead, the document covers the risks and rewards of moving applications and data to the cloud.

For more information and a copy of the paper visit http://cloudusecases.org/

The OCCI working group is co-chaired by Andy Edmonds, an SLA@SOI researcher focused on Infrastructure Management, and has benefited from the extensive open research carried out in SLA@SOI on existing infrastructure models and interfaces. SLA@SOI is currently building on this effort, developing OCCI-compliant interfaces to its Infrastructure Management layers to help prove and showcase this new open standard.

SLA@SOI looks forward to seeing this standard develop from strength to strength.

Introduction

The barriers to cloud adoption are heavily documented across the internet. In this blog post, we examine some of the main solutions put forward by the SLA@SOI consortium in addressing the issue of data security. By doing so, the SLA@SOI consortium is arguing that while indeed there are valid concerns today regarding moving to the cloud, these are by no means insurmountable. In fact, work such as our own prove that they will go away in time as developers and public providers implement more robust cloud solutions.

As part of the dissemination of SLA@SOI, we have had the opportunity to participate in a Google Cloud Use Case group which is an informal gathering of cloud enthusiasts who have produced several publications, the most recent of which is a high-level document outlining the major challenges to take into consideration before moving to the cloud [1]. So, how does the SLA@SOI framework help tackle these issues? Using the Enterprise IT use case as our example, let’s take a look at the classification of information assets in more detail.

Classification of Information Assets

The SLA@SOI Enterprise IT use case takes a multi-point approach in its solution to this problem. Firstly, in how information is classified in the enterprise. Next, we physically architect the cloud to protect our data and finally we use QoS terms associated with each service to govern how and where in the cloud the service is allowed to run.

(1) Information Classification

No organisation should consider a move to the cloud unless it already has certain key pre-existing business processes. One of the most fundamental of these is a mature process for the classification of the information assets of the business. Information assets can be described as the ‘secret sauce’ that makes the organisation and what it does unique in the industry. As such, this knowledge is the most valuable asset the organisation possesses and also is possibly the most difficult to secure. Of course, information classification is a process which extends to all information in the organisation including employee records, financial reports, marketing data and so on. Some data may be governed by legislation such as the EU’s Data Protection Act (Directive 95/46/EC) or the U.S.-EU Safe Harbour framework. Interestingly, in March 2011, Viviane Reding, the EU’s commissioner for justice, said U.S. firms cannot avoid the implications of EU laws, stating that “privacy standards for European citizens should apply independently of the area of the world in which their data is being processed” [2]. Other data however, may not be as critical, making those types of services ideal candidates for a move to external clouds.

Assuming a mature data classification process exists in the organisation, SLA@SOI then builds on this in its framework implementation. As a new service is created in the cloud, the service owner must supply data describing the level of protection required for the data contained within. This is done through the use of the DataClassification QoS term. These can be matched to the existing levels defined by the organisation and the SLA@SOI framework scheduler uses this information to control where within the cloud that service is provisioned. The scheduler may also make run-time decisions to consolidate or re-balance workloads for efficiency reasons. When this happens, the DataClassification QoS term helps the scheduler determine the optimum run-time profile of the cloud. An SLA violation can occur and will be reported to the service owner if at any time a service runs somewhere where its data is not protected to the required level.

(2) Physical Cloud Architecture

In the SLA@SOI Enterprise IT use case, the cloud is assumed to be large and constructed from a heterogeneous range of physical systems which have grown organically over time. This is more realistic and frees the provider from the costly obligation of matching vendor and server models across the full cloud as well as making it possible to add capacity in varying levels whenever needed. The cloud is also considered to be geographically diverse, split over multiple data centres, sites and even geographic regions. This brings the added complexity of meeting legal requirement which can vary by jurisdiction.

From a physical perspective, for research purposes the cloud is assumed to be divided into logically managed security enclaves. To do this, metadata is used to describe additional properties of the physical servers including location and DataClass. These allow the SLA@SOI workload scheduler to make decisions about the type of services which are allowed to run on them. The location property can be used to refer to the data centre, the site, the country or geographic region. The DataClass property specifies which security enclave a physical server belongs to. Security enclaves can be designed to match the data classification levels available in the cloud and the level of protection afforded in each is clearly related to the customer. In general, systems in the most secure enclaves will be the most locked down in terms of administrative access to the host operating system along with much tighter firewall controls.

(3) SLA@SOI Service QoS terms

In addition to the items already described in this post, the SLA@SOI framework provides several more mechanisms in the form of service QoS terms for addressing security concerns as follows:

a. VM Persistence; This QoS term describes if the virtual machines which constitute a service are persistent or not. Persistent virtual machines are stateful, meaning that following a reboot and changes made to the VM since the last reboot will be retained. Non-persistent VMs are state-less and revert back to their original condition if rebooted. This latter feature can be useful for activities such as test spirals, development or training classes.

b. VM Image; The service owner can choose from standard or encrypted guest templates. Using encrypted templates means that the guest OS within the VM will run disk encryption software. Keys for these are stored with the service owner and provider. Such protection makes it more difficult for an unauthorised party to boot a VM should they manage to make a copy of its running image or a gain access to a snap-shot or backup on the providers system.

c. Service Isolation; This QoS term is boolean and can be used in two ways. Firstly, it can be set to ensure that all VM’s belonging to a service are provisioned on separate physical systems from each other. It can, at the providers discretion, also be used to instead ensure that a service is given dedicated hosts which are not shared with VM’s from other services which can be a useful security feature helping to alleviate concerns around co-tenancy.

d. Auditability; This QoS term is another Boolean value and is used if the customer required that a service audit trail is required. A service audit trail simply means that all administrative operations relating to that service are stored in a security log and made available to the customer.

e. SAS70 Compliance; This is a guarantee term designed for enterprises that need to consider compliance with Statements on Auditing Standards (SAS) No. 70. It is used to control where within the cloud the service is allowed to run. Internal compliance procedures must be carried out by the provider on the physical hosts. The provider may carry these out on all systems in the cloud or for Total Cost of Ownership (TCO) reasons, may just do this on the most sensitive ones. This term therefore allows the scheduler the flexibility to run services on systems which are not SAS70 compliant should data privacy not be as important to the customer.

f. Service Data Retention; This QoS term, specified by the service owner, relates to the number of days which the provider will agree to maintain the customers data after the service ceases to be actively running. If set to 0, the data is deleted from the providers repositories as soon as the SLA contract ceases and the customer has elected not to extend the end date. If set to a value such as 2555 (ie: 7 years) the provider agrees to store the data for this period of time. The customer may then be able to comply with legal requirements they may be subject to on data retention.

g. Service Data Delete Method; This term defines HOW data is erased from the providers disk once the service owner no longer requires it to be stored. The provider defines what each level means. Possible values may be “Standard” or “Secure”. Standard may mean a normal delete which does not overwrite the areas of disk where the data used to reside with random 1’s and 0’s. There is an assumption that there is a compute resource cost to using the secure delete method from the provider. However, the provider may elect to use secure delete in all cases and would therefore not offer a choice, but rather advertise it as a security feature. This feature makes it more difficult for third parties to gain unauthorised access to data.

h. VM Snapshot Backup and VM Snapshot Retention; These QoS terms allow the service owner to request that regular snapshots of their data be taken. If this is required, the retention term lest the service owner specify how long they require the provider to keep each snapshot available to them. This lets the service owner be prudent about older images and ensure they are not stored for longer than required which makes unauthorised access a little easier to protect against.

Summary

The SLA@SOI consortium, particularly in the Enterprise Use Case, has shown many possible methods where an SLA aware cloud can help secure data and alleviate some of the security concerns with moving to the cloud. It is our goal to help further the development of these concepts in future projects through our dissemination activities and to promote the exploitation of such concepts by cloud providers by stating the business value behind them, by using the work of the SLA@SOI consortium to prove that they can be addressed and by influencing and contributing to the development of standards.

Mike Nolan

References

[1] http://cloudusecases.org/Moving_to_the_Cloud.pdf

[2] http://gigaom.com/2011/03/17/u-s-web-firms-told-to-stick-to-eu-privacy-laws/

The scheduler allocates requested virtual machines to the most appropriate physical machines. The allocations take into account the Infrastructure SLA specifications for the virtual machines (CPU, memory, location, isolation, HW redundancy level, auditability, etc.) as well as data center policies, e.g. server efficiency, energy consumption, user priorities and over-provisioning of the resources.

Scheduler Flow

Figure 1 shows the scheduler flow, which is executed periodically. It checks for new virtual machines requests and tries to find the most suitable host. Searching for a host can be described as a bin packing problem and the scheduler uses the first fit and best fit algorithms to determine the host (see the complementary Technical Paper for more details). The scheduler triggers live migrations when some resources are freed up and some virtual machines with high priority can be moved to the more efficient servers.

Figure 1: SLA@SOI Scheduler Algorithm

Overall, the responsibility of the scheduler is to guarantee the Infrastructure SLA terms, for example the following part of the SLA specifies that changes to the virtual machine disk have to be persistent.

<slasoi:VariableDeclr>

<slasoi:Text/>

<slasoi:Properties/>

<slasoi:Customisable>

<slasoi:Var>VM_PERSISTENCE_VAR</slasoi:Var>

<slasoi:Value>

<slasoi:Value>true</slasoi:Value>

<slasoi:Datatype>http://www.w3.org/2001/XMLSchema#boolean</slasoi:Datatype>

</slasoi:Value>

<slasoi:Expr>

<slasoi:SimpleDomainExpr>

<slasoi:ComparisonOp>http://www.slaatsoi.org/coremodel#isa</slasoi:ComparisonOp>

<slasoi:Value>

<slasoi:CONST>

<slasoi:Value>http://www.w3.org/2001/XMLSchema#boolean</slasoi:Value>

</slasoi:CONST>

</slasoi:Value>

</slasoi:SimpleDomainExpr>

</slasoi:Expr>

</slasoi:Customisable>

</slasoi:VariableDeclr>

The scheduler has to be careful to prepare enough images for virtual machines to be started with a persistent disk. After this it has to start the virtual machine with appropriate parameters. For KVM, that means the virtual machine must be started with a properly set snapshot parameter.

The developed modules have been integrated into Apache Tashi, but could be further integrated into other IaaS platforms.

More Information

A more extensive description of the schedule is available in an accompanying Technical Paper. The source code for these modules can be found on our project’s SourceForge presence while online documentation is also available.

The documentation includes instructions on how the scheduler simulation can be run and how the scheduler can be tested without manipulating any virtual machines or servers. We hope you find it useful. Please get in touch if you have any feedback.

For more information, and to register, please see Events > The Dependable Cloud.