Understanding resource groups

Resource groups provide a simple way of organizing and grouping resources (hosts). Instead of creating policies for individual resources, you can create and apply them to an entire group. Groups can be made of resources that are explicitly listed by name or those that satisfy a specific static requirement in terms of operating system, memory, swap space, CPU factor, and so on.

The cluster administrator can define multiple resource groups, assign them to consumers, and configure a distinct resource plan for each group.
Defining 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 use instance groups that need a Linux® operating system with not less than 1000 MB of maximum memory, you can create a resource group that only includes resources meeting those requirements.
Note: Ensure that your hosts do not overlap resource groups. Overlaps cause the hosts to be double-counted (or more) in the resource plan, resulting in recurring underallocation of some consumers.
Configuring a resource plan for individual resource groups
Tailoring the resource plan for each resource group requires you to complete several steps. These steps include adding the resource group to each desired frist level consumer (thereby making the resource group available for sub-consumers), along with configuring ownership, enabling lending or borrowing, specifying share limits and share ratio, and assigning a consumer rank within the resource plan.
Resource groups generally fall into one of three categories:
  • Resource groups that include compute hosts with certain identifiable attributes that a consumer may require in a requested resource; for example, resources with large amounts of memory. These resources are considered dynamic to indicate new hosts added to the cluster that meet the requirements and which are automatically added to the resource group.
  • Resource groups that only include certain compute hosts; for example, so that specified resources are accessed by approved consumers. These resources are considered static to indicate any new hosts added to the cluster that have to be manually added to the resource group.
  • Resource groups that only encompass management hosts (reserved for running services, not a distributed workload); for example, the predefined ManagementHosts group).
Resource group host lists are defined by a static list or are dynamic. A static list is where you specifically choose which hosts to use. Dynamically is where you specify either all hosts or a resource requirement so that when new hosts join, they are automatically added to the resource group.
Note: Requirements for resource-aware allocation policies (where only resources that meet specified requirements are allocated to a consumer) can be met by grouping resources with common features and configuring them as special resource groups with their own resource plans.
Tip: Use the egoconfig addresourceattr command to add a custom resource attribute tag to a host and then specify that tag when creating a resource group. See egoconfig.

Default resource groups

By default, EGO is configured with three resource groups: InternalResourceGroup, ManagementHosts, and ComputeHosts.

InternalResourceGroup and ManagementHosts must be untouched, but ComputeHosts can be kept, modified, or deleted if required.

Lost_and_found resource group

When host slots are allocated to a client, the resource manager (VEMKD) detects the resource group to which the host belongs. But when the VEMKD process restarts, there is a brief interval (while host information is updated) where it may not immediately detect the host's resource group. During this interval, 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 its resource group.

Note: This happens only if the host is already allocated and VEMKD must trace its resource group. If the host does not currently belong to an allocation, VEMKD does not search for a resource group.

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.