Jump to: navigation, search

Scalability and High Availability

This topic discusses options/possibilities for scalability and high availability for the Genesys Interaction Recording solution.

Tip
Click on the diagrams to enlarge them.

<tabber> Scalability=

Scalability


SIP Server uses the same unified media server instances to provide any new media services, and in this case, the recording service.

Scale.png

A media server (MCP) cluster is managed by a pair of Resource Managers running in Active-Active mode. Resource Manager identifies the tenant coming from SIP Server and selects the appropriate IVR Profile for the call. Each MCP instance in the cluster is able to handle call recording for any tenant based on the IVR Profile information.

MCP writes call recording to Amazon S3 or disk storage depending on the deployment type. Amazon S3 being a cloud service is already designed to scale. For disk storage, the premise deployment use a disk storage mechanism such as a disk array that can be scaled for the cluster of media servers. For more information on public keys and encryption, see the Genesys Media Server Deployment Guide.

|-| High Availability=

High Availability


This section describes supported High Availability and failover modes for the Genesys Interaction Recording components. The following diagram illustrates HA architecture:

Gir HA.png

SIP Server

SIP Server can be deployed in an active/hot-standby pair; whenever the primary instance fails, the hot-standby instance will take over and will have knowledge of all established sessions. If a recording session has been established with a recording server, a failure of SIP Server will not affect the operation of the communication and recording sessions.

Resource Manager

Resource Manager is a SIP Proxy that can operate in either active/hot-standby or active/active pair. When there is a failure at the Resource Manager, the remaining instance of Resource Manager will become active and continue to accept incoming requests. The remaining instance will remember the affinity of the recording sessions with Media Server as well as the recording server.

Media Control Platform

When the media is bridged through the Media Control Platform (MCP), MCP becomes a single point of failure for the duration of the communication session. If MCP fails, Resource Manager notifies SIP Server about the failure so that SIP Server can take alternative action on the call. SIP Server first joins the endpoints together to ensure communication session is not interrupted. SIP Server then attempts to record the call again by initiating a new recording session with the same parameters. RM most likely will select another MCP instance while the failed MCP is unavailable.


Web Services and Cassandra

Web Services and Cassandra runs in a N+1 cluster. For more information, see Initializing the Cassandra database.

Recording Processor

The Recording Processor runs in both active-active, and active-backup modes.

Recording Crypto Server

The Recording Crypto Server runs in active-active pair mode.

SpeechMiner

SpeechMiner requires reliable shared storage that can be accessed (read/write) by all SpeechMiner components. The shared folders are mapped as an UNC path on the SpeechMiner machines and all SpeechMiner machines must refer to the same UNC path.

  • SpeechMiner UI—You can deploy N+1 active instances.
  • SpeechMiner Interaction Receiver—You can deploy N+1 active instances.
  • SpeechMiner UPlatform—You can deploy active/standby instances of the Scheduler task on UPlatform. When the active instance fails, the standby instance automatically takes over to become the active instance.
This page was last edited on November 11, 2019, at 14:00.
Comments or questions about this documentation? Contact us for support!