Actions by entity type

Turbonomic generates actions based on how entity types use or provide resources, and what each entity type supports.

The following tables show the actions that each entity type supports:

Application entity types

Entity type Supported actions
Business application

None

Turbonomic does not recommend actions for a Business Application, but it does recommend actions for the underlying Application Components and infrastructure. The Pending Actions chart for a Business Application lists these actions, thus providing visibility into the risks that have a direct impact on the Business Application's performance.

Business transaction

None

Turbonomic does not recommend actions for a Business Transaction, but it does recommend actions for the underlying Application Components and infrastructure. The Pending Actions chart for a Business Transaction lists these actions, thus providing visibility into the risks that have a direct impact on the Business Transaction's performance.

Service
  • For APM services:

    None

    Turbonomic does not recommend actions for services discovered through APM targets, but it does recommend actions for the underlying Application Components and nodes. The Pending Actions chart for services list these actions, thus providing visibility into the risks that have a direct impact on their performance.

  • For container platform services:

    Scale (through workload controllers)

    Turbonomic recommends actions to scale the replicas that back the container platform services. Set the scope to the associated Workload Controller to view and execute the actions.

    For details, see Workload Controller Scale Actions.

Application component

Resize

Resize the following resources to maintain performance:

  • Thread pool

    Turbonomic generates thread pool resize actions. These actions are recommend-only and can only be executed outside Turbonomic.

  • Connections

    Turbonomic uses connection data to generate memory resize actions for on-prem Database Servers.

  • Heap

    Turbonomic generates Heap resize actions if an Application Component provides Heap and Remaining GC Capacity, and the underlying VM or container provides VMem. These actions are recommend-only and can only be executed outside Turbonomic.

    Note:

    Remaining GC capacity is the measurement of Application Component uptime that is not spent on garbage collection (GC).

The resources that Turbonomic can resize depend on the processes that it discovers from your Applications and Databases targets. Refer to the topic for a specific target to see a list of resources that can be resized.

Container platform entity types

Entity type Supported actions
Service

Scale (through workload controllers)

Turbonomic recommends actions to scale the replicas that back the container platform services. Set the scope to the associated Workload Controller to view and execute the actions.

For details, see Workload Controller Scale Actions.

Container

Resize

Turbonomic generates container resize actions for Bare Pods where the workload has no controller.

Container spec

Resize (through workload controllers)

A container spec retains the historical utilization data of ephemeral containers. Turbonomic uses this data to make resize decisions that assure optimal utilization of resources. By default, all replicas of the same container for the same workload type resize consistently.

For details, see Workload Controller Resize Actions.

Namespace

Resize quota

Turbonomic treats quotas defined in a namespace as constraints when making resize decisions. If existing actions would exceed the namespace quotas, Turbonomic recommends actions to resize up the affected namespace quota.

Note that Turbonomic does not recommend actions to resize down a namespace quota. Such an action reduces the capacity that is already allocated to an application. The decision to resize down a namespace quota should include the application owner.

For details, see Namespace Actions.

Workload controller
  • Resize

    Actions associated with a workload controller resize container specs vertically to assure optimal utilization of resources. This is a natural representation of these actions because the parent controller's container specs for vCPU limits/requests and vMem limits/requests are modified. The workload controller then rolls out the changes in the running environment.

    For details, see Workload Controller Resize Actions.

    Resize actions for certain types of workloads may be blocked or set to recommend-only, which means that they are currently not executable in Turbonomic. These actions usually require a dependent action or an external configuration to be completed first. For example, a workload controller resize up action may be temporarily blocked if there is insufficient resources in the corresponding node or namespace. In this case, a node provision or namespace quota resize action must be completed first. For more information, see this topic.

  • Scale

    Actions associated with a workload controller scale replicas horizontally to maintain Service Level Objectives (SLOs) for your applications. This is a natural representation of these actions because the parent controller's number of replicas are modified. The workload controller then rolls out the changes in the running environment.

    For details, see Workload Controller Scale Actions.

