Materielle Dimensionierung

Die hier angegebenen Daten dienen lediglich als Richtwerte. Denn selbst bei gleicher Nutzerzahl kann die Verwendung je nach Struktur und Gewohnheiten sehr unterschiedlich ausfallen. Die Anzahl der E-Mails, deren Größe, die Anzahl der Empfänger in den E-Mails, die Anzahl der Termine, der Planungsvorgänge … all dies variiert täglich stark.

Über virtualisierte Umgebungen

Die unten angegebenen Ressourcen an vCPU und/oder RAM sind für virtuelle Maschinen vorgesehen. Das bedeutet, dass diese Ressourcen von einer eventuellen gemeinsamen Nutzung mit anderen virtuellen Maschinen ausgeschlossen werden müssen.
Es ist daher besonders darauf zu achten, dass BlueMind Instanzen nicht in einem Kontext platziert werden, in dem der Hypervisor oder die Hypervisoren im Status overcommit sind.

Das Prinzip der Einheiten

In einem System wie BlueMind gibt es verschiedene Komponenten, die Ressourcen verbrauchen.

Eine einfache Berechnung „pro Benutzer“ ist nicht aussagekräftig, da ein Benutzer, der ausschließlich die E-Mail-Funktion verwendet, das System nicht in gleicher Weise belastet wie ein Benutzer, der sowohl die E-Mail-Funktion als auch Tools für die Zusammenarbeit verwendet (Kalender usw.) nutzt, noch wie ein Benutzer, der MAPI oder ein mobiles Gerät verwendet.

Bei dieser Berechnung spielen zwei Faktoren eine Rolle:

• Nutzung: Je mehr Funktionen ein Benutzer aktiviert (z. B. Funktionen für die Zusammenarbeit, MAPI), desto stärker wird das System beansprucht;
• der mit dieser Nutzung verbundene Speicherbedarf: Bei gleicher Nutzung bedeutet eine höhere Quote, dass mehr Daten indiziert, gesichert und bereitgestellt werden müssen, was sich somit als Multiplikator auf die Kosten pro Einheit auswirkt.

Die Berechnung der Dimensionierung erfolgt daher pro Einheit, wobei Folgendes zu beachten ist:

Benutzerprofil	Speicherplatz / Kontingent	Kosten pro Einheit
Nur E-Mail	2 GB	1
Messaging + intensive Zusammenarbeit	4 GB	2
Nachrichten + Zusammenarbeit + Mapi	10 GB	5
Nachrichten + Zusammenarbeit + Mapi	50 GB	25

Die letzten beiden Zeilen veranschaulichen die Auswirkungen der Speicherkapazität: Bei identischer Nutzung (E-Mail + Zusammenarbeit + MAPI) führt eine um das Fünffache erhöhte Quote zu einem ebenfalls um das Fünffache erhöhten Kostenvolumen.

Auch bei gleicher Anzahl an Einheiten hat eine reine E-Mail-Verwendung nicht denselben Ressourcenverbrauch wie eine Verwendung mit E-Mail und Kollaborationsanwendungen (bei gleicher Nutzerzahl). E-Mails sind beispielsweise stärker von der E/A-Leistung abhängig als von der CPU-Leistung, was im Allgemeinen bei Kollaborationsanwendungen umgekehrt ist.

CPU

Die Werte werden anhand der Anzahl der Kerne bewertet und angegeben.

Referenz und Hardware-Empfehlungen

Für die nachstehenden Berechnungen wird 1 Zen-4-Kern eines AMD EPYC 9654 (Genoa, 5 nm, Markteinführung Ende 2022) verwendet.

Die ausgewählte CPU muss vom Hersteller über die gesamte geplante Laufzeit des E-Mail-Systems unterstützt werden: Bei einer auf 5 Jahre angelegten Installation sollten Sie eine CPU bevorzugen, deren Herstellerunterstützung diesen gesamten Zeitraum abdeckt. Ein zusätzliches zu berücksichtigendes Kriterium ist das Verhältnis von Leistung pro Watt, das neuere Architekturen (≤ 5 nm) gegenüber früheren Generationen (14/10 nm) deutlich begünstigt.

Äquivalenzen zwischen CPU-Generationen

Die nachstehende Tabelle „Anzahl der Kerne pro Einheit“ ist in vCPU-Äquivalenten des Zen 4 9654 angegeben.
Zur Orientierung finden Sie hier Angaben dazu, wie viele vCPUs anderer Plattformen erforderlich sind, um 8 Referenz-vCPUs zu erreichen, berechnet auf der Grundlage des Geekbench-6-Single-Core-Ergebnisses (ein angemessener Indikator für die Leistung pro Kern):

Plattform	Geekbench 6 SC	Ratio gegen 9654	Entspricht 8 Referenz-vCPUs	Entsprechende Leistungsaufnahme
Intel Xeon Platinum 8280 – Cascade Lake, 14 nm (2019)	~1214	0,65	~12 vCPU	~88 W
AMD EPYC 9654 — Zen 4, 5 nm (2022) — Referenz	~1859	1,00	8 vCPU	~30 W
Intel Xeon Gold 6542Y — Emerald Rapids, Intel 7/10 nm (2023)	~2263	1,22	~7 vCPU	~73 W
AMD EPYC 9755 — Zen 5 „Turin“, 3–4 nm (2024)	~2413	1,30	~6 vCPU	~23 W

Mit Geekbench Browser ermittelte Ergebnisse. Watt-Budget = (Sockel-TDP / Anzahl der Kerne) × äquivalente vCPUs bei Volllast (8280: 205 W / 28 K; 9654: 360 W / 96 K; 6542Y: 250 W / 24 K; 9755: 500 W / 128 K). Diese Verhältnisse dienen lediglich als Anhaltspunkt: Die tatsächliche Leistung hängt auch von der Speicherbandbreite, dem Cache, der Plattform und der Auslastung ab – für eine genaue Dimensionierung ist ein Benchmark unter den Zielbedingungen weiterhin vorzuziehen.

Virtualisierungscluster

In einem Virtualisierungscluster stellen die Hypervisoren den virtuellen Maschinen in der Regel die Kapazitäten des CPU mit der geringsten Leistung im Cluster zur Verfügung, um die Verschiebung der VMs zwischen den Knoten zu ermöglichen. BlueMind nutzt die modernen Funktionen der CPUs entsprechend den tatsächlich für die virtuellen Maschinen bereitgestellten Kapazitäten; eine neuere CPU, die mit einem veralteten Profil bereitgestellt wird, wird daher nicht ihre tatsächliche Leistung entfalten.

Befehlssätze

Über die Anzahl der Kerne und deren Taktfrequenz hinaus verwendet BlueMind mehrere Hardware-Befehlssätze. Deren Vorhandensein ist in den flags unter /proc/cpuinfo ersichtlich (oder bei einer VM in den vom Hypervisor tatsächlich bereitgestellten Einstellungen – siehe Kasten oben):

• aes: Hardwarebeschleunigung der AES-Verschlüsselung, die bei allen SSL/TLS-Verbindungen (IMAPS, HTTPS, SMTP STARTTLS, serverübergreifende Replikation) in großem Umfang zum Einsatz kommt.
• sha_ni: SHA-Befehle von Intel/AMD, die Hash-Berechnungen beschleunigen (Integritätsprüfungen, Signaturen, speicherseitige Hash-Berechnungen und Authentifizierung).
• avx, avx2 (SIMD): Diese werden insbesondere für die Base64-Dekodierung beim Einlesen von E-Mail-Anhängen verwendet – ein Vorgang, der immer dann stattfindet, wenn ein Benutzer seine E-Mails abruft.

