Dimensionnement matériel

Les données indiquées ici le sont à titre indicatif. En effet, pour un même nombre d’utilisateurs, l’utilisation peut-être très différente selon les structures et habitudes. Le nombre de mails, leur taille, le nombre de destinataires dans les mails, le nombre de rdv, de planification... tout ceci par jour est très variable.

Le principe des unités

Dans un système comme BlueMind, il y a différents composants consommateurs de ressources.

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 :

Profil d’utilisateur	Coût en unité
Messagerie seule	1
Messagerie + collaboratif intensif	2
Messagerie + collaboratif + mapi	5

De même pour un nombre d’unités identique, une utilisation uniquement messagerie n’aura pas la même consommation de ressources qu’une utilisation messagerie + collaboratif (pour la moitié d’utilisateurs). Le mail étant par exemple plus dépendant des IO que du CPU, ce qui est inverse en général des outils collaboratifs.

CPU

Nous parlons en nombre de cœurs. La référence est un CPU serveur récent, de type Xeon.

BlueMind comprend de nombreux services, nous préconisons donc 2 cœurs minimum.

À noter qu'allouer trop de CPU peut mener à d'autres problèmes sur des environnements virtualisés.

Unités	Nombre de cœurs
1-200	2
200-1000	4
1000-2000	6
2000-3000	8
3000-6000	12
6000+	2 cœurs / 1000 unités

RAM

Nous préconisons 24 Go de RAM minimum.

Unités	Ram
1-1000	24 Go
1000-2500	32 Go
2500 - 5000	48 Go
5000-10000	64 Go*
10000+	96 Go*

* avec déport du service bm-elasticsearch sur un serveur dédié

Stockage / IO

Type de disques

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, …). La qualité des disques et leur rapidité est une donnée clé pour une messagerie performante.

L'utilisation de disques SSD/nvme est fortement recommandée. 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.

Performances et volumétrie minimales des disques

Le stockage est dimensionné en IOPS¹, 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, …)

Selon l'usage final, tous les disques n'ont pas nécessairement besoin d'avoir le même niveau de performance, ni la même volumétrie.

À noter

Les volumétries minimales indiquées ci-dessous sont des estimations qui peuvent être amenées à varier suivant les installations et l'évolution de l'organisation, il est donc préférable d'utiliser des technologies permettant d'agrandir simplement les FS (LVM, etc.).

Point de montage	Description	Type NFS	Type block device	Type Object Storage S3/Scality Ring	IOPS minimum	Volumétrie minimale
/var/spool/cyrus/data	Espace de stockage des emails	❌	✅	✅	6 000 iops	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	⚠️	✅	❌	6 000 iops
/var/lib/postgresql	Base de données PostgreSQL	❌	✅	❌	10 000 iops	5% du volume de /var/spool/cyrus/data + /var/spool/bm-hsm (L'espace utilisé sur cette partition est doublé durant une restauration DataProtect)
/var/spool/bm-elasticsearch	Données des index ElasticSearch	❌	✅	❌	10 000 iops	⚠️ Si la sauvegarde ElasticSearch est activée dans la Configuration de la sauvegarde : - Prévoir de laisser au moins 50% d'espace libre - Utiliser 2 partitions distinctes, de tailles égales, attachées aux sous-dossiers2 : /var/spool/bm-elasticsearch/data /var/spool/bm-elasticsearch/repo
/var/spool/bm-mail	Envoi des emails via EAS/mapi	❌	✅	❌	6 000 iops	2 Go
/var/backups/bluemind	Sauvegardes DataProtect	✅	✅	❌	6 000 iops	Somme de : /var/spool/cyrus/data, /var/spool/bm-hsm, /var/lib/postgresql et /var/spool/bm-elasticsearch/data. Pour des tailles de /var/spool/cyrus/data + /var/spool/bm-hsm supérieures à 1 To, nous conseillons de désactiver la sauvegarde DataProtect des mails. Vous pouvez utiliser un système de sauvegarde tiers et/ou la corbeille double fond.
/var/spool/bm-mapi	Dossiers temporaires du service bm-mapi	❌	✅	❌	6 000 iops	2 Go
/var/spool/bm-hollowed	Cache interne	❌	✅	❌	10 000 iops	1 Go
/var/spool/bm-docs	Stockage des vignettes utilisateurs, ressources...	❌	✅	❌	6 000 iops	1 Mo par entité avec vignette
/var/spool/postfix	File d'attente des mails	❌	✅	❌	6 000 iops	2 Go
/var/log	Journaux systèmes et applicatifs	❌	✅	❌	10 000 iops	50 Go
/tmp	Fichiers temporaires	❌	✅	❌	N/A	1.2Go de volumétrie est nécessaire à l'installation de BlueMind. Cela est relatif à la décompression de l'installeur
/usr		❌	✅	❌	N/A	8Go sont nécessaires pour contienir les modules et applications web.

nfs

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).

