Regardless of the model, the ForgeRock platform allows high availability services to be deployed to satisfy your organization's expected requirements. The platform was designed from the ground up to provide telco-grade scalability and availability, allowing you to build services for 24x7x365 availability.
Multiple Data Center Deployments
A commonly adopted architecture encompasses multiple regions, multiple data centers, and multiple nodes per data center, to provide both global and local high availability. High availability is achieved using standard web-tier load balancers. Session persistence can be achieved using directory replication between Directory Services nodes, both locally and across data centers.
In a multi-data center deployment, a global load balancer routes traffic across data centers, and data centers use local load balancers to route incoming traffic across local servers. Round robin or load average balancing algorithms can be used, although sticky (or 'affinity') load balancing is recommended for performance reasons, as it will route all requests pertaining to a particular authentication flow to the same server. Reverse proxies are also commonly used and work in concert with the load balancers to route the client requests to the backend web or application servers, providing an extra level of security in the public tier (DMZ).
Client-based Sessions (Stateless Tokens)
A client-based session model is commonly used in ForgeRock deployments. Following successful authentication, a session object is created and encoded in a stateless token (JWT). With this architecture, the infrastructure can be scaled horizontally since any server in the deployment can be used to validate any session JWT token from any client. This avoids the more volatile replication traffic than can occur with a Core Token Service (CTS)-based session model due to the possibility of short-lived entries.
See Introduction to sessions for further information on authentication session models.
Many customers are now turning to DevOps tooling, both for on-premises and cloud infrastructure, to simplify and orchestrate deployments. This offers many advantages, namely, rapid and repeatable deployments, deployment automation, continuous integration/continuous deployment pipelines, elastic "on-demand" scaling, and version-controlled configurations. ForgeRock provides numerous guides, samples, and predefined configurations which can be used to create large scale deployments using industry-standard tools such as Docker and Kubernetes.
See Welcome to ForgeOps (ForgeRock DevOps) for further information on deploying the ForgeRock platform in a containerized environment using DevOps techniques.
The diagram below shows an example physical architecture with complete high availability and disaster recovery across data centers. In this example, the ForgeRock platform components are deployed as pods within two container environment nodes across Data Centers A and B.
Incoming requests to the service are routed via an enterprise load balancer, with local load balancers in each data center. Standard reverse proxies, such as the Apache™ reverse proxy, are commonly deployed with the solution. High availability and disaster recovery are provided by Directory Services (DS).
See Example deployment topology for more example ForgeRock Identity Platform deployments.
For a resilient high availability deployment, all ForgeRock components should be replicated, eliminating all single points of failure.
ForgeRock Access Management (AM) uses load-balanced autonomous servers, which operate in a load-balanced cluster but act autonomously, and do not rely on, communicate with, or need to be aware of other members of the cluster. Servers can be added/removed with no disruption, and this is particularly effective when combined with DevOps deployment tools. The use of client-based sessions means that no tokens are stored centrally, eliminating replication overheads and greatly simplifying load-balancing algorithms, in particular, eliminating the need for sticky (or 'affinity') load-balancing. The tokens are simply stored as signed JWTs by clients. As long as all AM servers share common signing credentials, any server can validate and introspect any token.
ForgeRock Identity Management (IDM) can similarly be deployed in a load-balanced cluster and uses an external clustered database to replicate the state.
Directory Services (DS) is typically deployed in a multi-node architecture. It provides n-way multi-master replication meaning that any update can be applied to any node and the update will be replicated to all other nodes. When correctly designed, the loss of any node should not affect the replication array.
To ensure that your identity management service remains available in the event of system failure, you can deploy multiple IDM instances in a cluster, with each instance pointing to the same external repository.
Multi-version concurrency control (MVCC) ensures consistency and concurrency across all instances in a cluster by only updating the revision that was specified in the update. Moreover, in a deployment involving the internal scheduler, persistent schedules can be configured so that jobs and tasks are launched only once across the cluster.
All IDM instances in a cluster run simultaneously. When configured with a load balancer, this works as an Active-Active High Availability Cluster. If the database is also clustered, IDM points to the database cluster as a single system.