How To: Speed up of Domain Join (or updates) for Additional Servers
Especially in larger environments with thousands of LDAP objects the join of a new (backup or slave) server might take a noticeable amount of time (several hours). Same can apply for updates where new attributes introduced might need an index which takes a good amount of time, too.
The OpenLDAP transfers all objects to the new server who stores the data in its local ldap database.
Important Note: To use options 2, 3 or 4 you must not join your new system during installation. Instead, finish installation first, apply the below settings as needed and finally join the system.
Option 1: Improve your hardware.
The database is stored at /var/lib/univention-ldap. To improve writing you might mount a fast SSD instead of HDD for improved performance.
There are some more options possible (ie RAID controller, enabling write caching).
Doing some testing by using a SSD instead of a slow HDD the join got reduced from 9 hours to 1.5 hours.
Option 2:Speed up indexing
Slapindex is used to regenerate LDAP indices. By enabling “quickmode” it performs no consistency checks when writing the database. Improves indexing time, however the database will most likely be unusable if any errors or interruptions occur. For a slave or member server this can be accepted as a re-join will re-sync the LDAP database anyways.
To enable quickmode use a ucr variable:
ucr set ldap/index/quickmode=true
systemctl restart slapd
Note: You should not activate this on a UCS master server! And you should unset the variable after the successful join
ucr set ldap/index/quickmode=false
systemctl restart slapd
Option 3: Use MDB instead of BDB for upgraded systems
For UCS 3.x and earlier the use of BDB was the default. Since 4.0 new installed systems use MDB instead.
In case the system was upgraded from 3.x to 4.x it still uses BDB. To improve performance you should migrate these systems to MDB.
To migrate follow the performance guide.
Option 4: Fine tune MDB parameters
Usually every write to the local ldap database is verified but a followed read. Obviously this takes a good amount of time for each object. Verifying data is important to make sure everything got written properly in case of an issue (ie power loss).
If something goes wrong during the join it has to be started again from scratch. This will result in all previous data written being removed and rewritten during join. Conclusion is the verify of the data is not very important during a join and could be disabled therefore.
To improve performance especially during a join you can tune the settings for MDB installations by setting a variable:
ucr set ldap/database/mdb/envflags="nosync writemap"
systemctl restart slapd
You can use as parameters:
- nosync
- nometasync
- writemap
- mapasync
- noreadahead
For further details about these parameters check our performance guide.
Note: You should not activate this on a UCS master server! And you should unset the variable after the successful join
ucr unset ldap/database/mdb/envflags
systemctl restart slapd
Option 5: Clean up abandoned UDM locking objects
univention-ldapsearch -xLLL '(&(objectClass=lock)(createTimestamp>=20231230000000Z))' -b cn=temporary,cn=univention,$(ucr get ldap/base) 1.1 > ~/univention-support/delete_temporary2
Check also for timestamps less than 2023230000000Z
univention-ldapsearch -xLLL '(&(objectClass=lock)(createTimestamp<=20231230000000Z))' -b cn=temporary,cn=univention,$(ucr get ldap/base)|grep ^dn: |sed 's/dn: //' > ~/univention-support/delete_temporary2
Delete the temporary Objects (objectClass=lock)
while read dn; do echo "$dn" && ldapdelete -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret "$dn"; done < /home/univention-support/delete_temporary2