By default, the slot allocation policy is Stacked. With this policy, for each allocation, hosts are selected in the order in which they are listed in the resource group during vemkd initialization.
EGO allocates CPU slots from one host until all the CPU slots on the host are used. When all the CPU slots on that host are used, another host is selected and CPU slots from that host are allocated until the all the CPU slots on that host are used, and so on.
The following example illustrates the Stacked slot allocation policy for the ManagementHosts resource group and the distribution of system services on management hosts.
If you have Symphony installed, you would additionally have one session manager per application.
For this example, you have 3 management hosts in the ManagementHosts resource group, 12 CPU slots configured per host.
You additionally have 6 Symphony applications, which means 6 session managers. In total, you need 8 CPU slots for system services and 6 more CPU slots for session managers, a total of 14 CPU slots.
With the Stacked slot allocation policy, CPU slots are allocated as follows:
To allocate CPU slots for the SD service, EGO evaluates host1, host2, and host3 as listed in the resource group. EGO selects host1 and places SD on host1.
To allocate CPU slots for the WEBGUI service, EGO uses available CPU slots on host1.
In this way, EGO continues to allocate slots from host1 until all CPU slots from host1 are allocated.
Once all CPU slots from host1 are allocated, host2 is selected and CPU slots from that host are allocated until all CPU slots from host2 are allocated or until CPU slots have been allocated for all services.
After CPU slots have been allocated for all services, service distribution is as follows on management hosts:
With the Balanced slot allocation policy, for each allocation, hosts are selected from the resource group according to the number of free CPU slots.
Slots are allocated first from the host with the highest number of free CPU slots. When all the CPU slots on that host are allocated, CPU slots are allocated from the next host with the highest number of free CPU slots, and so on.
Since the number of free CPU slots on a host decreases with each allocation, the same host will not be reselected unless it still has the highest number of free CPU slots. As a result, slots are allocated equally from all hosts.
The following example illustrates the Balanced slot allocation policy for the ManagementHosts resource group and the distribution of system services on management hosts.
The benefits of using the Balanced slot allocation policy for the ManagementHosts resource group are:
Performance. Allocating CPU slots from different hosts (and thus starting system services on different hosts) can improve performance during service startup and normal operations.
Recovery. Should the host fail, recovery time may be reduced because there are fewer system services running on each host.
If you have Symphony installed, you would additionally have one session manager per application.
For this example, you have 3 management hosts in the ManagementHosts resource group, 12 CPU slots configured per host.
You additionally have 6 applications, which means 6 session managers. In total, you need 8 CPU slots for system services and 6 more CPU slots for session managers, a total of 14 CPU slots.
With the Balanced resource allocation policy, slots are allocated as follows:
To allocate CPU slots for the SD service, EGO evaluates host1, host2, and host3 as listed in the resource group. All hosts have the same number of free CPU slots so EGO selects host1 and allocates slots from host1 for SD.
To allocate CPU slots for WEBGUI, EGO evaluates the free number of CPU slots on all hosts. Both host2 and host3 have the highest number of free CPU slots, 12, so EGO uses the order in which hosts are listed in the resource group to narrow down its selection. EGO selects host2 and allocates slots from host2 for WEBGUI.
To allocate CPU slots for WebServiceGateway, EGO evaluates the free number of CPU slots on all hosts. Host3 has the highest number of free CPU slots (12), so slots from host3 are allocated for WebServiceGateway.
In this way, EGO continues to allocate slots from hosts until CPU slots have been allocated for all services.
After CPU slots have been allocated for all services, service distribution is as follows on management hosts:
Using the ManagementHosts resource group example, if a host goes down, slots are allocated for services that were running on the host that went down according to the number of free CPU slots on the remaining hosts. As a result, services are restarted on the remaining hosts according to the number of free CPU slots on the remaining hosts.
When the host that went down comes back up and is available, distribution remains unchanged. Services are not migrated back to the original hosts. As a result, the host that came back up will have the highest number of free CPU slots and will be selected when new services need to be started or restarted on management hosts.