Occasionally I am asked is there a downside to running the VSAN Observer on vCenter. Generally my recommendation is if a customer is using it for short term monitoring or troubleshooting in a small(ish) environment then it should be fine. For customers who are using it in larger clusters and in more anger I’d recommend a different approach.
VSAN Observer is a tool used to analyse the performance of a VSAN environment. Customers and VMware Support can use this tool to gain a deeper insight into their environment. Running VSAN Observer – http://www.punchingclouds.com/2013/09/03/vsphere-5-5-using-rvc-vsan-observer-pt2/
vCenter running VSAN Observer will hold all of the session history in it’s memory until it either times out or is manually is halted by the uses with the <Ctlr>+<C> combination. At this moment the default interval at which VSAN Observer collects stats is 60 secs, which is quite aggressive. If you think about vCenter Operations it will collect stats every 5 minutes so the use case of the two is actually quite different. VSAN Observer is meant for running for short periods, perhaps those for on the spot troubleshooting or point in time monitoring.
In situations where VSAN Observer is used often for heavier work it might be suitable to configure another vCenter Server as a dedicated RVC instance. Doing so would remove any potential impact on your production vCenter Server.
Of course this depends greatly on the customers usage and ability to manage another vCenter instance. This vCenter instance should be a cut down version not integrated into the production environment with SSO and the like. Using the vCenter Virtual Appliance would be the simplest recommendation I’d give. Just install a new vCVA and configure with a basic embedded config as per normal. In fact, it’s entirely possible to stop all the vCenter services on this server if really required.
NOTE: You can change the VSAN Observer collection interval and max runtime
–interval or –i – Interval in Sec in which to collect (default:60)
–max-runtime or –m – Maximum number of hours to collect stats (default:2)
After installing the second vCenter simply open an ssh connection to it and type rvc root@prodvc (where prodvc is your production vCenter server).
If this is the first time you have connected you will be prompted to accept the warning:
Host to connect to (user@host): root@mysecondvc
The authenticity of host ‘mysecondvc’ can’t be established.
Public key fingerprint is 6d62e48e1c8d80fc651359a356edc51b949097d68d1ca085fcd5415f8d46734e.
Are you sure you want to continue connecting (y/n)? y
Warning: Permanently added ‘mysecondvc’ (vim) to the list of known hosts
Once the password is entered correctly you’ll be at the prompt and all you are good to go. I should re-iterate that only special cases would call for this type of configuration but it is definitely possible.