A Hierarchical Self-X SLA for Cloud Computing

A Hierarchical Self-X SLA for Cloud Computing 1 Ahmad Mosallanejad, 2 Rodziah Atan, 3 Rusli Abdullah, 4 Masrah Azmi Murad *1,2,3,4 Faculty of Computer Science and Information Technology, UPM, Malaysia, ahmad.upm@gmail.com, {rodziah,rusli, masrah}@upm.edu.my Abstract In cloud computing, service level agreement (SLA) is a mutual contract between service provider and consumer upon quality of service (QoS). Currently, there is no an effective relation among different SLAs while some of them affect each other. Moreover, different systems are employed to operate SLA based functions for instance SLA monitoring system, SLA based resource adapting system and etc. heterogeneous SLA based systems and lack of hierarchical relations have deducted the efficiency of SLA based systems. In this paper, the SLA structure is extended to support the hierarchical relation of SLAs in cloud computing. Additionally, a self-x ability is also proposed and added inside the SLA structure to supply the SLA based operations. A self-healing SLA is developed by extended SLA and the experiment results have presented its effectiveness. Keywords: Service level agreement, Cloud computing, Self-healing SLA, SLA monitoring, Hierarchical SLA 1. Introduction SLA is a mutual contract between service provider and consumer about quality of service (QoS). There are also several SLAs among different service providers in cloud computing environment which they offer software as a service (SaaS), platform as a service (PaaS) and infrastructure as a service (IaaS). Some of the SLAs are depended on each other hierarchically for instance: if the SLA in IaaS is violated all depended SLAs in PaaS and SaaS will be violated. To have an effective SLA based cloud operations, the hierarchical relation of SLAs should be taken into account. The current SLA structure does not support the hierarchical relation of SLAs in cloud computing. [1] and [2] tried to build the hierarchical relation of SLAs for specific purposes including SLA aggregation and SLA validation. However, they are not generalizable for all SLA based operations. In this paper, the SLA structure is extended to construct the hierarchical relation of SLAs in cloud computing. This relation can be employed for various purposes in different SLA based activities for instance SLA negotiating, SLA monitoring and resource adapting systems. Moreover, the self-x ability is appended to the SLA which X can be any SLA based actions. This feature enables the extended SLA to operate its functions by itself. The self-negotiating SLA, self-monitoring SLA, self-healing SLA are some samples of extended SLA actions. Finally, the hierarchical self-healing SLA is simulated for cloud computing to evaluate the proposed extended SLA. This paper is structured as follows. The related works are presented in Section 2. Then, the extended SLA is described in Section 3 by two subsections about hierarchical SLA and self-x ability. The hierarchical self-healing SLA is simulated and the results are presented in Section 4. Finally the discussion and conclusion are presented in Section 5 and Section 6 respectively. 2. Related Works This research tries to build a hierarchical self-x SLA by SLA extension. There are some related works for different aspects of this research scope. The related works are divided into three parts: SLA extension works, hierarchical SLA works and self-ability works in cloud computing area. A. Marco et al. presented a basic model of SLA for non-functional properties between service provider and consumer [3]. The web service (WS) agreement protocol is also proposed by v. Deora et al [4]. It is the XML-based document for functional and non-functional specification of agreed service. Furthermore, some basic standards and languages are proposed to describe the agreed QoS including International Journal of Digital Content Technology and its Applications(JDCTA) Volume8, Number1, February 2014 28

