Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

4.2. Deployment Considerations for Replicas

4.2.1. Distribution of Server Services in the Topology

IdM servers can run a number of services, such as a certificate authority (CA) or DNS. A replica can run the same services as the server it was created from, but it is not necessary.
For example, you can install a replica without DNS services, even if the initial server runs DNS. Similarly, you can set up a replica as a DNS server even if the initial server was installed without DNS.
Replicas with Different Services

Figure 4.2. Replicas with Different Services

CA Services on Replicas

If you set up a replica without a CA, it will forward all requests for certificate operations to the CA server in your topology.

Warning

Red Hat strongly recommends to keep the CA services installed on more than one server. For information on installing a replica of the initial server including the CA services, see Section 4.5.4, “Installing a Replica with a CA”.
If you install the CA on only one server, you risk losing the CA configuration without a chance of recovery if the CA server fails. See Section B.2.6, “Recovering a Lost CA Server” for details.
If you set up a CA on the replica, its configuration must mirror the CA configuration of the initial server.

4.2.2. Replica Topology Recommendations

Red Hat recommends to follow these guidelines:
Configure no more than 60 replicas in a single IdM domain
Red Hat guarantees to support environments with 60 replicas or less.
Configure at least two, but no more than four replication agreements per each replica
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.
  • If you create replica B from server A and then replica C from server A, replicas B and C are not directly joined, so data from replica B must first be replicated to server A before propagating to replica C.
    Replicas B and C Are Not Joined in a Replication Agreement

    Figure 4.3. Replicas B and C Are Not Joined in a Replication Agreement

    Setting up an additional replication agreement between replica B and replica C ensures the data is replicated directly, which improves data availability, consistency, failover tolerance, and performance.
    Replicas B and C Are Joined in a Replication Agreement

    Figure 4.4. Replicas B and C Are Joined in a Replication Agreement

    See Chapter 6, Managing Replication Topology for details on managing replication agreements.
Configuring more than four replication agreements per replica is unnecessary. A large number of replication agreements per server does not bring significant additional benefits, because one consumer server can only be updated by one master at a time, so the other agreements are meanwhile idle and waiting. Additionally, configuring too many replication agreements can have a negative impact on overall performance.

Note

The ipa topologysuffix-verify command checks if your topology meets the most important recommendations. Run ipa topologysuffix-verify --help for details.
The command requires you to specify the topology suffix. See Section 6.1, “Explaining Replication Agreements, Topology Suffixes, and Topology Segments” for details.
Topology Example

Figure 4.5. Topology Example

4.2.2.1. Tight Cell Topology

One of the most resilient topologies is to create a cell configuration for the servers and replicas with a small number of servers in a cell:
  • Each of the cells is a tight cell, where all servers have replication agreements with each other.
  • Each server has one replication agreement with another server outside the cell. This ensures that every cell is loosely coupled to every other cell in the domain.
To accomplish a tight cell topology:
  • Have at least one IdM server in each main office, data center, or locality. Preferably, have two IdM servers.
  • Do not have more than four servers per data center.
  • In small offices, rather than using a replica, use SSSD to cache credentials and an off-site IdM server as the data back end.

4.2.3. 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 enables 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 7.7 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. 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 Section 4.5, “Creating the Replica: Introduction”.
Alternatively, you can change the state of an existing replica. For details, see Section 6.5.3, “Demotion and Promotion of Hidden Replicas”.