Scalability and High Availability
This topic discusses options/possibilities for scalability and high availability for the Genesys Interaction Recording solution.
SIP Server uses the same unified media server instances to provide any new media services, and in this case, the recording service.
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.
This section describes supported High Availability and failover modes for the Genesys Interaction Recording components. The following diagram illustrates HA architecture:
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 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.
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 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 indexer task on UPlatform. When the active instance fails, the standby instance automatically takes over to become the active instance.
- SpeechMiner Index folder—You can configure an automatic process that restores the last daily index backup in case of an index failure.