⚠️ Eine neuere CPU, die in einer VM mit einem zu veralteten Profil eingesetzt wird (z. B. ein Nehalem- oder Westmere-Profil in einem heterogenen Cluster), kann diese Flags ganz oder teilweise unterdrücken und die wahrgenommene Leistung erheblich beeinträchtigen, obwohl die physische Hardware identisch ist.

Anzahl der Kerne pro Einheit

BlueMind umfasst viele Dienste, daher empfehlen wir 2 Kerne als Minimum.

Bitte beachten Sie, dassdie Zuweisung von zu viel CPU-Leistung in virtualisierten Umgebungen zu weiteren Problemen führen kann.

Einheiten	Anzahl der Herzen
1-200	2
200-1000	4
1000-2000	6
2000-3000	8
3000-6000	12
6000+	2 Kerne / 1000 Einheiten

RAM

Wir empfehlen 24 GB RAM als Minimum.

Einheiten	RAM
1-1000	24 GB
1000-2500	32 GB
2500 - 5000	48 GB
5000-10000	64 GB*
10000+	96 GB*

* mit Auslagerung des bm-elasticsearch-Dienstes auf einen dedizierten Server

Warum sollte man bm-elasticsearch auslagern?

Die Auslagerung von Elasticsearch auf eine eigene VM berücksichtigt mehrere Aspekte:

• Eine mit dem Hypervisor und dessen Optionen kompatible VM-Größe.
  Bestimmte Funktionen des Hypervisors legen eine Obergrenze für die Anzahl der vCPUs pro VM fest. Beispielsweise ist bei VMware Fault Tolerance die Obergrenze bei 8 vCPUs pro geschützter VM (Broadcom-Dokumentation) festgelegt → Durch das Auslagern der ES-VM können die Haupt-VM und die ES-VM unter diesen Grenzwerten gehalten werden.
• In einem NUMA-Knoten bleiben.
  Ab einer bestimmten Größe passt eine VM nicht mehr in einen NUMA-Knoten, wodurch die CPU-/Speicherplanung an Effizienz verliert. Die Granularität hängt von der physischen CPU ab: Ein Prozessor mit 96 Kernen kann beispielsweise in Gruppen von maximal 24 Kernen pro NUMA-Knoten organisiert sein, was die nutzbare Größe einer Single-Socket-VM einschränkt.
• Aufteilung der Ressourcen zwischen ES und dem restlichen BlueMind.
  Bei einer dedizierten VM vermischen sich der ES-Heap, sein Dateicache und seine Indizierungs-E/A nicht mehr mit denen des BlueMind-Kerns oder von PostgreSQL → Eine intensive Indizierung beeinträchtigt weder SQL-Abfragen noch den Zugriff auf /var/spool/cyrus/data.
• Verlagerung auf einen anderen Hypervisor.
  Durch die Verlagerung der ES-VM auf einen anderen Host (und idealerweise auf andere Netzwerkkarten) werden Ressourcen auf dem Haupt-Host freigesetzt und die Last kann auf den Virtualisierungspool verteilt werden.

Die Kehrseite: Eine oder mehrere zusätzliche VMs für ES bringen Komplexität und einen gewissen Overhead mit sich – ein neuer Kernel, der gewartet werden muss, ein neuer BlueMind-Knoten, der angemeldet werden muss, neue Überwachungsagenten und, wenn die ES-VM auf einem anderen Hypervisor läuft, die Durchquerung des physischen Netzwerks bei jeder Indizierungs- oder Suchanfrage. Falls diese Einschränkungen nicht zutreffen, kann eine einzige, richtig dimensionierte VM ausreichen.

Lagerung / IO

Art der Disks

Die Qualität und Geschwindigkeit der Festplatten ist ein entscheidender Faktor für ein leistungsfähiges E-Mail-System: Ein E-Mail-System beansprucht die Festplatten stark, sowohl beim Lesen und Schreiben kleiner Dateien als auch bei allen Verarbeitungsvorgängen im Zusammenhang mit E-Mails (Indizierung, Lesestatus usw.).

Die Verwendung von SSD-/NVMe-Festplatten ist bei einer Neuinstallation zwingend erforderlich und wird im Rahmen eines Upgrades von einer Version 4 dringend empfohlen, es sei denn, die vorhandene Hardware erfüllt die Anforderungen voll und ganz. Mechanische/rotierende Festplatten weisen hohe Latenzen auf, die mit den Anforderungen unvereinbar sind. Diese können gegebenenfalls für Backups oder im hierarchischen Speichersystem hinter leistungsstarken SSD/NVMe-Laufwerken verwendet werden.

Speichervirtualisierung

Virtualisierte oder verteilte Speichersysteme (Ceph, vSAN, iSCSI- oder NVMe-oF-SAN, NFS auf Remote-Speicher usw.) fügen mehrere Schichten zwischen der BlueMind-VM und den physischen Festplatten hinzu. Jede dieser Schichten führt zu einer zusätzlichen Latenz, deren Auswirkungen umso größer sind, je kleiner und zahlreicher die durchgeführten E/A-Vorgänge sind.

BlueMind empfiehlt daher, den folgenden Punkten besondere Aufmerksamkeit zu widmen:

• Latenz: Die Anforderungen variieren je nach Datenvolumen:
  • Für /var/lib/postgresql sollten Sie bei synchronen Schreibvorgängen < 1 ms anstreben; ab einigen Millisekunden verschlechtert sich die Leistung des gesamten E-Mail-Systems.
  • Für /var/spool/cyrus/data und andere E/A-Volumes sollten die IOPS unter 10 ms bleiben.
• Blockgröße: Bei BlueMind-Installationen lässt sich in der Regel beobachten, dass 80 % der E-Mails kleiner als 128 KB und 95 % kleiner als 1 MB sind. Überdimensionierte Blockgrößen (4-MB-Blöcke auf der Ceph-Seite, DiskMaxIOSize 1-MB-Blöcke auf der VMware-Seite usw.) vergrößern jeden E/A-Vorgang unnötig und beeinträchtigen die Leistung, insbesondere bei der PostgreSQL-Datenbank, die mit 8-KB-Seiten arbeitet.
• Nenn- und gemessene Leistung: Die angegebenen IOPS entsprechen nicht unbedingt den tatsächlich für die VM verfügbaren Werten, sobald der Cache ausgelastet ist oder andere Lasten auf dem Cluster vorliegen.
• Cluster-Ereignisse: Rebuild- und Rebalance-Vorgänge auf Ceph- oder vSAN-Seite können vorübergehend zu Leistungseinbußen bei der virtuellen Maschine führen.
• Aufteilung der Netzwerkdatenflüsse: Das für den Zugriff auf den Speicher verwendete Netzwerk muss vom Benutzerdatenverkehr getrennt werden.
  So darf beispielsweise das Herunterladen eines großen Anhangs über Outlook weder die Leistung von SQL-Abfragen noch die von Schreibvorgängen im E-Mail-Volumen beeinträchtigen → Weisen Sie dem Speicher separate Schnittstellen und/oder VLANs zu.

