VM harvesting for IBM Spectrum Symphony

The IBM® Spectrum Symphony Server and VM Harvesting add-on feature for IBM Spectrum Symphony maximizes utilization of computing resources by harvesting VMs for IBM Spectrum Symphony workload when the demand exceeds IBM Spectrum Symphony's dedicated cluster resources. The VMs, which are shared with virtual desktops and other non-IBM Spectrum Symphony applications, can be made available to IBM Spectrum Symphony during periods of low VM utilization by these applications.

IBM Spectrum Symphony Server and VM Harvesting is only available with the IBM Spectrum Symphony Standard and Advanced editions on Windows and Linux® management hosts. An entitlement key is required to enable this feature. You can use these VMs with this feature:

VMware ESXi 5.5 with vCenter 5.5 and ESXi 6.0 with vCenter 6.0
Citrix XenServer 5.5 and 6.5

Limitations

IBM Spectrum Symphony Server and VM Harvesting only controls VMs belonging to an IBM Spectrum Symphony cluster within a VMware cluster or Citrix XenServer pool. All other VMs are outside the control of VM harvesting for IBM Spectrum Symphony.
IBM Spectrum Symphony Server and VM Harvesting does not support overlapped resource groups.

About VM harvesting

VM harvesting uses configurable CPU and memory utilization thresholds to determine if VMs can be made available for IBM Spectrum Symphony workload. Once VMs become available, VM harvesting can manage their personalities according to the application's requirements.

Functional flow

VM harvesting starts as an EGO service immediately after the IBM Spectrum Symphony primary host is up and running. On startup, VM harvesting connects to both the IBM Spectrum Symphony primary host and to each configured VMware vCenter or Citrix pool server. After the connections have been established, VM harvesting identifies all the IBM Spectrum Symphony virtual machines in the virtual clusters/pools. These logical compute hosts are located through the EGO API in the IBM Spectrum Symphony cluster. Initially, these hosts are closed and therefore not available to IBM Spectrum Symphony.

VM harvesting periodically monitors the VMware clusters and Citrix pools to gather cluster-level and physical host-level utilization metrics (CPU and memory) and compare them to preconfigured threshold values. If there is unsatisfied IBM Spectrum Symphony workload demand, three possible actions can be taken for each VMware cluster or Citrix pool during each scheduling cycle: (note that unless otherwise stated, the term cluster refers to both vCluster and/or Citrix pool.)

If both cluster metrics are between corresponding low and high thresholds, no action is taken; that is, no additional VMs are made available to IBM Spectrum Symphony and no VMs are removed.
If either cluster metric is over its High threshold value (either CPU or memory utilization), VM harvesting goes through all the physical hosts in the vCluster or resource pool retrieving host-level values for the utilization metrics. If a value is over the High threshold for the specific host, one IBM Spectrum Symphony compute host residing in a VM at this physical host is removed from the IBM Spectrum Symphony cluster by closing it. This sequence is repeated; that is, one VM is removed at each physical host where the utilization is over the High threshold, up to the pre-configured maximum number of VMs that can be removed during a scheduling cycle. As a result, EGO reclaims these hosts and the IBM Spectrum Symphony workload on these hosts is re-queued.
If both cluster metrics are under the corresponding Low threshold values, VM harvesting retrieves the unsatisfied demand from the IBM Spectrum Symphony applications' consumers. VM harvesting cycles through all the physical hosts in the vCluster or resource pool arranging the IBM Spectrum Symphony workload VMs in a host list in decreasing order of the physical host's utilization values. VM harvesting then opens one VM, which resides on the least loaded physical host, to make it available to IBM Spectrum Symphony. This sequence continues; that is, one VM is made available at each physical host where the CPU and memory utilization values are under the Low thresholds, up to the pre-configured maximum number of VM hosts, but not more than the initial unsatisfied demand requires.

Regardless of the comparison results, each time the IBM Spectrum Symphony application's demand for compute resources is satisfied, VM harvesting removes all VM hosts from IBM Spectrum Symphony that currently are not allocated to the applications' consumers. This cleanup operation prevents violation of utilization thresholds for non-IBM Spectrum Symphony virtual VMs as IBM Spectrum Symphony will not allocate and schedule any suddenly demanded workload to such hosts at any moment until the next scheduling cycle.

Personality management

Personality management involves maximizing the availability of VMs that match an application's requirements in an attempt to satisfy a consumer with the highest demand. For example, applications are often deployed in mixed clusters made up of resources running different operating systems. When an application has demand, its workload needs to be routed to resources with the appropriate OS. In this case, VM harvesting will provision the VMs that meet the operating system requirements of the application. This enables cluster resources to be more versatile and better equipped to handle diverse application requirements.

Scheduling policy

The VM harvesting scheduling policy attempts to balance the unsatisfied demands of consumers. The objective of the scheduling policy is to make VMs available that satisfy the consumer with the most demand.

For example, assume there are two consumers, A and B, configured to use resource groups resGroupA and resGroupB, respectively. Consumer A has a demand for 20 slots and consumer B has a demand for 10 slots. The maximum number of VMs to make available or remove for each scheduling cycle is configured to be 4. If VM harvesting decides it can make VMs available, it will open 4 VMs from resource group resGroupA because the demand for consumer A is more than the demand for consumer B. In each scheduling cycle, it will continue to make VMs available until either there are no VMs to open or the demand for consumer A is less than consumer B.

If VM harvesting decides it will remove VMs, it will remove VMs that belong to the most highly-loaded hypervisors; during each scheduling cycle, it will continue to do so until there are no VMs to remove.

Host-level policy

The scheduling policy can be enabled at the host level. This can be useful for cases where the VM software does not provide a load balancing mechanism such as Distributed Resource Scheduler (DRS). When the scheduling policy is enabled at the host level for a vCluster or pool, VM harvesting monitors the loading of each individual hypervisor inside the vCluster or pool to determine which VM should be opened or closed.

Data reporting

The "IS" service can collect resource information from a vCenter and IBM Spectrum Symphony, and dump it periodically into a file named harvesting_resourceinfo.soamdb under $EGO_CONFDIR/../../is/history. The data reporting feature is disabled by default. The following resource information is collected by the data reporting feature:

Field	Description
time	The GMT time that the record is written
resourceType	The resource type. Valid values are: vCenter vCluster hypervisor VM SymphonyHost
resourceName	Name of the resource.
vCenterName	Name of the vCenter that the resource belongs to.
vClusterName	Name of the vCluster to whic the resource belongs.
hypervisorName	Name of the hypervisor to which the resource belongs.
totalMemory	Total memory (MB) of the resource.
freeMemory	Total available memory (MB) of the resource.
nCores	Total cores of the resource.
cpuUsage	CPU usage of the resource (in percentage).
totalChild	Count of the children: For vCenter, it is the number of vClusters. For vCluster, it is the number of hypervisors. For hypervisor, it is the number of VMs. For VMs and IBM Spectrum Symphony hosts, it is 0.

To enable the data reporting feature, refer to Configuring data reporting for VM harvesting.