1. Adaptive SLA-aware
Cloud Federations
Attila Kertész (SZTAKI), Ivona Brandic (TUW),
Gabor Kecskemeti (SZTAKI), Marc Oriol (UPC),
attila.kertesz@sztaki.hu
S-Cube Industry Workshop, Thales, France
Feb. 24, 2012.
www.s-cube-network.eu

2. Introduction
• Highly dynamic service environments require a novel
infrastructure to handle on demand deployment and
decommission of service instances.
• Cloud Computing allows:
• Outsourcing these dynamic environments
• Constructing extensible service-based applications
• Utilizes the latest achievements of Grid Computing, Service-
oriented computing, business-processes and virtualization
• Virtual Appliances encapsulate metadata with a complete
system (OS, libraries and applications)
• Infrastructure cloud systems (IaaS) allow to instantiate
VA’s on their virtualized resources: Virtual Machines
• Several public and private IaaS systems co-exist
• Only a “Federated Cloud” could offer the different
capabilities as a whole
© S-Cube – 2

3. IaaS utilization steps
Repository Repository Repository
Virtual
VA
VA VA
ApplianceVA VA
VA VA VA
VA
Instantiation
Support
Virtual Libs
Appliance + Service Delivery
Support OS
Libs Environment
+ VA Service
VM
OS
Environment VMM VMM VMM
VA VMM VMM
VMM HostVMM Host
VMM Host
VMM
VMM VMM
Host Host
VMM Host
VMM
Host
VMM VMM Host Host
Host
VMM HostVMM Host Host
Host Host
Host Host
Infrastructure as a Service Cloud
© S-Cube – 3

4. Federated Cloud Management (FCM)
• An autonomic resource management solution
• Provides an entry point to a cloud federation
• Provides transparent service execution for users Cloud
• Following challenges are considered:
Cloud FCM Cloud
• Varying load of user requests
• Enabling virtualized management of applications Cloud
• Establishing interoperability and provider selection
• Minimizing Cloud usage costs
• Builds on meta-brokering, cloud brokering and automated on-demand
service deployment
• Layered architecture
• Meta-broker
• Cloud Brokers
• Cloud infrastructure providers
A. Cs. Marosi, G. Kecskemeti, A. Kertesz, P. Kacsuk, FCM: an Architecture for Integrating IaaS
Cloud Systems, In Cloud Computing 2011, IARIA, pp. 7-12, Rome, Italy, 2011.
© S-Cube – 4

5. FCM Architecture: overview
1
Generic Meta-Broker Service • Top-level brokering
• Autonomously manage
FCM the interconnected
Repository cloud infrastructures
CloudBroker CloudBroker • Forms a federation with
the help of Cloud
Brokers
Clouda Cloudb
G. Kecskemeti, A. Kertesz, A. Marosi, P. Kacsuk, Interoperable Resource Management for establishing Federated
Clouds, In Achieving Federated and Self-Manageable Cloud Infrastructures: Theory and Practice, IGI Global (USA), 2011.
© S-Cube – 5

6. FCM Architecture: overview
• Manages VA
Generic Meta-Broker Service
distribution among the
various cloud
2 infrastructures
FCM
Repository • Automated federation-
CloudBroker CloudBroker
wide repository content
management
• Offers current VA
Clouda Cloudb availability and
estimates its future
deployment
© S-Cube – 6

7. FCM Architecture: overview
Generic Meta-Broker Service
FCM • Interacts with a single
Repository IaaS system
3 3
CloudBroker CloudBroker • Manages resources
• Schedules service calls
Clouda Cloudb
© S-Cube – 7

8. Generic Meta-Broker Service
Meta-
FCM
Repository • BPDL – Broker Property
VAx..VAy
Description Language
Service call Call result
(+requierments) • Cloud Brokers are
described
IS Agent
Generic Meta-Broker Service
• Basic and aggregated
Meta-Broker Information dynamic properties
Collector
Core
BPDL list • Estimated availability time
for a specific VA in the
MatchMaker Invoker native repository
• Average VA deployment
time
• Scheduling: filters and
CB CloudBroker CloudBroker
ranks Cloud Brokers
Clouda Cloudb Cloudc
© S-Cube – 8

9. Cloud Broker
Generic Meta-Broker Service
CloudBroker a
• Dynamic requirements
VAx VAy may be specified with a
FCM
Q1
Clouda Clouda Repository service call
VMQx VMQy VAx..VAy
• Treated as a new VA type
Clouda VM Handler
• Some IaaS systems offer
predefined classes of
VMx1 VMy1 resources
Native Repository
• Resource class selected
VMx 2 VMy2 with at least the required
… … resources
VMxn VMym
Clouda © S-Cube – 9

10. Cloud Broker: Scheduling of service calls
• The Cloud Broker performs scheduling of service calls to
resources (VMs)
• Based on the monitoring information gathered
• May decide to start new resources based on:
• The number of running VM’s to handle the service call
• The number of waiting service calls in the Service call queue
• The average execution time of service calls
• The average deployment time of VA’s
• SLA constraints
• VM decommission
• Takes into account the “billing period”
© S-Cube – 10

