Jump to: navigation, search

Architecture

About Support for Business Continuity

Business Continuity provides protection to enterprise operations in the following situations:

  • Disaster Recovery (Site Failure)
  • Networking Failure Between Sites
  • Graceful Migration

For information about these functions, refer to the Business Continuity section of the SIP Server High-Availability Deployment Guide.

Genesys Info Mart supports Business Continuity by providing contact-center reporting in all three scenarios. In other words, the replicated database setup described in this document ensures that Genesys Info Mart continues to gather and process data when one of the sites fails, a network connection fails between the sites, or another Genesys component that supports Graceful Migration is migrated in this manner.

Note, however, that Genesys Info Mart, as an individual component, only supports the Disaster Recovery (Site Failure) scenario. For this reason, instructions in this document do not cover the switchover between Genesys Info Mart instances during a networking failure or for the purposes of application migration.

The Genesys Info Mart setup that is described in this document can be used in conjunction with the Genesys SIP Business Continuity solution.

Sample Two-Site Architecture

A typical Business Continuity architecture relies on the deployment of two or more sites to ensure continuous enterprise operations in the event of a site failure. Particular deployments may vary in distribution of Genesys components across the sites.

The sample Business Continuity architecture that is described in this section uses a synchronized, two-site deployment, where Genesys switch and server architecture is mirrored at each site in an active-active configuration, so that any agent can log in to either switch, at any time. One or several Oracle RDBMS instances are deployed at each data center to host Genesys databases.

This architecture is recommended for use with the Genesys-provided SIP Business Continuity solution. To learn about the overall SIP Business Continuity architecture, refer to the SIP Business Continuity Architecture.

GIMArchitectureBC.png

To provide reporting in this deployment, Interaction Concentrator at each site collects unique data from the local data sources. For example, SIP Server can serve as a data source for the Voice data domain and Interaction Server can serve as a data source for the Multimedia data domain. Configuration Server Proxy serves as a data source for the Configuration data domain. Outbound Contact Server (OCS) serves as a data source for the Outbound data domain in an environment with Outbound Contact.

An Interaction Concentrator instance consists of ICON server (or just ICON) and Interaction Database (IDB). ICON operates at the same site as the data source and stores data in a corresponding IDB. A separate instance of Interaction Concentrator is required at each site to store Voice or Multimedia details. Another, separate instance of Interaction Concentrator is required at each site to store Configuration details. Depending on the Outbound Contact data volume, one or more instances of Interaction Concentrator per OCS are required at each site to store Outbound details. Each IDB in the deployment uses a separate, dedicated database schema.

To provide high availability (HA) of reporting data, a redundant pair of Interaction Concentrators receives events from the same data source. Both ICONs in an HA pair operate in parallel as stand-alone servers; they process incoming data independently and store data in two independent IDBs. In this sample architecture, one IDB from the HA pair is located at the same (local) site as the HA pair of ICON servers, while the other IDB from the HA pair is located at the other (remote) site.

The active Genesys Info Mart at the primary site (Site 1) accesses all the IDBs at both sites and, for each HA pair, extracts data from the IDB that has the best quality data from a particular data source. The extracted data is stored at the active Info Mart database at Site 1. The data from the Info Mart database at Site 1 is replicated to the standby Info Mart database at Site 2 by means of Oracle GoldenGate. An active instance of Genesys Interactive Insights (GI2) at Site 1 provides historical reports for all users.

The standby Genesys Info Mart at Site 2 can be brought into service in the event that Site 1 fails. This Genesys Info Mart must not access the Info Mart database while replication is in progress. (To prevent accidental access, do not configure the database connection until the server at Site 2 has to be brought into service.) A standby GI2 instance at Site 2 can be brought into service in the event that Site 1 fails.

In the event that Site 1 fails, the disaster recovery procedure for the site must be started. As part of this procedure:

  • Genesys Info Mart at Site 2 is activated and configured to write data into the Info Mart database at Site 2.
  • The replication configuration at Oracle GoldenGate at Site 2 is modified to account for the absence of the replication source.

When the failed site, or its replacement, is back in service, Oracle GoldenGate replication must be set up once again between the active Info Mart database and the standby Info Mart database.

This page was last edited on September 5, 2013, at 15:54.
blog comments powered by Disqus