Introduction
This document details Clarity Connect server architecture, high availability configurations, disaster recovery, and geo-dispersed environments.
Server Architecture
Clarity Connect is a software-based contact center system. It consists of several software components that run on dedicated application servers (or, in one case, on Skype for Business Front End servers) along with a SQL server database (Figure 1). This section describes the architecture of a Clarity Connect deployment at a server level and the basic principles of capacity planning for a Clarity Connect deployment.
Figure 1 Server architecture
Capacity Planning
The following questions are useful to ask when preparing to plan for capacity:
- What is the average concurrent call volume expected during peak hours?
- Is the environment globally dispersed?
- Do you want or require a high availability configuration?
- Do you want or require disaster recovery?
- Are your Skype for Business servers on premise or hosted?
- Is the environment federated?
- Do you plan to install Agent Call Rerouter?
To plan for capacity, first determine how many application servers are required by examining the number of concurrent calls you plan to receive and if high availability is necessary.
The number of concurrent calls supported per application server depends on whether the servers are physical or virtual (Table 1). In addition, planning should be based on the peak number of expected concurrent calls. Performance may remain acceptable above this number, but it rapidly becomes unpredictable and can degrade substantially.
| Server Type | Concurrent Calls Supported |
|---|---|
| Physical | 70 |
| Virtual | 50 |
High availability for the application servers requires an N+1 configuration, so one additional application server must be added to the number derived from the peak concurrent call count.
For example, in a deployment where the expected peak concurrent call count is 250, the servers are all virtual, and high availability is required, six application servers are required. A peak concurrent call count of 140 without high availability could be supported by two physical servers.
Network Infrastructure
Since Clarity Connect uses resources spread around the network infrastructure and deals extensively with real-time communication, the latency between network components is critical to the application performing well. Table 2 details the preferred and required ping times between various components.
| Server A | Server B | Rec. Ping | Max. Ping |
|---|---|---|---|
| Primary Application Server | Primary Database | 10 ms | 50 ms |
| Remote Application Server | Primary Database | 100 ms | 300 ms |
| Application Server | “Local” Skype for Business Front End | 50 ms | 150 ms |
| Application Server | “Local” Agent | 50 ms | 150 ms |
| Agent | “Local” Skype for Business Front End | 50 ms | 200 ms |
System Requirements
Clarity Connect is a completely software-based contact center system. This section details the server resources required to run the various components that compose Clarity Connect.
It is possible to deploy Clarity Connect on either physical or virtual servers. Different server resources are necessary depending on whether the servers are physical or virtual, and there are also implications for capacity.
Physical Application Server Requirements
A physical server must conform to the following minimum specifications to run Clarity Connect (Table 3). An application server with the below specifications can handle up to 40 IVR calls or 100 calls connected to agents
| Component | Requirement |
|---|---|
| Operating System | Windows Server 2012 (64-bit only) |
| CPU | 64-bit processor, quad-core, 2.0 GHz or higher (Note: Intel Itanium processors are not supported) |
| Memory | 16 GB |
| Disk | Local storage with at least 100 GB free disk space on a fault tolerant drive array consisting of drives operating at a minimum of 10,000 RPM. Solid state drives may also be used |
| Network | 1 network adapter required (more supported), each 1 Gbps or higher |
Virtual Application Server Requirements
A virtual server must conform to the following minimum specifications to run Clarity Connect (Table 4). An application server with the below specifications can handle up to 40 IVR calls or 100 calls connected to agents.
| Component | Requirement |
|---|---|
| Operating System | Windows Server 2012 (64-bit only) |
| CPU | Four virtual CPU cores. As with Skype for Business server roles with media workloads, CPU cores must not be oversubscribed on the host server hosting Clarity Connect application servers |
| Memory | 16 GB |
| Disk | Local storage with at least 100 GB free disk space on a fault tolerant drive array consisting of drives operating at a minimum of 10,000 RPM. Solid state drives may also be used. |
| Network | 1 network adapter required (more supported), each 1 Gbps or higher. For Hyper-V, use the standard VM network adapter, not the legacy network adapter. |
CPU Core Oversubscription
It is extremely important to avoid oversubscribing host machine CPUs when using virtual servers to host the Clarity Connect application. Because of the intense load placed on the processors by the media stack, oversubscribing physical CPU cores on the host machine (i.e., allocating more virtual processors to virtual machines than are present on the host) will usually have a significant negative performance impact.
Database Requirements
Clarity Connect requires two SQL server databases (Figure 2). These may be collocated on the same server or the same instance with databases used by other applications as long as testing is performed to ensure there is not a negative performance impact.
Figure 2 Database requirements
Clarity Connect supports the following versions of Microsoft SQL Server:
- SQL Server 2012
- SQL Server 2014
- SQL Server 2016
SQL Server Setup
For the most stable experience, it is recommended to set up SQL server mirroring along with a witness server to provide automatic failover; however, Clarity Connect can support any of the following for your SQL server depending on the environment.
SQL Server Replication
SQL server replication involves copying and distributing data from one database to another. The following types of replication are supported:
Snapshot
A snapshot is taken of the entire database and is copied to the subscriber.
Transactional
Once a snapshot is copied, every change is passed on to the subscriber.
Merge
Once a snapshot is copied, the databases keep track of changes are made offline. These changes are then synchronized when simultaneously online.
Peer-to-Peer
As transactions occur, they are executed on all nodes to keep data synchronized in near real-time.
| Pros | Cons |
|---|---|
| Can replicate to multiple servers | Manual failover |
| Can access all databases being replicated | Snapshot can be time consuming if it is VLDB |
| Replication can occur in both directions | Data can get out of sync and will need to re-sync |
SQL Server Mirroring
In SQL server mirroring, the mirror database is an exact copy of the principal database. All new transactions are copied over to the mirror database, and a witness server, which provides automatic fail over, is optional.
| Pros | Cons |
|---|---|
| Automatic failover (with witness server) | Limited to two servers |
| Fairly easy to set up | Mirrored database is set to restore mode (cannot access) |
| Fast failover | None |
SQL Server Log Shipping
In SQL server log shipping, the primary server takes a transaction log and moves it to a backup share on the secondary server, which the secondary server then uses to restore its database. A monitor server tracks all of the details of log shipping.
| Pros | Cons |
|---|---|
| Can log ship to multiple servers | Failover is only as good as the last log backup |
| Secondary database will be read only for reporting | Manual failover |
| Does not require SQL server enterprise | None |
SQL Server Clustering
SQL server clustering allows for one physical server to take over the responsibilities of another physical server that has failed. Data is not copied between servers and it is located on a shared storage (SAN).
There are two types of SQL server clustering. An active/active configuration runs SQL server on both servers. If one fails, the remaining SQL server will fail over.
An active/passive configuration runs SQL server on one server while the other server waits in case of a failure.
| Pros | Cons |
|---|---|
| Can cluster multiple servers | Complex set up |
| Automatic failover | Risk of purchasing hardware that is never used |
| Server level failover compared to DB level | Not necessarily data protection |
SQL Server AlwaysOn
SQL server AlwaysON is not supported during the install process and must be turned on afterward. It combines log shipping and clustering to allow for high availability and disaster recovery. The primary replica is read/write, and the secondary replica is read-only. SQL server AlwaysON provides automatic failover and has both asynchronous and synchronous availability modes.
Skype For Business Infrastructure
Clarity Connect 4.0 is compatible with Skype for Business Server 2015. It is only compatible with Skype for Business Server 2015 Core Components. Only UCMA 5.0 runtime is supported.
Clarity Connect 3.2 is compatible with Skype for Business Server 2015 and Lync 2013. It is only compatible with Lync 2013 Core Components. Only UCMA 4.0 runtime is supported.
Support For Hosted Environments
Clarity Connect supports several possible hosted configurations. If Skype for Business infrastructure is hosted with a third-party Skype for Business hosting provider that is a certified Clarity Connect partner, then Clarity Connect can be hosted in the same environment that contains the customer’s Skype for Business infrastructure (Figure 3).
Figure 3 On-premise configuration
Second, if the Skype for Business infrastructure is hosted with a third-party hosting provider that is not a Clarity Connect partner, or if the customer is using Office 365, the Clarity Connect infrastructure can be hosted separately by a certified Clarity Connect hosting provider, while the users remain on the customer’s hosted environment (Figure 4).
Figure 4 Hosted configuration
This configuration is made possible by Skype for Business federation, and environments configured in this way will be referred to as federated environments.
The first limitation involves the impersonation feature Clarity Connect uses to show the correct identity to the agent receiving a call. In a federated environment, this does not allow display names to be altered when the receiving agent is a federated contact. This means agents in a federated environment may see a SIP URI rather than a display name in the Skype for Business toast message for an incoming Clarity Connect call.
The second limitation is that in a federated environment where users are authenticating with different SIP and network login domains (ex: user@localdomain.com, user@hosteddomain.com), answering calls through the Skype-enabled Dashboard is not supported. Customers with this type of federated setup must use the local Skype for Business client and Remote Session Experience. See Agent Experience for more information.
Several additional Clarity Connect features do not work in a federated environment:
- Direct call proxying
- Agent Rescue
- Opt-in presence state for ACD calls (i.e., available for ACD state)
- Custom presence state for RONA
Exchange UM Voice Mail
Clarity Connect integrates with Exchange UM voice mail to send ACD calls to voice mail boxes and allow transfers to voice mail where appropriate. Accordingly, Exchange UM voice mail must be deployed and configured in order for the voice mail features in Clarity Connect to function. The Exchange UM voice mail endpoint must be routable from the Clarity Connect environment for calls to be delivered there. This means if Exchange infrastructure is hosted in a separate location from the Skype for Business infrastructure, the appropriate network and federation configuration must be performed in order for the voice mail boxes to be reachable.
Generally, if voice mail is working in the Skype for Business client, it will work for Clarity Connect as well.
High Availability & Disaster Recovery
Disaster recovery is an important step to take to ensure minimal interruption of business during a major outage. As a native Skype for Business application, Clarity Connect uses the same approaches as often as possible to high availability (HR) and disaster recovery (DR) as Skype for Business.
Clarity Connect depends on the capability provided by the Skype for Business server and can only be as highly available as the underlying Skype for Business server environment. Because of this, there is little value to deploying Clarity Connect in a highly available configuration alongside a single-site standard edition deployment of Skype for Business server.
A typical Clarity Connect environment consists of the following:
- Microsoft SQL database server, SQL Server Reporting Services (SSRS) required
- Microsoft Lync 2013 or Skype for Business environment (standard edition or professional edition supported)
- X number of application servers (the number will depend on customer requirement)
High Availability
The primary tool for high availability in Skype for Business server is server pooling. Multiple servers with the same role can be grouped together to share load and ensure continued availability if one server in the pool goes down.
Similarly, Clarity Connect application servers can be configured in pools. In the Skype for Business server topology, these pools are set up as trusted application pools.
For a true highly available deployment of Clarity Connect, several items must be considered:
- Underlying Skype for Business architecture
- SIP traffic
- Web traffic
- File shares
- Databases
Active/Active
To deploy Clarity Connect as highly available, a multiple-computer trusted application pool must be created with a unique FQDN, separate from the FQDNs belonging to the individual servers (Figure 5). The number of servers in the trusted application pool must be at least one more than the number of servers dictated by the desired concurrent call capacity.
Figure 5 Active/active configuration
Keep the following in mind:
- Requests for the application will be sent to the unique FQDN.
- A load-balancing method (either DNS load-balancing or hardware load-balancing) must be in place to properly distribute the messages sent to the pool FQDN.
- Web traffic over HTTP/S for Clarity Connect must be load-balanced.
- This requires a hardware load-balancer; DNS load balancing is not supported for this workload.
- Traffic on ports 80 and 443 for the Connect website domain name, which do not need to be identical to the trusted application pool FQDN, should go to the hardware load-balancer.
- Source IP address persistence should be used with a timeout of 30 seconds and round robin server scheduling.
- Pass-through Windows authentication should also be enabled.
Disaster Recovery
The disaster recovery site is a secondary Clarity Connect deployment that has the capability to stand alone should the original deployment become inaccessible. This requires 2xN servers mirroring the application server setup, with new trusted applications and endpoints in a separate pool (Figure 6 and Figure 7). The second site also requires a database which is replicated from the main site. When not needed, the Clarity Connect services in the disaster recovery site should remain in an idle state and should be regularly tested.
Figure 6 Active/passive configuration
When installing the disaster recovery application servers for Clarity Connect 3.2, overrides must be added to the service configurations in the config file. In Clarity Connect 4.0, we support override setting creation on the Advanced Settings page of the administrative website.
In addition to the application server, a replicated database and file share hosting the recordings and voice prompts is required.
In the event of a disaster, follow the instructions below for the best results:
- If any phone numbers must be forwarded to the disaster recovery pool, contact the carrier.
- Delete all endpoints from the main site, and re-create them in the disaster recovery site within the corresponding trusted applications
- Update the DNS entry or load balancer entry for the website to point to the new servers.
- If needed, update the DNS entry for the database to point to the replicated database.
- Update the DNS entry for the file share hosting all voice prompts.
- Start all Clarity Connect services at the disaster recovery site and start placing test calls.
Figure 7 Disaster recovery
Appendix: Server Failure Scenarios
Table 9 depicts server failure scenarios and how they affect incoming and current calls.
| Scenario | Incoming Calls | Current Calls | Details |
|---|---|---|---|
| Single server environment: application server 1 goes down | Incoming calls stop coming into the system | Current calls remain live | If the app server fails in a single server scenario, incoming calls are stopped. Current calls remain live. However, call details for current calls are lost. |
| HA environment: application server 1 goes down | Incoming calls keep coming into the system on app server 2 once the AgentFinder service on app server 2 becomes active | Current calls remain live | In an HA scenario, app server 2 begins taking incoming calls. Calls queued by app server 1 are dropped. |
| Database server goes down | Incoming calls stop coming into the system | Current calls remain live | If the database fails, calls stop coming into the system. Calls currently connected to agents remain live. However, call details for current calls are lost. |
| Front End server goes down | Incoming calls stop coming into the system | Current calls are disconnected | The Front End server hosts the media (voice/IM), and all current and incoming sessions in the system are lost when it goes down. |