Applies To:Show Versions
- 11.3.0, 11.2.1
- 11.3.0, 11.2.1
- 11.3.0, 11.2.1
- 11.3.0, 11.2.1
- 11.3.0, 11.2.1
Virtual Clustered Multiprocessing (vCMP) is a feature of the BIG-IP system that allows you to run multiple instances of the BIG-IP software on a single hardware platform. vCMP allocates a specific share of the hardware resources to each BIG-IP instance, or vCMP guest. Each guest that you create behaves as a separate BIG-IP device, having its own CPU, memory, and disk space. Each guest also has its own configuration file, log files, and kernel instance.
vCMP is built on F5 Networks' CMP technology. CMP works with cluster members. Cluster members can be slots within a chassis or instances of the Traffic Management Microkernel (TMM) on an appliance. CMP allows cluster members to work together to form a coherent, distributed traffic-processing system to share traffic load. vCMP takes this one step further by allowing you to create and run virtualized BIG-IP modules, using a standards-based, purpose-built hypervisor.
A vCMP system includes these main components.
|BIG-IP cluster||A BIG-IP cluster is the set of available slots (cluster members) on the chassis. You manage a BIG-IP cluster using the Clusters screens in the BIG-IP Configuration utility.|
|Cluster IP address||A cluster IP address is a management IP address that you assign to a cluster to access the system. On a vCMP system, there are multiple cluster IP addresses: one for the BIG-IP cluster (to access the vCMP host), and one for each virtual cluster (to access each guest).|
|vCMP daemon||This daemon, named vcmpd, performs most of the work to create and manage guests, as well as to configure the virtual network.|
|vCMP guest||A vCMP guest is an object that you create on the vCMP system for the purpose of running one or more BIG-IP modules. A guest consists of a TMOS instance, plus one or more BIG-IP modules. Each guest has its own share of hardware resources that the vCMP host allocates to it, effectively making each guest function like a separate BIG-IP device.|
|vCMP host||The vCMP host is the system-wide hypervisor that makes it possible for you to create, view, and manage all guests on the system. A vCMP host allocates system resources to guests as needed.|
|VM||A Virtual machine is the portion of a guest that resides on a slot. For example, a guest that spans four slots comprises four VMs.|
|Virtual cluster||A virtual cluster is similar to a normal cluster on a chassis, except that unlike a normal cluster, a separate virtual cluster exists for each guest on the system. A virtual cluster contains only the portions of the slots that pertain to an individual guest. For example, if a guest spans two slots, then the two slot portions for the guest represent a virtual cluster. There is a one-to-one correlation of a virtual cluster to a guest.|
|Virtual disk||A virtual disk is the portion of disk space on a slot that the system has allocated to a guest. For example, if a guest spans three slots, the system creates three virtual disks for that guest. Each virtual disk is implemented as an image file with an .img extension, such as guest_A.img.|
|Virtual management network||The virtual management network contains the components necessary to connect a guest to the management network of the vCMP host.|
BIG-IP license considerations for vCMP
The BIG-IP system license authorizes you to provision and run the vCMP feature. Note the following considerations:
- Each guest inherits the license of the vCMP host.
- The license must include all BIG-IP modules that are to be provisioned within the guest. Examples of BIG-IP modules are BIG-IP Local Traffic Manager™ and BIG-IP Global Traffic Manager™.
- The license specifies the maximum number of vCMP guests that you can deploy simultaneously.
You activate the BIG-IP system license when you initially set up the system.
vCMP provisioning overview
The BIG-IP system allocates a portion of its resources to running vCMP. The system also allocates various system resources to each vCMP guest that you create. You enable this allocation through various types of provisioning:
- First, you provision the BIG-IP system for vCMP, by logging into the chassis system and using the Resource Provisioning screens within the BIG-IP Configuration utility. When you do this, the BIG-IP system dedicates all but 30GB of disk space to running the vCMP feature. (The 30GB of reserved disk space protects against any possible resizing of the file system.)
- After creating a guest, you set the State of the guest to Provisioned, which installs the guest on the host and causes the BIG-IP system to allocate the necessary system resources (such as CPU cores and virtual disks) to the guest. You install and provision guests one at a time; each guest takes you about 5 minutes to set up.
- Finally, after you deploy the guest, you provision specific BIG-IP modules within each guest, by logging into each guest and using the Resource Provisioning screens within the BIG-IP Configuration utility. In this way, each guest can run a different combination of modules. For example, one guest can run BIG-IP LTM only, while a second guest can run LTM and BIG-IP ASM™.
vCMP best practices
F5 Networks has the following recommendations for managing a vCMP system.
|Guest configuration||If you need to move a guest's configuration to another vCMP system (chassis), copy the guest configuration and then de-allocate all virtual resources (virtual disk, CPU cores, and so on) from the guest.|
|Licensing||Before upgrading a guest to a newer version of BIG-IP software later, you might need to coordinate with the vCMP host administrator to renew the license key.|
|Local traffic configuration||When you are logged in to the vCMP host, do not configure local traffic features (virtual servers, pools, profiles, and so on). To configure local traffic features, you must be logged in to a guest using the guest's cluster IP address, and the BIG-IP LTM module must be provisioned.|
|Network setup||When initially setting up the BIG-IP system, physically wire each slot's management interface to an external bridge. Access to the vCMP host could otherwise be impaired, because vCMP guests can be deployed on any slot in the chassis, and the primary member for a guest's virtual cluster can migrate. When you follow this recommendation, you do not need to re-configure the vCMP host or any external networks when the primary member of a virtual cluster changes.|
|Self IP address configuration||Configure self IP addresses on the vCMP guests. Because a vCMP guest acts as a fully functional BIG-IP system, configure self IP addresses on each vCMP guest just as you would on a physical BIG-IP system. You can also configure self IP addresses on the vCMP host to facilitate basic network connectivity tests. However, these self IP addresses are not visible to vCMP guests.|
|vCMP provisioning||When you provision the vCMP feature, the BIG-IP system allocates most, but not all, of the disk space to the vCMP application volume. The system reserves approximately 30 GB of disk space for other uses. If you want the system to reserve more than 30 GB of disk space, such as for installing another version of the BIG-IP system in the future, do this prior to provisioning the vCMP feature. Doing so after you have provisioned the vCMP feature can produce unwanted results. When increasing the reserve space on the disk, the recommended amount of additional space to reserve is 8 GB per BIG-IP installation.|
|Virtual disk management||When a virtual disk becomes unattached from a guest, that virtual disk remains on
the system. To prevent unattached virtual disks from consuming disk space over time,
consider deleting unwanted virtual disks from the system.
Important: Before deciding to delete a virtual disk, make certain that there is no potential use for it. Configuration objects for guests that require that virtual disk for re-creation, will no longer be available.
|VLAN configuration||Configure VLANs on the vCMP host instead of on the guest, because VLANs specified in the guest are not accessible on the vCMP host. Also, if two guests each have a VLAN group, verify that the VLAN group for each guest does not bridge the same two VLANs.|