Jump to: navigation, search

High Availability

Also known as HA. The use of Redundancy to enable contact centers to minimize interruptions that are due to hardware, software, or network connectivity issues.



Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Topology Diagrams

This page provides diagrams that illustrate the data-source topologies that Genesys Info Mart supports. The supported topologies implement the rules that are described in Genesys Info Mart Requirements for ICON Details Storage.

About the Topology Diagrams

Given the range of potential combinations, the diagrams on this page are not intended to represent specific deployment architectures. Instead, the diagrams illustrate generic building blocks for topologies that Genesys Info Mart supports. This page includes the following diagrams:

For related information about distributing the applications among hosts, see Recommendations on Hosting.

Diagram Conventions

The topology diagrams use the following conventions:

  • The diagrams do not show the DAP that each ICON requires in order to access the IDB it populates. In all cases, the role that is configured for the DAP matches the role that is configured for the ICON application.
    Tip
    You can reuse the Interaction Concentrator DAP to enable Genesys Info Mart to access the same IDB. For more information, see Reusing DAPs.
  • Square brackets ([ ]) indicate optional, additional data sources and Interaction Concentrator instances that you can include to scale your deployment.
  • The diagrams show only one instance of the Genesys Info Mart application and Info Mart database. However, you can deploy a second, parallel instance of the Genesys Info Mart Server to act as a standby. For more information, see Standby and Disaster Recovery.

Conceptual Architecture

The Figures under Basic Architecture and Basic High-Availability Architecture illustrate the data-source architecture at the highest level. You can extrapolate from the basic architectural concepts to scale or customize your deployment topology as required.

Basic Architecture

The following Figure illustrates the basic architecture for each data domain.

Conceptual Data-source Architecture

Basic High-Availability Architecture

The following Figure illustrates the basic architecture for HA.

Conceptual HA Architecture
Important
Genesys Info Mart provides HA of reporting data by supporting HA at the Interaction Concentrator level. Genesys Info Mart itself cannot be configured to operate in HA mode.

In each HA set of redundant ICONs and IDBs, the ICON applications must be configured to perform the same role, and they must have configured connections to all the primary data sources in the HA set.

The Genesys Info Mart extraction job uses session information in the IDBs to identify which instance of IDB from the HA set of IDBs contains the most complete and accurate set of data from each data source. For more information about Genesys Info Mart support for HA, see the High Availability chapter in the Genesys Info Mart 8.1 Deployment Guide.











One Data Source per ICON

The following Figure illustrates a topology in which each ICON monitors a single data source. This topology “building block” is supported for all data domains.

One Data Source per ICON

In this topology, the deployment consists of:

  • A single Interaction Concentrator instance to store Configuration details. You can co-locate the Configuration details IDB in the same RDBMS instance with Configuration Database (see Recommendations on Hosting).
  • At least one Interaction Concentrator instance to store data from either a T-Server (for Voice details) or an Interaction Server (for Multimedia details).
  • Any number of additional Interaction Concentrator instances for the Voice, Multimedia, or Outbound Contact data domains, with each ICON storing data from a single data source.

For HA support, provide redundant sets of Interaction Concentrator instances, as shown in Basic High-Availability Architecture, for each Interaction Concentrator depicted in the non-HA deployment.

Legend:

  • Data Source 1 represents either a T-Server (for Voice details) or an Interaction Server (for Multimedia details).
  • Data Source N represents any number of additional, optional data sources (T-Server, Interaction Server, or OCS).
  • DAP roles for the IDBs depend on the data domain:
    • DAP Role 1 is either ICON_CORE or ICON_MM.
    • DAP Role N is ICON_CORE, ICON_MM, or ICON_OCS.
Important
When this topology is deployed in a multi-site environment, temporary outages in network connectivity are less likely to result in a loss of data as long as the ICON application resides on the same site as its data source.

Multiple Data Sources per ICON: Separate Data Domains

The following Figure illustrates a topology in which each ICON monitors multiple data sources for a data domain. This topology “building block” is supported for the Voice, Multimedia, and Outbound Contact data domains.

Multiple Data Sources per ICON: Separate Data Domains

In this topology, the deployment consists of:

  • A single Interaction Concentrator instance to store Configuration details. You can co-locate the Configuration details IDB in the same RDBMS instance with Configuration Database (see Recommendations on Hosting).
  • At least one Interaction Concentrator instance to store data from multiple T-Servers (for Voice details) or Interaction Servers (for Multimedia details).
  • Any number of additional Interaction Concentrator instances for the Voice, Multimedia, or Outbound Contact data domains, with each ICON storing data from multiple data sources of the same type.

