Managing compute platforms

Managing compute platforms requires defining which data sources can be leveraged for supporting capacity management use cases.

Related topics

Recommended options to extract data

The following table contains a list of the recommended options for extracting data into TrueSight Capacity Optimization, as either provided by out-of-the-box ETL modules or provided by Sentry and Moviri ETL modules.

Platform classificationExamplesOptions for extracting data
AIX on IBM POWER (PowerVM hypervisor)Any POWER machine with at least one AIX partition

TrueSight Capacity Optimization agents

TrueSight Operations Management

Solaris in any LDOM/Zone/DSDAny Solaris virtualization technology

TrueSight Capacity Optimization agents

TrueSight Operations Management

HP IntegrityHP Integrity serverTrueSight Capacity Optimization agents
HP-UX virtualizationHP nPar, HP vParTrueSight Capacity Optimization agents
Xen hypervisorAny supported Linux distro running Xen

TrueSight Capacity Optimization agents

Microsoft Hyper-VMicrosoft Hyper-V

TrueSight Capacity Optimization agents

Microsoft SCOM ETL module from Moviri Integrator for TrueSight Capacity Optimization. See Moviri ETL modules.

KVMAny supported Linux distro running KVMTrueSight Capacity Optimization agents
VMware vSphere (ESXi and vCenter)vCentervCenter Extractor Service
Any supported OS running directly on a "standalone" x86 based machineLinux or Windows

TrueSight Capacity Optimization agents

TrueSight Operations Management (on supported platforms)

Any supported OS running on an x86 based hypervisorLinux or WindowsTrueSight Capacity Optimization agents
Any supported OSN/AOther options provided by ETL modules that integrate management tools from third-party vendors such as those provided by Moviri Integrator for TrueSight Capacity Optimization add-on. See Sentry ETL modules and Moviri ETL modules.

vSphere

With TrueSight Capacity Optimization, you can manage the capacity of vSphere running business workloads as virtual machines (VMs). There are two levels of capacity management for vSphere alone:

  • Managing the capacity of the infrastructure, including the VMware ESXi hosts, storage, and networks.
  • Managing the capacity of an individual virtual machine that is running a business workload.

In addition, vSphere capacity can be managed in context of a cloud management system:

  • In the context of VMware vCloud Director
  • In the context of BMC Cloud Lifecycle Management

The following topics consider each of these levels of capacity management separately.

Managing the capacity of the vSphere infrastructure

Benefits of using TrueSight Capacity Optimization to manage the capacity of the vSphere infrastructure


TrueSight Capacity Optimization lets you see the capacity of the ESXi hosts, clusters, resource pools, storage, and networks. Considering the clusters as containers of resources, TrueSight Capacity Optimization calculates the spare capacity you have available to support additional VMs. Using the trends in the data, it identifies you which resource (CPU, memory, disk space, and so on) is limiting the capacity. TrueSight Capacity Optimization also alerts you about how many days you have before a container reaches saturation. For more information, see vSphere views.

Managing the capacity of your vSphere infrastructure

You collect data from vSphere using the OOTB vCenter Extractor Service. The connector loads configuration and performance information on all (or a subset of) the entities in a vCenter into the TrueSight Capacity Optimization data warehouse (DWH). TrueSight Capacity Optimization contains built-in analysis and model templates, reports, and views that help you answer questions about spare capacity, limiting resources, and days to saturation.

The vCenter Extractor Service creates TrueSight Capacity Optimization entities of types Virtual Host - VMware and Virtual Machine - VMware respectively for the ESXi hosts and VMs.

Deploying and configuring the vCenter Extractor Service

A single vCenter Extractor Service can collect data continuously either from one entire vCenter, or from a subset of a vCenter. To deploy multiple extractors against a single vCenter, use the extract clusters list option when configuring each extractor, so that it will load only the entities (hosts, virtual machines, datastores, and resource pools) related to a subset of the clusters in the vCenter. For more information, see the following topics:

