VMware vROps - When and how to scale your monitoring solution?
This post was inspired by numerous vROps sizing consults I have done over the past year, and my good friend Max Drury, whose vROps Dynamic Thresholds calculations were taking over 24 hours which rendered the entire solution very sluggish and almost unusable. He wanted to add another node to his vROps cluster, but after closer analysis, it turned out he would be better off scaling-up his nodes by adding more CPU and memory. His two small nodes simply were not large enough to handle the additional number of objects and metrics collected as his environment grew over the course of a year. The number of users using the vROps solution has not changed, so there was no need to add any additional nodes. Simply bumping the CPU and memory up to the medium size on both nodes was enough to resolve both issues, DT calculation time and slowness. One key factor in Max's case that was impacting the solution was that the initial cluster size he deployed was for a much smaller environment. With time, the number of collected objects and metrics grew and Dynamic Thresholds had to chew through 12 months of accumulated data each night. The conclusion is that it is very important to keep an eye on the number of objects and metrics collected by each adapter as it directly correlates to the node size.
Mastering vRealize Operations Manager by Scott Norris
VMware vRealize Operations Manager Capacity and Performance Management by Iwan 'e1' Rahabok
VMware Professional Services
Official vROps Documentation
VMware Operations Management White Papers
Extensibility and Management Packs
vROps product page
vXpress by @
virtual red dot by @
Virtualise Me by @
Elastic Sky Labs by @
i'm all vIRTUAL by @