© Ion Chiosea, 123RF

Alle Postfächer der Firma auf einem einzelnen Server lagern – das etabliert einen Single Point of Failure. Stöhnen die User zudem über Performance-Einbrüche, ist es Zeit, seinen IMAP-Server zu replizieren.

Die Last auf dem lokalen IMAP-Server wächst mit jedem neuen Nutzer. Zugleich bleibt er als alleiniger Server auch ein Single Point of Failure. Derweilen meckern die Außendienstmitarbeiter auffällig laut über den langsamen Transfer ihrer E-Mails. Kein Wunder: Die Bandbreite der Firmenanbindung ist leider begrenzt. Den Mailserver in ein externes Rechenzentrum zu verlagern ist aber wegen der vielen internen Benutzer keine Option. Was tun, sprach Zeus?

Zum Glück kommt als IMAP-Server Dovecot [1] zum Einsatz. Dank der Dovecot-Replikation [2] kann der IMAP-Server sowohl im Firmennetz als auch im Rechenzentrum stehen. Dazu stellen die Admins im Rechenzentrum einfach einen zweiten IMAP-Server bereit. Der interne DNS-Eintrag zeigt dann auf den bisherigen Server. Eine Abfrage von außen liefert hingegen die IP-Adresse des neuen Servers im Rechenzentrum zurück.

Beim Abgleich der beiden Server kommt eine für Dovecot entwickelte Replikation mit Hilfe des Dsync-Protokolls ins Spiel, das der Artikel im Detail vorstellt.

Dovecot-Replikation

Replikation besteht typischerweise darin, Daten zu duplizieren und dauerhaft zu synchronisieren. Idealerweise wandern beim Synchronisieren nur die geänderten Daten hin und her, nicht der gesamte Datenbestand. So lassen sich mit zeitnaher Replikation redundante und hochverfügbare Dienste aufbauen.

Dovecot unterstützt seit der Version 2.2 eine automatische inkrementelle Replikation zwischen zwei Mailbox-Systemen (siehe Kasten “Dovecot Mailbox”). Dabei ermöglicht Dovecot standardmäßig eine asynchrone Master-zu-Master-Replikation. Das heißt, Nutzer oder System dürfen an beiden Endpunkten der Replikation Änderungen vornehmen.

Das Herzstück bildet aber nicht die Replikation selbst, sondern der schon anderweitig verfügbare Dsync-Mechanismus, der sich auch abseits der Replikation nutzen lässt, um Mail-Datenbestände abzugleichen.

Typische Nutzung

Ihren bevorzugten Einsatzbereich findet die Replikation bei größeren Mailsystemen, die mittels Replikation und mit Hilfe des Dovecot Director [3] ein redundantes und lastverteiltes Mailboxsystem aufbauen. Dovecots Direktoren sind intelligente IMAP-Proxys (und nicht nur das), die Anwenderzugriffe per Tunnel an die passenden Backend-Server weiterleiten. Bestehen diese Server aus einem replizierenden Pärchen, verteilt der Direktor die Last auf beide. Fällt einer der beiden Replikationspartner aus, kann der verbliebene, wenn auch unter höherer Last, weiterhin alle Dienste und Daten bereitstellen (Abbildung 1).

Abbildung 1: Wie die Abbildung zeigt, kann der Admin auch problemlos mehrere Replikationspaare aufsetzen.

Alternativ wäre es möglich, die Mailboxdaten auf einem gemeinsamen Storage abzulegen, auf den dann alle Dovecot-Backends zugreifen. Dieser muss aber hochverfügbar sein. Zudem warten beim gleichzeitigen Zugriff auf dieselbe Mailbox immer wieder Herausforderungen, die Admins meistern müssen.

Für viele Admins liegt daher der Vorteil von Replikation gegenüber der Nutzung eines gemeinsamen (Netzwerk-)Speichers auf der Hand. Die Daten liegen auf natürliche Weise mehrfach physisch vor und sind so resistent gegen den Ausfall eines Speichersystems. Außerdem stellt der Admin die Daten so problemlos an mehreren Standorten bereit.

In die Herde

Was aber muss nun passieren, damit ein ausgefallener Server wieder in den Verbund zurückkehren kann? Oft fürchten Admins in diesen Situationen ein Split-Brain-Szenario. Das ist zum Glück nicht der Fall. Dovecot gleicht während der Synchronisation auch die verfügbaren E-Mail-Objekte und eventuelle Änderungen ab. Dank seines Indexierungs-Mechanismus bemerkt Dovecot dabei auch genau, ob ein User zum Beispiel eines der Objekte gelöscht hat.

