Skip to main content
All CollectionsUsage & Deployment GuidesOn-Premise Deployment Guide
High Availability (HA)
High Availability (HA)
A
Written by Arick Disilva
Updated over 7 months ago

Overview

High availability (HA) ensures that your Teramind deployment is spread out in multiple instances to eliminate any single point of failure. It enables the Teramind applications and service to continue to operate even if one of the IT components it depends on, such as a server, fails.

The native, built-in high availability can be fine tuned and adapted for different scenarios.

Option 1 – HA of Critical Components

Critical TM components are deployed to all node.

Each node runs:

  • Web dashboard service

  • BI reporting service

  • App Server (terasrv) – Agent data collection service

On top of that, the Master node runs some Master-only workloads:

  • AD sync

  • BI sync

  • Reports exports (both one-time and scheduled)

  • Video exports

Requires 2*N+1 nodes.

  • Deployment of 2+N+1 nodes can tolerate N nodes being down:

  • 3-node deployment can live with 1 node down

  • 5-node deployment can live with 2 nodes down

  • 7-node deployment can live with 3 nodes down

  • etc…

This includes Master node being down, with exception of Master-only workloads not being functional.

All core workload (reporting and data capture) expected to be operational.

Master node can be restored, or another node can be promoted to Master in case of a disaster via manual re-configuration.

Relies on external storage & external DB. Does not cover automated DB failover, external service should be used.

Key Requirements:

  • 2*N+1 nodes

  • External (customer-managed) load balancer

  • External (customer-managed) PostgreSQL DB – can be single point of failure

  • External (customer managed) storage – can be single point of failure

  • External monitoring tools to detect node health

Option 2 – Active + Passive Standby

A set of similar nodes deployed to 2 DCs

Each DC is a “separate” deployment:

  • Has dedicated Master node

  • Has N other nodes if necessary/applicable

  • Does not require similar set of nodes in each DC. For example, DC 1 might have OCR, DC 2 might not have OCR. This might be useful for temporary failovers to 2nd DC for maintenance

  • No specific requirements for node count and configuration

At each moment of time, only a single deployment is active.

Information about active DC is stored in theshared DB.

There is no automatic DB failover, app relies on the external DB and storage that should be replicated between DCs.

Application switchover between DC’s is performed manually via script call.

Key Requirements:

  • At least 2 DC’s

  • External (customer-managed) load balancer

  • External (customer-managed) PostgreSQL DB replicated across DC’s

  • External (customer managed) storage replicated across DC’s

  • External monitoring tools to check system health and trigger switchover

Related Articles
On-Premise Deployment Guide
AWS Deployment Guide
Azure Deployment Guide
How to update the Teramind Server and BI Classification (On-Premise / Private Cloud)
How to set up a multi-node deployment (On-Premise)
Did this answer your question?