For HA support, provide redundant sets of Interaction Concentrator instances, as shown in Basic High-Availability Architecture, for each Interaction Concentrator in the non-HA deployment.

Legend:

  • Data Sources 1-1 through 1-N represent a set of N T-Servers (for Voice details) or Interaction Servers (for Multimedia details).
  • Data Sources N-1 through N-N represent any number of additional, optional sets of data sources, provided that each set consists of data sources of the same type (T-Server, Interaction Server, or OCS).
  • DAP roles for the IDBs depend on the data domain:
    • DAP Role 1 is either ICON_CORE or ICON_MM.
    • DAP Role N is ICON_CORE, ICON_MM, or ICON_OCS.
Important
In a multi-site environment, this topology is susceptible to data delays when temporary outages in network connectivity affect connections between sites. If the ICON instance is not on the same site as one or more of the data sources, this topology might also be susceptible to data loss in a non-HA deployment, if temporary outages in network connectivity affect the connection between a data source and ICON.

Multiple Data Sources per ICON: Combined Data Domains

The following Figure illustrates a topology in which a single ICON monitors multiple data sources of any type. Starting with release 8.5.007, this topology “building block” is supported for any combination of the Voice, Multimedia, and Outbound Contact data domains. In releases earlier than 8.5.007, Genesys Info Mart does not support extracting Voice and Multimedia details from the same IDB.

Multiple Data Sources per ICON: Combined Data Domains

In this topology, the deployment consists of:

  • A single Interaction Concentrator instance to store Configuration details as well as data from any number of data sources for the Voice, Multimedia, or Outbound Contact data domains.

To simplify initial deployment and maintenance, you can use a single ICON to monitor all data sources in the deployment, provided a single ICON is able to handle the workload in your contact center.

For HA support, provide a redundant Interaction Concentrator instance, as shown in Basic High-Availability Architecture.

Legend:

  • Data Source 1 represents a T-Server (for Voice details) or Interaction Server (for Multimedia details).
  • Data Sources 2 through N represent any number of additional, optional sets of data sources of any type (T-Server, Interaction Server, or OCS).
  • The Info Mart DAP role for the IDB depends on the data domains represented in the deployment. At a minimum, the DAP role will include ICON_CFG and either ICON_CORE or ICON_MM.
Important
In a multi-site environment, this topology is susceptible to data delays when temporary outages in network connectivity affect connections between sites. If the ICON instance is not on the same site as one or more of the data sources, this topology might also be susceptible to data loss in a non-HA deployment, if temporary outages in network connectivity affect the connection between a data source and ICON.

Mixed Example — Multi-Site, All Details

The following Figure illustrates a specific multi-site deployment, as an example of how you can combine the various approaches that are described in the preceding diagrams.

In this example:

  • HA is provided for Configuration details and Voice details, but not for the other data domains.
  • The T-Server on Site 1 and the T-Server on Site 2 are monitored by a single Interaction Concentrator instance (on Site 1).
  • Two Interaction Servers, both on Site 2, are each monitored by a separate Interaction Concentrator instance (on Site 2).
  • Two OCS data sources, one on Site 1 and one on Site 2, are each monitored by a separate Interaction Concentrator instance.
Important
There is nothing special about the Multimedia or Outbound Contact topology requirements. The following Figure shows one Interaction Server and one OCS per ICON simply to illustrate the possible topology “building blocks” in a multi-site context. However, multiple Interaction Server or OCS data sources can be monitored by a single ICON, as shown for T-Server.
Mixed Topologies Example — Multi-Site, All Details

The example illustrates the following features:

  • The deployment complies with the minimum requirements for supported topologies, including the additional requirements in releases earlier than 8.5.007.
  • Both sites host a combination of media types.
  • In some cases, multiple data sources of the same type populate a single IDB; in other cases, multiple data sources of the same type each populate their own IDB.

Because the example complies with pre-8.5.007 restrictions on IDB storage, the example does not illustrate Voice and Multimedia details in the same IDB, which occurs when one ICON monitors both T-Server and Interaction Server (see Multiple Data Sources per ICON: Combined Data Domains).

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on 26 April 2018, at 20:51.