Deployment Models
Remote Database Deployment
Since PCS application and database servers run on separate machines, make sure to share the report downloads folder on the PCS machine with the remote DB machine to download survey reports on the local machine from PCS.
Also, note that the ‘Write’ permissions must be provided on the shared folder to the user account.
Simplex/Non-HA Deployment
For a non-redundant deployment, the Docker images are deployed on a single server with a single point of failure.
High Availability (HA) Deployment
For High Availability, a redundant deployment is performed.
The following table lists how the solution components support PCS deployment in a High Availability mode.
Component | Description | Notes |
|---|---|---|
PCS IVR Script | PCS IVR script accesses PCS with a virtual IP in case of a redundant deployment. So the IVR queries PCS for an active survey. When the failover happens, it is seamless for the IVR so the IVR client application only has one single IP to access PCS at any time. | While using the Finesse version prior to 11.0, the survey script will be triggered only when the agent ‘transfers’ the call by using PCS gadget, instead of hanging up from the native Finesse gadget. |
PCS Call Transfer Gadget | PCS Gadget supports High Availability. However, the survey for an active call won’t be played in the event of a failure. The survey function will work normally for all the subsequent calls. | |
SMS connector | In the HA deployment, this component is supposed to be deployed on both VMs. So if deployed on side A and side B, the SMS connector on side A continues to send messages to the SMS gateway and keeps logging it's heartbeat/state in the database. On the other hand, the second instance on side B keeps checking the status of the side A instance via database. If the instance on the side A is found to be down at a certain time (if there are no more status updates in the DB within a defined time range), the second instance on side B automatically takes over and starts sending messages to the gateway. | |
Survey API for third-party chat engine | The client application always has a virtual IP to access PCS. So if at any time, the failover happens, PCS handles it internally to send the request to the active instance while the 3rd-party chat application doesn’t have to worry about it. |
Database failover with MS SQL
A two-node SQL Server is required to be set up in a failover cluster mode. ExpertFlow applications will connect to the MS SQL Server cluster via a SQL user, to create the application database schema. The cluster should be accessible through the unique SQL Server cluster VIP (Virtual IP).
ExpertFlow requires a SQL user with the database role db_owner on each of the EF application’s databases.
Application failover
EF applications are deployed on a two-nodes/VMs cluster with one node being the Primary and the other being the secondary to provide fault tolerance and high availability on VMs. Both of the two machines have everything running on them, thus, acting as a replica of each other. Each node of the cluster exposes a VIP (Virtual IP, using VRR protocol) which will route the service request to the primary node at any point in time.
The two nodes are synchronized with KeepAlived enabled such that as soon the primary node becomes down, the secondary node becomes the new primary. Thus, the failover from primary to secondary happens nearly seamlessly.
The overall architecture will look like below.
Note
Each Node represents a VM.
For the hardware resilience, these nodes/VMs should be set up on two physical servers. If all the VMs are deployed on the same physical server, it will provide only VM level resilience and fault tolerance.
Failover scenarios
When the Primary or Secondary node is down | |||||||
The system will switch to the other active node. | |||||||
Impact | All applications will continue to work after the failover. However, the web user on the admin portal will have to re-login. All read/write operations on the application will continue to function. No impact on live calls. With the MSSQL Server failover cluster, there’ll be no loss of data. | ||||||
Recovery | For the integration with IVR and web chat solution, since the APIs are deployed on two sides with a virtual IP to be accessed, the automatic failover to the secondary instance becomes seamless for the calling party. | ||||||
When Primary and Secondary nodes are down | |||||||
Impact | All applications and services will not work. | ||||||
Recovery | Manual intervention is required to recover the system. | ||||||