Pre-experiments Setup

The pre-experiments were conducted using the evaluation tool, testbed configuration and architecture configurations described below.

Figure 5.2: Evaluation Case: Stability Relational Model for the Quality of Service View- point

Figure 5.3: Evaluation Case: Stability Relational Model for the Environmental Viewpoint 5.4.2.1 Evaluation tool

As research in Cloud Computing is experimental in nature [36], it is almost practically not achievable to get highly scalable configurations and constant extensive workload to conduct repeatable and scalable experiments. Therefore, as most researchers do, we resort to simulation-based evaluations [36] [5], so that repeatable and scalable experimentation is manageable. However, the simulation results can be used to guide the application of

Figure 5.4: Evaluation Case: Stability Relational Model for the Quality of Adaptation Viewpoint

the selection approaches in of real-world scenarios.

To this end, we implemented the architecture of a self-adaptive cloud node, extend- ing the widely adopted CloudSim simulation platform for cloud environments [5]. Our evaluation tool implements a foundational adaptation controller of the IBM architectural blueprint for autonomic computing, that is the MAPE feedback loop [453] [25], imple- mented as monitor, detector, adaptation engine and adaptation executor components. The simulation was built using Java JDK 1.8 and was run on a 2.9 GHz Intel Core i5 16 GB RAM computer.

5.4.2.2 Testbed configuration

The cloud architecture is configured with maximum capacity of 1000 hosts (physical machines/ server). The configuration of each server is 2 x Xeon X5675 3067 MHz, 6 cores and 256 GB RAM. The frequency of the servers’ CPUs is mapped onto MIPS ratings: 3067 MIPS each core [454] and their energy consumption is calculated using power models of [454]. The maximum capacity of the architecture is 1000 hosts.

The characteristics of the virtual machines (VMs) types correspond to the latest gener- ation of General Purpose Amazon EC2 Instances [455]. In particular, we use the m4.large (2 core vCPU 2.4 GHz, 8 GB RAM), m4.xlarge (4 core vCPU 2.4 GHz, 16 GB RAM), and m4.2xlarge (8 core vCPU 2.4 GHz, 32 GB RAM) instances. The operational cost of different VMs types is 0.1, 0.2 and 0.4 $/hour respectively. Initially, the VMs are allocated according to the resource requirements of the VM types. However, VMs utilise fewer resources according to the workload data during runtime, creating opportunities for dynamic consolidation. The testbed configuration of the experiments is shown in Table 5.1.

5.4.2.3 Architecture Configuration

The Catalogue of Architectural Tactics. We defined the catalogue of architec- tural tactics to fulfil the quality attributes subject to stability. Table 5.2 lists the tactics

Table 5.1: Testbed Configuration

Configuration

Max. hosts 1000

Host type IBM x3550 server

Host Specs 2 x Xeon X5675 3067 MHz,

6 cores, 256 GB RAM

VMs type General Purpose Amazon EC2 Instances

VMs Specs m4.large: 2 core CPU 8 GB RAM,

m4.xlarge: 4 core CPU 16 GB RAM, m4.2xlarge: 8 core CPU 32 GB RAM

and their definitions. We have based this work on the description tactics by Bass et al. [4]. The tactics include: (i) horizontal scaling (increasing/decreasing the number of physical machines), (ii) vertical scaling (increasing/decreasing the number of virtual machines or their CPU capacities), (iii) virtual machines consolidation (running the virtual machines on less number of physical machines for energy savings), (iv) concurrency (by process- ing different streams of events on different threads or by creating additional threads to process different sets of activities), (v) dynamic priority scheduling (scheduling policy is implemented, where the scheduler handles requests according to a scheduling policy), and (vi) energy monitoring (providing detailed energy consumption information).

Adaptation Rules. Adaptation rules are defined as such tactics related with quality attributes. Adaptation rules are summarised in Table 5.3.

5.4.2.4 Pre-experiments Settings

We conducted the pre-experiments using the testbed configuration described above and the initial deployment of 10 running hosts. We run the pre-experiments for 300 time intervals, each interval is of 200 seconds, in order to get sufficient data for building the Bayesian network. In each time interval, we generate a random number of requests, and the length of each request randomly varies between 1,000 and 20,000 Million Instructions Per Second (MIPS).

To measure the stability ranges for different viewpoints, we configured the architec- ture to take adaptation actions to stabilise specific attributes within different ranges, by setting this attribute as the single adaptation goal. The adaptation controller selects an adaptation tactic from the tactics catalogue based on the adaptation rules, in order to achieve the quality requirement within the desired range. We, then, measured the impact of such stability actions on the stability of related attributes.

Table 5.2: Catalogue of Architectural Tactics

No. Tactic Description Object Limits Variations

1 Vertical

scaling

increasing the number of virtual machines (VMs) or their CPU capacities

VMs maximum CPU capacity of hosts running in the datacenter +1, 2, 3,... VMs or increase the CPU capacity of running VMs

2 Vertical

de-scaling

decreasing the number of virtual machines (VMs) or their CPU capacities

VMs minimum one

running VM

+1, 2, 3,... VMs

3 Horizontal

scaling

increasing the number of running hosts Hosts maximum number of hosts in the datacenter +1, 2, 3,... hosts 4 Horizontal de-scaling

decreasing the number of running hosts

Hosts minimum one

running host

-1, 2, 3,... hosts

5 VMs consol-

idation

shut down hosts running least number of VMs and migrate their VMs to other hosts Hosts, VMs minimum one running host and one VM -1, 2, 3,... hosts

6 Concurrency processing different streams of events on different threads or by creating additional threads to process different sets of activities

datacenter scheduler maximum CPU capacity of hosts running in the datacenter single, multiple threads 7 Dynamic scheduling scheduling policy is implemented, where the scheduler handles requests according to a scheduling policy datacenter scheduler maximum number of running hosts and VMs

earliest deadline first scheduling, least slack time scheduling, single queueing, multiple queueing, multiple dynamic queueing

Table 5.3: Adaptation Rules

Tactic Related Quality Attributes Priority

Dynamic scheduling response time 1

Concurrency response time 2

Vertical scaling response time 3

Horizontal scaling response time 4

VMs consolidation operational cost, energy consumption 1 Vertical de-scaling operational cost, energy consumption 2 Horizontal de-scaling operational cost, energy consumption 3