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.

Some usefull resources:

• CloudSim FAQ
• CloudSim API
• CloudSim source code
• CloudSim mailing-list

Setting up the environment

You must have a working Java 7 + maven environment to develop and Git to manage the sources. No IDE is necessary but feel free to use it.

1. 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

2. check everything is working by typing mvn install in the root directory
3. Integrate the project with your IDE if needed

How to test

fr.unice.vicc.Main is the entry point. It can be launch from your 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 in planetlab). When all 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

Exercices

For this project, you will have to develop various VM schedulers and a few observers that check if your schedulers behave correctly.

To integrate your schedulers within the codebase, you will have to declare your schedulers inside the class VmAllocationPolicyFactory.

A naive scheduler to start

This first scheduler aims only at discovering the CloudSim API. This scheduler simply places each Vm to the first Host with enough free capacity.

1. Just create the new class handling the scheduling, integrate it into VmAllocationPolicyFactory. The flag to call this scheduler for the command line interface (CLI) will be "naive". Test if the integration is correct. The code shall crash in your class but that is expected at this stage.

2. Implements the easy part first, that is to indicate where a Vm runs. This is done by the getHost(Vm) and the getHost(int, int) methods

3. Implements allocateHostForVm, the method to force a given Vm to be hosted on a given Host. For doing so, look at the method Host.vmCreate(Vm).

4. Implements deallocateHostForVm, the method that remove a running Vm from its hosting node.

5. The scheduler is static. optimizeAllocation must returns null

6. Now, implement allocateHostForVm(Vm) that is the main method of this class. As we said, the scheduler is very simple, it just schedule the Vm on the first appropriate Host.

7. Test your simulator on a single day. If the simulation terminates successfully, all the VMs have been scheduled, all the cloudlets ran, and the provider revenues is displayed.

8. Test the simulator runs succesfully 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

Support for Highly-Available applications

Let consider the VMs run replicated applications. To make them fault-tolerant to hardware failure, the customer expects to have the replicas running on distinct hosts.

1. Implement a new scheduler (flag antiAffinity) that place 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], ... .

2. To check the scheduler is effective, implements an observer. A sample one is PeakPowerObserver. Basically, your observer must be called every simulated second to confirm Vms of a same group are hosted on distinct nodes. If this constraint is violated, then the observer must reports the co-located Vms. If needed, modify your scheduler or use the naive one to exhibit the correctness of the observer.

Balance the load

Balancing the load is usefull to avoid to alter specific hosts prematurely. It is also convenient to minimize the probabilities of saturating a host.

1. Develop a scheduler that perform load balancing (balance load)
2. Develop an observer to evaluate every second the balancing rate. The balancing ratio must be logged for observations.

Get rid of SLA violations

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. It is then not desirable to have violations to attract customers and maximize the revenues.

Implement a scheduler that ensures there can be no SLA violation (noViolations flag). In practice, the scheduler must chose for each Vm, a host with enough free processing unit to support the peak demand in terms of MIPS.

Your scheduler is effective when you can succesfully simulates all the days, with the Revenue class reporting no refundings due to SLA violation.

Energy-efficient schedulers

static version

Develop a scheduler (statEnergy flag) that reduces the overall energy consumption without relying on Vm migration. The resulting simulation must consumes less energy than all the previous schedulers.

dynamic version (bonus)

Copy the previous scheduler and modify it to rely on Vm migration to continuously improve the Vm placement (dynEnergy flag). The resulting simulation must consumes less energy than the static version.

To indicate which Vm to migrate to which host, implement the method optimizeAllocation. The returned list is the sequence of migration to perform. Each list entry is a map that only contains the Vm to migrate (key vm) and the destination host (key host). For example:

public List<Map<String,Object>> optimizeAllocation(List<Vm> vms) {
	List <Map<String,Object> map = new ArrayList<>();
	Map<String,Object> m1 = new HashMap<>();
	m1.put("vm", vms.get(0));
	m1.put("host", getHostList().get(0));
	map.add(m1);
	Map<String,Object> m2 = ...
	...
	return map;
}

Greedy scheduler

Develop a scheduler that maximizes revenues. It is then important to provide a good tradeoff between energy savings and penalties for SLA violation.