10.5    Dovecot im Replikations-Cluster

Nachdem Sie nun einen einzelnen Rechner mit Postfix und Dovecot zum voll funktionsfähigen SMTP- und IMAP-Server aufgebaut haben, lohnt noch der Seitenblick in Richtung »Hochverfügbarkeit« und indirekt auch in Richtung »Backup«. Dovecot besitzt die geniale Fähigkeit, zwei ansonsten identisch aufgebaute Dovecot-Server zu einem bidirektionalen Replikations-Cluster zusammenzuschalten.

Dabei heißt Replikations-Cluster: Jede Änderung auf der einen Seite wird über ein internes Dovecot-Protokoll zur anderen Seite repliziert (natürlich gesichert über einen symmetrischen Schlüssel).

Dabei speichert jede Seite ihren Mailbestand autark individuell auf einer eigenen Festplatte. Anders als bei Replikationsdateisystemen wie DRBD werden dabei Schäden am Dateisystem nicht ebenfalls stoisch zum Clusterpartner übertragen, da Änderungen nur als Mail-Event von Dovecot an den Clusterpartner übertragen werden. Wird durch den Administrator auf einer Seite versehentlich ein ganzer Dateibaum mit Mails gelöscht, gleichen sich beide Systeme beim nächsten Replikationslauf wieder ab und restaurieren den »illegal« verschwundenen Mailbestand wieder.

Und bidirektional heißt: Dabei können auf jeder Seite Änderungen stattfinden, sodass es gar nicht notwendig ist, einen Knoten als Master und den anderen als Slave zu definieren.

Stattdessen können Sie den Dovecot-Cluster ganz bequem Master-Master betreiben. Damit entfallen auch typische HA-Probleme wie Split Brain oder STONITH, bei denen durch verschiedene Techniken dafür gesorgt werden muss, dass zur gleichen Zeit jeweils nur ein Knoten aktiv ist.

Bei Dovecot können Nutzer zeitgleich auf jedem Knoten aktiv sein und damit auch über ein einfaches Loadbalancing-Round-Robin verteilt werden. »Können« heißt aber eben nicht »müssen«, sodass wir Ihnen empfehlen möchten, zwar ein Master-Master-Setup aufzubauen, durch eine einfache Loadbalancer- oder HA-Konfiguration aber dafür zu sorgen, dass die User trotzdem nur jeweils einem Knoten zugeteilt werden. Sie behalten so besser den Überblick, haben alle Logfiles zentral und können ihr Mailsystem leichter administrieren. Doch dieses Balancing geschieht nun außerhalb von Dovecot, der sich trotzdem weiterhin in einer Master-Master-Replikation sieht und sehen soll. [ 17 ]

10.5.1    Einrichtung der Replikation

Um eine Replikation zwischen zwei Dovecot-Knoten zu initiieren, müssen beide einen TCP-Port für das Dovecot-eigene doveadm-Protokoll öffnen und einen auf beiden Seiten identisch eingestellten symmetrischen Schlüssel verwenden.

Des Weiteren müssen einige Plugins und Services aktiviert werden, die die stattfindenden Mail-Events überwachen und an die jeweils andere Seite melden.

Nachdem Sie entsprechend diesem Kapitel einen zweiten, identischen Mailserver aufgebaut haben (oder bei einer virtuellen Maschine die vorhandene Installation geklont haben), können Sie auf beiden Servern die Konfigurationsdatei /etc/dovecot/conf.d/17-replication.conf einspielen:

mail_plugins = $mail_plugins notify replication

service aggregator {
        fifo_listener replication-notify-fifo {
                user = vmail
        }

        unix_listener replication-notify {
                user = vmail
        }
}

service replicator {
        process_min_avail = 1
        unix_listener replicator-doveadm {
                mode = 0600
                user = vmail
        }
}

service doveadm {
        inet_listener {
        port = 12345
        }
}

doveadm_port = 12345
doveadm_password = secretpassword
replication_dsync_parameters = "-d -n INBOX -l 30 -U"


plugin {
# mail01 repliziert zu mail02 alias .1
# Auf mail01 also aktivieren, auf mail02 deaktivieren:
        mail_replica = tcp:192.168.10.1

# mail02 repliziert zu mail01 alias .2
# Auf mail02 also aktivieren, auf mail01 deaktivieren:
#       mail_replica = tcp:192.168.10.2
}

Listing 10.69    Konfiguration der Replikation auf beiden Mailservern

Passen Sie dabei die in der Beispielkonfiguration genannten IP-Adressen entsprechend an.

Wenn Sie Dovecot neu gestartet haben und damit auch das oben genannte notify-Plugin aktiviert haben, wird nun auch Ihr doveadm-Tool die replication-Kommandos unterstützen:

root@dobby5:~# doveadm replicator
usage: doveadm [-Dv] [-f <formatter>] replicator <command> [<args>]
  add          [-a <replicator socket path>] <user mask>
  dsync-status [-a <replicator socket path>]
  remove       [-a <replicator socket path>] <username>
  replicate    [-a <replicator socket path>] [-f] [-p <priority>] <user mask>
  status       [-a <replicator socket path>] [<user mask>]

Listing 10.70    »doveadm«-Befehlsübersicht für die Replikation

Ein doveadm replicator replicate '*' startet einen Replikationsabgleich über alle User. Kurz nach dem Kommando sollten Sie auf dem zweiten Server hektische Betriebsamkeit im Logfile sehen und auch im Dateisystem beobachten können, wie »von Zauberhand« der Mailspeicherbereich des ersten Servers auf den zweiten Server übertragen wird. Wenn Sie sich nun per POP3 oder IMAP auf dem zweiten Server einloggen, finden Sie dort das komplette Postfach vor, und gleichzeitig wird jede dort vorgenommene Änderung ebenfalls auf den ersten Server Rückübertragen – eben bidirektionale Replikation.

