For the last few months and certainly very recently (at the London VMUG meeting) I have had the chance to talk to peers and #vExperts and share “war stories” with regards to vRealize Operations Manager.
What has become a consistent theme in all the stories is just how much compute resources vROps requires when you “go big” and not just what is clearly defined in the sizing spreadsheet.
For example some of the large deployments I have either been involved in or heard about (to monitor upwards and beyond of 30000 VMs) required the deployment of Large vROps nodes.
A single Large node collecting data for a large deployment as outlined above requires the following resources.
As you can see a single node is not to be sniffed at and you would need 7 of them! (if you required HA) thats a total of 112 vCPUs and 336GB RAM. When you consider the IOPS required per node, we are already well into SSD/Flash territory so that will also need to be considered. Another important issue that has come up is vROps really does need (at this scale) a 1:1 ratio of pCPU to vCPU else it has been seen to behave erratically.
Then you will need to consider things like DRS affinity and or anti-affinity rules so as not to have your nodes ever sharing a host. Resource pools would need to be considered.
With all the above to consider vROps is no longer just another monitoring tool in my opinion it should be treated like a tier one application (even if its on your management cluster). I know of many businesses and organisations where they are now extremely dependant the alerting, capacity planning and other features vROps brings to the table as a product. It has now become the hub of a massive quantity of data and with more features and functions being added with each release this will only increase.
With all that’s being thown at it and with that only being set to increase vROps (like a diva) will need and demand special attention when it comes to planning, deploying and day to day running.