Chapter 59. Managing replication topology This chapter describes how to manage replication between servers in an Identity Management (IdM) domain. Additional resources Planning the replica topology Uninstalling an IdM server Failover, load-balancing, and high-availability in IdM 59.1. Explaining replication agreements, topology suffixes and topology segments When you create a replica, Identity Management (IdM) creates a replication agreement between the initial server and the replica. The data that is replicated is then stored in topology suffixes and when two replicas have a replication agreement between their suffixes, the suffixes form a topology segment. These concepts are explained in more detail in the following sections: Replication agreements Topology suffixes Topology segments 59.1.1. Replication agreements between IdM replicas When an administrator creates a replica based on an existing server, Identity Management (IdM) creates a replication agreement between the initial server and the replica. The replication agreement ensures that the data and configuration is continuously replicated between the two servers. IdM uses multiple read/write replica replication . In this configuration, all replicas joined in a replication agreement receive and provide updates, and are therefore considered suppliers and consumers. Replication agreements are always bilateral. Figure 59.1. Server and replica agreements IdM uses two types of replication agreements: Domain replication agreements replicate the identity information. Certificate replication agreements replicate the certificate information. Both replication channels are independent. Two servers can have one or both types of replication agreements configured between them. For example, when server A and server B have only domain replication agreement configured, only identity information is replicated between them, not the certificate information. 59.1.2. Topology suffixes Topology suffixes store the data that is replicated. IdM supports two types of topology suffixes: domain and ca . Each suffix represents a separate server, a separate replication topology. When a replication agreement is configured, it joins two topology suffixes of the same type on two different servers. The domain suffix: dc= example ,dc= com The domain suffix contains all domain-related data. When two replicas have a replication agreement between their domain suffixes, they share directory data, such as users, groups, and policies. The ca suffix: o=ipaca The ca suffix contains data for the Certificate System component. It is only present on servers with a certificate authority (CA) installed. When two replicas have a replication agreement between their ca suffixes, they share certificate data. Figure 59.2. Topology suffixes An initial topology replication agreement is set up between two servers by the ipa-replica-install script when installing a new replica. Example 59.1. Viewing topology suffixes The ipa topologysuffix-find command displays a list of topology suffixes: 59.1.3. Topology segments When two replicas have a replication agreement between their suffixes, the suffixes form a topology segment . Each topology segment consists of a left node and a right node . The nodes represent the servers joined in the replication agreement. Topology segments in IdM are always bidirectional. Each segment represents two replication agreements: from server A to server B, and from server B to server A. The data is therefore replicated in both directions. Figure 59.3. Topology segments Example 59.2. Viewing topology segments The ipa topologysegment-find command shows the current topology segments configured for the domain or CA suffixes. For example, for the domain suffix: In this example, domain-related data is only replicated between two servers: server1.example.com and server2.example.com . To display details for a particular segment only, use the ipa topologysegment-show command: 59.2. Using the topology graph to manage replication topology The topology graph in the web UI shows the relationships between the servers in the domain. Using the Web UI, you can manipulate and transform the representation of the topology. Accessing the topology graph To access the topology graph: Select IPA Server Topology Topology Graph . If you make any changes to the topology that are not immediately reflected in the graph, click Refresh . Interpreting the topology graph Servers joined in a domain replication agreement are connected by an orange arrow. Servers joined in a CA replication agreement are connected by a blue arrow. Topology graph example: recommended topology The recommended topology example below shows one of the possible recommended topologies for four servers: each server is connected to at least two other servers, and more than one server is a CA server. Figure 59.4. Recommended topology example Topology graph example: discouraged topology In the discouraged topology example below, server1 is a single point of failure. All the other servers have replication agreements with this server, but not with any of the other servers. Therefore, if server1 fails, all the other servers will become isolated. Avoid creating topologies like this. Figure 59.5. Discouraged topology example: Single Point of Failure Customizing the topology view You can move individual topology nodes by holding and dragging the mouse: Figure 59.6. Moving topology graph nodes You can zoom in and zoom out the topology graph using the mouse wheel: Figure 59.7. Zooming the topology graph You can move the canvas of the topology graph by holding the left mouse button: Figure 59.8. Moving the topology graph canvas 59.3. Setting up replication between two servers using the Web UI Using the Identity Management (IdM) Web UI, you can choose two servers and create a new replication agreement between them. Prerequisites You are logged in as an IdM administrator. Procedure In the topology graph, hover your mouse over one of the server nodes. Figure 59.9. Domain or CA options Click on the domain or the ca part of the circle depending on what type of topology segment you want to create. A new arrow representing the new replication agreement appears under your mouse pointer. Move your mouse to the other server node, and click on it. Figure 59.10. Creating a new segment In the Add topology segment window, click Add to confirm the properties of the new segment. The new topology segment between the two servers joins them in a replication agreement. The topology graph now shows the updated replication topology: Figure 59.11. New segment created 59.4. Stopping replication between two servers using the Web UI Using the Identity Management (IdM) Web UI, you can remove a replication agreement from servers. Prerequisites You are logged in as an IdM administrator. Procedure Click on an arrow representing the replication agreement you want to remove. This highlights the arrow. Figure 59.12. Topology segment highlighted Click Delete . In the Confirmation window, click OK . IdM removes the topology segment between the two servers, which deletes their replication agreement. The topology graph now shows the updated replication topology: Figure 59.13. Topology segment deleted 59.5. Setting up replication between two servers using the CLI You can configure replication agreements between two servers using the ipa topologysegment-add command. Prerequisites You have the IdM administrator credentials. Procedure Create a topology segment for the two servers. When prompted, provide: The required topology suffix: domain or ca The left node and the right node, representing the two servers [Optional] A custom name for the segment For example: Adding the new segment joins the servers in a replication agreement. Verification Verify that the new segment is configured: 59.6. Stopping replication between two servers using the CLI You can terminate replication agreements from command line using the ipa topology segment-del command. Prerequisites You have the IdM administrator credentials. Procedure [Optional] If you do not know the name of the specific replication segment that you want to remove, display all segments available. Use the ipa topologysegment-find command. When prompted, provide the required topology suffix: domain or ca . For example: Locate the required segment in the output. Remove the topology segment joining the two servers: Deleting the segment removes the replication agreement. Verification Verify that the segment is no longer listed: 59.7. Removing server from topology using the Web UI You can use Identity Management (IdM) web interface to remove a server from the topology. This action does not uninstall the server components from the host. Prerequisites You are logged in as an IdM administrator. The server you want to remove is not the only server connecting other servers with the rest of the topology; this would cause the other servers to become isolated, which is not allowed. The server you want to remove is not your last CA or DNS server. Warning Removing a server is an irreversible action. If you remove a server, the only way to introduce it back into the topology is to install a new replica on the machine. Procedure Select IPA Server Topology IPA Servers . Click on the name of the server you want to delete. Figure 59.14. Selecting a server Click Delete Server . Additional resources Uninstalling an IdM server 59.8. Removing obsolete RUV records If you remove a server from the IdM topology without properly removing its replication agreements, obsolete replica update vector (RUV) records will remain on one or more remaining servers in the topology. This can happen, for example, due to automation. These servers will then expect to receive updates from the now removed server. In this case, you need to clean the obsolete RUV records from the remaining servers. Prerequisites You have the IdM administrator credentials. You know which replicas are corrupted or have been improperly removed. Procedure List the details about RUVs using the ipa-replica-manage list-ruv command. The command displays the replica IDs: Important The ipa-replica-manage list-ruv command lists ALL replicas in the topology, not only the malfunctioning or improperly removed ones. Remove obsolete RUVs associated with a specified replica using the ipa-replica-manage clean-ruv command. Repeat the command for every replica ID with obsolete RUVs. For example, if you know server1.example.com and server2.example.com are the malfunctioning or improperly removed replicas: Warning Proceed with extreme caution when using ipa-replica-manage clean-ruv . Running the command against a valid replica ID will corrupt all the data associated with that replica in the replication database. If this happens, re-initialize the replica from another replica using USD ipa-replica-manage re-initialize --from server1.example.com . Verification Run ipa-replica-manage list-ruv again. If the command no longer displays any corrupt RUVs, the records have been successfully cleaned. If the command still displays corrupt RUVs, clear them manually using this task: 59.9. Viewing available server roles in the IdM topology using the IdM Web UI Based on the services installed on an IdM server, it can perform various server roles . For example: CA server DNS server Key recovery authority (KRA) server. Procedure For a complete list of the supported server roles, see IPA Server Topology Server Roles . Note Role status absent means that no server in the topology is performing the role. Role status enabled means that one or more servers in the topology are performing the role. Figure 59.15. Server roles in the web UI 59.10. Viewing available server roles in the IdM topology using the IdM CLI Based on the services installed on an IdM server, it can perform various server roles . For example: CA server DNS server Key recovery authority (KRA) server. Procedure To display all CA servers in the topology and the current CA renewal server: Alternatively, to display a list of roles enabled on a particular server, for example server.example.com : Alternatively, use the ipa server-find --servrole command to search for all servers with a particular server role enabled. For example, to search for all CA servers: 59.11. Promoting a replica to a CA renewal server and CRL publisher server If your IdM deployment uses an embedded certificate authority (CA), one of the IdM CA servers acts as the CA renewal server, a server that manages the renewal of CA subsystem certificates. One of the IdM CA servers also acts as the IdM CRL publisher server, a server that generates certificate revocation lists. By default, the CA renewal server and CRL publisher server roles are installed on the first server on which the system administrator installed the CA role using the ipa-server-install or ipa-ca-install command. You can, however, transfer either of the two roles to any other IdM server on which the CA role is enabled. Prerequisites You have the IdM administrator credentials. Procedure Change the current CA renewal server. Configure a replica to generate CRLs. 59.12. Demoting or promoting hidden replicas After a replica has been installed, you can configure whether the replica is hidden or visible. For details about hidden replicas, see The hidden replica mode . Prerequisites Ensure that the replica is not the DNSSEC key master. If it is, move the service to another replica before making this replica hidden. Ensure that the replica is not a CA renewal server. If it is, move the service to another replica before making this replica hidden. For details, see Changing and resetting IdM CA renewal server . Procedure To hide a replica: To make a replica visible again: To view a list of all the hidden replicas in your topology: If all of your replicas are enabled, the command output does not mention hidden replicas.

