Overview
Every moment of downtime represents a significant cost to OT/IT environments. To mitigate these costs and ensure operational efficiency, Dispel offers multiple options of high availability for each part of our deployments:
Manual failover of wickets through user input commands.
Auto-failover of wickets through parallel wicket stand ups.
Full redundancy in deployment, including both wickets and a Dispel region as well as geographical redundancy based on Azure Data Center.
💡 Some reference diagrams below show two wickets, but high availability deployments can be scaled to as many wickets as needed.
Standard Redundancy: Backup Tunnel Model
Description: In a standard deployment there is a backup tunnel as well as a production tunnel to allow Dispel’s support team direct access to the wicket for troubleshooting in case of emergency.
SOP During Failover: Dispel’s support team works through the support tunnel to bring the production tunnel back online.
Backup Cloned Wicket Redundancy: Active-Passive Model (Cold Failover)
Description: In this scenario the backup wicket is a clone of the primary wicket. We accomplish this by either cloning the primary wicket, or by installing another VM with the same ISO.
SOP During Failover: The primary wicket would be powered off, and the backup wicket would be powered on to take its place.
High Availability Two-Wicket Redundancy: Active-Active Model (Warm Failover)
Description: In this scenario, there would be two wickets running side-by- side at all times, but the primary wicket is the only one that would be used in normal day-to-day operations. The Secondary wicket would automatically take over for the primary wicket if the primary wicket were to go offline. Downtime lengths are set to 90 seconds by default, but can be customized.
SOP During Failover: No immediate action needed. Automated alerts will inform the Dispel operations team of the primary wicket’s offline status, and we will work with you to restore connectivity for both wickets.
Full Redundancy: Active-Active Model (Hot Failover)
Description: In this scenario there is true full redundancy. Both systems are independent of each other, but reach the same network.
SOP During Failover: Access can continue normally on the Secondary MTD Network.
