Below are some of the factors that affect the number of connections:
- How busy are the collectors?
- Are dynamic thresholds calculating during user sessions?
- Are custom dashboards using widgets that are taxing (weather maps, TopN, distribution widgets, ect.)?
- Is there good communication between the UI VM and Analytics VM?
- Are the VMs running on separate hosts to reduce contention?
- How many alerts, alarms, and RCAs are being processed?
- How many back-end storage IOPs are supporting the vCOps virtual machines?
For vRealize 6.0, because of the design changes we discussed in my previous post vRealize Operations - Looking Under the Hood, it is possible to get a higher number of concurrent connections. Right now the maximum best practice is 4 concurrent connections per large data node, which would be 32 concurrent connections for a single deployment. But, like vCOps 5.x, that depends on the dashboards that are being presented and the metrics being collected. If you keep it decentralized, with judicious amount of metrics being collected there is a possibility that you could see a modest improvement in concurrency. For example, if you had a data center in Boston that was collecting 10,000 metrics, which is at the top end of a single vRealize Operations 6.0 data node, and went with the full scaled out deployment of 8 nodes and are prudent with what you expose for dashboards to the users, we should able to reach a much higher number of concurrency. Talking with VMware product management, you could see up to twice the amount of concurrency which be up to 64 concurrent users.
But, there are a couple other design requirements you need to consider. Are you planning to centralize your data using remote collectors with vRealize Operations 6.0? In the previous version; if you had data centers in Boston, Atlanta, and London you would typically setup a vCenter Operations Manager 5.x instance at each site. If you were using a optimized dashboard, you could get 10 to 20 concurrent connections per site. vRealize Operations 6.0 provides you the ability of centralizing that data to a single instance with the use of remote collectors at the other locations. For example, Boston would be my master and data nodes, with Atlanta and London having remote collectors. I have moved away from three UI portals that could handle up 30 to 60 concurrent connections, to a single UI portal that can handle 32 concurrent connections.
Also, if you plan on using the new high availability (HA) feature with vRealize Operations 6.0, that is going to give you a maximum of 4 data nodes.
These are just a few factors you should consider before deploying vRealize Operations.