Chapter 3. Preparing for server loss with replication
Follow these guidelines to establish a replication topology that will allow you to respond to losing a server.
3.1. Connecting the replicas in a topology
- Connect each replica to at least two other replicas
- Configuring additional replication agreements ensures that information is replicated not just between the initial replica and the master server, 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
The figures below show examples of Identity Management (IdM) topologies based on the guidelines for creating a reliable topology.
Figure 3.1, “Replica Topology Example 1” shows four data centers, each with four servers. The servers are connected with replication agreements.
Figure 3.1. Replica Topology Example 1
Figure 3.2, “Replica Topology Example 2” shows three data centers, each with a different number of servers. The servers are connected with replication agreements.
Figure 3.2. Replica Topology Example 2
3.3. Protecting IdM CA data
If your deployment contains the integrated IdM Certificate Authority (CA), install several CA replicas so you can create additional CA replicas if one is lost.
Configure three or more replicas to provide CA services.
To install a new replica with CA services, run
[root@server ~]# ipa-replica-install --setup-ca
To install CA services on a preexisting replica, run
[root@replica ~]# ipa-ca-install
Create CA replication agreements between your CA replicas.
[root@careplica1 ~]# ipa topologysegment-add Suffix name: ca Left node: careplica1.example.com Right node: careplica2.example.com Segment name [careplica1.example.com-to-careplica2.example.com]: new_segment --------------------------- Added segment "new_segment" --------------------------- Segment name: new_segment Left node: careplica1.example.com Right node: careplica2.example.com Connectivity: both
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.
3.4. Additional resources
- For additional information on replication, see Planning the replica topology.