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.

• How Interaction Concentrator Achieves High Availability
  
• Extracting Data in an HA Deployment

For information about ICON configuration and other Configuration Layer settings that are required in an HA deployment, see Configuring for High Availability 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:

• Overview
  
• ICON HA Model
  
• Consequences of Failures

Overview

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.

ICON HA Model

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

Important

On the IDB side, connection problems between the Genesys DB Server and the RDBMS server are a potential source of failure that is not covered in the Interaction Concentrator HA design.

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	Incorrect party transitions from ICON’s point of view resulting in missing transition or party error records Calls deleted at unknown times Missing information about: Agent states Attached data Changes in attached data Parties Call linkages
Computer-telephony integration (CTI) link	Stuck calls Incorrect transitions in call- and agent-related events Stuck parties—parties which ICON reports as active (that is, not deleted) when the associated call interaction has in fact been deleted
Active T-Server in an HA pair	Incorrect transitions in TEvents Stuck parties Missing attached data Other inconsistencies due to incomplete eventflows
ICON connection to Interaction Server	Incorrect party transitions from ICON’s point of view resulting in missing transition or party error records Interactions deleted at unknown times Stuck interactions Missing information about: Agent state Attached data
ICON connection to OCS	Missing information about: Campaign processing Changes in calling lists Linkages between OCS and voice call data Missing OCS precalculated metrics
ICON server	As a result of data loss for the particular ICON instance as well as possible failure in restoring queued data from the persistent queue: Stuck calls Stuck parties Missing records