[SSSD] How to tune the failover mecanism ?

Olivier ldap at guillard.nom.fr
Mon Dec 3 20:12:28 UTC 2012


Many thanks for yours answers, I will look at all this.

I would add a comment if I may :

> I think the re-connection timeout is hardcoded as 30, I vaguely recall a
> discussion about it four years ago.
> If/when it is confirmed IMO would make sense to file an RFE.
> I am leaning to it be configurable  and think that 5 or 10 second
> timeout should be sufficient.

I may be wrong but that is not exactly the way I read the man page :
http://linux.die.net/man/5/sssd-ldap

On failover section :

--> Further connection attempts are made to machines or services
marked as offline after a --> specified period of time; this is
currently hard coded to 30 seconds.

As I understand it, once a machine or service has been stamped "offline",
then it won't be queried before 30 second has passed.

The delay I would like to know (and to tune if possible) is the time after which
sssd query the next ldap server in ldap_uri list if the current one is
not reachable
(IMHO, 5 second would be more than enough and I think would even tune less
 if I could).

----
Olivier


2012/12/3 Dmitri Pal <dpal at redhat.com>:
> On 12/03/2012 10:35 AM, Olivier wrote:
>> Hello everyone,
>>
>> I use sssd to authenticate users on redhat boxes,
>> as a layer between pam and my ldap serverS.
>>
>> User ldap accounts are announced but 3 replicated
>> (open)ldap servers.
>>
>> I have declared my 3 servers in sssd.conf:
>>
>> ldap_uri: ldap://ldap1.example.fr,ldap://ldap2.example.fr,ldap://ldap3.example.fr
>>
>> That works, but I would like now to better tune the
>> sssd failover and cache function offered by sssd,
>> and I'm a bit stuck.
>>
>> Questions :
>>
>> 1- about the failover mecanism, I read in sssd-ldap man page :
>>
>> " If the resolution attempt succeeds, the back end tries to connect to
>> a service on this machine.
>>   If the service connection attempt fails, then only this particular
>> service is considered offline and
>>   the back end automatically switches over to the next service."
>>
>> I there any way to tune the "timeout" after which the bakend considers
>> that the attempt
>> to connect to a server has failed and therefore that it's time to try
>> the next one ?
>
> I think the re-connection timeout is hardcoded as 30, I vaguely recall a
> discussion about it four years ago.
> If/when it is confirmed IMO would make sense to file an RFE.
> I am leaning to it be configurable  and think that 5 or 10 second
> timeout should be sufficient.
>
>
>>
>> 2- I'm a bit stuck to configure the behaviour of the boxes with regard to
>>     sssd cache (in anthother word, I have not perfectly understood under
>>     which condition sssd returns cached information rather than querying
>>     ldap and how to tune that).
>>
>> Intuitively, I would something like the sssd cache for an entry to be returned
>> rather than querying ldap if :
>>
>> -> the cache was "recently" refreshed for that entry ( not sur what I
>> should mean
>>     by "recently" )
>> -> no ldap server respond (I suspect that this would be tuned with
>> "ldap_search_timeout" ?)
>>
>> Any help from anyone ?
>
> If the system is offline the data is served from the cache.
> If the system is online but the entry is not available or the entry is
> pretty old (defined by the cache expiration timeout) then the data is
> fetched from LDAP and returned to the caller in parallel to updating cache.
> If the system is online and entry is available from the cache and it is
> younger than half of its life time then it is served from the cache.
> If the system is online and entry is available from the cache and it is
> older than half of its life time then it is served from the cache but an
> async operation to fetch the entry from LDAP and update the cache is
> launched in the background.
>
> HTH
>
>
>> Thanks,
>>
>> ---
>> Olivier
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list