On-prem VM policies

Automation workflow

For details about on-prem VM actions, see On-prem VM Actions.

* Turbonomic uses these settings, in conjunction with resize operational constraints, to set up tuned scaling for on-prem VMs.

You can use Action Scripts and third-party orchestrators (such as ServiceNow) for action orchestration.

Non disruptive mode

VM actions include the modifier, Enforce Non Disruptive Mode. When you enable this modifier, Turbonomic ensures that a resize action in Automatic or Manual mode will not require a reboot or any other disruption to the affected VM. If the action will disrupt the VM, Turbonomic posts the action in Recommend mode.

This setting has no effect on actions set to Recommend mode. Turbonomic will continue to post those actions for you to evaluate.

You can enforce non disruptive mode in the default VM policy, and then schedule action policies to automate resize actions during downtimes. Be aware that scheduled actions do not respect the enforced non disruptive mode — Scheduled resize actions will execute during the scheduled window even if they require a reboot. This is useful for setting up certain action behaviors, but you must be aware that enforced non disruptive mode has no effect on scheduled actions.

Shared-nothing migration

If you have enabled both storage and VM moves, Turbonomic can perform shared-nothing migrations, which move the VM and the stored VM files simultaneously. For example, assume a VM on a host also uses local storage on that host. In that case, Turbonomic can move that VM and move its data to a different datastore in a single action.

Currently, the following targets support shared-nothing migrations:

• vSphere, versions 5.1 or greater

• VMM for Hyper-V 2012 or later

Because of this feature's potential impact on performance, it is turned off by default. Turbonomic recommends enabling it only on VMs that need it. To do this, you must first set the action acceptance mode for VM and storage moves to either Manual or Automatic, and then enable the feature in a VM policy.

If a policy that enables this feature conflicts with a more conservative policy, the latter policy wins. For example, if compute move is set to Manual, storage move is set to Recommend, and shared-nothing migration is turned on, shared-nothing migration is in effect but remains in Recommended state.

Move enabled GPUs

Use this setting to construct a regex statement to identify which GPU models should support workload placement automation. By default, .*_(?:a16|t4).*$ is the regex pattern used for this field.

On-prem virtual machines with vGPU types that match the specified pattern are enabled for moves. Leave this field blank to disable moves for all VMs in the selected scope.

To enable vMotion for vGPU Virtual Machines, you must change the vgpu.hotmigrate.enabled advanced setting. For more information, see the VMware documentation.

Resize VStorage

The default setting disables resize actions. This is usually preferred because VStorage resize requires that you reformat the storage. The increment constant takes effect if you enable resizing.

vCPU scaling controls

For details, see VCPU Scaling Controls.

Resize increments

These increments specify how many units to add or subtract when resizing the given resource allocation for a VM.

For VMem, you should not set the increment value to be less than what is necessary for the VM to operate. If the VMem increment is too low, then it’s possible that Turbonomic would allocate insufficient VMem for the machine to operate. For a VM that is under utilized, Turbonomic will reduce VMem allocation by the increment amount, but it will not leave a VM with zero VMem. For example, if you set this to 1024, then Turbonomic cannot reduce the VMem to less than 1024 MB.

Rate of resize

When resizing resources for a VM, Turbonomic calculates the optimal values for VMem, VCPU, and V Storage, but it does not necessarily make a change to that value in one action. Turbonomic uses the Rate of Resize setting to determine how to make the change in a single action.

Using the Low (1) or Medium (2) value creates actions to bring the VM partially to the Desired State, resulting in more actions and possibly more total downtime. It is recommended to use the default value of High (3) to give the VM the correct resources all at once, which achieves the benefits of performance and efficiency in one action. Fewer actions results in less possible downtime.

• Low

  Change the value by one increment, only. For example, if the resize action calls for increasing VMem, and the increment is set at 1024, Turbonomic increases VMem by 1024 MB.

• Medium

  Change the value by an increment that is 1/4 of the difference between the current value and the optimal value. For example, if the current VMem is 2 GB and the optimal VMem is 10 GB, then Turbonomic will raise VMem to 4 GB (or as close to that as the increment constant will allow).

• High

  Change the value to be the optimal value. For example, if the current VMem is 2 GB and the optimal VMem is 8 GB, then Turbonomic will raise VMem to 8 GB (or as close to that as the increment constant will allow).

Consistent resizing

When you create a policy for a group of VMs and turn on Consistent Resizing, Turbonomic resizes all the group members to the same size, such that they all support the top utilization of each resource commodity in the group. For example, if you have deployed load balancing for a group, then all the VMs in the group should experience similar utilization. In that case, if one VM needs to be resized, then it makes sense to resize them all consistently.

Assume VM A shows top utilization of CPU, and VM B shows top utilization of memory. A resize action would result in all the VMs with CPU capacity to satisfy VM A, and memory capacity to satisfy VM B.

