A predictive framework for load balancing clustered web servers

J Supercomput (2016) 72:588–611 DOI 10.1007/s11227-015-1584-8

A predictive framework for load balancing clustered web servers Sanaz Sheikhi1 · Seyed Morteza Babamir1

Published online: 9 December 2015 © Springer Science+Business Media New York 2015

Abstract Self-adaptation is the mechanism that is used automatically by some clustered web servers for resolving issues such as server bottleneck and overload. Such mechanisms are usually reactive meaning that they will be used when some issue occurs. However, taking an adaptation mechanism after arising a bottleneck or overload may be late and can cause some problems. Such problems could be resolved if we are able to predict future behavior of servers. To this end, based on our previous experiences, we presented a framework by which an adaptation strategy is selected based on a learning-based predictive method. Through the prediction, we are provided with a number of decision-making parameters for adaptation strategy selection. To show the effectiveness of our framework, we applied it for design and implementation of a differentiated cluster-based web server system and showed results. In such systems, each cluster is considered to serve a specific service. By comparison of simulation results between our predictive method and the reactive one, we found: (1) increase of the number of replied requests by servers, (2) decrease of average response time, and (3) increase of resource utilization of the system twofold to threefold. Keywords Clustered web servers · Self-adaptation · High-level specification · Learning-based prediction · Load balancing

1 Introduction A self-adaptive system is a system that has been armed with mechanisms for detecting problems and taking strategies for resolving them. Such mechanisms may be reactive

B 1

Seyed Morteza Babamir [email protected]; [email protected] Department of Computer Engineering, University of Kashan, Kashan, Iran

123

A predictive framework for load balancing clustered web servers

589

or predictive. While the former tries to make a system self-adaptive by redressing the system when some issue occurs, the latter tries to prevent the system from entering such a situation in future. The latter is intended for resolving some problems that the former suffers from [1]. Considering our previous experience of exploiting a predictive-based approach, we aim to present a framework in which a learning-based predictive approach is used [2]. Another feature of our work is using the architecture-level (high-level) specification of the system constraints and self-adaptation strategies. In contrast with such specifications, some studies used low-level (code-level) mechanisms, for instance, exception handling routines and code redundancies. However, such mechanisms are more suitable for functional requirements, which is component-level instead of quality attributes such as load balancing, which is system-level. Such a specification is called architecture-based self-adaptation and has been regarded as a preferable approach by researchers [3–5]. In [6], Garlan accounted features of architecture-level specification for self-adaptive systems. An architecture-based specification method is expressed by schematic diagrams or specific languages such as one that we used in this article [7]. We had a previous experience of applying a high-level model called Techne for testing adaptive systems [8]. Exploiting such architecture-level specification helps us to deal with detection, diagnosis, and resolution of the problems in an abstraction level. Moreover, it: (1) creates a global view of system behavior, system properties, and system constraints and (2) exploits an abstraction analysis to detect problems and proposes corrective solutions. Although [3–5] enjoy architecture-level method for specification of self-adaptive strategies, they employ areactive decision-making method meaning that an adaption strategy is selected and executed when some issue occurs. However, such an approach could not always lead to selection of an optimal strategy because in some cases, a decision may be optimal if we know just the current system state but not suitable if we do future states of the system. To tackle this problem, predictive-based methods were considered. According to the specification, we will select an adaptation strategy based on prediction of potential (future) behavior of the system if the prediction denotes some issue. We used the Viterbi algorithm, which is a statistical learning-based method [9] to predict potential behavior of the system. It can predict the probability of hidden states of a self-adaptive system based on Hidden Markov Models (HMMs). Our framework consisting of learning-based prediction and adaptation strategy selection is applied to the differentiated web cluster system. The system becomes selfadaptive by the intelligent prediction of future behavior of the system based on its up-to-now behavior. A differentiated web cluster system consists of clusters each one which has been meant to a specific service and self-adaptation is considered as cluster load balancing. We adopt self-adaptation strategy based on pre-defined quantities: (1) the number of requests replied by the servers, (2) the average time of responses to requests, and (3) the rate of resource sharing among requests. We continue the paper as follows: In Sect. 2, we discuss the related work. In Sect. 3, we address architectural specification of system and adaptation strategy. In Sect. 4, we describe our framework and in Sect. 5, we introduce cluster-based web server systems and apply our framework to it. In Sect. 6, we discuss results and in Sect. 7, we deal with conclusions and future work.

123

590

S. Sheikhi, S. M. Babamir

