High availability and cache mirroring

Last Updated : Oct 16, 2025 |

Avaya Oceana® provides the Campus High Availability (HA) functionality. Using this functionality, Avaya Oceana® can automatically recover from a single point of failure.

Note:

In this chapter, the terms virtual machine and node refer to a virtual server that hosts the Avaya Breeze® platform.

This functionality provides mitigation for the following failure scenarios:

  • A single Avaya Oceana® process outage at a time

  • A single virtual machine outage at a time

  • A single physical server outage at a time

  • A single network link outage at a time

The advantages of Avaya Oceana® HA are:

  • Processes new contacts after the outage.

  • Agents and supervisors can operate after the outage.

The following table lists the concepts used in Avaya Oceana® HA:

Table 1: High availability concepts

Concept

Description

Failure Event

Specifies one of the following single failure scenarios:

  • Failure of a single process

  • Failure of a single virtual machine

  • Failure of a single physical server

  • Failure of both the network links to a virtual machine

  • Failure of all the network links to a single physical server

Network Failure

Specifies one of the following network failures:

  • Failure of all network links to a virtual machine.

    For example, the failure of a virtual network adaptor on a virtual machine isolates the virtual machine from the network.

  • Failure of all network links to a single physical server.

    For example, the failure of all network adaptors on a physical server isolates the physical server from the network.

Avaya Oceana® does not detect the network latency directly. The Avaya Breeze® platform detects severe network issues and triggers a virtual machine or process failover. When a network failure isolates a virtual machine or a physical server, manual intervention is required before the virtual machine, or physical server can reconnect to the network.

When a network failure isolates a virtual machine or a physical server from the network, Avaya Oceana® identifies and shuts down WAS and GigaSpaces on the isolated virtual machine or physical server.

Process Failure

Specifies the failure of a single process in Avaya Oceana®.

For example, the failure of the WebSphere Application Server process or a GigaSpaces PU instance.

Server Failure

Specifies the failure of a single virtual machine or a single physical server. This failure implies that all process instances within the virtual machine or the physical server are lost.

Avaya Oceana® supports a single failure event. Therefore, if two simultaneous failure events occur, Avaya Oceana® components cannot operate in HA mode.

Avaya Oceana® supports HA in the following failure scenarios:

  • Network failure on the physical server hosting the Avaya Oceana® Cluster 3 - Avaya Breeze® platform node (Active Load Balancer) and Active Omnichannel Database.

  • Power failure on the physical server hosting the Avaya Oceana® Cluster 3 - Avaya Breeze® platform node (Active Load Balancer) and Active Omnichannel Database.

  • Network failure on the physical server hosting the Avaya Oceana® Cluster 2 - Avaya Breeze® platform node (Active Load Balancer).

  • Power failure on the physical server hosting the Avaya Oceana® Cluster 2 - Avaya Breeze® platform node (Active Load Balancer).

  • Network failure on the physical server hosting the Avaya Oceana® Cluster 1 - Avaya Breeze® platform node (Active Load Balancer and Database), Active Application Enablement Services, and Active Communication Manager.

  • Power failure on the physical server hosting the Avaya Oceana® Cluster 1 - Avaya Breeze® platform node (Active Load Balancer and Database), Active Application Enablement Services, and Active Communication Manager.

Campus High Availability

Avaya Oceana® offers Campus High Availability (HA) from a single failure event. The main features of Campus HA are:

  • Capacity is maintained for a single failure in the system.

  • Service availability of new contacts arriving into Avaya Oceana®. Service to existing contacts in progress can be affected depending on the failure.

  • Coverage for system outage scenarios. Note that some network outage scenarios do not provide HA.

  • Leveraging Avaya Control Manager HA and Avaya Analytics™ HA capabilities. Deployment of HA for Avaya Control Manager and Avaya Analytics™ 3.x is optional, the architecture for Avaya Analytics™ 3.x provides HA by default.

Note:

If an Avaya Breeze® platform node fails, you must schedule a maintenance window to reboot the affected cluster after recovering the failed node.

Cache Mirroring

Avaya Oceana® provides Cache Mirroring configuration for a reliable infrastructure. You can keep active and standby multichannel Database servers in one data center and the backup multichannel Database server in another data center.

Omnichannel Database utilizes the Cache mirroring feature for Campus HA. A mirror can provide HA through automatic failover where a failure of the Cache instance causes the other instance to take over automatically.

All Omnichannel Database clients connect to the active mirror through a Virtual IP address, which is always bound to an interface on the currently active database.

When you configure Omnichannel Database, you can do data mirroring with one of the following:

  • HA active and standby Omnichannel Database servers within one Avaya Oceana® site (Data Center 1) with automatic failover

    In this configuration, you do not have a geo-redundant backup.

  • Active Omnichannel Database server in Data Center 1 and Geo backup Omnichannel Database server in the geo-redundant site (Data Center 2) with no automatic failover

  • HA active and standby Omnichannel Database servers within Data Center 1 with automatic failover and Geo backup Omnichannel Database server in Data Center 2 with no automatic failover

In Omnichannel Database HA, Omnichannel Database:

  • Records the transcripts of Chat, Email, SMS, Messaging, and Social sessions for Customer History at the end of the interaction.

  • Requires its deployment in an active-standby configuration on separate physical servers in the same subnet with a Round Trip Time (RTT) less than 120ms.

  • Automatically switches over to the standby server during an outage or lack of communication from the active server. After the switchover, the standby server becomes the active server.

    Data on the standby server remains updated in real-time.