CX High Availability
CX Core is deployed on a Kubernetes infrastructure. For high availability, it requires four virtual machines in the same data centre.
Control Plane is deployed on three VMs and the reporting VM is separate.
The workload is distributed across 3 Worker nodes. To increase redundancy, more worker nodes can be added.
All the application components (stateless) are deployed in Kubernetes
The Statefulsets comprising of underlying data (Mongo,Redis, etc) are setup as system services in HA mode.
Limitations
Out of three nodes, at least two nodes must always be up and connected for the cluster to function. More nodes can be added if required. For example solution can be deployed on five nodes instead of three, which will allow the solution to keep functioning as long as two out of five are available.
HA is not supported for Voice. Manual intervention is required in case of failure.
The reporting server is deployed on a single node. If the reporting server goes down, reporting will not be accessible until the reporting server is restored. No data loss occurs in the meantime. If an HA for the reporting server is required, a redundant deployment on additional hardware, along with additional professional services, will be required.
Deployment Prerequisites
At least four VMs.
Full network connectivity between all nodes.
Hardware Requirement
The worker node hardware sizing for CX in the table below can handle workloads of up to 100 concurrent agents or 300 concurrent conversations.
CX Core, Channels, and Add-On modules are collocated on the same VM(s) to optimize infrastructure.
Resource requirements should be adjusted based on the number of enabled channels, the expected workload (agents/conversations), and the selected Add-On features.
Reporting and Voice profiles are deployed on separate VMs due to their isolation and specific workloads
Com
Profile | vCpu | vRam | vDisk (GiB) | Notes |
|---|---|---|---|---|
CX Core | 3) | 6 | 200 (100+100) | Required. Deployed across 2 VMs (CX A & CX B) for High Availability |
Digital Channels | 1 | 2 | 20 (10+10) | Included within CX VMs (A & B). Sizing supports 3 digital channels. Increase if additional channels needed. |
Reporting | 8 | 16 | 500 (250+250) | Required, non-HA |
Voice | 8 | 16 | 300 (150+150) | Optional, non-HA |
WFM ADD-ON | 4 (2+2) | 8 (4+4) | ||
QM ADD-ON | 6 (3+3) | 12 (6+6) | 500 (250+250) | Refer to this document to determine the hardware requirements for additional QM workload. |
Survey ADD-ON | 4 (2+2) | 8(4+4) | 20 (10+10) | |
Campaign ADD-ON | 6 (3+3) | 12 (6+6) | 100 (25 +25) | |
Scripted Bot ADD-ON | 8 (4+4) | 16 (8+8) | (150+150) | |
Autonomous Bot ADD-ON |
Profile | vCpu | vRam | vDisk (GiB) | Notes |
|---|---|---|---|---|
CX Core | 6 (3+3) | 12 (6+6) | 200 (100+100) | Required. Deployed across 2 VMs (CX A & CX B) for High Availability |
Digital Channels | 2 (1+1) | 4 (2+2) | 20 (10+10) | Included within CX VMs (A & B). Sizing supports 3 digital channels. Increase if additional channels needed. |
Reporting | 8 | 16 | 500 (250+250) | Required, non-HA |
Voice | 8 | 16 | 300 (150+150) | Optional, non-HA |
WFM ADD-ON | 4 (2+2) | 8 (4+4) | ||
QM ADD-ON | 6 (3+3) | 12 (6+6) | 500 (250+250) | Refer to this document to determine the hardware requirements for additional QM workload. |
Survey ADD-ON | 4 (2+2) | 8(4+4) | 20 (10+10) | |
Campaign ADD-ON | 6 (3+3) | 12 (6+6) | 100 (25 +25) | |
Scripted Bot ADD-ON | 8 (4+4) | 16 (8+8) | (150+150) | |
Autonomous Bot ADD-ON |
Profile | vCpu | vRam | vDisk (GiB) | Notes |
|---|---|---|---|---|
CX Core | 6 (3+3) | 12 (6+6) | 200 (100+100) | Required. Deployed across 2 VMs (CX A & CX B) for High Availability |
Digital Channels | 2 (1+1) | 4 (2+2) | 20 (10+10) | Included within CX VMs (A & B). Sizing supports 3 digital channels. Increase if additional channels needed. |
Reporting | 8 | 16 | 500 (250+250) | Required, non-HA |
Voice | 8 | 16 | 300 (150+150) | Optional, non-HA |
WFM ADD-ON | 4 (2+2) | 8 (4+4) | ||
QM ADD-ON | 6 (3+3) | 12 (6+6) | 500 (250+250) | Refer to this document to determine the hardware requirements for additional QM workload. |
Survey ADD-ON | 4 (2+2) | 8(4+4) | 20 (10+10) | |
Campaign ADD-ON | 6 (3+3) | 12 (6+6) | 100 (25 +25) | |
Scripted Bot ADD-ON | 8 (4+4) | 16 (8+8) | (150+150) | |
Autonomous Bot ADD-ON |
Network topology
For load balancing of control planes, consider any of the following three options.
External Load Balancer (ELB) | A Load balancer is used for routing the traffic to the Kubernetes cluster. For a layer-7 load balancer, you may use NGINX reverse proxy, HAproxy, or any available load balancer. For setting up an HA cluster using external load balancer, see High Availability using External Load Balancer |
|---|---|
KubeVIP | Kube-vip provides Kubernetes clusters with a virtual IP and load balancer for both the control plane (for building a highly-available cluster) and Kubernetes Services of type LoadBalancer without relying on any external hardware or software.High Availability with Kube-VIP |
DNS | DNS can be configured to point all the traffic of a domain to any of the needed Control-Plane Nodes High Availability with DNS |