vRealize Operations Manager 6.4 Sizing Guidelines

Products

• VMware Aria Suite

Issue/Introduction

This article provides information on using the sizing guidelines for vRealize Operations Manager 6.4 to determine the configurations used during installation.

Environment

VMware vRealize Operations Manager 6.4.x

Resolution

By default, VMware offers Extra Small, Small, Medium, and Large configurations during installation. You can size the environment according to the existing infrastructure to be monitored. After the vRealize Operations Manager instance outgrows the existing size, you must expand the cluster to add nodes of the same size.

 

Characteristics/ Node Size	Extra Small	Small	Medium	Large	Standard Size Remote Collectors	Large Size Remote Collectors
vCPU	2	4	8	16	2	4
Memory (GB)	8	16	32	48	4	16
Datastore latency	Consistently lower than 10 ms with possible occasional peaks up to 15 ms
Network latency for data nodes	< 5 ms
Network latency for remote collectors	< 200 ms
Network latency between agents and vRealize Operations Manager nodes and remote collectors.	< 20 ms
vCPU: Physical core ratio for data nodes (*)	1 vCPU to 1 physical core at scale maximums
IOPS	See the attached Sizing Guidelines worksheet for details.
Disk Space
Single-Node Maximum Objects	250	2,400	7,000	12,000	1,500 (****)	12,000 (****)
Single-Node Maximum Collected Metrics (**)	70,000	800,000	2,000,000	3,500,000	600,000	3,500,000
Multi-Node Maximum Objects Per Node (***)	NA	2,000	5,000	10,000	NA	NA
Multi-Node Maximum Collected Metrics Per Node (***)	NA	700,000	1,500,000	2,500,000	NA	NA
Maximum number of End Point Operations Management agents per node	100	300	1200	2500	250	2,000
Maximum Objects for 16-Node Maximum (***)	NA	NA	60,000	120,000	NA	NA
Maximum Metrics for 16-Node Configuration (***)	NA	NA	15,000,000	30,000,000	NA	NA

 

(*) It is critical to allocate enough CPU resources for environments running at scale maximums to avoid performance degradation. Refer to the vRealize Operations Manager Cluster Node Best Practices in the vRealize Operations Manager 6.4 Help for more guidelines regarding CPU allocation.

 

(**) Metric numbers reflect the total number of metrics that are collected from all adapter instances in vRealize Operations Manager. To get this number, you can go to the Cluster Management page in vRealize Operations Manager, and view the adapter instances of each node at the bottom of the page. You can get the number of metrics collected by each adapter instance. The sum of these metrics is what is estimated in this sheet. Note: The number shown in the overall metrics on the Cluster Management page reflects the metrics that are collected from different data sources and the metrics that vRealize Operations Manager creates.

 

(***) In large, 16-node configurations, note the reduction in maximum metrics to permit some head room.

 

(****)The object limit for the remote collector is based on the VMware vCenter adapter.

 

Notes:

• Maximum number of remote collectors (RC) certified: 50.
• Maximum number of VMware vCenter adapter instances certified: 50.
• Maximum number of VMware vCenter adapter instances that were tested on a single collector: 30.
• Maximum number of certified concurrent users: 200.
• This maximum number of concurrent users is achieved on a system configured with the objects and metrics at 50% of supported maximums (For example: 4 large nodes with 20K objects or 7 nodes medium nodes with 17.5K objects). When the cluster is running with the nodes filled with objects or metrics at maximum levels, then the maximum number of concurrent users is 4 users per node (For example: 16 nodes with 120K objects can support 64 concurrent users).
• Maximum number of the End Point Operations Management agents per cluster certified - 10,000 on 4 large nodes cluster.
• If you enable High Availability (HA), then the number of nodes is two times more than in a non-HA configuration - 16 nodes is the maximum limit. HA supports only one node failure, you can avoid single-point-of-failure by putting vROps cluster nodes into different hosts in the cluster.
• An object in this table represents a basic entity in vRealize Operations Manager that is characterized by properties and metrics that are collected from adapter data sources. Example of objects include a virtual machine, a host, a datastore for a VMware vCenter adapter, a storage switch port for a storage devices adapter, an Exchange server, a Microsoft SQL Server, a Hyper-V server, or Hyper-V virtual machine for a Hyperic adapter, and an AWS instance for a AWS adapter.
• The limitation of a collector per node: The object or metric limit of a collector is the same as the scaling limit of objects per node. The collector process on a node supports adapter instances where the total number of resources is not more than 2,400, 5,000, and 10,000 respectively, on a small, medium, and large multi-node vRealize Operations Manager cluster. For example, a 4-node system of medium nodes support a total of 20,000 objects. However, if an adapter instance needs to collect 8,000 objects, a collector that runs on a medium node cannot support that, as a medium node can handle only 5,000 objects. In this situation, you can add a large remote collector or use a configuration that uses large nodes instead of small nodes.
• A large node can collect more than 20,000 vRealize Operations for Horizon objects when a dedicated remote collector is used.
• A large node can collect more than 20,000 vRealize Operations for Published Apps objects when a dedicated remote collector is used.
• If the number of objects is close to the high-end limit, dependent on the monitored environment, increase the memory on the nodes. Contact Product Support for more details.
• The performance of vRealize Operations Manager can be impacted by the usage of snapshots. Presence of a snapshot on the disk causes slow IO performance and high CPU costop values which degrade the performance of vRealize Operations Manager. Use snapshots minimally in the production setups.

Additional Information

For translated versions of this article, see: