Main Page/Resources/E-motions/Cloud

From Atenea

Jump to: navigation, search

Contents

Introduction

This example presents a domain-specific visual language (DSVL) to model cloud system infrastructures. These systems allow auto-reconfiguration in terms of scalability. They are able to duplicate one or more services in order to satisfy a required throughput.

System Modeling

Structure

The metamodel of our DSVL is shown below. A System is composed by a set of Elements, which can be either Links or Nodes. The latter represent the Services of the cloud systems, and also those entities that start the data flow (Source) and those where the data eventually arrives or is consumed (Sink). Services count the number of jobs they serve, and they have information about their service time and the cost of the service (which is also the cost of duplicating it). As for Links, they can be of three types, Fork, Single and Join. Fork links are used to split a job into many, Single links transmit jobs between two Nodes, and Join links are used to join several jobs of the same type into one.

Image:CloudMM.png

The metamodel for the observers, which aim at monitoring non-functional properties of these systems, is shown below. The individual observers in this system are aimed at monitoring both the percentage of the time that the monitored service is busy and the evolution in the cost of a service, considering it can be replicated. The general observers measure the throughput of the system and control the logic that deals with the replication of services in each iteration.

Image:ObsCloudMM.png

An initial model for our system is shown below. It shows the concrete syntax chosen for the models. This case study models a geolocation, photographic service, where the input of the system (the source src) provides a constant stream of geolocalized pictures. These pictures are then sent in parallel to services s1, which provides the map of their location, and s2, which escalates the pictures to an appropriate size and resolution. The resized pictures are then processed by service s3 which applies some image filters. The results coming from s1 and s2 are finally combined and ready to be stored or delivered by the sink (snk) of the system.

Image:InitModelCloud.png

Behavior

The semantics for the models is defined by means of 12 behavioral rules. 7 of them model how packets flow among the nodes and links, while the other 5 deal with the observers update and system adaptation.

Rules to model packets flow among nodes and links

Image:Service-Join.png


Image:Join-Node.png


Image:Source-Fork.png


Image:Service-Fork.png


Image:Fork-Services.png


Image:Source-Single-Node.png


Image:Service-Single-Node.png


Rules that deal with the observers update and system adaptation

Image:UpdateIndObs.png


Image:UpdateGeneralObs.png


Image:ReconfigureSystem.png


Image:ResetSystem.png


Image:ReLaunch.png

Personal tools