IBM web service level agreement (WSLA) [5] and web service management language (WSML) [6]. The structure of WS-Agreement is illustrated in Figure 1A as a basic SLA structure. Context Terms Service Description Terms Guarantee Terms Context Terms Service Description Terms Guarantee Terms Negotiation Terms Context Terms Service Description Terms Guarantee Terms Constraints Figure 1. A)The basic SLA[3] and extended SLA for: B) QoS renegotiation[3] C) creation constraints In a few works the SLA structure is extended for specific purposes. Figure 1B has presented the extended SLA structure by A. Marco et al. The Negotiation Term is added to the basic structure of SLA to enable the SLA renegotiation about violated QoS at run-time [3]. Besides, C. Muller et al. extended the SLA by adding the constraints as presented in Figure 1C [7]. The constraint part defined the different period of SLA attributes by different value. In related works, the SLA structure is extended to fulfill specific requirements. In this paper the SLA structure is extended to provide a general hierarchical self-x SLA in cloud computing. The hierarchical relation of SLAs is taken in to account in few works. The hierarchical aggregation of SLAs is done by U. H. Irfan et al. for Business Value Networks [1]. The SLAs had the top down links in SLA aggregation to be compatible for composed services. The hierarchical relation also took attentions for SLA validation in Service Value Chains [2]. B. Ivona et al. employed the hierarchical and layered cloud architecture to propagate the SLA violations among cloud actors [8]. The hierarchical relation of SLAs was also important in SLA establishing and monitoring [9]. So, each related works paid attentions to hierarchical SLA for specific reasons and all of them build this relation by their proposed frameworks. This paper extends the SLA structure to provide the hierarchical relation of SLAs for applying on SLA based operations. The self-x ability refers to the independent autonomic behaviors [10]. Several self-adaptive systems are applied in cloud computing to adapt the resources at run time based on agreed SLA [11] [12] [13]. Some other self-x samples are introduced including self-management [14] [10], self-configuring, self-healing [15] and self-optimizing [16] however they have a high overhead cost because they are separated systems from SLA. In this paper, the self-x ability is integrated in SLA structure. 3. SLA Structure Extension The SLA structure is extended for two purposes. First, it is extended to build a hierarchical relation of SLAs in cloud computing. Second, it is extended to enforce the self-x ability in SLAs. The extended SLA is illustrated in Figure 2. The Context and Term parts are represented in extended SLA as same as basic structure. They are the main parts of SLA which presented the information about parties, service attributes and agreed SLO. The Relation and Function are two extended parts which try to provide the hierarchical relation and self-x ability of SLA. 29

Figure 2. Extended SLA The Relation and Function parts refer to the structural and behavioral feature of SLA respectively. The addresses of related SLAs are recorded in Relation part which they would have depended, affected or spared relationship. They are employed for any necessary notification between SLAs by self-x functions. Any procedure could be defined in Function part for instance negotiating, monitoring, reacting etc. So each SLA can operate their tasks independently. 3.1. Hierarchical SLAs The SLA is extended to fulfill the hierarchical nature of cloud computing. Currently, the SLA is a lacking of any relation to other related SLAs while they depend on each other in cloud computing. The Relation part is added to the SLA structure to record the address of all related SLAs. So, each SLA can build a hierarchical relation with related SLAs. The example relation of SLAs in cloud computing is illustrated in Figure 3 which is introduced by M. Cumuzzi et.al [9]. The SLA CS is a mutual contract between business consumer and composite service provider. The SLA CS depends on SLA IS1, SLA AS1 and SLA AS2 as an infrastructure service and service components. Moreover, both SLA AS1 and SLA AS2 depend on another infrastructure service by SLA IS2.1 and SLA IS2.2. The hierarchical relation of SLAs is clearly illustrated in this scenario however the SLAs could not build this relation independently. The extended SLA can accomplish the hierarchical relation of SLAs as presented in Figure 4. Figure 3. Hierarchical relation of SLAs in cloud [9] If the extended SLA is employed for described scenario of Figure 3, the hierarchical relation of SLAs is constructed as depicted in Figure 4. The related SLA addresses are recorded in Relation part and each SLA is connected to the related SLAs hierarchically. This hierarchical relation is widely 30

