5 Die Architektur von E-Mail-Speicher ist eines der ältesten Speicherprobleme großen Maßstabs in der IT und eines der am wenigsten diskutierten. Telekommunikationsanbieter, Internetanbieter, Hosting-Unternehmen und Webmail-Plattformen speichern Postfächer für Millionen Benutzer, oft über Jahrzehnte. Jedes Postfach ist eine Mischung aus winzigen Metadatenaktualisierungen und vielen kleinen, unveränderlichen Nachrichten mit einem langen Schweif an Anhängen. Die meiste Mail wird einmal geschrieben und selten wieder gelesen, doch Benutzer erwarten, dass sich jede Nachricht von vor Jahren sofort auf dem Smartphone öffnet. Dieser Artikel erklärt, wie große Mailplattformen typischerweise aufgebaut sind, wie sich Speicherformate und Backends von lokalen Festplatten über NAS bis zu Objektspeicher entwickelt haben und was Architekten bei der Neugestaltung der Speicherschicht abwägen sollten. Er richtet sich an Plattformarchitekten und Mail-Ingenieure bei Anbietern, doch dieselben Ideen gelten auch für große Unternehmen, die eigene Mailsysteme betreiben. Die Bausteine einer Mailplattform Eine große Mailplattform gliedert sich in der Regel in Schichten: Edge- und Proxy-Server, die IMAP-, POP3- und Webmail-Verbindungen annehmen und jeden Benutzer an das richtige Backend leiten. Mail Transfer Agents (MTAs), die eingehende Mail empfangen, Spam- und Malware-Filter ausführen und Nachrichten an die Zustellung übergeben. Server für Mailzustellung und -zugriff, die Nachrichten in Postfächer schreiben und an Clients ausliefern. Index und Metadaten, die für jedes Postfach Ordner, Flags, Nachrichtenreihenfolge und Suchdaten verfolgen. Mailspeicher, der die Nachrichten selbst vorhält. Verzeichnis- und Authentifizierungsdienste, die Benutzer Backends und Zugangsdaten zuordnen. Entscheidungen zur Speicherarchitektur betreffen vor allem die letzten drei Schichten: wie Nachrichten abgelegt werden, wo Indizes liegen und welches Backend sie vorhält. Postfachformate Wie Nachrichten auf den Speicher geschrieben werden, beeinflusst Leistung, Effizienz und Skalierbarkeit der Plattform. mbox Das älteste Format speichert einen ganzen Ordner in einer Datei und hängt jede neue Nachricht an. Es ist einfach, arbeitet im großen Maßstab aber schlecht, da das Löschen oder Ändern einer Nachricht das Neuschreiben einer großen Datei bedeuten kann. Maildir Maildir speichert jede Nachricht als eigene Datei, wobei die Flags im Dateinamen kodiert sind. Das Format ist robust und leicht nachvollziehbar und wurde für viele große Plattformen auf NAS zum Standard. Der Nachteil ist eine sehr große Zahl kleiner Dateien, die mit wachsenden Postfächern die Metadaten des Dateisystems und Backup-Werkzeuge belasten. Proprietäre Postfachformate Einige Mailserver nutzen eigene, proprietäre Postfachformate mit Single-Varianten (eine Nachricht pro Datei) und Multi-Varianten (viele Nachrichten pro Datei) sowie separaten Indexdateien für die Metadaten. Sie verringern einen Teil des Overheads von Maildir. Objektbasierte Layouts Objektspeicher-Plug-ins speichern jede Nachricht als Objekt mit eindeutiger Kennung und packen Indexdaten in Bundles, die in den Objektspeicher hochgeladen werden. Das beseitigt die Abhängigkeit von einem gemeinsamen Dateisystem. Speicher-Backends: von der lokalen Festplatte zum Objektspeicher Lokale Festplatten und Direct-Attached Storage Frühe große Plattformen platzierten Benutzer auf einzelnen Servern mit lokalem Speicher. Das ist günstig, aber starr: Fällt ein Server aus, sind seine Benutzer offline, und eine Neuverteilung der Benutzer bedeutet das Kopieren von Postfächern zwischen Servern. NAS und gemeinsame Dateisysteme Die meisten großen Mailplattformen der letzten zwei Jahrzehnte sind auf Network-Attached Storage über NFS umgestiegen. Jeder Backend-Server kann jeden Benutzer bedienen, was Failover und Lastverteilung vereinfacht. Als die Plattformen auf Milliarden Dateien wuchsen, brachte NAS eigene Probleme mit sich: Grenzen der Metadatenleistung, Probleme mit Dateisperren über NFS, teure Scale-up-Arrays, große und langsame Backups und störende Migrationen bei jeder Hardwareerneuerung. Objektspeicher Objektspeicher skaliert über viele Standardserver, bewältigt Milliarden Objekte und schützt Daten mit Erasure Coding oder Replikation statt mit RAID-Arrays. Für Mail passt er gut zum Workload: Nachrichten sind nach der Zustellung unveränderlich, jede kann ein einzelnes Objekt sein, und gemeinsame Dateisystemsperren sind überflüssig. Index- und Metadatenaktivität wird von lokalen Caches und Bundling auf den Mailservern abgefangen, während der Objektspeicher die dauerhafte Kopie vorhält. Die grundsätzlichen Unterschiede beschreibt der Beitrag Objektspeicher oder klassischer Speicher. Indizes, Caching und Metadaten Mailclients fragen ständig nach Ordnerlisten, Flags, Zählern ungelesener Nachrichten und Nachrichtenköpfen. Diese bei jeder Anfrage aus dem Speicher-Backend zu bedienen, wäre langsam. Große Plattformen setzen auf: Postfachindizes, die den Zustand jedes Ordners zusammenfassen. Lokale Caches auf den Mailservern für die Indizes aktiver Benutzer und kürzlich abgerufene Nachrichten. Metadatendatenbanken zur Zuordnung von Benutzern, Ordnern und Objekten, insbesondere in objektbasierten Designs, in denen das Auflisten von Objekten aus Leistungsgründen vermieden wird. Suchindizes für die Volltextsuche über Postfächer hinweg. Das Speicher-Backend muss häufige kleine Schreibvorgänge durch Indexaktualisierungen ebenso bewältigen wie größere Nachrichtenlesezugriffe. Objektbasierte Designs bündeln Indexaktualisierungen, wodurch aus vielen kleinen Änderungen weniger, größere Schreibvorgänge werden. Langlebigkeit, Verfügbarkeit und mehrere Standorte Mail ist ein Dienst mit hoher Sichtbarkeit. Benutzer bemerken selbst kurze Ausfälle, und verlorene Mail führt zu Beschwerden, Kundenabwanderung und bei Geschäftskunden zu vertraglichen Ansprüchen. Architekturen umfassen typischerweise: Datensicherung innerhalb der Speicherplattform, etwa Erasure Coding, das mehrere Laufwerks- oder Knotenausfälle übersteht. Mehrere Standorte, wobei Benutzer von einem Standort bedient und die Daten an einen anderen repliziert werden, oder Aktiv-aktiv-Designs, bei denen Benutzer von beiden Standorten bedient werden können. Zustandslose oder nahezu zustandslose Mailserver, damit ein ausgefallenes Backend ohne Datenwiederherstellung ersetzt werden kann. Backup und Wiederherstellung bei von Benutzern ausgelösten Löschungen und plattformweiten Vorfällen; mehr dazu im Beitrag E-Mail-Archivierung oder E-Mail-Backup. Kosten und Effizienz Mailspeicher wächst stetig. Benutzer löschen selten Mail, Postfach-Quotas steigen mit der Zeit, und Anhänge werden größer. Zu den Kostentreibern gehören: Rohkapazität und Redundanz-Zuschlag. Die Zahl der Dateien oder Objekte, die Metadatenleistung und Backup beeinflusst. Strom, Rack-Fläche und Zyklen der Hardwareerneuerung. Betriebsaufwand für Neuverteilung, Migrationen und Backup. Kalte Mail auf günstigere Kapazität zu verlagern, Nachrichten zu komprimieren und identische Anhänge zu deduplizieren, kann die Kosten senken, erhöht aber jeweils die Komplexität des Designs. Die Abwägungen zwischen Speicherstufen behandelt der Beitrag Hot Storage oder Cold Storage. Skalierung auf Millionen Postfächer Beim Wachstum zeigt sich, ob Architekturentscheidungen tragen. Eine Plattform auf Scale-up-NAS stößt an Grenzen bei Metadatenleistung und Array-Größe, und jedes neue Array schafft eine weitere Insel, die verwaltet werden muss. Scale-out-Designs, bei denen Mailserver und Speicherknoten schrittweise hinzugefügt werden, vermeiden diese Grenzen. Unser Artikel zum Thema Mailbox-Speicher auf Millionen Benutzer skalieren beschreibt die Muster im Detail. Sicherheit und Datenschutz Mail enthält einige der sensibelsten personenbezogenen Daten, die ein Anbieter vorhält. Das Speicherdesign sollte Verschlüsselung im Ruhezustand, Verschlüsselung bei der Übertragung zwischen Mailservern und Speicher, streng geregelten administrativen Zugriff mit Audit-Protokollierung und einen klar definierten Speicherort der Daten für regulatorische Zwecke wie die DSGVO abdecken. Viele Anbieter müssen zudem die Daten eines Benutzers bei Kontoschließung vollständig löschen und die Entfernung nachweisen können. Wann die Speicherschicht neu gestaltet werden sollte Häufige Auslöser für eine Neuarchitektur sind eine NAS-Plattform am Ende des Supports, Backup-Fenster, die nicht mehr ausreichen, Probleme mit der Metadatenleistung zu Spitzenzeiten, die Kosten des nächsten Array-Upgrades oder eine Konsolidierung nach Übernahmen. Der Umzug einer laufenden Mailplattform ist ein erhebliches Projekt, lässt sich aber schrittweise, Benutzer für Benutzer, umsetzen. Checkliste: Architektur von E-Mail-Speicher bewerten Welches Postfachformat nutzen Sie, und wie viele Dateien oder Objekte erzeugt es? Kann jeder Mailserver jeden Benutzer bedienen, oder sind Benutzer an Speicherinseln gebunden? Wo liegen Indizes und Caches, und wie werden sie nach einem Ausfall neu aufgebaut? Wie skaliert das Speicher-Backend: vertikal durch zusätzliche Arrays oder horizontal durch zusätzliche Knoten? Wie werden Daten innerhalb eines Standorts und standortübergreifend geschützt? Wie lange dauern Backups und Wiederherstellungen eines großen Postfachbestands? Wie hoch sind die Kosten pro gespeichertem Terabyte, einschließlich Hardwareerneuerung und Betrieb? Lassen sich Benutzer schrittweise und ohne Ausfallzeit auf neuen Speicher migrieren? Sind Verschlüsselung, Zugriffskontrolle und Löschung für die Compliance nachprüfbar? Fazit Die Architektur von E-Mail-Speicher hat sich von lokalen Festplatten über NAS zunehmend zu Objektspeicher entwickelt, getrieben durch das Wachstum bei Benutzern, Postfachgrößen und der Zahl kleiner Dateien. Das richtige Design hält Mailserver so zustandslos wie möglich, nutzt lokales Caching und gebündelte Indizes für schnelle Reaktionszeiten und legt dauerhafte Daten auf Speicher, der horizontal skaliert, sich selbst schützt und erneuert werden kann, ohne jedes Postfach zu verschieben. Für Anbieter, die ihre nächste Plattform planen, ist das Ziel ein Design, das ein weiteres Jahrzehnt wachsen kann, ohne eine weitere Komplettmigration. Häufig gestellte Fragen Welchen Speicher nutzen große E-Mail-Anbieter? Viele große Plattformen nutzten in der Vergangenheit NAS über NFS mit Maildir oder ähnlichen Formaten. Zunehmend setzen Anbieter auf Objektspeicher mit Mailserver-Plug-ins, die Nachrichten als Objekte speichern und Indizes lokal zwischenspeichern. Wird Maildir noch genutzt? Ja, es ist weiterhin verbreitet, vor allem auf NAS. Das Prinzip einer Datei pro Nachricht ist robust, erzeugt im großen Maßstab aber sehr hohe Dateizahlen. Warum E-Mail auf Objektspeicher verlagern? Objektspeicher skaliert horizontal auf Milliarden Objekte, vermeidet NFS-Sperren und Metadatengrenzen, schützt Daten mit Erasure Coding und ermöglicht eine schrittweise Hardwareerneuerung. Wie halten Mailplattformen IMAP auf Objektspeicher reaktionsschnell? Sie speichern Indizes und aktuelle Nachrichten lokal auf den Mailservern zwischen, bündeln Indexaktualisierungen und nutzen Metadatendatenbanken, statt Objekte aufzulisten. Wie viel Speicher benötigt eine große Mailplattform? Das hängt von Benutzerzahl, Quotas, durchschnittlicher Postfachgröße, Aufbewahrung und Redundanz-Zuschlag ab. Plattformen mit Millionen Benutzern erreichen häufig den Petabyte-Bereich. Weiterführende Artikel Mailbox-Speicher skalieren E-Mail-Archivierung oder E-Mail-Backup Mailspeicher von NAS auf Objektspeicher migrieren Speicher für Telekommunikationsdaten
