Chapter 4. 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. Client-side failover capability By default, the SSSD service on an IdM client is configured to use DNS service (SRV) resource records so that the client can automatically determine the best IdM server to connect to. Primary and backup server configuration The server resolution behavior is controlled by the _srv_ option in the ipa_server parameter of the /etc/sssd/sssd.conf file: Example /etc/sssd/sssd.conf With the _srv_ option specified, SSSD retrieves a list of IdM servers ordered by preference. If a primary server goes offline, the SSSD service on the IdM client automatically connects to another available IdM server. Primary servers are specified in the ipa_server parameter. SSSD attempts to connect to primary servers first and switches to backup servers only if no primary servers are available. The _srv_ option is not supported for backup servers. Note SSSD queries SRV records from the DNS server. By default, SSSD waits for 6 seconds for a reply from the DNS resolver before attempting to query another DNS server. If all DNS servers are unreachable, the domain will continue to operate in offline mode. You can use the dns_resolver_timeout option to increase the time the client waits for a reply from the DNS resolver. 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: Example /etc/sssd/sssd.conf Failover behavior for IdM servers and services SSSD failover mechanism treats an IdM server and its services independently. If the hostname resolution for a server succeeds, SSSD considers the machine is online and tries to connect to the required service on that machine. If the connection to the service fails, SSSD considers only that specific service as offline, not the entire machine or other services on it. If hostname resolution fails, SSSD considers the entire machine as offline, and does not attempt to connect to any services on that machine. When all primary servers are unavailable, SSSD attempts to connect to a configured backup server. While connected to a backup server, SSSD periodically attempts to reconnect to one of the primary servers and connects immediately once a primary server becomes available. The interval between these attempts is controlled by the failover_primary_timeout option , which defaults to 31 seconds. If all IdM servers become unreachable, SSSD switches to offline mode. In this state, SSSD retries connections every 30 seconds until a server becomes available. 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. Additional resources sssd.conf(5) man pages on your system

Commands:
[domain/example.com] id_provider = ipa ipa_server = _srv_ , server1.example.com, server2.example.com ipa_backup_server = backup1.example.com, backup2.example.com
[domain/example.com] id_provider = ipa ipa_server = server1.example.com, server2.example.com ipa_backup_server = backup1.example.com, backup2.example.com