vRealize Operations Manager 6.6 and 6.6.1 Sizing Guidelines (2150421)

KB Link

By default, VMware offers Extra Small, Small, Medium, Large, and Extra 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	Extra Large	Standard Size Remote Collectors	Large Size Remote Collectors
vCPU	2	4	8	16	24	2	4
Memory (GB)	8	16	32	48	128	4	16
Maximum Memory Configuration (GB)	N/A	32	64	96	N/A	8	32
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	8,500	15,000	35,000	1,500 (****)	15,000 (****)
Single-Node Maximum Collected Metrics (**)	70,000	800,000	2,500,000	4,000,000	10,000,000	600,000	4,375,000
Multi-Node Maximum Objects Per Node (***)	NA	2,000	6,250	12,500	30,000	NA	NA
Multi-Node Maximum Collected Metrics Per Node (***)	NA	700,000	1,875,000	3,000,000	7,500,000	NA	NA
Maximum number of nodes in a cluster	1	2	16	16	6	50	50
Maximum number of End Point Operations Management agents per node	100	300	1,200	2,500	2,500	250	2,000
Maximum Objects for the configuration with the maximum supported number of nodes (***)	250	4000	75,000	150,000	180,000	NA	NA
Maximum Metrics for the configuration with the maximum supported number of nodes(***)	70,000	1,400,000	19,000,000	37,500,000	45,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.6 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. This adjustment is accounted for in the calculations.

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

What's new with vRealize Operations 6.6.x sizing:

Monitor larger environment with improved scale: The vRealize Operations 6.6 cluster can handle 6 Extra Large Nodes in a cluster which can support up to 180,000 Objects and 45,000,000 metrics.

Monitor more vCenter Servers: A single instance of vRealize Operations can now monitor up to 60 vCenter Servers.

Deploy larger sized nodes: A large Remote Collector can support up to 15000 objects.

Notes:

• Maximum number of remote collectors (RC) certified: 50.
• Maximum number of VMware vCenter adapter instances certified: 60.
• Maximum number of VMware vCenter adapter instances that were tested on a single collector: 40.
• 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 5 users per node (For example: 16 nodes with 150K objects can support 80 concurrent users).
• Maximum number of the End Point Operations Management agents per cluster certified - 10,000 on 4 large nodes cluster.
• When High Availability (HA) is enabled, each object is replicated in one of the nodes of a cluster. The limit of objects for HA based environment is half compared to a non-HA configuration. vRealize Operations HA supports only one node failure and you can avoid Single-point-of-failure by adding vRealize Operations 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 will support adapter instances where the total number of resources is not more than 2,400, 8,500, and 15,000 respectively, on a small, medium, and large multi-node vRealize Operations Manager cluster. For example, a 4-node system of medium nodes will support a total of 25,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 6,250 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.
• The sizing guides are version specific, please use the sizing guide based on the vRealize Operations version you are planning to deploy.
  Extra small and small node are designed for test environment and POC, we do not recommend to scale-out small node more than two nodes and we do not recommend to scale out extra small node.
• Simply scale up as you scale - Increase memory instead of configuring more nodes to monitor larger environments. We recommend to scale up to the possible maximum (default memory x 2) and then do scale out based on underlying hardware that will support the scale requirements. Example: Large node default memory requirements are 48GB and now, if needed, can be configured up to 96GB. All nodes must be scaled equally.