Direkt zum Inhalt
10.11.2022 - Fachbeitrag

Kein Dovecot Director mehr in Dovecot 3.0?

Heinlein Support Consulting Mailserver
Testimonial Portrait von Carsten Rosenberg

Mailserver-Consultant Carsten Rosenberg über die anstehenden Änderungen bei Dovecot und die Auswirkungen für Admins

Dovecot Cluster Architecture

Die ersten Updates in der Dokumentation von Dovecot 3.0 sprechen davon, dass das Dovecot Director-Feature aus Dovecot entfernt wird und durch eine neue Cluster-Architektur ersetzt wird.

https://doc.dovecot.org/3.0/admin_manual/cluster/

In der folgenden Diskussion auf der Maillingliste haben die Dovecot-Entwickler dargelegt, dass der Director zu komplex für kleine Setups und nicht 100% fehlerfrei für sehr große Setups ist. Zumindest können wir bestätigen, dass man in großen Setups ein wenig vorsichtig mit einigen Director-Operationen sein sollte. Die Komplexität des Dovecot Director in kleinen Setups sehen wir aber nicht als Problem. Sobald man sich für Redundanz und für mehr als ein Backend entscheidet, bietet der Dovecot Director große Vorteile bei der Lastverteilung und dem Management der User-Zuordnungen auf die Backends. Die Idee der Dovecot-Entwickler in kleineren Setups auf Active/Passive zu setzen, halten wir nur in wenigen Fällen für die richtige Idee.

Ersetzt wird der Director durch eine Cluster-Komponente, die scheinbar genauso wie der Director User- bzw. Backend-Zuordnungen verwalten kann und der Director-Funktion architektonisch ziemlich nahe steht. Auffallend ist, dass bei der neuen Cluster-Architektur lokale Datenbanken und eine zentrale CassandraDB vorgesehen sind. Also eine zentrale Datenbankkomponente mit lokalem Caching bzw. lokalen extra Informationen. Das sollte vor allem bei großen, verteilten Setups mit verschiedenen Standorten und bei der Containerisierung von Vorteil sein. Denn der Dovecot Director hat mit seinem Ring-Protokoll mit den jeweils anderen Direktoren direkt kommuniziert. Das konnte bei häufigen Änderungen an Ring-Mitgliedern schon einmal problematisch sein oder aus Netzwerksicht vielleicht nicht immer automatisch realisierbar.

So gesehen ist die Weiterentwicklung des Directors hin zum Cluster erst einmal eine positive Entwicklung, die selbst in kleineren Setups Vorteile bringen sollte. Leider scheint der Cluster eine Dovecot Pro 3.0 Komponente zu werden. Das heißt, der Cluster ist erst einmal nicht in der Community-Variante enthalten, sondern nur in der lizenzierbaren PRO Variante.

Damit fällt in der Community-Variante der Dovecot Director leider ersatzlos weg.

Die Frage ist aber: Geht uns damit der Layer-7-Loadbalancer (IMAP-Protokoll) und Proxy verloren, den wir so sehr schätzen?

Was ist das Konstrukt Dovecot Director eigentlich genau?

Der Dovecot Director als Gesamtsystem ist ein Layer-7-Proxy und Loadbalancer. Layer-7 bedeutet, dass es das (IMAP-)Protokoll versteht und entsprechend reagieren kann. Dagegen kennt ein Layer-4-Proxy wie klassische Loadbalancer keine Protokollinhalte, sondern nur die IP-Daten einer Kommunikation. Sie können also nicht z.B. anhand eines Usernamens routen.

Der Dovecot Director bietet uns die Möglichkeit den User optional zu Authentifizieren und anhand seines Logins bzw. anhand seiner Informationen aus der User-DB an einen bestimmten Next-Hop weiterzureichen. Das kann genauso ein Dovecot IMAP-Server auf einem anderen Host sein wie ein Exchange. Und nicht nur IMAP wird unterstützt, sondern auch alle anderen Protokolle, die Dovecot beherrscht.

