> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/installation/rpm/rpm-ha.md). # Three nodes A three-node OpenIAM cluster — what it gives you, what sits where, and the order of the pages. Three identical hosts, each running the full OpenIAM stack, with every tier clustered across them. This is OpenIAM's high availability deployment shape: **the loss of any one host leaves the platform's own tiers serving.** **Three things sit outside that, and each needs its own arrangement.** The shared filesystem is exported from the first node in the default build, so that node is not interchangeable with the other two until you supply resilient storage. The database and the load balancer are likewise arranged for availability in their own right. [*Scope and availability*](/installation/scope-and-availability.md) sets out exactly what this shape survives, and it is worth reading before you build rather than after. **Allow most of a day** for a first three-node build, including the load balancer and verification. The build itself is two to three hours, most of it unattended. **Building on AWS or Azure?** Read [*RPM on AWS and Azure*](/installation/rpm/cloud.md) alongside these pages — it covers instance sizing, storage, networking, the load balancer and the managed database. ## What this gives you * **The platform's own tiers are redundant.** Application services, message broker, cache, graph store, search tier and secret store are all replicated across the three hosts. * **Capacity to spread load.** User traffic is distributed across the three nodes by a load balancer in front of them. * **Headroom when a node is lost.** With three nodes, a failure leaves two to carry the load rather than one — the reason three is the usual starting point rather than two. ## What sits where ```mermaid flowchart TD U["Users"] --> LB["Load balancer — yours to provide"] LB --> N1["Node 1"] LB --> N2["Node 2"] LB --> N3["Node 3"] N1 --> NFS["Shared filesystem — conf, upload, secret-store certificates.
Exported from node 1 in the default build"] N2 --> NFS N3 --> NFS N1 --> DB[("Database")] N2 --> DB N3 --> DB ``` **Each of the three nodes is a complete stack** — reverse proxy, interface router, the six interfaces, the application services and the clustered infrastructure tiers. The message broker, cache, graph, search and secret store are clustered across all three. A node's reverse proxy reaches the interface router beside it, so no node depends on another for that hop. **One thing is unique to the first node.** It exports the shared filesystem the other two mount — `conf`, `upload` and the secret store's certificates. Loss of that node removes the shared filesystem from every node at once, which is the one failure this shape does not absorb on its own. [*Scope and availability*](/installation/scope-and-availability.md) sets out the two ways to address it: provide the shared filesystem from storage you already run, or accept it as a component whose loss needs intervention. Two things sit outside the cluster: * **The database.** Usually external to the three hosts, on your own server or managed service, with its own availability arrangement — the common production choice. See [*Use a remote database*](/installation/rpm/rpm-single-node/use-a-remote-database.md). The build can alternatively create a three-node MariaDB Galera cluster across the same hosts. * **The load balancer.** In front of the three hosts, distributing user traffic and taking a failed node out of rotation. Connectors that must run close to the systems they manage — a Windows host for Active Directory, for example — run on their own machines and connect back to the cluster's message broker. ## What the cluster tolerates **The loss of one application host that is not the shared-storage node.** The platform keeps serving, established sessions survive, and every tier rebuilds its third member when the host returns. Planned maintenance follows the same path — take one node at a time, which is how the restart in [*Install*](/installation/rpm/rpm-ha/install.md) is written. **Three dependencies sit outside that guarantee** — the database, the load balancer, and the shared filesystem exported by the first node. Each needs its own arrangement, and [*Scope and availability*](/installation/scope-and-availability.md) covers all three. Read it before quoting an availability figure to anyone. Several tiers reach agreement by majority — the secret store's backend, the message broker's queues, and the database cluster where you build one on the same hosts. Two of three is a majority; that is what makes one-node loss safe, and it is the reason the shape starts at three rather than two. Designs for larger populations, multiple sites and site-loss scenarios are in the [Solution Architecture and Design Guide](/solution-architecture/deployment/availability-and-recovery.md). ## When to choose this instead of a single node Choose three nodes when the platform itself must survive the loss of a host. Choose a single node when that requirement is met another way — a hypervisor cluster, a storage snapshot regime, or a documented rebuild-and-restore procedure — or when the deployment is for evaluation, development or test. Larger populations sometimes need more than three nodes, or a tiered arrangement separating the interface layer from the services and infrastructure. Those designs are covered in the [Solution Architecture and Design Guide](/solution-architecture/deployment/rpm-topologies.md); this guide builds the three-node cluster. ## The pages, in order
PageWhat it does
Prepare the hostsThree hosts, name resolution, and the trust the build uses between them
InstallOne run, from one host, that builds all three
The clustered tiersWhat the build produced, tier by tier, and how to confirm each
Component load balancingHow each node reaches the shared tiers, and what to do when a backend is marked down
Start and verifyConfirm every tier is genuinely clustered, and that a node can be lost
Configure the load balancerWhat to put in front of the three hosts
PortsWhat faces users, and what runs between the three hosts
TroubleshootSymptom, meaning, action
**You install once, from one host.** OpenIAM provides cluster tooling that configures all three hosts over SSH and forms every tier's cluster as it goes — you do not repeat the single-node procedure three times. ## Before you start Read [*What you need*](/installation/what-you-need.md) and [*System requirements*](/installation/system-requirements.md). Every host must meet the requirements individually — the three-node shape is three full deployments joined together, not one deployment split three ways. ## After the cluster is built The remaining pages in the single-node path apply to a cluster unchanged, with any differences noted on each: [*First sign-in*](/installation/rpm/rpm-single-node/first-sign-in.md), [*Configure*](/installation/rpm/rpm-single-node/configure.md), [*Add a connector*](/installation/rpm/rpm-single-node/add-a-connector.md), [*Enable HTTPS*](/installation/rpm/rpm-single-node/enable-https.md) and [*Back up and restore*](/installation/rpm/rpm-single-node/back-up-and-restore.md). **Upgrades** are covered in [*Upgrading OpenIAM*](/installation/rpm/rpm-upgrade.md), which starts by settling whether yours is a minor or a major one. Take a backup first. ## Related * [*Choose your route*](/installation/choose-your-route.md) * [*Scope and availability*](/installation/scope-and-availability.md) — the shared-storage dependency and what it means * [*What you need*](/installation/what-you-need.md) *Applies to OpenIAM 2026.8.1.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/installation/rpm/rpm-ha.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.