Vicc project: homemade VM Schedulers
This project aims at developing different VM schedulers for a given IaaS cloud. Each scheduler will have meaningful properties for either the cloud customers or the cloud provider.
The implementation and the evaluation will be made over the IaaS cloud simulator CloudSim. The simulator will replay a workload extracted from Emulab, on a datacenter having realistic characteristics (when it was created).
The simulated datacentre is made of:
- 400 HP Proliant Ml111G4 nodes. 2 CPUs (aka. PES) @ 1860 Mips, 4 GB RAM
- 400 HP Proliant Ml111G5 nodes. 2 CPUs (aka. PES) @ 2660 Mips, 4 GB RAM
The workload consists of 10 random days of Planetlab.
- 1052 VMs
- 4 VM templates:
- 1x 500 MIPS, 613 MB RAM
- 1x 2500 MIPS, 870 MB RAM
- The Mips requirements for the VMs change over the time
- All the VMs are launched at the same moment
Some usefull resources:
Setting up the environment
You must have a working Java 7 + maven environment to develop and Git to manage the sources. No IDE is required but feel free to use it.
- clone this repository. The project directory is organized as follow:
$ tree |- src # the source code |- repository # external dependencies |- planetlab # the workload to process |-cloudsim-3.0.3-src.tar.gz # simulator sources \- pom.xml # maven project descriptor
- check everything is working by typing
mvn installin the root directory
- Integrate the project with your IDE if needed
How to test
fr.unice.vicc.Main is the entry point. It can be launch from an IDE or using the command
mvn compile exec:java.
Usage: Main scheduler [day]
scheduleris the identifier of the scheduler to test, prefixed by
dayis optional, it is one of the workload day (see folders in
allis indicated all the days are replayed sequentially.
By default, the output is written in a log file in the
If you execute the program through
mvn exec:java, then the arguments are provided using the 'sched' and the 'day' properties.
- To execute the simulator using the
naivescheduler and all the days:
mvn compile exec:java -Dsched=naive -Dday=all
- to replay only day
mvn compile exec:java -Dsched=naive -Dday=20110303
For this project, you have to develop various VM schedulers.
To integrate your schedulers within the codebase, you will have to declare your schedulers inside the class
A first fit scheduler to warm up
This scheduler aims only at discovering the CloudSim API. This scheduler simply places each
Vm to the first
Host having enough free resources (CPU and memory). The skeleton is in the class
NaiveVmAllocationPolicy.java. It is used from the CLI using the
allocateHostForVm are the core of the Vm scheduler. They are called by the simulator each time a Vm is submitted.
allocateHostForVm(Vm, Host)is straighforward as the host is forced. To allocate the Vm on a host look at the method
Host.vmCreate(Vm). It allocates and returns true iff the host has sufficient free resources. The method
VmAllocationPolicyreturns the datacenter nodes. Use the
hosterattribute to map the host associated to each Vm.
allocateHostForVm(Vm), the main method of this class. A simple first fit algorithm does the job.
- Test your simulator on a single day. If the simulation terminates successfully, all the VMs have been scheduled and the provider revenues is displayed.
- Test the simulator on all the days. For future comparisons, save the daily revenues and the global one. At this stage, it is ok to have penalties due to SLA violations
Below are different request for features that require to develop alternative schedulers. All the scheduler are independent. They are not sorted by difficulty. Implement those you are interested in.
Fault-tolerance for replicated applications
Let consider the VMs run replicated applications. To make them fault-tolerant to node failure, the customer expects to have the replicas running on distinct hosts.
Implement a new scheduler (
antiAffinity flag) that places the Vms with regards to their affinity. In practice, all Vms with an id between [0-99] must be on distinct nodes, the same with Vms having an id between [100-199], [200-299], ... .
Develop an algorithm based on a worst fit heuristic (
worstFit flag) that balances with regards to both RAM and mips. There is different solutions to consider the two dimensions. Be pragmatic, test alternative implementations and try to observe the consequences in terms of SLA violations.
Implement a scheduler that ensures there can be no SLA violation. Remember the nature of the hypervisor in terms of CPU allocation and the VM templates. The scheduler is effective when you can successfully simulate all the days, with the
Revenue class reporting no re-fundings due to SLA violation.
For a practical understanding of what a SLA violation is in this project, look at the
Revenue class. Basically, there is a SLA violation when the associated Vm is requiring more MIPS it is possible to get on its host. If the SLA is not met then the provider must pay penalties to the client.
Develop a scheduler that reduces the overall energy consumption without relying on VM migration. The resulting simulation must consumes less energy than all the previous schedulers.
Develop a scheduler that maximizes revenues. It is then important to provide a good trade-off between energy savings and penalties for SLA violation. Justify your choices and the theoretical complexity of the algorithm