IBM Turbonomic Glossary

An AWS Access Key is a credential that an AWS account root user or IAM user uses to sign programmatic requests to the AWS environment. When configuring AWS targets in Turbonomic, you can provide an access key for the target authentication.

For more information about AWS Access Keys, see https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html

Formerly "On Generation" (see Action Mode)

An Action Execution Schedule is a policy setting which determines when Turbonomic can execute specific generated actions. You can use it to defer the execution of generated actions to a non-critical time window.

For example, if mission-critical VMs experience memory bottlenecks during the week, you can defer the necessary memory resizes to the weekend. Even if the VMs have minimal utilization over the weekend, Turbonomic will recognize the need to resize, and execute the resize actions. Do not confuse Action Execution Schedule with Policy Schedule. (For more about the difference, see Policy Schedule.)

Action Mode is a policy setting that specifies the degree of automation for the actions that Turbonomic generates.

An action mode can direct Turbonomic to execute actions automatically, or only post them so you can do a review and decide which ones are safe to execute. See also Recommend (Action Mode), Manual (Action Mode), and Automated (Action Mode).

The Action Orchestrator is a component of the Turbonomic platform that tracks, translates, and starts the execution of actions in both the live and Plan markets. 

It also provides statistics about actions and action severity.

Active Directory (AD) is a directory service developed by Microsoft for Windows domain networks. It authenticates and authorizes all users and computers in a Windows domain type network. (https://en.wikipedia.org/wiki/Active_Directory) 

Turbonomic integrates AD servers and domains to authenticate AD users and groups, and assign them user roles.

 An Affinity Rule is a rule affecting placement of virtual machines on a host. You can implement affinity rules in Turbonomic via placement policies. Also, Turbonomic discovers vSphere Host DRS (Distributed Resource Scheduler) rules when DRS is enabled, and implements them as placement policies. Imported rules are enabled by default, but you can disable specific rules as necessary.

Turbonomic supports Place, Don’t Place, Merge, and License policies. The Place and Don’t Place policies implement Affinity and Anti-affinity rules, respectively. Affinity rules place groups of workloads together on specific hosts so you can easily audit the usage of those workloads. Anti-affinity rules keep specific workloads from running together on the same host to support HA and prevent a single point of failure at that host.

An Agent is a computer program installed  on a node or server to monitor the processes in the background. In most cases, Turbonomic monitors your environment without agents. It uses target APIs to discover applications, platforms, and infrastructure in your environment.

To monitor Kubernetes clusters, Turbonomic uses the Kubeturbo agent. When you install Kubeturbo on a node, it automatically registers itself as a target for the complete Cluster.

• High Percentile – Less aggressive, recommended for critical workloads that need maximum guaranteed performance at all times.
• Default Percentile – The recommended setting to achieve maximum performance and savings.
• Low Percentile – The most aggressive, recommended for non-production workloads that can stand higher resource utilization.

Amazon Web Services (AWS) is a public Cloud platform that provides compute, storage, and application services.

Turbonomic can manage AWS targets in your environment. Turbonomic is an AWS Partner Network Partner with Cloud Management Tools Competency status.

Ansible is an IT automation engine for cloud provisioning, configuration management, application deployment, intra-service orchestration and more. Based on YAML, it uses no agents or additional custom security infrastructure. Turbonomic uses Ansible Inventory and Play Books to discover VM configuration data and to build application topologies.

See Affinity Rule

An API  is a specification of supported interactions with a software component or resource. APIs make components reusable, and public APIs enable you to tap into functionality developed elsewhere over the web.

Turbonomic uses target APIs to discover applications, platforms, and infrastructure in your environment. The Turbonomic REST API exposes Turbonomic data and processing to remote access via HTTP.

Turbonomic documentation includes a REST API Guide to help you script interactions with the Turbonomic software and develop integrations between Turbonomic and other software applications. 

See also REST

AppDynamics is an Application Performance Management (APM) tool that  provides code-level visibility for on-prem and cloud applications. When you configure AppDynamics targets, Turbonomic provides a full-stack view of your environment, from application to physical hardware.

Turbonomic supports discovery of applications that are managed by AppDynamics, and can make  recommendations and take actions to both assure performance and drive efficiency with the full knowledge of the demands of each individual application experience.

An Application is a program or group of programs designed to perform specific processing for end users. The end users can be human or machine.

An application can be deployed as a single process running on a single host, or as a distributed set of processes running on one or more hosts. For distributed applications the Turbonomic Supply Chain can include a Business Application entity, with underlying Business Transaction, Service, and Application Component entities. The application is ultimately hosted on one or more VMs or Containers.

An Application Component is a software component, application code, or a unit of processing that consumes resources to enable it to perform its function for the Business Application. Examples of resources include memory or CPU.

Turbonomic can recommend actions to adjust the amount of resources available to Application Components.

Application Insights is an Application Performance Management (APM) target type that Turbonomic supports for Microsoft Azure environments.

According to the Microsoft Azure documentation, “Application Insights, a feature of Azure Monitor, is an extensible Application Performance Management (APM) service for developers and DevOps professionals.” (https://docs.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview -- “What is Application Insights?“)

Turbonomic supports workload management of the application infrastructure monitored by Application Insights, and provides a full-stack view of the infrastructure, from application to hosting server.

APM is the monitoring and management of performance and availability of software applications. APM strives to detect and diagnose complex application performance problems to maintain an expected level of service. (Dragich, Larry (4 April 2012). “The Anatomy of APM – 4 Foundational Elements to a Successful Strategy”. APM Digest.)

When Turbonomic discovers Business Applications and provides visibility into the full application stack. Turbonomic supports targets from such leading vendors as Dynatrace, New Relic, and AppInsights.

Application Resource Management (ARM) is a top-down, application-driven approach that continuously analyzes applications’ resource needs and generates fully automatable actions to ensure applications always get what they need to perform.

ARM is the Turbonomic mission to simultaneously optimize performance, compliance, and cost of your applications and infrastructure in real time. Turbonomic manages the complete application stack, automatically. Applications are continually resourced to perform while satisfying business constraints. APM runs 24/7/365 and scales with the largest, most complex environments.

ArangoDB is a graph database that runs in the Repository component of Turbonomic.

ArangoDB is a free and open-source native multi-modal database system. It natively works with graphs, documents, and full-text search in one database.

See also Repository.

Automated is an Action Mode that directs Turbonomic to automatically execute the actions that it generates.

Executed actions appear in the All Actions chart.

An Availability Set is a logical grouping in Microsoft Azure that isolates VM resources from each other to limit the impact of failure.  

Microsoft documentation says that with Availability Sets, “If a hardware or software failure happens, only a subset of your VMs are impacted.”
(Tutorial: Create and deploy highly available virtual machines with Azure PowerShell )

Turbonomic discovers Azure Availability Sets. For each set, it creates a policy that identifies compute tiers to exclude from that set.

Azure is a public Cloud platform created by Microsoft that provides compute, storage, and application services.

Turbonomic can manage Azure targets in your environment. Turbonomic holds Co-Sell Ready status in the  Microsoft One Commercial Partner program for its expertise in Azure.

Ballooning is a technique for VMware ESXi hypervisors to reclaim memory from virtual machines that they host. For VMware environments, Turbonomic discovers utilization of ballooning and considers ballooning in its analysis.

On the host, a balloon driver runs in the VM guest OS. When the host needs more memory, it can “inflate” the balloon on the VM to claim physical pages on the guest OS. The VM cannot use that memory, which leaves it available for the host to allocate to other consumers. The host drives ballooning when it is low on memory. If the host is in a healthy state, you should not see ballooning on the hosted VMs.

Bring Your Own License (BYOL) is a licensing model that lets corporate customers use their existing licenses flexibly, on-premise or in the cloud, without additional fees. Under this model, the customer remains responsible for managing these licenses, including renewals. For migrations from on-prem to the cloud, you can set BYOL in the plan configuration.

If you enable BYOL, Turbonomic assumes that you are paying for the OS license, and will not include the license cost in the plan results. If you do not enable BYOL, Turbonomic gets the license cost from the service provider (when it can) and includes that cost in the plan results.

For network environments that support buffered switch ports (Arista networks), this resource measures utilization of a port buffer. For example, if a host connects to the network through port 1 on a switch, and that port has enough traffic to cause packet buffering, this resource will show utilization.

A Business Application is a logical grouping of application entities and nodes that work together to compose a complete application as end users would view it.

Turbonomic users can monitor overall performance, make resourcing decisions, and set policies in the context of their Business Applications.

A Business Transaction is a logical grouping of underlying elements in the Supply Chain of the Application View in Turbonomic. These elements, which should represent all elements that fulfill a user-initiated request, could include Services, Applications Components, Database Servers, Containers, and Virtual Machines. A Business Transaction can also be used to represent a part of a Business Application and how that application is structured in your environment. 

The performance of a Business Transaction has a direct impact on user experience. You can use Business Transactions to monitor performance as experienced by your end users.

[Also known as Consumer] A Buyer is an entity in your environment that consumes resources from another entity, such as a Virtual Machine buying memory resources from a Host.

A Chart is an element of a graphical user interface that displays information or provides a specific way for a user to interact with the operating system or an application. 

Turbonomic displays information about your environment in various charts. You can edit and resize existing charts, as well as change the display order of them in dashboards. You can also add new charts to scoped views and dashboards.

Turbonomic organizes charts in the widget gallery under information categories: Actions and Impact, Status and Details, Cloud, and On-Prem. Format options -- such as table, bar chart, or ring chart -- vary in each of the four categories.

See also Widget

See Microservices

 A computer cluster is a group of two or more computers, or hosts, that are connected in a network and run in parallel to complete individual tasks. Turbonomic discovers clusters in your environment, and represents them in the Supply Chain. You can use clusters to specify scope for your Turbonomic session, for plans, for policies, and for charts.

In Turbonomic, you can configure placement policies that merge clusters. Turbonomic can use a Merge placement policy to move workloads across cluster boundaries. This creates a Supercluster.

See Buyer

A Container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computer environment to another (Docker website). The benefits include quick delivery and feedback and lower release risk. 

Turbonomic discovers Containers through Kube-Turbo targets that run in your Kubernetes cluster (see also Container Pod, Container Spec, Workload Controller, and Namespace).

In Kubernetes, controllers are control loops that watch the state of your cluster, then make or request changes where needed. Each controller tries to move the current cluster state closer to the desired state. (Kubernetes Documentation: https://kubernetes.io/docs/concepts/architecture/controller/)

In Turbonomic on-prem environments, CPU (Central Processing Unit) is the measure of processing capacity on a host. CPU is typically expressed on the host as the number of cores, with a given processing speed. Turbonomic measures allocated CPU capacity and utilized CPU in hertz of processing power (GHz or MHz). 

Turbonomic Data Cloud is a data service that integrates directly with Turbonomic to pull data about your Applications, Container Orchestration, Hypervisors, Storage, and Cloud Service Providers and give you the means to show and share how Turbonomic is currently assuring application performance.

For more information, see the Data Cloud documentation at 

The Data Exporter is a reporting capability that customers can use to feed reporting data to an external system. By using Data Exporter, valuable Turbonomic insights can be visualized with reporting solutions that customers already have in their environments.

The Data Exporter is a component that extracts reporting data from the core Turbonomic platform, transforms the data into JSON, and regularly publishes that data to a Kafka topic.

A Data Transfer Object (DTO) is an object that is used to encapsulate data and send it from one subsystem of Turbonomic to another. The API uses DTOs to send and receive REST payloads. For example, a DTO can represent the list of actions for a given entity. Turbonomic uses Kafka software to communicate DTOs between its platform components.

The memory in use by the database, as a percentage of the allocated capacity. Database configuration determines the capacity for this resource. Note that for databases, Turbonomic uses this resource to drive actions, instead of the VMem on the hosting VM. This means that actions are driven by the actual memory consumption on the database.

The Desired State is the state of your environment that assures application performance while achieving efficient use of resources and complying with business rules and constraints.

Instead of responding after a threshold is crossed, Turbonomic analyzes operating conditions and constantly recommends actions to keep the entire environment within the desired state.

You can measure performance as a function of delay, in which zero delay gives the ideal Quality of Service (QoS) for a given service. You can measure efficiency as a function where 100% utilization of a resource is the ideal. You can plot the relationship between delay and utilization as a curve. Up to a point, as you increase utilization, the increase in delay is slight. There comes a point on the curve where a slight increase in utilization results in an unacceptable increase in delay. On the other hand, there is a point in the curve where a reduction in utilization doesn’t yield a meaningful increase in QoS. The desired state lies within these points on the curve. 

DRS is the VMware vSphere utility that “provides resource management capabilities like load balancing and virtual machine (VM) placement” on a cluster of ESXI hosts. (Understanding vSphere DRS Performance, p.4).

Turbonomic discovers DRS rules in your environment and generates Placement Policies that respect the given constraints.

Dynatrace is a platform that uses artificial intelligence to deliver application performance monitoring (APM), artificial intelligence for operations (AIOps), IT infrastructure monitoring, digital experience management (DEM), and digital business analytics capabilities.

Turbonomic supports discovery of applications that are managed by the Dynatrace platform, and can make recommendations and take actions to both assure performance and drive efficiency with the full knowledge of the demands of each individual application experience.

Amazon Elastic Block Store (EBS) is an easy to use, high performance block storage service designed for use with Amazon Elastic Compute Cloud (EC2) for both throughput and transaction intensive workloads at any scale (Amazon website).

For AWS environments, Turbonomic discovers storage capacity and recognizes whether it is ephemeral “instance” storage or persistent EBS storage. For EBS storage, Turbonomic can recommend and execute storage resize actions.

A Fabric is a service that unites compute, network and storage access into a cohesive system. When you connect Turbonomic to fabric targets, it monitors the performance and resource consumption of the fabric entities to assure application performance while also utilizing resources as efficiently as possible.

Once connected, Turbonomic discovers the blades that host the VMs, the chassis and datastores that provide resources to the blades, the IO modules and fabric interconnects that provide network resources, and the virtual datastores that provide storage resources to the VMs.

As part of this process, Turbonomic stitches information from the fabric target and the associated hypervisor targets together to support Application Resource Management (ARM).  With this support, it provides deeper insight into the state of the hardware, the applications, and the VM’s running on the hypervisor-stitched blades. Combined with other targets, this information supports a top-down, application-driven approach to managing your environment.

Flow0 -- InProvider Flow is a measurement of network flow within a single provider, e.g.,, the network flow between VMs that are hosted by the same physical machine. This measures network flow between consumers that are on the same set of closely connected providers. Charts show the percentage of capacity that is utilized. 

Note that Turbonomic assumes an unlimited supply of InProvider Flow because this flow does not go across the physical network

(6.4 version family only)

Flow1-- InDPOD Flow is a measurement of network flow that is local to the given DPOD. This measures network flow between consumers that are on the same set of closely connected providers. Charts show the percentage of capacity that is utilized.

(6.4 version family only)

Flow2 -- CrossDPOD Flow is a measurement of network flow that is between different DPODs. This measures network flow between consumers that are on different sets of closely connected providers. Charts show the percentage of capacity that is utilized.

(6.4 version family only)

See Wasted Storage

Grafana is an analytics platform for creating and sharing dashboards to visualize and understand metrics.

The Turbonomic Embedded Reports feature uses Grafana to display its data in dashboards.

Heap is the measurement of heap capacity allocated for an Application Component.

In Turbonomic charts, Heap shows the percentage of that capacity that Application Components use.

Hot-Add refers to the ability to add CPU and/or Memory without requiring rebooting. 

This is supported by ESX and Hyper-V hypervisors, and by certain versions of Windows and Linux. 

Turbonomic automatically detects and groups (Virtual Machines) VMs in which both the guest Operating System (OS) and hypervisor support Hot-Add.

A Hypervisor is a service that creates and runs virtual machines (VMs), providing them compute and storage resources. The hypervisor treats on-prem resources such as CPU, memory, and storage as a pool that can be easily reallocated between existing guests or to new virtual machines. 

When you connect Turbonomic to hypervisor targets, it recommends placement and resize actions for VMs and the underlying infrastructure.

Identity and Access Management (IAM) is a term referring to how enterprise IT defines and manages the roles and access privileges of individual network users (customers or employees) and the circumstances in which these users are granted (or denied)  privileges. IAM systems provide administrators with the tools and technologies to change a user’s role, track user activities, create reports on those activities, and enforce policies on an ongoing basis. 

Turbonomic supports IAM roles to authorize access to AWS targets.Turbonomic integrates with such IAM services as AWS IAM to create and manage AWS users and use permissions to control their access to AWS resources.

An IdP (Identity Provider, sometimes IDP) is a system that creates, maintains, and manages identify information and provides authentication services for multiple service providers.  A common use of an IdP is for Single Sign-On (SSO). The service provider does not have to maintain account information because the IdP does so, which represents a cost saving for service providers. You can configure SSO for Turbonomic using any SAML 2.0-compliant SSO IdP.

Information Technology Service Management (ITSM)  is a set of workflows and tools to develop, deliver, and manage IT services. ITSM is used to handle incidents, service requests, problems, and changes—all of which are typically linked through an ITSM platform, such as ServiceNow. (https://crossfuze.com/servicenow/what-is-servicenow/itsm/)

Turbonomic integrates with ServiceNow so actions it generates can be recorded, approved, and tracked in ServiceNow work flows. Further, Turbonomic users can create schedules for executing approved actions during user-defined maintenance windows.

See also ServiceNow and Orchestration.

Instana is an IBM platform that delivers AI-powered enterprise observability and application-performance monitoring. It automatically discovers, maps, and monitors all hosts and applications wherever they are running. 

Starting with version 8.2.2, Turbonomic supports the Instana platform as an application target. For information about adding Instana targets, see the Turbonomic Target Configuration Guide.

Cisco Intersight is a cloud operations platform that delivers intelligent visualization, optimization, and orchestration for applications and infrastructure across your hybrid environment. 

Intersight users can get a license to use IWO within Intersight. IWO is a version of the Turbonomic platform that is specially designed to integrate with Intersight.

Cisco Intersight Assist helps you add endpoint devices to Cisco Intersight.  A datacenter could have multiple devices that do not connect directly with Cisco Intersight. Any device that is supported by Cisco Intersight, but does not connect directly with it, will need a connection mechanism. Cisco Intersight Assist provides that connection mechanism, and helps you add devices into Cisco Intersight.

IWO (Intersight Workload Optimizer) is a version of the Turbonomic platform that is specially designed to run within  Cisco Intersight. IWO integrates the Turbonomic ARM solution so that Intersight users can claim targets in their environment, take advantage of Turbonomic analysis, and execute actions to assure performance and efficiency.

IOPS is a common performance measurement for computer storage devices, such as hard disk drives (HDD), solid state drives (SSD), and storage area networks (SAN). It refers to the maximum number of reads and writes to non-contiguous storage locations. You can set IOPS capacity and utilization constraints in Turbonomic policies.

For cloud storage, Turbonomic considers IOPS utilization to drive storage scaling actions. For on-prem storage, IOPS capacity for a disk array takes precedence. Datastores that are members of a disk array always have the IOPS capacity that is set to the disk array.

For hyperconverged infrastructure, you can set an effective IOPS capacity for the datastores on the hyperconverged host. Turbonomic uses the value that you set to provide an estimate of effective IOPS capacity for each host in the cluster.

An ISO is an electronic file that contains the identical content of an optical disc, including the folder and file hierarchy. Using an .ISO file extension, ISO images are created to distribute the disc’s data over a network in order to burn a CD or DVD at the destination computer.

In Turbonomic, these images can be reported as wasted storage, which can throw off reports. You can avoid this by updating the Default Storage Policy Storage Settings to ignore these files.

The method for updating Turbonomic offline is via an ISO.

ITIL is a best-practice framework for facilitating the delivery and management of IT services. Turbonomic integrates with software based on ITIL frameworks, such as ServiceNow. 

The ITIL framework is delivered in five publications covering various parts and stages of the IT service lifecycle. It was initially developed by the UK Central Computer and Telecommunications Agency (CCTA) in the 1980s. Since 2013, it has been owned by the UK Cabinet Office and Capita in a joint venture called Axelos, which controls licensing.

Kafka is a component of the Turbonomic platform that runs the Kafka stream-processing service. The Kafka service is an open-source, stream-processing software platform developed by Apache to handle real-time data feeds, integration, and analytics. Kafka is the bus over which Turbonomic communicates Data Transfer Object (DTO) data between its platform components.

Latency is the time it takes for a storage device to reply to a request for data. Charts show the latency experienced by all VMs and hosts that access a given datastore. 

In Turbonomic, latency is expressed as a commodity that can be bought and sold. For a given datastore, there is no real capacity for Latency, but Turbonomic assigns a default storage latency capacity of 100ms.

A license is a file that you install on a Turbonomic instance to gain access to Turbonomic features. 

Under the Settings View, the license summary displays license details such as total workloads licensed, workloads in use, and the currently activated features.

If you exceed your workload count, Turbonomic will continue to manage your environment, but you will not be able to add new targets or upgrade your instance. If your license expires, Turbonomic will continue to monitor your environment, but you cannot execute recommended actions.

For legal information and resources, see https://www.turbonomic.com/company/legal/

Manual is an Action Mode that directs Turbonomic to post the actions that it generates and gives you the option of executing them via the Turbonomic user interface.

Turbonomic posts the generated actions in the Pending Actions chart.

MariaDB is an open-source relational database provided by MariaDB.org that Turbonomic uses for persistent storage of historic data. By default, Turbonomic includes MariaDB in the Open Virtualization Appliance (OVA) installation package.

The Turbonomic Market is an abstraction that represents the datacenter as buyers and sellers in a supply chain. Each entity (such as physical machines, virtual machines, storage device, volume, application component) in the environment is a buyer or seller.  The Turbonomic Supply Chain is a graphical display of the buyer and seller relationships. 

Turbonomic uses Virtual Currency to give a budget to buyers and assign cost to resources. This virtual currency assigns value across all tiers of your environment, making it possible to compare the cost of application transactions with the cost of space on a disk or physical space in a datacenter.

[Also called Cloud-Native] Microservice architecture  is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates  a well-defined lightweight mechanism to serve a business goal. 

Starting in Version 7.0, Turbonomic has been architected as a microservice. 

A Namespace in computer science (sometimes also called a name scope) is an abstract container or environment created to hold a logical grouping of unique identifiers or symbols (i.e., names). An identifier defined in a namespace is associated only with that namespace.(Wikipedia: https://en.wikipedia.org/wiki/Namespace#:~:text=A%20namespace%20in%20computer%20science,associated%20only%20with%20that%20namespace.)

A Kubernetes Namespace is a logical pool of resources in a Kubernetes environment that manages workloads based on specific requirements or business needs. For example, administrators can pool resources for different organizations within the enterprise and assign different policies to each pool.

A Namespace Entity is the Turbonomic Supply Chain entity that represents a Kubernetes Namespace. See also Namespace (Kubernetes). 

Turbonomic treats quotas defined in namespaces as constraints when making sizing decisions for containers. When you scope to a Namespace Entity in the supply chain, the Capacity and Usage chart shows Capacity values as namespace quotas.

The Turbonomic Navigation Bar is a menu of key Turbonomic pages and other resources including notifications (from the Notification Center), the Green Circle, Help, and Feedback. 

The Navigation Bar appears on the left side of the Turbonomic user interface.

New Relic One is an observability platform built to help engineers create software. It is designed to instrument, analyze, troubleshoot, and optimize your entire software stack.

Turbonomic supports discovery of the application infrastructure monitored by New Relic, and can make recommendations and take actions to both assure performance and drive efficiency with the full knowledge of the demands of each individual application experience.

For a Reserved Instance (RI) in AWS environments, nfu is a measure of RI capacity that you can use to compare or combine that capacity for different template families. For AWS environments, Turbonomic measures RI utilization and coverage in terms of nfu.

Measuring by nfu gives a common measure for RI capacity across different instance families.  For example, assume ts_small factors to 1 nfu, while ts_large factors to 4 nfu. If you reserve one small and one large workload, your RI consumption is 5 nfu.

See also RI Ratio for Azure environments

A NIC (Network Interface Card) provides a dedicated network connection to the computer it’s installed on.  Without it, a computer could not connect to a network. It can be used in both wired and wireless communications, providing both a physical layer and data link layer device. 

When scaling cloud workloads, Turbonomic uses maximum supported NICs as a property of an instance type, and recommends the cheapest instance type that will meet a workload’s demand.

Non-disruptive Mode is a policy setting for VMs that prevents actions that require a reboot or introduce disruptions from executing automatically.

Turbonomic posts such actions in Manual (Action Mode), so you can defer their execution to a non-critical time window.

The Notification Center is the location in the user interface where Turbonomic informs you about problems affecting its functionality. This can include issues with VMware Tools, target connectivity, or other similar problems. 

You can find the Notification Center in the lower part of the Navigation Bar. Issues with your environment are not reported here.

For Turbonomic analysis, Observation Period is the time span of sampling for the data that is used to calculate utilization percentiles. You can set a Maximum Observation Period and a Minimum Observation Period.

The observation period impacts the analysis that Turbonomic uses to generate actions. A shorter period means analysis uses fewer data points to calculate utilization percentiles. This results in more dynamic, elastic resizing, while a longer period results in more stable or less elastic resizing.

See also Aggressiveness.

The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection (https://swagger.io/specification/). 

The Turbonomic API is implemented using OpenAPI, and it uses Swagger as one way to deliver API documentation.

OVA is a file that contains a compressed, installable version of a virtual machine. One of the methods for deploying Turbonomic is via an OVA. When you open an OVA, it extracts the virtual machine (VM) and imports it into your datacenter. The Virtual Machine contains a complete instance of the Turbonomic platform.

(See also MariaDB)

See Aggressiveness

A Plan Market is a snapshot of the real-time market that you can create in Turbonomic  to simulate “what-if” scenarios against your environment. It starts with the same entities, utilization levels, placement constraints and analysis settings as the real-time market has.

To configure the plan, you can modify the plan scope, change policies and constraints, and add or remove workloads. When plans run, they generate and execute actions. The plan stops when there are no further actions to take. 

Turbonomic displays the results at the end of the analysis. Actions in the Plan Market have no effect on the real-time market. 

A Policy Schedule is a setting which makes the policy active only at designated times. This sets a window of time when the policy takes effect.

When the policy is in effect, Turbonomic uses the policy settings in its analysis, and can recommend or automatically execute actions as they are generated. When the policy is not in effect, it is the same as not having the policy at all.

Do not confuse Policy Schedule with Action Execution Schedule. The Policy Schedule sets when the policy takes effect, and an Action Execution Schedule sets when Turbonomic can execute a given action. For example, you can set a policy that automatically resizes or starts VMs for the entire month of December, in anticipation of an increase in demand. Within this same policy, you can set the resize execution schedule to Monday, from midnight to 7:00 AM, when demand is expected to be minimal.

Polling is an action taken to collect data. Turbonomic polls targets periodically to collect data on capacity, average utilization, and peak utilization.

Power is a measure of the energy that is consumed by a physical device.

Price is an indication of utilization or the value of a resource; high utilization increases the price. In on-prem environments, price is based on congestion, and resource prices grow asymptotically with percent utilization. In the Cloud, pricing is based on actual dollar cost.

The price that a seller charges for a resource changes according to the seller’s supply. As demand increases, prices increase. As prices change, buyers and sellers react. Buyers are free to look for other sellers that offer a better price, and sellers can duplicate themselves (open new storefronts) to meet increasing demand. 

Turbonomic uses its Economic Scheduling Engine to analyze the market and make these decisions. The effect is an invisible hand that dynamically guides your IT infrastructure to the optimal use of resources.

See Seller

Prometheus is an open-source systems monitoring and alerting toolkit.  Turbonomic can discover Prometheus targets using Prometurbo. 

Find details for deploying Prometurbo in Github at https://github.com/turbonomic/prometurbo.

Prometurbo is a Turbonomic probe that connects to Prometheus servers to collect application metrics and pass them to Turbonomic. 

Find details for deploying Prometurbo in Github at https://github.com/turbonomic/prometurbo.

Ready Queue is the percentage of time that there is work to be done for VMs, but no physical CPU (Central Processing Unit) available on which to do it (i.e., all host CPUs are busy serving other VMs). 

So, if you have 5 VMs with 4 VCPUs, and they’re on a 16 CPU host, that means that no more than 4 VMs can run a process at the same time.  One of those VMs has to wait in a ready queue.  

It is an on-prem commodity in the Turbonomic market, meaning it can be bought and sold. 

Recommend is an Action Mode that directs Turbonomic to post only the actions that it generates, so you can review them and then execute the ones that are safe to execute outside the Turbonomic user interface (for example, from the given hypervisor).

Turbonomic posts the generated actions in the Pending Actions chart.

A Regular Expression (Regex) is a string of letters and symbols (sometimes numbers) that defines a search pattern. 

Turbonomic supports Regular Expressions to define groups and filter Search results.

Remaining GC Capacity is the percentage of CPU time not spent on garbage collection (GC).

Turbonomic uses this metric in conjunction with Heap Utilization when making scaling decisions for Application Component entities.

The Repository is component of the Turbonomic platform that stores source topology (from the Topology processor) and projected topology (from the Market), as well as handles Supply Chain queries.

The data for the Repository component is stored in a graph database called ArangoDB.

A Reserved Instance (RI) is a reservation of cloud resources and capacity purchased at a set price for a given time period. Unlike on-demand pricing, when you purchase a reservation, you commit to paying for all of the hours of the contract’s term. As a benefit, the hourly rate is lowered significantly. 

Turbonomic can help determine how many RI’s to purchase, if any. It can also optimize utilization of the RI inventory, assuring the best RI coverage and a good return on your RI investment.

Pricing is determined by the specific cloud provider. Cloud providers use their own factors to measure RI capacity so you can combine that capacity for different template families. See Normalized Factor Unit (nfu) and RI Ratio

Response Time is the measure of time between request and response on an Application Component entity, measured in ms. For Turbonomic analysis, you set the response time capacity in Application Component policies.

REST is an acronym for REpresentational State Transfer. It is an architectural style for distributed hypermedia systems, and was first presented by Roy Fielding in 2000.  

Turbonomic exposes its functions and capabilities via the Turbonomic REST API.

Return on Investment (ROI) is the calculation an entity makes in each Turbonomic market cycle to decide what action, if any, it wants to take.  ROI equals Revenue divided by Expenses.

For hosts, If ROI is less than 1, the host will remain the same or suspend (after all Virtual Machines move off it). If ROI equals more than 1, the host is considered to be profitable, and might decide to clone itself.

For Virtual Machines (VMs), if ROI equals less than 1, the VM is considered to be unprofitable, and might downsize. If it equals more than 1, the VM is considered to be profitable and might decide to upsize.

RHEL (Red Hat Enterprise Linux) is an open-source operating system that supports technologies for automation, cloud, containers, middleware, storage, application development, micro-services, virtualization, management, and more. Turbonomic can discover and  manage RHEL workloads, and you can deploy Turbonomic on RHEL platforms.

Turbonomic supports management of RHEL workloads in the real-time market and in plans, including Migrate To Cloud plans.

SaaS is a software distribution model in which a service provider hosts applications for customers and makes them available to these customers via the internet.

Turbonomic delivers a fully managed SaaS edition of its platform. This edition runs on Tier-1 data centers in the Cloud, with one instance per customer.

SAML (Security Assertion Markup Language) is an XML-based open standard for transferring identity data between two parties -- an IdP (Identity Provider) and a Service Provider (SP). SAML is often used to implement SSO because it allows users to sign in one time (to the IdP) and access multiple service providers. Turbonomic supports Single Sign-On (SSO) using any SAML 2.0-compliant SSO IdP (Identity Provider).

[Also known as Producer] A Seller is an entity in your environment that provides resources to another entity, such as a Host selling CPU resources to a Virtual Machine. 

 In the Turbonomic Supply Chain, a Service is a measurable function that is part of an internal or user-initiated request, such as a request to update inventory. A service can consume from Application Components, Containers and Container Pods, VMs, and Database Servers. Turbonomic can discover Services through APM or Kubernetes targets. 

Service performance is key to understanding application performance, but it only indirectly affects user experience.

A Service Provider (SP) is an organization that provides a network, storage, or processing service. Different types of such providers include Internet Service Providers (ISP), Application Service Providers (ASP) Storage Service Providers (SSP) and content providers.

ServiceNow is a cloud-based company that provides software-as-a-service (SaaS) to manage technical workflows. Many Turbonomic enterprise customers use ServiceNow to manage incidents, service requests, and Change Requests (CRs).

Turbonomic integrates with ServiceNow to audit actions and create CRs for specific actions. Once an action is tracked in a CR, it can be approved, scheduled, and recorded in ServiceNow, and executed in Turbonomic on demand or on schedule.

See also Information Technology Service Management (ITSM) and Orchestration

Shared-Nothing Migration is a VM move to a host and to a storage all in one action.  This is necessary when the new host for the VM cannot access the storage that supports the VM. For example, assume a VM on a host also uses local storage on that host. 

Turbonomic can move that VM to a different host and move its data to a different datastore in a single action.

Single Sign-On (SSO) is an authentication process that allows a user to log in with a single ID and password to any of several related, yet independent, software systems. True single sign-on allows the user to log in once and access services without re-entering authentication factors. You can configure SSO for Turbonomic using any SAML 2.0-compliant SSO IdP (Identity Provider).

When SSO is enabled, Turbonomic only permits logins via the SSO IdP. Whenever you navigate to your Turbonomic installation, it redirects you to the SSO Identity Provider (IdP) for authentication before displaying the Turbonomic user interface. Before you enable SSO for your Turbonomic installation, you must configure at least one SSO user with Turbonomic Administrator privileges. If you do not, once you enable SSO, you will not be able to configure any SSO users in Turbonomic.

SLES (SUSE Linux Enterprise Server) is an open-source operating system developed by the SUSE organization. It is designed for workload management and optimization at the enterprise level on mainframes, servers, workstations and desktop computers. Turbonomic can discover and manage RHEL workloads, and the Turbonomic OVA is delivered as a SLES platform.

Turbonomic supports management of SLES workloads in the real-time market and in plans, including Migrate To Cloud plans. 

SLO (Service Level Objective) is a specific metric, such as maximum number of transactions per second or maximum acceptable response time, within a Service Level Agreement. Failure to meet the SLO could result in a penalty for the service provider, such as partial refund of fees or use of the service for additional time without additional charge.

IBM Turbonomic actively supports meeting Business Application SLOs. To evaluate the performance of your applications and Database Servers, set Response Time or Transaction SLOs as an operational constraint in policies. For applications, you can set the SLO at the Business Application, Business Transaction, Service, or Application Component level. In Kubernetes environments, SLOs defined in a Service policy override any SLOs set in the associated Application Component to prevent conflicts.

No Turbonomic actions would cause failure to meet SLO levels.

Snowflake is a SaaS product that provides data warehouse services. The Turbonomic Data Exporter can stream data to Snowflake, and customers can use Snowflake to visualize that data and gain insights into their virtual environments. 

SPECis a non-profit corporation formed to establish and maintain standardized benchmarks and tools to evaluate performance and energy efficiency for computing systems.  When creating Host templates in Turbonomic, you can choose from a catalog of CPU capacity. To build this catalog, Turbonomic uses benchmark data from spec.org.

SQL is a standard language for accessing and manipulating databases, e.g., to execute queries, retrieve data, insert or edit records, or create stored procedures. 

In the 6.4 version family, Turbonomic uses SQL to create new report templates. In later version families, Turbonomic offers Embedded Reports.

SSH is a software package that enables secure system administration and file transfers over insecure networks. In SSH, all user authentication, commands, output, and file transfers are encrypted to protect against attacks in the network. Tatu Ylonen developed the SSH protocol in 1995 in response to the hacking of the Finnish university network

To administer the Turbonomic platform at the OS or container level, you can use SSH sessions on the hosting VM. 

Supercluster is a term that refers to the results of a Merge placement policy. This Merge policy joins two or more clusters into a single group of providers. This enables Turbonomic to move workload from a host in one of the clusters to a host in any of the merged clusters.

By default, Turbonomic respects boundaries inherent in your environment, such as cluster boundaries or networks. A supercluster provides more choices for workload placement.

See also Cluster

In Turbonomic, the Supply Chain is the full stack of entities in your IT environment, placed in buyer/seller relationships with each other, where some entities provide resources while others consume the supplied resources.

Turbonomic uses Targets to discover the entities in your environment and stitch them together into a Supply Chain, and it displays the Supply Chain in an organizer that you can use to view the relationships or set session scope. With the Supply Chain, you can see at a glance how resource issues impact the full stack of your IT environment.

Swagger refers to the set of tools that you can use to implement APIs using the OpenAPI specification.  Turbonomic uses the SwaggerGUI as one way to deliver documentation for the Turbonomic API.

A Target is a resource or workload management service in your virtual environment that you have connected to Turbonomic. For example, a public cloud account on AWS (Amazon Web Services) can be a target, as can an on-prem datacenter managed by VMware vCenter Server.

For each target that you configure, Turbonomic communicates with the service via the management protocol that it exposes — a REST API, SMI-S, XML, or some other management transport. Turbonomic uses this communication to discover the managed entities, monitor resource utilization, and execute actions.

Virtual CPU (VCPU) (also known as Virtual Processor) is a measure of the CPU resources on a VM. VCPU is typically expressed in a VM as the number of cores. Turbonomic measures allocated VCPU capacity and utilized VCPU in hertz of processing power (GHz or MHz).

For on-prem environments, VCPU capacity is a percentage of the CPU capacity of the underlying host (see CPU).

For cloud VMs, the VCPU capacity is determined by the instance type and the CPU options you specify upon instance launch. For example, an Azure Standard_D2_v2 instance has a default of two VCPU cores. Turbonomic discovers the VCPU capacity and expresses it as GHz of processing power.

A Virtual Datacenter (vDC) is a collection or pool of resources that groups the resources around specific requirements or business needs. These vDCs can implement boundaries for a private cloud infrastructure, and then can establish Tenant groups on that infrastructure.

Turbonomic discovers vDCs for Private Cloud environments. The private cloud infrastructure provides resources to the cloud, and to the workloads that run on the cloud. To manage these resources, private clouds organize the infrastructure into Provider and Consumer vDCs. A Provider vDC is a collection of physical resources (hosts and datastores) within the cloud stack. A Consumer vDC is a collection of resources that are available to tenant customers so they can manage their workloads. A Consumer vDC uses the resources supplied by a Provider vDC.

For container environments, if you deployed Kubeturbo 7.22.0 or earlier, Turbonomic uses vDCs in the supply chain to represent a Kubernetes Namespace, or a Cloud Foundry Org. 

Virtual Desktop Infrastructure  (VDI) is a technology that allows virtual machines to provide and manage virtual desktops. VDI hosts desktop environments on a centralized server and deploys them to end users on request. 

Turbonomic integrates with Horizon VDI so customers can apply our Application Resource Management to maximize the value of their VDI deployment.

A Virtual Machine (VM) is a software emulation of a physical computer that can run programs or applications. For an on-prem environment, one or more VMs can run as guests on a single physical machine. 

For a public cloud environment, virtual machines run in cloud regions. Each VM is a unique machine with its own CPU, memory, network, and storage resources, as well as its own OS.

Turbonomic can discover and manage VMs that run in on-prem and public cloud environments.

For Kubernetes environments, Turbonomic discovers the nodes that provide resources to containers, and presents them as virtual machines in the supply chain.

Virtual Memory (VMem) is a measure of the memory resources on a VM. Turbonomic measures allocated VMem capacity and utilized VMem in bytes (GB or MB).

Note that percentages of allocated VMem are measured against whichever is the less of the VMem limit (if set) or the allocated VMem capacity. This is also true in reports and recommended actions. For example, assume a VM with allocated VMem of 8 GB, but a limit of 4 GB. In this case, the percentage in a chart shows the percentage utilized of 4GB.

For on-prem environments, VMem capacity is a percentage of the Mem capacity
of the underlying host (see Mem). For cloud VMs, the VMem capacity is determined by the instance type. 

See Virtual CPU (VCPU)

VStorage is the allocated virtual storage capacity, measured in Kbytes. 

Charts show the percentage of storage that is in use.

[Also called Ghost Volumes] Wasted Storage refers to storage volumes that are not actively used by any workload in the system. Typically, these are paid for but unused.

Turbonomic can help you reclaim unused storage or realize potential savings by identifying and deleting these volumes.

See Chart

A Workload Controller is the Turbonomic Supply Chain entity that represents a Kubernetes controller. This entity watches the state of your Container Pod entities and then requests changes where needed. You can execute container resize actions when you set the scope to a Workload Controller.

A Workload Controller executes container actions, but Turbonomic does not recommend actions to perform on the Workload Controller itself. When you scope to a Workload Controller and view the actions list, the actions apply to containers.

Zookeeper is a component of the Turbonomic platform that runs the Zookeeper software to manage the Kafka configuration settings. It is open-source software developed by Apache.