Abbildung 1: Die Menschen hinter Nemesis: Das Entwicklerteam und die Mail-Admins. Links im Bild Jerôme Waibel, Entwicklungsleiter Unix-Mailsysteme.

An Open-Source-Software zum Betrieb eines Mailservers besteht wahrlich kein Mangel. Trotzdem hat ein Entwicklerteam beim Karlsruher Hoster Schlund+Partner ein System von Grund auf neu implementiert. Doch die Motive für das Projekt Nemesis leuchten ein.

Ist er erst mal eingerichtet, sind täglich 10000 E-Mails für einen MTA-Server keine Herausforderung. Einen Spam- und Virenscanner anzuflanschen ist für Vollblutadmins auch kein Problem. Wenn aber wie bei Schlund+Partner [1] in Karlsruhe 20 Millionen Mails am Tag einlaufen, ist\’s mit Klein-klein-Konzepten vorbei. Diese Fragen beschäftigten vor zwei Jahren die Administratoren der United-Internet-Tochter, als ihnen die Hochrechnungen des für die nächsten Jahre zu erwartenden Maildurchsatzes ins Haus flatterten.

Bis dato betrieb das Rechenzentrum ein Mailboxen-Backend (Mailstore), das nur bis 16 Server skalierte. Dort störte die fehlende IMAP-Unterstützung, da die dafür nötigen Flags nicht abzubilden waren. Die Exim-MTAs am anderen Ende der Verarbeitungskette litten an einer antiquierten Benutzerverwaltung ohne eigene Datenbank.

Das System war so am Ende, dass das Anlegen von Accounts zum Schluss drei Stunden dauerte. Theoretisch wäre es möglich gewesen, alle Komponenten durch Basteln zu etwas mehr Leistung zu überreden. Aber statt an den Symptomen zu laborieren, suchten die Verantwortlichen gleich nach einer zukunftsfähigen Lösung.

Ihnen war jedoch bald klar, dass sie mit gängiger Software die sehr speziellen Anforderungen ihres Arbeitgebers nicht würden erfüllen können:

• Kernkomponente ist ein Mailstore-Cluster, der seine Ressourcen
  selbstständig verteilt, also gut ausnutzt
• Ausfallsicherheit durch Redundanz
• Lauffähig auf üblicher Hardware
• Datenschnittstelle zur hauseigenen Statistiksoftware
• Antiviren- und Antispam-API
• TKÜV-Schnittstelle (konzernweit rund 50
  Überwachungsanfragen pro Jahr).

Weil es so ein System nicht mal in Ansätzen gab, beschlossen die Karlsruher eine Neuentwicklung. Die, so die Überlegung, erleichtere zudem die Pflege exotischer Dinge wie der TKÜV-Schnittstelle.

Papier statt Software

Nach einigen Recherchen fanden sie die Antwort in einem Paper von Saito, Bershad und Levy, das einen redundanten Mailstore-Cluster beschreibt, der Ressourcen selbstständig verteilt [2]. Der Aufsatz beschreibt einen Cluster aus Standardmaschinen, der sich beim Hinzufügen von Knoten dynamisch anpasst. Er repliziert die Daten automatisch auf mindestens zwei Maschinen, um sie beim Ausfall eines Knotens weiterhin verfügbar zu halten. Nach Reparatur des Knotens zieht ein Recovery-Mechanismus den zweiten Satz Daten neu hoch.

Entwicklung

Mit diesem Konzept ging ein Team von zehn Entwicklern an den Start. Die Programmiersprache der Wahl war C++, die Sourcen verwaltete zunächst ein CVS, später Subversion. Initial lief die Entwicklung gewohnt unstrukturiert. Doch schnell zeigte sich, dass ein Projekt von zehn Mannjahren nur mit Projektmanagement funktioniert.

Tatsächlich gelang es den Entwicklern, einen Mailstore-Cluster zu implementieren, der die Mailboxen der Kunden dynamisch über alle Nodes ohne manuelles Eingreifen verteilt. Jeder Server besitzt sein eigenes Raid-System zum Speichern der Mailboxen. Läuft ein Rechner voll, verschiebt er Mailboxen selbsttätig auf einen weniger stark ausgelasteten; neue Knoten bezieht das System automatisch mit ein (siehe Abbildung 2).

Ext 2 für dicke Dateien