Container pod
  • Move

    Move a pod that is controlled by a ReplicationController, ReplicaSet, or Deployment (through a ReplicaSet) to another node (VM) to address performance issues or improve infrastructure efficiency. For example, if a particular node is congested for CPU, you can move pods to a node with sufficient capacity. If a node is underutilized and is a candidate for suspension, you must first move the pods before you can safely suspend the node.

    For details, see Container Pod Move Actions.

  • Provision or suspend

    When recommending node provision or suspend actions, Turbonomic will also recommend provisioning pods (based on demand from DaemonSets) or suspending the related pods.

    For details, see Container Pod Provision and Suspension Actions.

Container platform cluster

None

Turbonomic does not recommend actions for a container platform cluster. Instead, it recommends actions for the containers, pods, nodes (VMs), and volumes in the cluster. Turbonomic shows all of these actions when you scope to a container platform cluster and view the Pending Actions chart.

Container platform node (VM)

A node (cloud or on-prem) is represented as a Virtual Machine entity in the supply chain.

Note:

For nodes in the public cloud, Turbonomic reports the cost savings or investments attached to these actions.

For details, see Node Actions.

Cloud infrastructure entity types

Entity Type Supported Actions
Virtual machine (cloud) For details about cloud VM actions, see the following topics:
Virtual machine spec
  • For AWS Auto Scaling groups:

    Stop and start (also known as 'parking' actions)

    Stop an Auto Scaling group for a given period of time to reduce your cloud expenses, and then start it at a later time.

    For details, see Parking: Stop or Start Cloud Resources.

  • For Azure Virtual Machine Scale Sets:

    Stop and start (also known as 'parking' actions)

    Stop a Virtual Machine Scale Set for a given period of time to reduce your cloud expenses, and then start it at a later time.

    For details, see Parking: Stop or Start Cloud Resources.

  • For Azure App Service plans:

    • Scale

      Scale Azure App Service plans to optimize app performance or reduce costs, while complying with business policies.

    • Delete

      Delete empty Azure App Service plans as a cost-saving measure. A plan is considered empty if it is not hosting any running apps.

    For details, see Virtual Machine Spec Actions.

App component spec

None

Turbonomic does not recommend actions for App Component Specs, but it does recommend actions for the underlying Virtual Machine Specs. For details, see Virtual Machine Spec Actions.

Database server (cloud)
  • For AWS RDS:

    • Stop and start (also known as 'parking' actions)

      Stop a Database Server for a given period of time to reduce your cloud expenses, and then start it at a later time.

    • Scale

      Scale compute and storage resources to optimize performance and costs.

    For details, see Cloud Database Server Actions and Parking: Stop or Start Cloud Resources.

  • For Azure SQL Managed Instances:

    Scale

    Change the Managed Instance to use a different instance type or tier to optimize performance and costs.

    For details, see Actions for SQL Managed Instances.

  • For Azure Cosmos DB Accounts:

    None

    Turbonomic does not recommend actions for a Cosmos DB account but it does recommend actions for the databases and document collections in the account.

Database (cloud)
  • Scale SQL database

    • DTU pricing model

      Scale DTU and storage resources to optimize performance and costs.

    • vCore pricing model

      Scale vCPU, vMem, IOPS, throughput and storage resources to optimize performance and costs.

    For details, see Scale Actions for SQL Databases.

  • Scale Cosmos DB database

    Scale request units (RUs) to optimize performance and costs.

    For details, see Scale Actions for Cosmos DB Databases.

  • Reconfigure Cosmos DB database

    Remove unused provisioned throughput to reduce costs.

    For details, see Reconfigure Actions for Cosmos DB Databases.

  • Delete Cosmos DB database

    Delete a database with provisioned throughput but without any underlying document collection (container) to reduce costs.

    For details, see Delete Actions for Cosmos DB Databases.

  • Suspend or stop dedicated SQL pool

    Suspend or stop a dedicated SQL pool (used in Azure Synapse Analytics) to reduce compute costs.

    • Turbonomic analysis generates suspend actions for idle pools.

      Note:

      Currently, Turbonomic analysis does not generate actions to start a suspended pool. You can start a suspended pool from the Parking page (see the next item) or from Azure.

      For details, see Suspend Actions for Dedicated SQL Pools.

    • You can use the Parking page to stop pools (running or idle), either on-demand or according to a schedule. Use the same page to start a stopped pool.

      For details, see Parking: Stop or Start Cloud Resources.

