Working with migrate container workloads plan results

After the plan runs, you can view the results to see the impact of workload migration on the destination cluster. The results do not show data for the source cluster (for example, the cluster that currently hosts the workloads).

General guidelines

Familiarize yourself with these common terms that appear in the plan results:

A container pod represents the compute demand from a running pod.
A node (virtualized or bare metal) is represented as a VM.
Used (or Usage) values represent actual resource consumption. For example, a node that consumes 100 MB of memory has a used value of 100 MB.
Utilization values represent used/usage values against capacity. For example, a node that consumes 100 MB of memory against a total capacity of 500 MB has a utilization value of 20%.

Migrate container workloads summary

Table columns

Table columns shows the following information for the destination cluster:

Before migration

This column shows the state of the destination cluster before workload migration.
Lift & Shift

The Lift & Shift scenario migrates your container workloads based on the resources currently available in the destination cluster.
Optimized

The Optimized scenario identifies opportunities to optimize performance in the destination cluster. For example, after analyzing historical resource utilization, Turbonomic might recommend resizing limits and requests for containers (via the associated workload controllers) to maintain performance. If you were to migrate workloads based on the resources currently available in the destination cluster, then your applications could risk losing performance.

Table rows

Table rows show the following information for the destination cluster:

Row	Description
Workload controllers	Count of active Workload Controllers. This chart does not count "non-participating" entities in the real-time market, such as inactive Workload Controllers.
Container pods	Count of active (running) container pods.
Virtual machines	Count of active nodes (virtualized or bare metal). This chart does not count "non-participating" nodes in the real-time market, such as suspended nodes.
Pod density	Average number of pods per node. The 'Optimized' result shows if you can improve density by increasing the number of pods per node. For the total number of pods against the node capacity (maximum pods per node), see the Number of Consumers data in the following charts: Nodes (VMs) Optimized Improvements Container Platform Cluster Optimized Improvements
Cluster CPU capacity	Total CPU capacity for the cluster. The 'Optimized' result indicates how much CPU capacity will result in the optimal number of nodes required to run workloads.
Cluster CPU allocatable	Total amount of cluster CPU available for pod requests. The 'Optimized' result indicates how much of the allocatable CPU capacity will change if you provision or suspend nodes.
Cluster CPU request	Total CPU request capacity for the cluster.
Cluster CPU limit	Total CPU limit capacity for the cluster.
Cluster CPU overcommitment	(Only for containers with CPU limits) This indicates whether the CPU limits exceed the capacity of the underlying nodes. A value greater than 100% indicates overcommitment. Turbonomic manages cluster resources by actual utilization and limit rightsizing so that you can run more workloads with less risk. Turbonomic only calculates overcommitment in plans. The calculation can be expressed as: `Overcommitment = Sum of CPU limits for all containers / Sum of CPU capacity for all nodes`
Cluster memory capacity	Total memory capacity for the cluster. The 'Optimized' result indicates how much memory capacity will result in the optimal number of nodes required to run workloads.
Cluster memory allocatable	Total amount of cluster memory available for pod requests. The 'Optimized' result indicates how much of the allocatable memory capacity will change if you provision or suspend nodes.
Cluster memory request	Total memory request capacity for the cluster.
Cluster memory limit	Total memory limit capacity for the cluster.
Cluster memory overcommitment	(Only for containers with memory limits) This indicates whether the memory limits exceed the capacity of the underlying nodes. A value greater than 100% indicates overcommitment. Turbonomic manages cluster resources by actual utilization and limit rightsizing so that you can run more workloads with less risk. Turbonomic only calculates overcommitment in plans. The calculation can be expressed as: `Overcommitment = Sum of memory limits for all containers / Sum of memory capacity for all nodes`

Plan actions

Turbonomic shows separate tabs for Lift & Shift and Optimized migration actions. You can download the list of actions as a CSV file.

These tabs show the actions that you need to execute to achieve the plan results. For example, you might need to resize limits and requests for containers (via the associated Workload Controllers) to address performance issues. Or, you might need to move pods from one node to another to reduce congestion.

Smarter redistribution and workload rightsizing also drive actions, resulting in the need to provision node(s) based on application demand, or to defragment node resources to enable node suspension.

Turbonomic can recommend the following actions:

Entity	Lift & shift actions	Optimized actions
Workload controller	None	Resize container limits and requests See Workload Controller Resize Actions for additional details.
Namespace	None	Resize quotas (if container resize actions would exceed the namespace quotas)
Pod	Move Provision (if node provision is required) Reconfigure	Move Provision (if node provision is required) Suspend (if node suspension is required) Reconfigure
Node (VM)	Provision Move on-prem nodes	Provision Suspend Move on-prem nodes
Cloud volume	Scale	Scale
On-prem storage	Provision Suspend	Provision Suspend
On-prem host	Provision Suspend	Provision Suspend

