InstaSafe BCP / DR Strategy

InstaSafe Business Continuity Planning (BCP) strategy covers disaster scenarios like flood, fire, or prolonged power outages resulting in any critical components failing. InstaSafe Business continuity approach rides on High Availability deployment.

InstaSafe uses 2 standard deployment models for our customers

1. Cloud Hosted Controllers: Primarily used for customers who have low data requirements and whose access to public internet sites is NOT through InstaSafe secure tunnel.
2. Privately Hosted Controllers: Primarily used for customers who have requirements that all data should go through InstaSafe secure tunnels including public internet sites.

Based on the above scenarios as well as based on the customer's specific requirements, an appropriate deployment model is chosen.

In both the deployment setups, InstaSafe deploys multiple active controllers. Agents deployed on the clients connect to controllers and if the controller is down, it automatically connects to the next available controller.

For the database, InstaSafe uses a cluster with one writer node (primary) and multiple reader nodes. In the case of the primary going down the reader nodes take over as the writer node within seconds.

Strategy for Deployment Type: Cloud Hosted Controllers

Below is the Deployment Architecture of Cloud Hosted Controller Model. In this model the controllers are hosted in InstaSafe’s cloud infrastructure.

Different strategies for each DR scenario are below.

1. A controller is not available: This can happen due to any disaster resulting in the cloud datacenter where the primary controller hosted is not available. Since we have multiple controllers for each client the other controllers will take the traffic and end users will have minimal impact. In cloud deployments, the controllers are hosted in different service zones and regions.
2. Primary database is not available: If a disaster results in the primary writer node becoming unavailable, one of the reader nodes takes over as the writer node and our platform is back to normal functioning. The reader nodes and writer nodes are kept in different service zones to ensure both writer and reader nodes are not impacted together by the same disaster.
3. Authentication Server / Console not available: If the authentication server goes down for any reason, we bring up the authentication server in another service zone and associate the public IP with the same. Authentication server images are taken on a daily basis and stored in different service zones. Users already connected and utilizing the systems are not impacted, only new connections are impacted in this scenario.

Strategy for Deployment Type: Privately Hosted Controllers

Below is the Deployment Architecture of Privately Hosted Controller Model. In this model the client hosts the controller in their primary and DR data centers.

Different strategies for each DR scenario are below.

1. Primary database is not available: If a disaster results in the primary writer node becoming unavailable, one of the reader nodes takes over as writer node and our platform is back to normal functioning. The reader nodes and writer nodes are kept in different service zones to ensure both writer and reader nodes are not impacted by the same disaster.
2. Authentication Server / Console not available: If the authentication server goes down for any reason, we bring up the authentication server in another service zones and associate the public IP with the same. Authentication Server Instance Template are taken on a daily basis and stored in different service zones. Users already connected and utilizing the systems are not impacted, only new connections are impacted in this scenario.

In case of Privately Hosted controllers, the scenario of controllers going down results in Client activated DR. Since the HA mode is always Active Active, InstaSafe team does not have a role to play.

Note: For BCP / DR test initiated by clients, InstaSafe work with their network and applications team to plan a joint BCP / DR test.