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.
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.
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 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
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-Laufwerken ist bei einer Neuinstallation zwingend erforderlich und wird bei einem Upgrade von Version 4 dringend empfohlen, es sei denn, die vorhandene Hardware ist nicht zufriedenstellend. 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 | Typ Object Storage S3/Scality Ring | Mindestvolumen |
|---|---|---|---|---|
/var/spool/cyrus/data | E-Mail-Speicherplatz | ❌ | ✅ | 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 | ⚠️ | ❌ | |
/var/lib/postgresql | PostgreSQL-Datenbank | ❌ | ❌ | 5% des Volumens von |
/var/spool/bm-elasticsearch | ElasticSearch-Indexdaten | ❌ | ❌ | 10% des Volumens von |
/var/spool/bm-mail | Senden von E-Mails über EAS/Mapi | ❌ | ❌ | 2 GB |
/var/backups/bluemind | DataProtect-Backups | ✅ | ❌ | Summe aus: |
/var/spool/bm-mapi | Temporäre Ordner des Dienstes bm-mapi | ❌ | ❌ | 2 GB |
/var/spool/bm-hollowed | Interner Cache | ❌ | ❌ | 1 GB |
/var/spool/bm-docs | Stockage des vignettes utilisateurs, resources... | ❌ | ❌ | 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 Datenvolumen von 1,2 GB erforderlich. Dies bezieht sich auf das Entpacken des Installationsprogramms |
/usr. | ❌ | ❌ | 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).
Die Verwendung von "Full Flash"-Speicherarrays ist eine gute Sache. Es muss jedoch besonders darauf geachtet werden, dass die Latenzen zwischen der BlueMind-Instanz und der Speicherinfrastruktur niedrig bleiben. BlueMind empfiehlt, dass die IOPS nicht mehr als 10ms betragen sollten..
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.
Für weitere Informationen
Lesen Sie die BlueMind-Dokumentation in Verbindung mit
Footnotes
-
IOPS: "In/Out per second", d.h. "Eingabe/Ausgabe pro Sekunde". ↩