11. Service monitoring with SALMon
• Service Level Agreement Monitor (SALMon): designed for
monitoring QoS of software services
• Capable of passive monitoring and testing purposes
• Supports any type of service technology (SOAP-based WS,
RESTful services, etc.)
• It is itself an SBA with two main components:
• Monitor: retrieves values of quality metrics with the help of Measure
Instruments
• Analyzer: evaluates conditions over these metrics
• It is suitable for monitoring running services in Cloud infra-
structures
© S-Cube – 11

12. The SALMon service monitoring
framework
© S-Cube – 12

13. Integrated Monitoring Approach for Seamless
Service Provisioning (IMA4SSP)
© S-Cube – 13

14. IMA4SSP details
• We have integrated SALMon to enable performance-driven
SLA-based service executions in Cloud federations
• Metrics related to service methods may be defined to monitor
service operations
• Metric values are regularly refreshed in the Generic Service
Registry (GSR) of the architecture
• Finally information stored in the GSR are used by the GMBS
for Cloud infrastructure selection based on service reliability
A. Kertesz, G. Kecskemeti, M. Oriol, A. Marosi, X. Franch, J. Marco, Integrated Monitoring Approach for
Seamless Service Provisioning in Federated Clouds, Proc. of PDP '12, IEEE CS, 2012.
© S-Cube – 14

15. Enhanced monitoring with M3S
• SALMon reports
service metrics to
3. Fetch
Users a DB regularly
GMBS
reliability checked by the
info
meta-broker
SALMon • The Minimal Metric
DDBB CloudBroker CloudBroker Montoring Service
OpenNebula Amazon
(M3S) is used to
2. Send monitor:
results
• Availability;
SALMon
VM • Computing
M3S capability;
1. Test
metrics • and data transfer
reliability.
© S-Cube – 15

16. Miminizing monitoring costs
• Keeping the monitoring VMs in the Cloud can be costly
• To reduce these costs, the IS Agent component of GMBS has
been extended to initiate the deployment and decommission of
these VMs
• The monitored metric values have timestamps
• When the retrieved metric value of a service is outdated, the IS
Agent contacts the responsible Cloud Broker to initiates a M3S and
SALMon VM deployment
• When metric values with new timestamps are read from the
registry, the IS Agent contacts the CB again, to decommission the
monitoring VMs
© S-Cube – 16

17. Autonomous behavior
• Inter-Cloud management for optimized resource usage and
SLA violation prevention
• Predefined set of reactive actions in the Knowledge
management system requiring local/global intervention in the
system
Action Involved Component Integration
Reschedule calls Meta-Broker Global
Rearrange VM queues Cloud-Broker Global
Extend/Shrink VM Queue Cloud-Broker Local
Rearrange VA storage FCM repository Global
Self-Initiated Deployment Service instances Local
• Adaptation actions are triggered by a rule-based system,
based on monitored metrics
© S-Cube – 17

18. Hybrid knowledge management in FCM
Hybrid approach for
incorporting a Knowledge
Management System to
FCM: global and local
Allows global control over
local decisions
Global KM could stop the
application of a locally
optimal action to avoid an
autonomic chain reaction
Enables the execution of more
fine-grained actions
postponing adaptation
action exhaustion
G. Kecskemeti, M. Maurer, I. Brandic, A. Kertesz, Zs. Nemeth, and S. Dustdar,
Facilitating self-adaptable Inter-Cloud management, Proc. of PDP '12, IEEE CS, 2012.
© S-Cube – 18

19. Monitored metrics
- Service call queue length in every Cloud-Broker
Call rescheduling
- VM queue length for every appliance in every Cloud-Broker
- Call throughput
- Average waiting time for particular service
- Average waiting time of a queue
storage extension/shrinking
- Number of service (s) instances in an IaaS system (x):
rearrangements
vms(x,s)
and queue
VM queue
- Call/VM ratio
- overall infrastructure load
rearrang
ing VA
- Global storage cost
© S-Cube – 19

20. Conclusions
• We have designed a Federated Cloud Management solution that
acts as an entry point to cloud federations
• Meta-brokering, cloud brokering and on-demand service deployment
• We have shown how Cloud Brokers manage the number and
location of VMs for the various service requests
• We have extended FCM with enhanced SLA monitoring
capabilities with the SALMon framework in collaboration with
Universitat Politecnica de Catalunya (UPC)
• We have developed a method to enable SLA-aware self-adaptable
Inter-Cloud management with a rule-based knowledge model in
collaboration with the Technical University of Vienna (TUW)
© S-Cube – 20

21. Relation to S-Cube learning packages
• The presented work is related to the following packages:
• JRA-1.2: Service Level Agreement based Service
infrastructures in the context of multi layered adaptation
• JRA-2.3: SLA-based Service Virtualization
in distributed, heterogenious
environments
• The following research topics are covered:
• T-JRA-2.3.1: Infrastructure Mechanisms for the Run-Time Adaptation of
Services
• T-JRA-1.2.2: Integrated Adaptation Principles, Techniques and Methodologies
• T-JRA-1.2.3: Comprehensive, Context-Aware Monitoring

22. Thank You for your attention!
Questions?
https://www.lpds.sztaki.hu/CloudResearch
© S-Cube – 22