Sizing the vCenter Extractor Service

With TrueSight Capacity Optimization, you can manage very large vSphere environments containing multiple vCenters. The TrueSight Capacity Optimization DWH and Application Server must be sized appropriately for the entire environment, including all the data expected to be loaded every day. For general information about sizing, see Sizing and scalability considerations.

The vCenter Extractor Service is a "service connector". When sizing the ETL Engines, follow the guidelines for service connectors. If you have a very large vCenter, you may have to deploy multiple extractors against it. 

Specifically for the vCenter Extractor Service, the main drivers for sizing are:

  • the number of VMs
  • the number of clusters managed

Use the following rules:

  • No more than 2,000 VMs per connector
  • Scheduler heap: 2 GB for the first 2,000 VMs, and 1 GB for 2000 VMs thereafter
  • Data storage on the ETL Engine machine: 10 GB per 2,000 VMs

For heavily populated clusters, the 2,000 VMs in the above rules can be equated to a single cluster. If you have many small clusters, consider that the number of clusters affects the number of threads used by the vCenter Extractor Service; allow enough CPU resources to ensure timely polling of data by limiting the number of clusters for each vCenter extractor.

How to split a vCenter among multiple vCenter extractors

When configuring the vCenter Extractor Service, it is possible to specify two key advanced properties:

  • Extract clusters list: specify a list of clusters whose data is to be extracted.
  • Blacklist file path: specify a file containing a list of clusters whose data is not to be extracted.

See the configuration details in the topic for continuous extraction of vCenter data.

Using the whitelist and blacklist file, you can distribute the clusters of a single vCenter among multiple vCenter extractors, either running the extractors on the same ETL Engine, or running the extractors on different ETL Engines, depending upon the sizing constraints. A standardized way of using the lists among a set of N extractors is: use whitelists for (N-1) extractors, and use a blacklist in the last extractor so that it will automatically pick up any newly added clusters in the vCenter.

Relationship with storage (requires Sentry integration version 3.5 or later)

Sometimes it is necessary to map datastores to their backup storage volumes. For VMFS datastores backed by shared LUNs, you can link storage data extracted for the underlying LUNs with the datastores.

The vCenter Extractor Service loads the config metric “DSTORE_DEVICE”, which is the external “naa” ID of the first backing block storage volume. For more information, see Datastore config metrics.

Managing the capacity of an individual virtual machine

For managing the capacity of a virtualized system running inside an individual VM, you need the "inside view" of the performance of a VM. Just like any server running on physical hardware with an operating system, the virtual node runs processes that do useful work. Performance data extracted from this system using an Agent can be extracted and optionally used to define Gateway Server workloads. In TrueSight Capacity Optimization, this kind of system is called a "virtual node". It is distinct from the system that represents the VM as seen by the hypervisor; TrueSight Capacity Optimization represents the two by using two distinct System Types.

TrueSight Capacity Optimization collects data directly from the operating system (Windows, or Linux) using Gateway Server data collection capabilities and OOTB TrueSight Capacity Optimization connectors to Gateway Server. You deploy the Gateway Server data collection components, and then use one of the OOTB Gateway Server connectors to load the results into the TrueSight Capacity Optimization DWH. The connector loads configuration and performance information on any of these virtualized systems. TrueSight Capacity Optimization contains built-in analysis and model templates, reports, and views, which help you answer questions about spare capacity, limiting resources, and days to saturation.

For new installations, use the "Virtual Nodes vis file parser" connector. For more information, see BMC - TrueSight Capacity Optimization Gateway VIS files parser.

For details about how to configure the Gateway Server data collection capabilities including agents and TrueSight Capacity Optimization, see Data collection requirements.

Managing the capacity of your IBM Power Series environment

IBM Power Series hosts are large servers, sometimes called "frames", that support virtualized "partitions" that run operating systems. Use TrueSight Capacity Optimization to collect data from these servers to manage capacity.

