Skip to content

Getting Started

Jump to bottom
fhermeni edited this page Oct 28, 2014 · 95 revisions

Getting started

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

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();
  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 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
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 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

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