vRealize Operations Concurrent User Connections

When deploying vRealize Operations 6.0, it is important to take into account the best practice for the concurrent user connections. This is an often misunderstood aspect when designing a deployment for vCenter Operations Manager 5.x and also the most complex. There are several factors that go into the amount of concurrent users that can access the product UI. In the prior version, when customers wanted to have more than a handful of users looking at the vSphere UI at a single time, it was recommended to create a custom dashboard with minimum overhead. You would want to limit the number alerts, alarms, and RCA information because it places a heavy load on the database, which can drag down the system. The vSphere UI in vCenter Operations 5.8 was able to handle about four concurrent connections, whereas an optimized custom dashboard in the Custom UI could handle anywhere between 10 to 20 concurrent users. There isn't a hard set number of concurrent connections, but out of the box for vCenter Operations Manager 5.8 you can expect 10 concurrent connections based on a large vApp deployment.

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?

As you can recognize, there are a lot of elements that determine the overall performance and concurrency. The higher the concurrent connections when the system is under load, longer latency and ultimately unacceptable refresh rate become noticeable in the vSphere UI.

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.