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 SimgridInjector 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 sovle 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.
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 Simgrid Injector VM framework is to deliver a building block that will enable to compare fairly different VM placement algorithms.
VMPlaces is using SBT. You can find information regarding how configuring VMPlaces directly on the github page (see README.md). If you need additional information, please contact <[email protected]> if you are not familiar with SBT.
Once you have configured the different parameters of your simulation (config/simulator.properties), you can run the simulation by executing the simulation.Main class. As Simgrid requires several parameters to run, we encourage you to use either Eclipse or Intellij. Under one of these environments, create a new configuration for launching the simulation.Main class and add the following information: VM Options: -Xmx4G -d64 -Dlogback.configurationFile=config/logback.xml Program arguments: ./config/cluster_platform.xml ./config/generated_deploy.xml –cfg=cpu/optim:Full –cfg=tracing:1 –cfg=tracing/filename:simu.trace –cfg=tracing/platform:1 Logs (if exists): ./logs/console.log
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.
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 launchers 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. While VMPlaceS has been developped with the objective of facilitating the evaluations of different scheduling policies, we strongly encourage new users to startby evaluating your scheduling policy in a centralized manner (See CentralizedResolver launcher). A complete example, should be available on the website soon.
- Adrien Lebre - [email protected] - France - Project founder, principal maintainer
- Jonathan Pastor - [email protected] - France - Implementation of the distributed resolver (based on the DVMS proposal)
- Flavien Quesnel - [email protected] - France - Contributor (simulator properties, bug fixes, distributed resolver)
- José Simao - [email protected] - Portugal - First beta tester - few bug fixes
- Mario Sudhol - [email protected] - Implementation of the hierarchical resolver (based on the Snooze proposal)
- Adrian Fraisse - [email protected] - France - Implementation of the centralized resolver based on the BtrPlace algorithm
- Killian Saint Cricq - [email protected] - France - Implementation of the centralized resolver based on the BtrPlace algorithm