Commands:
ipa topologysuffix-find --------------------------- 2 topology suffixes matched --------------------------- Suffix name: ca Managed LDAP suffix DN: o=ipaca Suffix name: domain Managed LDAP suffix DN: dc=example,dc=com ---------------------------- Number of entries returned 2 ----------------------------
ipa topologysegment-find Suffix name: domain ----------------- 1 segment matched ----------------- Segment name: server1.example.com-to-server2.example.com Left node: server1.example.com Right node: server2.example.com Connectivity: both ---------------------------- Number of entries returned 1 ----------------------------
ipa topologysegment-show Suffix name: domain Segment name: server1.example.com-to-server2.example.com Segment name: server1.example.com-to-server2.example.com Left node: server1.example.com Right node: server2.example.com Connectivity: both
ipa topologysegment-add Suffix name: domain Left node: server1.example.com Right node: server2.example.com Segment name [server1.example.com-to-server2.example.com]: new_segment --------------------------- Added segment "new_segment" --------------------------- Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both
ipa topologysegment-show Suffix name: domain Segment name: new_segment Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both
ipa topologysegment-find Suffix name: domain ------------------ 8 segments matched ------------------ Segment name: new_segment Left node: server1.example.com Right node: server2.example.com Connectivity: both ---------------------------- Number of entries returned 8 ----------------------------
ipa topologysegment-del Suffix name: domain Segment name: new_segment ----------------------------- Deleted segment "new_segment" -----------------------------
ipa topologysegment-find Suffix name: domain ------------------ 7 segments matched ------------------ Segment name: server2.example.com-to-server3.example.com Left node: server2.example.com Right node: server3.example.com Connectivity: both ---------------------------- Number of entries returned 7 ----------------------------
ipa-replica-manage list-ruv server1.example.com:389: 6 server2.example.com:389: 5 server3.example.com:389: 4 server4.example.com:389: 12
ipa-replica-manage clean-ruv 6 ipa-replica-manage clean-ruv 5
dn: cn=clean replica_ID, cn=cleanallruv, cn=tasks, cn=config objectclass: extensibleObject replica-base-dn: dc=example,dc=com replica-id: replica_ID replica-force-cleaning: no cn: clean replica_ID
ipa config-show IPA masters: server1.example.com, server2.example.com, server3.example.com IPA CA servers: server1.example.com, server2.example.com IPA CA renewal master: server1.example.com
ipa server-show Server name: server.example.com Enabled server roles: CA server, DNS server, KRA server
ipa server-find --servrole "CA server" --------------------- 2 IPA servers matched --------------------- Server name: server1.example.com Server name: server2.example.com ---------------------------- Number of entries returned 2 ----------------------------
ipa server-state replica.idm.example.com --state=hidden
ipa server-state replica.idm.example.com --state=enabled
ipa config-show