High availability
Keeping IdentityIQ available: clustered app servers, database HA and load balancing.
High availability uses multiple app servers behind a load balancer with a highly available database, so no single failure takes the platform down.
- Cluster multiple IdentityIQ app servers
- Load-balance UI traffic across them
- Use database HA (clustering/replication)
- Design task servers for failover
High availability keeps IdentityIQ serving users and running work despite the failure of any single component. Because all state lives in the database and background jobs are coordinated across nodes, HA design centres on clustering the application tier, protecting the database, and ensuring tasks recover cleanly when a node is lost.
The building blocks
- Multiple application nodes: run several IdentityIQ instances against the shared database so no single node is a point of failure.
- Load balancer: distribute UI and REST traffic across the nodes, with health checks so traffic drains from a failed node automatically.
- Database high availability: cluster or replicate the database (for example Oracle RAC/Data Guard, SQL Server Always On), because it is the critical shared dependency.
- Resilient task execution: configure task/request servers so that if one fails, surviving nodes continue the work.
Protecting the critical dependency
The database is the component whose loss is most catastrophic, so it gets the most HA investment. Clustering or synchronous replication ensures that a database node failure does not take the platform down or lose committed state. Everything else in the architecture can be made redundant relatively cheaply; the database is where careful design pays off most.
Task resilience and session behaviour
Two subtleties distinguish a real HA design from a naive one:
- Tasks must recover. If a task server dies mid-job, the work should resume or safely re-run on another node rather than being silently lost or left half-complete. This requires configuring task servers and request processing for failover, not just adding nodes.
- Session handling across nodes. With multiple UI nodes behind a load balancer, plan for how user sessions behave on failover, sticky sessions or a shared approach, so a node loss does not force every user to re-authenticate mid-task.
Testing failure, not assuming it works
An HA architecture that has never had a node deliberately killed is an untested hypothesis. Regular failover exercises, pull a node, fail the database over, confirm work continues, are the only way to know the design actually delivers availability.
HA versus DR
High availability handles component failure within a site, keeping the service up. Disaster recovery handles loss of the whole site and is covered separately. A complete resilience strategy needs both: HA for the everyday failures, DR for the catastrophe.
Common pitfalls
- Redundant app nodes with a single-point-of-failure database.
- No task failover, so background work stalls when a node dies.
- Never testing failover until a real outage proves it does not work.