2 Related work The discussion about the related work is twofold: (1) The self-adaptive methods specify a system and its constraints in architecture-level and (2) the methods use prediction for the self-adaptation of future behavior of the system; our framework exploits both of them. To specify a system in architecture level: (1) components, (2) connectors between the components and (3) the constraints governing the architecture of the components and connectors are determined. For a client–server system such as clustered web servers, clients and servers are the components and connections between clients and servers are the connectors. The governing constraint in the system is that each client connects to a specific server and there is no connection between two clients. Cámara et al. [3–5] and Cheng et al. [10] used the system architecture specification for self-adapting the pervasive computing systems where the pervasive environment consists of a set of mobile users accessing shared information through a variety of devices and the users need high reliability, QoS and low cost. In [8], we used a highlevel model called Techne for testing adaptation systems. Garlan [11] proposed a framework (called Rainbow) consisting of the specification of system architecture and system constraints to (1) monitor the system and detect violation of the constraints and (2) select an adaptation strategy. However, the approaches stated above are reactive (see Sect. 1), which may decrease the system performance and impose an extra cost due to applying some strategy after occurring an issue [1]. To resolve such problems, we determine parameters of selfadaptation strategy selection through predicting future work modes of the cluster system. The second part of discussion is related to the prediction. We used two learningbased prediction methods: (1) “Nonlinear Autoregressive with External (eXogenous) inputs” (NARX) and (2) “Nonlinear Autoregressive” (NAR) for verifying three concurrent programs [2]. We used two versions of NARX and two versions of NAR for prediction of deadlock in three different multithreaded programs. NARX and NAR are two types of recurrent Neural Networks. The result obtained from the experiments with NARX for the third program showed 74–76 % deadlock predictions were successful. Poladian et al. leveraged the resource prediction for anticipatory dynamic configuration [12] and Cheng et al. employed their prediction results for deciding on the self-adaptation mechanisms [13]. However, their prediction mechanism was created for just the prediction of resource availability. In this paper, in addition to prediction of resource utilization, our approach addresses prediction of future work modes of the cluster system and then adapts them based on specification of the system constraints (qualities). In [1], Anaya et al., with accounting the problems of reactive methods, used a prediction-based method for self-adaptation of sensor networks. In [14,15], predictive methods were used to predict resource availability. In [15], Sharifian et al. used a probabilistic predictive method to load balancing clustered web servers. The load balancer is a classifier for the: (1) classification of clients’ requests into different classes, (2) dynamic selection of a request from a class and (3) assignment of the request to a server. Their main theme is about the prediction of load work of cluster-based web servers; however, their approach is not self-adaptive.

123


591

3 Specification In a dynamic self-adaptive system, the runtime behavior of the target system is monitored constantly and analyzed. Then, a compensation strategy will be recommended when some constraint is not met. In Sects. 1 and 2, we stated advantages of the high-level specification of adaptive systems. According to a survey [16], for design of adaptive systems, two approaches have been proposed: (1) adoption of architectural model such as Rainbow [11] and (2) use of the control theory concepts such as Zanshin [17] that exploit feedback loops. In our framework, we used the architectural Description Language (ADL) ACME [7] for specification of system architecture and its constraints. In our framework, we used the architectural language Stitch [18] for specification of adaptation strategies. The following explains our motivation for choosing a high-level language. As stated in Sect. 1, the strategies are typically introduced in terms of codebased mechanisms, for instance, program exceptions. However, they are suitable for the decisions taken locally (module-level) not globally (system-level such as system load balancing). Furthermore, the low-level strategies are application-specific and may not be used in abstraction level. In the following, we briefly explain elements of the ACME and Stitich architectural languages. As stated in Sect. 2, the architecture-level specification consists of, components, connectors between the components and the constraints governing the system architecture. To this end, ACME consists of some specifiers: Component, Connector, port, role and property, where (1) ports are gateways of connectors, (2) roles indicate the tasks of connectors, and (3) properties are the variables used by components for representing the constraints. The Stitch language consists of: (1) the basic commands called Operators, (2) a sequence of commands for defining an action, called a Tactic and (3) adaptation (repair) patterns, called Strategy. A Tactic includes three parts: conditions, sequence of actions, and a set of effects that will be held after the sequence execution. A Strategy indicates an adaptation pattern in which an action is executed based on evaluation of a number of conditions. In fact, Strategy is a tree of tactics, which is responsible for holding quality dimensions of a system. After execution of a Tactic, the system is analyzed to select next tree Tactic branch. The selection of a Tactic branch, called Tactic matching, is based on evaluation of some quality dimensions.

