Recorder load balancing and failover design

This feature is available in version 8 and later.

Table of Contents

Overview

Verba Recording Servers can be used as a standalone recording solution, or in cooperation with Verba Media Collectors.

When Verba Media Collectors are used, you can build a 2 layer recording architecture, where:

  • a media collector layer collects all necessary media
  • a recorder layer that processes and records media

Complex load balancing and failover configurations are possible between the media collector and the recorder layer.

Media Collectors and Recording Servers

Verba Media Collectors on the media collector layer are able to collect media from

  • network traffic recorded from a network port (e.g. calls with unencrypted SIP, Skinny signaling)
  • network traffic recorded from a network port, extended with signaling from an external source (e.g. signaling from Lync filters)
  • the built-in media proxy, an RTP proxy that terminates media streams and forwarded them to a target (e.g. Lync proxy recording mode, where the Media Collector acts as a middleman in the media stream)
  • the built-in SIP proxy (e.g. a SIP trunk can be routed through a Media Collector).

In turn, the Verba Recording Servers are able to:

  • receive and process media and signaling from Verba Media Collectors
  • create and send call detail records to the database
  • compress and write recorded media to disk
  • upload recordings directly to Media Repositories or external compliance stores

Verba Media Collectors have a very low CPU and disk I/O requirements, while the Verba Recording Servers need more CPU and disk I/O to process and store calls.

In all cases, the Verba Media Collector can send media to:

  • a single recorder
  • multiple recorders at the same time (redundancy)
  • multiple recorders in a load balanced way (load balancing)

The Verba Media Collector makes a recording routing decisions based on the redundancy configuration of the deployed platform.

Routing concepts and configuration

The following concepts are used on the redundancy configuration of a Verba system:

  • Server Weight - defines the relative processing power of a Recording Server, to be used when a weighted load balancing algorithm is used to distribute recordings to Recording Servers. The weight counts when we are load balancing Recorder Servers with the same priority. We distribute the traffic between the Recorder Servers in the ratio of their weight: if there are three Recorder Servers joined to a Verba Proxy with the weight of 1, 2 and 3 then the first will get 1/6 the second will get 2/6 and the third will get 3/6 number of calls. In case of the weight is set to 0 then the Recorder Server will only get calls when there are no other ones online. If there are multiple Recorder Servers with the weight of 0 then the last connected one will get all the calls. If that one goes offline then the second last connected will get all the calls.
  • Recorder Group - list of Recording Servers belonging to the same Recorder group are receiving the same recordings at the same time
  • Recorder Group Priority - the priority of a Recorder Group

Recording routing decision

The following steps are used by a Media Collector when a recording routing decision is made:

  1. it selects the Recorder Group (or groups) with the highest Recorder Group priority
  2. lists the servers included in the group(s)
  3. (if there are no servers, it goes back to step 1 and continues with lower Recorder Group priorities)
  4. it randomly selects a recorder using the server weight (only using servers with the same Recorder Group priority)
  5. it sends recordings to the selected server AND to all other servers in the same Recorder Group

Configuring High Availability

On Verba Recording Servers

On Verba Recording Servers you have to define the

  • list of Media Collectors, this recorder accepts recordings from
  • the weight of this Recording Server as advertised to each Media Collector
  • the Recorder Group of this Recording Server as advertised to each Media Collector

The Verba server configuration tool provides a tool to configure the Media Collector list:

Example configuration (with the parameters seen in the screenshot):

PETER-PC|11112|verba|1vcYm2yq7Fr5WuO3yi9oQQ==|0|1|1|GRPA1

Different Media Collectors can get different weight, however, for easier understanding, it is highly recommended to advertise the same weight for all Media Collectors. One Recording Server could belong to multiple groups, but only one group can be advertised to a certain Media Proxy.

On Verba Media Collectors

On Verba Media Collectors you have to define the

  • list of Recorder Groups and
  • associated priorities for each Recorder Group.

Syntax:

<Recorder Group priority>|<Recorder Group name>

Example configuration:

10|GROUP1
10|GROUP2
1|GROUP3

Different Media Collectors can be configured with different Recorder Group lists in order to configure e.g. more complex load balancing designs

Configuration examples

Example 1 - Three recording servers with load balancing

Requirements

MC1 should load balanced recordings to R1, R2 and R3

Configuration overview

 

List of Recorder Groups on MC1:

1|MGR1
1|MGR2
1|MGR3
(each server belongs to a separate Recorder Group and all groups have the same priority)

List of Media Collectors on R1:

MC1:5, MGR1

List of Media Collectors on R2:

MC1:5, MGR2

List of Media Collectors on R3:

C1:5, MGR3

Explanation

As all recorders belong to different Recorder Groups, all recordings will only be sent once and the weight of the servers are used for load balancing.

Example 2 - Dual recording with failover

Requirements

  • MC1 should send recordings to both R1 and R2 at the same time,
  • however, if none of them are available it should send to R3.

Configuration overview

 

List of Recorder Groups on MC1:

2|MGR1
1|MGR2
(MGR1 has higher priority than MGR2)

List of Media Collectors on R1:

MC1:5, MGR1

List of Media Collectors on R2:

MC1:5, MGR1

List of Media Collectors on R3:

C1:5, MGR2
(note: this server is not in MGR1, but in MGR2)

Explanation

R1 and R2 servers are part of MGR1, therefore will get the same recordings at the same time. MGR1 is also higher priority than MGR2, therefore MGR2 will only get recordings if MGR1 is no server from MGR1 is available.

Example 3 - Two sites dual recording with site-failover to each-other

Requirements

  • MCA and MCB are Media Collectors in two separate data centers (A and B). RA1, RA2 recorders are on site A, while RB1 and RB2 are on site B
  • The sites are running in an active-active setup with calls passing by both Media Collectors, those should send recordings to both servers on the same site
  • however, if none of the local servers are available, recordings should be sent to the other site
  • When recordings are sent to the other site, only one copy should be sent to lower bandwidth

Configuration overview

 

List of Recorder Groups on MCA:

10|MGRA
1|MGR-RB1
1|MGR-RB2
(MGRA consists of the local servers, so it is higher priority)
(MGRB-R1 and MGRB-R2 will consist only one server, and since their priority is the same, they will be load balanced)

List of Recorder Groups on MCB:

MGR-RA1, 1
MGR-RA2, 1
MGRB, 10
(configuration on the other site is reversed)

List of Media Collectors on RA1:

MCA:1, MGRA
MCB:1, MGR-RA1
(Note how different groups are advertised to different Media Collectors)

List of Media Collectors on RA2:

MCA:1, MGRA
MCB:1, MGR-RA2

List of Media Collectors on RB1:

MCA:1, MGR-RB2
MCB:1, MGRB

List of Media Collectors on RB2:

MCA:1, MGR-RB2
MCB:1, MGRB
(note: this server is not in MGR1, but in MGR2)

Explanation

From the perspective of MCA, local servers belong to a single group, remove servers belong to two groups. MCB has the same list reversed. On both MCA and MCB the group with the two local servers have higher priority, while the servers on the other site are listed as Recorder Groups, that have the same priority and only hold a single server.

By advertising different groups to different Media Collectors, the recording servers achieve that the local recorders will be preferred until at least one of them is up, otherwise, the recordings will be load balanced to one of the two remote servers.