Load Balancing and High Availability - Desktop Connect Unified Agent
Introduction
Geomant Desktop Connect Unified Agent offers scalability and high-availability for customers with a large number of users. The Geomant Desktop Connect Unified Agent server component is able to serve 1000 concurrent inbound/outbound and predictive dialler users per instance.
Geomant Desktop Connect Unified Agent offers a load-balanced high availability solution, this means that every deployed instance is fully live and operational and accepts agent sessions.
Geomant Desktop Connect Unified Agent is able to communicate with multiple instances of Avaya Proactive Contact with the help of the APC Agent API. The Proactive Contact instances are constantly monitored and in the event that one of the instances fails, DC-UA redirects requests to the next PC instance. In case of failure of an APC instance the connection with the dialler is torn down, client application is reset, and the agent is login process is restarted.
By design, DC-UA is able to handle an HA AES connection. DC-UA communicates with Avaya AES over the telephony link via JTAPI, whenever the AES connection is “broken”, DC-UA receives a system statistics event indicating that the link is down and that all monitored stations observation ended; in this scenario DC-UA will try to re-establish the connection with the AES server. In case of communication failure with the AES, the client application interface is reset and the login process is restarted. Once the connection is re-established, the agent is logged back in and agent state is synchronized.
Unified Agent can be installed into multiple datacentres. In each data centre there can be multiple instances of Geomant Desktop Connect Unified Agent Server, each instance serving up to 1000 active agents. This DC-UA architecture can be optimized to have all DC-UA Server instances interconnected to allow for the sharing of “heartbeats” and agent session information.
Geomant Desktop Connect Unified Agent cluster can be deployed in multiple data centre, in an active-passive mode, providing a fully redundant instance with the secondary data centre taking over only when the Unified Agent cluster in the primary node fails.
Architecture
The Desktop Connect Unified Agent client sessions are web sessions between the browser (or JSONP API Client) and the selected Desktop Connect Unified Agent server. The selection of the active server is performed as part of the session initiation before the agent log in is being performed. Once the active server found the further communication flow is direct between that server and the client.
The active server selection can be achieved in multiple ways.
Apache HTTP server
As part of the Desktop Connect Unified Agent solution an Apache HTTP server can be installed. This Apache HTTP Server is connected to the Unified Agent Servers using the Apache Tomcat Connector (mod_jk) and acts as the load balancer.
To provide full high availability the Apache HTTP server also need to support resiliency, so multiple of these servers should be part of the architecture. In case there are multiple Apache HTTP servers a mechanism must be in place to select the active Apache HTTP server, but for this there is no special requirements so this can be provided by any load balancer or DNS load balancing.
This Apache HTTP server can coexist so can be installed on the UA servers or on dedicated server(s). As this server is only used for the session initialization there is no extra hardware requirement on top of the standard Unified Agent Desktop Connect.
Load Balancer Server
Desktop Connect Unified Agent can work with some load balancers without the Apache HTTP server. In this case the load balancer must be capable to check the availability of the Unified Agent Server and route the request there. Once the Unified Agent server selected the client browser must be able to directly communicate with the selected UA server.
Application Level High Availability
For those installations when the JSONP API is used to connect to the Unified Agent application server the client application can store the location of the UA servers and can manage the failover scenarios by connecting to the other server in case of the primary server failure. The location of the servers can still be behind a shared FQDN with multiple 'A' entries in the DNS that the client application can retrieve.