MELA Architecture

Note: From here onwards we will refer to services and cloud services with the same "services" term.

In general, elastic cloud services can re-configure individual units or the whole service at run-time, due to various elasticity requirements. Such run-time re-configuration can either focus on: (i) vertical scaling, adding/removing resources to existing units; or (ii) horizontal scaling, duplicating units/instantiating more instances of the same type. As virtual machines themselves are created/destroyed dynamically at run-time, if monitoring information is associated only with each virtual machine, it will be lost during scale-in operations which destroy virtual machines. Solving the first issue, MELA provides a service for logically structuring and aggregating monitoring information according to the structure of the monitored service. Secondly, MELA provides a series of services which analyze different elements of elastic services, from service behavior with respect to service requirements, to cost evaluation.

Depending on individual needs, a MELA user can choose what services to deploy and run, depending on individual requirements, thus, offering maximum usage flexibility.

MELA Data Service

MELA contains a core service called MELA Data Service, and additional extensions: MELA Elasticity Pathway and Space Analysis Service, and MELA Composable Cost Evaluation Service. The MELA Data Service gathers and structures data from existing monitoring solutions (e.g., Ganglia or JCatascopia), data associated with a dependency model level or monitored element (e.g., responseTime for a particular service unit), which is then processed by the extension services. As monitoring data is usually associated with a single level, e.g., virtual infrastructure, service topology or service unit, an important MELA feature is the linking of these levels, which implies a configuration by supplying the (i) service structure, (ii) metric composition rules, and (iii) service elasticity requirements. As output, MELA Data Service provides a multi-level monitoring snapshot in which monitoring information is represented at the service topology and unit levels, not only at the VM level.

MELA Elasticity Pathway and Space Analysis Service

In order to analyze the elastic behavior of cloud services, MELA Elasticity Pathway and Space Analysis Service uses the concept of elasticity boundary. An elasticity boundary describes the upper and lower allowed values over a set of metrics for a cloud service. Another MELA core concept is elasticity space. An elasticity space is determined via an elasticity space function and captures all runtime metrics described in the user-defined elasticity boundary when a monitored element is in elastic behavior. Based on the elasticity space, MELA provides a mechanism for extracting characteristics of the elasticity space that can be used to predict its behavior, characteristics called “elasticity pathway”. An elasticity pathway function is designed to perform a complex evaluation of the cloud service behavior, extracting characteristics that can be used to predict its behavior.

Moreover, as a result of elasticity analysis, MELA Elasticity Pathway and Space Analysis Service provides in real-time the elasticity space of the service with determined elasticity boundaries, and the elasticity pathway.

MELA Composable Cost Evaluation Service

What is important from a cost perspective is that usually, different combinations of services have different pricing schemes, and different elastic services could use at run-time different services with specific configurations, influencing the service cost. Involving different pricing schemes for different combinations of services, cost complexity also depends on the complexity of a cloud service’s deployment structure. Moreover, depending on the level of knowledge and particular interests of the user, some users might be interested in very complex and complete cost evaluation, while others.html might be content with an estimation over cost, even if not completely accurate.

To this end, MELA Composable Cost Evaluation Service can capture from simple cost functions, such as fixed cost per used cloud service, to cost per service if used in conjunction with other services, with respect to the service usage so far (usage intervals). Using this cost composition model, the MELA Composable Cost Evaluation service computes in detail the cost for the whole application or individual components, using information about the cloud services used by the application, and structured monitoring information provided by the MELA Data Service.

MELA service service specific configuration

MELA Data Service must be configured for each individual service it monitors and analyzes. A RESTful APi is provided, and thus all MELA configurations can be done through service calls.

Service Structure Specification

For describing elastic services from the whole service level to the underlying virtual infrastructure, we developed a representation model (Figure 2) that enables the decomposition of user-defined elasticity requirements in lower level requirements which can be mapped to the virtual infrastructure. To support analysis of service behavior at different levels, we represent a cloud service composed of service topologies, each topology containing several service units, which are deployed on one virtual machines belonging to virtual clusters. The model can represent cloud services composed of other services (service topologies) deployed in federated cloud environments or in different availability zones (virtual clusters).

Based on the dependency model, MELA Data Service builds composite monitoring snapshots which aggregate monitoring metrics bottom-up, creating based on lower level metrics higher level ones which can be targeted by user-defined elasticity requirements. At different levels we allow the association of different elasticity space and pathway functions, enabling multi-level custom analysis of cloud service behavior. Using the dependency model we combine monitoring snapshots, elasticity spaces and pathways from one level and propagate them to the other levels, obtaining a complete view over the cloud service behavior.