4 The proposed framework Our approach is a dynamic and learning-based self-adaptation approach meaning that it aims to predict the future runtime behavior of a target system based on training its past runtime behavior and recommend an adaptation strategy if some issue is predicted. The framework consists of three layers: (1) architectural layer, which was considered for the high-level specification of the target system (stated in the ACME language) and adaptation strategies (stated in the Stitich language). When an adaptation is recommended to the system, it should be applied to the system architecture in this layer. (2) Strategy selection layer for prediction and strategy selection. (3) System layer for monitoring runtime behavior of the target system and applying an adaptation

123

592


Fig. 1 The high-level structure of the proposed framework

Fig. 2 The detailed structure of the proposed framework

strategy if recommended. Figures 1 and 2 show the high-level and detailed views of our framework where the first layer includes the specifications whose elements were explained in Sect. 3. Now, we explain the framework layers more detail.

123

A predictive framework for load balancing clustered web servers Table 1 Mapping monitored values to time series symbols

Observation

593 Symbol

conn.latency > M. MAX_LATENCY

V1

conn.latency M.MAX_UTIL

V3

s.load Rac ∗ Gamahigh (defined as LL. 4–5 in Appendix 3), (b) shared mode to exclusive mode when Rac ∗ Gamalow > load ≥ Rac ∗ Gamahigh (defined as LL. 6–7 in Appendix 3), (c) exclusive mode to shared mode when load ≤ Rac ∗ Gamalow (defined as LL. 8–9 in Appendix 3) (d) shared mode to shared mode when load ≤ Rac ∗ Gamalow (defined as LL. 8-9 in Appendix 3).

123


599

where Rac is Reactivity Coefficient (explained above) and Gamalow and Gamahigh are two load factors. We considered default values 100, 80, and 90 % for Rac , Gamalow , and Rac × Gamahigh , respectively (defined as LL. 2 and 4–5 in Appendix 2). In shared mode, a cluster replies to the requests that receive from the class switch and allows to web servers of other clusters use its resources. In the exclusive mode, a cluster replies to the requests are sent to and is unable to share its resources with other clusters. In this mode, load of the cluster has been reached the RC threshold and hence sharing its resources leads to an overload. In the saturated mode, a cluster cannot reply to any request and requests are rejected because the cluster load has been exceeded the RC threshold. Load value of a cluster is computed as the average load of web servers of the cluster and loadik indicates the load value of cluster i at time k. Adaptation strategies When a switch class delivers a client’s request to a respective cluster, the cluster adapts itself according to one of the following strategies: (a) No adaptation is required if the cluster works in the shared mode. (b) When a cluster works in exclusive mode, adaptation strategy is assigning a less load web server of system to the cluster (indicated by strategy AllocateHostToCluster and defined as LL. 12–20 in Appendix 3); this is carried out by changing connectors between components in architectural model. (c) When a cluster works in saturated mode, adaptation strategy is increase of the cluster threshold by Delta (indicated by strategy UpdateThreshold and defined as LL. 21–26 in Appendix 3; default value for Delta is 0.1, L. 3 in Appendix 3). In this work mode, if the number of increases in the threshold is exceeded a predefined number in a period, threshold of the least load cluster in the system is decreased by Delta (indicated by strategy ControlRhresholdUpdates and defined as LL. 33–38 in Appendix 3). However, the total number of increases in threshold should not exceed 50% of the initial threshold value, i.e., 1.5 × Rac . (d) Threshold of a cluster should be reinitialized when the cluster returns to the shared mode (indicated by strategy ReIntializeThreshold and defined as LL. 27–32 in Appendix 3). For example, when a web server is borrowed from a less load cluster and added to a saturated cluster, the saturated cluster will be backed to its original work mode. This replacement leads to change of connectors of the two clusters.

5.3 Evaluation of the proposed framework In the first step, we simulated the web server cluster system by Simulink toolbox of MATLAB and monitored average load of all clusters. The system consists of 2 clients, 1 switch including one request dispatcher and one response dispatcher, 2 clusters (each cluster includes 2 web servers), one predictor and one strategy executor. In the second step, we: (a) As stated in Sect. 4 and Table 1, mapped 3 concerned observation to symbols V1 , V2 , and V3 (Table 2),

123

600


Table 2 Mapping system observations to time series symbols Observed system values (outputs)

HMM observation symbol

cluster. load cluster.Rac * Gamalow && cluster. load < cluster. Rac * Gamahigh

V2

cluster. load > cluster. Rac * Gamahigh

V3

Fig. 7 The HMM for the cluster based web servers

a11

a22 a12

S 1: shared

