IBM Turbonomic ARM v8.x Administrator - Professional key terms

The top-level logical container that groups all targets, policies, users, and settings for one installation. Administrators scope most configuration work to a single instance and may manage several separate instances independently.

The containerized service architecture that runs the market analysis engine, API gateway, user interface, and data stores. It can be deployed on Kubernetes or as a VM-based appliance depending on release and edition.

The economic scheduling model Turbonomic uses to compare supply and demand for compute, storage, and network resources, then propose actions that improve utilization while respecting constraints and policies.

The hierarchical graph of entities that Turbonomic discovers and models, from data centers and clusters down through hosts, virtual machines, workloads, and storage. It represents what consumes and provides resources.

Any discovered object in the supply chain, such as a VM, host, cluster, application, or storage volume. Entities carry metrics, relationships, and policy assignments used during analysis.

The category that classifies entities in the model, for example VirtualMachine, PhysicalMachine, or StorageVolume. Policies, actions, and reports are usually scoped by entity type.

A discovered management endpoint, such as a vCenter, cloud account, or hypervisor, that Turbonomic connects to in order to import entities and metrics. Targets are added with credentials and a scope.

The process of connecting to a target, enumerating its entities and relationships, and validating credentials. Discovery populates the supply chain and repeats on a schedule or on demand.

A stored username, password, token, or key used to authenticate to a target. Credentials are validated during target creation and can be scoped to specific targets or shared across targets.

The check Turbonomic performs against a target to confirm the credential works and the required permissions are present. Failed validation blocks discovery and must be resolved before analysis can use the target.

A recommended change such as resizing a VM, moving a workload, or provisioning storage. Actions carry risk, savings, and impact estimates and may be automated, approved manually, or ignored depending on policy.

The setting that determines whether an action is automated, recommended for manual execution, or disabled. Modes can be configured globally, by policy, or per entity.

A severity classification, often minor, major, or critical, describing the potential disruption of executing an action. Risk influences default automation and approval requirements.

A process where proposed actions require a user to review and approve them before execution. Approval can be required by policy and is often used for higher-risk changes.

A rule set that controls analysis and automation for a scope of entities, such as placement, scaling, or utilization thresholds. Policies override global defaults and are evaluated during market analysis.

The set of entities a policy applies to, defined by entity type and selection criteria such as group membership. Scope determines which objects inherit the policy settings.

A policy that sets action modes and approval requirements for a scope, allowing administrators to automate low-risk actions while keeping high-risk actions manual.

A limit that actions must respect, such as maximum CPU per VM, minimum headroom, or anti-affinity rules. Constraints prevent optimization from violating operational or business requirements.

The reserved capacity kept free on a resource provider so that demand spikes can be absorbed. Headroom settings influence how aggressively Turbonomic recommends consolidation.

The percentage of a resource's capacity currently consumed, measured across CPU, memory, storage, and network. Utilization percentiles drive sizing and placement recommendations.

Adjusting the allocated capacity of a workload to match observed demand, reducing waste from overprovisioning or relieving pressure from underprovisioning. It is a common action category in Turbonomic.

A condition where an entity has more capacity allocated than its workload needs, creating cost or efficiency waste. Turbonomic flags these entities and may recommend downsizing actions.

The decision about which host, cluster, or storage a workload should run on. Placement actions aim to balance utilization and satisfy affinity and constraint rules.

A user-defined or dynamically populated collection of entities used for scoping policies, dashboards, and reports. Groups can be static or based on filters and tags.

Metadata attached to entities that can be used for filtering, grouping, and policy scoping. Tags often come from the target platform or are added within Turbonomic.

A permission set assigned to a user or group that controls what they can view and change, such as administrator, operator, or observer. Roles limit access to actions, policies, and settings.

Managing accounts, roles, and access for people who use the platform. It includes creating local users, mapping directory groups, and assigning scopes so users see only relevant entities.

An authentication setup that lets users log in through an external identity provider instead of separate local credentials. It centralizes access control and is configured with trust metadata.

A configuration that connects Turbonomic to a directory service so users and groups can be imported and authenticated. It simplifies role assignment for large organizations.

The entitlement that defines which capabilities and how much capacity the instance may manage. Administrators apply and monitor licenses to keep usage within purchased limits.

The state of managed capacity relative to licensed entitlement. Exceeding entitlement can block certain features or require remediation, so administrators monitor it regularly.

A method of installing and managing the Turbonomic platform on Kubernetes using an operator and custom resources. It supports upgrades, scaling, and configuration through declarative manifests.

The process of capturing platform configuration and data so it can be recovered after failure or migration. Regular backups protect policies, targets, and user settings.

The procedure for moving an instance to a newer release, including pre-checks, backup, and post-upgrade validation. Administrators verify target connectivity and policy behavior afterward.

The programmatic interface used to query entities, read recommendations, and trigger actions. Administrators and integrators use it for automation, scripting, and external reporting.

An HTTP callback that sends event notifications, such as new actions or alerts, to an external system. Webhooks support integration with ticketing and chat platforms.

A notification generated when a monitored condition crosses a threshold or an event occurs. Alerts can be routed to email, webhooks, or external monitoring tools.

A record of user and system activity, including configuration changes and executed actions. Audit logs support troubleshooting, compliance review, and accountability.

The generation and export of views covering utilization, savings, actions, and compliance. Reports help administrators demonstrate value and investigate trends over time.

A configurable visual summary of key metrics, actions, and health indicators. Dashboards can be scoped to groups and shared with stakeholders.