Availability Concepts

At Curity, we realize that high availability is critical to our customers. Therefore, we ensure our system is accompanied by modern availability features.

Auto Healing

Each node provides HTTP Status Endpoints that can be called by monitoring systems or a platform such as Kubernetes. If not contactable for a configurable time period, the instance will be marked down, and the platform should 'auto-heal' by spinning up a new instance.

Auto Scaling

We provide Prometheus Standard Metrics with more detailed information, including CPU and memory usage. This data can then be used to define rules to manage auto-scaling during periods of high load, as in this example:

• Run four nodes at normal times
• While CPU is above 30%, spin up new nodes, up to a maximum of eight
• While CPU is below 5%, reduce nodes, down to a minimum of four

HTTP Clients

The Curity Identity Server makes HTTPS connections to external systems in some scenarios, such as when using authenticators or Mutual TLS connections to business partners. These connections use HTTP Clients to manage the security and reliability of the connection.

Alarms

Curity raises alarms when healthy nodes have problems connecting to dependencies, such as HTTP clients or JDBC/LDAP data sources. In these cases, when an alarm is triggered, it can be handled in many ways to notify people, using either a built-in or custom Alarm Handler.

Zero Downtime Upgrades

Upgrades work in a zero-downtime manner. Therefore, all active runtime nodes remain working at any point in time, even if some are not yet upgraded. Starting an upgrade in a canary manner would work like this:

• First update data schemas, if specified in the new version's release notes
• Then upgrade the admin node to the new version
• Then upgrade a subset of runtime nodes to the new version

Both old and new runtime nodes would use token and session data in the same way. Therefore a load balancer could route multiple requests from a user app to runtime nodes on different versions, which would not lead to application problems.

Downgrades

In the event of a post-upgrade problem that is not fixable by a Configuration Rollback, we ensure that the system can be safely downgraded via the following steps. This will ensure that there is no impact on customer applications, since there will be no loss of user, session, or token data:

• Leave databases on the new version
• Then redeploy admin nodes with the previous image and configuration
• Then redeploy runtime nodes with the previous image and configuration

Conclusion

The Curity Identity Server includes modern features to ensure high availability. These features also integrate well with monitoring systems that companies already use for their own back-end components. This ensures that there is an early warning of any technical issues and that, in most cases, the system can be automatically repaired.