a21 b12 b11

b21 y1: V1

Table 3 Initial transition and emission probabilities (with random numbers)

a33

S 2: exclusive

a23

S3: saturated

a32

b22

b33

b32

b23 b13

b31 y1: V2

y1: V3

A0 = [0.3333

0.3333

0.3333

0.1500

0.7000

0.1500

0.1500

0.1500

0.7000]

B0 = [0.1098

0.5649

0.3253

0.1098

0.5649

0.3253

0.1098

0.5649

0.3253]

(b) Executed the system a number of times and observed system outputs (i.e., Vi s, i = 1, 3), which leads to a sequence of Vi s, say V1 V3 V2 V2 . . ., in length of t for t system outputs, (c) Constructed HMM of the system (Fig. 7) according to Figs. 3 and 4 and specification of the system and strategy adaptation (stated in Appendixes 1–3). Based on the adaptation strategy defined for the system, the HMM consists of three states called S1 , S2 , and S3 indicating shared, exclusive and saturated work modes, respectively. Based on Table 2, the HMM consists of three types of observations called V1 , V2 , and V3 . Transition and emission probabilities were initialized with arbitrary values (Matrices A0 and B0 in Table 3), (d) We trained the HMM using the Baum–Welch algorithm and obtained trained transition and emission probabilities (Matrices A and B in Table 4). In the third step, we executed the system for a while and observed system outputs; then, we applied the Viterbi algorithm for computing the most probable path of hidden states leading to the sequence of observations, i.e., system outputs (Fig. 8). For a sequence of less than 1000 observations, almost all state predictions were correct. However, for more than 1000 and less than 5000 observations, the veracity of states

123

A predictive framework for load balancing clustered web servers Table 4 Trained transition and emission probabilities (by the Baum–Welch algorithm)

A = [0.9939

601

0.0031

0.0031

0.0007

0.8230

0.1763

0.0007

0.1763

0.8230]

B = [0.5721

0.4137

0.0142

0.0500

0.0500

0.9000

0.0500

0.0500

0.9000]

Fig. 8 The Viterbi veracity in prediction of future results of the cluster based web servers

prediction was reduced but it was more than 50 %. The average veracity of states prediction for 500–5000 observations was 70.7 %. In the fourth step, to select the most proper adaptation strategy when some cluster is in the saturated work mode, we ranked the strategies by considering the following quality dimensions (constraints) and using the utility theory (see Sect. 4). We consider that to what extent strategy adaptations influences to these qualities. Quality dimensions are defined based on the system goals: • ReplytoReq the number of requests is replied to. The value of 0.6 for many and 1 for all, • ReduceRespTime decrease of response times. The value of 0.9 for high, 0.5 for medium, 0.2 for little, • ShareResources utilization of shared resources (web servers). The value of 1 for full and 0.5 for half. We determine the weight of each quality dimension according to the user’s view; for instance, W ReplytoReq = 0.5, W Reduce RespT ime = 0.3, and W Shar e Resour ces = 0.2. For four strategies we explained in Sect. 5.2, we compute value of the utility function that we defined in Sect. 4 for the quality dimensions. Table 5 shows utility values of the strategies, which lie between zero (null) and one (full) where values “1”, “between 1

123

123

Many (0.6)

Many (0.6)

All (1)

Many (0.6)

AllocateHostToCluster

ReInitializeThreshold

ControlThresholdUpdates

ReplytoReq , 0.5

Medium (0.5)

Little (0.2)

Little (0.2)

Medium (0.9)

ReduceRespTime ,0.3

Quality Dimensions and their weigths

UpdateThreshold

Strategy

Table 5 The extent of satisfying quality dimensions by adaptation strategies

Fully (1)

Fully (1)

Nohow (0)

Half (0.5)

ShareResources ,0.2

(0.5 × 0.6) + (0.3 × 0.5) + (0.2 × 1) = 0.65

(0.5 × 1) + (0.3 × 0.2) + (0.2 × 1) = 0.76

(0.5 × 0.6) + (0.3 × 0.2) + (0.2 × 0) = 0.36

(0.5 × 0.6) + (0.3 × 0.9) + (0.2 × 0.5) = 0.58

Total utility value Wquality × utility value

602 S. Sheikhi, S. M. Babamir


603