Ein weiterer Einsatzbereich der Dovecot-Replikation besteht in der Migration von E-Mail-Daten von einem auf einen anderen Server. Dabei macht es sich der Admin zunutze, dass Dovecot beim Replizieren ein Mailobjekt überträgt. Er darf nämlich die beiden replizierenden Server mit unterschiedlichen Einstellungen betreiben. Er kann die Mails in einem anderen Format (etwa Maildir und »mdbox«) und in einem anderen Pfad speichern. Auch die erlaubten Anmeldemechanismen und verwendeten Datenbanken dürfen sich unterscheiden. Der andere Server behandelt die übertragene Änderung wie jede andere vom User verursachte Änderung oder eingehende E-Mails.

Aus diesem Grund eignet sich Replikation auch zur Migration von Daten von einem alten auf einen neuen Server. Hierbei sollten die Dovecot-Versionen allerdings immer möglichst identisch sein.

Richtungweisend

Die Dovecot-Replikation benötigt zum Synchronisieren der Datenbestände keine dauerhafte Verbindung. Findet auf einem der beiden Server eine Änderung statt, repliziert dieser Server die Mailbox erneut. Auch wenn nur ein Server die Replikation auslöst, erfolgt diese stets bidirektional. Warten etwa auf dem anderen Server Änderungen, die dank eines Netzwerkausfalls noch nicht übertragen sind, geschieht dies jetzt automatisch.

Als Herzstück der Replikation dient der Dsync-Mechanismus. Der steckt auch hinter den administrativen Dovecot-Befehlen »doveadm import«, »doveadm backup« und »doveadm sync«.

Dovecot gleicht mit Hilfe von Dsync zwei Mailboxen ab – uni- oder bidirektional. Eine Richtung decken »doveadm import« und »doveadm backup« ab. Sie lesen die Daten auf einer Seite und integrieren sie in eine Mailbox. Oder sie schreiben Daten aus einer Mailbox heraus. Bidirektional agiert »doveadm sync«. Es stößt einen Mechanismus an, der beide Seiten abgleicht und auf denselben Stand bringt. Eine Replikation ist also schlicht ein automatisiertes »doveadm sync«.

Der Dsync-Mechanismus beschränkt sich nicht auf den Abgleich von Dovecot-Installationen. Dsync liest valide Mailboxen auch aus einem lokalen Verzeichnis oder benutzt einen fremden IMAP- oder POP3-Server. Es ist sogar möglich, die alten IMAP- und POP3-UIDs zu recyceln. Dazu synchronisiert Dovecot die Daten via IMAP und meldet sich dann über POP3 an, um die verwendeten UIDs zu übernehmen. Denn: Ändern sich bei einem POP3-Account die UIDs, lädt der Client alle Mails erneut herunter. Für frisch migrierte Server mit Tausenden Accounts ist das ein Problem.

Theoretisch funktioniert all dies auch für die Replikation. Praktisch warten aber konfigurationsbedingte und logische Fallstricke. Doch haben die Dovecot-Entwickler einen intelligenten Weg gefunden, zwei Mailboxen über Dsync synchron zu halten. Sie legen keine reinen Kopien an. Der Synchronisationsprozess gleicht vielmehr verfügbare Objekte und deren Metadaten (Flags wie Gelesen, Ungelesen und so weiter) ab.

Dazu identifiziert Dovecot ein Objekt anhand bestimmter Merkmale. Es ist also nicht einmal nötig, dass die Objekte auf beiden Seiten den gleichen eindeutigen Identifier – die UID – verwenden. Dovecot protokolliert zugleich Änderungen an Objekten in Indexdateien. So erkennt der IMAP-Server bei einer Synchronisation problemlos, ob ein User auf einer Seite ein E-Mail-Objekt gelöscht hat.

Dsync gleicht jedoch nicht nur E-Mails ab. Einmal eingerichtet überträgt es auch Sieve-Skripte [4], Subscriptions sowie Access Control Lists (ACLs) der Benutzer. Dabei beschränkt sich die Synchronisation jedoch stets auf die Elemente in einer Mailbox. Indexdateien, globale ACLs, globale Sieve-Skripte, Konfigurationsdateien oder Nutzerdatenbanken überträgt Dsync nicht.

Synchron-Modi

