High-Availability Configuration

VGSx High-Availability Configuration

Scaling VGSx will result in multiple VGSx services running in parallel as shown in the example deployment sketch below. Each VGSx should be connected to each of the SIPREC servers and a load balancer should be used to distribute the calls from the Session Border Controller(s) and the SIPREC Servers.

Connecting each SIPREC server to every VGS will result in all VGS servers being aware of all the calls in the system. At the point where a call is to be analyzed, an action will be sent to a single VGSx. This will be the only VGS which processes the call. As a result, all status requests for the call must be sent to the same VGS server as other VGS servers will be unaware of the analysis status. To support this, the VGSx will set a HTTP cookie in the response to the action. The expectation is that the load balancer (load balancer 2 in the diagram) will balance requests from the application to the VGSx servers and will use the cookie to redirect calls to the same VGSx server for that call.

From a development perspective, when the application calls the VGSx requesting analysis on a call, an HTTP cookie will be returned from VGSx. This cookie must be supplied with all subsequent requests to VGSx to get the status for that call. When an action is sent for a new call, the earlier cookie must NOT be supplied, allowing the load balancer to distribute the call to the next VGSx in rotation. This way, the load across the VGSx servers can be managed and VGSx servers removed from the pool, when required, without impacting on any current calls.

Cookie Details and Configuration Settings

The following are the HTTP cookie details which can be reconfigured in sentinel-vgsx/config/application.properties

cookie.name=SEN_VGC

cookie.maxAge=1500

cookie.secure=false

cookie.httpOnly=false

cookie.path=/

VCDx High-Availability Configuration

The VGSx splits up audio to be analyzed into audio speech segments where each segment is sent to the VCDx for analysis. When multiple VCDx instances are configured to run in parallel, each segment may be sent to a different VCDx instance. VCDx averages probabilities as to whether the call is genuine across the entire call. As such, a centralized way of storing statistics about a particular call is required when the call analysis is shared among multiple VCDx instances. Redis is used as a central cache for this information.

Configuring Redis

On-premise installations of VCDx can operate in two modes:

1. High-availability (HA) mode. Uses a Redis server for distributed caching of call information.
2. Stand-alone mode. Does not use a Redis server. This mode is advised when only one instance of VCDx is going to be used.

To configure Redis for HA mode:

Edit the sentinel-vcdx/config/application.properties file as follows:

1. Set the sentinel.onprem.should.use.redis property to true.
2. Add a spring.main.allow-bean-definition-overriding=true property and set the host and port of the Redis server that is going to be used for the on-premise VCDx instances:

spring.data.redis.host=

spring.data.redis.port=

spring.data.redis.ssl.enabled=

spring.main.allow-bean-definition-overriding=true

sentinel.onprem.should.use.redis=true

After finalizing the setup, restart VCDx so that Redis will be used for storing call information to allow probability scores to be averaged for the same call across multiple VCDx instances.