Neben der Weiterleitung an einen einzelnen Server beherrscht der Dovecot Director auch die Weiterleitung an einen Server aus einer Liste von Servern. Welche Server zu welcher Liste gehören, wird im Director definiert. Welche Liste für einen User in Frage kommt, wird über die Option director_tag bei der Authentifizierung des Users ermittelt. Der Director kümmert sich hier auch um die gerechte Verteilung der einzelnen Verbindungen auf die entsprechenden Server.

Die einfachste Möglichkeit Dovecot IMAP Backends hochverfügbar zu machen, ist die Replikation via Dovecot dsync. Hierbei werden die Postfachdaten eines Users über zwei Server mit Dovecot-Mitteln sehr effizient (wenn auch in den letzten Versionen nicht immer fehlerfrei) synchron gehalten. Das klappt automatisch leider immer nur mit genau zwei Servern.

Das heißt, in typischen Setups haben wir ein oder mehrere Pärchen an Dovecot-Backend-Servern auf die unsere User dann verteilt werden. Daher auch der Begriff Sharding, wenn man vom director_tag bzw. den Listen von Next-Hop-Systemen spricht.

Dovecot Director - nur ein Teil des Rädchens

Alles was wir derzeit als Dovecot Director zusammenfassen, ist eigentlich ein Zusammenspiel verschiedener Komponenten, die genauso auf Backend-Systemen und Standalone-Dovecots zum Einsatz kommen.

Wir benötigen für die Funktionalität des Directors die Services auth, (imap-) login, proxy und director. auth und login werden so auch vom Backend verwendet, proxy nur in ganz speziellen Fällen. Nur für den Service director finden wir auf dem Backend keine Einsatzmöglichkeit.

Der Login-Prozess (je nach Protokoll z.B. imap-login) bindet sich an den entsprechenden Port und wartet auf eingehende Verbindungen. Zur Authentifizierung des Users werden bestimmte Werte aus der Kommunikation an den auth-Service übermittelt und dort z.B. geprüft und die Account-Daten abgerufen. Beim LMTP-Protokoll wird z.B. die Empfängeradresse übergeben und darüber das nächste Ziel ermittelt. Demgegenüber gibt es bei dem IMAP-Protokoll einen Login, so dass hier neben der Bereitstellung der Account-Daten mittels des Usernamen auch das Passwort des Users geprüft werden kann.

Eine der Optionen, die vom auth-Service zurückgeliefert werden können, ist proxy=yes und das dazugehörige host=10.0.0.1. Das weist den jeweiligen Login-Service an, dass der User kein lokales Postfach hat, sondern die Verbindung an den Host 10.0.0.1 weitergereicht werden soll (per Proxy-Verbindung).

Wenn der Service director dazu kommt, gibt es noch einen Zwischenschritt. Nachdem auth die Account-Daten abgerufen hat, werden diese an den director-Service gegeben, damit sie dort weiterverarbeitet werden können. Der Service director sucht in den Account-Daten nun nach dem Attribut director_tag. Ist dieser vorhanden (z.B. director_tag=shard1), dann wird versucht die Liste der Server mit dem Namen "shard1" zu finden und einen Server aus der Liste auszuwählen. Dieser Server wird dann ggf. aufgelöst und als host-Option gesetzt. Das heißt unsere host-Option muss nicht mehr statisch über die Account-Daten zurückgeliefert werden, sondern der director wählt den aus seiner Sicht empfehlenswertesten Server aus.

Der Service director merkt sich diese getroffene Zuordnung nicht nur lokal selbst, sondern synchronisiert diese auch mit seinen Director-Partnern im Ring. Wenn der gleiche User sich also erneut einloggt, wird er wieder an den gleichen Server aus der Liste verwiesen. Selbst, wenn sich der User mehrfach gleichzeitig einloggt (Desktop & Mobil) und dabei auch auf unterschiedlichen Direktoren landet, wird er immer an das gleiche Backend weitergeleitet. Das hat den riesigen Vorteil, dass die Postfach-Daten des Users bereits im Cache/Memory sind und nicht immer wieder neu geladen werden müssen.

Autor: Carsten Rosenberg, Mailserver-Consultant, Heinlein Support