Adaptive SLA-aware Cloud Federations
- 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