© Nongnuch Leelaphasuk, 123RF

Indem Admins Dovecot mit einem Objektspeicher nach S3-Standard an den Start bringen, umgehen sie die typischen Skalierbarkeitsprobleme bei Mailservern. Mit einem – allerdings kommerziellen – Dovecot-Plugin von den Entwicklern des Mailservers selbst gelingt das ohne große Probleme.

Admins von Mailservern sind ein leidgeprüftes Volk. Einerseits produzieren wenige andere Dienste so viele Missbrauchsbeschwerden, wie es der Mail-Betrieb üblicherweise tut – falsche Blacklistings sind ein Beispiel. Andererseits merkt man der E-Mail mittlerweile auch an, dass sie ein Produkt aus einer anderen Zeit ist, das mit der schnelllebigen IT der Gegenwart seine Schwierigkeiten hat. Die Anforderungen, die Nutzer an den Empfang und den Versand von E-Mails stellen, sind in den letzten Jahren stetig gewachsen.

War es zum Beispiel vor einigen Jahren durchaus noch üblich, Anhänge für E-Mails nur bis zu einer bestimmten, sehr niedrigen Größe zuzulassen, ist genau das heute verpönt: Nutzer erwarten, dass sie ihre 20-MByte-Präsentation für Powerpoint per E-Mail verschicken können und diese beim Gegenüber auch ankommt. Obendrein wächst die Zahl der E-Mail-Nutzer noch immer kontinuierlich und die Menge an Daten, die alle Nutzer eines Anbieters zusammen speichern, wächst proportional zur Nutzeranzahl.

Das ist zwar nicht E-Mail-spezifisch, denn auch andere Internetdienste erleben den Effekt des stetigen Wachstums der zu bewältigenden Datenmengen. Bei E-Mail-Setups ist es aber vergleichsweise komplex, dieses Problem zu umgehen. Das liegt vorrangig an der Architektur, die dem Prinzip “E-Mail” innewohnt.

Architektonisches

Normale Setups folgen meist dem immer gleichen Schema: Auf der einen Seite sorgen SMTP-Daemons dafür, dass Kunden Mails versenden können und eingehende Nachrichten bei den Empfängern landen. Den größeren Teil der Arbeit erledigen auf der anderen Seite allerdings die Dienste, die den Kunden ihre E-Mails ausliefern. Zwar gibt es noch immer Provider, die nur auf POP3 setzen oder IMAP nur gegen Bezahlung anbieten. Im Großen und Ganzen hat sich das IMAP-Protokoll allerdings durchgesetzt.

Für die Betreiber von E-Mail-Diensten bedeutet das zusätzliche Sorgen: Der Kunde erwartet nämlich völlig zu Recht, seine E-Mails jederzeit vorzufinden – auf den Servern des Anbieters. Meist laden diese Kunden erst gar keine lokalen Kopien der Mails mehr herunter und verlassen sich auf ihren Anbieter. Der muss dann zusehen, wie er mit der Last und dem Speicherplatzbedarf eines solchen Setups umgeht. Selbst wenn jeder Anwender nur eine kleine Mailbox hat, ist der Bedarf an Speicherplatz bereits beachtlich, wenn viele Nutzer da sind.

Früher oder später werden Admins also in die Situation geraten, ihre Infrastruktur an gestiegene Nutzerzahlen anzupassen, also auszuskalieren. Load-Probleme bei den Diensten lassen sich erfahrungsgemäß über multiple MX-Einträge (auf der SMTP-Seite) und IMAP- oder POP3-Daemons per Load Balancer verhältnismäßig einfach in den Griff kriegen. Das Storage-Problem ist kniffliger.

Das Storage-Problem

Wenn E-Mail-Admins ihre Server mit Speicherplatz ausstatten wollten, taten sie das bis jetzt hauptsächlich über zentrale Storage-Systeme. SAN-Modelle der großen Hersteller stellten die klassischen Kandidaten. Doch sind die Dinger teuer und skalieren höchstens in die Höhe. Zur Erinnerung: Skalierbarkeit in die Höhe meint, vorhandene Hardware mit mehr Power auszustatten. Dem gegenüber steht das Skalieren in die Breite, bei dem vorhandenen Maschinen einfach noch mehr Maschinen zur Seite gestellt werden. Die Last verteilt sich dann auf die Geräte, die zur Installation gehören.

Sharding

