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.

The SLA@SOI management framework (http://sourceforge.net/projects/sla-at-soi/develop) can easily be applied to different Future Internet scenarios. The SLA model is rich and extensible enough to be applied to e.g. infrastructure and networking resources, to sensor-like resources in the Internet of Things, to services in the Internet of Services, but also to describe people, knowledge, and other resources. Similarly, the service construction model can be adopted, which allows specification of arbitrary internal resource/service aspects.

Based on this model foundation, the framework components can be flexibly instantiated. Assuming to have Manageability Agents for the relevant artefacts in the Future Internet, a management environment consisting of SLA and Service Managers can be set up in different flavours. The setup can support autonomic scenarios, where specific SLA/Service managers are responsible for single artefacts, but also highly coordinated scenarios, where SLA/Service managers govern a larger set of entities collectively. Business aspects can be addressed at all layers by introducing a dedicated business manager. Service Evaluations can be also introduced at all layers: However there will most likely be different evaluation/optimization mechanisms for different actual domains.

Last, different framework instances can be flexibly created and connected as needed according to the requirements of the involved value chain stakeholders in the respective Future Internet scenario.

Wolfgang Theilmann, SAP Research

The full article “A Reference Architecture for Multi-Level SLA Management” can be downloaded here.

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