and zero”, or “zero” indicate the strategy satisfies the quality fully, partially, or nohow, respectively. Value of quality ReplytoReq shows quality of service (QoS) in reply to requests. The utility value will be (all, 1), (many, 0.6), or (noEffect, 0) if we want an adaptation strategy satisfies reply to all, more than half, or none of requests. The third case denotes that the strategy execution has no effect on the number of replied requests. Value of quality ReduceRespTime shows amount of load balancing indicating response time of requests. The utility value is (little, 0.2) or (high, 0.9) if execution of an adaptation strategy decreases response time low or considerably. In the fifth step, as mentioned in Sect. 4, we should apply the adaptation strategy selected in the fourth step to the architectural model stated in ACME language in Sect. 5.1 (see module 6 in Architecture layer in Fig 2). This task was done using the AcmeStudio software [27]. Applying a selected strategy to the running system leads to change of the execution path of the running system.

6 Discussion We discuss some scenarios to show: (1) the problems of the reactive strategy selection policy and (2) benefits of exploiting prediction in the adaption strategy selection: (a) The adaption mechanism selects the UpdateThreshold strategy when a cluster is saturated. If other clusters work in the exclusive mode at the same time, in reactive approach the system will reject all the requests of the saturated cluster until UpdateThreshold strategy is executed completely and successfully. However, in prediction approach, the UpdateThreshold strategy is selected if it is predicted that one of the clusters will be in the saturated mode in future. Predicting the saturation work mode of a cluster and executing UpdateThreshold strategy in advance leads to avoiding the saturated mode of the cluster. Since such prediction culminates in replying more requests, the ReplyAllRequests quality dimension is improved. Similarly, the AllocateHostToClusters strategy is selected if the exclusive mode is predicted for one of the clusters. (b) If one of the clusters, say C1, is working in the exclusive mode, the adaption mechanism will choose the AllocateHostToClusters strategy as a solution. Through this strategy, a web server of some another cluster, say C2, is selected and added to the cluster C1. However, if this operation brings a prediction of saturation of the cluster C2, the adaption mechanism will select the UpdateThreshold strategy instead of AllocateHostToCluster one. According to this prediction, C2 will not be saturated and C1 will return to the shared mode, (c) The adaption mechanism selects the AllocateHostToClusters strategy if one of the clusters is in exclusive mode. However, the adaption mechanism will become aware of returning the cluster to the shared mode if we employ a prediction method. Accordingly, the mechanism will refuse to select AllocateHostToClusters. The same policy can be applied to a saturated cluster when it is predicted that the cluster will be turned back to the exclusive mode in future. In both of cases, the prediction and adaption will assist to the system in not executing the unsuitable strategies; accordingly, time and cost is saved.

123

604


Therefore, exploiting prediction in a strategy selection can avoid: (1) occurrence of undesirable states in future, (2) execution of unsuitable strategies or the strategies having short time effect and (3) execution of strategies that may cause problems. These avoidances improve the satisfaction of quality dimensions. Moreover, to avoid a future undesirable work mode of the system, we ranked all selected strategies to select the most suitable strategy.

6.1 Evaluating the predictions To evaluate the influence of our prediction on strategy selection, we configured two separate cluster-based web server systems using the Simulink toolbox of MATLAB. The first configuration, named Reactive, selects an adaption strategy without prediction. In the second one, the Viterbi algorithm was used for prediction. In each configuration, we observed the results by changing (1) parameters Rac , Gamahigh and Gamalow (see Sect. 5.2) and (2) length of the observation period. The simulation results showed that the quality dimensions were considerably improved when we used the Viterbi predictor for the system adaptation. Figure 9 shows the simulation results for the number of requests replied by the system where Rac = 200, Gamahigh = 0.9, Gamalow = 0.8, and Delta = 0.1. This diagram is an evidence to corroborate the use of prediction in selection of a strategy for improvement of the ReplyToReq quality dimension. We found that the results are almost the same when clients’ requests are less than 4000 because in case of Rac = 200, no two clusters are concurrently in the (1) sat-

Fig. 9 The request–response diagram

123


605

Fig. 10 The response time diagram

urated mode or (2) saturated and exclusive modes. However, when clients’ requests exceed 4000, clusters concurrently reach saturate and exclusive modes many times. Accordingly, adaption strategies are repeatedly applied to the system. In such a situation, prediction is so helpful for selection of an optimal strategy. Figure 10 depicts average response time of the Reactive and predictive configurations. Figure 10 shows the acceptable response times when the simulation time was short. However, when we extended the simulation time and consequently received more requests, in the Reactive configuration some of clusters entered the saturate mode, some of them remained in the shared mode, and one of them entered the exclusive mode. Moreover, many requests remained in buffers for a long time and therefore the average response time was increased. Predicting work mode of clusters and selecting strategies for avoiding occurrence of predicted undesirable states enabled clusters to reply to more requests and requests remained in buffers for shorter time than before. Figure 11 depicts resource sharing using the Reactive and predictive configurations. The rate of resource sharing is low in the Reactive configuration because clusters frequently work in saturate or exclusive modes and cannot share their resources. However, thanks to prediction of undesirable states in the predictive configuration, the shared mode of clusters was more than that of clusters in the Reactive configuration. Note that the shared mode indicates that a cluster can share their web servers with others. Therefore, the ShareResources quality dimension is improved through the prediction of the system modes. Another simulation was carried out for a differentiated cluster-based web server system with four clusters including three Puppy Linux servers for each cluster. Table 6

