Manual Chapter : Flexible Resource Allocation

Applies To:

Show Versions Show Versions

BIG-IP AAM

  • 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1

BIG-IP GTM

  • 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1

BIG-IP LTM

  • 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1

BIG-IP ASM

  • 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Manual Chapter

Flexible Resource Allocation

What is flexible resource allocation?

Flexible resource allocation is a built-in vCMP® feature that allows vCMP host administrators to optimize the use of available system resources. Flexible resource allocation gives you the ability to configure the vCMP host to allocate a different amount of CPU and memory to each guest, based on the needs of the specific BIG-IP® modules provisioned within a guest. When you create each guest, you specify the number of cores that you want the host to allocate to the guest. Configuring these settings determines the total amount of CPU and memory that the host allocates to the guest. With flexible allocation, you can customize CPU and memory allocation in granular ways that meet the specific resource needs of each individual guest.

Understanding guest resource requirements

Before you create vCMP® guests and allocate system resources to them, you need to determine the specific CPU and memory needs of each guest. You can then decide how many cores to allocate to a guest, factoring in the resource capacity of your hardware platform.

To determine the CPU and memory resource needs, you must know:

  • The number of guests you need to create
  • The specific BIG-IP® modules you need to provision within each guest
  • The combined memory requirement of all BIG-IP modules within each guest

Resource allocation planning

To determine the resource allocation that you need to configure for each guest, you must know the resource capacity of your hardware platform and the total memory requirement for each guest. You can then calculate the number of cores required for each guest based on the memory requirement that you want to configure for each guest.

Prerequisite hardware considerations

Appliance models vary in terms of how many cores the model provides and how much memory each core contains. Also variable is the maximum number of guests that each model supports.

Before you can determine the number of cores to allocate to a guest, you should understand:

  • The total number of cores that the model provides
  • The amount of memory that the model provides
  • The maximum number of guests that the model supports

By understanding these metrics, you ensure that the total amount of resource you allocate to guests is aligned with the amount of resource that your appliance model supports.

For specific information on the resources that each appliance model provides, see the vCMP® guest memory/CPU core allocation matrix on the AskF5™ Knowledge Base at http://support.f5.com.

About core allocation for a guest

When you create a guest on the vCMP® system, you must specify the total number of cores that you want the host to allocate to the guest based on the guest's total resource needs. Each core provides some amount of CPU and a fixed amount of memory. You should therefore specify enough cores to satisfy the combined memory requirements of all BIG-IP® modules that you provision within the guest.

Important: For metrics on memory and CPU support per appliance model, refer to the vCMP guest memory/CPU allocation matrix at http://support.f5.com.

About single-core guests

On platforms with hard drives, the vCMP® host always allocates cores for a guest in increments of two cores. In the case of platforms with solid-state drives, however, the host can allocate a single core to a guest, but only for a guest that requires a maximum of one core; for guests that require more than one core, the host does not allocate an odd number of cores (such as three, five, or seven cores).

The illustration shows a possible guest configuration on an appliance with a solid-state drive, where one of the guests has a single core only allocated to it.

vcmp single-core guest

A vCMP configuration with a single-core guest

Because the amount of CPU and memory in a single-core guest is limited, F5 Networks® highly recommends that you provision only the BIG-IP® Local Traffic Manager™ (LTM®) module within a single-core guest, and no other modules.

About SSL and compression hardware

On systems that include SSL and compression hardware processors, the vCMP® feature shares these hardware resources among all guests on the system, in a round robin fashion.

When sharing SSL hardware, if all guests are using similar-sized keys, then each guest receives an equal share of the SSL resource. Also, if any guests are not using SSL keys, then other guests can take advantage of the extra SSL resource.

Guest states and resource allocation

As a vCMP® host administrator, you can control when the system allocates or de-allocates system resources to a guest. You can do this at any time, by setting a guest to one of three states: Configured, Provisioned, or Deployed. These states affect resource allocation in these ways:

Configured
This is the initial (and default) state for newly-created guests. In this state, the guest is not running, and no resources are allocated to the guest. If you change a guest from another state to the Configured state, the vCMP host does not delete any virtual disks that were previously attached to that guest; instead, the guest's virtual disks persist on the system. The host does, however, automatically de-allocate other resources such as CPU and memory. When the guest is in the Configured state, you cannot configure the BIG-IP® modules that are licensed to run within the guest; instead, you must set the guest to the Deployed state to provision and configure the BIG-IP modules within the guest.
Provisioned
When you change a guest from Configured to Provisioned, the vCMP host allocates system resources to the guest (CPU, memory, and any unallocated virtual disks). If the guest is new, the host creates new virtual disks for the guest and installs the selected ISO image on them. A guest does not run while in the Provisioned state. When you change a guest from Deployed to Provisioned, the host shuts down the guest but retains its current resource allocation.
Deployed
When you change a guest to the Deployed state, the guest administrator can then provision and configure the BIG-IP modules within the guest. If you are a host administrator and you reconfigure the properties of a guest after its initial deployment, the host immediately propagates those changes to all of the guests and also propagates the list of allowed VLANs.