Sun ONE Calendar Server 6.0 Administrator's Guide |
Appendix D
Using the LDAP Data CacheThis appendix describes the Sun ONE Calendar Server LDAP data cache, which ensures that LDAP data is available immediately after it has been committed, even if the LDAP directory server is configured to include a delay in the availability of committed data. Topics in this appendix include:
Considerations for Using the LDAP Data CacheUse these guidelines to determine if your site should configure the LDAP data cache:
- If Calendar Server at your site accesses your master (or root) LDAP directory server directly with no delays in the availability of committed LDAP data, you don’t need to configure the LDAP data cache. Make sure that the local.ldap.cache.enable parameter is set to “no” (which is the default).
- If your site has deployed a Master/Slave LDAP Configuration where Calendar Server accesses the master LDAP directory through a slave LDAP directory server, which in turn introduces a delay in the availability of committed LDAP data, configure the LDAP data cache to ensure that your end users have the most recent data.
Master/Slave LDAP ConfigurationA Master/Slave LDAP configuration includes a master (root) directory server and one or more slave (consumer or replica) directory servers. Calendar Server can access the master LDAP directory server either directly or through a slave directory server:
- If Calendar Server accesses the master LDAP directory server directly, the LDAP should be accurate, and you don’t need to configure the LDAP data cache.
- If Calendar Server accesses the master LDAP directory server through a slave directory server, LDAP data changes are usually written transparently via an LDAP referral to the master directory server, which in turn replicates the data back to each slave directory server.
In this second type of configuration, problems with inaccurate LDAP data can occur because of the delay in the availability of committed LDAP data to the slave directory servers.
For example, Calendar Server commits an LDAP data change, but the new data is not available for a specific amount of time because of the delay in the master directory server updating each slave directory server. A subsequent Calendar Server client operation uses the old LDAP data and presents an out-of-date view.
If the delay in updating the slave directory servers is short (only a few seconds), clients might not experience a problem. However, if the delay is longer (minutes or hours), clients will display inaccurate LDAP data for the length of the delay.
Table D-1 lists the LDAP attributes that are affected by a delay in a master/slave LDAP server configuration where Calendar Server accesses the master LDAP directory server through a slave LDAP directory server.
To insure that your end uses have the most recent LDAP data, configure the LDAP data cache as described in the following sections: LDAP Data Cache and LDAP Data Cache Configuration Parameters.
LDAP Data CacheThe LDAP data cache resolves the master/slave LDAP configuration problem by providing Calendar Server clients with the most recent LDAP data, even when the master directory server has not updated each slave directory server.
If the LDAP data cache is enabled, Calendar Server writes committed LDAP data to the cache database (ldapcache.db file). By default, the LDAP cache database is located in the cal_svr_base/var/opt/SUNWics5/csdb/ldap_cache directory, but you can configure a different location if you prefer.
When a client makes a change to the LDAP data for a single user, Calendar Server writes the revised data to the LDAP cache database (as well as to the slave directory server). A subsequent client operation retrieves the LDAP data from the cache database. This data retrieval applies to the following operations for a single user:
Thus, the LDAP data cache database provides for:
- Data consistency across processes on a single system–The database is available to all Calendar Server processes on a multi-processor system.
- Data persistence across user sessions–The database is permanent and does not require refreshing. You can configure the time to live (TTL) for an LDAP data cache entry and the interval between each database cleanup. See LDAP Data Cache Configuration Parameters for more information.
Limitations
The LDAP data cache does not provide for:
- Reading the cache for searches where a list of entries is expected. For example, searching for attendees for a meeting. This type of search is subject to any LDAP delay. For instance, a newly created calendar will not appear in a calendar search if the LDAP search option is active and the search is performed within the delay period following the creation of a new calendar.
- Reading and writing of the cache across multiple front-end servers. Each front-end server has its own cache, which is not aware of data in other caches.
- The capability to handle a user who doesn’t always log into the same server. Such a user will generate different LDAP data in the cache on each server.
LDAP Data Cache Configuration ParametersTable D-2 describes the configuration parameters in the ics.conf file for the LDAP data cache.