123

606


Fig. 11 Resources sharing diagram Table 6 Simulation Results using the Reactive and viterbi configurations #req.

#CPV

#RS

#RV

ARS

ARV

RSS

RSV

1000

907

980

1000

1.2

1

10

17

5000

4650

4385

4831

7.5

5.4

105

209

10000

8717

8154

9127

15

11

304

837

15000

13522

12283

13352

22.5

18

726

2060

20000

17813

16703

17955

27

21.5

1116

2719

9121.8

8501

9253

14.64

11.38

452.2

1168.4

Average 10200

#req. the number of request, #CPV the number of correct predictions by Viterbi, #RS the number of system responses using the Reactive, #RV the number of system responses using Viterbi, ARS Average response time using the Reactive, ARV Average response time using Viterbi, RSS resource sharing using the Reactive, RSV resource sharing using Viterbi

shows simulation results where the last row states average value of each column. The average value of the second column shows 89.4 % predictions were successful. The comparison between the percentage of average values of columns 3 (83.3 %) and 4 (90.7 %) shows the number of system responses increased 7 % using Viterbi. The comparison between average values of columns 5 and 6 shows the average response time decreased 3.26 using Viterbi over non-prediction method. The most significant improvement is shown by comparison of 2 last columns; resource utilization increased more than 2 times using Viterbi over the non-prediction method.

7 Conclusions and future work In this article, we proposed a predictive framework for self-adaptation of cluster-based web servers. It was considered that use of a suitable prediction for self-adaptation of

123


607

systems decreases the cost imposed on the system due to misbalancing load of servers. The simulation results showed the Viterbi predictor selects the adaption strategy that brings a significant improvement in the satisfaction of desired quality dimensions. The prediction assisted in determining parameter values of the system ahead. This leads to decrease uncertainty at runtime and decrease the probability of making incorrect decisions for the system adaptation. Moreover, the simulation results showed that the more predictions are accurate, the more resource sharing and less response time are used. Increase of clients’ requests increases the probability of saturate and exclusive modes of clusters; this leads to applying adaption strategies more, which causes more cost and more response time in the reactive approach. In such a situation, prediction is so helpful for selection of an optimal strategy. Moreover, the number of requests in waiting list of clusters becomes less; this leads to decrease of the average response time. In fact, prediction of cluster work modes and selection of strategies for avoiding future undesirable modes enable clusters to reply to more requests. Definition of the undesirable mode of a system is not restricted to a couple of cases. As a future work, one can try to compute the utility function dynamically through the change of quality dimensions weights. Increase of the time domain of the prediction leads to the improvement of decision-making in adaption strategies. Therefore, another future work is dealing with long-term predictions. Another future work that may be thought is including other restrictions of web servers such as disk, memory, and network bandwidths usage.

Appendix 1 Architectural desription of element types of web server cluster in ACME language 1. import TargetEnvType . acme ; 2. Family WS-DSACFam extends EnvType with { 3. Property InitialRac: f loa t ; 4. Property Delta : f loa t ; 5. Property Gamalow : f loa t ; 6. Property Gamahigh : f loa t ; 7. Component Type ServerT extends ArchElementT with { 8. Property load : f loat > ; 9. Property role : string ; 10. rule anotherConst raint = heur ist ic sel f . load ; 14. Property SendReqTime : f loa t > ; 15. Property SendReqRate : f loa t > ; 16. rule pr imar yCons t raint = invar iant sel f . SendTime < sel f . RecieveTime; 17. } 18. Connector Type HttpConnT extends ArchConnT with { 19. Role req : RequestorRoleT = new RequestorRoleT extended with { } 20. Role rec : ReceiverRoleT = new ReceiverRoleT extended with { } 21. } 22. Port Type HttpReqPortT extends ArchPortT with { } 23. Port Type HttpPortT extends ArchPortT with { } 24. Role Type RequestorRoleT extends ArchRoleT with { } 25. Role Type ReceiverRoleT extends ArchRoleT with { } }