Alternative mit lokaler Latenz: Ein Hypervisor wie Proxmox in Verbindung mit ZFS auf lokalen NVMe-Festplatten bietet die Latenz einer direkt angeschlossenen Festplatte und gewährleistet gleichzeitig Snapshots, asynchrone Replikation und Datenintegrität. Dies ist ein sinnvoller Ansatz, wenn die E/A-Leistung Vorrang vor der Hot-Mobility der VMs hat.

Zurück zu einem früheren Snapshot

Das Zurücksetzen der BlueMind-Instanz auf einen früheren Hypervisor- oder ZFS-Snapshot hat für bereits konfigurierte Clients nicht nur geringfügige Auswirkungen:

• MAPI-Clients (Outlook): Der Status von Client und Server gerät aus dem Gleichgewicht, was zu Duplikaten, fehlenden Elementen oder einer vollständigen Neusynchronisierung des Postfachs führen kann.
• Mobile Apps / MailApp: Die Objekt-IDs (UID, Sync-Schlüssel) lassen sich zeitlich zurückverfolgen; Kunden können Änderungen rückgängig machen oder überspringen.

Um einen Rückschritt durchzuführen, sollten Sie daher eine Wiederherstellung über DataProtect einem Snapshot vorziehen.

Snapshots eignen sich hingegen weiterhin als Sicherheitsnetz bei einem Update, sofern zwei Bedingungen erfüllt sind:

• Der Benutzerdatenfluss wird vor BlueMind unterbrochen, bevor der Snapshot erstellt wird (keine aktiven MAPI-, Mobil- oder Webmail-Clients während des Zeitfensters)
• Snapshots sind über alle VMs der Infrastruktur hinweg atomar, um eine dienstübergreifende konsistente Wiederherstellung zu gewährleisten

Mindestleistung und -volumen der Festplatten

Die Dimensionierung des Speichers erfolgt anhand zweier Kriterien: IOPS¹ ) und Latenz.

Beispiel

Zur Veranschaulichung: Ein Laufwerk wie die Samsung PM1733 NVMe SSD (2022) erfüllt diese Anforderungen bei direktem Anschluss perfekt.

Sobald sich diese Festplatte hinter einer Netzwerkspeicherschicht (Ceph, vSAN, iSCSI-SAN oder NVMe-oF...) verbirgt, machen die durch diese Schicht verursachte Latenz sowie die Konfiguration dieser Komponenten für den Messaging-Einsatz den entscheidenden Unterschied aus (siehe Abschnitt „Speichervirtualisierung“).

BlueMind hat daher einen dedizierten E/A-Puffer hinzugefügt, der unter /var/mmap-pool eingebunden ist (siehe entsprechende Zeile in der Tabelle der Einhängepunkte unten).
ℹ️ Funktionsweise: Dieser Puffer hält ein Maximum an Daten im Arbeitsspeicher vor; wenn ein Schreibvorgang auf die Festplatte erforderlich wird, bündelt er die Operationen zu großen Blöcken, die von den darunterliegenden Schichten besser verarbeitet werden können. Dadurch wird das System gegenüber virtualisierten oder netzwerkbasierten Speichersystemen (vSAN, Ceph, NFS, iSCSI-SAN oder NVMe-oF) fehlertoleranter als ein IO-naiver Dienst.

Der Speicherplatz hängt hingegen direkt von den Anforderungen des Kunden ab (Kontingente usw.).

Je nach Verwendungszweck müssen nicht alle Festplatten zwangsläufig das gleiche Leistungsniveau oder die gleiche Speicherkapazität aufweisen.

Bitte beachten Sie

Die unten angegebenen Mindestspeichergrößen sind Schätzwerte, die je nach Installation und organisatorischen Veränderungen variieren können. Es ist daher ratsam, Technologien zu verwenden, die eine einfache Erweiterung der Dateisysteme (LVM usw.) ermöglichen.

Einbindungspunkte

Montagepunkt	Beschreibung	Typ NFS	Typ Object Storage S3/Scality Ring	Minimale Volumetrie
/tmp	Temporäre Dateien	❌	❌	1,2 GB für die Installation von BlueMind. Dies ist auf die Entpackung des Installationsprogramms zurückzuführen.
/usr		❌	❌	8 GB für die Speicherung von Modulen und Webanwendungen.
/var/backups/bluemind	DataProtect-Backups	✅	❌	Summe aus: /var/spool/cyrus/data, /var/spool/bm-hsm, /var/lib/postgresql und /var/spool/bm-elasticsearch/data. Bei /var/spool/cyrus/data und /var/spool/bm-hsm mit einer Größe von mehr als 1 TB empfehlen wir, die DataProtect-Sicherung von E-Mails zu deaktivieren. Sie können ein Backup-System eines Drittanbieters und/oder den doppelten Papierkorb verwenden.
/var/lib/alloy	Erfassung und Berichterstellung von Metriken für die Überwachung	❌	❌	3 GB auf jedem Server der Installation
/var/lib/mimir	Mimir/Promotheus-Datenbank (Überwachungsmetriken)	❌	❌	10 GB auf dem Server mit dem Tag „bm/monitoring“
/var/lib/postgresql	Postgresql-Datenbank	❌	❌	5% des Volumens von /var/spool/cyrus/data + /var/spool/bm-hsm. NB: Der auf dieser Partition genutzte Speicherplatz wird während einer Einzelne Wiederherstellungen - DataProtect verdoppelt.
/var/lib/valkey	Valkey/Redis-Datenbank (interner Cache, ersetzt /var/spool/bm-hollowed)	❌	❌	Mindestens 2 GB, anzupassen je nach Anzahl der gleichzeitigen Sitzungen und der Größe des Verzeichnisses (einschließlich Fotos und S/MIME-Zertifikate).
/var/log	System- und Anwendungsprotokolle	❌	❌	50 GB
/var/mmap-pool	BlueMind-E/A-Puffer: Der Speicherplatz wird auf der Festplatte reserviert, doch die tatsächlichen Schreibvorgänge werden erst in Abhängigkeit von der Speicherauslastung des Systems ausgelöst (siehe oben).	❌	❌	20 GB
/var/spool/bm-docs	Speichern von Miniaturansichten von Benutzern, Ressourcen...	❌	❌	1 MB pro Einheit mit Miniaturbild
/var/spool/bm-elasticsearch	Elasticsearch Indexdaten	❌	❌	10% des Volumens von /var/spool/cyrus/data + /var/spool/bm-hsm.
/var/spool/bm-mail	Versenden von E-Mails über EAS/MAPI	❌	❌	2 GB
/var/spool/bm-mapi	Temporäre Verzeichnisse des Dienstes bm-mapi	❌	❌	2 GB
/var/spool/cyrus/data	Speicherplatz für E-Mails	❌	✅	Der größte Speicherbedarf, der sich nach dem erwarteten E-Mail-Volumen richtet.
/var/spool/bm-hsm	Aus Version 4 übernommen: Sekundärer Speicherplatz für E-Mails (siehe Hierarchischer Speicher (HSM)); dieser bleibt zur Gewährleistung der Kompatibilität bei Migrationen von Version 4 → Version 5 erhalten. Bei einer Neuinstallation von Version 5 das integrierte HSM nicht aktivieren: BlueMind empfiehlt, die Speicherhierarchie unterhalb der Anwendung zu verwalten, entweder im Objektspeicher (wo die Hierarchie auf Bucket-Ebene konfigurierbar ist) oder indem die Verwaltung eines RAM-/NVMe-/mechanischen Festplatten-Pools spezialisierten Teams anvertraut wird.	⚠️	❌
/var/spool/postfix	E-Mail-Warteschlange	❌	❌	2 GB

