Chapter 3. Failover, load-balancing, and high-availability in IdM

Identity Management (IdM) has built-in failover mechanisms for IdM clients, and load-balancing and high-availability features for IdM servers.

3.1. Client-side Failover Capability

  • By default, the SSSD service on an IdM client is configured to use service (SRV) resource records from DNS to automatically determine the best IdM server to connect to. This behavior is controlled by the _srv_ option in the ipa_server parameter of the /etc/sssd/sssd.conf file:

    [root@client ~]# cat /etc/sssd/sssd.conf
    
    [domain/example.com]
    id_provider = ipa
    ipa_server = _srv_, server.example.com
    ...

    If an IdM server goes offline, the SSSD service on the IdM client connects to another IdM server it has automatically discovered.

  • If you prefer to bypass DNS lookups for performance reasons, remove the _srv_ entry from the ipa_server parameter and specify which IdM servers the client should connect to, in order of preference:

    [root@client ~]# cat /etc/sssd/sssd.conf
    
    [domain/example.com]
    id_provider = ipa
    ipa_server = server1.example.com, server2.example.com
    ...

3.2. Server-side load-balancing and service availability

You can achieve load-balancing and high-availability in IdM by installing multiple IdM replicas:

  • If you have a geographically dispersed network, you can shorten the path between IdM clients and the nearest accessible server by configuring multiple IdM replicas per data center.
  • Red Hat supports environments with up to 60 replicas.
  • The IdM replication mechanism provides active/active service availability: services at all IdM replicas are readily available at the same time.
Note

Red Hat recommends against combining IdM and other load-balancing or high-availability (HA) software.

Many third-party high availability solutions assume active/passive scenarios and cause unnecessary service interruption to IdM availability. Other solutions use virtual IPs or a single hostname per clustered service. All these methods do not typically work well with the type of service availability provided by the IdM solution. They also integrate very poorly with Kerberos, decreasing the overall security and stability of the deployment.