employed in many SLA based activities for instance SLA monitoring, SLA reacting and SLA negotiating. This relation is highlighted in Self-healing scenario as presented in Section 4. Figure 4. Hierarchical relation of SLAs by extended SLA The related SLAs address should be recorded in Relation part at the SLA construction time. Moreover, the kind of relation is also noted. In presented scenario, the SLA CS recorded the SLA IS1, SLA AS1 and SLA AS2 as affected SLAs. The SLA IS1, SLA AS1 and SLA AS2 recorded the SLA CS as a dependent SLA. So, the both hierarchical and kind of relations are clarified by the extended SLA. 3.2. Self-X SLA Currently, the SLA based systems are centralized in a service provider and specific system is in charge for SLA operations for instance SLA negotiation system, SLA monitoring system and SLA based adaptation system. The extended SLA distributes these kinds of operation among SLAs and each SLA can do their procedures by itself independently. There are various functions related to the SLA in cloud computing for instance SLA monitoring, SLA managing, SLA based adapting, SLA negotiation. These kinds of functions are called X in this paper. The Self-X ability refers to the autonomic function which is done by SLA independently based on actor demand or environment changing. The extended SLA has the operational abilities while the basic SLA is the recorded document in database. Each SLA can have several self-x functions. Figure 2 has presented the Function part of SLA. Each SLA can monitor its attributes by its self-monitoring function and react against any detected violation. Each Self-X function employs SLA attribute metrics, agreed SLO value, related SLAs addresses and other variables based on the function responsibilities. The Self-X functions can invoke each other and they can be run sequentially as described in Section 4 for self-healing SLA scenario. 4. Self-Healing SLA Experiment and Result A hierarchical self-healing SLA is developed by extended SLA. The self-healing SLA is a closedloop of SLA violation detecting, diagnosing and reacting [17] which aims to prevent or revive the violated SLA. The self-healing SLA includes SLA contents, related SLAs address and two Self-X functions: self-monitoring and self-reacting functions as presented in Figure 5. The self-healing SLA is always at the running time. The raw data is collected based on agreed attributes. Then, the attribute value is measured in self-monitoring function and they are compared with agreed SLO. If the attribute value exceeds the agreed SLO, the SLA violation is happened and the selfreacting function should be invoked. The self-monitoring results are also recorded in monitoring log database. The self-healing function analyzes the kind of violation and provides the reaction plan based on rule-based reasoning method. The reaction plan is sent to the resource manager to enforce the planned infrastructure rearrangement. To prevent the SLA violation, the threshold value is employed to predict the SLA violation before happening. If the reaction plan could not prevent the violation, the 31

alert notification will be sent to the all dependent SLAs. This notification helps the related SLA to prevent the violation by early reaction. Figure 5. Self-healing SLA scheme based on extended SLA To evaluate the extended SLA, four self-healing SLAs with hierarchical relations are simulated. The collected data by [15] and [18] is employed to observe the self-healing SLA functionalities. The stress test is done and the number of SLA violations for end user is observed as illustrated in Figure 6. 400 350 300 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Figure 6. The detected violations for HS-SLA and SLA in stress test HS SLA SLA The critical value is increased 20 times step by step in the stress test. The number of SLA violations is presented in Figure 6 for both self-healing SLA and basic SLA. the number of violations in basic SLA is dramatically increased when the stress is enlarged. The self-healing SLA could resist aginst the critical situation after 9 th level of stress. the number of violations in self-healing SLA is more than basic SLA in specific short period, from 6 th to 8 th levels, because of unsuccessful reactions. 5. Discussion The extended SLA provided the hierarchical relation between SLAs in cloud computing and build the self-x ability in each SLA. The extended SLA is compared with some related works in SLA monitoring and adapting area as presented in Table 1. All of related works have done the SLA 32

monitoring automatically without any request but none of them had the self-monitoring ability. They had to employ the individual system to monitor the SLAs while the extended SLA could monitor their attributes by itself. Although the hierarchical relation is made in [19] and [2], the relation was between cloud managers rather than SLAs. The SLA based functions also distributed among actors not SLAs. In extended SLA, each SLA has its required hierarchical relations and actions. Table 1. Comparison of extended SLA and related works Proposed Solution Automated Hierarchical SLA Self-Monitoring Decentralized [19] * [20] [2] * [21] Extended SLA In Self-healing SLA case study, each SLA had its own monitoring and reacting operations. Moreover, the needed communications are done between hierarchical SLAs. So, the extended SLA is successfully employed to build a self-healing SLA. 6. Conclusion In this paper, SLA structure is extended to build the hierarchical relation of SLAs in cloud computing. Additionally, self-x ability is also proposed to operate the SLA based functions. Then, self-healing SLA is developed by extended SLA and the experiment results have presented the adaptability of services in stress test. Each extended SLA could monitor its attributes by itself and react against any detected violation. Other SLA based functions can be added and experimented in cloud environment as a future work. References [1] I. Ul Haq, A. Huqqani, and E. Schikuta, "Aggregating hierarchical service level agreements in business value networks," in Business Process Management, ed: Springer, 2009, pp. 176-192. [2] I. U. Haq, E. Schikuta, I. Brandic, A. Paschke, and H. Boley, "SLA Validation of Service Value Chains," in GCC, 2010, pp. 308-313. [3] M. Aiello, G. Frankova, and D. Malfatti, "What s in an Agreement? An Analysis and an Extension of WS-Agreement," in Service-Oriented Computing-ICSOC 2005, ed: Springer, 2005, pp. 424-436. [4] V. Deora, J. Shao, W. A. Gray, and N. J. Fiddian, "A quality of service management framework based on user expectations," in Service-Oriented Computing-ICSOC 2003, ed: Springer, 2003, pp. 104-114. [5] A. Keller and H. Ludwig, "The WSLA framework: Specifying and monitoring service level agreements for web services," Journal of Network and Systems Management, vol. 11, pp. 57-81, 2003. [6] A. Sahai, A. Durante, and V. Machiraju, "Towards automated SLA management for web services," Hewlett-Packard Research Report HPL-2001-310 (R. 1), 2002. [7] C. Müller, O. Martín-Díaz, A. Ruiz-Cortés, M. Resinas, and P. Fernandez, "Improving temporalawareness of WS-agreement," in Service-Oriented Computing ICSOC 2007, ed: Springer, 2007, pp. 193-206. [8] I. Brandic, V. C. Emeakaroha, M. Maurer, S. Dustdar, S. Acs, A. Kertesz, and G. Kecskemeti, "LAYSI: a layered approach for SLA-violation propagation in self-manageable cloud infrastructures," in Computer Software and Applications Conference Workshops (COMPSACW), 2010 IEEE 34th Annual, 2010, pp. 365-370. 33

