UCS Identity Management verwaltet Mail-Plattform mit über 30 Mio. Anwendern

Über zwei Jahre nach dem Start eines der größten Projekte, das Univention bisher begleiten durfte, ging im vierten Quartal 2016 eine Mail-Plattform mit über 30 Millionen verwalteten Endanwendern online. UCS Identity Management übernimmt dabei den Bereich Identity Management für sämtliche Nutzerkonten.

Vor knapp einem Jahr hatte ich bereits in dem Artikel Wie skaliert man OpenLDAP mit UCS auf über 30 Millionen Objekte? über die Anforderungen des Projekts berichtet. Inzwischen handelt es sich jedoch nicht mehr um „graue Theorie“, sondern der Live-Gang ist erfolgt und das LDAP muss sich seitdem im Echteinsatz unter der Last von Tausenden von Zugriffen pro Sekunde bewähren.

Heute möchte ich Ihnen hierzu gern ein Update geben und wichtige Erkenntnisse, die wir nach dem Live-Gang gezogen haben, mit Ihnen teilen.

Überblick

Ziel des Projektes ist die Migration einer großen Consumer Mail Plattform, auf der ca. 31 Millionen Endanwender Zugriff auf ein eigenes Konto haben, auf eine aktuelle Software-Umgebung. Das Projekt tauscht dabei nicht nur das Frontend, sondern die gesamte Plattform aus. Entsprechend umfangreich sind die notwendigen Schritte, um den Betrieb aus Sicht der Endanwender nicht zu unterbrechen.

Bereits 2014 begann daher das Projekt, in dem Univention die Rolle des Identity Providers für die Endanwender-Accounts übernimmt. Diese Accounts dienen als Benutzerverzeichnis für Mail- und Groupware-Services auf Basis von Dovecot und Open-Xchange. Wie in dieser Größenordnung nicht überraschend, unterliegt eine solche Umgebung einer hohen Last. Mehrere Millionen Logins und mehrere Tausend Änderungen müssen pro Stunde verarbeitet werden.

Rollenverteilung im Projekt

 

Univention bzw. UCS übernimmt im Projekt die Rolle des zentralen Speicherorts für die Daten über die Endbenutzer (Login, Passwort, Mail-Adresse usw.). Diese Daten werden von unterschiedlichen Systemen abgrufen (z. B. von OX und Dovecot), aber auch von ganz unterschiedlichen Systemen („Customer Tools“) gepflegt. Dabei kommen über Jahre entwickelte Verfahren und APIs zum Einsatz, die im Rahmen des Projektes basierend auf den Standardschnittstellen von UCS re-implementiert wurden („Provisioning API“). Für einen möglichst fließenden Übergang zwischen der Bestandsumgebung („Legacy Systems“) sorgt dabei der von tarent entwickelte „Provisioning Router“, der Anfragen je nach Status einer Mailbox an das Altsystem, UCS oder beide sendet.

Aufbau der IT-Umgebung

 

Der gesamte Betrieb der Umgebung wird auf zwei Haupt-Rechenzentren aufgeteilt. Alle Services für Endanwender sind in beiden Rechenzentren aktiv. Im Projekt wurde dabei die Replikation des UCS LDAP so konfiguriert, dass möglichst wenig Traffic zwischen den Rechenzentren entsteht, aber gleichzeitig eine möglichst gleichmäßige Belastung der LDAP Server gewährleistet ist. Im Gegensatz zur Standardkonfiguration im Produkt dürfen DC Slave Instanzen daher nur von DC Backup Systemen im gleichen Rechenzentrum replizieren. So ist es auch mit mehr als 50 LDAP Servern möglich, über tausend Änderungen pro Minute ohne nennenswerte Latenzen zu replizieren.

Die projektspezifische „Provisioning API“ basiert dabei auf SOAP und setzt eingehende Requests in Anfragen an die Python API des Univention Directory Managers um. Zur besseren Lastverteilung kommt dabei RabbitMQ zum Einsatz, das die Bearbeitung eingehender Änderungen sowie aktive Benachrichtigungen für Drittsysteme verwaltet. Diese Prozesse laufen dabei auf einem eigenen Cluster aus UCS Memberservern ab.

Projekt-Zahlen

