Skip to content

Getting Started

Jump to bottom
Fabien Hermenier edited this page May 16, 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 platforms. 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 transit 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 figure on the left. It represents a model composed by 4 online servers hosting 6 running VMs.

The mapping

In Btrplace, as in many hypervisors, elements such as servers and VMs are identified by a UUID. The next snippet creates a mapping that declare the online node n1 and place VMs vm2 and vm3 on it. Next it creates a model origin:

Mapping m = new DefaultMapping();

UUID n1 = UUID.randomUUID();
UUID vm2 = UUID.randomUUID();
UUID vm3 = UUID.randomUUID();
//n1 is online
map.addOnlineNode(n1);

//vm3 and vm2 runs on n1
map.addRunningVM(vm3, n1);
map.addRunningVM(vm2, n1);

Model origin = new DefaultModel(map);

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 origin. For this example, itindicates the number of physical CPUs available on n1, and the number of virtual CPUs that are allocated to vm2 and vm3.

ShareableResource rcCPU = new ShareableResource("cpu");
//n1 has 8 physical CPUs
rcCPU.set(n1, 8);
        
//vm2 has 3 virtual CPUs
rcCPU.set(vm2, 3);
//vm3 has 3 virtual CPUs
rcCPU.set(vm3, 4);
        
//the rcCPU view is attached to the model
origin.attach(rcCPU);

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.

The following code creates 5 constraints:

//VM2 and VM3 must be running on distinct nodes
Spread s = new Spread(new HashSet<UUID>(Arrays.asList(vm2, vm3)));

//VM1 must have at least 3 virtual CPU dedicated to it
Preserve cpu4vm1 = new Preserve(Collections.singleton(vm1), "cpu", 3);

//node N4 must be offline
Offline offN4 = new Offline(Collections.singleton(n4));
  
Set<SatConstraint> cstrs = new HashSet<SatConstraint>(Arrays.asList(spread, cpu4vm1, offN4));

Use BtrPlace to compute a viable model

If we oppose the model origin with the set of constraints:

  • spread(vm2, vm3) is not satisfied in mo as both VMs are running on n1.
  • preserve(vm1, "cpu", 3) is not satisfied as the VMs currently has 2 virtual CPUs.
  • offline(n4) is not satisfied as n4 is online.

Using Btrplace, it is possible to compute a new model that satisfies all the stated constraints. The following snipped instantiates the default 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  migrate vm5 from n3 to n2
0:00 to 0:01  migrate vm3 from n1 to n2
0:01 to 0:02  migrate vm6 from n4 to n1
0:02 to 0:03  shutdown n4
0:03 to 0:03 allocate 3 "cpu" on vm1

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.

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
-  migrate vm5 from n3 to n2
- migrate vm3 from n1 to n2 
migrate vm3 from n1 to n2 migrate vm6 from n4 to n1
migrate vm6 from n4 to n1  shutdown n4
migrate vm5 from n3 to n2 allocate 3 "cpu" on vm1

Basic tuning the solving process

A couple of getters/setters allows to tune the basic parameters of the solving process. These methods are in ChocoReconfigurationAlgorithm

Optimizing

By default, Btrplace stops once a solution has been found. However, it might be worthy to let it try to improve the solution if an Objective is set.

  • The method ChocoReconfigurationAlgorihm.doOptimize(boolean) tells BtrPlace if it can continue searching once a first solution has been computed

  • The method ChocoReconfigurationAlgorihm.setObjective(boolean) declares the ReconfigurationObjective to consider when solving a problem. By default, it is MinMTTR which tries to make reconfiguration plan as small and fast as possible.

Setting a timeout

By default, BtrPlace stops the solving process until a solution has been found. Solving big or hard problems may then take a non-reasonnable time (from milliseconds to hours or even days). The method ChocoReconfigurationAlgorihm.setTimeLimit(int) specifies a timeout value.

Repair mode

By default, BtrPlace considers every VMs when it solves a model. This may lead to a non-reasonnable solving process duration when a few number of constraints are violated. The repair approach addresses that problem by trying to reduce as possible the number of VMs to consider in the model. The downside is that in some corner cases, it may not be able to compute a solution.

See the method ChocoReconfigurationAlgorihm.doRepair(boolean)

Clone this wiki locally