Ce contenu n'est pas disponible dans la langue sélectionnée.
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.
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.
- For example, if the server includes an integrated IdM CA as the root CA, the replica must also be installed with an integrated CA as the root CA.
- See Section 2.3.2, “Determining What CA Configuration to Use” for the supported CA configuration options.
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.
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.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.NoteThe 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.
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.