Die Software kennt drei Arten der Synchronisation: Full, Fast und Stateful. In der Variante Full gleicht Dsync jedes Mailobjekt auf beiden Seiten ab. Die Variante Fast versucht Änderungen anhand der aktuellen »UID« oder des Antwortcodes »HIGHESTMODSEQ« zu erkennen. Bei Stateful hingegen merkt sich Dovecot den Stand der letzten Synchronisation und überträgt nur zeitlich nachgeordnete Änderungen.

Den Stateful-Mechanismus verwendet auch die Replikation. Zusätzlich kennt sie den Parameter »replication_full_sync_interval«. Der sorgt dafür, dass Mailboxen nach einer definierten Zeit eine volle Synchronisation durchlaufen.

Beteiligte Dienste

Für die Netzwerkverbindung zwischen zwei Servern nutzt Dovecot im Normalfall den Service »doveadm«. Den bindet der Admin an einen TCP-Socket, wo er dann administrative Befehle von »doveadm«-Clients auf entfernten Systemen erwartet. Die Authentifizierung erfolgt über einen Benutzernamen und ein Passwort oder via API-Schlüssel.

Wer will, kann die Kommunikation mit SSL verschlüsseln, wobei Dovecot bei einer SSL-Verbindung die Zertifikatskette überprüft und nur verifizierte Verbindungen erlaubt. Alternativ darf der Dsync-Nutzer die Replikation auch über eine SSH-Verbindung verwenden.

Damit die Replikation automatisch startet, sobald auf einer Seite Änderungen vorliegen, braucht das Setup noch zwei weitere Dienste. Das sind »aggregator« und »replicator«. Der erste erhält eine Nachricht von anderen Diensten wie IMAP, LMTP und Sieve, sobald eine Mailbox eine Veränderung bemerkt. Er erinnert dann den »replicator« daran, dass Arbeit auf ihn wartet und er eine Mailbox replizieren muss.

Der »replicator« reagiert, indem er »doveadm sync« mit den passenden Parametern aufruft und den Erfolg der Replikation überwacht. Schlägt die Replikation einer Mailbox fehl, versucht er, diese schnellstmöglich nochmals abzugleichen.

User-Datenbanken

Wie bei anderen administrativen »doveadm«-Kommandos, die alle bekannten Nutzer betreffen, muss Dovecot auch für die Replikation eine komplette Benutzerliste abrufen. Gibt es nur lokale Systemnutzer oder verwendet Dovecot eine Nutzerliste im Textformat, muss der Admin den Abruf nicht definieren. Laufen im Hintergrund hingegen Datenbanken wie SQL oder LDAP, muss er so genannte »iterate_query« definieren.

Ohne diese Liste gleicht die Replikation nicht sämtliche User regelmäßig vollständig ab. Um die »iterate_query« zu testen, hilft der Befehl »doveadm user ‘*’«. Er gibt eine Liste aller Nutzer zurück, die Dovecot kennt.

addgroup --gid 10000 vmail
adduser --system --disabled-login --home /srv/mail --uid 10000 -gid 10000 vmail

wget -O - https://repo.dovecot.org/ DOVECOT-REPO-GPG  | sudo apt-key add -
add-apt-repository 'deb https://repo.dovecot.org/ce-2.3-latest/debian/stretch stretch main'
apt update && apt install dovecot-imapd

#!include auth-system.conf.ext
!include auth-passwdfile.conf.ext

#user:password:uid:gid:(gecos):home:(shell):extra_fields
user1@example.com:{PLAIN}User1_Passwort::::::
user2@example.com:{PLAIN}User2_Passwort::::::

# das Home-Verzeichnis eines Users liegt etwa unter /srv/vmail/example.com/user1
mail_home = /srv/vmail/%d/%n
# die Mails eines Users landen in dessen Homeverzeichnis im Unterordner Maildir. Sie werden im Maildir-Format gespeichert
mail_location = maildir:~/Maildir
# Alle virtuellen Nutzer laufen mit dem zuvor angelegten Systemuser vmail
mail_uid = 10000
mail_gid = 10000
# unverschlüsselte Plain-Text-Anmeldung erlauben
disable_plaintext_auth=no
# Mailbox-Debugging aktiviert
mail_debug = yes

Was aber würde passieren, wenn beide Seiten unterschiedliche User-Datenbanken verwenden und nur einige Benutzer auf beiden Seiten definiert sind? Beide Server würden versuchen ihre gesamte User-Liste zu replizieren. Da der Partner-Server eingehende Replikationsanfragen aber nur akzeptiert, wenn der User auch auf der anderen Seite existiert, würde die Replikation nur die Schnittmenge beider User-Datenbanken abgleichen.

