Auf den diversen Mailserver-spezifischen Listen, die ich lese, tauchen regelmäßig Leute auf, die gerne ein “HA-Mailsystem” bauen würden. Und alle sehen sie die Probleme an der falschen Stelle.

  1. Der Empfang von Mails ist nicht schwer: Das SMTP-Protokoll kann von Haus aus mit ausgefallenen Mailservern umgehen - und jede moderne Software die mir bekannt ist, wertet mindestens zwei MX-Records aus. Das heisst das man den Empfang von Mails extrem einfach hochverfügbar gestalten kann: Wenn zwei MX-Server nicht mehr reichen, hängt man hinter diese beiden Einträge einen Loadbalancer (Cisco ACE, ldirectord etc.). “Hinter” die beiden, weil dann der einliefernde Mailserver eher geneigt ist, die Delivery erneut zu probieren, wenn er bei der ersten Verbindung, die auf dem Loadbalancer terminiert, einen Fehler kriegt.
  2. Das Filtern von Mails ist nicht schwer: Gehen wir mal von dem mir gut bekannten OSS-Setup aus Postfix und amavisd aus: In einem Post-Queue-Filter-Modus kann man als content_filter-Eintrag einfach eine interne Domain angeben, deren MX-Einträge auf die amavis-Server zeigen - fällt ein Filter aus, wird transparent der nächste genommen. In einem Pre-Queue-Setup muß man halt wieder zu Loadbalancern greifen - aber auch hier hält sich das Risiko in Grenzen, ist der Filter kaputt, den man gerade erwischt hat, hat man ja eine Ebene weiter vorne immer noch zwei MX-Einträge. Und für die Datenbanken, die so ein Setup benötigt, gibt es genügend Replikationslösung im OSS-Markt, egal, ob man MySQL, PostgreSQL oder OpenLDAP benutzt (ja ja, ich weiß, eine Bayes-Datenbank kann man nicht in LDAP ablegen). Und mit minimalem Konfigurationsaufwand (und vielleicht dem Ersetzen des Standard-SA-Bayes-Filters durch CRM114 oder ähnliche Alternativen) bekommt man ein Setup, das nicht nur robust ist, sondern auch gute Ergebnisse erzielt.
  3. Der Versand von Mails ist nicht schwer: Webmail und so sollten klar sein (Webmail verbindert sich auf 127.0.0.1 oder eine LB-Adresse, kann vielleicht sogar mit mehr als einem Mailserver umgehen, von da via MX-Routing auf die Outgoing-Server), und den Submission-Kram fackelt man wiederum über Loadbalancer ab. Zu den Authentifizierungs-Datenbanken siehe die Anmerkungen unter Punkt zwei. Mit der einfachste Job.
  4. Der IMAP-Zugriff ist schwer (ich lasse POP3 mal außen vor, interessiert mich nicht, ist aber auch nicht anders): Es ist leicht, mit OSS-Software ein Failover-System aufzubauen (DRBD, Pacemaker, beliebiger IMAP-Server), keine Frage. Aber damit ist es ja nicht getan: Wie skaliert man sowas: IMAP-Server bieten tolle Features an, z.B. das serverseitige Suchen nach Mails. Das ist alles knorke, aber das ganze benötigt CPU und vor allem RAM. Große IMAP-Server, stellen wir uns mal 300000 Mailboxen vor (BTDT), halten auch viele 10000e Verbindungen gleichzeitig. Und irgendwann hat kommt man halt an die Grenze, wenn man keine zusätzliche Hardware mehr hinstellen kann. Und das ist dann der Moment, wo es schwer wird - denn dann muß man ein System bauen, das skaliert und robust ist. Und da gibt es viele Fallstricke: Geht man naiv an die Sache heran und nimmt als Storage-Backends NFS-Server, dann wird man recht schnell über NFS-Caching stolpern. Workarounds wie der Dovecot-Director existieren zwar, und nach kurzer Freude wird man über NFS-Locking stolpern. Bleiben also Cluster-Filesystem-basierte Lösungen, also beispielsweise ein SAN und darüber dann IBM GPFS, GFS2, OCFS2 etc. Wieder muß man das Sharding in den Griff kriegen (Cache-Effizienz, anyone?). Und wenn das alles endlich läuft: Wie speichert man die Daten auf dem Backend? Maildir? REALLY? Jemand schonmal 4TB Maildirs mit vielen Milliarden kleiner Files aus einem Backup zurückgespielt? Viel Spaß. Dovecot bietet hier (m)dbox - und auf den Mailinglisten kann man sich schön die Assertions und Stacktraces dazu ansehen. Aber Alternativen im OSS-Umfeld? Tja. Das ist der Grund, warum nicht jeder Mail machen sollte ;-)

Also: Wenn ihr da draußen ein HA-Mailsystem aufbauen wollt, das skaliert: Vergesst die Punkte eins bis drei. Macht Euch einfach nur Gedanken darüber, wie Eure Nutzer an ihre Mails kommen, was ihr tut, wenn ihr plöztlich doppelt so viele Nutzer habt und wie ihr den Disaster-Fall abdecken könnt. Das ist es, worauf es ankommt. Punkte eins bis drei fackelt Euch jeder halbwegs kompetente Mailadmin in zwei Tagen ab (immer unter der Voraussetzung, daß er mit Datenbanken klarkommt oder da unterstützt wird).