Die Inbetriebnahme erfolgte direkt in Vollauslastung: Da das LDAP als Quelle für viele Migrationsprozesse dient, wurden gleich zu Beginn der Inbetriebnahme alle Daten aus dem Bestandssystem importiert und alle Änderungen seitdem laufend eingepflegt. Auf diesem Wege werden bis zu 400.000 Änderungen täglich oder bis zu 40.000 stündlich im LDAP geschrieben.

In den vorbereitenden Lasttests haben sich dabei einige interessante Grenzen aufgezeigt:

Provisioning-Anfragen (SOAP):
Das Gesamtsystem kann derzeit mindestens 70 Anfragen pro Sekunde verarbeiten. Hier lässt sich relativ leicht über die Anzahl der Instanzen im Provisioning Cluster, also der die SOAP requests verarbeitenden UCS Member Server, skalieren. Da die meisten durch Provisioning-Anfragen  generierten LDAP Zugriffe aber einfache Lese-Operationen sind, sind die vom Provisioning Cluster genutzten DC Slave Systeme kaum ausgelastet.

LDAP und Replikation:
Wie im letzten Blogartikel ausführlicher dargelegt, ist der Flaschenhals bei der Bearbeitung von LDAP Anfragen die I/O Performance des darunterliegenden Storage. Besonders bei Schreiboperationen gibt es in der Standardkonfiguration von OpenLDAP eine direkte Abhängigkeit von den erreichbaren IOps. Im Projekt haben sich darüber hinaus aber auch spezielle LDAP ACLs bemerkbar gemacht. Mit schlecht definierten ACLs, in denen die am häufigsten angewendeten Regeln erst am Ende der ACL-Definition stehen, wird die Replikation erheblich ausgebremst.

Im gesamten Projektverlauf unkritisch waren Lesezugriffe auf das LDAP. In der Projektvorbereitung wurde bei allen Prozessen darauf geachtet, möglichst spezifische LDAP Anfragen zu nutzen, deren Suchabfragen auf die konfigurierten Indices passt und die nicht mehr als 10 Ergebnisse liefern. Die Server sind daher in der Lage, tausende Anfragen pro Sekunde zu verarbeiten — in den Performance Tests war der Flaschenhals die Verarbeitungsgeschwindigkeit der LDAP Clients.

LDAP BIND Authentifikation:
Einen im Projekt überraschenden Flaschenhals ergab ein Test der maximal vom LDAP Server durchführbaren Authentifikationen. Dafür sollte die LDAP Standardoperation „LDAP BIND“ genutzt werden, die im Rahmen eines Verbindungsaufbaus zum LDAP Server eine Authentifikation mit Klartext Passwort durchführt. In OpenLDAP wird das Handling neuer Verbindungen aber im Kern seriell abgearbeitet, sodass die Performance dieses Schrittes maßgeblich von einem einzelnen CPU Core abhängt – mit den üblichen Multi-Prozessor Systemen also nicht skaliert. Damit verarbeitet ein durchschnittliches Serversystem immer noch ca. 300 Authentifikationen pro Sekunde. Ein Wert, der für einige hunderttausend Anwender völlig ausreicht, bei über 30 Millionen aber ein Cluster von Dutzenden LDAP Servern benötigen würde. Im Projekt wurde daher entschieden, dass Authentifikationen durch einen separaten Dienst abgewickelt werden, der Zugriff auf die im LDAP hinterlegten Passwort Hashes erhält.

Lessons Learned

Die wichtigsten Erkenntnisse aus dem Projekt mit UCS Identity Management sind die schon im ersten Blogbeitrag genannten Punkte:

Konzeptionelle Voraussetzung für das Gelingen sind eine gut definierte Datenstruktur im LDAP und aufeinander abgestimmte LDAP Anfragen der Clients und Indices auf dem Server. Zusammen mit einer gut konfigurierten Infrastruktur aus Hypervisor, Netzwerk und Storage ist die Hauptlast, also die lesenden Zugriffe durch IMAP, SMTP und Webmail Services für die Endanwender, unkritisch.

Gern können Sie uns zu diesem Projekt weitere Fragen stellen – entweder über unser Kontaktformular oder auf dieser Seite über die Kommentarfunktion!

Wir freuen uns auf Ihr Feedback!