--- title: "Introduction to Hot Standby Redundancy" slug: "hot-standby-redundancy" tags: ["automatic failover", "Docker", "hot standby", "Hot Standby Redundancy"] updated: 2026-06-01T17:43:23Z published: 2026-06-01T17:43:23Z canonical: "docs.crossworkassurance.cisco.com/hot-standby-redundancy" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.crossworkassurance.cisco.com/llms.txt > Use this file to discover all available pages before exploring further. # Introduction to Hot Standby Redundancy This article explains how the Legacy Orchestrator Hot Standby Redundancy feature works and covers the requirements for deploying the feature. Redundancy ensures continuous operation of the Legacy Orchestrator system by various hardware and software means. Two identical Legacy Orchestrator sites are set up: one site is active, one site is passive. Data from the active site is continuously replicated to the passive site. Failover from the active site to the passive site is triggered automatically. Hot Standby Redundancy is an optional feature that requires a license. ***Note:** This article will mention several default names for the interface and partition such as ethX (eth0, eth1,...), sdX (sdc,...); they can differ depending on who sets up the Docker host*. **CAUTION:** The Legacy Orchestrator Hot Standby Redundancy feature relies on the DRBD driver, which is compatible only with specific kernel versions on the Docker host. Consequently, this feature is restricted to supported kernel versions. If a kernel update is applied that is incompatible with the version of the DRBD driver used by the Legacy Orchestrator, the redundancy feature will fail to initialize. For the validated kernel versions, refer to [Docker Deployment](/latest/docs/legacy-orchestrator-docker-deployment). ### Network Communication The network communication setup for redundancy consists of: - Management interface - Replication interface - Monitoring interface - Virtual IP address (optional) ### Initial Setup and Startup This section describes the initial setup for redundancy and what happens when redundancy starts. For the procedure to configure redundancy, see *Configuring Hot Standby*. The initial setup for Hot Standby Redundancy is as follows: - The Legacy Orchestrator site is set up and activated on **Site-A** - Each site has a redundancy state, which is either: - When redundancy is configured, a **preferred site** can be defined. For more information about the preferred site, see *Preferred Site and Recovery after Failover*. - When redundancy starts: ### Automatic Failover If the active site fails, failover to the passive site is triggered automatically. Some points to note about automatic failover: - Automatic failover can be suspended when necessary. For example, during a maintenance window. See *Controlling Redundancy*. - Automatic failover can be disabled in the redundancy configuration, if your organization decides it will initiate failover manually. See *Disabling Automatic Failover*. ### Preferred Site and Recovery After Failover It is possible to configure a preferred site. The purpose of a preferred site is to determine which site will be active in many circumstances. For example, after both sites reboot. If a preferred site is configured: - **Startup**: When redundancy starts, the preferred site will be the active site. - **Failover**: If the preferred site fails, the system automatically fails over and the other site becomes the active site. - **Recovery after Failover**: When the preferred site is once again operational, it becomes the active site again. If a preferred site is not configured (the default: preferred site is set to None): - **Startup**: When redundancy starts, Site-A will be the active site. - **Failover**: If the active site fails (initially Site-A), the system automatically fails over and the passive site (initially Site-B) becomes the active site. - **Recovery after a Failover**: Even after the site that failed is operational again, the site that became active during the failover remains active. ***Note:** The "config preferred " must be configured correctly with the latest active site so as to prevent the issue of losing the latest database; this issue occurs when HA starts or restarts again*. ### Conditions That Trigger Automatic Failover The following conditions trigger automatic failover from the active to the passive site: - **Passive site detects loss of communication with active site** The passive site cannot communicate with the active site over the monitoring channel. See *Network Communication* above. - **Active site fails resources check** The resources check determines whether all the resources required for proper operation of the Legacy Orchestrator system are available on the active site. This check includes ensuring that the database is up, that the web application server is up, that the northbound interface server is up and that at least one mediation server is running. ### Split Brain Condition When both sites become active (due to loss of communication on both inter-site connections), this condition is known as split brain. The redundancy feature detects and handles a split brain condition as follows. ***Note:** In the following scenario, Site-A is the preferred site and the active site before the split brain condition occurs. A split brain condition could also arise if Site-B were the active site before the split brain condition occurred.* 1. Before split brain occurs - Redundancy feature is operating normally: 2. Split brain condition occurs: 3. Redundancy feature detects the split brain condition: 4. When Site-A is operational again and both inter-site connections are re-established: ### Requirements Hot Standby Redundancy has the following requirements: 1. Network requirements between the two sites: 2. Both Docker hosts for installing Legacy Orchestrator must be of the same type (one of the following): - Virtual machines is deployed on either KVM host or ESXi host. - Hardware machines 3. An empty partition to dedicate for the Hot Standby Redundancy function on each site: 4. Host names for all appliances must be unique. 5. IP addresses for all Docker hosts must be IPv4. Subnets must be specified by a CIDR value. 6. All Docker hosts must use NTP to set the date and time. 7. All Docker hosts must be running the same version of Legacy Orchestrator. 8. *Optional*: Virtual IP address for Legacy Orchestrator: 9. Three interfaces must be configured on the Docker hosts at both sites: 10. TCP and UDP ports must be opened in the firewall. These are the default ports: **© 2026 Cisco and/or its affiliates. All rights reserved.** For more information about trademarks, please visit: [Cisco trademarks](https://www.cisco.com/c/en/us/about/legal/trademarks.html)[](https://www.cisco.com/c/en/us/about/legal/trademarks.html) For more information about legal terms, please visit: [Cisco legal terms](https://www.cisco.com/c/en/us/about/legal/terms-conditions.html)