Skip to main content

High Availability and Disaster Recovery
ENTERPRISE

For high availability, use Styra DAS on a Kubernetes cluster spanning multiple availability zones and have a pod scheduling policy that places replicas across multiple availability zones.

The default on-premises installation sets the replica value to 1.

For high availability, set the microservices replicas with the following values:

Table 1 - Microservices Replicas
microservicereplicas
activity3
agentbundle3
agentloader1
agentstatus3
agentstatusstore1
analysis-api3
blueprints1
coordinator1
datasources3
environment-configurator1
fetchdb3
gateway3
gateway-alt1
logreplay3
mock-opa1
policies3
stacks3
systems3
tenants1
timeseries3
ui3

In addition to the Kubernetes cluster, the database can be configured for multiple availability zones. Multipe availabilty zones are configured through the PostgreSQL deployment. For High Availability (Multi-AZ) for Amazon RDS, see the documentation page.

For disaster recovery purposes, configure Styra DAS for disaster recovery across multiple geographically distant regions as follows:

  1. In the secondary region, prepare a secondary, standby Kubernetes cluster that is ready to be used to install Styra DAS if the primary cluster in the primary region fails.

  2. In the primary region, configure the database to asynchronously replicate its database to a read-only replica in the secondary region. For more information on AWS RDS PostgreSQL, see the AWS RDS Read Replica documentation.

info

This procedure prevents data loss, but does not support automated failover. In the case of a disaster, manual operations are required to enable Strya DAS.

In case of a disaster, execute the following:

  1. For a new Styra DAS setup, promote the read replica in the secondary region to a new standalone database instance. For an instance with AWS RDS PostgreSQL, refer to https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Promote.

  2. Deploy Styra DAS to the secondary cluster and point it to use the newly created database instance.

  3. Change the DNS name assigned for Styra DAS and configured to OPAs to point to the secondary Styra DAS setup. This instructs the OPAs to connect to the secondary Styra DAS setup once the DNS cache expires.

tip

It is recommended to have short TTLs for the DNS entries pointing to the Styra DAS.