Deployment

The first component that needs redundancy is the PBX itself. If the telephony network architecture relies upon one set of servers, then obviously this becomes a single point of failure. A true Highly Available topology would provide redundancy for all components. The current version of QMS supports the following PBXs in HA mode:

Other PBX types may work in HA mode, but there may be licensing and other considerations with deploying in those environments. This document will not detail how to set up these PBXes in a redundant manner. Simply note that QMS will expect this to be redundant.

At least two supported Windows servers are required for a redundant architecture. Each server will be home to one QMS Media Processing Service, one QMS Call Recording Service configured as an HA node and one QMS Data Service configured as an HA node. It is also possible to deploy additional Media Processing, Call Recording and Data Services on additional servers if desired. But at least two of each service is required for a redundant deployment. In addition to the services, the Data Service installation will install the QMS Administration web application, which will also exist on the Data Service servers and requires IIS. This provides a highly available administration system as well. Please refer to the QMS Installation Guide for supported systems, pre-requisites, and installation instructions.

Again, at least two instances of SQL Server are required installed on separate servers to provide redundancy. At a minimum, one SQL Server must be Standard Edition or higher. The second SQL Server instance can use SQL Express. These instances can be co-hosted with the QMS Services on the two QMS Servers. They may also be hosted on dedicated SQL Server systems. SQL Clustering with Always On features could be used with SQL Server 2016 or later, but earlier versions of SQL Server are not supported with clustering.

The standard deployment for QMS data redundancy uses SQL Server’s Merge Replication. With this feature, two SQL Server instances are connected as a Publisher and Subscriber instance. QMS is configured to send data to the Publisher in normal instances. If the Publisher fails, QMS will automatically send data to the Subscriber. SQL Server itself will keep track of any data written to either the Publisher or Subscriber and will automatically replicate that data to the other server. When one instance is down, the other instance will keep track of the non-replicated data until the instance comes back up at which point all the data is replicated across both servers. For more details on setting up merge replication, please refer to the "Setup Merge Replication between the Primary and Secondary SQL Servers" step in the Step-by-Step HA Deployment Instructions.

The final component in the HA topology is a redundant file system where data is mirrored across two or more storage devices. Again, there are many options that can be used to provide data redundancy. This document will not outline how to setup a redundant file storage as it is outside of the QMS architecture. In QMS, a remote file storage is configured and is expected to point to a redundant file system. All call recordings, screen recordings, and other files stored by QMS will be written to this location.

In a highly available installation that records agent screens it may be desirable to prevent screen recording duplication to conserve resources in the network and at the agent desktop. Setting SuppressScreenRecordingAtSecondary in the Advanced Settings section of the Recording Service tab on the primary call recorder will prevent communication between a desktop agent and the secondary recording stack. It should be noted that this setting should only be administered at the primary call recorder and agent screens will not record in the event the primary call recorder isn’t functioning.