Klassische Speichersysteme sind möglicherweise durch den Einbau von neuen Festplatten zu erweitern, doch irgendwann ist das Ende der Fahnenstange erreicht und zusätzlicher Speicherplatzbedarf lässt sich nur durch die Anschaffung mehrerer Speichersysteme in den Griff kriegen. Genau das war über viele Jahre der übliche Ansatz: Nutzer bekamen verschiedene Storage-Systeme zugeordnet (Sharding).

Das bringt eine Latte von Nachteilen: Erstens sind SAN-Storages empfindlich teurer als normale Hardware von der Stange, zweitens machen viele Storage-Inseln zentralisierte Administration eher schwer. Admins bissen aus Mangel an Alternativen trotzdem in den sauren Apfel, denn im Hinblick auf das Skalieren in die Breite schien der Storage-Markt sehr lange im Dornröschenschlaf.

Objektspeicher zur Hilfe

Das änderte sich schlagartig mit dem Aufkommen von Object Stores. Den Namen haben Lösungen dieser Art erhalten, weil sie intern alle Daten auf die gleiche Weise behandeln – wie binäre Objekte nämlich. Der Clou dabei ist, dass sich binäre Objekte nach Belieben aufteilen und wieder zusammensetzen lassen, solange das in der gleichen Reihenfolge passiert.

Durch diesen Kniff bieten Objektspeicher echtes Skalieren in die Breite. Denn der Objektspeicher selbst muss “nur” noch dafür sorgen, dass das Aufteilen in die binären Objekte ordnungsgemäß stattfindet und dass sich die Objekte auf die vorhandenen Festplatten ordentlich verteilen. Kommen mehr Festplatten zur Installation dazu, nutzt der Objektspeicher diese automatisch und erweitert so die Grenzen der Skalierbarkeit in theoretische Bereiche.

Die vorhandenen Cloud-Computing-Lösungen haben eine ganze Welle verschiedener Objektspeicher ins Rampenlicht gespült. Red Hat hat Ceph ([1], Linux-Magazin-Artikel unter [2] und [3]) gekauft ([4], [5]) und mit seinem Storage Server [6] eine eigene Lösung für das Speichern von Objekten im Angebot. Open Stack kommt mit Swift daher, das ebenfalls ein Objektspeicher im klassischen Sinne ist. Und dann sind da noch die Dienste, die selbst einen Objektspeicher als Dienst für Nutzer zur Verfügung stellen, etwa Amazon S3 oder Dropbox.

Mit allen Diensten ist es jedenfalls möglich, skalierbare Storage-Systeme aufzubauen. Phänomenal wäre es für die Admins von E-Mail-Plattformen, wenn sich eine solche Speicherlösung mit der beschriebenen E-Mail-Architektur in Einklang bringen ließe. Schließlich spricht nichts dagegen, eine E-Mail genauso zu behandeln wie ein binäres Objekt. Das dachte sich wohl auch Timo Sirainen, der Autor von Dovecot, und zog die Konsequenz: Das S3-Plugin für Dovecot verbindet den IMAP-Daemon mit einem S3-kompatiblen Speicher und nutzt die Object-Storage-Vorteile damit ideal aus.

Dovecot mit S3

Sirainen bietet das Dovecot-S3-Plugin bereits seit einer Weile an. Wichtig im Vergleich zur normalen Dovecot-Version ist, dass das Plugin lediglich mit der Enterprise-Version von Dovecot läuft und Admins eine Lizenz benötigen, um es zu verwenden (Abbildung 1). Die Lizenz lässt Sirainen sich mit rund 5000 Euro pro Jahr für 10  000 Mailboxen vergüten. Das ist zugegebenermaßen kein Pappenstiel; an und für sich ist die Zahl aber auch wenig aussagekräftig.

Abbildung 1: Nur gegen Bares gibt es bei Dovecot die Lizenz für das S3-Plugin. Die Kosten lassen sich aber meist durch günstige Hardware abfedern.

Zwar kostet Dovecot in einem solchen Setup mehr als die freie Version; der Einsatz mit einem Objektspeicher im Rücken wird für das betreibende Unternehmen aber in vielen Fällen erhebliche Vergünstigungen beim Thema Hardware mit sich bringen, weil SAN-Storages nicht mehr nötig sind und Hardware von der Stange genügt. Überlegungen dieser Art sollten Firmen jedenfalls anstellen, wenn sie über den Dovecot-Einsatz mit S3-Plugin nachdenken.

