Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Preparing for server loss with replication

Identity Management (IdM) replication provides high availability and protects against the loss of individual servers. In the event of a server failure, the remaining replicas maintain service continuity and serve as the data source for restoring the lost node. Proper replication topology ensures that the environment remains resilient and functional during hardware malfunctions or maintenance.

Properly sizing and connecting your IdM replicas in a topology is critical to ensuring your infrastructure maintains high-availability, delivers optimal performance, and achieves data consistency across the entire domain.

Connect each replica to at least two other replicas
This ensures that information is replicated not just between the initial replica and the first server you installed, but between other replicas as well.
Connect a replica to a maximum of four other replicas (not a hard requirement)

A large number of replication agreements per server does not add significant benefits. A receiving replica can only be updated by one other replica at a time and meanwhile, the other replication agreements are idle. More than four replication agreements per replica typically means a waste of resources.

Note

This recommendation applies to both certificate replication and domain replication agreements.

There are two exceptions to the limit of four replication agreements per replica:

  • You want failover paths if certain replicas are not online or responding.
  • In larger deployments, you want additional direct links between specific nodes.

Configuring a high number of replication agreements can have a negative impact on overall performance: when multiple replication agreements in the topology are sending updates, certain replicas can experience a high contention on the changelog database file between incoming updates and the outgoing updates.

If you decide to use more replication agreements per replica, ensure that you do not experience replication issues and latency. However, note that large distances and high numbers of intermediate nodes can also cause latency problems.

Connect the replicas in a data center with each other
This ensures domain replication within the data center.
Connect each data center to at least two other data centers
This ensures domain replication between data centers.
Connect data centers using at least a pair of replication agreements
If data centers A and B have a replication agreement from A1 to B1, having a replication agreement from A2 to B2 ensures that if one of the servers is down, the replication can continue between the two data centers.

3.2. Replica topology examples
Copy link

These examples offer the practical application of the topology guidelines. They illustrate how you can structure your IdM deployment to build a resilient and scalable IdM infrastructure that guarantees high-availability and optimal performance across multiple data centers.

Figure 3.1. Replica topology with four data centers, each with four servers that are connected with replication agreements

A diagram showing 4 data centers - Geo 1 through 4. Each data center has four servers connected to each other with replication agreements. There are also replication agreements connecting two servers from Geo 1 to two servers in Geo 2. This pattern continues with two servers in Geo 2 connected to two servers in Geo 3 and two servers in Geo 3 connected to Geo 4. This connects each data center so each server is at most 3 hops away from another Geo.

Figure 3.2. Replica topology with three data centers, each with a different number of servers that are all interconnected through replication agreements

A diagram showing 3 data centers: Geo 1 has 5 servers each connected to the other - Geo 2 has two servers connected to each other - Geo 3 has 3 servers connected in a triangle. There are 2 connections from each Geo connecting two of its servers to 2 servers in the next Geo.

3.3. Protecting IdM CA data
Copy link

Identity Management (IdM) deployments with an integrated Certificate Authority (CA) maintain high availability through the use of multiple CA replicas. Install several CA replicas to ensure the environment remains resilient and provides the necessary data source to replace any lost nodes.

Procedure

  1. Configure three or more replicas to provide CA services.

    1. To install a new replica with CA services, run ipa-replica-install with the --setup-ca option. 

      [root@server ~]# ipa-replica-install --setup-ca

    2. To install CA services on a preexisting replica, run ipa-ca-install. 

      [root@replica ~]# ipa-ca-install

  2. Create CA replication agreements between your CA replicas. 

    [root@careplica1 ~]# ipa topologysegment-add
Suffix name: ca
Left node: ca-replica1.example.com
Right node: ca-replica2.example.com
Segment name [ca-replica1.example.com-to-ca-replica2.example.com]: new_segment
---------------------------
Added segment "new_segment"
---------------------------
  Segment name: new_segment
  Left node: ca-replica1.example.com
  Right node: ca-replica2.example.com
  Connectivity: both
    Warning

    If only one server provides CA services and it is damaged, the entire environment will be lost. If you use the IdM CA, Red Hat strongly recommends having three or more replicas with CA services installed, with CA replication agreements between them.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top