FeaturesLync

Lync recording redundancy in Verba 8

By October 31, 2014 August 3rd, 2017 No Comments

Verba 8 Gearing Up

A new high availability model has been implemented in Verba 8. You are able to separate media collection from actual recording, so you can build a two layer, scalable and redundant recording system. It is a perfect Microsoft Lync recording redundancy solution, however it also provides improved HA capabilities for all our standard passive and SIP recording solutions. Here is a high level view of the new solution.

This post is part of our Gearing up for Verba 8 series.

Lync recording redundancy with media collectors

If you have used Verba 7 with Lync, you have experienced the first version of this new architecture, when you deployed our remote traffic capture or proxy recording solution.

In Verba 8, Verba Recording Servers can be used as a standalone recording solution (as before), or in cooperation with Verba Media Collectors.

 

When Verba Media Collectors are used, you are essentially building a two layer recording solution, where:

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

 

Complex high availability scenarios are possible between the media collector and the recorder layers:

  • simultaneous recording streams – when Verba Media Collectors are sending streams to multiple Verba Recording Servers at the same time
  • failover – when Verba Media Collectors start sending streams to the next available server when the currently used server is not available
  • load balancing – when Verba Media Collectors are distributing sessions between multiple recorders to increase availability

 

In this new solution: you can start combining the above modes in a single system. Take an extreme case: you can load balance between two groups of recorders on a local site (that get simultaneous streams), then fail over to remote site and send single streams to a set of load balanced recorders, when all recorders on the local site are down. With such a design, you can address, scalability, redundancy and even the fact that bandwidth to a remote site is limited.

Verba Media Collectors and Verba Recording Servers

Verba Media Collectors and Verba Recording Servers are able to work in multiple modes to fit your UC deployment.

 

Verba Media Collectors in the media collector layer are able to collect media streams in multiple ways:

  • passive network recording – network traffic recorded from a network port (e.g. calls with unencrypted SIP, Skinny signalling)
  • passive network recording with external signalling – network traffic recorded from a network port, extended with signalling from external source (e.g. signalling from Lync filters)
  • RTP proxy – this built-in media proxy is able to terminate media streams and forward them to the original target (e.g. in our Lync proxy recording mode, where the Verba Media Collector acts as a middleman in the media stream)
  • SIP proxy – e.g. a SIP trunk can be routed through a Verba Media Collector

 

The collected streams are forwarded to one or more Verba Recording Servers, in turn the Verba Recording Servers are able to:

  1. receive streams – receive and process media and signalling from Verba Media Collectors (and signalling sources like our Lync filters)
  2. store conversation records in database – create and send call/conversation detail records into the database
  3. write media to disk – compress and write recorded media to disk
  4. reliably upload to a repository – recordings directly to Media Repositories or external compliance stores (in a secure, buffered way)

 

When designing a solution, you can take into account, that

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

The low CPU and disk I/O requirements of Verba Media Collectors, make it a feasible best practice to install those on your UC production systems (e.g. your Lync Mediation or Edge servers).

How the recording routing decision is made?

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

  • a single recorder
  • multiple recorders at the same time (stream mirroring)
  • multiple recorders in a load balanced way (load balancing)
  • to the first available recorders in a priority list (failover)

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

 

The following new 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
  • mirror group – list of Recording Servers belonging to the same mirror group are receiving the same recordings at the same time
  • mirror group priority – the priority of a mirror group

 

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

Step 1 – it selects the mirror group (or groups) with the highest mirror group priority (note a mirror group might contain only one server)

Step 2 – it lists the servers included in the group(s) (if there are no servers, it goes back to Step 1 and continues with lower mirror group priorities) – achieves failover

Step 3 – it randomly selects a recorder using the server weight (only using servers with the same mirror group priority) – achieves load balancing

Step 4 – it sends recordings to the selected server AND to all other servers in the same mirror group – achieves stream mirroring

High availability examples

This system is able to fulfil many HA requirements. Let’s take a look at two possible examples:

Three recording servers with load balancing

A very simple scenario. One Media Collector can load balance streams between 3 Recording Servers. In this case each recorder will belong to different mirror group, therefore recordings will only be sent once and the weight of the servers are used for load balancing.

Dual recording with failover

Here we both required mirrored recording streams sent to two recorders (R1 and R2), but also a failover to a 3rd recorder (R3), when none of the primary ones are available. To achieve this, R1 and R2 servers will be part of the same mirror group, therefore will get the same recordings at the same time. To achieve failover to R3, another mirror group is created with lower priority, that will only include R3.

There are lot more possibilities with multiple sites, site failover and load-balancing, if you are interested in more details, please contact one of our experts today.