An IBM Power Series host can be partitioned into logical partitions (LPARs) in several ways: in dedicated mode, processors are assigned entirely to partitions; in shared dedicated mode, partitions may "donate" their spare CPU cycles to others; in shared mode, fractions of processing units are assigned as "entitlements" from a shared pool. The operating system (AIX, IBM, or Linux) running within the LPAR may further perform workload partitioning. Meanwhile, certain special partitions are dedicated to virtual I/O; these partitions, called VIO Servers, manage physical storage and network resources and mediate access to these by other partitions. The end result of these partitioning schemes is that the CPU, memory, storage, and network resources managed by the Power Series host are used by the business workloads.

TrueSight Capacity Optimization helps you see the capacity of the Power Series hosts (servers) and their VIO partitions. Considering the hosts as containers of resources, TrueSight Capacity Optimization indicates the spare capacity you have available to support additional LPARs. You can see which resource (CPU, memory, disk space, etc.) is limiting the capacity. Using the trends in the data, TrueSight Capacity Optimization provides you with the count of days that you have before a container reaches saturation. For more information, see AIX views.

Options for collecting data about IBM Power Series frames

The Hardware Management Console (HMC) is a separate management station for administering a number of IBM Power frames. An HMC is required in any substantial Power series installation.

An Agent can collect configuration and performance data either only from the AIX operating system within the partition it is running on, or both from the AIX partition and from the HMC. The second method provides data about the entire frame and all the partitions in it.

We describe these options in more detail below.

The following figure illustrates an example of three Power series frames and one HMC. The HMC is a separate machine, typically a rack mounted server. The three instances of Power Series frames can be either rack servers or blade servers. Not shown in the figure are any direct-attached data storage drives or SAN based storage.

The Power Series frames contain the built-in PowerVM hypervisor, and the administrator can create a number of logical partitions. These partitions can either be virtual I/O server partitions (VIO), which run a specialized version of AIX and manage I/O, or "client partitions", which in turn run an operating system and business applications. We show nine LPARs in the diagram, three in each frame.

HMConly

The above figure shows Agents installed on some of the partitions (LPARs 1-4 and 7) in order to collect data. Agents can be installed either on VIO server partitions or on AIX client partitions. In either case, we refer to the agent and collector as AIX agent and AIX collector.

Collecting data about IBM Power Series frames from HMC

The HMC has embedded software that does not support agents or other third-party additions. It allows third-party software like TrueSight Capacity Optimization to collect data from it remotely by issuing commands using SSH. The HMC provides configuration data and some utilization related data about the frames and the partitions running on the frames.

Agents can be configured to periodically collect HMC data. The agent must be installed on any AIX or VIO Server LPAR with network access to the HMC. In the previous figure, an Agent is installed on LPARs 1-4 and 7. The agents on LPARs 4 and 7 are each configured to connect to the HMC and collect data from it.

When collecting HMC data, an agent collects HMC data only for its own frame. Thus, each frame needs at least one AIX agent running on it. For more information, see Configuration requirements for collecting data from the HMC.

Collecting data from AIX running inside a partition

Agents can be installed on any AIX partition. In the above figure, LPAR 1 is an example of such a partition. The TrueSight Capacity Optimization UI refers to such partitions as "instrumented" partitions. The data for Frames 2 and 3 comes almost entirely from the HMC, while the data for Frame 1 comes entirely from instrumented partitions in the frame.

Advantages of full instrumentation

TrueSight Capacity Optimization can extract certain metrics only from instrumented partitions. Also, certain data about shared processor pools is possible to obtain correctly only when all of the contained partitions are instrumented. The trade-off is that in order to fully instrument the partitions, you need to install agents on each partition, remembering to install the agent on any new partition. In return for this complexity, you get two advantages:

  • A more complete list of metrics collected from inside each LPAR. These allow you to manage specific AIX or POWER features like AME, AMS, etc., as well as accurate utilization information for memory and storage.
  • Process-level data, and the ability to define business-specific workloads in Gateway Server and import them into TrueSight Capacity Optimization.

