Beyond the Clouds

VMPlaceS

A dedicated framework to evaluate and compare VM placement algorithms

Getting Started

Learning how to implement an scheduling algorithm with VMPlaceS, and how include it in a simulation.

View details »

Run VMPlaceS in Docker

Learning how to a simulation inside a docker container (works on Linux, MacOS, Windows).

View details »

Javadoc

Javadoc of the VMPlaceS project.

View details »

Overview

A dedicated framework to evaluate and compare VM placement algorithms. At coarse-grained, the framework is composed of two major components: the injector and the VM placement algorithm. The injector is the generic part of the framework (i.e. the one you can directly use) while the VM placement algorithm is the part you want to study (or compare with available algorithms). Currently, the VMPlaceS is released with three algorithms:

  • Entropy [VEE09], a centralized approach using a constraint programming approach to solve the placement/reconfiguration VM problem

  • Snooze [CCGRID12], a hierarchical approach where each manager of a group invokes Entropy to solve the placement/reconfiguration VM problem. Note that in the CCGRID'12 paper, Snooze is using a specific heuristic to solve the placement/reconfiguration VM problem. As the sake of simplicity, we have simply reused the entropy scheduling code.

  • DVMS [SCALE12], a distributed approach that dynamically partitions the system and invokes Entropy on each partition.

VMPlaceS has been presented at the Europar 2015 conference, the preprint version of the article is available here! A longer version of the article is currently under review.

Description of the Injector

The injector executes different kind of events:

  • Load events: every t seconds, the injector selects one VM and changes its CPU load according to a Gaussian distribution. t is a random variable that follows an exponential distribution with rate parameter lambda declared in the simulator.properties file. The Gaussian distribution is defined by a mean as (i.e mu) well as a standard deviation (i.e. sigma) that are given at the beginning of each simulation. The parameters of the simulation are defined in the ''simulator.properties'' file available in the ''config'' directory. By default, the duration of each experiment is set to 3600 seconds. The parameters are lambda=Nb_VMs/300 and mu=70, sigma=30. Concretely, the load of each VM starts from 0% and varies on average every 5 minutes in steps of 10 (with a significant part between 40% and 100% of CPU usage). For more information, please give a look at the injector packages and the corresponding Injector (mainly the generateLoadQueue method), the InjectorEvent interface and the LoadEvent class

  • Fault events: Similarly to the load events, the injector turn off/on physical hosts following an exponential distribution with a rate parameter lambda declared in the simulator.properties file. This enables to simulate node crashes.

To modify the injector parameters, please edit config/simulator.properties

At the beginning, the simulation create n VMs, each of which is based on one of predefined VM classes. A VM class is a template of the specification of a VM and its workload. It is described as nb_cpu:ramsize:net_bw:mig_speed:mem_speed. VMs are launched on PMs in a round-robin manner, i.e., each PM has almost the same number of VMs. According to the investigated algorithm, VMs are relocated through the different PMs during the whole execution of the simulation.

The ultimate objective of the VMPlaceS framework is to deliver a building block that will enable to compare fairly different VM placement algorithms.

Installing and Running the simulator

Please follow the steps described in the Getting Started section.

Topology of the simulated infrastructure

Please note that the Simulator injector is currently released with a default platform xml file (see config/cluster_platform.xml) allowing to run a simulation up to 5K hosts in a one-site cluster scenario. That means that nodes are homogeneous. They have the same capabilities in terms of nb of cores, cpu/ram capacitity and network bandwidth. You can if you want change the network topology as well as the network capability of each node by modifying the platform file or by using your own one (for more information, please refer to the SimGrid documentation, section Platform description) WARNING: please keep in mind that due to the fact the capability in terms of cores number/cpu/ramsize is defined in the simulator.properties files, nodes will stay homogeneous.

The injector runs on node((nb_node)+1) and the node0 is reserved to run specific services. For instance, if you have configured the simulation in order to simulate the centralized approach with 10 nodes. Node 0 will run the event injector, Node[1-10] will host the VMs and the scheduler will be launched on node 11. This is important as the crash injector only consider nodes between 0 (inclusive) and nb_nodes. In other words, the injector node can never crash.

Implement/evaluate a new algorithm

We chose to implement centralized, hierarchical and distributed scheduling approaches in order to illustrate the different possibilites to implement scheduling policies. Hence, according to the scheduling you want to evaluate and the software architecture you want to rely on, you can simply give a look to the corresponding launcher available in the simulation package (CentralizedResolver, HierarchichalResolver and DistributedResolver). The work consists in forking such a launcher in order to replace the scheduling strategy invoked by the proposal you want to investigate. We highlight, however, that while VMPlaceS has been developped with the objective of facilitating the evaluations of different scheduling policies, we strongly encourage new users to start by evaluating their scheduling policy in a centralized manner (See CentralizedResolver launcher). A complete example, should be available on the website soon.

Active Contributors

Past Contributors