Additional information:

Workload controller resize actions

When you expand an action on a Workload Controller, you will see charts that track VCPU and VMem utilization for the impacted container spec. With these charts, you can easily recognize the utilization trends that Turbonomic analyzed to make accurate resize decisions.

For more information about these charts, see Utilization Charts.

Executing several container resize actions can be very disruptive since pods need to restart with each resize. For replicas of the container scale groups related to a single Workload Controller, Turbonomic consolidates resize actions into one merged action to minimize disruptions. When a merged action has been executed (via the associated Workload Controller), all resizes for all related container specifications will be changed at the same time, and pods will restart once.
Pod constraints

A Migrate Container Workloads plan evaluates pod constraints on the source cluster when making placement decisions for pods. The plan enforces taints, tolerations, and nodeSelector specifications if there are matching constraints in the destination cluster. If these constraints cannot be achieved in the destination cluster, the plan ignores them to guarantee placement.

The plan always enforces affinity and anti-affinity constraints, which could result in unplaced pods in the destination cluster. If this happens, the plan generates reconfigure actions for the unplaced pods and shows a notification in the plan results.

Click Show Details to see the list of pods and the reasons for their non-placement. The charts in the plan results do not count these pods.

Savings

For a destination cluster in the public cloud, Turbonomic shows the savings you would realize if you execute the actions that the plan recommends. The results show separate charts for the Lift and Shift and Optimized scenarios, so you can compare the impact of actions on your cloud expenses.

For example, in both scenarios, the plan might recommend scaling volumes to new tiers to address performance issues. If these new tiers happen to be more cost-effective than the current tiers, then the actions are treated as cost-saving measures. For the optimized scenario, the plan might also recommend suspending certain nodes to increase infrastructure efficiency, which could introduce additional savings.

Note that application performance and infrastructure efficiency are the drivers of these actions, not cost optimization. Cost information is included to help you track your cloud expenses.

The charts show total monthly savings. Click Show All to view the actions with cost savings.

Note:

An empty chart indicates that no savings will be realized after you execute the recommended actions.

Investments

For a destination cluster in the public cloud, Turbonomic shows the costs you would incur if you execute the actions that the plan recommends. The results show separate charts for the Optimized and Lift and Shift scenarios, so you can compare the impact of actions on your cloud expenses.

For example, if some applications risk losing performance, the plan might recommend provisioning nodes to increase capacity. The charts show how node provision actions translate to an increase in expenditure. You can use cost information in the charts as you seek approval to execute these actions.

The charts show total monthly investments. Click Show All to view the actions that require investments.

Note:

An empty chart indicates that no investments are required to execute the recommended actions.

Nodes (VMs) optimized improvements

This chart compares the following before and after the plan:

Utilization of the following resources for all nodes:
- vMem
- vCPU
- vMem Request
- vCPU Request
Number of pods consuming resources against the maximum pod capacity for all the nodes

Use this chart to identify nodes that are candidates for suspension, or resources with unusual utilization. You can also use this chart to drill down to a specific resource. Click Show All for more details.

Namespace quotas optimized improvements

This chart shows pod utilization of resource quotas defined in namespaces. Resource quotas include:

CPU Limit Quota
Memory Limit Quota
CPU Request Quota
Memory Request Quota

The chart highlights utilization improvements as a result of namespace resizing.

For namespaces without defined quotas, utilization is 0 (zero).

Container platform cluster optimized improvements

This chart shows the following, assuming you execute all actions in the plan:

Changes to the utilization of cluster resources
Overcommitment values

Optimized improvements for hosts and storage

Use these charts if you ran the plan on an on-prem cluster. These charts show how the utilization of resources would change assuming you accept all of the actions that the plan recommends.

Downloading plan results

You can download the plan results shown in individual charts. Click the Show All button for a chart, and then the download button at the Details page.

Re-running the plan

You can run the plan again with the same or a different set of configuration settings. This runs the plan scenario against the market in its current state, so the results you see might be different, even if you did not change the configuration settings.

Use the toolbar for the Configuration section to change the configuration settings.

Note:

It is not possible to change the scope of the plan in the Plan Page. You must start over if you want a different scope. To start over, click the More options icon (), and then select New Plan.

When you are ready to re-run the plan, click Run Again.