Materielle Dimensionierung
Die hier angegebenen Daten sind unverbindlich. In der Tat kann die Nutzung einer gleichen Anzahl von Nutzern je nach Struktur und Gewohnheiten sehr unterschiedlich sein. Die Anzahl der E-Mails, deren Größe, die Anzahl der Empfänger in den E-Mails, die Anzahl der Termine, der Terminplanung... all dies pro Tag ist sehr unterschiedlich.
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 nur die E-Mail-Funktion nutzt, das System nicht in gleicher Weise belastet wie ein Benutzer, der sowohl die E-Mail-Funktion als auch die Tools für die Zusammenarbeit (Kalender usw.) nutzt, oder wie ein Benutzer, der MAPI 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.
Ebenso wird bei gleicher Anzahl von Einheiten eine reine E-Mail-Nutzung nicht den gleichen Ressourcenverbrauch haben wie eine Nutzung von E-Mail + Zusammenarbeit (für die Hälfte der Nutzer). E-Mail ist z.B. stärker von IO als von CPU abhängig, was bei kollaborativen Tools im Allgemeinen nicht der Fall ist.
CPU
Wir sprechen von der Anzahl der Herzen. Als Referenz für die folgenden Berechnungen dient ein Zen-4-Kern eines AMD EPYC 9654 (Genoa, 5 nm, erschienen Ende 2022): Es handelt sich um eine aktuelle CPU, die weit verbreitet ist und vom Hersteller noch mehrere Jahre lang unterstützt werden wird.
Die ausgewählte CPU muss nämlich vom Hersteller über die gesamte geplante Laufzeit des Messaging-Vertrags hinweg unterstützt werden: Bei einer auf 5 Jahre angelegten Installation sollten Sie eine CPU bevorzugen, deren Herstellersupport diesen gesamten Zeitraum abdeckt. Ein gutes ergänzendes Kriterium ist das Leistungs-Watt-Verhältnis, bei dem neuere Architekturen (≤ 5 nm) gegenüber früheren Generationen (14/10 nm) deutlich im Vorteil sind.
Äquivalenzen zwischen CPU-Generationen
Die Tabelle „Einheiten → Anzahl der Kerne“ weiter unten ist in Zen 4 9654-äquivalenten vCPUs 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 Näherungswert 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 |
Ergebnisse gemessen mit Geekbench Browser. Leistungsbedarf in Watt = (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 Kennzahlen dienen lediglich als Richtwerte: 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 vorzuziehen.
In einem Virtualisierungscluster stellen die Hypervisoren den virtuellen Maschinen in der Regel die Kapazitäten der CPU mit der geringsten Auslastung im Cluster zur Verfügung, um die Verlagerung der VMs zwischen den Knoten zu ermöglichen. BlueMind nutzt die modernen Funktionen der CPUs entsprechend den Kapazitäten, die den virtuellen Maschinen tatsächlich zur Verfügung gestellt werden: Eine moderne CPU, die mit einem veralteten Profil bereitgestellt wird, kann ihre tatsächliche Leistung nicht entfalten.
Von BlueMind unterstützte Befehlssätze
Über die Anzahl der Kerne und deren Taktfrequenz hinaus nutzt BlueMind mehrere Hardware-Befehlssätze für Vorgänge, die auf einem E-Mail-Server sehr häufig vorkommen. Ihre Anwesenheit ist in den Flags von /proc/cpuinfo (oder auf einer VM in den vom Hypervisor tatsächlich bereitgestellten Flags — siehe Kasten oben) ersichtlich:
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 Lesen von E-Mail-Anhängen verwendet, ein Vorgang, der immer dann stattfindet, wenn ein Benutzer seine Nachrichten abruft.
Eine neuere CPU, die in einer VM mit einem veralteten Profil betrieben wird (beispielsweise 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.
Zu beachten ist, dass die Zuweisung zu vieler CPUs zu anderen Problemen in virtualisierten Umgebungen 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
bm-elasticsearch auslagern?Die Auslagerung von ElasticSearch auf eine eigene VM trägt mehreren Anliegen Rechnung:
- Mit dem Hypervisor und dessen Optionen kompatible VM-Größe.
Bestimmte Funktionen des Hypervisors sehen eine Obergrenze für die Anzahl der vCPUs pro VM vor — So ist beispielsweise bei VMware Fault Tolerance die Anzahl der vCPUs pro geschützter VM auf 8 begrenzt (Broadcom-Dokumentation). Durch das Auslagern von ES können die Haupt-VM und die ES-VM unter diesen Schwellenwerten gehalten werden. - In einem NUMA-Knoten bleiben.
Ab einer bestimmten Größe passt eine VM nicht mehr in einen NUMA-Knoten, und die CPU-/Speicherplanung wird weniger effizient. 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. - Ressourcen zwischen Elasticsearch und dem restlichen BlueMind aufteilen.
Mit einer dedizierten VM vermischen sich der Elasticsearch-Heap, sein Dateicache und seine Indizierungs-E/A-Vorgänge 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 freigegeben und die Last kann auf den Virtualisierungspool verteilt werden.
Die Kehrseite: Eine oder mehrere zusätzliche VMs für ES führen zu einer höheren Komplexität und einem gewissen Mehraufwand: — – 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 Überwindung des physischen Netzwerks bei jeder Indizierungs- oder Suchanfrage. Falls diese Einschränkungen nicht zutreffen, kann eine einzige, angemessen dimensionierte VM ausreichen.
Lagerung / IO
Art der Disks
Ein Messaging-System beansprucht die Festplatten stark, sowohl beim Lesen und Schreiben kleiner Dateien als auch bei allen Verarbeitungsvorgängen im Zusammenhang mit den Nachrichten (Indizierung, Lesestatus usw.). Die Qualität und Geschwindigkeit der Festplatten sind entscheidend für eine leistungsstarke E-Mail-Kommunikation.
Die Verwendung von SSD-/NVMe-Festplatten ist bei einer Neuinstallation zwingend erforderlich und wird auch bei einem Update 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 der Software nicht kompatibel sind. Diese können gegebenenfalls für Backups oder im hierarchischen Speichersystem hinter leistungsstarken SSDs/NVMe-Laufwerken eingesetzt werden.
Speichervirtualisierung
Virtualisierte oder verteilte Speichersysteme — wie Ceph, vSAN, iSCSI- oder NVMe-over-Fibre-SAN sowie NFS auf Remote-Speicher — fügen mehrere Schichten (Netzwerk, Replikation, Abstraktion) zwischen der BlueMind-VM und den physischen Festplatten ein. Jede dieser Ebenen führt zu einer zusätzlichen Latenz, die sich bei den vielen kleinen E/A-Vorgängen, die für Messaging-Anwendungen charakteristisch sind, summiert.
Zu beachtende Punkte:
- Latenz: Die Anforderungen variieren je nach Datenvolumen. Für
/var/lib/postgresql(transaktionale Datenbank, WAL-Synchronisation) sollten Sie bei synchronen Schreibvorgängen einen Wert von < 1 ms anstreben ; : Ab einer Dauer von mehr als einigen Millisekunden leidet die Leistung des gesamten Nachrichtenaustauschs. Für/var/spool/cyrus/dataund die anderen E/A-Volumes sollten die IOPS unter 10 ms bleiben. Die synchrone Replikation eines verteilten Clusters verursacht bei jedem Schreibvorgang automatisch zusätzliche Netzwerk-Hin- und Rückläufe, die sich bei jeder dieser Anforderungen summieren. - Blockgröße: Bei BlueMind-Installationen lässt sich in der Regel feststellen, dass 80 % der E-Mails weniger als 128 KB und 95 % weniger als 1 MB groß sind. Überdimensionierte Blockgrößen — 4-MB-Blöcke auf der Ceph-Seite,
DiskMaxIOSizeauf 1 MB auf der VMware-Seite usw. — verstärken jeden IO-Vorgang unnötig und beeinträchtigen die Leistung, insbesondere bei der PostgreSQL-Datenbank, die mit 8-KB-Seiten arbeitet. - Nennleistung vs. tatsächliche Leistung: Die vom Array angegebenen IOPS entsprechen nicht den Werten, die der VM tatsächlich zur Verfügung stehen, sobald der Cache ausgelastet ist oder andere Lasten auf dem Cluster vorhanden sind.
- 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 des Netzwerkverkehrs: Der für den Zugriff auf den Speicher verwendete Netzwerkverkehr muss vom Benutzerverkehr getrennt werden. Das Herunterladen eines großen Anhangs durch einen Outlook-Kunden darf keinen Einfluss auf die Leistung von SQL-Abfragen oder auf Schreibvorgänge im E-Mail-Volumen haben. Es ist üblich, dem Speicher eigene Schnittstellen und/oder separate VLANs zuzuweisen.
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.
Das Zurücksetzen der BlueMind-Instanz auf einen früheren Hypervisor- oder ZFS-Snapshot hat Auswirkungen auf bereits konfigurierte Clients:
- MAPI-Clients (Outlook): Der Status auf Client- und Serverseite gerät aus dem Gleichgewicht, was zu Duplikaten, fehlenden Elementen oder einer vollständigen Neusynchronisierung des Postfachs führen kann.
- Mobile Apps / MailApp: Objekt-IDs (UIDs, Sync-Schlüssel) lassen sich zurückverfolgen; Kunden können Änderungen rückgängig machen oder überspringen.
Um auf Kundenseite eine konsistente Wiederherstellung zu gewährleisten, sollten Sie 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 der Erstellung des Snapshots von BlueMind unterbrochen (während des Zeitfensters dürfen keine MAPI-, Mobil- oder Webmail-Clients aktiv sein);
- Die Snapshots sind auf allen VMs der Infrastruktur atomar, um eine konsistente Wiederherstellung über alle Dienste hinweg zu gewährleisten.
Mindestleistung und -volumen der Festplatten
Die Dimensionierung des Speichers erfolgt anhand von zwei Kriterien: den IOPS1 und der Latenz. Ein Messaging-Dienst ist ein großer IO-Verbraucher.
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 und die Konfiguration dieser Komponenten für den Einsatz im E-Mail-Verkehr den entscheidenden Unterschied aus (siehe Abschnitt Speichervirtualisierung).
Diese Asymmetrie wird von BlueMind v5 explizit über einen speziellen E/A-Puffer berücksichtigt, der unter /var/mmap-pool eingebunden ist (siehe entsprechende Zeile in der nachstehenden Tabelle der Einhängepunkte). Er hält so viele Daten wie möglich im Speicher vor, und 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 — wodurch die Software gegenüber virtualisierten oder netzwerkbasierten Speichersystemen (vSAN, Ceph, NFS, iSCSI-SAN oder NVMe-oF) deutlich fehlertoleranter ist als ein IO-naiver Dienst. Dieser Mechanismus bringt zudem die Anforderungen an die Leistungsfähigkeit von E-Mail-Systemen mit den Anforderungen an hohe Verfügbarkeit in Einklang, die fast immer eine virtualisierte Speicherung erfordern.
Der Speicherplatz hängt hingegen direkt von den Anforderungen des Kunden ab (Kontingente usw.).
Je nach Endnutzung müssen nicht alle Laufwerke die gleiche Leistung oder das gleiche Volumen haben.
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.
Montagepunkt | Beschreibung | Typ NFS | Typ Object Storage S3/Scality Ring | Minimale Volumetrie |
|---|---|---|---|---|
/var/spool/cyrus/data | Speicherplatz für E-Mails | ❌ | ✅ | Der größte Speicherplatz, der entsprechend dem erwarteten E-Mail-Volumen festgelegt wird. |
/var/spool/bm-hsm | Aus Version 4 übernommen. Speicherort für sekundäre Speicherung von E-Mails; der Code bleibt vorhanden, um die Kompatibilität bei Migrationen von Version 4 → auf Version 5 zu gewährleisten. Bei einer Neuinstallation der Version 5 sollten Sie das integrierte HSM nicht aktivieren: BlueMind empfiehlt, die Speicherhierarchie auf Anwendungsebene zu verwalten, entweder als Objektspeicher (wo die Hierarchie auf Bucket-Ebene konfiguriert werden kann) oder indem die Verwaltung eines RAM-/NVMe-/mechanischen Festplatten-Pools den erfahrenen Speicherteams überlassen wird. | ⚠️ | ❌ | |
/var/lib/postgresql | PostgreSQL-Datenbank | ❌ | ❌ | 5% des Volumens von |
/var/spool/bm-elasticsearch | ElasticSearch Indexdaten | ❌ | ❌ | 10% des Volumens von |
/var/spool/bm-mail | Versenden von E-Mails über EAS/mapi | ❌ | ❌ | 2 GB |
/var/backups/bluemind | DataProtect-Backups | ✅ | ❌ | Summe aus: |
/var/spool/bm-mapi | Temporäre Verzeichnisse des Dienstes bm-mapi | ❌ | ❌ | 2 GB |
/var/lib/keydb | KeyDB/Redis-Datenbank (interner Cache, ersetzt | ❌ | ❌ | Mindestens 2 GB, anzupassen je nach Anzahl der gleichzeitigen Sitzungen und der Größe des Verzeichnisses (einschließlich Fotos und S/MIME-Zertifikate). |
/var/lib/influxdb | InfluxDB-Datenbank (Überwachungsmetriken) | ❌ | ❌ | 5 GB, proportional zur Anzahl der Benutzer (bestimmte MAPI- und IMAP-Metriken werden pro Benutzer erfasst). |
/var/mmap-pool | IO-Puffer von BlueMind, der entwickelt wurde, um die Diskrepanz zwischen den Anforderungen der Software (kleine, häufige IO-Vorgänge mit geringer Latenz) und den Einschränkungen virtualisierter oder netzwerkbasierter Speichersysteme auszugleichen. Es werden so viele Daten wie möglich im Arbeitsspeicher gehalten; wenn ein Schreibvorgang auf die Festplatte erforderlich wird, bündelt es die Vorgänge in große Blöcke, die von den zugrunde liegenden Schichten (vSAN, Ceph, NFS, iSCSI-SAN oder NVMe-oF) besser verarbeitet werden können. Der Speicherplatz wird auf der Festplatte reserviert, doch die eigentlichen Schreibvorgänge werden erst in Abhängigkeit von der Speicherauslastung des Systems ausgelöst. | ❌ | ❌ | 20 GB |
/var/spool/bm-docs | Speichern von Miniaturansichten von Benutzern, Ressourcen... | ❌ | ❌ | 1 MB pro Einheit mit Miniaturbild |
/var/spool/postfix | E-Mail-Warteschlange | ❌ | ❌ | 2 GB |
/var/log | System- und Anwendungsprotokolle | ❌ | ❌ | 50 GB |
/tmp | Temporäre Dateien | ❌ | ❌ | Für die Installation von BlueMind ist ein Volumen von 1,2 GB erforderlich. Dies bezieht sich auf das Dekomprimieren des Installers. |
/usr | ❌ | ❌ | Für die Speicherung der Module und Webanwendungen sind 8 GB erforderlich. |
/var/spool/cyrus/data?BlueMind v4 nutzte cyrus-imapd als IMAP-Speicher-Engine. Ab Version 5 wird Cyrus zugunsten einer internen BlueMind-Lösung abgeschafft; das IMAP-Protokoll wird weiterhin als Zugriffsmodus unterstützt, ebenso wie ActiveSync, MAPI oder CalDAV, doch es ist nicht mehr die Komponente, die die Nachrichten speichert.
Um die Migration von Version 4 zu vereinfachen und den bei unseren Kunden bereits bestehenden Speicherzuweisungen gerecht zu werden, werden E-Mails weiterhin (abgesehen vom Objektspeicher) unter /var/spool/cyrus/data gespeichert. Der Pfad bleibt erhalten; die Software „Cyrus“ wird hingegen nicht mehr verwendet.
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 von BlueMind v5 können auf einem S3-kompatiblen Objektspeichersystem (oder nativ auf Scality Ring) gespeichert werden. Dies ist die bevorzugte Option, sobald Sie den PostgreSQL-Server — entlasten möchten, auf dem die Datenbank bj-data und der Großteil der mit dem E-Mail-System — verbundenen Tabellen gehostet werden. Dazu werden die E-Mail-Blobs von der lokalen Festplatte ausgelagert und die Speicherhierarchie (RAM / NVMe / mechanische Festplatten) der Objektschicht statt dem integrierten HSM überlassen.
Die am häufigsten mit BlueMind eingesetzten Objektsysteme:
| 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 | Eher bei Vorproduktionen |
| 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 Lastausgleich ...) und ein und dasselbe Backend lässt sich nicht auf dieselbe Weise konfigurieren, je nachdem, was es speichern soll: Ein Cluster, der für das Streaming von Videos mit einer Größe von mehreren GB ausgelegt ist, eignet sich nicht unbedingt für einen E-Mail-Bucket, in dem die überwiegende Mehrheit der Objekte weniger als 1 MB groß ist. Die Wahl des Backends und dessen Konfiguration müssen vor der Festlegung einer Architektur geklärt werden, insbesondere hinsichtlich der im Abschnitt Speichervirtualisierung angesprochenen Punkte (Latenz bei kleinen Objekten, Blockgröße, Cluster-Ereignisse).
Bandbreite
Der erforderliche Bandbreitenbedarf lässt sich nicht ohne Weiteres abschätzen: Er hängt hauptsächlich vom E-Mail-Verkehr ab, der wiederum je nach Nutzung und Ereignissen (Newsletter, Massenkommunikation usw.) starken Schwankungen unterliegt. Die nachstehenden Angaben dienen eher der Veranschaulichung von Größenordnungen und der Schaffung eines Analyserahmens als der Festlegung normativer Werte.
Beispiel anhand einer realen Anlage
Die folgende Grafik zeigt den externen Netzwerkverkehr, der über einen Zeitraum von einer Woche auf einer BlueMind-SaaS-Installation gemessen wurde. Da sich alle Nutzer außerhalb der Infrastruktur befinden, wird ihr Datenverkehr über das Internet geleitet; der interne Netzwerkverkehr (Zugriff auf den Objektspeicher usw.) wird nicht erfasst. Spam-Verkehr wird zudem bereits im Vorfeld durch spezielle Geräte blockiert und erscheint daher nicht in den hier gemessenen eingehenden Daten.
Merkmale der gemessenen Anlage:
- 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 ist das Fazit:
- Deutliche Asymmetrie: Der ausgehende Datenverkehr (Server – → – Clients) ist deutlich höher als der eingehende Datenverkehr, was mit einer E-Mail-Nutzung übereinstimmt, bei der die Nutzer mehr Daten herunterladen als versenden.
- Deutlicher Tag-Nacht-Rhythmus: Die Aktivität sinkt nachts und an den Wochenenden fast auf Null und steigt morgens mit den täglichen Verbindungen wieder sprunghaft an.
- Übertragungsspitzen von mehreren hundert Mbit/s am Ausgang (Achtung: Megabit, nicht Megabyte; die Achse des Diagramms ist in
Mbitangegeben), wie sie typisch für Massenkommunikation sind, die gleichzeitig an Tausende von Empfängern weitergeleitet wird. - Tagesdurchschnitt von einigen Dutzend Mib/s am Ausgang, was der üblichen Aktivität entspricht.
Die Dimensionierung muss auf der Grundlage der beobachteten Spitzenwerte erfolgen, nicht auf der Grundlage des Durchschnittswerts oder des Tagesdurchschnitts.
Bewährte Verfahren
Auslegung für die Spitzenlast
Ein System muss für seine Spitzenlast ausgelegt sein, nicht für den Normalbetrieb oder die durchschnittliche Last. Ein Unternehmens-E-Mail-System weist charakteristische Spitzenauslastungen auf, die berücksichtigt werden müssen:
- Zugriffe am Morgen: Die meisten Nutzer melden sich zu Beginn des Tages innerhalb desselben 15-Minuten-Zeitraums an und lösen die Synchronisierung aller seit dem Vortag eingegangenen Nachrichten aus. Denken Sie auch an Newsletter und Massenmitteilungen, die an die gesamte Belegschaft versendet werden und gleichzeitig in allen Posteingängen eintreffen.
- Big-Bang-Migration: Bei einer Umstellung werden alle Server am selben Tag synchronisiert. Auch bei einer Webmail-Umgebung müssen die differentiellen Synchronisierungen initiiert werden: Die E-Mail-Listen der verschiedenen Ordner werden abgerufen, 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 (Doppelboden-Papierkorb, Sicherungen, Archivierung) bewahren eine Kopie der Nachrichten auch nach deren Bearbeitung auf Benutzerseite auf. Beispiel: Bei 20 GB eingehenden E-Mails pro Tag und einer doppelten Aufbewahrungsfrist von 30 Tagen müssen mindestens 600 GB vorgesehen werden, um diesen Datenverkehr aufzunehmen — , selbst wenn diese E-Mails noch am selben Tag von den Empfängern gelesen und gelöscht werden.
Die maximale Größe von Nachrichten begrenzen
Zur Erinnerung: Auf 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: Da das SMTP-Protokoll Daten überträgt, ohne deren Größe im Voraus anzukündigen, 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; siehe die Zeile /var/mmap-pool in der Tabelle der Einhängepunkte).
Außerdem werden Dritte, mit denen die Nutzer kommunizieren, E-Mails mit einer Größe von 100 MB in der Regel nicht annehmen. E-Mail ist kein Tool zur Dokumentenverwaltung: BlueMind bietet die Möglichkeit, Anhänge auszulagern und eine Anbindung an Nextcloud zu nutzen, um große Dateien zu teilen (siehe Abschnitt Hosting von Dateien).
Empfehlung: Vermeiden Sie es, mehr als 30 bis 35 MB pro Nachricht zuzulassen. Darüber hinaus können sich Nachrichten im Postausgang stapeln, was bei den Nutzern zu Missverständnissen führt (interne Empfänger erhalten 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, angefangen bei der Beschreibung der Benutzer/Kunden bis hin zu den bereitzustellenden Hardware-Ressourcen. Die Zahlen sind unverbindlich und sollen anhand der Beobachtungen vor Ort angepasst werden: Sie dienen eher als Diskussionsgrundlage denn als verbindliche Vorgabe.
Die Tabellen auf dieser Seite liefern eine für Spitzenlasten berechnete Dimensionierung — gleichzeitige morgendliche Anfahrtsströme, Massenausbreitungen, Big-Bang-Migrationen usw. Dies ist die theoretische Soll-Auslegung, die die Sicherheit einer neuen Anlage gewährleistet, ohne deren tatsächliche Betriebsbedingungen zu kennen.
In der Praxis läuft BlueMind auch auf deutlich weniger leistungsstarken Systemen sehr gut. Sobald man die tatsächliche Auslastung einer Zielanlage betrachtet (tatsächliches Volumen, Nutzungsmix, zeitliche Verteilung, Kundenverhalten), können viele theoretische Vorgaben gelockert werden, ohne dass die Benutzererfahrung darunter leidet.
Nur ein gemeinsam mit unseren Integratoren durchgeführter Test ermöglicht es, genau zu ermitteln, wo diese Spielräume liegen und wie groß sie sind. — Dies ist der Schritt, der eine theoretische Dimensionierung in eine für den Kundenkontext optimierte operative Dimensionierung umwandelt.
Grundlegende Annahmen
Die Kostenangaben in Einheiten basieren auf der Profiltabelle weiter oben auf dieser Seite. In diesem 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 |
| Großkundenkonto (Top 2 %, 50 GB) | E-Mail + Zusammenarbeit + MAPI (50 GB) | 25 |
| Wenig genutzte Box (Dienst, Alias, Mitarbeiter ohne Bildschirm) | ≈ 30 % eines „reinen E-Mail-Tarifs“ | 0,3 |
Beobachtete Verteilung der Kontingente. Bei den bestehenden Installationen zeigt sich ein relativ stabiles Quoten-Histogramm: etwa 2 % der Postfächer mit einer erweiterten Quote von 50 GB (Führungskräfte, Archivierung, spezielle Konten), 10 % mit einer Quote von 10 GB (intensive Zusammenarbeit, typischerweise Outlook MAPI) und der Rest zwischen 1 und 2 GB. Für die folgenden Berechnungen:
- Die Kohorte 10 GB wird in den Architekturen B und C explizit durch Outlook-Benutzer mit vollständiger Kollaborationsfunktion repräsentiert und fehlt in Architektur A naturgemäß (kein MAPI im Einsatz);
- Die Kohorte 50 GB wird jeder Architektur als 2 % der Gesamtzahl der Postfächer hinzugefügt — Sie ist weder hinsichtlich der Einheiten (× 25) noch hinsichtlich des Speicherplatzes (× 50 GB) zu vernachlässigen, selbst wenn keine groß angelegte MAPI-Bereitstellung vorliegt.
Die Gewichtung von 0,3 für wenig genutzte Anschlüsse ist die unsicherste Annahme in diesem Beispiel: Sie spiegelt die Vorstellung wider, dass diese Anschlüsse nicht ständig verbunden sind (funktionale Anschlüsse, Aliase, Arbeitsplätze ohne dedizierten Arbeitsplatz). Dies ist in der Regel der Wert, der bei einer vergleichbaren Anlage als Erstes neu kalibriert werden muss.
Architektur A — 20.000 Postfächer, Thunderbird-Park + MailApp
E-Mail-basierte Organisation mit einfachen Funktionen für die Zusammenarbeit, ohne MAPI-Implementierung. Die 10-GB-Gruppe fehlt von vornherein; die 50-GB-Gruppe (2 %) ist weiterhin vorhanden (Archive, spezielle Konten). Praxisdaten: Bei der Referenzinstallation verfügen 2.300 von 5.000 Nutzern über ein Smartphone, das mit BlueMind verbunden ist (≈ 46 %); die übrigen 2.700 greifen ausschließlich über Webmail oder einen Desktop-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: über 6.000 Einheiten → 2 Kerne / 1.000 Einheiten ⇒ ≈ 44 Kerne Zen 4-Referenz (≈ 36 Kerne bei einem Xeon Gold 6542Y, ≈ 34 Kerne bei einem EPYC 9755; vgl. Äquivalenzen zwischen CPU-Generationen).
- RAM: 10.000+ ⇒ 96 GB mit ausgelagertem
bm-elasticsearch. - E-Mail-Volumen (theoretisches Maximum bei Auslastung der Kontingente): 2.300 × 4 GB + 2.700 × 2 GB + 400 × 50 GB + 14.600 × 2 GB = ≈ 64 TB. Bei einer typischen Auslastung von 30 bis 50 % sollten Sie mit 19–32 TB nutzbarem Speicherplatz rechnen. Bei der Objektspeicherung befindet sich dieses Volume im Bucket (siehe Speicherort des zugehörigen Objekts (siehe unten); bei lokaler Speicherung würde es unter
/var/spool/cyrus/dataabgelegt werden. /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 im Anhang enthalten) |
| ElasticSearch | 8 | 32 GB | 4 TB NVMe für /var/spool/bm-elasticsearch |
| Gesamt | 44 | 168 GB | ≈ 6,3 TB |
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).
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: Die Verbindung des eigenen Telefons mit dem geschäftlichen E-Mail-System ist eine individuelle Entscheidung (vom Arbeitgeber bereitgestelltes Diensttelefon, BYOD, Recht auf digitale Auszeit). In den untersuchten Systemen verbinden etwa 30 % der tatsächlichen Nutzer — – d. h. die persönlichen Postfächer, ohne Funktions- und Dienstpostfächer — – ihr Smartphone, was ~1.550 Smartphones in dieser Architektur entspricht (≈ 1.240 EAS + 310 IMAP-only).
Anwendung der Tabellen:
- CPU: 29.852 Einheiten ⇒ ~60 Kerne Zen 4-Referenz (≈ 49 bei einem Xeon Gold 6542Y, ≈ 46 bei einem EPYC 9755).
- RAM: ≫ 10.000 Einheiten ⇒ 96 GB pro Knoten, Remote-ES erforderlich.
- E-Mail-Volumen (theoretisches Maximum bei Auslastung der Kontingente): 5.000 × 10 GB + 160 × 50 GB + 2.840 × 2 GB ≈ 64 TB max. ⇒ 20–32 TB realistisch. Bei der Objektspeicherung befindet sich dieses Volume im Bucket (siehe Speicherort des zugehörigen Objekts (siehe unten); bei lokaler Speicherung würde es unter
/var/spool/cyrus/dataabgelegt werden. /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 ⇒ wie in der Tabelle Speicher / IO angegeben, deaktivieren Sie DataProtect für E-Mails bei diesem Volumen 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 im Anhang enthalten) |
| ElasticSearch | 12 | 48 GB | 4 TB NVMe für /var/spool/bm-elasticsearch |
| Gesamt | 60 | 192 GB | ≈ 6,3 TB |
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).
Speicherung des zugehörigen Objekts:
| Volumen / Bucket | Geschätztes Volumen | Beschreibung |
|---|---|---|
| E-Mail-Ablage | 20–32 TB | Nachrichtenspeicher, auf den BlueMind über S3 zugreift |
Bei 29.852 Einheiten (~60 Zen-4-Kerne) würde eine einzelne VM, die Rechenkerne, PostgreSQL und ElasticSearch vereint, die von den Hypervisoren empfohlenen VM-Größen (in der Regel ~8 vCPU) bei weitem überschreiten. Durch die Skalierung werden die ressourcenintensiven Aufgaben aufgeteilt: ein dedizierter ElasticSearch-Server und ein dedizierter PostgreSQL-Server, wodurch jede VM eine angemessene Größe erhält. Sofern dies möglich ist, sorgt die Unterbringung von ES und/oder der PostgreSQL-VM auf separaten Hypervisoren (und separaten Netzwerkkarten) für zusätzliche Ausfallsicherheit im Falle eines Host-Ausfalls.
Auf dem PostgreSQL-Server befindet sich die Datenbank bj-data, die den Großteil der BlueMind-Tabellen im Zusammenhang mit dem Nachrichtensystem enthält. Mit Objektspeicher 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üsselung veranschaulicht dies: 16–20 vCPU, 40–48 GB, ~2 TB in /var/lib/postgresql, und das war's). Bei der lokalen Speicherung hingegen werden PostgreSQL und das E-Mail-Dateisystem unter /var/spool/cyrus/data auf demselben Rechner gespeichert: Würde man PostgreSQL auslagern, würde jeder Zugriff auf eine Nachricht einen zusätzlichen Netzwerksprung zwischen der Datenbank und den Blobs erfordern, was zu Leistungseinbußen führen würde, die den Nutzen einer separaten VM überwiegen. Im großen Maßstab übernimmt dieselbe Maschine dann sowohl die Basis als auch die Blobs und bündelt den Großteil der E/A-Vorgänge; ihr 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 Bildschirmzugang und der üblichen 50-GB-Gruppe (auf wenige Konten beschränkt).
| 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 tatsächlichen Nutzer (ohne gemeinsam genutzte Postfächer / Mitarbeiter ohne Bildschirm) ⇒ ~155 Smartphones (≈ 125 EAS + 30 nur IMAP).
Anwendung der Tabellen:
- CPU: Bereich 3.000–6.000 Einheiten ⇒ 12 Kerne Zen 4 Referenz (≈ 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) |
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).
Die C-Architektur lässt sich problemlos auf einer einzigen VM betreiben, die auf dem vom Hypervisor bereitgestellten Speicher basiert: In dieser Größenordnung 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 Kerne Zen 4-Referenz (≈ 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) |
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).
Diese Architektur läuft sehr gut auf einem VMware vSphere-Hypervisor: eine einzelne VM mit 12 vCPUs und 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 zwischen Hosts zu verschieben, ohne dass es zu Unterbrechungen für die Benutzer kommt. Um die von bestimmten HA-Optionen (typischerweise VMware Fault Tolerance) auferlegte Obergrenze von 8 vCPUs 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 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-Node-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.
Weiterführende Informationen — Synchrone Replikation von BlueMind-Instanzen, standortübergreifendes Anwendungs-Failover — ist möglich, jedoch hängt jede verlustfreie synchrone Replikation vom zugrunde liegenden Netzwerk 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 Hochverfügbarkeitsschemas ist ein Kompromiss zwischen zwei Aspekten:
- Art der verbundenen Clients. Outlook (MAPI) kommt mit asynchronen Synchronisierungen nur schlecht zurecht, 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 Clients MailApp und ActiveSync stellen die Verbindung nun reibungsloser wieder her und reagieren besser auf kurze Unterbrechungen oder IP-Wechsel.
- RPO und RTO erforderlich. 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 (Latenzzeiten von unter einer Millisekunde zwischen den Standorten, Redundanz der Verbindungen, auf die IO-Spitzenlast ausgelegte Bandbreite).
Dies ist ein Thema, das je nach Kundenkontext mit unseren Integratoren abgestimmt werden muss: Standorte, verfügbare Latenz zwischen den Standorten, Kundenstruktur, vertragliche RPO-/RTO-Anforderungen.
Unter realen Bedingungen zu kalibrieren
Die oben genannten Zahlen basieren auf den Tabellen ohne Korrektur. Die Posten, die vorrangig vor Ort überprüft werden müssen:
- Kosten für wenig genutzte Postfächer (0,3 Einheiten angenommen): Diese sind neu zu berechnen, indem das Verhältnis „gleichzeitige Sitzungen / geöffnete Postfächer“ bei einer vergleichbaren Installation herangezogen wird. Je nach Nutzungsgewohnheiten (Anwesenheit oder Nichtanwesenheit eines mobilen Clients, Häufigkeit der Aufrufe) kann der realistische Bereich zwischen 0,1 und 0,5 liegen.
- Anteil der 50-GB-Kohorte (2 % einbehalten): Je nach Archivierungsrichtlinie und dem Vorhandensein von „Sonderkonten“ (Rechtsabteilung, Personalabteilung, Geschäftsleitung) kann dieser Anteil zwischen 0,5 % und 5 % schwanken. Sehr beeindruckend sowohl hinsichtlich der Einheiten (× 25) als auch hinsichtlich des Speicherplatzes (× 50 GB pro Konto).
- Anteil der Nutzer mit verbundenem Smartphone: 46 % für A (basierend auf einer bestehenden Installation: 2.300 / 5.000), ~30 % für B und C (bezogen auf die Gesamtbevölkerung, ohne funktionsfähige Anschlüsse), 100 % für D (explizite Annahme: ein Telefon pro Person). Es handelt sich um eine individuelle Entscheidung (Diensthandy, BYOD, Recht auf digitale Auszeit), die von Organisation zu Organisation stark variieren kann — Jeder Nutzer wechselt von 1 Einheit (ohne) zu 2 Einheiten (mit), daher ist der Koeffizient 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: Ab etwa 6.000 bis 10.000 Einheiten ist die Aufteilung ressourcenintensiver Rollen (dedizierter ElasticSearch, dediziertes PostgreSQL — , auf dem die Datenbank
bj-datagehostet wird) sinnvoller als eine einzige große VM. Die Trennung von PostgreSQL ist am einfachsten, wenn ein Objektspeicher vorhanden ist: Die Datenbank ist dann schlank (ohne lokale Blobs). Bei der lokalen Speicherung hingegen werden PostgreSQL und das E-Mail-Dateisystem auf demselben Rechner belassen, um bei jedem Zugriff auf die Blobs einen ressourcenintensiven Netzwerksprung zu vermeiden.