123

608


Appendix 2 High-level specification of an instantiation of a part of actual elements of web server cluster 1. System WS-DSACSys : WS-DSACFam { 2. Property InitialRac: f loa t = 100; 3. Property Delta : f loa t = 0.1 ; 4. Property Gamalow : f loa t = 0.8 ; 5. Property Gamahigh : f loa t = 0.9 ; 6. Component classSwitch : ServerT = new ServerT extended with { 7. Property role = 'classSwitch'; 8. Property load = 0.198; 9. Property Rac1= InitialRac1; 10. Property Rac2= InitialRac2; 11. Property Rmax = 0.75 * InitialRac1 ; 12. Property isArchEnabled = true ; 13. Port http0 : HttpPortT = new HttpPortT extended with { } 14. Port http1 : HttpPortT = new HttpPortT extended with { } 15. Port Rac1Port : HttpPortT = new HttpPortT extended with { } 16. Port Rac2Port : HttpPortT = new HttpPortT extended with { } 17. } 18. Component clusterGateway1 : ServerT = new ServerT extended with { 19. Property role = 'clusterGateway'; 20. Property clusterNumber = 1; 21. Property load = 0.198; 22. Property Rac; 23. Property sumThresholdIncrease = 0; 24. Property numIncrementThreshold =0; 25. Property isArchEnabled = true ; 26. Port http11 : HttpPortT = new HttpPortT extended with { } 27. Port http12 : HttpPortT = new HttpPortT extended with { } 28. Port load1 : HttpPortT = new HttpPortT extended with { } 29. Port load2 : HttpPortT = new HttpPortT extended with { } 30. Port RacPort : HttpPortT = new HttpPortT extended with { } 31. Port selectedServer : HttpPortT = new HttpPortT extended with { } 32. Port cluster : HttpPortT = new HttpPortT extended with { } 33. Port req1 : HttpReqPortT = new HttpReqPortT extended with { } 34. Port req2 : HttpReqPortT = new HttpReqPortT extended with { } } }

123


609

