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. Le nombre de mails, leur taille, le nombre de destinataires dans les mails, le nombre de rdv, de planification... 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.
Le calcul basique “par utilisateur” n’est pas valide car un utilisateur qui n’utilise que la partie messagerie ne sollicitera pas le système de la même façon qu’un utilisateur utilisant le mail et les outils collaboratifs (agenda, …), ni qu'un utilisateur utilisant mapi.
Le calcul du dimensionnement s’effectue donc par unité sachant que :
| 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. La référence est un CPU serveur récent, de type 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
Une messagerie sollicite beaucoup les disques, pour la lecture et l'écriture de petits fichiers, mais aussi pour tous les traitements sur les messages (indexation, état de lecture, …). Die Qualität und Geschwindigkeit der Festplatten sind entscheidend für eine leistungsstarke E-Mail-Kommunikation.
L'utilisation de disques SSD/nvme est obligatoire pour une nouvelle installation et fortement recommandé dans le cadre d'une mise à jour depuis une version 4, à moins que le matériel en place ne donne pleinement satisfaction. Les disques mécaniques / rotationnels présentent des latences élevées incompatibles avec le logiciel. Ces derniers peuvent éventuellement être utilisés pour les sauvegardes ou dans le stockage hiérarchique, derrière des SSD/nvme performants.
Mindestleistung und -volumen der Festplatten
Le stockage est dimensionné en IOPS1, un service de messagerie étant un gros consommateur d’IO. L’espace de stockage est lui directement dépendant de la demande du client (quotas, …)
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.
Point de montage | Beschreibung | Type NFS | Type Object Storage S3/Scality Ring | Volumétrie minimale |
|---|---|---|---|---|
/var/spool/cyrus/data | Espace de stockage des emails | ❌ | ✅ | Espace le plus volumineux, à déterminer en fonction de la volumétrie mail attendue. |
/var/spool/bm-hsm | Espace optionnel de stockage secondaire des emails | ⚠️ | ❌ | |
/var/lib/postgresql | Base de données PostgreSQL | ❌ | ❌ | 5% des Volumens von |
/var/spool/bm-elasticsearch | Données des index ElasticSearch | ❌ | ❌ | 10% des Volumens von |
/var/spool/bm-mail | Envoi des emails via EAS/mapi | ❌ | ❌ | 2 GB |
/var/backups/bluemind | Sauvegardes DataProtect | ✅ | ❌ | Summe aus: |
/var/spool/bm-mapi | Temporäre Verzeichnisse des Dienstes bm-mapi | ❌ | ❌ | 2 GB |
/var/spool/bm-hollowed | Cache interne | ❌ | ❌ | 1 Go |
/var/spool/bm-docs | Stockage des vignettes utilisateurs, ressources... | ❌ | ❌ | 1 Mo par entité avec vignette |
/var/spool/postfix | File d'attente des mails | ❌ | ❌ | 2 GB |
/var/log | Journaux systèmes et applicatifs | ❌ | ❌ | 50 GB |
/tmp | Fichiers temporaires | ❌ | ❌ | 1.2Go de volumétrie est nécessaire à l'installation de BlueMind. Dies bezieht sich auf das Dekomprimieren des Installers. |
/usr | ❌ | ❌ | 8Go sont nécessaires pour contienir les modules et applications web. |
Privilégier le stockage objet pour avoir de meilleurs résultats que les montages NFS, particulièrement si les stockages blocks utilisés s'appuient sur du réseau (par exemple Ceph, SAN iSCSI).
L'usage de baie de stockage rapide de type "full flash" est une bonne chose. Il faudra néanmoins porter une attention particulière à conserver des latences faibles entre l'instance BlueMind et l'infrastructure de stockage. BlueMind recommande de ne pas dépasser 10ms sur les IOPS.
Bandbreite
La bande passante nécessaire n’est pas prévisible car elle dépend en très grande partie du trafic mail.
À titre d’informations ci-dessous les informations sur la consommation bande passante de l’agenda BlueMind et des smartphones, qui montre bien la prédominance du trafic mail.
Bandbreite Agenda BlueMind
Pour un utilisateur avec l'application d'agenda ouverte dans son navigateur, en http et en octets (mesuré sur le réseau avec wireshark) :
- toutes les 30 sec: un "doSync" 1067 / 293 (envoie des modifs locales et récupération des changements)
- toutes les 5 sec: un "ping": 898 / 233, soit 5388 / 1398 en 30 s(un "keep alive")
Soit :
- Client vers serveur : 215 octets/sec (1067+5388)/30
- Serveur vers client : 56 octets/sec (293+1398)/30
| Utilisateurs actifs | Client vers serveur | Serveur vers client |
|---|---|---|
| 1 | 215 octets/s | 56 octets/s |
| 100 | 21 ko/s | 6 ko/s |
| 1 000 | 210 ko/s | 60 ko/s |
| 10 000 | 2,1 Mo/s | 600 ko/s |
Avec de la marge, pour 1000 agendas ouverts dans les navigateurs :
- Client vers serveur: 500 ko/sec.
- Serveur vers client: 150 ko/sec.
Bandbreite de la gestion des contacts
Pour un utilisateur avec l'application de gestion des contacts ouverte dans son navigateur, en http et en octets :
144 octets / seconde
Avec en particulier :
- toutes les 5 secondes un "ping"
- toutes les 30 secondes un "bmc"
En prenant une marge de sécurité en doublant la valeur mesurée, nous obtenons une bande passant de 288 octets par seconde pour un utilisateur ayant lancé l'application de gestion de contacts.
Bandbreite smartphones
Les ratios ActiveSync sont fournis par Microsoft : 1.04kb /sec/utilisateur.
Donc pour 100 smartphones 104 Ko, soit 13 Ko/sec.
En prenant une marge raisonnable de x2, on comptera alors :
- 100 smartphones == 26 Ko/sec
- 1 000 smartphones == 260 Ko/sec