[9] M. Comuzzi, C. Kotsokalis, G. Spanoudakis, and R. Yahyapour, "Establishing and monitoring SLAs in complex service based systems," in Web Services, 2009. ICWS 2009. IEEE International Conference on, 2009, pp. 783-790. [10] J. Kramer and J. Magee, "Self-managed systems: an architectural challenge," in Future of Software Engineering, 2007. FOSE'07, 2007, pp. 259-268. [11] D. Weyns, S. Malek, and J. Andersson, "On decentralized self-adaptation: lessons from the trenches and challenges for the future," in Proceedings of the 2010 ICSE Workshop on Software Engineering for Adaptive and Self-Managing Systems, 2010, pp. 84-93. [12] N. Huber, F. Brosig, and S. Kounev, "Model-based self-adaptive resource allocation in virtualized environments," in Proceedings of the 6th International Symposium on Software Engineering for Adaptive and Self-Managing Systems, 2011, pp. 90-99. [13] D. Weyns, B. Schmerl, V. Grassi, S. Malek, R. Mirandola, C. Prehofer, J. Wuttke, J. Andersson, H. Giese, and K. M. Göschka, "On patterns for decentralized control in self-adaptive systems," in Software Engineering for Self-Adaptive Systems II, ed: Springer, 2013, pp. 76-107. [14] F. Faniyi and R. Bahsoon, "Self-managing SLA compliance in cloud architectures: a market-based approach," in Proceedings of the 3rd international ACM SIGSOFT symposium on Architecting Critical Systems, 2012, pp. 61-70. [15] Y. Dai, Y. Xiang, and G. Zhang, "Self-healing and Hybrid Diagnosis in Cloud Computing," in Cloud Computing, ed: Springer, 2009, pp. 45-56. [16] S. Dobson, R. Sterritt, P. Nixon, and M. Hinchey, "Fulfilling the vision of autonomic computing," Computer, vol. 43, pp. 35-41, 2010. [17] H. Psaier and S. Dustdar, "A survey on self-healing systems: approaches and systems," Computing, vol. 91, pp. 43-73, 2011. [18] Z. Zheng and M. R. Lyu, "Ws-dream: A distributed reliability assessment mechanism for web services," in Dependable Systems and Networks With FTCS and DCC, 2008. DSN 2008. IEEE International Conference on, 2008, pp. 392-397. [19] O. Mola and M. A. Bauer, "Towards Cloud Management by Autonomic Manager Collaboration," International Journal of Communications, Network and System Sciences, vol. 4, pp. 790-802, 2011. [20] M. Maurer, I. Brandic, and R. Sakellariou, "Adaptive resource configuration for Cloud infrastructure management," Future Generation Computer Systems, 2012. [21] Q. Li, Q.-f. Hao, L.-m. Xiao, and Z.-j. Li, "An integrated approach to automatic management of virtualized resources in cloud environments," The Computer Journal, vol. 54, pp. 905-919, 2011. 34