Dass Sie über doveadm replicator remove einzelne User von der Replikation ausnehmen möchten, wird eher selten der Fall sein. Ganz analog brauchen Sie dann auch diese gesperrten User nie über add hinzuzufügen – per Default repliziert Dovecot von Beginn an jeden Nutzer.

Praxisrelevanter ist hier eher das Kommando doveadm replicator dsync-status, mit dem Sie sich einen Überblick verschaffen können, womit sich die Replikation derzeit »live« beschäftigt. Per Default werden maximal zehn Replikationsaktivitäten parallel ausgeführt. Da aber nach der allerersten Replikation nur noch Änderungen übertragen werden, ist es nicht ungewöhnlich, dass kaum oder keine konkrete Aktivität zu sehen ist:

root@host:~# doveadm replicator dsync-status
username                                   type        status
user8@example.org                           incremental Waiting for dsync to finish
                                            -           Not connected
                                            -           Not connected
user1@example.org                           incremental Waiting for dsync to finish
user3@example.org                           incremental Waiting for dsync to finish
                                            -           Not connected
user6@example.org                           incremental Waiting for dsync to finish
                                            -           Not connected
                                            -           Not connected
                                            -           Not connected

Listing 10.71    Live-Statusübersicht der Replikation

Über das Kommando doveadm replicator status hingegen können Sie sich anzeigen lassen, wie der generelle Systemzustand ist und wie viele Einträge derzeit gegebenenfalls noch in der Replikationswarteschlange auf Abarbeitung warten (siehe Listing 10.72).

Dabei dürfen Sie sich auch im laufenden Betrieb nicht wundern, wenn immer wieder User auf einen full resync-Request warten, da Dovecot per Default jeden User alle 24 Stunden einem full resync unterzieht, um gegebenenfalls verlorene einzelne Events aus dem inkrementellen Abgleich abzufangen.

root@host:~# doveadm replicator status
Queued 'sync' requests        0
Queued 'high' requests        0
Queued 'low' requests         3
Queued 'failed' requests      0
Queued 'full resync' requests 7016
Waiting 'failed' requests     0
Total number of known users   45341

Listing 10.72    Statusübersicht der Replikation

Hinweise auf die Aktivitäten der Replikation und gegebenenfalls auch Hintergründe zu etwaigen Fehlern finden Sie wie gewohnt im Mailserver-Logfile.

Nun haben Sie zwei sich gegenseitig absichernde IMAP-Cluster, die durch ihre jeweils autarke Datenspeicherung auch für ein gewisses Grund-Backup sorgen.

Dieses schützt Sie zwar nicht davor, dass ein User versehentlich alle seine Mails löscht, wohl aber vor einem Hardwareschaden oder gegebenenfalls auch einfach vor »menschlichem Versagen« an der Tastatur, wenn Sie Dateien auf dem Server löschen.

10.5.2    Hochverfügbare Service-IP

Damit der Cluster gemeinsam und ausfallsicher für den Nutzer seine Dienste anbinden kann, benötigen Sie nun noch eine gemeinsame Service-IP (Cluster-IP), die wahlweise auf dem einen oder dem anderen Server liegt.

Das zu realisieren ist auf vielen verschiedenen Wegen möglich, beispielsweise über Heartbeat/Pacemaker, wie es in Kapitel 19 beschrieben wird. Sie benötigen dabei nur eine absolute Minimalkonfiguration (wie in Abschnitt 19.6.1 gezeigt), die die besagte Service-IP mal auf dem einen Server, mal auf dem anderen Server hochfährt. Dovecot und alle anderen Dienste laufen auf den Servern weiterhin nonstop durch und müssen darum auch nicht über Heartbeat/Pacemaker gemanagt werden.

Wenn Sie jedoch nicht bereits mit Heartbeat/Pacemaker aus anderen Projekten vertraut sind, ist die für Sie sicher schlankere und übersichtlichere Lösung der Einsatz von VRRP (alias keepalived). Dazu wird auf beiden Servern ein keepalived-Dämon installiert, sodass sich beide über IP-Broadcasts gegenseitig überwachen und koordinieren. Auf dem jeweils zum Master gekürten System wird die eingestellte Service-IP aktiv geschaltet.

Installieren Sie dafür keepalived, und passen Sie /etc/keepalived/keepalived.conf an.

Dabei benötigen Sie auch hier nur eine absolute Minimalkonfiguration, denn auch hier ist es nur notwendig, die Service-IP, nicht aber den eigentlichen Dovecot-Dienst zu verwalten. Die eigentliche keepalived.conf ist dabei auf beiden Servern identisch:

global_defs {
   notification_email {
     admin@example.com
   }
   notification_email_from admin@example.com
   smtp_server 192.168.10.54
   smtp_connect_timeout 30
   router_id IMAP-Cluster
}

vrrp_instance IMAP {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass geheimespasswort
    }
    virtual_ipaddress {
        192.168.10.10
    }
}

Listing 10.73    Konfiguration in »/etc/keepalived/keepalived.conf«

[+]  Haben Sie mehrere VRRP-Server im gleichen Netzwerk aktiv, muss jedes Serverpärchen eine eigene virtual_router_id zugewiesen bekommen!

Ist Ihr Dovecot-Replikations-Cluster aktiv und sehen auch Ihre Tests mit keepalived/VRRP Erfolg versprechend aus, können Sie nun im DNS den IMAP-Hostnamen auf die hochverfügbar gehaltene Service-IP zeigen lassen und schon sind Sie hochverfügbar aufgestellt.