Data warehouse

Suspend

Suspend a Redshift provisioned cluster to reduce compute costs.

For details, see Suspend actions for Redshift provisioned clusters.

Document collection

Scale

Scale Request Units (RUs) to optimize performance and costs.

For details, see Document Collection Actions.

Volume (cloud)
  • Scale

    Scale attached volumes to optimize performance and costs.

  • Delete

    Delete unattached volumes as a cost-saving measure. Turbonomic generates an action immediately after discovering an unattached volume.

For details, see Cloud Volume Actions.

Zone

None

Turbonomic does not recommend actions for a cloud zone.

Region

None

Turbonomic does not recommend actions for a cloud region.

On-prem infrastructure entity types

Entity type Supported actions
Virtual machine (on-prem)
  • Resize

    Resize resource capacity, reservation, or limit to improve performance.

  • Resize PU or VP (IBM PowerVM)

    Resize PU (processing units) or VP (virtual processor) to optimize LPAR processing unit allocation and virtual processor capacity based on historical demand collected from the HMC.

  • Move

    Move a VM due to high resource utilization on VM or host, excess IOPS or latency in VStorage, workload placement violation, underutilized host (move VM before suspending host).

  • Reconfigure

    Change a VM's configuration to comply with a policy.

    For hypervisor targets, Turbonomic can reconfigure VMs that violate vCPU scaling policies. For details, see VCPU Scaling Controls.

For details, see On-prem VM Actions.

Volume (on-prem)
  • Move

    Move a VM's volume (virtual storage) due to excess utilization of the current datastore, or for more efficient utilization of datastores in the environment.

    Points to consider:

    • The default global policy includes a setting that directs Turbonomic to use relevant metrics when analyzing and recommending actions for volumes. For details, see Enable Analysis of On-prem Volumes.

    • Turbonomic will not recommend moving a volume to a datastore that is currently in maintenance mode. Any volume in that datastore should move to an active datastore (for example, via vMotion).

  • Reconfigure

    Reconfigure a VM's volume (virtual storage) to comply with placement policies.

Database server (on-prem)

Resize

Resize the following resources:

  • Connections

    Turbonomic uses connection data to generate memory resize actions for on-prem Database Servers.

  • Database memory (DBMem)

    Actions to resize database memory are driven by data on the Database Server, which is more accurate than data on the hosting VM. Turbonomic uses database memory and cache hit rate data to decide whether resize actions are necessary.

    A high cache hit rate value indicates efficiency. The optimal value is 100% for on-prem (self-hosted) Database Servers, and 90% for cloud Database Servers. When the cache hit rate reaches the optimal value, no action generates even if database memory utilization is high. If utilization is low, a resize down action generates.

    When the cache hit rate is less than the optimal value but database memory utilization remains low, no action generates. If utilization is high, a resize up action generates.

  • Transaction log

    Resize actions based on the transaction log resource depend on support for virtual storage in the underlying hypervisor technology.

    Currently, Turbonomic does not support resize actions for Oracle and Database Servers on the Hyper-V platform (due to the lack of API support for virtual storage).

Virtual datacenter

None

Turbonomic does not recommend actions for a virtual datacenter. Instead, it recommends actions for the entities that provide resources to the virtual datacenter.

