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
- CloudSim FAQ
- CloudSim API
- CloudSim source code
- CloudSim mailing-list
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 install
in the root directory - Integrate the project with your IDE if needed
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]
scheduler
is the identifier of the scheduler to test, prefixed by--
.day
is optional, it is one of the workload day (see folders inplanetlab
). Whenall
is indicated all the days are replayed sequentially.
By default, the output is written in a log file in the logs
folder.
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
naive
scheduler and all the days:mvn compile exec:java -Dsched=naive -Dday=all
- to replay only day
20110303
: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 VmAllocationPolicyFactory
.
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 naive
flag.
The 2 allocateHostForVm
are the core of the Vm scheduler. They are called by the simulator each time a Vm is submitted.
- Implementing
allocateHostForVm(Vm, Host)
is straighforward as the host is forced. To allocate the Vm on a host look at the methodHost.vmCreate(Vm)
. It allocates and returns true iff the host has sufficient free resources. The methodgetHostList()
fromVmAllocationPolicy
returns the datacenter nodes. Use thehoster
attribute to map the host associated to each Vm. - Implement
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.
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