Die Ausfallsicherungsfunktionalität ermöglicht es, dass Backends automatisch auf einen anderen Server wechseln, falls der aktuelle versagt. Die Server werden als durch Kommata getrennte Liste angegeben. Um das Komma herum ist eine beliebige Anzahl von Leerzeichen erlaubt. Die Server werden in Reihenfolge der Bevorzugung aufgeführt. Die Liste kann eine beliebige Anzahl von Servern enthalten. Von jeder Konfigurationsoption mit aktivierter Ausfallsicherung existieren zwei Varianten: primary und backup. Die Idee dahinter ist, dass Server in der Liste »primary« bevorzugt werden und nur nach »backup«-Servern gesucht wird, falls kein »primary«-Server erreichbar ist. Falls ein »backup«-Server ausgewählt wird, wird eine Dauer von 31 Sekunden bis zur Zeitüberschreitung festgelegt. Nach dieser Zeit wird SSSD periodisch versuchen, sich mit einem der primären Server zu verbinden. Ist dies erfolgreich, wird es den derzeit aktiven (»backup«-)Server ersetzen. Der Ausfallsicherungsmechanismus unterscheidet zwischen einer Maschine und einem Dienst. Das Backend versucht zuerst, den Rechnernamen der angegebenen Maschine aufzulösen. Falls dieser Versuch scheitert, wird davon ausgegangen, dass die Maschine offline ist und sie auch für keinen anderen Dienst zur Verfügung steht. Kann der den Namen erfolgreich aufgelöst werden, versucht das Backend, sich mit einem Dienst auf dieser Maschine zu verbinden. Ist das nicht möglich, dann wird nur dieser bestimmte Dienst als offline angesehen und das Backend wechselt automatisch weiter zum nächsten. Die Maschine wird weiterhin als online betrachtet und kann immer noch für andere Dienste herangezogen werden. Weitere Verbindungsversuche zu Maschinen oder Diensten, die als offline gekennzeichnet sind, werden erst nach einer angegebenen Zeitspanne unternommen. Diese ist derzeit hart auf 30 Sekunden codiert. Falls es weitere Maschinen durchzuprobieren gibt, wechselt das Backend als Ganzes in den Offline-Modus und versucht dann alle 30 Sekunden, sich erneut zu verbinden. Resolving a server to connect to can be as simple as running a single DNS query or can involve several steps, such as finding the correct site or trying out multiple host names in case some of the configured servers are not reachable. The more complex scenarios can take some time and SSSD needs to balance between providing enough time to finish the resolution process but on the other hand, not trying for too long before falling back to offline mode. If the SSSD debug logs show that the server resolution is timing out before a live server is contacted, you can consider changing the time outs. This section lists the available tunables. Please refer to their description in the sssd.conf5 , manual page. dns_resolver_server_timeout Time in milliseconds that sets how long would SSSD talk to a single DNS server before trying next one. Voreinstellung: 1000 dns_resolver_op_timeout Time in seconds to tell how long would SSSD try to resolve single DNS query (e.g. resolution of a hostname or an SRV record) before trying the next hostname or discovery domain. Voreinstellung: 3 dns_resolver_timeout How long would SSSD try to resolve a failover service. This service resolution internally might include several steps, such as resolving DNS SRV queries or locating the site. Voreinstellung: 6 For LDAP-based providers, the resolve operation is performed as part of an LDAP connection operation. Therefore, also the ldap_opt_timeout timeout should be set to a larger value than dns_resolver_timeout which in turn should be set to a larger value than dns_resolver_op_timeout which should be larger than dns_resolver_server_timeout.