[Postfixbuch-users] Alles neu macht der Mai: Postfix/Dovecot/MySQL/Postfixadmin/DRBD/Heartbeat

[listacc at gmx.de]

Hallo!

Ich bin immer noch am Planen und Experimentieren mit unserem neuen Mailsetup. Mittlerweile habe ich aber den Eindruck, daß das, was wir uns ausgedacht haben, ziemlich komplex ist. 

Und Komplexität ist der Feind der Zuverlässigkeit. Vielleicht habt ihr ja den einen oder anderen Hinweis aus der Praxis für mich, ob ich irgendwo auf dem falschen Dampfer bin? 

Ich bin mir nämlich grad ein wenig unsicher, da wir mit ähnlichen Setups noch keine Erfahrungen haben. Es geht zur Zeit weniger um die Details, sondern mehr darum, ob das Gesamtkonzept in dieser Art empfehlenswert ist:

Kleine, munter expandierende Firma mit ca. 500 Mailboxen.

Es soll zwei Postfix-Relays gleicher MX-Prio geben, mit Amavis/Spamassassin, Antivirus, Blacklists... also das Übliche halt. Amavis ist mit smtpd_proxy_filter eingebunden.

Diese Relays leiten die Mails dann weiter an einen IMAP-Cluster. Mit "verify / reject_unverified_recipients" schauen die Relays beim IMAP-Cluster nach, ob der Empfänger valide ist.

Alles zusammen hängt am gemeinsamen DMZ-Switch.

Der IMAP-Cluster besteht aus zwei Maschinen, die active/passive mit Heartbeat geclustert sind. Die Heartbeat-Verbindung ist redundant (über Crosskabel und Seriell).

Wir verwenden die Kombination Postfix/Dovecot/MySQL/Postfixadmin sowie DRBD. DRBD läuft über eine dedizierte Direktverbindung (nicht über den Switch, sondern Crosskabel; zwei gebondete Interface).

Heartbeat verwaltet folgende Ressourcen (starten/stoppen):

- Cluster-IP
- DRBD
- MySQL
- Dovecot
- Postfix
- Apache

Es gibt eine DRBD-Partition, auf die wir folgende Sachen ausgelagert haben:

- Dovecot: /var/run/dovecot, sowie das Maildir
- MySQL: /etc/my.cf, /var/lib/mysql


Die Überwachung der einzelnen Dienste soll mit MON erfolgen. Fällt ein Dienst aus, gibt der Node seine Ressourcen ab.
Überwacht werden sollen:

- DRBD
- Postfix
- MySQL
- IMAP

ipfail schaut nach der Netzanbindung, indem es prüft, ob ein Pingnode (unser Gateway) erreichbar ist.

DOPD setzt die nicht aktive DRBD-Partition auf "outdated", falls die DRBD-Verbindung zwischen beiden Nodes unterbrochen wird, und verhindert damit Datensalat.

Soweit scheint das alles auch tatsächlich zu funktionieren.

Ein Stonith ist sicherlich auch noch erforderlich, über die Art der Umsetzung sind wir uns aber noch nicht ganz klar. Eventuell werden es telnet-gesteuerte Steckdosenleisten, oder wir lassen es einfach drauf ankommen, da es unwahrschelinlich ist, dass Netzwerk- und serielle Heartbeatverbindung gleichzeitig ausfallen, und die Stonith-Devices ja selber zur Problemquelle weden können und teuer sind.


Die Passwörter unserer Clients sind im Klartext in der MySQL-Datenbank auf dem IMAP-Cluster hinterlegt. Dadurch kann sichere Authentifizierung mit "CRAM-MD5" erfolgen. Die Verbindung wird dann zusätzlich mit TLS gesichert. 

Für die IMAP-Verbindung haben wir SSL eingerichtet. Auch der Postfixadmin läuft über SSL.

Ausgehende Mails werden von den Clients auf dem IMAP-Cluster abgeliefert und von diesem an eines der beiden Relays weitergegeben. Dort erfolgt noch ein schneller Spam- und Virencheck, bevor es dann nach draußen geht. 

In unserem lokalen DNS sind beide Relays "relay1" und "relay2" mit jeweils einem A-Record eingetragen. Außerdem gibt es einen virtuellen Host "mailrelay". Also in etwa so:

---
relay1.		IN A 192.168.1.1
relay2.		IN A 192.168.1.2

mailrelay.	IN MX 10 relay1.
mailrelay.	IN MX 10 relay2.	
---

Auf dem IMAP-Cluster steht dann "relayhost=mailrelay", also ohne eckige Klammern, weshalb ausgehende Mails an beide Relays weitergegeben werden und es wegen Verwendung des MX-Records auch nicht schlimm ist, wenn mal ein Relay abgeschaltet wird.

Auf den Relays ist dann wie ab S.326 beschrieben relay_domains=btree:/liste/mit/unseren/domains 
eingetragen, incl. des transport-Eintrags, damit sie unsere Mails annehmen und an den IMAP-Cluster ("final destination") weiterleiten.


Unser Ziel ist, neben einer Minimierung von Downtime auch Mailverlust zu vermeiden, wenn z.B. der RAID-Controller spinnt. Zur Zeit bräuchten wir im "worst case" ca. 1 Arbeitstag für die Recovery.
 
Natürlich ist so ein DRBD recht anfällig, denn ein Fehler auf dem aktiven Node zerstört in der selben Sekunde die Daten auf dem passiven Node. Lösungen mit rsync fanden wir aber nicht so toll, weil der zeitliche Abstand zwischen zwei Syncs nicht zu klein gewählt werden darf, damit man noch Zeit zum Reagieren hat. Umgekehrt steigt mit längerem Abstand die Zahl von Mails, die verloren gehen können. Und so ein rsync ist ja auch recht I/O-fordernd, beim Aufbau der Liste und den vielen kleinen Dateien im Maildir, die andauernd in andere Ordner verschoben werden. Statt dessen machen wir wohl noch ein always_bcc auf einen weiteren Server, wo die Mails in einer mbox-Datei gespeichert werden (die beim nächsten Backup-Lauf des IMAP-Clusters gelöscht wird) und aus der man mittels eines noch zu erstellenden Scriptes die Mails erneut zustellen kann.

Was uns noch fehlt, ist Sieve, und wie wir die Unmengen "Shared Folders" migriert bekommen, die sich zur Zeit auf unserem Postfix/Cyrus/MySQL-System befinden. 

Und es gibt noch das Problem, wie wir für die Migration die Anmeldekennungen umwandeln können: bislang meldet man sich an mit "vorname.nachname.domain.tld", unser neues Setup kommt aber anscheinend nur mit "vorname.nachname at domain.tld" klar. Dovecot hat zwar wohl die Möglichkeiten, Zeichen umzuschreiben, bevor er in die Userdatenbank schaut, aber ich kann mir vorstellen, daß er nicht weiß, ob er den Anmelder als "name at subdomain.domain.tld" oder "name.name at domain.tld" interpretieren soll. In aller Gründlichkeit getestet haben wir das allerdings noch nicht.

Dies war erst mal nur das Grobe, davon aber ganz schön viel. Ich hoffe, ich hab jetzt nicht zu viel Quatsch geschrieben und freue mich auf eure Einschätzung :-)

Ein großes Dankeschön vorweg und viele Grüße,

  Andreas
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01