BicaraIT.com

Disrupting the world using Generative AI & Innovative Technology (by Doddi Priyambodo)

vRealize Operations Manager 6.1 and 6.2 Sizing Guidelines (2130551)

by ·

Source: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2130551

Details

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

Solution

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.1 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.
  • The maximum number of analytics cluster nodes is 16 regardless of whether they are used for High Availability (HA). If HA is enabled, the effective maximum is 8 nodes as the other 8 nodes will be used for HA. Remote collectors do not count against the maximum of 16 nodes.
  • 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 total 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.
  • 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 degrades the performance of vRealize Operations Manager. Use snapshots minimally in the production setups.

Attachments

Tags:

You may also like...