Customizing a Model

Customizing a Model

[Associated source code] (http://www.btrplace.org/apidocs/index.html?org/btrplace/examples/ModelCustomization.html)

In this tutorial, we present how to customize a model using Model' Attributes a specific actions duration estimators. On the sample model associated to this tutorial, this customization allows BtrPlace to infer for the best possible relocation method for VMs.

Element attributes

Attributes allow to provide additional informations about given elements in a model. The supported attributes are described here.

As an example, it is possible to indicate a VM can be relocate using either live-migration or re-instantiation. This possibility is given to the reconfiguration algorithm using two VM attributes: clone to indicate the VM can be re-instantiated, and template to indicate the template to use to re-instantiate a new VM if needed.

The following snippet set the template for the VMs and states they are cloneable. It also indicates a specific forge duration for each VM.

Attributes attrs = model.getAttributes();

for (VM vm : model.getMapping().getAllVMs()) {
  attrs.put(vm, "template", vm.id() % 2 == 0 ? "small" : "large");
  attrs.put(vm, "clone", true);
  attrs.put(vm, "forge", vm.id() % 2 == 0 ? 2 : 10);
}

Custom estimated action duration

BtrPlace computes a schedule for the reconfiguration actions using, among other things, an estimated duration of the actions. By default, BtrPlace estimates an action takes 1 second to complete but this can be overriden using attributes (see Supported Attributes).

In practice, each action duration is estimated using a dedicated DurationEvaluator. These evaluators are accessible from the DurationEvaluators associated to a ChocoReconfigurationAlgorithm. By default, a DurationFromAttribute is used but this can be changed to another pre-defined or a custom implementations of DurationEvaluator.

The following snippet associates a new evaluator for the MigrateVM action. This evaluator states the action duration equals two times the amount of memory allocated to the VMs plus 3 seconds:

dev.register(MigrateVM.class, new LinearToAResourceDuration("mem", 2, 3));

Solving the problem using migration or re-instantiation:

In this tutorial, the following constraints are defined:

• runningCapacity(N0, 5) and runningCapacity(N0, 5) to restrict to up to 5 the number of running VMs on each node
• gather({VM0,VM9}) to force both VMs being co-located
• split({VM0, VM1, VM3}, {VM4, VM5, VM7}) to force the 2 set of VMs to not share any nodes
• running(VM9) to set this VM running.

The following reconfiguration plan is a solution that satisfies all the constraints. With the cloneand the template attributes set, BtrPlace is aware it is possible to perform a relocation using a migration or a re-instantiation. BtrPlace inferred it was a necessary to relocate VM4 and VM5 to be able to reach a new viable model. The following table summarizes the relocation duration of these VMs depending on the relocation method.

VM	Migration duration	Re-instantiation duration
VM4	7 sec. (2 x mem + 3, mem=2)	4 sec. : 2 sec. (forge) + 1 sec. (boot) + 1 sec. (shutdown)
VM5	9 sec. (2 x mem + 3, mem=3)	12 sec. : 10 sec. (forge) + 1 sec. (boot) + 1 sec. (shutdown)

With these estimations, BtrPlace inferred it is faster to relocate VM4 using a re-instantation and VM5 using a migration. The following table shows the resulting reconfiguration plan. VM10 is the new clone that will, once booted, substitute VM4.

Schedule	Action
0:00 to 0:01	boot VM9 on N0
0:00 to 0:02	forge VM10
0:00 to 0:09	migrate VM5 from N0 to N1
0:02 to 0:03	boot VM10 on N1
0:03 to 0:04	shutdown VM4

Conclusion

In this tutorial, we saw how to customize a model using attributes and how to change the estimated actions duration.

The next tutorial is about the tuning of a scheduler to control the solving duration and the quality of the computed plans.