Chapter 2. Planning the replica topology

The following sections provide advice on determining the appropriate replica topology for your use case.

2.1. Multiple replica servers as a solution for high performance and disaster recovery

Continuous functionality and high availability of Identity Management (IdM) services is vital for users who access resources. One of the built-in solutions for accomplishing continuous functionality and high availability of the IdM infrastructure through load balancing is the replication of the central directory by creating replica servers of the master server.

IdM allows placing additional servers in geographically dispersed data centers to reflect your enterprise organizational structure. In this way, the path between IdM clients and the nearest accessible server is shortened. In addition, having multiple servers allows spreading the load and scaling for more clients.

Maintaining multiple redundant IdM servers and letting them replicate with each other is also a common backup mechanism to mitigate or prevent server loss. For example, if one server fails, the other servers keep providing services to the domain. You can also recover the lost server by creating a new replica based on one of the remaining servers.

2.2. Introduction to IdM servers and clients

The Identity Management (IdM) domain includes the following types of systems:

IdM servers

IdM servers are Red Hat Enterprise Linux systems that respond to identity, authentication, and authorization requests within an IdM domain. In most deployments, an integrated certificate authority (CA) is also installed with the IdM server.

IdM servers are the central repositories for identity and policy information. IdM servers can also host any of the optional services used by domain members:

  • Certificate authority (CA)
  • Key Recovery Authority (KRA)
  • DNS
  • Active Directory (AD) trust controller
  • Active Directory (AD) trust agent

The first server installed to create the domain is the IdM master or master server. The IdM master is not to be confused with the master CA server: they can run on two different machines.

IdM clients

IdM clients are Red Hat Enterprise Linux systems enrolled with the servers and configured to use the IdM services on these servers.

Clients interact with the IdM servers to access services provided by them. For example, clients use the Kerberos protocol to perform authentication and acquire tickets for enterprise single sign-on (SSO), use LDAP to get identity and policy infromation, use DNS to detect where the servers and services are located and how to connect to them.

IdM servers are also embedded IdM clients. As clients enrolled with themselves, the servers provide the same functionality as other clients.

To provide services for large numbers of clients, as well as for redundancy and availability, IdM allows deployment on multiple IdM servers in a single domain. It is possible to deploy up to 60 servers. This is the maximum number of IdM servers, also called replicas, that is currently supported in the IdM domain. IdM servers provide different services for the client. Not all the servers need to provide all the possible services. Some server components like Kerberos and LDAP are always available on every server. Other services like CA, DNS, Trust Controller or Vault are optional. This means that different servers in general play different roles in the deployment.

If your IdM topology contains an integrated CA, one server also has the role of the Certificate revocation list (CRL) generation master and the CA renewal master. This server is the master CA.

Warning

The master CA server is critical for your IdM deployment because it is the only system in the domain responsible for tracking CA subsystem certificates and keys, and for generating the CRL. For details about how to recover from a disaster affecting your IdM deployment, see Performing disaster recovery with Identity Management.

For redundancy and load balancing, administrators create additional servers by creating a replica of any existing server, either the master server or another replica. When creating a replica, IdM clones the configuration of the existing server. A replica shares with the initial server its core configuration, including internal information about users, systems, certificates, and configured policies.

Note

A replica and the server it was created from are functionally identical except for the role of the CRL generation master. Therefore, the term server and replica are used interchangeably here depending on the context.

2.3. Replication agreements

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.

Replication agreements are always bilateral: the data is replicated from one server to the other as well as from the other server to the first server.

IdM uses multi-master replication. In multi-master replication, all replicas joined in a replication agreement receive updates, and are therefore considered data masters.

Figure 2.1. Server and replica agreements

64 RHEL IdM 0120 2.1

IdM uses two types of replication agreements:

Domain replication agreements
These agreements replicate the identity information.
Certificate replication agreements
These 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.

2.4. Determining the appropriate number of replicas

Set up at least two replicas in each data center (not a hard requirement)
A data center can be, for example, a main office or a geographical location.
Set up a sufficient number of servers to serve your clients
One Identity Management (IdM) server can provide services to 2000 - 3000 clients. This assumes the clients query the servers multiple times a day, but not, for example, every minute. If you expect more frequent queries, plan for more servers.
Set up a maximum of 60 replicas in a single IdM domain
Red Hat guarantees to support environments with 60 replicas or fewer.

2.5. 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.

2.6. Replica topology examples

The figures below show examples of Identity Management (IdM) topologies based on the guidelines for creating a reliable topology.

Figure 2.2, “Replica Topology Example 1” shows four data centers, each with four servers. The servers are connected with replication agreements.

Figure 2.2. Replica Topology Example 1

64 RHEL IdM 0120 2.2



Figure 2.3, “Replica Topology Example 2” shows three data centers, each with a different number of servers. The servers are connected with replication agreements.

Figure 2.3. Replica Topology Example 2

64 RHEL IdM 0120 2.3

2.7. The hidden replica mode

By default, when you set up a new replica, the installer automatically creates service (SRV) resource records in DNS. These records enable clients to auto-discover the replica and its services. A hidden replica is an IdM server that has all services running and available. However, it has no SRV records in DNS, and LDAP server roles are not enabled. Therefore, clients cannot use service discovery to detect these hidden replicas.

Note

The hidden replica feature is available in Red Hat Enterprise Linux 8.1 and later as a Technology Preview and, therefore, not supported.

Hidden replicas are primarily designed for dedicated services that can otherwise disrupt clients. For example, a full backup of IdM requires to shut down all IdM services on the master or replica. Since no clients use a hidden replica, administrators can temporarily shut down the services on this host without affecting any clients.

Note
  • Restoring a backup from a hidden replica on a new host always results in a non-hidden (regular) replica.
  • All server roles used in a cluster, especially the Certificate Authority role if the integrated CA is used, must be installed on the hidden replica for the backup to be able to restore those services.
  • For more information on creating and working with IdM backups, see Backing Up and Restoring IdM.

Other use cases include high-load operations on the IdM API or the LDAP server, such as a mass import or extensive queries. To install a replica as hidden, pass the --hidden-replica parameter to the ipa-replica-install command.

For further details about installing a replica, see Installing an Identity Management replica.

Alternatively, you can change the state of an existing replica. For details, see Demotion and Promotion of Hidden Replicas.