Non-instrumented partitions

All the data for non-instrumented partitions comes only from the HMC. This data measures allocation of CPU and memory to the partitions, and CPU utilization. Data about shared processor pools is limited to allocated resources.

OOTB views for different levels of instrumentation

For each LPAR, TrueSight Capacity Optimization reports whether it is instrumented or not. For each frame, TrueSight Capacity Optimization also reports whether the frame is fully instrumented or not.

The same OOTB Views for AIX can be used whether a frame is fully instrumented or not.

  • The "Allocated Capacity" view and its associated links show metrics that do not need full instrumentation.
  • The "Used Capacity" view and its associated links show metrics that need full instrumentation.

There is a view setting "HMC-only" to turn off those columns that require full instrumentation. You can use this setting if your frames are relying mostly on HMC data collection.

Xen hypervisor

Xen hypervisor is installed directly on hardware and is used for monitoring virtual machine operating systems and scheduling virtual machine operating system requests to the physical server's CPU and memory. The Xen hypervisor works in concert with a control domain, which is called dom0 or domain 0. Dom0 is automatically started when Xen hypervisor server boots. Dom0 manages the I/O and network interfaces for the Xen server. In Xen terminology, unprivileged domains are called domU or domain U; the industry term for domU is virtual machine. Dom0 and domUs are all virtual machines.

Managing the capacity of Xen hypervisor

BMC recommends collecting Xen hypervisor data using capacity agents that provide both outside and inside perspective. The two perspectives should be used in tandem to effectively manage the capacity of Xen hypervisor servers.

Outside

Deploy capacity agent in dom0 to collect configuration metrics for the Xen host, the list of all domUs (virtual machines) running on the host, core configuration metrics for domUs and limited set of performance metrics both at the host and the domU level. Capacity agent deployed in dom0 is referred to as the outside collection; it gives a complete picture of the configuration of the XenServer and its virtual machines but a limited set of performance metrics for each individual virtual machine. It should be noted that the outside data collection does not report actual memory used inside domUs. To get a detailed account of physical and virtual memory usage, paging and other detailed memory metrics, capacity agents should be deployed inside domU.

Inside

Deploy capacity agent in domUs to collect detailed configuration and performance metrics from each of the domUs. Capacity agents can be deployed in any of the Operating Systems - Linux, Windows or Solaris that run on domUs. The capacity agents deployed inside domU are similar to the capacity agents deployed in any standalone system running Linux, Windows or Solaris. The same set of metrics are collected.

Data collected using capacity agents both from outside and inside perspective can be processed and imported to TSCO database to enable users to perform data analysis, modeling or visualization or capacity assessment using the out of the box views. Data processing should be scheduled using gateway server manager runs and import using gateway servers ETLs. This workflow is similar to that of other virtualization platforms and standalone systems.

System types

Outside collection (capacity agent deployed in dom0), reports two types of systems to TSCO:

  1. Virtual Host – Xen
  2. Virtual Machine – Xen

Inside collection (capacity agent deployed in domU) reports one type of system to TSCO:

Virtual Machine –Xen and Virtual Node – Xen are connected using the relationship GM_ASSOCIATED_TO_VN. This association is performed by the administration task ‘virtual node linker’ which is scheduled to run daily.

Lookup ID and Domain name

ScenarioLook-up ids used for mapping VM to VNName used in Capacity Optimization tree

Outside collection (VM):

  1. Domain name
  2. UUID

Inside collection (VN):

  1. Domain name
  2. UUID (Serial number)
VM.domain_name -> VN.domain_name
  1. For VM: Domain Name from outside collection

  2. For VN:  Domain Name from inside collection

Outside collection (VM):

  • UUID

Inside collection (VN):

  1. Domain name
  2. UUID (Serial number)
