MINISTERIO DE EDUCACIÓN

offs in DDDAS Architecture

The cloud federation architecture induced by DDDAS is shown in figure 6.4. The DDDAS adaptive layer in the architecture realises the adaptation mechanism use to coordinate and control CSPs. It is composed of distributed simulator instances. These simulators receive requests from cloud users and select cloud providers capable of meeting these requests. The simulators receive control feedbacks from cloud providers signifying successful execu- tion of submitted job requests or risk alerts signifying their inability to do so. Risk alerts could be triggered by reasons such as unanticipated resource failure and unforeseen spike in workload. The simulators act on this feedback by taking risk mitigation actions such

as selection of substitute cloud provider(s) to avoid violating the SLA terms of submitted requests. Feedbacks received by the simulator can also be discriminated as: high priority (requires immediate intervention), medium priority (react within a time bound) or low priority (trivial, non-threatening risk). The knowledge acquired from the continuous inter- action between simulators and CSPs improves the accuracy of the simulators at selecting reliable CSPs. Next, we zoom into the details of adaptive layer of the architecture.

Market-based Simulator Instance, MS1

CSP Reputation Repository

. .

.

CLOUD USERS DDDAS ADAPTIVE LAYER

CSP1 . . . (Job1 , SLA1) (Job2 , SLA2) (Job3 , SLA3) (JobM , SLAM) (Jobi , SLAi) CLOUD SERVICE PROVIDERS Trading Strategy Repository CSP2 CSP3 CSPN update rating fetch rating

selects cloud provider

feedback select strategy Market-based Simulator Instance, MS2

Market-based Simulator Instance, MSK

UM

U1

U2

U3

Submits job and its SLA

to execute

Key

User i Cloud Service Provider i Repository Ui

CSPi

Figure 6.4: Cloud Architecture Induced by DDDAS Architecture Style. Source: [70]

6.4.1

Onling Shopping Application Induced by DDDAS Archi-

tecture

The adaptive layer consists of many simulator instances which coordinate the cloud fed- eration. The distributed simulation approach is preferred due to the scale of the cloud federation. A single simulator instance may constitute a bottleneck under heavy work- load and thus make the adaptation subsystem less scalable. Distribution of simulator instances improves the scalability of the adaptation subsystem and affords dedication of simulators to multiple concerns. For example, some simulators may be more efficient at selecting CSP for specific types of incoming job requests than others. In accordance

with the DDDAS paradigm, these simulators collect data based on current state of the cloud, perform measurements to detect probable violations, and effect control changes to mitigate them.

More precisely, the simulators performs the following functions:

• receive job requests and associated SLAs as input from cloud users, • inspect offerings of cloud service providers at specified intervals,

• select CPS(s) to execute job requests based on job type and SLA terms, • monitor job execution to detect risk alerts from cloud providers, and

• effect actions to prevent the violation of users’ SLAs whenever a risk alert is received. Simulator instances select CSPs by utilising our reputation-aware posted offer market mechanism. The steps of the reputation-aware posted offer mechanism for each trading round is described as follows:

Step 1: sellers (CSPs) publish the prices and service terms of their resource offerings Step 2: buyers search for active sellers in the reputation repository

Step 3: if buyer finds a matching seller, allocate job to it, then step 4, otherwise step 2 Step 4: buyer (simulator instance) monitors the selected seller (CSP) at intervals Step 5: if seller successfully executes job then sends success notification else raise alert Step 6: if buyer detects risk alert or seller (CSP) is not responsive then reputation repos- itory is updated with a negative rating for the CSP and transfers control to step 2 else step 7

Step 7: if CSP violates SLA constraint, reputation repository is updated with a negative rating for the CSP otherwise it is updated with positive rating

6.4.2

Analysis of Architectural Decisions

Risk

1. SLA constraints are the drivers for deciding which trading strategy is used to meet a job request, however, the impact of mixing strategies is not explicitly stated. While the mechanism is able to accommodate diverse trading strategies, the overall impact on the architecture’s adaptive behaviour is not explicitly stated.

Sensitivity Points

1. The computational overhead of the adaptive layer is sensitive to the number of market simulators active per unit time.

2. As with the 3-layered architecture, the repositories constitute single points of failure. The impact of failure of the trading strategy repository is likely to be catastrophic because it encodes the logic of how CSPs are selected.

3. The accuracy of allocation decisions made by the simulators is sensitive to their training time. That is the time spent initialising the system to look ahead, acquiring knowledge about cloud services, before actually making selection decisions.

4. The integrity of data written or read from the repositories are sensitive to the transactional consistency of the read/write operation. If improperly handled this may lead to corruption of reputation records, and consequently incorrect adaptation.

Trade-off Points

1. Adaptability versus Cost

In order to make correct adaptation actions, simulators should continue running in order to maintain the current state of the real-world. However, this consumes computational resources, which is costly, especially in the variant of the architecture where simulators are dedicated to various job types.

2. Adaptability versus Performance

During peak workload scenario (S2), the computational overhead incurred by the simulators is likely to negatively impact the performance constraints specified for service instantiation, hence, leading to violation of the SLAs.