Skip to content

Getting Started

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

Getting started

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

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.

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