Wie funktioniert das S3-Plugin für Dovecot im Detail? Timo Sirainen erklärt das in der Dokumentation zum Plugin selbst und ausführlich. Grundsätzlich gilt: Wer das S3-Backend von Dovecot nutzen möchte, benötigt Zugriff auf einen Objektspeicher nach Amazon-S3-Standard. An solchen Accounts hängen zumeist die Zugangsdaten in Form zweier Werte: Erstens fungiert der Access Key als eine Art Nutzername, zweitens ist der Secret Key das Passwort. Wer sich bei Amazon einen Account anlegt, erhält beide Informationen automatisch.

Für die Ablage von Mails per Dovecot in S3 ist es zudem nötig, ein eigenes Bucket in S3 anzulegen. Dass nicht jeder Nutzer ein eigenes Bucket erhält, mag im ersten Augenblick Bauchschmerzen im Hinblick auf die Sicherheit verursachen – doch das ist eine Täuschung. Bei einem normalen Mailserver hat eben auch nicht jeder Nutzer sein eigenes Dateisystem, die Verantwortung für die Durchsetzung der Zugriffsrechte liegt in beiden Fällen bei Dovecot als Mailserver.

Dovecot-Konfiguration

Dann folgt die Konfiguration von Dovecot selbst: Wer das Programm bereits für IMAP oder IMAPS nutzt, kennt die Absatz-ähnliche Struktur der Config-Files. Für das Amazon-S3-Plugin genügt es, einen zusätzlichen Absatz einzutragen, der die Plugin-Konfiguration übernimmt. Das Beispiel in Listing 1 ist direkt der Dovecot-Dokumentation entnommen (siehe Abbildung 2).

01 plugin {
02 # Use 100 GB cache for mails in /var/lib/dovecot/cache. The cache directory is the same for all users.
03 obox_fs = fscache 100G:/var/lib/dovecot/cache:s3:https://Accesskey:Secret@Bucket-Name.s3.amazonaws.com/
04 }

Abbildung 2: Dovecot bietet auf der eigenen Website ein PDF-File an, das sowohl die Einrichtung des Enterprise-Repo als auch die des S3-Plugins beschreibt.

Dovecot schaltet S3 in diesem Fall noch einen lokalen Cache mit insgesamt 100 GByte Platz vor, um den lokalen Zugriff auf häufig benötigte Objekte so schnell wie möglich abzuwickeln. Klar ist damit, dass es nicht sehr schwierig ist, Dovecot an ein S3 anzudocken, falls die benötigte Dovecot-Lizenz für das Plugin vorliegt.

Wer seine Daten lieber in Microsofts Azure-Cloud ablegen will, kann das ebenso tun, auch für Azure steht ein Plugin zur Verfügung. Obendrein gibt es Dropbox-Support, auch Dropbox kann also als Backend-Speicher für Dovecot zum Einsatz kommen.

Gerade dieser Umstand führt allerdings zu einer Diskussion, die viel mehr eine rechtliche als eine technische ist: Wollen Unternehmen ihre E-Mails per Dovecot wirklich bei Amazon, Microsoft oder Dropbox lagern? Gerade vor dem Hintergrund der Snowden-Enthüllungen ist Skepsis verständlich.

Ceph-Grundlagen

Das bedeutet aber nicht, dass Admins auf den Komfort der S3-Speicher in Dovecot ganz verzichten müssten. Denn das S3-Protokoll ist öffentlich dokumentiert, auf FLOSS-Basis existieren gleich mehrere Projekte, die einen S3-Speicher selbst anbieten. Darunter der Shootingstar des Storage-Umfelds: Ceph.

In den vergangenen Monaten hat Ceph gerade auch durch den Verkauf an Red Hat viel Publicity erhalten; den meisten Admins ist Ceph daher ein vertrauter Begriff. Zusammengefasst lässt sich Ceph als Objektspeicher mit diversen Frontends betiteln. Die Eigenschaft, mehrere Frontends zu bieten, ist dabei durchaus ein Unterschied zu anderen Objektspeichern wie Open Stack Swift. Ceph ist seitens der Herstellerfirma Inktank als universeller Storage für beinahe alles ausgelegt, was in einem modernen Rechenzentrum anfällt.

Ein Ceph-Cluster besteht idealerweise aus mindestens drei Maschinen. Auf denen laufen dann verschiedene Ceph-Komponenten, mindestens ein Monitoring-Server pro Host (im Fachjargon MON) sowie ein Speicherdaemon (OSD, Object Storage Daemon) für jede vorhandene Festplatte.

