Configuring MELA
Specifying and submitting service structure
MELA imposes a logical structure over monitoring data collected from existing monitoring tools. Towards this, the service structure needs to be submitted to MELA. In the case the service structure changes in time due to elasticity actions (i.e., scale in/out), the updated structure needs to be resubmitted to MELA using a "POST" to the "servicestructure" RESTful service. Usually, the resubmission of the updated structure should be done automatically by the elasticity controller which changes the service's structure by enforcing actions.
For instructions on how to write the service structure please read our guide here , and watch the demo below (if possible, in HD quality).
The example XML file can be downloaded from here and the used XSD schema can be found here.
Specifying and submitting service structure
For choosing which metrics should be collected by MELA from existing monitoring tools, to which element from the service structure the metrics should be associated, and enrich monitoring information, metric composition rules need to be defined.
For instructions on how to write the metrics composition rules please read our guide here , and watch the demo below (if possible, in HD quality).
The example XML file can be downloaded from here and the used XSD schema can be found here.
Complete overview demo
The demo below is a complete demo showcasing MELA's features. It includes audio comments of each step needed to configure MELA for a specific service, assuming MELA is deployed and running. Moreover, it contains explanations of all MELA features, detailing what each feature means and why it is usefull.
MELA and rSYBL run-time elasticity controller
The demo below shows MELA used in conjunction with rSYBL, a run-time for controlling elasticity of cloud services. While focused on rSYBL, it showcases how MELA can be used to support mechanisms for controlling elastic cloud services. If possible, please watch the demo in HD quality.
The XML schema for writing service structure specifications can be downloaded from here
Analyzing multi-cloud elastic services
In the following we show a brief example of using MELA to analyze elastic services deployed on multiple-clouds.
Scenario description
The example is centered around the Daas elastic service prototype we have implemented as to validate our tools. The current prototype is available on GitHub here. Detailed videos explaining how to configure and deploy our prototype are available on the DaaSM2M project wiki.
For the example, we use two cloud providers. The first is the private cloud of the Distributed Systems Group (DSG) from Vienna University of Technology, running on top of OpenStack. The second cloud is a public cloud offered by a commercial cloud provider: Flexiant Cloud Orchestrator.
The pilot elastic cloud service runs a distributed NOSQL data end on top of Cassandra. We configure Cassandra in a master-slave fashion, in which we have a fixed Cassandra Seed, and a variable number of Cassandra Node instances. Thus, the elasticity of the data end is given by the ability of adding and removing at run-time nodes for holding data. The data end is deployed on the DSG cloud.
The second tier of the elastic cloud service handles client requests and read/writes from/to the data end. The request are received by a Load Balancer running HAProxy, which distributes them to instances of an Event Processing Service, which in turn processes the request and writes/reads data from the data end. Thus, the elasticity of this tier is achieved by adding/removing Event Processing Service instances at run-time. This tier is deployed on the Flexiant cloud.
An overview over our elastic cloud service deployed in a multi-cloud environment is shown in the figure below.
Configuring MELA for multi-cloud analysis
MELA has two components: a MELA-DataService which collects monitoring information from existing cloud monitoring solutions, and a MELA-AnalysisService which used data from the data service to analyze elastic cloud services.
In this example we deploy a distributed monitoring solution Ganglia on the virtual machines running our elastic cloud services in both clouds. We configure Ganglia separately on each cloud, depending on the clouds' particularities. Most importantly, the two Ganglia installations on the two clouds are independent, and do not communicate one with each other.
For configuring MELA to collect data from multiple clouds, we just need to define in the MELA-DataService configuration folder, in the dataSources.xml, the "data sources" from which MELA should collect data. In this case, we define two data sources, as in the example below (by adding valid IPs and ports):
<mela:ganglia-datasource id="ganglia-dsg" host="DSG_PUBLIC_IP" port="DSG_PUBLIC_PORT" polling-interval-ms="5000"/>
<mela:ganglia-datasource id="ganglia-flexiant" host="FLEXIANT_PUBLIC_IP" port="FLEXIANT_PUBLIC_PORT" polling-interval-ms="5000"/>
An overview over the monitoring data flow and how MELA interacts with this multi-cloud setup is provided in the figure below.