Exemples

La répartition des cœurs / ram sur plusieurs serveurs (virtuels ou non) n’est pas décrite ici, cependant :

• jusqu’à 24 Go de RAM, nous considérons pertinent d’installer l’ensemble sur une même plateforme
• au-delà 24 Go de RAM, l’architecture peut être distribuée
• pour gérer les populations en dizaine (ou plus) de milliers d’utilisateurs, la partie messagerie, ainsi que la base de données (très sollicitée par le collaboratif / mapi) doivent être séparées

Users / unités	Noeud	CPU (cœurs)	RAM en Go	IOPS / Disque
25 utilisateurs / 5 avec mapi 45 unités (20 + 25)		2	24	13,5 SSD
150 utilisateurs / 50 collaboratifs dont 25 avec mapi 225 unités (100+25 * 2+25 * 5)		4	24	67,5 SSD
300 utilisateurs / 100 collaboratifs / 30 mapi 490 unités (200 + 70 * 2 + 30 * 5)		4	24	147 SSD
600 utilisateurs / 200 collaboratifs / 50 mapi 950 unités (400 + 150 * 2 * 50 * 5) → 4 CPU, 24 Go de RAM	Core	2	20	285 SSD, Baie ou autre système
	Edge	2	4
1000 util. / 250 collaboratifs / 100 mapi 1300 unités (750 + 150 * 2 + 100 * 5) → 6 CPU, 32 Go de RAM	Core	2	20	390 SSD, Baie ou autre système
	BM-ES	2	8	ES dédié à partir d'1To de mails et archives
	Edge	2	4
2000 util. / 500 collaboratifs / 200 mapi 3100 unités (1500 + 300 * 2 + 200 * 5) → 12 CPU, 48Go de RAM	Core	6	20	930 Baie (2000 IOPS)
	BM-ES	2	12	ES dédié à partir d'1To de mails et archives
	Backend messagerie	2	12	Backend dédié à partir de 2To de mails et archives
	Edge	2	4
4000 util. / 1000 collaboratifs / 300 mapi 5900 unités (3000 + 700 * 2 + 300 * 5) → 12 CPU, 64Go de RAM	Core	6	36	1770 Baie (2-3000 IOPS)
	BM-ES	2	12	ES dédié à partir d'1To de mails et archives
	Backend messagerie	2	12	Backend dédié à partir de 2To de mails et archives
	Edge	2	4
4000 util. / 1000 collaboratifs / 1000 mapi 8000 unités (3000 + 1000 * 5) → 16 CPU, 64Go de RAM	Core	6	36	2400 BAIE 3000 IOPS SAN / autre techno
	BM-ES	4	12	ES dédié à partir d'1To de mails et archives
	Backend messagerie	4	12	Backend dédié à partir de 2To de mails et archives
	Edge	2	4
4000 util. / 4000 collaboratifs / 1000 mapi 11000 unités (3000 * 2 + 1000 * 5) → 22 CPU, 96Go de RAM	Core	10	44	3300 BAIE 3000 IOPS SAN / autre techno
	BM-ES	4	24	ES dédié à partir d'1To de mails et archives
	Backend messagerie	6	24	Backend dédié à partir de 2To de mails et archives
	Edge	2	4
5000 utilisateurs et + (10 000, 100 000,..)	Le système doit être distribué et l’architecture étudiée en fonction du contexte particulier.

Bande passante

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.

Bande passante 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.

Bande passante 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.

Bande passante 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

Footnotes

1. IOPS : "In/Out per second" en anglais, soit « Entrée/Sorties par seconde » ↩

2. ElasticSearch :

   Les données ElasticSearch doivent être statiques pour être sauvegardées.

   C'est pourquoi lors de l'exécution de DataProtect, les données ES présentes dans /var/spool/bm-elasticsearch/data sont copiées vers /var/spool/bm-elasticsearch/repo pour ensuite être sauvegardées.

   Une fois cette tâche effectuée, le /var/spool/bm-elasticsearch/repo est vidé.

   ↩