Show/Hide Toolbars

Configuration and Management of Inventu Viewer+ License Cluster Servers

Here are the important concepts for configuring your load balancing solution.

 

Sticky Sessions - Session Affinity

The most important consideration in configuring a load balancing solution for a Inventu Viewer+ Viewer server set is that a client accessing through the load balancer must have a "sticky" relationship to a single Inventu Viewer+ server.  The Telnet sockets that the Inventu Viewer+ server uses to connect to the host cannot be shared between the servers; once a new session is started, a client session must have all HTTP interactions with the same Inventu Viewer+ server for the duration of the session.

 

Generally, as all of the FVTerm interactions between the Inventu Viewer+ server and the client are HTTP-based, cookie-based affinity is recommended.  Note that users, once connected to the cluster, will open new sessions on that same server or a different server depending on the browser!

 

Load Balance Algorithm

This may need tweaking depending on the nature of user session duration, but generally, start with a round-robin approach and see how it works.  Further tweaks will need to be performed but the use of the health monitor can help should one server get "topped-out" and new sessions need routing to the other server(s)

 

Health Monitoring

The Inventu Viewer+ FVTerm application includes an HTTP request that can be called by the load balancer to check on the health of the server--this is documented in the "Health Monitor Configuration" section.  Note that once a Inventu Viewer+ server has all sessions in-use, it will report that in the request.  If your load balancer can distinguish between different "levels" of health, this can provide a more effective end-result in terms of fulfilling user requests.

 

Minimum Server: 1

If your load balancing solution has an option for managing a condition where all servers are "unhealthy" be sure to set that at least one server should still be available to respond to requests.  This avoids an HTTP 503 error as opposed to the more friendly FVTerm "no sessions are currently available" client-side alert.