Oversubscription at the node level

Next, we provision application instances inside virtual data centers. An application instance must specify the virtual datacenter it runs in. It also specifies the amount of resources it needs, and whether those resources must come from a certain category or from any category.

Continuing the example from Oversubscription at migration zone level, we allocate a total of six (6) application instances. App1 is allocated inside VDC1 and needs 12 cores and 128 GB of General. App2 is allocated inside VDC2 and needs 20 cores and 64 GB of General. App3 is also allocated inside VDC2 and needs 20 cores and 128 GB of High_Perf. App4 is allocated inside VDC3 and needs 10 cores and 64 GB of any category. Since there are not enough resources of the High_Perf category, App4 is allocated in the General category. App5 in VDC3 needs five (5) cores and 32 GB of General. Finally, App6 in VDC3 needs four (4) cores and 12 GB of High_Perf. We still have room for application instances in VDC1 as long as they consume less than four (4) cores and 32 GB of General category or can run in any category. (These resources must be available in a single node.) Similarly, we still have room for application instances in Virtual Data Center2 as long as they consume less than four (4) cores and 32 GB of either category, and in VDC3 as long as they consume less than five (5) cores and 32 GB of General.

Refer to the following table for the example allocation of application instances to virtual data centers and what remains available in each virtual data center.

Table 1. Allocation of application instances to VDCs and what remains available in each VDC
	Compute Categories
Migration Zone Allocation	40	256	20	128
VDC Allocations	General		High Perf
	Cores	RAM	Cores	RAM
VDC1	16	160	0	0
App1	12	128
Free	4	32
VDC2	24	96	24	160
App2	20	64
App3			20	128
Free	4	32	4	32
VDC3	20	128	4	12
App4	10	64
App5	5	32
App6			4	12
Free	5	32	0	0
Subscription Factor	1.5	1.5	1.4	1.34375

To support even more application instances, infrastructure admins may allow the size of existing virtual data centers to become larger. For example, if an application instance that consumes more than four (4) cores and 32 GB of General needs to be started in Virtual Data Center1, this cannot be allowed until Virtual Data Center1 is made larger. Infrastructure admins may also allow new virtual data centers to be created; for example, they may allow a new Virtual Data Center4.

The infrastructure admin can look at the actual utilization of the running application instances to decide whether to allow these new allocations. Even though the subscription factor for the General category in this example is 1.5, if it turns out that the actual utilization of the General application instances (that is, application instances running on General nodes) is quite low, the admin can allow more virtual data centers to be created using General compute and General GBs and let the subscription factor go even higher. On the other hand, if the actual utilization of General application instances is very high, further virtual data centers needing General compute and General GBs may not be permitted. The infrastructure admin must make this decision carefully. Once the infrastructure admin allows a virtual data center of a certain size (cores, GBs) to be created, the virtual data center administrator for that virtual data center expects to be able to fully use those cores and GBs in running applications.

CAUTION

If an infrastructure admin allows utilizations to run high, there is a danger that a virtual data center admin cannot start an application in their virtual data center, even with enough resources allocated. This situation must be avoided.

Since application instances must run on nodes, assume App1 and App4 run on Node 1, App2 and App5 run on Node 2, and App3 and App6 run on Node 3 as shown in the following table. This table shows the node-level oversubscription after the application instances have been provisioned. SF refers to subscription factor.

Table 2. Example assignment of application instances to nodes
	Apps	Cores	GB
Node 1	App1	20	128
	App4	10	64
	Used	30	192
	Avail	20	128
	SF	1.5	1.5
Node 2	App2	20	64
	App5	5	32
	Used	25	96
	Avail	20	128
	SF	1.25	0.75
Node 3	App3	20	128
	App6	4	12
	Used	24	140
	Avail	20	128
	SF	1.2	1.09375

The ThinkAgile CP user interface shows the application instances assigned to each node, as well as the core and memory requirements of each application instance. The subscription factor per node is not shown in the UI,but can be calculated by summing up the needs of each application instance on that node.

The ThinkAgile CP user interface also shows the load on each node. The load is different than the subscription factor.; the load is a function of the actual usage of the running application instances and can be lower than the subscription factor. It also varies with time. The load also includes the resources taken up by the hypervisor. A new application instance can be started on a node as long as the load is low enough and can accommodate the needs of the new instance, even if the subscription factor is high.

In our example, Node 1 has a compute subscription factor of 1.5 and a memory subscription factor of 1.5. The compute subscription factor is acceptable in our example. However, a memory subscription factor of 1.5 is higher than we generally recommend.

Give feedback