Replikation einrichten

Um die nötigen Dienste und Optionen einzurichten, erweitert der Admin die im Kasten “Dovecot aufsetzen” erwähnte Datei »99-myconfig.conf« um die in Listing 1 gezeigten Zeilen. Die erste Zeile ergänzt dabei die zu ladenden Dovecot-Plugins um die Erweiterungen »notify« und »replication«.

01 mail_plugins = $mail_plugins notify replication
02
03 service doveadm {
04   inet_listener {
05     port = Portnummer
06   }
07 }
08
09 doveadm_password =  Passwort
10 doveadm_port = Portnummer
11
12 service aggregator {
13   fifo_listener replication-notify-fifo {
14     user = vmail
15   }
16   unix_listener replication-notify {
17     user = vmail
18   }
19 }
20
21 service replicator {
22   process_min_avail = 1
23   unix_listener replicator-doveadm {
24     mode = 0660
25     user = vmail
26     group = vmail
27   }
28 }
29
30 plugin {
31   mail_replica = tcp:10.0.0.2
32 }

Zeile 3 definiert einen Service »doveadm«, der auf einem TCP-Socket mit wählbarer Portnummer lauscht. »doveadm_password« definiert ein Passwort, das der Admin verwenden muss, will er sich am vorher definierten »doveadm«-Port erfolgreich anmelden. Zugleich nutzt Dovecot dieses Passwort, um sich an entfernten »doveadm«-Servern anzumelden. Das Passwort sollte im Falle einer Replikation also auf beiden Servern gleich lauten. »doveadm_port« definiert den Port auch für den »doveadm«-Client, der darüber mit entfernten »doveadm«-Servern kommuniziert.

Der Bereich für den »aggregator«-Dienst (ab Zeile 12) definiert eine Fifo-Warteschlange und einen Socket, den Dienste wie IMAP, LMTP oder Sieve verwenden, um eine Änderung bekanntzugeben. Der Bereich für den Dienst »replicator« (ab Zeile 21) definiert einen Socket, den das »doveadm«-Kommando ansprechen darf, um Befehle abzusetzen oder den Status der Replikation abzufragen.

Eine Konfiguration fehlt noch – die klärt, mit welchem Server sich der lokale standardmäßig repliziert. Da es sich um eine Plugin-Option handelt, landet die Konfiguration in der Sektion »plugin« (Zeile 30). Damit erweitert sie eventuell Optionen bestehender Plugins.

Die von Dovecot verarbeitete endgültige Konfiguration, die alle Konfigurationsdateien einschließt, lässt sich am Ende über den Befehl »doveconf« anzeigen. Um sie zu aktivieren, lädt der Admin mittels »doveadm reload« den Dovecot-Dienst neu. Schon kurz danach beginnt der »doveadm«-Prozess damit, die Synchronisationen zu starten, selbst wenn es keine Änderungen an den Mailboxen gab. Grund dafür ist die Option »replication_full_sync_interval«. Da es zuvor nie einen Abgleich gab, ist das Full-Sync-Intervall für Dovecot abgelaufen. Dieser Logik folgend startet der Dienst eine vollständige Synchronisation.

Admin-Befehle

Hat der Admin im Quick-Install-Prozess »mail_debug« aktiviert (siehe Kasten “Dovecot aufsetzen”), kann er nun im Log nachvollziehen, wie der »doveadm«-Client nacheinander die Mailboxen der Benutzer öffnet.

Um das Ganze zu überwachen und zu verwalten, stellt »doveadm« zugleich weitere Befehle bereit. Wie Listing 2 zeigt, gibt das Kommando »doveadm replicator status« einen summarischen Überblick über den Stand der zu replizierenden Mailboxen aus. Bei »sync« handelt es sich dabei um Replikationsanfragen, die Dovecot synchron ausführen muss, um eine Mail erfolgreich zu speichern. Synchrone Requests muss der Admin über die Option »replication_sync_timeout« aber erst explizit einschalten.

01 Queued 'sync' requests        0
02 Queued 'high' requests        0
03 Queued 'low' requests         0
04 Queued 'failed' requests      0
05 Queued 'full resync' requests 0
06 Waiting 'failed' requests     0
07 Total number of known users   2

