Sizing a vRealize Operations Manager Environment

VMware vRealize Operations Manager is the flagship monitoring suite for the entire VMware Software Defined Datacenter stack. The software is incredibly powerful, but it can be a bit daunting to a newcomer. Each update has improved out of the box functionality, however there is a lot to learn to master the software and truly make the most out of its features. Every successful environment starts with a strong design. It is a good idea to think about our architectural decisions and options before we run through our first deployment.

Definitions

vRealize Operations Manager introduces many new terms into the system engineering lexicon. They aren’t exactly particular but they do have specific meanings, so defining these terms is step one.

• Analytics Node - any node that performs analysis or data collection for the vRealize Operations Manager cluster
  • Master Node - The first node in a vRealize Operations Manager cluster. This manages any other nodes in the cluster and there can only be one per cluster
  • Replica Node - A node deployed as a replica of the master node, required for high availability
  • Data Node - Nodes used to expand the capacity of a vRealize Operations Manager cluster. A data node has adapters installed and can perform collection and analysis
• Remote Collector Node - a node deployed in a remote datacenter location across a firewall. It only gathers objects to send back to the analytics cluster and does not store data or provide analysis itself
• Collector Group - a collection of analytics nodes and remote collectors. You can assign adapters to a collection group instead of a single node. Only normal adapters can be added to a collector group
• Adapter - An interface between vRealize Operations Manager and an endpoint, vCenter Server for example
• End Point Operations Agent - an in-guest agent installed to allow deeper inspection of a Windows or Linux VM

Requirements

• Analytics nodes should be deployed into the same vCenter cluster and must be in the same geographical location
• Analytics nodes must be on the same VLAN and that VLAN must not span datacenters
• Analytics nodes within a cluster must be the same node size, and if one node’s resources are changed, all nodes must be changed to match
• Remote collectors can be deployed behind a firewall but may not use NAT
• Remote collectors may be different sized nodes
• Every node must have a static IP address and be registered in DNS

Virtual Appliance Sizing

vRealize Operations Manager can consume a lot of resources. By default it gathers data from its adapters every five minutes and retains all of those points of data for six months. VMware gives administrators quite a bit of flexibility with scaling up or scaling out their environment.

There are multiple options for analytic node sizes:

Analytic Node Size	vCPU	RAM (GB)	Single Node Object Max	Max Nodes in a cluster
Extra Small	2	8	250	1
Small	4	16	2,400	2
Medium	8	32	8,500	16
Large	16	48	15,000	16
Extra Large	24	128	35,000	6

Remote Collectors also have two sizing options:

Remote Collector size	vCPU	RAM (GB)	Single Node Object Max	Max Nodes in a cluster
Standard	2	4	1,500	50
Large	4	16	15,000	50

These details plus many more are available in KB2150421

A vRealize Operations Manager deployment can be a very simple, single node deployment or can deploy as a cluster of multiple nodes with various roles. A single extra small master node will be sufficient for a small home lab or isolated testing environment, though this node wouldn’t provide enough capacity or performance for an enterprise scale environment. The smallest nodes sufficient for production is the Medium node, though any Enterprise deployment should be based off of the large node.

Finally, we can bring all of the information and considerations from above into an actual design, which we will do in our next post.