The Interaction Concentrator HA Model
This topic and the following topic contain information about the high availability (HA) model in Interaction Concentrator, and about how you can implement HA for Interaction Concentrator.
For information about ICON configuration and other Configuration Layer settings that are required in an HA deployment, see the High Availability tab on the Special Configuration Requirements topic in the Interaction Concentrator Deployment Guide.
How Interaction Concentrator Achieves High Availability
This section describes the design and implementation of high availability (HA) in Interaction Concentrator. It describes the Interaction Concentrator HA model and the consequences of dropped server connections and other failures as they relate to data consistency in Interaction Database (IDB). This page contains the following sections:
You can deploy Interaction Concentrator in an HA configuration to ensure redundancy of your reporting data for voice and multimedia interactions, voice attached data, agent states and login sessions, virtual queues, and Outbound Contact solution details.
In an HA configuration, if a component or network outage prevents one of the Interaction Concentrator (ICON) processes from storing data in its IDB, data is not lost as long as the other ICON process is able to store those interactions in its IDB. A downstream reporting application such as Genesys Info Mart can continue to extract, transform, and load interaction, voice attached data, virtual queue, agent-related, and Outbound Contact data, as long as data is available in at least one of the IDBs in the HA pair.
Furthermore the ICON processes track and store control information about connections and data source events. Downstream reporting applications can use this information to determine the availability and reliability of data in HA pairs of IDBs for a given timeframe, so that they can determine the best IDB to use as the source of reporting data for that time period.
ICON HA Model
The HA model used in Interaction Concentrator differs significantly from the Genesys standard HA model that is implemented in a majority of Genesys servers.
Different from Standard Genesys HA Model
Unlike a typical Genesys server (for example, T-Server), two Interaction Concentrator instances (ICONs) that are deployed as a redundant (HA) pair do not operate in either primary or backup mode, nor does their mode switch from backup to primary when the other server fails. Rather, both ICONs in the HA pair operate in parallel as stand-alone servers and process incoming data independently.
A redundant pair of ICONs receives interaction-related events from the same T-Server, Interaction Server, or Outbound Contact Server (OCS)—either a stand-alone server or the primary server from a redundant pair—and stores data in two independent IDBs. The downstream reporting applications are responsible for managing extraction of reliable data.
In addition to data from interaction-related events, the ICON HA pair also store configuration and connection-related information from Configuration Server. Downstream reporting applications can use this information to determine the availability and reliability of IDB data for a given timeframe.
The figure below illustrates the major components of a full Interaction Concentrator HA solution. For simplicity, DB Servers and the connections between Configuration Server and the other Genesys components are not included. The Network T-Servers shown in the diagram are operating in load-balancing mode.
Sources of Data Interruption
Data source session control tables in IDB enable ICON and the downstream reporting application to identify and handle the following interruptions:
- On the data source server side—T-Server or Interaction Server, Outbound Contact Server (OCS), and Configuration Server, depending on the ICON role:
- Disconnection of the data source server from ICON
- Shutdown of the data source server
- No interaction activity on T-Server/Interaction Server or OCS
- Reconnection of T-Server to the switch or OCS to T-Server
- On the ICON side:
- Disconnection of ICON from its data sources
- Shutdown of ICON
- Disconnection of ICON from IDB
- On the IDB side:
- RDBMS server disconnection
- RDBMS server shutdown
For more information about the data source session control tables, Data Source Session Control Tables.
For more information about using the data source session control tables to identify data interruptions, see Determining Data Availability and Reliability.
Consequences of Failures
Dropped server connections and other failures that interrupt data result in data inconsistencies in IDB. The table below summarizes the consequences of these kinds of failures in an ICON HA configuration.
IDB Inconsistencies Resulting from Failures
|Point of Failure||Resulting Data Inconsistency|
|ICON connection to T-Server||
|Computer-telephony integration (CTI) link||
|Active T-Server in an HA pair||
|ICON connection to Interaction Server||
|ICON connection to OCS||