Die Monitoring-Server sind die Wachposten innerhalb der Speicherarchitektur: Sie überwachen mittels Paxos-Algorithmus das Quorum, um Split Brains zu vermeiden. Grundsätzlich gilt hier, dass eine Clusterpartition nur dann als “quorat” (also “mit Quorum”) gilt, wenn sie mindestens 50 Prozent aller MONs plus einen ganzen MON enthält. Bei einem Drei-Knoten-Cluster ist folglich eine Clusterpartition dann quorat, wenn sie zwei MONs sieht – die Partition, die nur einen MON sieht, würde Ceph automatisch deaktivieren.

MONs

Obendrein spielen die MONs für den Ceph-Cluster das Telefonbuch: Clients reden eigentlich direkt mit den Festplatten im Cluster, also den OSDs. Wollen die Clients jedoch mit den OSDs reden, müssen sie wissen, wie sie jene erreichen. Die MONs führen dynamische Listen über die vorhandenen OSDs sowie die vorhandenen MONs (OSD-Map und MON-Map) und liefern beide Karten aus, wenn Clients die Information erbitten. Auf der Grundlage des Crush-Algorithmus ist es den Clients anschließend möglich, die korrekte Position binärer Objekte selbst auszurechnen. Ceph kennt insofern kein zentrales Verzeichnis, in dem für jedes einzelne binäre Objekt die Zielfestplatten vermerkt sind.

Als großer Vorteil von Ceph erweist sich außerdem die inhärente Parallelisierung, die nahezu allen Ceph-Diensten innewohnt. Ein einzelner Client, der eine 16 MByte große Datei in Ceph ablegen möchte, teilt diese üblicherweise in vier Blöcke zu 4 MByte auf. Dann lädt er alle vier Dateien gleichzeitig auf vier OSDs im Cluster hoch, sodass er die kombinierte Schreibgeschwindigkeit von vier Festplatten erhält. Je mehr Spindeln sich in einem Cluster befinden, desto mehr Prozesse kann der Ceph-Cluster parallel abhandeln.

Für den Einsatz im S3-Beispiel ist das eine gute Voraussetzung: Selbst Mailsysteme, die erhöhter Last ausgesetzt sind, können im Hintergrund problemlos viele Mails zeitgleich in Ceph ablegen. Einzig bei der sequenziellen Schreiblatenz schneidet Ceph meist deutlich schlechter ab als konventionelle Speicherlösungen; genau dieser Fall ist für das Dovecot-S3-Beispiel allerdings belanglos.

Ceph-Frontends: RBD, Ceph-FS, Ceph Object Gateway

Der schönste Objektspeicher ist nutzlos, wenn die Clients nicht direkt mit ihm kommunizieren können. Ceph bietet gleich mehrere Möglichkeiten für Clients, Kontakt mit ihm aufzunehmen. Das Rados-Blockdevice emuliert auf Linux-Basis eine normale Festplatte. Was auf den Client-Computern dann so aussieht, als wäre es lokal eingebaut, ist in Wirklichkeit ein virtuelles Blockdevice. Writes auf dieses Blockdevice wandern im Hintergrund direkt zu Ceph.

Ceph-FS ist ein Posix-kompatibles Dateisystem, das jedoch Inktanks ewiges Sorgenkind ist und seit Jahren konsequent nicht fertig wird. Für das S3-Beispiel aus den Abbildungen 3 bis 5 wirklich interessant ist dagegen das Ceph Object Gateway. Das vormals als Rados Gateway bezeichnete Konstrukt basiert auf der Librados, die direkten und nativen Zugriff auf Ceph-Objekte ermöglicht. Auf der anderen Seite exponiert das Rados Gateway RESTful-APIs, die wahlweise der Syntax von Amazon S3 oder Open Stack Swift folgen.

Abbildung 3: Ein existierender Ceph-Cluster lässt sich über einen Eintrag wie diesen schnell um ein Ceph Object Gateway erweitern.

Abbildung 4: Damit das Ceph Object Gateway funktioniert, braucht es einen Fast-CGI-fähigen Webbrowser. Apache mit »mod_fastcgi« ist die typische Kombination.

Abbildung 5: Der Beweis: Das Ceph Object Gateway meldet sich beim Aufruf einer URL und zeigt an, dass für den Nutzer »anonymous« keine Buckets hinterlegt sind.

Zwar implementiert das Ceph Object Gateway die S3-Spezifikation nicht vollständig, die wichtigsten Funktionen sind aber auch im Gateway zu finden. Damit ist die Lösung vollständig: Ein Cluster mit mindestens drei Knoten betreibt auf lokalen Platten Ceph. Hinzu kommt ein Server, der das Ceph Object Gateway steuert und verschiedenen Instanzen von Dovecot mit S3-Plugin das Ablegen von E-Mails erlaubt.

