A VM Group defines a set of related VMs, and associated placement constraints for the VMs in the group. A VM Group allows you to place together (or separately) ceartain VMs (or VM classes, roles). VMGroups will help you to optimize the performance (e.g. not placing all the cpu bound VMs in the same host) or improve the fault tolerance (e.g. not placing all your front-ends in the same host) of your multi-VM applications.
HyperCX pre-configured groups
Two Vm groups are configured and ready to be used by default on HyperCX Bento clusters:
- HA: Instances belonging to this group will be divided among different hosts. This is useful to separate workloads from an HA cluster.
- Packed: Instances belonging to this group will be deployed on the same compute node. This is useful for workloads that require a heavy east-west traffic. By using this group, these instances will communicate using the server's internal bridge and will not affect the physical network.
HyperCX MiniBento will not use these VM Groups by default.
Using a VM Group
VMs can be added to Virtual Groups by either picking a role and VM group at instantiation or by setting it in the VM Template.
Defining a VM Group
A VM Group consists of two parts: a set of roles, and a set of placement constraints for the roles. In a VM Group, a role defines a class of virtual machines that are subject to the same placement constraints and rules. Usually, you will put in the same role VMs implementing a given functionality of a multi-VM application, e.g. the front-ends or the database VMs. Additonally, you can define placement constraints for the VMs in the VM-Group, this placement rules can refer to the VMs within a role or VMs across roles.
A role is defined with the following attributes:
|NAME||Mandatory||The name of the role, it needs to be unique within the VM Group|
|POLICY||Optional||Placement policy for the VMs of the role. Possible values are: AFFINED and ANTI-AFFINED|
|HOST_AFFINED||Optional||Defines a ser of hosts (by their ID) where the VMs of the role can be executed|
|HOST_ANTI_AFFINED||Optional||Defines a set of hosts (by their ID) where the VMs of the role cannot be executed|
Additional placement constraints can be imposed to the VMs of a role with the following attributes:
|AFFINED||Optional||List of roles (comma separated) whose VMs has to be placed in the same host|
|ANTI_AFFINED||Optional||List of roles (comma separated) whose VMs cannot be placed in the same host|
The following placement policies can be applied to the VMs of a VM Group.
VM to Host Affinity
Specifies a set of hosts where the VMs of a role can be allocated. This policy is set in a role basis using the HOST_AFFINED and HOST_ANTI_AFFINED attributes. The host affinity rules are compatible with any other rules applied to the role VMs.
A common example is to place VMs implementing an important database in high performance hosts. In this case, you should select the affined hosts under Host-VM affinity.
VM to VM Affinity
Specifies whether the VMs of a role have to be placed together in the same host (AFFINED) or scattered across different hosts (ANTI_AFFINED). The VM to VM affinity is set per role with the POLICY attribute.
A common example is to spread the VMs belonging to a HA cluster. In this case, the Anti Affined option should be selected under VM-VM affinity.
Role to Role Affinity
Specifies whether the VMs of a role have to be placed together or separately with the VMs of other role. This useful to combine the Host-VM and VM-VM policies. Affinity rules for roles are set with the AFFINED and ANTI_AFFINED attributes.
For example, I want the VMs of a database to run together so they access the same storage, I want all the backup VMs to run in a separate hosts; and I want database and backups to be also in different hosts. Finally, I may have some constraints about where the database and backups may run. For this case, a role called apps will be created as AFFINED with N servers under Affined Hosts. Another group called backup will be created as Anti Affined. Finally, roles apps and backup are selected as Anti Affined.
Scheduler Configuration and Remarks
VMGroups are placed by dynamically generating the requirement (SCHED_REQUIREMENTS) of each VM an re-evaluating these expressions. Moreover, the following is also considered:
The scheduler will look for a host with enough capacity for an affined set of VMs. If there is no such host all the affined VMs will remain pending.
If new VMs are added to an affined role, it will pick one of the hosts where the VMs are running. By default, all should be running in the same host but if you manually migrate a VM to another host it will be considered feasible for the role.
The scheduler does not have any synchronization point with the state of the VM group, it will start scheduling pending VMs as soon as they show up.
Re-scheduling of VMs works as for any other VM, it will look for a different host considering the placement constraints.