In Avaya Analytics™, high availability (HA) is available by default.

The reporting database gets deployed automatically with a primary and standby instance. The Avaya Analytics™ measure processors are deployed as a primary and standby pair. The active and hot standby instances process all events with only the Active instance providing output to the database and Real-time topics. The HA switchover occurs at the application level. If any active application fails, the hot standby instance takes over.

Avaya Analytics™ node HA

The vCenter HA manages the node detection and recovery. If a node fails, the pods running on that node is rescheduled to the other nodes in the cluster where pod anti-affinity rules permits. Anti-affinity indicates that no replica of a pod is co-located on a single node. The pods are relocated only if the available nodes have sufficient resources to meet the pod requirements.

Avaya Analytics™ host HA

The host recovery is based on vCenter assuming that all physical hardware, such as disk, CPU, RAM, or NIC are working. Any outages in these hardware component prevents the recovery of the host.

Avaya Analytics™ stream services

The streams services provide producers and measures to Avaya Workspaces for use in real-time reporting dashboards.

• By using Avaya Workspaces, you can view real-time reporting dashboards to monitor up-to-date statistics for your contact center and resources.

• By using the Avaya Analytics™ historical reporting interface, you can view and analyze historical interaction dashboards to enhance customer experience and agent performance.

Avaya Analytics™ HA caveats

Avaya Analytics™ HA is not based on an n+1 HA strategy due to footprint constraints. The current cluster consist of three master nodes on which the applications run. When a VM node or the EXSi host fails, Avaya Analytics™ relies on VMWare HA to recover the failed node or host.

• During a node or host outage, Avaya Analytics™ runs at reduced capacity with potential loss of feature functionality depending on the node or host that failed.

• The remaining two node in the cluster do not have the resource capacity to host all the service that were originally running on the failed node.

• Kubernetes automatically spins up new instances of the failed service on the remaining two nodes, however; with limited resource capacity on these nodes not all service restarts.

• For restore, you must recover the failed node.

• After the node is recovered, the cluster remains unbalanced with most services running on the two nodes that remained running.

• Depending on the node that failed, recovery of the node outage can take up to 15 to 25 minutes.

• During node failure you do not lose any data, however, you might lose service continuity.

• After a node outage, the Real-time reports take several minutes to start updating.

• Historical reporting might not be available until the node recovers.

• After the node recovers, historical reporting services could take upto 45 minutes to revert to Running state and will continue to remain unavailable during this time.

For details about Avaya Analytics™ on non-HA, see the relevant chapter in this document.