VUE server supports 1:1 and N:1 redundancy to achieve high availability using redundancy clusters (RC). A redundancy cluster is a group of VUE application servers in which one or more VUE servers performs the active role while only one server performs in a standby role. When the standby VUE application server detects a failed active server, it takes over the failed active VUE server and achieves high availability.

The standby server stores the configurations (and ACCP state) of up to ten active servers. Changes to the configuration of any active servers are automatically synchronized with the standby server within one second

In a 1:1 redundancy cluster, the active server receives and transmit video/data streams while the standby server only receives video/data streams (all output TS on the standby server is dropped by the server through the use of IP tables). The standby server continuously listens to all the active servers making it a hot_hot cluster.

In an N:1 redundancy cluster, the standby server does not actively process video until there is a failover where it assumes the configuration of the failed active server at that time. The Auto Failback feature in an N:1 redundancy cluster enables the recovered Initial Active Server to automatically revert back to the Initial Active Server from the Standby Server. This will free-up the Standby server as soon as possible making it again available for the cluster. You can set the auto failback delay time period for the recovered initial active role to revert to the initial active role freeing the standby server.

In a 1:1 cluster, there is only one active server to be backed up by the standby server. Hence, the standby assumes the active server's configuration and processes video, but does not transmit anything on its outputs.

In an N:1 HA redundancy cluster, a recovered initially active server will assess its own health and the health of the current active standby server before resuming the active role. This enhancement allows the system to stay on a healthy standby server if needed, preventing unnecessary service interruptions.

The initial standby server must have equal or more number of cores, equal or more memory, and equal or more interfaces than the initial active servers. VUE performs compatibility checks to ensure the initial standby has equal or more resources than the initial active server. VUE informs you if the initial standby server resources are insufficient to backup every initial active server within the cluster.

The VUE servers within an RC share health status information by using Heartbeat (HB) protocol. The HB protocol provides information about each node’s health status, status of its NICs, current state (for example, failed or unavailable), ID, readiness to assume active role if an initially active server, readiness to assume standby role if it is was assigned as the initial standby server. Heartbeats are exchanged every 100 ms. Failure to receive a HB signal within the configured heartbeat interval (default is 2000 ms) period is considered as a failure of the active server causing the standby server to take over. This interval is configurable from 300 ms to 5000 ms. CommScope recommends to configure two HB interfaces on each server to prevent unnecessary failover due to loss of network connectivity (for example, switch port failure, switch power loss). As long as a HB is received from one of the interfaces within the configured HB window, a failover will not be triggered unless the HB protocol indicates an unhealthy condition exists on the active server (for example, failed interface).

The initial standby server supports up to 2 receive HB UDP stream and 2 transmit HB UDP streams from each initial active server.

Each VUE Application Server contains an agent called the VUE Application Monitoring Service (VAMS) which is responsible for monitoring the particular node and fetching configuration changes made by the VUE controller. VAMS also works in conjunction with a distributed cache (REDIS) to maintain configuration synchronization between active server(s) and the standby server when HA is enabled.

You can choose multiple initial active servers during the creation of the redundancy cluster by choosing the Hot_Cold RC type on the Element Manager (EM). The initial active servers maintain all the transport streams, mappings, Auxiliary Core Control Plane (ACCP), and SDV configuration. Any configuration change in the initial active server is synced with the standby server automatically. The initial active servers can have streams and mappings configured prior to the creation of the RC. The configured streams and mappings on the initial active server will be synced to the initial standby server when the RC is created. You cannot configure any streams or mappings on the initial standby server.

To facilitate the configuration and failover, you must configure the input/output interfaces with VIPs. This allows the same transport stream or mappings to be configured on both servers. VUE utilizes IP tables to block all output (ARPs, ping, data Tx) on the standby server. This means that only the management interface can have a static IP assigned. All other interfaces used by the VUE servers utilizes a VIP.

You can add new servers during the creation of an RC.

You can delete or modify a server or a redundancy cluster through the EM based on your system requirements.

You can manually initiate a failover for scheduled maintenance, such as a software upgrade.

When HB communications are re-established, and assuming both servers are healthy at that time, the server that was the first server to become initially active (state retained by the system and shared using the HB protocol) as part of the RC remains as an active server, and the other server assumes a standby role. Alternatively, if one of the active servers is observed to be in a degraded state after HB communications is re-established, the healthy server remains active, and the unhealthy server assumes the standby role.