For an affected resize, the Actions List shows individual resize actions for each of the VMs in the group. To avoid the possibility of resizing VMs disruptively at the same time, you must create automation policies with non-overlapping schedules. For example, if VMs A and B are in the same consistent resizing group, create two policies that resize the VMs at different times of the day.

• For Policy 1, set the scope to a group containing VM A and enable resize automation between, say, 01:00 and 01:45.

• For Policy 2 set the scope to a group containing VM B and enable resize automation between 02:00 and 02:45.

When working with Consistent Resizing, consider these points:

• You should not mix VMs in a group that has a Consistent Resizing policy, with other groups that enable Consistent Resizing. One VM can be a member of more than one group. If one VM (or more) in a group with Consistent Resizing is also in another group that has Consistent Resizing, then both groups enforce Consistent Resizing together, for all their group members.

• For any group of VMs that enables Consistent Resizing, you should not mix the associated target technologies. For example, one group should not include VMs that are on Hyper-V and vCenter platforms.

• Charts that show actions and risks assign the same risk statement to all the affected VMs. This can seem confusing. For example, assume one VM needs to resize to address vCPU risk, and 9 other VMs are set to resize consistently with it. Then charts will state that 10 VMs need to resize to address vCPU risks.

Aggressiveness and observation periods

Turbonomic uses these settings to calculate utilization percentiles for vCPU, vMEM, IOPS, and VPs. It then recommends actions to improve utilization based on the observed values for a given time period.

• Aggressiveness

  Attribute	Default value
  Aggressiveness	75th Percentile

  When evaluating performance, Turbonomic considers resource utilization as a percentage of capacity. The utilization drives actions to scale the available capacity either up or down. To measure utilization, the analysis considers a given utilization percentile. For example, assume a 75th percentile. The percentile utilization is the highest value that 75% of the observed samples fall below. Compare that to average utilization, which is the average of all the observed samples.

  Using a percentile, Turbonomic can recommend more relevant actions. For scheduled policies, the more relevant actions will tend to remain viable when their execution is put off to a later time.

  For example, consider decisions to reduce the capacity for CPU on a VM. Without using a percentile, Turbonomic never resizes below the recognized peak utilization. For most VMs, there are moments when peak CPU reaches high levels, such as during reboots, patching, and other maintenance tasks. Assume utilization for a VM peaked at 100% just once. Without the benefit of a percentile, Turbonomic will not reduce allocated CPU for that VM.

  With Aggressiveness, instead of using the single highest utilization value, Turbonomic uses the percentile you set. For the above example, assume a single CPU burst to 100%, but for 75% of the samples CPU never exceeded 50%. If you set Aggressiveness to 75th Percentile, then Turbonomic can see this as an opportunity to reduce CPU allocation for the VM.

  In summary, a percentile evaluates the sustained resource utilization, and ignores bursts that occurred for a small portion of the samples.

  By default, Turbonomic uses samples from the last 30 days. Use the Max Observation Period setting to adjust the number of days. To ensure that there are enough samples to analyze and drive scaling actions, set the Min Observation Period.

• Max Observation Period

  Attribute	Default value
  Max Observation Period	Last 90 Days

  To refine the calculation of resource utilization percentiles, you can set the sample time to consider. Turbonomic uses historical data from up to the number of days that you specify as a sample period. If the database has fewer days' data then it uses all of the stored historical data.

  You can make the following settings:

  • Less Elastic – Last 90 Days

  • Recommended – Last 30 Days

  • More Elastic – Last 7 Days

  Turbonomic recommends an observation period of 30 days following the monthly workload maintenance cycle seen in many organizations. VMs typically peak during the maintenance window as patching and other maintenance tasks are carried out. A 30-day observation period means that Turbonomic can capture these peaks and increase the accuracy of its sizing recommendations.

  You can set the value to 7 days if workloads need to resize more often in response to performance changes. For workloads that cannot handle changes very often or have longer usage periods, you can set the value to 90 days.

• Min Observation Period

  Attribute	Default value
  Min Observation Period	None

  Especially for scheduled actions, it is important that resize calculations use enough historical data to generate actions that will remain viable even during a scheduled maintenance window. A maintenance window is usually set for "down" time, when utilization is low. If analysis uses enough historical data for an action, then the action is more likely to remain viable during the maintenance window.

  • More Elastic – None

  • Less Elastic – 7 Days

Placement policies

Turbonomic supports placement policies for on-prem VMs, as follows:

• You can create placement policies to enforce constraints for VM placements.

  For example, the VMs in a consumer group can only run on a host that is in the provider group. You can limit the number of consumers that can run on a single provider - for hosts in the provider group, only 2 instances of VMs in the consumer group can run on the same host. Or no more than the specified number of VMs can use the same storage device.

• For VMs that require paid licenses, you can create placement policies that set up certain hosts to be the VMs' preferred license providers. Turbonomic can then recommend consolidating VMs or reconfiguring hosts in response to changing demand for licenses.

For more information, see Creating Placement Policies.