Skip to content

Getting Started

Jump to bottom
Fabien Hermenier edited this page Jun 3, 2013 · 95 revisions

Getting started

Btrplace is a flexible algorithm 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.

[Associated source code] (https://github.com/fhermeni/btrplace-solver/blob/master/examples/src/main/java/btrplace/examples/GettingStarted.java)

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

  • A reconfiguration algorithm is an algorithm that takes a model and a set of constraints as a parameter. It checks if the model is consistent with regards to the states constraints. If not, it computes a plan to reach a model that satisfies all the 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();
  map.addOnlineNode(n);
}

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

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

//set VM4 is ready to be running on a node.
map.addReadyVM(vms.get(4));

BtrPlace support more states for VMs and nodes. For additional informations, 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
model.attach(rcCPU);

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

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(Collections.singleton(vms.get(0)), "cpu", 3);

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

//VM3 must be set back to the ready state
SatConstraint c6 = new Ready(Collections.singleton(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 reconfiguration algorithm and solve the current problem:

ChocoReconfigurationAlgorithm ra = new DefaultChocoReconfigurationAlgorithm();
ReconfigurationPlan plan = ra.solve(origin, cstrs);

plan contains the following schedule of actions that will lead to a new model satisfying all the constraints in cstrs:

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 applyed, the resulting model, accesible through plan.getResultingModel() will be:

The actions schedule has been infered from the actions semantics but also a theroretical 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 Basic Tuning).

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 N1
- shutdown VM3 
shutdown VM3 migrate VM5 from N3 to N2
migrate VM5 from N3 to N2  shutdown N3
shutdown N3 allocate 3 "cpu" on VM0

Conclusion

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.

Clone this wiki locally