Über 30 Millionen Objekte im LDAP - Ein Erfahrungsbericht über die Aktualisierung einer Consumer Mailplattform

1. Erfahrungen mit >30 Millionen Objekten im LDAP
„Lessons Learned“: Sizing, Performance, Replikation, Domain-Join,
Verbesserungen in UCS
Ingo Steuwer
Univention GmbH
steuwer@univention.de

2. Projektüberblick - Projektpartner
Ziel: Aktualisierung einer „Consumer
Mailplatform“
Projektkonsortium:
OX
Projektleitung, Webmail / Groupware
Dovecot
IMAP, MDA
Univention
LDAP /„Provisioning“, Administrations-Portal
Tarent
„Provisioning Router“

3. Projektübersicht - Anforderungen
~ 30 Millionen Mailkonten
~ 170 Millionen eingehende Mails / Tag
~ 420 Millionen Logins / Tag (IMAP, SMTP, Webmail)
~ 200 Tausend Provisioning-Requests / Tag
~ 10 Tausend LDAP-Updates / Stunde

4. Projektübersicht - Aufbau
Tools Kunde (IDM, Support etc.)
Provisioning Router
Webmail / Groupware
IMAP / MDA
Altsysteme
Provisioning API LDAP Administrations-Portal

5. UCS Komponenten - Standard
OpenLDAP
Standard UCS: Benutzer, Gruppen, Berechtigungen (interne Administration)
Projektspezifisch: Mailboxen (Adressen, Quota etc.), weitere Objekte
Univention Directory Manager (UDM)
Projektspezifische Pflege von Mailboxen (z.B. Berechnung Quota)
Diverse Konfigurationsobjekte
Univention Management Console (UMC)
Administrations-Portal, Fokus auf Mailboxen

6. UCS Komponenten - Projekt
„Business-Logik“ in UDM-Modulen
Beispiel: Berechnung der Quota einer Mailbox anhand des Vertragsstatus
Provisioning-API
SOAP-Service für Zugriff auf UDM
Benachrichtigung von OX, Dovecot und anderen über Änderungen

7. OpenLDAP Performance
Review in Vorprojekt-Phase:
ist OpenLDAP / UCS performant genug?
BDB-Backend (Standard in UCS 3.x): Performance „ausreichend“
→ aber nur knapp!
MDB: seit 2012 „feature complete“, inzwischen von OpenLDAP
empfohlen

8. OpenLDAP Performance - Vergleich
Storage RAM
slapadd (duration) ldapsearch (duration)
MDB
BDB

9. OpenLDAP MDB „caveats“
MDB Datenbank ist „sparse file“:
wächst bis „maxsize“, schrumpft nie
Backup / Kopieren mit ungeeigneten Tools generiert Datei mit „maxsize“
MDB backend kann nicht größer als „maxsize“ werden!
Vergrößern nur per export/import (slapcat/slapadd)
MDB generiert sehr viele IO-Operationen/Sekunde
Im Projekt: >10.000 IOPS pro LDAP-Server
Verhalten Konfigurierbar (erhöht Inkonsistenz-Risiko bei crashes)

10. OpenLDAP Security
LDAP ACLs
Dedizierte Accounts je Service (z.B. für OX)
Ein Service „sieht“ nur die LDAP-Attribute die er wirklich braucht
Diverse Rollen (Benutzergruppen) mit ACLs für Administration/Support
LDAP Limits
Ziel: geringere Load bei schlechten Suchanfragen, verringern der Gefahr
von Datenverlusten bei Kompromittierung
Services benötigen i.d.R. nur ein oder kein Objekt im Suchergebnis
Administration benötigt auch keine vollständigen Suchergebnisse

11. OpenLDAP Indices
LDAP Indices sind kritisch für Antwortzeiten
Aber: mehr Indices bedeuten
→ langsamere Änderungen
→ höherer Platzbedarf
Stolpersteine:
performantes Anwenden von Limits benötigt Indices auf „unerwartete“
Attribute
MDB backend hat ein „max limits“ von 128 eincompiliert

12. OpenLDAP Numbers
Initialer Import:
30.000.000 Mailbox-Objekte (~60 GB ldif)
Import per slapadd
„nosync“ MDB-Option
Dauer: 6-12 Stunden
Limit ist i.d.R. das Storage, nicht die CPU

13. UCS 4.x - Was geht nicht?
30M User oder Gruppen
Im Projekt: Mailbox ≠ User (kein POSIX etc.)
Hauptproblem: Gruppenmitgliedschaften
Wird die meisten Clients überfordern, inklusive UCS
Überschreitet diverse Limits im UDM / UMC
Samba 4
Aktuelles Limit < 1 Millionen LDAP-Objekte

14. Lessons Learned
UCS
Sizing: „einfacher“ als erwartet
Performance: hängt am Storage
UMC / UDM können ohne Anpassung genutzt werden
Sonstiges
Amazon EC2 / AWS ist für Performance-Tests ungeeignet
Security „hurts“
Minimale funktionale Änderungen haben manchmal Auswirkungen auf ACLs,
Limits, Performance...

15. Vielen Dank für Ihre Aufmerksamkeit!
Kontakt
Ingo Steuwer
Univention GmbH
steuwer@univention.de
www.univention.de