Warum /var/spool/cyrus/data?

Die Version 4 von BlueMind nutzte Cyrus-imapd als IMAP-Speicher-Engine. Ab Version 5 wird Cyrus zugunsten einer internen Lösung abgeschafft: Das IMAP-Protokoll wird weiterhin als Zugriffsmodus unterstützt, ebenso wie ActiveSync, MAPI oder CalDAV, jedoch ist es nicht mehr die Komponente, die die Nachrichten speichert.

Um die Migration von Version 4 zu erleichtern und den bei unseren Kunden bereits bestehenden Speicherzuweisungen gerecht zu werden, werden E-Mails weiterhin (außer im Objektspeicher) unter /var/spool/cyrus/data gespeichert.

NFS

Bevorzugen Sie Objektspeicher, um bessere Ergebnisse als bei NFS-Konfigurationen zu erzielen, insbesondere wenn die verwendeten Blockspeicher netzwerkbasiert sind (z. B. Ceph, iSCSI-SAN oder NVMe-oF).

Objektspeicherung

E-Mails können auf einem S3-kompatiblen Objektspeichersystem (oder nativ auf Scality Ring) abgelegt werden. Dies ist die bevorzugte Option, um den PostgreSQL-Server zu entlasten und die Speicherhierarchisierung (RAM / NVMe / mechanische Festplatten) an die Objektschicht statt an das integrierte HSM zu delegieren.

Die am häufigsten mit BlueMind eingesetzten Zielsysteme sind:

System	Zugangswege	Typischer Kontext
Ceph	S3 (RadosGW)	Vor Ort, interne Cluster
Scality Ring	Native Ring-Schnittstelle (sproxyd) oder S3	Vor Ort, große Datenmengen
Scality Artesca	S3	Vorproduktionsumgebungen
Outscale-Objektspeicher	S3	Souveräne Cloud
MinIO	S3	Vor Ort
SeaweedFS	S3	Vor Ort

Jedes dieser Systeme bringt seine eigenen Einschränkungen mit sich (Konsistenz, minimale Blockgröße, Latenz, Verwaltung von Speicherklassen, TLS-Integration, Schlüsselverwaltung, Skalierbarkeit, Verhalten beim Rebalancing …) und ein und dasselbe Backend lässt sich je nach den Anforderungen an die Speicherung unterschiedlich konfigurieren: Ein Cluster, der für das Streaming von Videos mit einer Größe von mehreren GB ausgelegt ist, eignet sich nicht unbedingt am besten für einen E-Mail-Bucket, in dem die meisten Objekte kleiner als 1 MB sind.
Die Auswahl des Backends und dessen Konfiguration müssen daher erfolgen, bevor die Architektur endgültig festgelegt wird.

Bandbreite

Die erforderliche Bandbreite lässt sich nicht ohne Weiteres vorhersagen: Sie hängt hauptsächlich vom E-Mail-Verkehr ab, der wiederum je nach Nutzung und Ereignissen (Newsletter, Massenkommunikation usw.) stark schwankt. Die folgenden Angaben dienen eher dazu, Größenordnungen und einen Analyserahmen aufzuzeigen, als normative Werte vorzugeben.

Beispiel anhand einer realen Anlage

Die nachstehende Grafik zeigt den externen Netzwerkverkehr, der über einen Zeitraum von einer Woche auf einer BlueMind-SaaS-Installation gemessen wurde.

Bitte beachten Sie

Da sich alle Nutzer außerhalb der Infrastruktur befinden, wird ihr Datenverkehr über das Internet geleitet.
Der interne Netzwerkverkehr wird nicht berücksichtigt.
Spam-Verkehr wird zudem bereits im Vorfeld durch eine spezielle Vorrichtung blockiert und erscheint daher nicht im hier gemessenen eingehenden Datenverkehr.

Eingehender/ausgehender Datenverkehr über eine Woche, ausgedrückt in MiB²

Merkmale der gemessenen Installation:

• 10.000 Nutzer (nur E-Mail)
• 2.000 Nutzer der erweiterten Zusammenarbeit
• > 2.000 über EAS verbundene Smartphones
• Verteilung der E-Mail-Clients: 70 % MailApp, 30 % Thunderbird

Das Wichtigste im Überblick:

• Deutliche Asymmetrie: Der ausgehende Datenverkehr (Server → Clients) ist deutlich höher als der eingehende Datenverkehr.
  Dies lässt sich dadurch erklären, dass Nutzer mehr Daten herunterladen als senden (Empfang von E-Mails, Herunterladen von Anhängen usw.). Dabei handelt es sich um übliche Verwendungen.
• Tag-Nacht-Rhythmus: Die Aktivität sinkt nachts und an den Wochenenden fast auf Null und steigt am Morgen dann schlagartig wieder an.
  Auch hierbei handelt es sich um eine klassische Verwendung: Die Benutzer melden sich morgens innerhalb eines begrenzten Zeitfensters an und arbeiten den Tag über.
• Spitzenwerte bei der Datenübertragung von mehreren hundert MiB²/s beim Auslesen.
  Dies ist typisch für Massenversendungen: Eine Mitteilung wird an alle Nutzer versendet.
• Tagesdurchsatz von einigen Dutzend MiB²/s bei der Ausgabe.
  Dies entspricht dem üblichen E-Mail-Aufkommen während der Arbeitszeiten.

Bewährte Verfahren

Auslegung für die Spitzenlast

Ein System muss für seine Spitzenauslastung ausgelegt werden und nicht für den Normalbetrieb oder die durchschnittliche Auslastung.

Wie das obige Beispiel zeigt, weist ein Unternehmens-E-Mail-System charakteristische Spitzenauslastungen auf, die berücksichtigt werden müssen:

• Anmeldungen am Morgen: Die Mehrheit der Benutzer verwendet das gleiche Zeitfenster zu Beginn des Tages und löst die Synchronisierung aller seit dem Vortag eingegangenen Nachrichten aus.

💡 Denken Sie auch an Newsletter und andere Mitteilungen, die an die gesamte Belegschaft versendet werden und somit gleichzeitig in allen Postfächern eintreffen.

• Big-Bang-Migration: Bei einer Umstellung werden alle Server am selben Tag synchronisiert. Doch selbst bei einer ausschließlich aus Webmail bestehenden Benutzerbasis müssen die differentiellen Synchronisierungen initiiert werden: Die E-Mail-Listen der verschiedenen Ordner werden übertragen, auch wenn die Inhalte zu diesem Zeitpunkt noch nicht heruntergeladen werden.

Planung der E-Mail-Speicherkapazität

Das tägliche Volumen der eingehenden E-Mails muss bekannt sein und bei der Dimensionierung der Festplatten berücksichtigt werden, unabhängig von den Benutzerkontingenten.