Ein Mailfolder bildet sich als eine große, fortlaufende Datei ab, die dem Mbox-Format nicht unähnlich ist. Gelöschte Mails bekommen erst mal nur eine Löschmarkierung verpasst, ihr Platz in der Datei bleibt belegt. Erst beim allnächtlichen Bereinigungslauf reorganisiert sich die Mailbox und gibt den Platz der gelöschten Mails frei.

Nemesis legt Mailbox-Dateien auf Ext-2-Systemen ab, die sich in Performancetests als vorteilhaft erwiesen. Moderneren Filesystemen haftet ein Overhead an, der laut Projektchef Jerôme Waibel bei XFS noch am geringsten ausfällt. Besonders ungünstig wäre ReiserFS gewesen, da es auf die Nutzung vieler kleiner Dateien optimiert ist. Das fehlende Journaling bei Ext 2 spielt bei Nemesis keine Rolle, da das Gesamtsystem auf Redundanz ausgelegt ist, sodass ein langwieriger Fsck auf einem Node den Produktionsbetrieb nicht behindert.

Um den Mailstore herum ranken sich die SMTP-, POP- und IMAP-Serververbünde, auf denen auch selbst entwickelte Software läuft. Das Ganze organisiert sich über ein Set von Daemons selbst: Fallen Rechner aus, kommen neue hinzu, ändern sich Kundenprofile oder sind Connections von außen nach innen zu verteilen – nie muss ein Admin per Configdatei eingreifen.

In der ganzen Zeit stolperten die Entwickler über Bugs und Limits sowohl im Linux-Kernel als auch in der Libc und im GCC. Das ist im Enterprise-Bereich nicht ungewöhnlich, da es nicht so viele Anwender gibt wie bei Standardsoftware – Bugs schlafen bis zu ihrer Entdeckung einfach länger. Teils behob das Team die Fehler selbst, teils ging eine Meldung an die Community.

Abbildung 2: Der Weg einer E-Mail durch die vielen Server von Schlund+Partner. Im Zentrum steht Nemesis, der redundant ausgelegte Mail-Storage-Cluster.

Tests am lebenden Objekt

Für die ersten Lasttests duplizierten die Admins den Maileingang des normalen Produktivbetriebs und schickten ihn gleichermaßen an das Altsystem wie an Nemesis. Im zweiten Schritt übernahm das Neusystem ausgewählte Mailboxen, später alle Kundenaccounts.

Der für Tests eingesetzte 2.6-Kernel erwies sich als deutlich performanter als der 2.4er zuvor. Das Scheduling lief runder und beim Abarbeiten von Prozessen mit – wie bei Nemesis – vielen Threads zeigten sich klare Verbesserungen. Die Migration war auf zwei Jahre projektiert und wurde am 1. Januar 2005 zur Zufriedenheit der Beteiligten beendet. Derzeit besteht der Mailstore-Cluster aus 75 Intel-Rechnern (Abbildung 3).

Viren- und Spamschutz

Der Virenscan der Mail läuft in einer extra CPU-starken Serverfarm mit Symantec-Software. Nemesis und die AV-Cluster tauschen die Mails über Queue-Rechner aus. Die Antispamfilter hat die Schlund-Schwester GMX entwickelt. Der MTA nimmt aber erst mal jede einlaufende Mail an – allein schon wegen der etwas unklaren Rechtslage. Das Sortieren und Verwerfen per Filter erfolgt nach Kundenwunsch.

Abbildung 3: Einige der 75 Mailstores, auf die täglich Millionen E-Mails einprasseln.

Die Schlund-Kunden bekommen von Nemesis kaum etwas zu sehen. Sie administrieren ihre Mailaccounts in einem Webfrontend, das an einer zwischenspeichernden Sybase-Datenbank hängt. Die repliziert ihre Inhalte wiederum in ein MySQL-Cluster, aus dem sich alle Nemesis-Komponenten direkt bedienen.

Die Zukunft von Nemesis

Softwaresysteme dieser Größenordnung sind nie ganz final. Zu den geplanten Detailverbesserungen zählt eine Filterfunktion auf dem Server, deren Regelsatz der Benutzer Web-basiert vorgeben soll. Schlund+Partner plant zudem ein zweites Rechenzentrum. Ab dann wird Nemesis auch Constraints der Art “Die Mail eines Kunden muss auf zwei Servern sein, die in verschiedenen Rechenzentren stehen” realisieren. (jk/fjl)