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

The software illustrated in this video is currently being modified to accommodate the requirements of the use cases, and we are working to open-source it by Summer 2010. Please stay tuned for further updates!

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

• D.A1a Framework Architecture
• D.A2a Business SLA Management
• D.A3a SLA-aware Service Management
• D.A4a SLA-Aware Infrastructure Management
• D.A6a Predictable Service Engineering Methodology
• D.B2a Adhoc Demonstrator
• D.B3a ERP Hosting
• D.B4a Use Case Specification Enterprise IT
• D.B5a Service Aggregator
• D.B6a Use Case Specification eGovernment
• D.B7a Use Case Specification Financial Grids
• D.B8c Annual Review of External Collaborations

You can find links to all of our  deliverables under Deliverables,  whilst pointers to relevant deliverables have been added to each Focus Area page.

As always, we encourage you to contact us if you would like to connect with any of the research described.

1. Hui Li, Giuliano Casale, Tariq Ellahi. SLA-Driven Planning and Optimization of Enterprise Applications. 1st joint ACM WOSP/SIPEW Intl. Conference on Performance Engineering, San Jose, CA USA, Jan 2010. With an acceptance rate < 25%, this is a premier forum in the performance community.
2. Hui Li and Daniel Scheibli. On Cost Modeling of Hosted OLTP Applications. 1st Intl. Conference on Cloud Computing (CloudComp), Munich, Oct 2009.

Congratulations to all involved!

vfhea42rsm

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.