Die Aufbewahrungsmechanismen (doppelte Papierkorbfunktion, Sicherungen, Archivierung) bewahren eine Kopie der Nachrichten über die Erledigung derselben auf Benutzerseite hinaus auf.

So sind beispielsweise bei 20 GB eingehender E-Mails pro Tag und einer Aufbewahrungsdauer von 30 Tagen mit doppelter Sicherheit mindestens 600 GB einzuplanen, um diesen Datenverkehr aufzunehmen, selbst wenn diese E-Mails noch am selben Tag von ihren Empfängern gelesen und gelöscht werden.

Die maximale Größe von Nachrichten begrenzen

Zur Erinnerung: Bei BlueMind-Installationen sind 80 % der Nachrichten kleiner als 128 KB und 95 % kleiner als 1 MB.

Die für E-Mails konfigurierte maximale Größe wird vom System als Indikator für die Vorreservierung von Speicherplatz verwendet: Das SMTP-Protokoll überträgt die Daten, ohne deren Größe im Voraus anzukündigen, daher muss BlueMind seinen Empfangspuffer auf den höchstzulässigen Wert dimensionieren (vereinfachte Darstellung; der tatsächliche Mechanismus ist komplexer und umfasst einen dedizierten mmap-pool sowie Optimierungen in Abhängigkeit von der Speicherauslastung).

Zudem akzeptieren Dritte, mit denen die Nutzer kommunizieren, in der Regel keine E-Mails mit einer Größe von 100 MB. BlueMind bietet daher die Möglichkeit, Anhänge zu trennen und eine Anbindung an Nextcloud herzustellen, um große Dateien zu teilen (siehe Abschnitt Hosting von Dateien).

Empfehlung: Vermeiden Sie es, mehr als 30 bis 35 MB pro Nachricht zuzulassen. Bei Überschreitung dieser Grenze können sich Nachrichten im Postausgang stauen, was zu Missverständnissen auf Seiten der Nutzer führt (beispielsweise erhalten interne Empfänger die Nachrichten, externe hingegen nicht).

Beispiel für die Dimensionierung

In diesem Abschnitt wird die Anwendung der oben genannten Regeln auf vier konkrete Architekturen erläutert. Die Zahlen sind Richtwerte und sollen anhand von Beobachtungen aus der Praxis angepasst werden: Sie dienen eher als Grundlage für Überlegungen als als verbindliche Vorgaben.

Von der theoretischen Dimensionierung zur betrieblichen Dimensionierung

Die Tabellen auf dieser Seite liefern eine für die Spitzenauslastung berechnete Dimensionierung (siehe oben). Dabei handelt es sich um die theoretische Zieldimensionierung, die eine sichere Inbetriebnahme einer neuen Anlage gewährleistet, ohne deren tatsächliche Auslastung zu kennen.

In der Praxis läuft BlueMind auch auf deutlich weniger leistungsstarken konfigurationen einwandfrei. Sobald man die tatsächliche Auslastung einer Zielinstallation beobachtet (tatsächliches Datenvolumen, Nutzungsmix, zeitliche Verteilung, Verhalten der Clients), können viele theoretische Voraussetzungen gelockert werden, ohne die Benutzererfahrung zu beeinträchtigen.

Nur ein gemeinsam mit unseren Integratoren durchgeführter Test ermöglicht es, genau zu ermitteln, wo und in welcher Höhe diese Spielräume ansetzen sollten: Dies ist der Schritt, der eine theoretische Dimensionierung in eine für den Kundenkontext optimierte operative Dimensionierung umwandelt.

Grundlegende Annahmen

Nutzer

💡 Die Kosten pro Einheit basieren auf dem oben auf dieser Seite erläuterten Prinzip der Einheiten.

Für dieses Beispiel:

Beispielpopulation	Ausgewähltes Profil	Einheiten
TB- oder MailApp-Benutzer mit verbundenem Smartphone	E-Mail + intensive Zusammenarbeit (4 GB)	2
TB- oder MailApp-Benutzer ohne verbundenes Smartphone	Nur E-Mail (2 GB)	1
Outlook-Benutzer mit vollständiger Zusammenarbeit (MAPI 10 GB)	E-Mail + Zusammenarbeit + MAPI (10 GB)	5
Konto mit großem Kontingent (Top 2 %, 50 GB)	E-Mail + Zusammenarbeit + MAPI (50 GB)	25
Wenig genutztes Konto (Service-Konto, Alias, Mitarbeiter ohne Computer...)	≈ 30 % eines „reinen E-Mail-Tarifs“	0,3

Beobachtete Verteilung der Kontingente

Bei bestehenden Installationen lässt sich ein relativ stabiles Quotenhistogramm feststellen:

• ca. 2 % der Postfächer mit einer erweiterten Kontingentierung von 50 GB (Führungskräfte, Archivierung, Kommunikation, spezielle Konten)
• 10 % Kontingent von 10 GB (intensive Zusammenarbeit, typischerweise Outlook MAPI)
• Der Rest liegt zwischen 1 und 2 GB.

Für die folgenden Berechnungen:

• Die 10-GB-Kohorte wird in den Architekturen B und C explizit durch Nutzer mit vollständiger Outlook-Zusammenarbeit repräsentiert und fehlt in Architektur A konstruktionsbedingt (kein MAPI im Einsatz).
• Die 50-GB-Kohorte wird jeder Architektur als 2 % der Gesamtzahl der Rechner hinzugefügt: Sie ist sowohl hinsichtlich der Einheiten (× 25) als auch hinsichtlich der Festplatten (× 50 GB) nicht zu vernachlässigen, selbst wenn keine groß angelegte MAPI-Bereitstellung stattfindet

Die Gewichtung von 0,3 Einheiten für wenig genutzte Rechner istdie unsicherste Annahme in diesem Beispiel: Sie spiegelt die Vorstellung wider, dass diese Rechner nicht ständig verbunden sind (funktionale Rechner, Aliase, Arbeitsplätze ohne dedizierte Workstation). Dies ist in der Regel der Wert, der bei einer vergleichbaren Installation als Erstes neu kalibriert werden sollte.

Mit BlueMind verbundene Smartphones

Die Anbindung des eigenen Mobiltelefons an das geschäftliche E-Mail-System ist eine individuelle Entscheidung (vom Unternehmen bereitgestelltes Diensthandy, BYOD, Recht auf digitale Auszeit). Bei den untersuchten Installationen lässt sich feststellen, dass etwa 30 % der tatsächlichen Nutzer („persönliche“ Postfächer, ohne gemeinsam genutzte Postfächer) ihr Smartphone verbinden.

Architektur A – 20.000 Postfächer, Thunderbird + MailApp

Es handelt sich um eine E-Mail-orientierte Organisation mit leichter Zusammenarbeit, ohne dass MAPI eingesetzt wird.
Die 10-GB-Gruppe fehlt; die 50-GB-Gruppe (2 %) ist weiterhin vorhanden (Archive, spezielle Konten).

Praxisdaten: In der Referenzinstallation verfügen 2.300 von 5.000 Benutzern über ein mit BlueMind verbundenes Smartphone (≈ 46 %); die übrigen 2.700 greifen ausschließlich über Webmail oder einen IMAP-Client auf ihr Postfach zu:

Bevölkerung	Personalbestand	Einheiten/Profil	Gesamtzahl der Einheiten
TB- oder MailApp-Nutzer mit Smartphone (4 GB)	2 300	2	4 600
TB- oder MailApp-Nutzer ohne Smartphone (2 GB)	2 700	1	2 700
Konten mit großem Datenvolumen (Top 2 %, 50 GB)	400	25	10 000
Postfächer mit geringer Aktivität	14 600	0,3	4 380
Gesamt	20 000		21.680 Einheiten

Anwendung der Tabellen:

• CPU: ab 6.000 Einheiten: 2 Kerne pro 1.000 Einheiten ⇒ ~ 44 Zen-4-Referenzkerne (~ 36 Kerne bei einem Xeon Gold 6542Y oder ~ 34 Kerne bei einem EPYC 9755).
  Siehe: Äquivalenzen zwischen CPU-Generationen
• RAM: Stufe 10.000+ Einheiten ⇒ 96 GB pro Knoten, ausgelagerte Elasticsearch-Instanz erforderlich.
• E-Mail-Volumen (theoretisches Maximum bei Kontingenten): 2.300 × 4 GB + 2.700 × 2 GB + 400 × 50 GB + 14.600 × 2 GB = ≈ 64 TB ⇒ Planen Sie 19–32 TB nutzbaren Speicher ein, da die Auslastung in der Regel bei 30 bis 50 % liegt.
  Hinweis: Bei Objektspeicher befindet sich dieses Volume im Bucket (siehe „Zugehöriger Objektspeicher“ weiter unten); bei lokalem Speicher würde es den Pfad /var/spool/cyrus/data belegen.
• /var/lib/postgresql: ~5 % des E-Mail-Volumens ⇒ 1,0–1,6 TB.
• /var/spool/bm-elasticsearch: ~10 % des E-Mail-Volumens ⇒ 1,9–3,2 TB.

Vorschlag zur Aufteilung in VMs (E-Mails im Objektspeicher):

VM / Rolle	vCPU	RAM	Lokale Speicherung
BlueMind-Kern	20	96 GB	200 GB NVMe (Betriebssystem, /var/log, /var/spool/bm-mail, /var/spool/bm-mapi, /tmp, Caches)
PostgreSQL (Datenbank bj-data)	16	40 GB	2,1 TB NVMe für /var/lib/postgresql (≈ 2 TB, Betriebssystem/Protokolle ≈ 0,1 TB – E-Mail-Blobs sind separat)
Elasticsearch	8	32 GB	4 TB NVMe für /var/spool/bm-elasticsearch
Gesamt	44	168 GB	≈ 6,3 TB

Referenz³

Speicherung des zugehörigen Objekts:

Volumen / Bucket	Geschätztes Volumen	Beschreibung
E-Mail-Ablage	19–32 TB	Nachrichtenspeicher, auf den BlueMind über S3 zugreift

B-Architektur — 8.000 Postfächer, Outlook-MAPI-Umgebung

Eine vollständig auf Zusammenarbeit ausgerichtete Outlook-Organisation (10-GB-Kontingent) mit zusätzlichen Funktionspostfächern und dem üblichen 50-GB-Kontingent.

Bevölkerung	Personalbestand	Einheiten/Profil	Gesamtzahl der Einheiten
Outlook mit vollständiger Zusammenarbeit (MAPI)	5 000	5	25 000
Konten mit großem Datenvolumen (Top 2 %, 50 GB)	160	25	4 000
Funktions-/Serviceboxen	2 840	0,3	852
Gesamt	8 000		29.852 Einheiten

Mit BlueMind verbundene Smartphones: 30 % der Nutzer (siehe oben), d. h. ca. 1.550 Smartphones auf dieser Architektur (≈ 1.240 EAS + 310 einfache IMAP-Zugänge).

Anwendung der Tabellen:

• CPU: 29.852 Einheiten ⇒ ~60 Zen-4-Referenzkerne (~49 bei einem Xeon Gold 6542Y, ~46 bei einem EPYC 9755).
• RAM: Stufe 10.000+ Einheiten ⇒ 96 GB pro Knoten, ausgelagerte Elasticsearch-Instanz erforderlich.
• E-Mail-Volumen (theoretisches Maximum bei Kontingenten): 5.000 × 10 GB + 160 × 50 GB + 2.840 × 2 GB ≈ max. 64 TB ⇒ realistisch 20–32 TB.
  Bei Objektspeicher befindet sich dieses Volume im Bucket (siehe „Zugehöriger Objektspeicher“ weiter unten); bei lokalem Speicher würde es den Speicherort /var/spool/cyrus/data belegen.
• /var/lib/postgresql: ~5 % des E-Mail-Volumens ⇒ 1,0–1,6 TB.
• /var/spool/bm-elasticsearch: ~10 % des E-Mail-Volumens ⇒ 2,0–3,2 TB.
• DataProtect-Sicherung: E-Mail-Volumen > 1 TB → Deaktivieren Sie DataProtect für E-Mails dieses Volumens und wechseln Sie zu einer Sicherungsstrategie eines Drittanbieters + doppeltem Papierkorb.

Vorschlag zur Aufteilung in VMs (E-Mails im Objektspeicher):

VM / Rolle	vCPU	RAM	Lokale Speicherung
BlueMind-Kern	28	96 GB	200 GB NVMe (Betriebssystem, /var/log, /var/spool/bm-mail, /var/spool/bm-mapi, /tmp, Caches)
PostgreSQL (Datenbank bj-data)	20	48 GB	2,1 TB NVMe für /var/lib/postgresql (≈ 2 TB, Betriebssystem/Protokolle ≈ 0,1 TB – E-Mail-Blobs sind separat)
Elasticsearch	12	48 GB	4 TB NVMe für /var/spool/bm-elasticsearch
Gesamt	60	192 GB	≈ 6,3 TB

Referenz³

Speicherung des zugehörigen Objekts:

Volumen / Bucket	Geschätztes Volumen	Beschreibung
E-Mail-Ablage	20–32 TB	Nachrichtenspeicher, auf den BlueMind über S3 zugreift

In diesem Maßstab sollten die Rollen aufgeteilt werden, um die Größe der VMs in einem angemessenen Rahmen zu halten

Bei 29.852 Einheiten (~60 Zen-4-Kerne) würde eine einzige VM, die Rechenkerne, PostgreSQL und Elasticsearch vereint, die von den Hypervisoren empfohlenen VM-Größen (typischerweise ~8 vCPU) bei weitem überschreiten. Bei der Dimensionierung müssen daher rechenintensive Rollen getrennt werden: ein dedizierter Elasticsearch-Server und ein dedizierter PostgreSQL-Server, wodurch jede VM wieder eine angemessene Größe erhält.

Sofern möglich, sorgt die Platzierung von ES und/oder der PostgreSQL-VM auf separaten Hypervisoren (und separaten Netzwerkkarten) für zusätzliche Ausfallsicherheit im Falle eines Host-Ausfalls.

Der PostgreSQL-Server hostet die Datenbank bj-data, die den Großteil der BlueMind-Tabellen im Zusammenhang mit dem E-Mail-Verkehr enthält.
Bei der Objektspeicherung werden die E-Mail-Blobs in den Bucket ausgelagert, wodurch die PostgreSQL-VM deutlich schlanker wird: In diesem Zusammenhang lässt sich die Trennung vom Kern am einfachsten umsetzen (die obige Aufschlüsselungstabelle veranschaulicht dies: 16–20 vCPU, 40–48 GB, ~2 TB /var/lib/postgresql, und das war’s).
Im lokalen Speicher hingegen werden PostgreSQL und das Dateisystem für E-Mails unter /var/spool/cyrus/data auf demselben Rechner belassen: Eine Auslagerung von PostgreSQL würde dazu führen, dass jeder Zugriff auf eine Nachricht einen zusätzlichen Netzwerksprung zwischen der Datenbank und den Blobs erfordern würde, was mit Leistungseinbußen verbunden wäre, die den Nutzen einer separaten VM überwiegen. Im großen Maßstab hostet derselbe Rechner somit sowohl die Datenbank als auch die Blobs und bündelt den Großteil der E/A-Vorgänge; ihm wird die entsprechende Hardware (schnelles NVMe, hohe E/A-Leistung, RAM) zugewiesen, anstatt die Funktion aufzuteilen.

C-Architektur — 1.000 Postfächer, kleiner Outlook-MAPI-Bestand

Kleine MAPI-Organisation mit einem hohen Anteil an freigegebenen Postfächern, Mitarbeitern ohne festen Arbeitsplatz und der üblichen 50-GB-Kontingentierung, die auf wenige Konten reduziert wurde.

Bevölkerung	Personalbestand	Einheiten/Profil	Gesamtzahl der Einheiten
Outlook mit vollständiger Zusammenarbeit (MAPI)	500	5	2 500
Konten mit großem Datenvolumen (Top 2 %, 50 GB)	20	25	500
Gemeinsame Postfächer / Mitarbeiter ohne Bildschirm	480	0,3	144
Gesamt	1 000		3.144 Einheiten

Mit BlueMind verbundene Smartphones: 30 % der Nutzer (siehe oben), d. h. ~155 Smartphones (≈ 125 EAS + 30 einfache IMAP-Konten).

Anwendung der Tabellen:

• CPU: Bereich 3.000–6.000 Einheiten ⇒ 12 Zen-4-Referenzkerne (~ 10 Kerne bei einem 6542Y, ~ 9 Kerne bei einem 9755).
• RAM: 2.500–5.000 Einheiten ⇒ 48 GB.
• /var/spool/cyrus/data: 500 × 10 GB + 20 × 50 GB + 480 × 2 GB ≈ 7 TB max. ⇒ 2–3,5 TB realistisch.
• /var/lib/postgresql: ~5 % ⇒ ~0,1–0,2 TB.
• /var/spool/bm-elasticsearch: ~10 % ⇒ ~0,2–0,4 TB.

Vorschlag zur Aufteilung in VMs (eine VM, lokaler Speicher):

VM / Rolle	vCPU	RAM	Lokale Speicherung
Einzelne BlueMind-VM	12	48 GB	5 TB NVMe (/var/spool/cyrus/data ≈ 3,5 TB, bm-elasticsearch ≈ 0,4 TB, postgresql ≈ 0,2 TB, Betriebssystem / Protokolle / Sonstiges ≈ 1 TB)

Referenz³

Die C-Architektur lässt sich problemlos auf einer einzigen VM betreiben, die auf dem vom Hypervisor bereitgestellten Speicher basiert: In diesem Umfang sind die zusätzlichen Betriebskosten eines Multi-Server-Clusters oder eines Objekt-Backends nicht gerechtfertigt.

Architektur D — 3.000 Thunderbird-Postfächer, Einzel-VM

Diese Architektur veranschaulicht eine Organisation mit 3.000 Thunderbird-Benutzern, wobei jeder ein Smartphone (EAS oder IMAP) besitzt, mit einer einheitlichen Speicherkontingent von 10 GB pro Postfach, ohne MAPI und ohne Objektspeicherung — wobei das Ziel darin besteht, alles auf einer einzigen VM unterzubringen, die auf dem vom Hypervisor bereitgestellten Speicher basiert.

Bevölkerung	Personalbestand	Einheiten/Profil	Gesamtzahl der Einheiten
Thunderbird + Smartphone (10 GB)	3 000	2	6 000
Gesamt	3 000		6.000 Stück

Bei 10 GB pro Postfach ohne MAPI gehen wir von 2 Einheiten pro Benutzer aus: Dies ist die untere Grenze der Schätzung, da IMAP/EAS den Server bei gleicher Kontingentierung deutlich weniger belastet als MAPI. Bei sehr intensiver Nutzung (große Mengen an Anhängen, die mit dem Smartphone synchronisiert werden, häufige Volltextsuchen) ist es ratsam, 2,5 bis 3 Einheiten anzustreben, was dazu führen würde, Elasticsearch auf einen dedizierten Server zu verlagern.

Anwendung der Tabellen:

• CPU: 6.000 Einheiten ⇒ 12 Zen-4-Referenzkerne (~ 10 Kerne bei einem Xeon Gold 6542Y, ~ 9 Kerne bei einem EPYC 9755) — verfügbar auf einem einzigen modernen Sockel.
• RAM: Die Tabelle gibt 5.000–10.000 Einheiten bei 64 GB mit ausgelagertem ES an. Um Elasticsearch auf derselben VM zu hosten, sollten Sie 96 GB einplanen, damit der Heap ohne Speicherengpässe untergebracht werden kann.
• /var/spool/cyrus/data: 3.000 × 10 GB = max. 30 TB ⇒ realistisch 9–15 TB (30–50 % Auslastung), vollständig auf den vom Hypervisor bereitgestellten Speicher (vSAN, VMFS-Datenspeicher, leistungsstarkes NFS...) adressierbar.
• /var/lib/postgresql: ~5 % ⇒ 0,5–0,8 TB.
• /var/spool/bm-elasticsearch: ~10 % ⇒ 0,9–1,5 TB.

Vorschlag zur Aufteilung in VMs (eine VM, lokaler Speicher):

VM / Rolle	vCPU	RAM	Lokale Speicherung
Einzelne BlueMind-VM	12	96 GB	18 TB NVMe (/var/spool/cyrus/data ≈ 15 TB, bm-elasticsearch ≈ 1,5 TB, postgresql ≈ 0,8 TB, Betriebssystem / Protokolle / Sonstiges ≈ 1 TB)

Referenz³

Diese Architektur läuft sehr gut auf einem VMware vSphere-Hypervisor: eine einzelne VM mit 12 vCPUs + 96 GB, die auf dem vom Hypervisor bereitgestellten Speicher (vSAN, SAN-Datenspeicher, leistungsstarkes NFS…) basiert, sowie vMotion, um die VM während Wartungsarbeiten im laufenden Betrieb ohne Unterbrechung für die Benutzer zwischen Hosts zu verschieben. Um die von bestimmten HA-Optionen (typischerweise VMware Fault Tolerance) auferlegte Obergrenze von 8 vCPU einzuhalten, wird Elasticsearch in einer alternativen Architektur ausgelagert: Haupt-VM mit 8 vCPU + 64 GB und ES-VM mit 4 vCPU + 32 GB (siehe Kasten „Warum sollte man bm-elasticsearch auslagern?“).

Hohe Verfügbarkeit

Bei den oben beschriebenen Architekturen wird die Hochverfügbarkeit hauptsächlich durch die Hypervisor-Ebene und die darunter liegenden Speicherkomponenten gewährleistet, ohne dass auf Seiten von BlueMind eine spezielle Konfiguration erforderlich ist:

