Resource groups organize a heterogeneous resource pool.
Resource groups are logical groups of hosts. Resource groups provide a simple way of organizing and grouping resources (hosts) for convenience; instead of creating policies for individual resources, you can create and apply them to an entire group. Groups can be made of resources that satisfy a specific static requirement in terms of OS, memory, swap space, CPU factor, and so on, or that are explicitly listed by name.
The cluster administrator can define multiple resource groups, assign them to consumers, and configure a distinct resource plan for each group. For example:
Define multiple resource groups: A major benefit in defining resource groups is the flexibility to group your resources based on attributes that you specify. For example, if you run workload units or use applications that need a Linux OS with not less than 1000 MB of maximum memory, then you can create a resource group that only includes resources meeting those requirements.
Configure a resource plan based on individual resource groups: Tailoring the resource plan for each resource group requires you to complete several steps. These include adding the resource group to each desired top-level consumer (thereby making the resource group available for other sub-consumers within the branch), along with configuring ownership, enabling lending/borrowing, specifying share limits and share ratio, and assigning a consumer rank within the resource plan.
Resource groups are either specified by host name or by resource requirement using the select string.
By default, EGO comes configured with three resource groups: InternalResourceGroup, ManagementHosts, and ComputeHosts.
InternalResourceGroup and ManagementHosts should be left untouched, but ComputeHosts can be kept, modified, or deleted as required.
When you create a resource group in the Platform Management Console, you must decide on how many slots to assign to each host. The assignment of slots to hosts is a critical function that serves to match the host’s resources with the expected workload. If a host is too heavily loaded, performance suffers. If it is underutilized, resources are wasted. Generally, as a starting point, one slot per CPU is allocated for each service instance.
Once the number of slots per host has been configured, it is suggested to monitor host loading via the Platform Management Console. If an adjustment is required, reconfigure the number of slots per host. If hosts are overburdened, decrease the number of slots that are assigned to them. Conversely, if hosts are underutilized, add more slots to them.
There is a 1-to-1 mapping between small workload units (for example, a session, a task, etc.) and slots.
If there is a differing individual host value of “slots per host,” it overrides the setting of x slots per host you set for the resource group. The host level setting overrides the group level configuration.
For example, if there are 10 hosts in a resource group and you choose in the Console to set up 5 slots per host, you would normally expect to see 50 slots listed within the Member Host Summary section of a resource group’s properties page. However, if you see a different number showing in the summary (for example, 45), then an administrator has manually overridden the settings for one or more hosts. This individual value overrides the group setting configured in the Console.
In some cases, even if an administrator has not manually changed the slots per host" value, you may still see an unexpected number in the Member Hosts Summary section. This may mean that certain hosts within this particular resource group are double-allocated, meaning they are allocated to more than one resource group. In cases of double-allocation, the sum of the allocated slots displays in the Member Hosts Summary section, not the number of slots for this resource group alone. It is advised not to double-allocate slots.
If you want to change the value of the number of slots per CPU, it must be specified on the workload management side (outside of EGO).
The value for the number of CPUs per host is automatically detected during installation.
The number of slots per host can be defined in the Platform Management Console as an expression. Here are the expression guidelines:
When host slots are allocated to a client, the vemkd detects the resource group to which the host belongs. But when the vemkd restarts, there is a brief interval (while host information gets updated) where it may not immediately detect the host’s resource group. It is during this update interval that Platform EGO creates a temporary resource group called “LOST_AND_FOUND”. The vemkd adds any host with a current allocation to this resource group if it cannot immediately detect an assigned group. Once vemkd completes its update of host information and detects the host’s assigned resource group, the host automatically rejoins it.
Similarly, if a host with allocated slots is permanently removed from its resource group (thus never rejoining its original resource group when vemkd restarts), the vemkd adds this host to the “LOST_AND_FOUND” group. It will remain in this group until the cluster administrator frees up the allocation on the host.