Customizing a Model

Customizing a Model

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 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 = 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 : 7);
}

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({N0, N1}, 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. BtrPlace stated it was a necessary to relocate VM4 and VM5 to be able to reach a new viable model. With the clone and the template attributes set, it is possible to choose between a migration or a re-instantiation to relocate the VMs.

    //Relocate VM4:
    //  using a migration: mem=2 -> 7 sec.
    //  using a re-instantiation: 3 sec. (forge:2 + boot:1)
    //Relocate VM5:
    //  using a migration: mem=1 -> 5 sec.
    //  using a re-instantiation: 8 sec. (forge:7 + boot:1)

VM	Migration duration	Re-instantiation duration
VM4	7 sec. (2x mem + 3, mem==2)	3 sec. : 2 sec. (forge) + 1 sec. (boot)
VM5	5 sec. (2x mem + 3, mem==1)	8 sec. : 7 sec. (forge) + 1 sec. (boot)

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 VM9 on N0
0:00 to 0:02	forge VM10
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.