Univention Bugzilla – Bug 18619
Performance-Optimierung des AD Connectors in grossen Umgebungen
Last modified: 2011-12-13 15:50:39 CET
Die Performance des AD Connectors beim initialen Sync grosser Umgebungen sollte analysiert und weiter optimiert werden: Ansatzpunkte: - Existieren redundante Konsistenz-Checks / doppelte Prüfungen auf Gruppenmitgliedschaften? - Können LDAP-Anfragen vermieden oder zwischengespeichert werden? - Kann die Abarbeitungsreihenfolge der Änderungen optimiert werden? Detaillierte Beobachtungen aus einer Kundenumgebung finden sich an Ticket 2010040110000284.
Ich denke zu den Themen sollten einzelne Bugs erstellt werden, zur Gruppensynchronisation habe ich Bug #21010 erstellt.
Created attachment 3139 [details] ad-connector-performance_mapping-poll.patch Ein erster Patch um die Performance zu verbessern. In meinen Tests wurden die LDAP Abfragen dadurch halbiert. Die vollständigen Produkttests fehlen aber noch. Die Änderungen: 1. object_memberships_sync_from_ucs wurde von den con_modify Funktionen entfernt Das ist eigentlich nicht notwendig, da in UCS auch immer die Gruppen selbst noch modifiziert werden, wenn sich die Gruppenmitgliedschaften ändern. Für AD ist die Funktion vermutlich noch notwendig. 2. poll_ucs Es werden jetzt alle Pickle-Dateien eingelesen und daraus wird eine Übersicht erstellt, welche DNs synchronisiert werden müssen. Wenn eine DN mehrfach synchronisiert wird, so wird nur der letzte Sync dieser DN durchgeführt.
(In reply to comment #2) > 1. object_memberships_sync_from_ucs wurde von den con_modify Funktionen > entfernt > > Das ist eigentlich nicht notwendig, da in UCS auch immer die Gruppen selbst > noch modifiziert werden, wenn sich die Gruppenmitgliedschaften ändern. Für AD > ist die Funktion vermutlich noch notwendig. Es muss nochmal geprüft werden, ob durch diese Änderung bei der Initialisierung auch alle Gruppenmitgliedschaften übertragen werden.
(In reply to comment #3) > (In reply to comment #2) > > 1. object_memberships_sync_from_ucs wurde von den con_modify Funktionen > > entfernt > > > > Das ist eigentlich nicht notwendig, da in UCS auch immer die Gruppen selbst > > noch modifiziert werden, wenn sich die Gruppenmitgliedschaften ändern. Für AD > > ist die Funktion vermutlich noch notwendig. > > Es muss nochmal geprüft werden, ob durch diese Änderung bei der Initialisierung > auch alle Gruppenmitgliedschaften übertragen werden. Das ist durch die Änderung "2. poll_ucs" jetzt nicht mehr der Fall. Das Vorgehen beim Anlegen eines Benutzers, welcher automatisch in Domain Users und Domain Admins ist, sieht dann so aus: 1. Drop User 2. Sync Group 3. Sync User Wenn die Gruppe synchronisiert wird, dann ist der Benutzer noch nicht da und wird anschließend nicht in die Gruppe übernommen.
Es ist ein weiteres Problem aufgetreten. Wenn der AD Connector auf UCS Seite initialisiert wird, dann werden alle UCS LDAP Objekte einmal über den Listener in die Dump-Dateien ausgelagert. Der AD Connector bekommt dann beispielsweise die Reihenfolge: - gruppe1 - benutzer1 - benutzer2 - gruppe2 Wenn benutzer1 in gruppe1 ist, so ist zum Zeitpunkt der Synchronisation von gruppe1 auf AD-Seite der benutzer1 noch nicht vorhanden. Deshalb ist am Ende der Synchronisation benutzer1 nicht in gruppe1. Die post-con-modify-function object_memberships_sync_from_ucs hat in diesem Fall dafür gesorgt, wenn benutzer1 synchronisiert wird, dann werden alle Gruppenmitgliedschaften von benutzer1 erneut geprüft und synchronisiert. Es gibt unterschiedliche Möglichkeiten das zu lösen. Ein ganz einfacher Workaround ist es, einfach erneut einen Resync durchzuführen. Das sollte immer noch deutlich schneller sein, als die post-function zu nutzen. In UCS 3.0 müssten wir das aber anders lösen. Entweder wir merken uns im Listener Modul alle Gruppen und synchronisieren diese nach der eigentlichen Synchronisation erneut (Gruppen in Gruppen müssten ggf. beachtet werden). Eine andere Möglichkeit ist es zu überlegen, ob wir erst alle Benutzer und dann alle Gruppen synchronisieren. Hier müsste aber noch geprüft werden, ob es Probleme gibt, wenn der Benutzer eine andere primäre Gruppe als Domain Users hat.
Created attachment 3291 [details] ad-connector.py.patch Ein möglicher Patch für Comment #5. Am Ende der Initialisierung werden nochmal alle Gruppenobjekte für die Synchronisation vorgesehen.
Created attachment 3292 [details] ad_connector.py-clean.patch Dieser Patch sollte auch eingespielt werden. Ansonsten kann es vorkommen, dass die Initialisierungsphase im Listener Modul nicht durchläuft.
Patches sind mit wenigen Anpassungen übernommen.
Dadurch kommt es zumindest im S4 Connector zu folgendem Problem: 28.09.2011 08:06:31,159 LDAP (PROCESS): Drop /var/lib/univention-connector/s4/1317189986.691159. The DN cn=daniel,cn=uid,cn=temporary,cn=univention,dc=deadlock5,dc=local will synced later 28.09.2011 08:06:31,159 LDAP (PROCESS): Drop /var/lib/univention-connector/s4/1317189986.691159. The DN cn=daniel,cn=uid,cn=temporary,cn=univention,dc=deadlock5,dc=local will synced later 28.09.2011 08:06:31,161 LDAP (PROCESS): Drop /var/lib/univention-connector/s4/1317189986.768644. The DN cn=2016,cn=uidNumber,cn=temporary,cn=univention,dc=deadlock5,dc=local will synced la ter 28.09.2011 08:06:31,161 LDAP (PROCESS): Drop /var/lib/univention-connector/s4/1317189986.768644. The DN cn=2016,cn=uidNumber,cn=temporary,cn=univention,dc=deadlock5,dc=local will synced la ter 28.09.2011 08:06:31,162 LDAP (PROCESS): Drop /var/lib/univention-connector/s4/1317189987.010176. The DN uid=daniel,cn=users,dc=deadlock5,dc=local will synced later 28.09.2011 08:06:31,162 LDAP (PROCESS): Drop /var/lib/univention-connector/s4/1317189987.010176. The DN uid=daniel,cn=users,dc=deadlock5,dc=local will synced later 28.09.2011 08:06:31,196 LDAP (PROCESS): sync from ucs: [ group] [ modify] cn=domain users,cn=users,dc=deadlock5,dc=local 28.09.2011 08:06:31,196 LDAP (PROCESS): sync from ucs: [ group] [ modify] cn=domain users,cn=users,dc=deadlock5,dc=local Domain Users wird jetzt endlos weiter synchronisiert.
Wurde im S4 und im AD Connector angepasst. Reproduzieren konnte ich es so: udm users/user create --set username=test1 --set password=univention --set lastname=Test1; /etc/init.d/samba4 restart
UCS 2.4 <=> w2k8 UCS 3.0 <=> w2k8 Auf beiden UCS System wurden vor dem Start des Connectors 6000 Benutzer und 600 Gruppen zu je 10 verschiedenen und 20 gleichen Benutzer angelegt. 3.0 Sync war nach ca. 4h komplett durch. Alle Benutzer und Gruppen waren vorhanden, die Gruppenmitgliedschaften wurde stichprobenartig getestet und waren korrekt. 2.4: Sync wurde nach 10h abgebrochen, zu diesem Zeitpunkt waren alle Benutzer und Gruppen im AD vorhanden (ca. nach 4h) aber das anschließende modify (sync to ucs) lief noch. Changelog Eintrag vorhanden.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"