vRealize Operations Manager v6 architecture differs significantly from vCenter Operations 5.x. The biggest change comes in vRealize Operations v6’s new scale-out architecture. In this blog post, we’ll cover how you can size vROps for maximum functionality.A vRealize Operations Manager implementation can now be scaled up to 8 cluster nodes and 50 remote collectors. This significantly improves on vCenter Operations, allowing an implementation to scale to support 75,000 objects and 20,000,000 metrics. The vRealize architecture also brings improved redundancy.
First, let’s take a look at what a vRealize Operations node now looks like. In the graphic below, we can see that a vRealize Operations node contains all of the functions needed to operate a vRealize environment – UI, Collectors, Controller, Analytics, and Persistence. This means that one can deploy a single node and have a fully functional vRealize environment. Preferably, one would opt to deploy more than one node for the purpose of redundancy and performance.
The Persistence Layer, a key component of the new architecture, allows for greater capacity, performance, and the option to scale out. Here, VMware has implemented an in-memory multi-node database called Pivotal Gemfire. This makes understanding the capacity requirements of your vRealize environment critical. You must have sufficient memory to host the Gemfire database.
VMware’s KB article, vRealize Operations Manager 6.0.1 Sizing Guidelines (2109312) contains a sizing worksheet useful for planning your vRealize environment. In this article, we will discuss sizing for vRealize Operations Manager v6.0.1. If you have not yet upgraded to v6.0.1, we recommend you do so as soon as possible. This release contains a number of critical fixes as well as improved performance and capacity. VMware’s sizing guide for v6.0.1 can be found here:
Blue Medora’s updated version of the worksheet includes Cisco UCS, Citrix XenDesktop, and NetApp Management Packs, and can be found here:
The worksheet is a great start for sizing a vRealize environment.
vRealize Operations Manager requires all nodes of a cluster to be the same size. Now that we have Gemfire Pivotal providing access to in-memory data across multiple nodes, we can gain performance and redundancy improvements by taking advantage of a multi-node deployment.
To begin, open up the sizing spreadsheet and jump to the ‘Advanced’ tab. Here we will enter the various resources we want to manage with vRealize Operations. Start by selecting your high availability (HA) and data retention settings. The defaults are HA DISABLED and 6 months data retention. Next enter your estimates for your vCenter objects – Virtual centers, Datacenters, Clusters, Virtual Machines, Hosts, and Datastores. Do your best to project at least 6 months growth.
Now, enter the Resources and Metrics from any other Management Packs you plan to install. Use an estimate when you do not know a value, or attempt to ascertain the value from a native tool (console, management interface, etc).
Once you have completed the entries for all Management Packs you intend to deploy, the sizing worksheet will provide an analysis at the bottom of the advanced tab.
In our example worksheet, the indication is that a single Medium or Large node will handle our load. Keep in mind the “Total # of Objects” and “Total # of Selected Metrics” values and compare these against the first tab. Note that the capacity numbers on the “Overall Scaling” tab are architectural maximums and not goals. If our worksheet brought us closer to 6700 objects we would want to seriously consider using a large node – or even better – two medium nodes.
As always, feel free to reach out to your Blue Medora Sales Engineer or a Blue Medora authorized reseller with any questions relating to the implementation or sizing for Blue Medora Management Packs.