• VMware vSphere: vMotion verschiebt VMs im laufenden Betrieb zwischen Hosts für Wartungsarbeiten (ohne Unterbrechung für die Benutzer); vSphere HA startet eine VM im Falle eines Knotenausfalls automatisch auf einem anderen Host neu, wobei es während des Neustarts zu einer kurzen Unterbrechung kommt.
• Proxmox + Ceph: Die Multi-Knoten-Replikation von Ceph schützt die Datenblöcke, und die Live-Migration von Proxmox ermöglicht die Hot-Migration von VMs zwischen den Hosts des Clusters.
• Proxmox + lokales ZFS: Snapshots und die asynchrone ZFS-Replikation auf einen sekundären Knoten decken den Ausfall eines Hosts mit einem RPO von wenigen Minuten ab, wobei die Latenz einer lokalen Festplatte beibehalten wird.

Dieses Basispaket deckt die häufigsten Ausfälle (Ausfall eines Hosts, geplante Wartungsarbeiten) ab, wobei die RPO und RTO im Bereich von einigen Sekunden bis zu einigen Minuten liegen.

Eine Erweiterung (synchrone Replikation von BlueMind-Instanzen oder standortübergreifendes Anwendungs-Failover) ist möglich, jedoch hängt jede verlustfreie synchrone Replikation von der zugrunde liegenden Netzwerkinfrastruktur ab. Die Latenz bei standortübergreifenden Schreibvorgängen kommt zu den synchronen Schreibvorgängen von PostgreSQL und der E-Mail-Datenbank hinzu und kann die wahrgenommene Leistung erheblich beeinträchtigen, sobald die Standorte weit voneinander entfernt sind oder die Latenz einige Millisekunden überschreitet.

Die Wahl eines HA-Konzepts ist somit ein Kompromiss zwischen zwei Aspekten:

• Art der verbundenen Clients:
  • Outlook (MAPI) verträgt asynchrone Replikationen nur schlecht, da diese im Falle eines abrupten Ausfalls als Rückschritt in der Zeit angesehen werden. Dies kann zu aufwendigen Neusynchronisierungen, Duplikaten oder fehlenden Elementen führen.
  • Die MailApp- und ActiveSync-Clients stellen die Verbindung flexibler wieder her und reagieren besser auf kurze Unterbrechungen oder IP-Wechsel.
• Erforderliche RPO- und RTO-Werte:
  • Ein RPO von wenigen Minuten (asynchrone Replikation) deckt die meisten geschäftlichen Anforderungen ab, ohne die Leistung zu beeinträchtigen.
  • Ein RPO nahe Null erfordert eine synchrone Replikation und damit hohe Anforderungen an das Netzwerk (Latenz unter einer Millisekunde zwischen den Standorten, Redundanz der Verbindungen, für die E/A-Spitzenlast ausgelegte Bandbreite).

Dies ist ein Thema, das je nach Kundenkontext mit unseren Systemintegratoren besprochen werden sollte: Standorte, verfügbare Latenz zwischen den Standorten, Kundenmix, vertragliche RPO-/RTO-Anforderungen...

Unter realen Bedingungen zu kalibrieren

Die oben genannten Zahlen basieren auf den Tabellen ohne Korrekturen. Die folgenden Punkte sollten vorrangig mit den tatsächlichen Gegebenheiten abgeglichen werden:

• Kosten für wenig genutzte Benutzerkonten (0,3 Einheiten angenommen): Diese sind unter Berücksichtigung des Verhältnisses „gleichzeitige Sitzungen / geöffnete Benutzerkonten“ bei einer vergleichbaren Installation neu zu berechnen. Je nach Nutzungsgewohnheiten (Vorhandensein oder Fehlen eines mobilen Clients, Häufigkeit der Zugriffe usw.) kann die realistische Spanne zwischen 0,1 und 0,5 liegen.
• Anteil der 50-GB-Kohorte (2 % zurückbehalten): Je nach Archivierungsrichtlinie und dem Vorhandensein oder Fehlen von „Ausnahme“-Konten (Rechtsabteilung, Personalwesen, Geschäftsleitung) kann dieser Anteil zwischen 0,5 % und 5 % variieren. Dies kann sich sowohl auf die Anzahl der Einheiten (× 25) als auch auf den Festplattenspeicher (× 50 GB pro Konto) erheblich auswirken.
• Anteil der Nutzer mit verbundenem Smartphone: 46 % für A angenommen (kalibriert anhand einer bestehenden Installation: 2.300 / 5.000), ~30 % für B und C (bezogen auf die Gesamtbevölkerung, ohne funktionale Einheiten), 100 % für D (explizite Annahme: ein Telefon pro Person). Diese Angabe kann von Organisation zu Organisation stark variieren, und da jeder Nutzer zwischen 1 Einheit (ohne) und 2 Einheiten (mit) wechselt, ist der Koeffizient daher empfindlich.
• Tatsächliche Quoten vs. theoretische Quoten: Die E-Mail-Volumen werden auf Basis der maximalen Quote berechnet; die tatsächliche Auslastung liegt jedoch eher bei 30–50 %.
• Morgendliche Spitzenlast: Die Dimensionierung muss die gleichzeitigen Zugänge zwischen 8 und 9 Uhr sowie die Massenübertragungen abdecken, nicht den Tagesdurchschnitt (siehe Bewährte Verfahren > Dimensionierung für Spitzenlasten).
• Mehrserver-Architektur: Bei mehr als 6.000 bis 10.000 Einheiten ist die Trennung ressourcenintensiver Rollen (dediziertes Elasticsearch, dediziertes PostgreSQL) sinnvoller als eine einzige große VM. Die Trennung von PostgreSQL ist bei Objektspeicher am einfachsten: Die Datenbank ist dann schlank (ohne lokale Blobs). Bei lokalem Speicher hingegen werden PostgreSQL und das E-Mail-Dateisystem auf demselben Rechner belassen, um bei jedem Zugriff auf die Blobs einen kostspieligen Netzwerksprung zu vermeiden.

Weiterführende Informationen

Lesen Sie die BlueMind-Dokumentation in Verbindung mit

• S3-Speicher
• Voraussetzungen für die Installation

Footnotes

1. IOPS: "In/Out per second", d.h. "Eingabe/Ausgabe pro Sekunde". ↩

2. MiB: Die Einheit MiB (MebiByte) ist ein Vielfaches von Byte (Byte) und unterscheidet sich von MB (Megabyte, oder MB Megabyte): Sie entspricht 1024 Kebibyte, was wiederum 1024 Byte (Byte) entspricht. So entsprechen 9 MiB 9,43718 MB (MB). ↩ ↩² ↩³

3. vCPUs, ausgedrückt in Kernen Zen 4 9654 (Referenz) (siehe Äquivalenzen zwischen CPU-Generationen); Speicher abgestimmt auf Samsung PM1733 NVMe im Direktanschluss — Virtualisierungsschichten und Netzwerkspeicher verursachen zusätzliche Latenz, die größtenteils vom Puffer /var/mmap-pool aufgefangen wird (siehe Mindestanforderungen an Festplattenleistung und Speicherkapazität). ↩ ↩² ↩³ ↩⁴