Overview

While the MELA-DataService provides monitoring snapshots containing multi-level monitoring data organized after the service structure,such snapshots do not provide information about the elasticity behavior of the service in terms of user-defined elasticity requirements fulfillment.

Thus, we introduce the MELA Space and Pathway Analysis Service, which analyzes the elasticity of cloud services, and determines their elasticity space, elasticity boundaries, and elasticity pathway. The elasticity space, boundaries, and pathway are determined for each service unit, complex units, and the whole service, providing a multi-level view over the service's elasticity. This view is used for analyzing the behavior of the service, whether or not it behaves within expected boundaries, in order to know what decisions to take, and in which part of the service these decisions should be enforced.

Elasticity Boundary

An elasticity boundary is an upper and lower limit over the service's metric's values in which user-defined elasticity requirements are fulfilled. Boundaries describe the upper and lower allowed values over a set of metrics for a unit or the whole cloud service, and are used in determining what behavioral limits are to be enforced for the service by elasticity controllers such as rSYBL

Conceptually, an elasticity boundary is defined as: elBoundary=〈c_i^u,c_i^l 〉,〈q_j^u,q_j^l 〉,〈r_k^u,r_k^l 〉, where c_i^u and c_i^l denote the upper bound and the lower bound of cost metric c_i , respectively, q_j^u and q_j^l for quality metric q_j, and r_k^u and r_k^l for resource metric r_k.

We discriminate between two types of elasticity boundaries: (i) user-defined elasticity boundary and (ii) evaluated elasticity boundary In a user-defined elasticity boundary, the boundary metrics and bounds are specified by user-defined elasticity requirements, indicating the parameters under which the cloud service is elastic. An evaluated elasticity boundary is determined from monitoring snapshots, using the user-defined boundary.

Thus, such a boundary indicates encountered bounds on the monitored metrics not targeted by user requirements, in which the user requirements were respected. Elasticity controllers such as rSYBL could use the determined elasticity boundaries to refine its control elasticity mechanism, by adding beside user-defined requirements the determined boundaries. Thus, even if the user has limited knowledge, we determine boundaries over the rest of the service.

Elasticity Space

Given a set of monitoring snapshots and a user-defined elasticity boundary, we need to understand when a monitored element is in elastic behavior, if its behavior violates the elasticity boundaries, i.e. it fulfills user-defined requirements.

In the current prototype, the elasticity space boundaries are determined for all service units, complex units, and whole service, and are equal to the maximum and minimum encountered metric values when the elasticity requirements were respected. Thus, starting from supplied user requirements, MELA Space and Pathway Analysis Service determines and continuously updates requirements for the rest of the service units

Elasticity Pathway

While the elasticity space enables elasticity analysis, it does not provide insight into relationships between metrics influencing the elastic behavior over time. In order to characterize the elastic behavior of cloud service from specific views/perspectives, we define the concept elasticity pathway

An elasticity pathway function must describe the evolution of an elastic cloud service over time. Such a function is necessary for evaluating the historic behavior of a cloud service, given a certain control strategy, with respect to user-defined requirements, as to understand if the control strategy was effective or not. Moreover, such a function gives a foundation for predicting the behavior of the cloud service, serving as a base for refining control strategies.

More concretely, an elasticity pathway could indicate that the response time of an service and its CPU usage are high in x% of the encountered situations, indicating there might be a correlation between them.