Business user

Move

Move a business user between desktop pools to address:

  • Resource congestion on the image

    When utilization is consistently near capacity for image resources, Turbonomic can recommend moving a business user to a desktop pool that serves larger images.

  • Resource congestion on the desktop pool

    When utilization is consistently near capacity for the desktop pool, Turbonomic can recommend moving a business user to a desktop pool that has more available resources.

Note:

To support moves, you must configure placement policies that merge similarly configured desktop pools. For details, see Desktop Pool Placement Policies.

Desktop pool

None

Turbonomic does not recommend actions for a desktop pool. It recommends actions for the business users running active sessions in the pool.

View pod

None

Turbonomic does not recommend actions for a view pod. Instead, it recommends actions for the business users that are running active sessions.

Host
  • Start

    Start a suspended host when there is increased demand for physical resources.

  • Provision

    Provision a new host in the environment when there is increased demand for physical resources. Turbonomic can then move workloads to that host.

  • Suspend

    When physical resources are underutilized on a host, move existing workloads to other hosts and then suspend the host.

  • Reconfigure

    Turbonomic generates this action in response to changing demand for software licenses. For details, see License policy.

For details, see Host Actions.

Chassis

None

Turbonomic does not recommend actions for a chassis.

Datacenter

None

Turbonomic does not recommend actions for a datacenter. Instead, it recommends actions for the entities running in the datacenter.

Storage
  • Move

    For high utilization of physical storage, move datastore to a different disk array (aggregate).

  • Provision

    For high utilization of storage resources, provision a new datastore.

  • Resize

    Increase or decrease the datastore capacity.

  • Start

    For high utilization of storage resources, start a suspended datastore.

  • Suspend

    For low utilization of storage resources, move served VMs to other datastores and suspend this one.

  • Delete (datastore or volume)

    Delete a datastore or volume that has been suspended for a period of time.

  • Delete (unattached files)

    Delete a file on a datastore that has not been accessed or modified for a period of time.

For details, see Storage Actions.

Logical pool
  • Move

    For high utilization of physical storage, move the logical pool to a different disk array (aggregate).

  • Provision

    For high utilization of storage resources, provision a new logical pool.

  • Resize

    Increase or decrease the logical pool capacity.

  • Start

    For high utilization of storage resources, start a suspended logical pool.

  • Suspend

    For low utilization of storage resources, move served VMs to other logical pools and suspend this one.

Disk array
  • Provision

    For high utilization of the disk array’s storage, provision a new disk array. This action can only be executed outside Turbonomic.

  • Start

    For high utilization of disk array, start a suspended disk array. This action can only be executed outside Turbonomic.

  • Suspend

    For low utilization of the disk array’s storage, move VMs to other datastores and suspend volumes on the disk array. This action can only be executed outside Turbonomic.

  • Move

    (Only for NetApp Cluster-Mode) For high utilization of Storage Controller resources, Turbonomic can move an aggregate to another storage controller. The storage controllers must be running.

    For high IOPS or latency, a move is always off of the current disk array. All the volumes on a given disk array show the same IOPS and Latency, so moving to a volume on the same array would not fix these issues.

  • Move VM

    For high utilization of Storage on a volume, Turbonomic can move a VM to another volume. The new volume can be on the current disk array, on some other disk array, or on any other datastore.

    For high IOPS or latency, a move is always off of the current disk array. All the volumes on a given disk array show the same IOPS and Latency, so moving to a volume on the same array would not fix these issues.

  • Move datastore

    To balance utilization of disk array resources, Turbonomic can move a datastore to another array.

Storage controller

Provision

For high utilization of the storage controller’s CPU, provision a new storage controller, and then move disk arrays to it.

IO module

Suspend

For low utilization of net resources, move VMs to another host that provides compatible network connectivity and suspend this IO Module.

Switch

Resize

Resize PortChannel for a switch to increase bandwidth.