VM.UUID -> VN.UUID
  1. For VM: Domain Name from inside collection
  2. For VN:  Domain Name from inside collection

Outside Collection (VM):

  1. Domain name
  2. UUID

No inside collection

N/A

For VM: Domain Name from outside collection

Outside Collection (VM):

  • UUID

No inside collection

N/A

For VM: UUID from outside collection

Oracle VM

Oracle VM is a virtualization solution based on the Xen.org open source hypervisor. Oracle hypervisor is installed directly on hardware and is used for monitoring virtual machine operating systems and for scheduling virtual machine operating system requests to the physical server's CPU and memory. The hypervisor works in concert with a control domain, which is called dom0 or domain 0. Xen and dom0 are automatically started when an Oracle VM server boots. Dom0 manages the I/O and network interfaces for the Xen server. In Xen terminology, unprivileged domains are called domU or domain U; the industry term for domU is virtual machine. Dom0 and domUs are all virtual machines.

Managing the capacity of Oracle VM server

BMC recommends collecting Oracle VM data using capacity agents that provide both outside and inside perspective. The two perspectives should be used in tandem to effectively manage the capacity of Oracle VM servers.

Outside

Deploy capacity agent in dom0 to collect configuration metrics for the Oracle VM host, the list of all domUs (virtual machines) running on the host, core configuration metrics for domUs and limited set of performance metrics both at the host and the domU level. Capacity agent deployed in dom0 is referred to as the outside collection; it gives a complete picture of the configuration of the oracle VM server and its virtual machines but a limited set of performance metrics for each individual virtual machine. It should be noted that the outside data collection does not report actual memory used inside domUs. To get a detailed account of physical and virtual memory usage, paging and other detailed memory metrics, capacity agents should be deployed inside domU.

Inside

Deploy capacity agent in domUs to collect detailed configuration and performance metrics from each of the domUs. Capacity agents can be deployed in any of the operating systems -  Linux, Windows or Solaris that run on domUs. Capacity agents deployed inside domU are similar to capacity agents deployed in any standalone system running Linux, Windows or Solaris. The same set of metrics are collected.

Data collected using capacity agents both from outside and inside perspective can be processed and imported to TSCO database to enable users to perform data analysis, modeling or visualization or capacity assessment using the out of the box views. Data processing should be scheduled using gateway server manager runs and import using gateway servers ETLs. This workflow is similar to that of other virtualization platforms and standalone systems.

System types

Outside collection (capacity agent deployed in dom0), reports two types of systems to TSCO:

  1. Oracle VM host - identified in TSCO as ‘Virtual Host – Xen’
  2. Oracle VM guest – identified in TSCO as ‘Virtual Machine – Xen’

Inside collection (capacity agent deployed in domU) reports one type of system to TSCO:

Virtual Machine –Xen and Virtual Node – Xen are connected using the relationship GM_ASSOCIATED_TO_VN. This association is performed by the administration task ‘virtual node linker’ which is scheduled to run daily.

Lookup ID and Domain name

ScenarioLook-up ids used for mapping VM to VNName used in Capacity Optimization tree

Outside collection (VM):

  1. Domain name
  2. UUID

Inside collection (VN):

  1. Domain name
  2. UUID (Serial number)
VM.domain_name -> VN.domain_name
  1. For VM: Domain Name from outside collection

  2. For VN:  Domain Name from inside collection

Outside collection (VM):

  • UUID

Inside collection (VN):

  1. Domain name
  2. UUID (Serial number)
VM.UUID -> VN.UUID
  1. For VM: Domain Name from inside collection
  2. For VN:  Domain Name from inside collection

Outside Collection (VM):

  1. Domain name
  2. UUID

No inside collection

N/A

For VM: Domain Name from outside collection

Outside Collection (VM):

  • UUID

No inside collection

N/A

For VM: UUID from outside collection

Was this page helpful? Yes No Submitting... Thank you

Comments