Customizing a Model

Customizing a Model

Element attributes

Attributes allow to provide additional informations about given elements in a model. The supported attributs 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. In addition, the clone attribute is set to allow their re-instantiation:

Attributes attrs = mo.getAttributes();

for (UUID vm : mo.getMapping().getAllVMs()) {
  long i = vm.getLeastSignificantBits();
  attrs.put(vm, "template", i % 2 == 0 ? "small" : "large");
  attrs.put(vm , "clone", true);
}        

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:

• singleRunningCapacity({n1, n2}, 5) to restrict to up to 5 the number of running VMs on each node
• gather({vm1,vm10}) to force both VMs being co-located
• split({vm1, vm2, vm4}, {vm5, vm6,vm8}) to force the 2 set of VMs to not share any nodes
• running({vm10}) to set this VM running.

The following reconfiguration plan is a solution that satisfies all the constraints. BtrPlace stated it was more efficient to choose a re-instantiation over a migration to relocate vm6. Indeed, its migration would take 9 seconds while its re-instantiation takes 3 seconds. BtrPlace also stated it was more efficient to relocate vm5 using a migration over a re-instantiation.

Schedule	Action
0:00 to 0:01	boot vm10 on n1
0:00 to 0:02	forge vm6'
0:00 to 0:07	migrate vm5 from n1 to n2
0:02 to 0:03	boot vm6' on n1
0:03 to 0:04	shutdown vm6

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 reconfiguration algorithm to control the solving duration and the quality of the computed plans.