The patches attached provide a framework for LDAP connection tracking,
sharing and fail-over retries in LDAP ID backend, which is designed to
address the tickets #468, 464, 465 and 466.
The patches are structured as follows:
0001-GSSAPI-ticket-expiry-time-is-returned-from-ldap_chil.patch
A small utility patch saving GSSAPI ticket expiry time in
sdap_handle for future use.
0002-Added-an-interface-to-query-number-of-configured-and.patch
Another utility patch allowing to dynamically determine number
of fail-over servers (including resolved through SRV records)
0003-LDAP-connection-usage-tracking-sharing-and-failover-.patch
The main patch -- LDAP connection tracking, sharing and
fail-over retry framework
0004-Use-new-LDAP-connection-framework-to-get-user-accoun.patch
Sample usage of the new LDAP connection framework for user
account information request
The key object of the framework is sdap_id_op object. It keeps
per-request data required for:
- LDAP connection usage tracking and sharing
- Fail-over retry logic
The typical lifespan of sdap_id_op object equals to lifespan of LDAP ID
backend request. The usage pattern is as follows:
1. At the beginning of request execution sdap_id_op is created
with sdap_id_op_create method
2. When LDAP connection is needed sdap_id_op_connect is called,
which obtains the LDAP connection (from cache or establishes new one)
and locks the obtained connection for use
3. LDAP query is executed using connection obtained
4. When query completes (succeeds or fails) sdap_id_op_done is
called to mark the LDAP connection as no longer used by the backend
request. If LDAP query has failed sdap_id_op_done also translates error
code into data provider error and provides recommendation for fail-over
retry.
5. Fail-over retry continues from step 2.
6. When the backend request completes sdap_id_op is destroyed.
Another important object of the framework is sdap_id_conn_cache, which
implements LDAP connection caching and sharing logic. As the connection
caching logic is completely opaque to BE request code, it can be changed
or improved later on with minimal impact on the other code.
The connection caching logic proposed in this patch is very similar to
the approach implemented in SSSD 1.2:
- LDAP connection is established on the first request to LDAP server;
- Single LDAP connection is shared between all concurrently
executed requests;
- LDAP connection is removed from cache when its GSSAPI ticket is
about to expire and closed as soon as all BE requests using it (if any)
complete;
To summarize, this patch will allow us to address the following issues:
- To establish only one LDAP connection when 2 or more requests are
executed in parallel (ticket #464)
- To keep track of LDAP connection usage providing support
connection caching and expired (or otherwise unwanted) connection
disposal (ticket #468)
- Consistent fail-over retry handling: attempt a fail-over retry
also when master server goes down during LDAP query execution (ticket #465)
- Promptly to close LDAP connection when GSSAPI ticket is about to
expire (ticket #466)
Please note that the patches are provided only as a material for
comments and discussion on solution architecture. I have only made sure
that they compile. I am completely open to suggestions and other
approaches on how to solve the above problems.
Eugene Indenbom