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, ihre Größe, die Anzahl der Empfänger in den E-Mails, die Anzahl der Termine, die Planung... all dies pro Tag ist sehr unterschiedlich.
Das Prinzip der Einheiten
In einem System wie BlueMind gibt es verschiedene Komponenten, die Ressourcen verbrauchen.
Die grundlegende Berechnung "pro Nutzer" ist nicht gültig, da ein Nutzer, der nur den E-Mail-Bereich nutzt, das System nicht auf die gleiche Weise belastet wie ein Nutzer, der E-Mail und kollaborative Tools (Kalender, …) nutzt, oder ein Nutzer, der Mapi nutzt.
Die Berechnung der Dimensionierung erfolgt daher pro Einheit, wobei zu beachten ist, dass :
| Benutzerprofil | Kosten pro Einheit |
|---|---|
| Nur E-Mail | 1 |
| Messaging + intensive Zusammenarbeit | 2 |
| Nachrichten + Zusammenarbeit + Mapi | 5 |
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. Die Referenz ist eine neuere Server-CPU vom Typ Xeon.
BlueMind umfasst viele Dienste, daher empfehlen wir mindestens 2 Kerne.
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 mindestens 24 GB RAM.
| 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
Lagerung / IO
Art der Disks
Eine E-Mail beansprucht die Festplatten sehr stark, sowohl für das Lesen und Schreiben kleiner Dateien als auch für die gesamte Verarbeitung der Nachrichten (Indexierung, Lesestatus, …). Die Qualität und Geschwindigkeit der Festplatten sind entscheidend für eine leistungsstarke E-Mail-Kommunikation.
Die Verwendung von SSD/nvme-Festplatten wird dringend empfohlen. Mechanische/rotierende Laufwerke haben hohe Latenzen, die mit der Software nicht kompatibel sind. Diese können möglicherweise für Backups oder in der hierarchischen Speicherung hinter leistungsfähigen SSD/nvme verwendet werden.
Mindestleistungs- und Speicherkapazitätsanforderungen für die Festplatten
Die Speicherbereitstellung erfolgt in IOPS1, da ein E-Mail-Dienst eine hohe Anforderung an Ein-/Ausgänge hat. Der Speicherplatz hängt direkt von der Nachfrage des Kunden ab (Quoten, …).
Je nach Endnutzung müssen nicht alle Laufwerke die gleiche Leistung oder das gleiche Volumen haben.
*Die unten angegebenen Mindestvolumina sind Schätzungen, die je nach Installation und Entwicklung der Organisation variieren können, daher sollten Sie Technologien verwenden, die eine einfache Vergrößerung der FS ermöglichen (LVM, etc.).
Punkt der Befestigung | Beschreibung | NFS-Typ | Gerätetyp für Blöcke | Typ Object Storage S3/Scality Ring | Minimale IOPS | Mindestvolumen |
|---|---|---|---|---|---|---|
/var/spool/cyrus/data | E-Mail-Speicherplatz | ❌ | ✅ | ✅ | 6.000 iops | Größter Speicherplatz, abhängig vom erwarteten E-Mail-Volumen zu bestimmen. |
/var/spool/bm-hsm | Optionaler Speicherplatz für sekundäre Speicherung von E-Mails | ⚠️ | ✅ | ❌ | 6.000 iops | |
/var/lib/postgresql | PostgreSQL-Datenbank | ❌ | ✅ | ❌ | 10.000 iops | 5% des Volumens von /var/spool/cyrus/data + /var/spool/bm-hsm (Der auf dieser Partition belegte Speicherplatz wird während einer DataProtect-Wiederherstellung verdoppelt)) |
/var/spool/bm-elasticsearch | ElasticSearch-Indexdaten | ❌ | ✅ | ❌ | 10.000 iops | ⚠️ Wenn das ElasticSearch-Backup in der Datenbank aktiviert ist, können Sie es in der Datenbank speichern. Einrichten des Backups : - Planen Sie, mindestens 50% freien Raum zu lassen. - Verwenden Sie zwei separate Partitionen gleicher Größe, die an die Unterordner2 angehängt sind: |
/var/spool/bm-mail | Senden von E-Mails über EAS/Mapi | ❌ | ✅ | ❌ | 6.000 iops | 2 GB |
/var/backups/bluemind | DataProtect-Backups | ✅ | ✅ | ❌ | 6.000 iops | Summe aus: /var/spool/cyrus/data, /var/spool/bm-hsm, /var/lib/postgresql und /var/spool/bm-elasticsearch/data. Bei Größen von /var/spool/cyrus/data + /var/spool/bm-hsm über 1 TB empfehlen wir, die DataProtect-Sicherung von E-Mails zu deaktivieren. Sie können ein Backup-System eines Drittanbieters und/oder den Papierkorb doppelter Boden verwenden. |
/var/spool/bm-mapi | Temporäre Ordner des Dienstes bm-mapi | ❌ | ✅ | ❌ | 6.000 iops | 2 GB |
/var/spool/bm-hollowed | Interner Cache | ❌ | ✅ | ❌ | 10.000 iops | 1 GB |
/var/spool/bm-docs | Stockage des vignettes utilisateurs, resources... | ❌ | ✅ | ❌ | 6.000 iops | 1 MB pro Einheit mit Miniaturbild |
/var/spool/postfix | E-Mail-Warteschlange | ❌ | ✅ | ❌ | 6.000 iops | 2 GB |
/var/log | System- und Anwendungsprotokolle | ❌ | ✅ | ❌ | 10.000 iops | 50 GB |
/tmp | Temporäre Dateien | ❌ | ✅ | ❌ | N/A | Für die Installation von BlueMind ist ein Datenvolumen von 1,2 GB erforderlich. Dies bezieht sich auf das Entpacken des Installationsprogramms |
/usr | ❌ | ✅ | ❌ | N/A | 8 GB sind erforderlich, um die Module und Webanwendungen zu unterstützen. |
Bevorzugen Sie Objektspeicher, um bessere Ergebnisse als NFS-Mounts zu erzielen, insbesondere wenn die verwendeten Blockspeicher netzwerkbasiert sind (z.B. Ceph, iSCSI SAN).
Beispiele
Die Verteilung von Kernen/Ram auf mehrere Server (virtuell oder nicht) wird hier nicht beschrieben, aber :
- bis zu 24 GB RAM, halten wir es für sinnvoll, alles auf einer einzigen Plattform zu installieren.
- über 24 GB RAM, die Architektur kann verteilt werden
- Um Populationen von zehn (oder mehr) Tausenden von Nutzern zu verwalten, müssen der E-Mail-Teil und die Datenbank (die für die Zusammenarbeit / Mapi sehr wichtig ist) getrennt werden.
Benutzer / Einheiten | Knoten | CPU (Kerne) | RAM in GB | IOPS / Laufwerk |
|---|---|---|---|---|
25 Benutzer / 5 mit Mapi 45 Einheiten (20 + 25) | 2 | 24 | 13,5 SSD | |
150 Benutzer / 50 Zusammenarbeitende, davon 25 mit Mapi 225 Einheiten (100+25 * 2+25 * 5) | 4 | 24 | 67,5 SSD | |
300 Benutzer / 100 Zusammenarbeitende / 30 Mapi 490 Einheiten (200 + 70 * 2 + 30 * 5) | 4 | 24 | 147 SSD | |
600 Benutzer / 200 Zusammenarbeitende / 50 MAPI 950 Einheiten (400 + 150 * 2 * 50 * 5) → 4 CPU, 24 GB RAM | Kern | 2 | 20 | 285 SSD, Bay oder anderes System |
Edge | 2 | 4 | ||
1000 Utilities. / 250 Zusammenarbeitende / 100 MAPI 1300 Einheiten (750 + 150 * 2 + 100 * 5) → 6 CPU, 32 GB RAM | Kern | 2 | 20 | 390 SSD, Bay oder anderes System |
BM-ES | 2 | 8 | Dedizierter ES ab 1 TB an E-Mails und Archiven | |
Edge | 2 | 4 | ||
2000 Utilities. / 500 Zusammenarbeitende / 200 MAPI 3100 Einheiten (1500 + 300 * 2 + 200 * 5) → 12 CPU, 48 GB RAM | Kern | 6 | 20 | 930 Fach (2000 IOPS) |
BM-ES | 2 | 12 | Dedizierter ES ab 1 TB an E-Mails und Archiven | |
E-Mail-Backend | 2 | 12 | Dediziertes Backend ab 2 TB an E-Mails und Archiven | |
Edge | 2 | 4 | ||
4000 Utilities. / 1000 Zusammenarbeitende / 300 MAPI 5900 Einheiten (3000 + 700 * 2 + 300 * 5) → 12 CPU, 64 GB RAM | Kern | 6 | 36 | 1770 Fach (2-3000 IOPS) |
BM-ES | 2 | 12 | Dedizierter ES ab 1 TB an E-Mails und Archiven | |
E-Mail-Backend | 2 | 12 | Dediziertes Backend ab 2 TB an E-Mails und Archiven | |
Edge | 2 | 4 | ||
4000 Utilities. / 1000 Zusammenarbeitende / 1000 MAPI 8000 Einheiten (3000 + 1000 * 5) → 16 CPU, 64 GB RAM | Kern | 6 | 36 | BAY 3000 IOPS SAN / andere Technik |
BM-ES | 4 | 12 | Dedizierter ES ab 1 TB an E-Mails und Archiven | |
E-Mail-Backend | 4 | 12 | Dediziertes Backend ab 2 TB an E-Mails und Archiven | |
Edge | 2 | 4 | ||
4000 Utilities. / 4000 Zusammenarbeitende / 1000 MAPI 11000 Einheiten (3000 * 2 + 1000 * 5) → 22 CPU, 96 GB RAM | Kern | 10 | 44 | 3300 SAN / andere Technik |
BM-ES | 4 | 24 | Dedizierter ES ab 1 TB an E-Mails und Archiven | |
E-Mail-Backend | 6 | 24 | Dediziertes Backend ab 2 TB an E-Mails und Archiven | |
Edge | 2 | 4 | ||
5000 Benutzer und + (10 000, 100 000,..) | Das System muss verteilt und die Architektur gemäß dem spezifischen Kontext überprüft werden. | |||
Bandbreite
Die erforderliche Bandbreite ist nicht vorhersehbar, da sie größtenteils vom Mailverkehr abhängt.
Nachfolgend finden Sie Informationen über den Bandbreitenverbrauch des BlueMind Kalenders und der Smartphones, die zeigen, dass der E-Mail-Verkehr dominiert.
Bandbreite Agenda BlueMind
Für einen Nutzer, der die Kalenderanwendung in seinem Browser geöffnet hat, in http und Bytes (gemessen im Netzwerk mit Wireshark) :
- alle 30 Sekunden: ein "doSync" 1067 / 293 (Senden der lokalen Änderungen und Abrufen der Änderungen)
- alle 5 Sekunden: ein "Ping": 898 / 233, d.h. 5388 / 1398 in 30 Sekunden (ein "Keep alive")
Sei es :
- Client zu Server: 215 Bytes/sec (1067+5388)/30
- Server zu Client: 56 Bytes/Sek (293+1398)/30
| Aktive Benutzer | Client zu Server | Server zu Client |
|---|---|---|
| 1 | 215 Bytes/s | 56 Bytes/s |
| 100 | 21 kb/s | 6 kb/s |
| 1 000 | 210 kb/s | 60 kb/s |
| 10 000 | 2,1 MB/s | 600 kb/s |
Mit Spielraum für 1000 offene Agenden in den Browsern :
- Client zu Server: 500 kb/sec.
- Server zu Client: 150 KB/Sek.
Bandbreite des Kontaktmanagements
Für einen Nutzer, der die Anwendung zur Kontaktverwaltung in seinem Browser geöffnet hat, in http und in Bytes :
144 Bytes / Sekunde
Insbesondere mit :
- alle 5 Sekunden ein "Ping".
- alle 30 Sekunden ein "bmc".
Unter Berücksichtigung einer Sicherheitsmarge durch Verdopplung des gemessenen Wertes erhalten wir eine Bandbreite von 288 Bytes pro Sekunde für einen Nutzer, der die Anwendung zur Kontaktverwaltung gestartet hat.
Bandbreite Smartphones
Die ActiveSync-Kennzahlen werden von Microsoft bereitgestellt: 1.04kb /sec/User. Dies bedeutet für 100 Smartphones 104 KB, d.h. 13 KB/sec.
Bei einer angemessenen Marge von x2 zählen wir dann :
- 100 Smartphones == 26 KB/Sek.
- 1.000 Smartphones == 260 KB/Sek.
Footnotes
-
IOPS: "In/Out per second", d.h. "Eingabe/Ausgabe pro Sekunde". ↩
-
ElasticSearch :
ElasticSearch-Daten müssen statisch sein, um gesichert werden zu können.
Aus diesem Grund werden bei der Ausführung von DataProtect die ES-Daten in
/var/spool/bm-elasticsearch/datanach/var/spool/bm-elasticsearch/repokopiert und anschließend gesichert.Nach Abschluss dieser Aufgabe wird
↩/var/spool/bm-elasticsearch/repogeleert.