Eine solche Lösung skaliert auf allen Ebenen: Braucht der Ceph-Cluster mehr Platz, schiebt der Admin mehr Kisten ins Rack. Wird die Last auf den Dovecot-Servern zu hoch, stellt der Admin ebenfalls mehr Maschinen ins Rack. Solange hinreichend Platz in Racks zur Verfügung steht, lässt sich dieses Prinzip praktisch ohne Grenzen ausdehnen.

Design-Überlegungen: S3-Load-Balancing

Vom nackten Blech zum fertigen Ceph-Cluster mit S3-Frontend ist der Weg übrigens nicht so steinig, wie es auf den ersten Blick aussieht. Inktank [4] hat in Form von »ceph-deploy« ein mächtiges Werkzeug im Köcher, das Ceph in wenigen Minuten auf Systeme mit gängigen Distributionen bringt. Wer erst mal in drei virtuellen Maschinen testen möchte, kann das natürlich ebenfalls tun.

Auch in die üblichen Automatisierungswerkzeuge wie Puppet oder Chef ist Ceph mittlerweile integriert – der Ceph-Cluster selbst gelingt also schnell. Mit etwas mehr Aufwand ist das Ceph Object Gateway verbunden: Inktank selbst hält auf [7] ausführliche Dokumentation bereit, die den gesamten Vorgang erklärt. Am Ende haben Admins eine Instanz des Ceph Object Gateway, die S3 spricht und als Anknüpfungspunkt für eine Dovecot-Instanz dienen kann.

Admins sollten allerdings im Hinterkopf behalten, dass bei großen Setups das S3-Gateway durchaus ins Schwitzen geraten kann. Kein Wunder: Wenn bloß eine einzelne Gateway-Instanz existiert, quetschen sich alle Verbindungen von den Dovecot-Frontends zu Ceph durch dieses eine Nadelöhr. Das ist nicht nur aus Performance-Sicht ein Problem, sondern auch ein klassischer Single Point of Failure (Abbildung 6).

Abbildung 6: So sieht ein einfaches Ceph-Gateway-Setup aus; dabei stellt die einzelne Gateway-Instanz allerdings einen Single Point of Failure dar.

Weil S3 aber auf HTTP basiert und HA-Ansätze für HTTP zur Genüge existieren, ist die Lösung des Problems naheliegend: Sinnvollerweise fangen Admins gleich mit zwei Objekt-Gateways an, vor denen ein (hochverfügbarer) Load Balancer eingehende Verbindungen entsprechend weiterleitet (Abbildung 7). Auch diese Architektur ist skalierbar; zusätzliche Object Gateways lassen sich jederzeit integrieren, und das gelingt dann auch ohne jede Downtime.

Abbildung 7: So ist’s besser: Das Setup lässt sich auf allen Ebenen nahtlos in die Breite skalieren.

Fazit

Timo Sirainen erweitert mit seinem S3-Plugin für Dovecot das Thema Mail um Skalierbarkeit auf der Storage-Ebene. Für Admins steht damit eine sinnvolle Alternative zu den klassischen Lösungen bereit – jenen Lösungen wie Sharding, deren Inflexibilität in den agilen IT-Strukturen der Gegenwart oft genug Probleme bereitet. Wermutstropfen sind zweifellos die Lizenzkosten, die der Autor für das Plugin erhebt. In einem sinnvollen Setup sollten die sich allerdings recht schnell wieder dadurch einspielen lassen, dass auf Storage-Seite kein teures SAN mehr arbeitet, sondern Ceph auf Hardware von der Stange. In Sachen Performance erweist sich Ceph – vom Single-Serial-Write-Szenario abgesehen – meist als die überlegene Lösung und muss den direkten Vergleich mit kommerziellen Storages keinesfalls scheuen.

Wer ein E-Mail-Setup betreibt und regelmäßig vor der Herausforderung steht, mehr Platz für die Daten seiner Nutzer zu schaffen, sollte sich die Kombination aus Dovecot, dem S3-Plugin und Ceph mit Ceph Object Gateway jedenfalls genauer ansehen. Die Anleitung in [8] erläutert, wie sich ein Ceph mit Object Gateway so einrichten lässt, dass es gegenüber Clients vom “echten S3” gar nicht zu unterscheiden ist.