Getting Started

fhermeni edited this page Oct 28, 2014 · 95 revisions

Getting started

[Associated source code] (

Btrplace is a flexible scheduler to place Virtual Machines (VMs) on servers in a hosting platforms. Basically, it manages VMs with respect to constraints that are stated by the users. As a user of the algorithm, you only have to declare the constraints you want to have satisfied. This tutorial presents the fundaments of BtrPlace.

BtrPlace is articulated around 4 primitives:

  • The model depicts the current state of a virtualized hosting platform. It is usually generated from monitoring data

  • A reconfiguration plan. A plan consists of a scheduled set of actions to execute. A plan allows to transfer from a source model to a destination model.

  • A set of Satisfaction Oriented Constraints (SatConstraints). A SatConstraint imposes a restriction on a model or a reconfiguration plan. On a model, it provides a discrete restriction. On a plan, it imposes a continuous restriction, i.e a restriction over the time. In practice, a constraint allows to control the state of the elements (VMs, servers), the resource allocation, the VMs placement, ...

  • One Optimization Constraint (OptConstraint). An OptConstraint is a special constraint that indicates to minimize or maximize a value. As an example "reduce the MTTR", "use as few nodes as possible", ... This kind of constraints will not be discussed in this tutorial.

  • A scheduler is an algorithm that takes a model, a set of SatConstraints, and an OptConstraint as parameters. It checks if the model is consistent with regards to the stated SatConstraints. If not, it computes a plan to reach a model that satisfies all these constraints simultaneously.

Defining a model

A model is composed of several elements:

In this tutorial, we will reproduce the model that is depicted by the following figure. It represents a model composed by 4 online servers hosting 5 VMs and a sixth ready for being running.

The mapping

VMs and servers are created from a model. The element state and positions are then specified through the model mapping. The next snippet is a part of the makeModel() method in the tutorial. It creates a model, 4 nodes and 6VMs:

Model model = new DefaultModel();
Mapping map = model.getMapping();

//Create 4 online nodes: N0 to N3
for (int i = 0; i < 4; i++) {
  Node n = model.newNode();

//Create 6 VMs: VM0 to VM5
for (int i = 0; i < 6; i++) {
  VM v = model.newVM();

//set VM2 running on N0
map.addRunningVM(vms.get(2), nodes.get(0));

//set VM4 is ready to be running on a node.

BtrPlace support more states for VMs and nodes. For additional information, see VMs and nodes life cycle.

Describing the current resource usage with Views##

In Btrplace, a resource is defined using a special view called ShareableResource. This allows to specify the physical resource capacity of the nodes and the virtual resource usage of the VMs.

Below is the snippet to declare a resource called "cpu" and attach it to the model

//By default, each node will provide 8 cpu resources
ShareableResource rcCPU = new ShareableResource("cpu", 8, 0);
//4 virtual cpu resources for VM2
rcCPU.setConsumption(vms.get(2), 4);
//the rcCPU view is attached to the model

By default, BtrPlace considers at most 1 unit of virtual resource can be mapped to 1 unit of physical resource. See the Overbook constraint to change this behavior.

Stating satisfaction-oriented constraints

A Satisfaction Oriented Constraint (SatConstraint) imposes a restriction on a model or a reconfiguration plan. On a model, it provides a discrete restriction. On a plan, it imposes a continuous restriction, i.e a restriction over the time. The type of the restriction depends on the constraint semantics and a constraint may support the both type of restriction.

These constraints control several aspects of the model (VM and nodes states, resource allocation, ...). By default, BtrPlace considers the state of a VM is not changed unless a constraint explicitely asks for a new state.

The following snippet creates 5 constraints:

//VM1 and VM2 must be running on distinct nodes
SatConstraint c0 = new Spread(new HashSet<UUID>(Arrays.asList(vms.get(1), vms.get(2))));

//VM0 must have at least 3 virtual CPU dedicated to it
SatConstraint c1 = new Preserve(vms.get(0), "cpu", 3);

//node N3 must be offline
SatConstraint c2 = new Offline(ns.get(3));
//VM4 must be running, It asks for 3 cpu and 2 mem resources
SatConstraint c3 = new Running(vms.get(4));
SatConstraint c4 = new Preserve(vms.get(4), "cpu", 3);
SatConstraint c5 = new Preserve(vms.get(4), "mem", 2);

//VM3 must be set back to the ready state
SatConstraint c6 = new Ready(vms.get(3));

List<SatConstraint> cstrs = Arrays.asList(c0, c1, c2, c3, c4, c5, c6);

Use BtrPlace to compute a viable model

If we oppose the model origin to the stated constraints:

  • spread(VM1, VM2) is not satisfied in mo as both VMs are running on N1.
  • preserve(VM0, "cpu", 3) is not satisfied as the VMs currently has 2 virtual CPUs.
  • offline(N3) is not satisfied as N3 is online
  • ready(VM3) is not satisfied as VM3 is running
  • running(VM4) is not satisfied as VM4 is ready.

Using Btrplace, it is possible to try to compute a new model that satisfies all the stated constraints. The following snippet instantiates a scheduler and solve the current problem:

Scheduler ra = new DefaultChocoScheduler();
ReconfigurationPlan plan = ra.solve(origin, cstrs);

plan contains a schedule of actions that will lead to a new model satisfying all the constraints in cstrs. A possible one is:

Schedule Action
0:00 to 0:01  boot VM4 on N1 then allocate 2 "mem" and 3 "cpu" resources
0:00 to 0:01  shutdown VM3
0:01 to 0:02  migrate VM5 from N3 to N2
0:02 to 0:03  shutdown N3
0:03 to 0:03 allocate 3 "cpu" on VM0

If this plan is applied, the resulting model, accessible through plan.getResultingModel() will be:

The actions schedule has been inferred from the actions semantics but also a theoretical estimation of the actions duration. By default, each action takes one second to complete. This can be changed easily to comply with your data (see Customizing a Model).

The practical duration of an actions may exceed its estimated duration. It is then not safe to rely only on the time-based schedule to execute a reconfiguration plan on a real infrastructure. A solution is to extract the actions dependencies using a DependencyBasedPlanApplier. This produces an event-based reconfiguration plan where blocked actions are delayed until there dependencies have been met (i.e. until the unblocking actions are terminated). Here, the resulting event-based plan will be:

Dependency Action
-  boot VM4 on N0
- shutdown VM3 
shutdown VM3 migrate VM5 from N3 to N1
migrate VM5 from N3 to N1  shutdown N3
shutdown N3 allocate 3 "cpu" on VM0


That's all for this tutorial. We have seen how to create a basic model, state some satisfaction-oriented constraints and compute a plan that fix a non-viable model. Have a look to the VMs and nodes life cycle for a better understanding of the state management using BtrPlace or the supported constraints.

Next tutorial is about how to use attributes and change the estimated actions durations.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.