7 Mailbox-Speicher von Tausenden auf Millionen Benutzer zu skalieren, hat weniger mit dem Kauf größerer Arrays zu tun als damit, die Designentscheidungen zu beseitigen, die das Wachstum einer Plattform bremsen. Mailplattformen bei Telekommunikationsanbietern, Internetanbietern und Hosting-Unternehmen wachsen in zwei Richtungen zugleich: mehr Benutzer und mehr Daten pro Benutzer, weil Quotas steigen und Anhänge größer werden. Plattformen, die reibungslos skalieren, haben einige Merkmale gemeinsam: Benutzer können frei zwischen Servern wechseln, Mailserver halten wenig dauerhaften Zustand, Caching fängt den Großteil der Lesezugriffe ab, und das Speicher-Backend wächst durch zusätzliche Knoten statt durch den Austausch von Systemen. Dieser Artikel behandelt die Dimensionierung von Mailbox-Speicher, die Architekturmuster, mit denen eine Plattform Mailbox-Speicher auf Millionen Benutzer skaliert, und die Betriebspraktiken, die sie beherrschbar halten. Das Gesamtdesign beschreibt unser Überblicksartikel zur Architektur von E-Mail-Speicher. Mit einem Dimensionierungsmodell beginnen Ein hilfreiches Modell trennt Kapazität und Aktivität, da beide unterschiedlich skalieren. Eingangsgrößen für die Kapazität Anzahl der Postfächer, einschließlich inaktiver Konten, die noch Daten enthalten. Durchschnittliche Postfachgröße, die zwischen kostenlosen Privatkonten, kostenpflichtigen Konten und Geschäftspostfächern meist stark variiert. Wachstum pro Postfach und Jahr, bestimmt durch das eingehende Mailvolumen und die Löschgewohnheiten der Benutzer. Quota-Richtlinie, die das Wachstum für manche Benutzer begrenzt, aber nicht für alle. Redundanz-Zuschlag durch Erasure Coding oder Replikation, plus Kopien an einem zweiten Standort. Aufbewahrung gelöschter Mail, sofern gelöschte Nachrichten für einen Wiederherstellungszeitraum behalten werden. Ein Beispiel: 5 Millionen Postfächer mit durchschnittlich 2 GB ergeben 10 PB logische Daten vor Kompression und Redundanz. Wächst die durchschnittliche Postfachgröße um 15 Prozent pro Jahr, kommen allein im ersten Jahr 1,5 PB logische Daten hinzu. Die realen Zahlen variieren stark, bauen Sie das Modell daher aus Ihren eigenen Kontostatistiken auf. Die allgemeine Methode beschreibt der Beitrag Kapazitätsplanung für Speicher. Eingangsgrößen für die Aktivität Gleichzeitig aktive Benutzer zu Spitzenzeiten, oft nur ein kleiner Teil aller Konten. Zugestellte Nachrichten pro Sekunde zu Spitzenzeiten. IMAP-Operationen pro Benutzersitzung, etwa Ordnersynchronisationen, Flag-Änderungen und Nachrichtenabrufe. Durchschnittliche und mediane Nachrichtengröße, da viele Nachrichten klein sind. Lösch- und Expunge-Rate. Die Aktivität bestimmt die Zahl der Mailserver, die Cache-Größen und die Anfragerate, die das Speicher-Backend bewältigen muss. Eine Plattform kann reichlich Kapazität haben und trotzdem in Schwierigkeiten geraten, wenn das Backend zu Spitzenzeiten nicht mit kleinen Anfragen Schritt hält. Die Inseln beseitigen Das erste Hindernis für die Skalierung ist meist, dass Benutzer an bestimmten Speicher gebunden sind. Hält jeder Mailserver oder jedes NAS-Volume eine feste Gruppe von Benutzern, muss bei jedem Wachstumsschritt die Platzierung neuer Benutzer sorgfältig geplant werden, und jede Neuverteilung bedeutet das Kopieren von Postfächern. Gut skalierende Plattformen entkoppeln Benutzer vom Speicher: Eine Proxy- oder Director-Schicht leitet jeden Benutzer anhand einer konsistenten Zuordnung, typischerweise eines Hashs des Benutzernamens, an einen Mailserver. Mailserver sind austauschbar und können jeden Benutzer bedienen, weil die Daten auf gemeinsamem Speicher liegen. Das Speicher-Backend ist ein logischer Pool und keine Sammlung separater Volumes. Mit dieser Trennung erhöhen zusätzliche Mailserver die Verarbeitungskapazität und zusätzliche Speicherknoten die Speicherkapazität, unabhängig voneinander. Mailserver nahezu zustandslos machen Halten Mailserver nur zwischengespeicherte Daten, ist ein ausgefallener Server ein kleines Ereignis: Seine Benutzer werden an einen anderen Server geleitet, der ihre Daten aus dem Backend abruft. Mail-Designs auf Basis von Objektspeicher treiben das am weitesten: Nachrichten und Index-Bundles werden als Objekte gespeichert, und lokale Festplatten dienen nur als Cache. Auf dateibasierten Plattformen entspricht dem ein gemeinsames NAS ohne Daten auf lokalen Festplatten, wobei NFS-Sperren und Metadatengrenzen mit wachsender Benutzerzahl zur nächsten Hürde werden. Caching die Hauptarbeit überlassen Die meisten Lesezugriffe auf Mail betreffen aktuelle Nachrichten und Indizes aktiver Benutzer. Lokale Caches auf den Mailservern fangen den Großteil dieser Last ab: Index-Caches halten den Ordnerstatus aktiver Benutzer auf lokalen SSDs vor. Nachrichten-Caches halten kürzlich gelesene Nachrichten im Arbeitsspeicher oder auf SSDs vor. Benutzeraffinität auf der Proxy-Schicht hält jeden Benutzer auf demselben Server, sodass die Caches warm bleiben. Gutes Caching bedeutet, dass das Speicher-Backend überwiegend neue Zustellungen, Cache-Misses und periodische Index-Uploads sieht, eine weit vorhersehbarere Last als der rohe Client-Verkehr. Ein Backend wählen, das horizontal skaliert Bei Millionen Benutzern muss das Speicher-Backend Milliarden Objekte oder Dateien, hohe Raten kleiner Anfragen und stetiges Kapazitätswachstum bewältigen. Grob gibt es diese Optionen: Scale-up-NAS, das gut arbeitet, bis Metadaten- oder Controller-Grenzen erreicht sind, und dann ein neues Array und eine Migration erfordert. Scale-out-Dateisysteme, die Knoten hinzufügen, aber weiterhin den Overhead von Dateisystem-Metadaten und Sperren mitbringen. Objektspeicher, der Kapazität und Anfrageverarbeitung durch zusätzliche Knoten skaliert, ohne gemeinsame Dateisystemsperren auskommt und Daten mit Erasure Coding schützt. Für große Mailplattformen ist Objektspeicher zu einem gängigen Ziel geworden, weil Mailnachrichten nach der Zustellung unveränderlich sind und sich natürlich auf Objekte abbilden lassen. Für kleine Objekte und hohe Anfrageraten planen Mail ist ein Workload mit kleinen Objekten. Viele Nachrichten sind wenige Kilobyte groß, Index-Bundles sind moderat, und Löschungen erfolgen ständig. Testen Sie bei der Bewertung eines Backends: Dauerhafte Raten kleiner PUT- und GET-Anfragen mit realistischen Objektgrößen. Latenz-Perzentile, nicht nur Mittelwerte, da langsame Ausreißer das Benutzererlebnis beeinträchtigen. Löschdurchsatz und wie schnell Kapazität freigegeben wird. Verhalten bei Laufwerks- und Knotenausfällen, einschließlich der Auswirkungen von Rebuilds auf die Latenz. Der Artikel im scality.com-Blog über S3-Anfrageleistung behandelt die entscheidenden Faktoren, und der Beitrag über Rebuilds bei Objektspeicher erklärt, was bei Hardwareausfällen geschieht. Über mehrere Standorte skalieren Große Anbieter betreiben Mail meist über mindestens zwei Rechenzentren. Gängige Muster: Aktiv-passiv: Benutzer werden von einem Standort bedient, und die Daten werden für die Notfallwiederherstellung an einen anderen repliziert. Aktiv-aktiv nach Benutzer: Jeder Benutzer ist einem Heimatstandort zugeordnet und kann auf den anderen umschalten. Gestreckter Speicher: Eine Objektspeicherplattform erstreckt sich über mehrere Standorte, sodass Mailserver an jedem Standort die Daten jedes Benutzers lesen können. Die Wahl hängt von der Latenz zwischen den Standorten, den Wiederherstellungszielen und den Kosten ab. Unabhängig vom Muster sollten Sie das Failover zwischen Standorten mit echten Benutzern testen. Wachstum über Richtlinien steuern Speicherwachstum ist nicht nur eine technische Frage. Richtlinien, die das Wachstum beherrschbar halten: Quotas nach Kontotyp, mit klaren Upgrade-Pfaden für kostenpflichtige Tarife. Bereinigung inaktiver Konten: Postfächer, auf die lange nicht zugegriffen wurde, werden nach Benachrichtigung der Benutzer entfernt, im Einklang mit den Nutzungsbedingungen und dem Datenschutzrecht. Grenzen für die Aufbewahrung gelöschter Mail, damit Wiederherstellungszeiträume nicht zu unbegrenzter Speicherung werden. Kompression gespeicherter Nachrichten, die Kapazität bei moderatem CPU-Aufwand spart. Datenschutzvorgaben wie die DSGVO verlangen zudem, dass personenbezogene Daten nicht länger als nötig aufbewahrt werden, was die Bereinigung geschlossener und verwaister Konten unterstützt. Im großen Maßstab betreiben Betriebspraktiken entscheiden darüber, ob eine Plattform reibungslos wächst oder von Krise zu Krise stolpert: Je Schicht überwachen: Proxy-Routing, Mailserver-Last, Cache-Trefferquoten und Speicherlatenz. Benutzerumzüge automatisieren ebenso wie den Austausch von Servern. Kapazität in kleinen Schritten hinzufügen, deutlich bevor Schwellenwerte erreicht werden. Hardware im laufenden Betrieb erneuern, indem alte Speicherknoten ersetzt werden, während der Dienst läuft. Backup und Wiederherstellung testen, sowohl für Wiederherstellungen einzelner Benutzer als auch für größere Vorfälle. Checkliste: Mailbox-Speicher skalieren Ein Dimensionierungsmodell aufbauen, das Kapazität und Aktivität trennt. Benutzer mit einer Proxy-Schicht und einem gemeinsamen Backend vom Speicher entkoppeln. Mailserver nahezu zustandslos halten und lokale Festplatten als Cache nutzen. Caches für die aktiven Benutzer zu Spitzenzeiten dimensionieren und Benutzeraffinität durchsetzen. Ein Backend wählen, das für Kapazität und Anfragerate horizontal skaliert. Leistung bei kleinen Objekten, Latenz-Perzentile und Löschdurchsatz testen. Zugriff über mehrere Standorte entwerfen und Failover testen. Quota-, Bereinigungs- und Aufbewahrungsrichtlinien anwenden. Den Betrieb automatisieren und Kapazität in kleinen Schritten hinzufügen. Fazit Um Mailbox-Speicher auf Millionen Benutzer zu skalieren, beseitigen Sie die Inseln, die Benutzer an bestimmte Server binden, halten Sie Mailserver schlank, lassen Sie Caching die Lesezugriffe abfangen und legen Sie dauerhafte Daten auf Speicher, der durch zusätzliche Knoten wächst. Kombinieren Sie diese Architektur mit Wachstumsrichtlinien und diszipliniertem Betrieb, dann kann die Plattform weiter wachsen, ohne die periodischen Komplettmigrationen, die viele Mailplattformen geprägt haben. Läuft Ihre Plattform heute auf NAS, lesen Sie den Beitrag Mailspeicher von NAS auf Objektspeicher migrieren. Häufig gestellte Fragen Wie viel Speicher benötigen eine Million Postfächer? Das hängt von durchschnittlicher Postfachgröße, Wachstum und Redundanz-Zuschlag ab. Bei beispielhaften 2 GB pro Postfach ergeben eine Million Postfächer rund 2 PB logische Daten vor Kompression und Redundanz. Was begrenzt die Skalierung von Mailspeicher auf NAS? Meist die Metadatenleistung bei Milliarden kleiner Dateien, NFS-Sperren, Controller-Grenzen sowie Kosten und Störungen durch Array-Upgrades. Warum Mailserver zustandslos machen? Damit jeder Server jeden Benutzer bedienen kann und ein ausgefallener Server ohne Datenwiederherstellung ersetzt werden kann, was Skalierung und Failover vereinfacht. Wie wichtig ist Caching für Mailplattformen? Sehr wichtig. Lokale Index- und Nachrichten-Caches fangen den Großteil der Lesezugriffe ab, machen die Speicherlast vorhersehbarer und halten IMAP reaktionsschnell. Eignet sich Objektspeicher für E-Mail? Ja. Nachrichten sind nach der Zustellung unveränderlich und lassen sich natürlich auf Objekte abbilden, und Objektspeicher skaliert mit Erasure-Coding-Schutz auf Milliarden Objekte. Weiterführende Artikel Architektur von E-Mail-Speicher E-Mail-Archivierung oder E-Mail-Backup Mailspeicher von NAS auf Objektspeicher migrieren Kapazitätsplanung für Speicher