Appendix 3 Adaptation strategies in the Stitch high-level language 1. import lib " WS-DSAC Tact ics . s " ; 2. define boolean styleApplies = 3. Model . hasType (M, " Cl i entT " ) && Model . hasType (M, " ServerT " ) ; 4. define boolean saturate = 5. exists c : T . ServerT in M. components | c. role = = 'clusterGateway' && c. load > c. Rac *M.Gamahigh; 6. define boolean exclusive = 7. exists c : T . ServerT in M. components | c. role = = 'clusterGateway' && c. load > c.Rac * M. Gamalow && c. load < c. Rac * M. Gamahigh ; 8. define boolean shared = 9. exists c : T . ServerT in M. components | c. role = = 'clusterGateway' && c. load 10; 12. strategy AllocateHostToClusters 13. [ styleApplies && exclusive] { 14. t0 : ( exclusive ) → activateMaximumLoadAgent ( ) { 15. t0a : ( success ) → selectLeastLoadedServer ( ) { 16. t0a1 : ( ! exclusive) → done; 17. t0a2 : (default) → NULL; 18. } 19. t0b : ( defaul t ) → NULL ; 20. }} 21. strategy UpdateThreshold 22. [ styleApplies && saturate] { 23. t0 : ( saturate ) → changeThreshold ( ) { 24. t0a : ( !saturate ) → done; 25. t0b : ( defaul t ) → TNULL ; 26. }} 27. strategy ReInitializeThreshold 28. [ styleApplies && shared] { 29. t0 : ( shared ) → initializeThreshold ( ) { 30. t0a : (success) → done; 31. t0b : ( defaul t ) → TNULL ; 32. } 33. strategy ControlThresholdUpdates 34. [ styleApplies && ExeededUpdateThreshold] { 35. t0 : ( ExeededUpdateThreshold ) → checkUpdates ( ) { 36. t0a : (success) → done; 37. t0b : ( defaul t ) → TNULL ; 38. }}

123

610


References 1. Anaya IDP et al (2014) A prediction-driven adaptation approach for self-adaptive sensor networks. In: The 9th ACM international symposium on software engineering for adaptive and self-managing systems, pp 145–154 2. Babamir SM, Hassanzade E, Azimpour M (2015) Predicting potential deadlocks in multithreaded programs, concurrency & computation, practice & experience, Wiley, 27(17):5261–5287 3. Cámara J et al (2013) Evolving an adaptive industrial software system to use architecture-based self-adaptation. In: The 8th international symposium on software engineering for adaptive and selfmanaging systems 4. Cámara J et al (2014) Empirical resilience evaluation of an architecture-based self-adaptive software system. In: The 10th international ACM sigsoft conference on the quality of software architectures. ACM SIGSOFT QoSA Distinguished Paper Award, France, Lille 5. Cámara J et al (2014) Impact models for architecture-based self-adaptive systems. In: The 11th international symposium on formal aspects of component software (FACS2014), Bertinoro, Italy 6. Garlan D (2013) A 10-year perspective on software engineering self-adaptive systems (keynote). In: The 8th international symposium on software engineering for adaptive and self-managing systems. IEEE Press, pp 2–2 7. Garlan D, Schmerl B (2006) Architecture-driven modelling and analysis. In: The 11th Australian workshop on safety related programmable systems, 69:3–17 8. Sheikhi S, Babamir SM (2012) A novel model-based slicing approach for adaptive softwares. In: The 3rd international conference on contemporary issues in computer and information sciences, pp 195–199 9. Lember J, Koloydenko AA (2014) Bridging Viterbi and posterior decoding: a generalized risk approach to hidden path inference based on hidden markov models. J Mach Learn Res 15:1–58 10. Cheng SW, Garlan D, Schmerl B (2006) Architecture-based self-adaptation in the presence of multiple objectives. In: The international workshop on self-adaptation and self-managing systems, Shanghai, China, pp 2–8 11. Garalan D (2009) Rainbow: engineering support for self-healing systems: invited talk. In: The XXIII Brazilian symposium on software engineering 12. Poladian V et al (2007) Leveraging resource prediction for anticipatory dynamic configuration. In: The 1st international conference on self-adaptive and self-organizing Systems, pp 214–223 13. Cheng SW, Poladian VV, Garlan D, Schmerl B (2009) Improving architecture-based self-adaptation through resource prediction. In: Betty HC et al (eds) Software engineering for self-adaptive systems. Springer, Berlin, pp 71–88 14. Herbst NR, Huber N, Kounev S, Amrehn E (2013) Self-adaptive workload classification and forecasting for proactive resource provisioning. In: The ACM/SPEC international conference on performance engineering (ICPE), pp 187–198 15. Sharifiana S, Motamedia SA, Akbarib MK (2011) A predictive and probabilistic load-balancing algorithm for cluster-based web servers. Appl Soft Comput 11(1):970–981 16. Angelopoulos1 K, Souza VES, Pimentel J (2013) Requirements and architectural approaches to adaptive software systems: a comparative study. In: The 8th ICSE workshop on software engineering for adaptive and self-managing systems, pp 23–32 17. Tallabaci G, Souza VES (2013) Engineering adaptation with Zanshin: an experience report. In: The 8th international symposium on software engineering for adaptive and self-managing systems, IEEE Press, pp 93–102 18. Cheng SW, Garlan D (2012) Stitch: a language for architecture-based self-adaptation. J Syst and Softw, Special Issue on State of the Art in Self-Adaptive Systems. vol 85, no (12), Elsevier, pp 2860–2875 19. Jachan M (2012) Time-frequency-autoregressive-moving-average modeling, AV Akademikerverlag, publication 20. Franke J (2012) Markov switching time series models. In: Rao TS et al (eds) Chapter 5 of handbook of statistics, time series analysis: methods and applications. Elsevier, New York 21. Cappé O, Moulines E, Ryden T (2005) Inference in hidden markov models, Springer series in statistics 22. Rezaei V, Pezeshk H, Pérez-Sa’nchez H (2013) Generalized Baum–Welch algorithm based on the similarity between sequences. PLoS One 8(12):e80565. doi:10.1371/journal.pone.0080565 23. Jha GK, Sinha K (2014) Load balancing technique to improve QoS for lightpath establishment in optical WDM networks. J Theor Appl Inf Technol 68(2):255–264

123


611

24. Marques C, Ilarri S, Barroso GC (2009) DARC: A dynamic architecture for reconfiguration of web servers clusters using multiagent systems. In: The 5th international conference on networking and services, pp 169–174 25. Serra DGA, Barroso G, Ramos R, Boudy J (2005) Assuring QoS diferentiationand load balancing on web servers clusters. In: The international conference on control aplications, pp 885–890 26. Olejnik R, Bouchi A, Toursel B (2002) An object observation for a java adaptative distributed application platform. In: International conference on parallel computing in electrical engineering, pp 171–176 27. http://www.cs.cmu.edu/~./acme/AcmeStudio/index.html. Accessed 4 Feb 2009

123