Typical Topologies

There are a number of options available for the QMS Database architecture. For QMS in High Availability mode, the minimum requirement are two SQL Server instances where one must be SQL Standard Edition or Higher. The second instance can utilize SQL Express. These database instances can either be co-located with the QMS software or hosted on dedicated or existing SQL Server systems. SQL Server clustering options are only available with Enterprise Edition and QMS can only support SQL Server 2016 or higher in clustered mode. This is due to a limitation in earlier SQL Server versions that does not support Microsoft’s Distributed Transaction Coordinator with cluster resource groups. Other options and variations may exist, but below are three typical options for QMS database architecture in High Availability mode.

The next component to consider is the QMS Data Service. The Data Service coordinates all database interaction between the Call Recording Service, Desktop Agents, and other QMS components. Only the Data Service interacts directly with the database. The Data Service also provides access to the QMS Administration pages. In High Availability mode, two Data Services are deployed to separate servers. The Data Service deploys both the Data Service itself as well as the web client running under IIS.

When QMS is configured in HA mode, the Data Servers become identified as a node, which contains a primary and secondary Data Service. Call Recording Service and other components reference the Data Service Node instead of individual services. At that point, QMS will manage and coordinate communication and failover between the primary and secondary Data Services in the node.

The QMS Administration pages may be accessed from either the primary or secondary server. Since the underlying data and communication is duplicated across either server, there will be no difference when managing from either location. If the primary system goes, down, the administration pages will need to be accessed from the secondary. If desired, a single administration URL can be accomplished using simple DNS failover, but that is outside the scope of QMS High Availability.

Finally, both Data Services in the node are configured to point to the same primary and secondary databases. Either Data Service within the node can access the primary database and will automatically failover to the secondary when there is a system failure. Typically there will only be two Data Services configured in one node, but it is also possible to have multiple Data Service Nodes in an HA deployment. The diagram below illustrates the typical topology.

Similar to Data Services, Call Recording Service pairs are also configured as nodes. Each Call Recording Service is installed on separate servers. Often these are co-hosted with the Data Service pairs. Once the node is configured, the Call Recording Service is accessed by the node and not by individual CR Services. Not all PBX types are supported with High Availability. This is primarily due to the PBX’s ability to support a redundant and highly available topology, which QMS assumes is in place. Each Call Recording Service will be configured with its own Media Processing Service or Media Processing Service Pool. Additionally, the Call Recording Service is configured to have a Remote Storage Location, which should be a redundant and highly available file system. Call Recordings will initially be written to the local system disks on each of the CR Servers. Once the call is complete the file is sent to the Media Processing Service for conversion, during the conversion process, the files are moved to the Remote Storage Location. This location should be available and accessible by all Media Processing Services. QMS will reconcile which of the two redundant recordings are saved and at that point on, only one file is written to the remote storage location. If that file system is not redundant, then there is potential for loosing recording data. The diagram below describes a typical HA deployment with Call Recording Services and Media Processing Services.

Other deployment topologies exist, but these are the typical scenarios.