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:
| microservice | replicas |
|---|---|
| activity | 3 |
| agentbundle | 3 |
| agentloader | 1 |
| agentstatus | 3 |
| agentstatusstore | 1 |
| analysis-api | 3 |
| blueprints | 1 |
| coordinator | 1 |
| datasources | 3 |
| environment-configurator | 1 |
| fetchdb | 3 |
| gateway | 3 |
| gateway-alt | 1 |
| logreplay | 3 |
| mock-opa | 1 |
| policies | 3 |
| stacks | 3 |
| systems | 3 |
| tenants | 1 |
| timeseries | 3 |
| ui | 3 |
In addition to the Kubernetes cluster, the database can be configured for multiple availability zones. Multiple availability 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:
-
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.
-
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.
This procedure prevents data loss, but does not support automated failover. In the case of a disaster, manual operations are required to enable Styra DAS.
In case of a disaster, execute the following:
-
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. -
Deploy Styra DAS to the secondary cluster and point it to use the newly created database instance.
-
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.
It is recommended to have short TTLs for the DNS entries pointing to the Styra DAS.