Ansonsten läuft die Dovecot-Replikation zwar sehr schnell ab, aber genau genommen asynchron. Die »high requests« in Listing 2 dienen der asynchronen Übertragung von E-Mail-Objekten, während die »low requests« alle anderen Übertragungen zusammenfassen. »Failed requests« sind bei erstmaligem Versuch fehlgeschlagene Replikationen, während »Waiting ‘failed’ request« auf längerfristige Probleme verweisen. »’Full resync’ requests« sind entsprechend wartende vollständige Replikationen.

Die »Total number of known users« zeigt schließlich die Anzahl der bekannten Replikations-Nutzer an. Sie muss aus mehreren Gründen nicht mit der Summe der lokalen User korrelieren, sondern stellt die Anzahl der Einträge in der Datei »/var/lib/dovecot/replicator.db« dar. In dieser trackt Dovecot den Status der Synchronisation eines Users.

Den detaillierten Replikationsstatus eines Benutzers lässt sich der Admin über »doveadm replicator status User@example.com« ausgeben. Das klappt für alle User oder eine Suchmaske über: »doveadm replicator status ‘*’« (Listing 3).

01 username                      priority fast sync full sync success sync failed
02 user1@example.com             none     00:01:33  14:34:33  00:01:33     -
03 user2@example.com             none     00:10:56  14:34:33  00:10:56     -

Ein weiterer Status-Befehl zeigt die laufenden Replikationen an: »doveadm replicator dsync-status« (Listing 4). Hier erscheinen neben dem Benutzernamen die Art der Synchronisation und der aktuelle Status. Dabei entspricht »incremental« dem oben erwähnten Stateful, »normal« dem Fast-Mechanismus sowie »full« einer vollständigen Synchronisation.

01 username                   type         status
02 user2@example.com          full         Waiting for dsync to finish
03 user1@example.com          incremental  Waiting for handshake
04                            -            Not connected
05                            -            Not connected

Über »doveadm replicator add/remove« ergänzt und entfernt der Admin User zur Laufzeit. Bei einem Neustart vergisst Dovecot die Änderungen und erzeugt die User-Liste für den Replicator neu. »doveadm replicator replicate« gibt dem Admin die Möglichkeit, die Replikation händisch anzustoßen. Ist der Parameter »-f« gesetzt, forciert dies zugleich eine vollständige Synchronisation.

Neben den Anpassungen zur Laufzeit lassen sich auch zwei Optionen für die Replikation in der User-Datenbank hinterlegen, das sind »mail_replica« und »noreplicate«. Während die allein stehende Option »noreplicate« die Replikation für einen Benutzer deaktiviert, setzt der Admin über die Option »mail_replica« den Replikations-Endpunkt für jeden Nutzer individuell und überschreibt die gesetzte Option unter »plugins«. Hier gibt er, wie in Listing 1, die Verbindungsart und die IP des Replikationspartners als Wert ein, zum Beispiel »mail_replica=tcp:10.0.0.2«.

Lösung des Problems

Aber zurück zum Ausgangsproblem. Der Admin installiert im Rechenzentrum einen zweiten Dovecot-Server und richtet die Replikation ein. Die Verbindung sichert er über VPN ab, um den Port nicht aus dem Internet zugänglich zu machen. Daneben geht er die Liste der Postfächer durch und ergänzt alle Postfächer, die niemand von außen abruft, mit der Option »noreplicate«.

Beim erstmaligen Synchronisieren öffnet Dsync jetzt viele Mailboxen und überträgt massiv Daten. Das belastet nicht nur den alten IMAP-Server, sondern auch das Netzwerk. Grund genug, den ersten Sync in die arbeitsfreie Zeit zu legen. Ist das keine Option, kann der Admin auch die Bandbreite begrenzen oder die Anzahl gleichzeitiger Replikationen (»replication_max_conns«) verringern.

Hat er die Bestandsdaten einmal synchronisiert, läuft das Replizieren sehr effizient. Meist genügt nun ein inkrementelles Synchronisieren, das nur geänderte Objekte oder Metadaten-Änderungen überträgt. Die Außendienstmitarbeiter greifen direkt auf den externen Server zu und bekommen nicht nur ihre Mails schneller, sondern sparen zugleich Bandbreite.

Fazit

Die Dovecot-Replikation bietet eine robuste, effiziente und performante Möglichkeit, um Mailboxen zu duplizieren und abzugleichen. Zusammen mit dem Dovecot Director lassen sich redundante, hochverfügbare Cluster bauen – sofern der doppelte Speicherplatz und die Limitierung auf zwei Backends nicht zu sehr schmerzt. Mit Dsync im Hintergrund lässt sich die Replikation theoretisch auch für viele andere Anwendungsfälle und Szenarien einsetzen.