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 d'e-mails, leur taille, le nombre de destinataires dans les e-mails, le nombre de rdv, de planification... tout ceci par jour est très variable.

A propos des environnements virtualisés

Les ressources en vCPU et/ou RAM indiquées ci-après sont entendues dédiées aux machines virtuelles. C'est à dire que ces ressources doivent être exclues d'une quelquonque mutualisation avec d'autres machines virtuelles.
De fait, il convient de porter une attention particulière à ne pas placer des instances BlueMind dans un contexte où le ou les hyperviseurs seraient en statut d'overcommit.

Le principe des unités

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

Un 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 la messagerie ET les outils collaboratifs (agenda, ...), ni qu'un utilisateur utilisant mapi ou un appareil mobile.

Deux dimensions entrent en jeu dans ce calcul :

• l'usage : plus un utilisateur active de fonctionnalités (collaboratif, mapi), plus il sollicite le système ;
• le stockage associé à cet usage : à usage identique, un quota plus élevé implique plus de données à indexer, sauvegarder et servir, et agit donc comme un multiplicateur sur le coût en unités.

Le calcul du dimensionnement s’effectue donc par unité, sachant que :

Profil d’utilisateur	Stockage / quota	Coût en unité
Messagerie seule	2 Go	1
Messagerie + collaboratif intensif	4 Go	2
Messagerie + collaboratif + mapi	10 Go	5
Messagerie + collaboratif + mapi	50 Go	25

Les deux dernières lignes illustrent l'effet du stockage : à usage identique (messagerie + collaboratif + mapi), un quota multiplié par 5 se traduit par un coût en unités également multiplié par 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). L'e-mail étant par exemple plus dépendant des IO que du CPU, ce qui est inverse en général des outils collaboratifs.

CPU

Les valeurs sont évaluées et exprimées en nombre de cœurs.

Référence et recommandations matérielles

La référence utilisée pour les calculs ci-dessous est 1 cœur Zen 4 d'un AMD EPYC 9654 (Genoa, 5 nm, sorti fin 2022).

Le CPU retenu doit être supporté par son constructeur sur toute la durée d'engagement prévue pour la messagerie : pour une installation engagée sur 5 ans, privilégier un CPU dont le support constructeur couvre l'ensemble de cette période. Un critère complémentaire à prendre en compte est le rapport performance par watt, qui favorise nettement les architectures récentes (≤ 5 nm) face aux générations antérieures 14/10 nm.

Équivalences entre générations de CPU

Le tableau Nombre de cœeurs par unités ci-après est exprimé en vCPU équivalents Zen 4 9654.
À titre indicatif, voici combien de vCPU d'autres plateformes il faut pour égaler 8 vCPU de référence, calculé à partir du score Geekbench 6 single-core (proxy raisonnable de la performance par cœur) :

Plateforme	Geekbench 6 SC	Ratio vs 9654	Équivalent à 8 vCPU de référence	Budget watts associé
Intel Xeon Platinum 8280 — Cascade Lake, 14 nm (2019)	~1214	0,65	~12 vCPU	~88 W
AMD EPYC 9654 — Zen 4, 5 nm (2022) — référence	~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

Scores relevés sur Geekbench Browser. Budget watts = (TDP socket / nombre de cœurs) × vCPU équivalents, à pleine charge (8280 : 205 W / 28 c ; 9654 : 360 W / 96 c ; 6542Y : 250 W / 24 c ; 9755 : 500 W / 128 c). Ces ratios sont indicatifs : la performance réelle dépend aussi de la bande passante mémoire, du cache, de la plateforme et de la charge — un benchmark sur la charge cible reste préférable pour un dimensionnement fin.

Clusters de virtualisation

Dans un cluster de virtualisation, les hyperviseurs exposent généralement aux machines virtuelles les capacités du CPU le moins-disant du cluster, afin de permettre le déplacement des VMs entre les nœuds. BlueMind exploite les fonctionnalités modernes des CPUs en fonction des capacités effectivement exposées aux machines virtuelles, un CPU récent exposé avec un profil ancien ne donnera donc pas ses performances réelles.

Jeux d'instructions

Au-delà du nombre de cœurs et de leur fréquence, BlueMind utilise plusieurs jeux d'instructions matériels. Leur présence est visible dans les flags de /proc/cpuinfo (ou, sur une VM, dans ceux effectivement exposés par l'hyperviseur — voir l'encadré ci-dessus) :

• aes : accélération matérielle du chiffrement AES, utilisée massivement sur toutes les connexions SSL/TLS (IMAPS, HTTPS, SMTP STARTTLS, réplication inter-serveurs).
• sha_ni : instructions SHA d'Intel/AMD, qui accélèrent les calculs de hash (intégrité, signatures, hachages côté stockage et authentification).
• avx, avx2 (SIMD) : utilisées notamment pour le décodage base64 lors de la lecture des pièces jointes des e-mails, opération omniprésente dès qu'un utilisateur consulte ses messages.

⚠️ Un CPU récent exposé à la VM avec un profil trop ancien (par exemple un profil Nehalem ou Westmere sur un cluster hétérogène) peut masquer tout ou partie de ces flags et dégrader significativement les performances perçues, à matériel physique pourtant identique.

Nombre de cœurs par unités

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é

Pourquoi déporter bm-elasticsearch ?

Le déport d'Elasticsearch sur sa propre VM répond à plusieurs préoccupations :

• Taille de VM compatible avec l'hyperviseur et ses options.
  Certaines fonctionnalités de l'hyperviseur imposent un plafond de vCPU par VM. Par exemple VMware Fault Tolerance plafonne à 8 vCPU par VM protégée (documentation Broadcom) → Déporter ES permet de garder la VM principale et la VM ES sous ces seuils.
• Rester dans un nœud NUMA.
  Au-delà d'une certaine taille, une VM ne tient plus dans un nœud NUMA et la planification CPU/mémoire devient moins efficace. La granularité dépend du CPU physique : un processeur 96 cœurs peut par exemple être organisé en groupes de 24 cœurs maximum par nœud NUMA, ce qui contraint la taille utile d'une VM mono-socket.
• Segmenter les ressources entre ES et le reste de BlueMind.
  Avec une VM dédiée, la heap ES, son cache de fichiers et ses IO d'indexation ne se mélangent plus avec ceux du cœur BlueMind ou de PostgreSQL → Une indexation intensive ne pénalise plus les requêtes SQL ni les accès à /var/spool/cyrus/data.
• Déport sur un autre hyperviseur.
  Placer la VM ES sur un hôte différent (et idéalement sur des cartes réseau différentes) libère des ressources sur l'hôte principal et permet de répartir la charge sur le pool de virtualisation.

Le revers : une ou plusieurs VM supplémentaires pour ES amènent de la complexité et un peu d'overhead — nouveau kernel à maintenir, nouveau nœud BlueMind à déclarer, nouveaux agents de supervision, et, lorsque la VM ES vit sur un autre hyperviseur, traversée du réseau physique pour chaque requête d'indexation ou de recherche. Dans le cas où ces contraintes ne s'appliquent pas, une seule VM bien dimensionnée peut suffire.

Stockage / IO

Type de disques

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

L'utilisation de disques SSD/NVMe est obligatoire pour une nouvelle installation et fortement recommandée 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 les besoins. Ces derniers peuvent éventuellement être utilisés pour les sauvegardes ou dans le stockage hiérarchique, derrière des SSD/NVMe performants.

Virtualisation du stockage

Les systèmes de stockage virtualisés ou distribués (Ceph, vSAN, SAN iSCSI ou NVMe-oF, NFS sur stockage distant...) ajoutent plusieurs couches entre la VM BlueMind et les disques physiques. Chacune de ces couches se traduit par un surcoût en latence, ce qui a un impact d'autant plus important que les IO réalisés sont petits et nombreux.

BlueMind recommande donc une attention particulière sur les points suivants :

• Latence : les exigences ne sont pas les mêmes selon les volumes :
  • Pour /var/lib/postgresql, viser < 1 ms sur les écritures synchrones ; au-delà de quelques millisecondes, les performances de l'ensemble de la messagerie sont dégradées.
  • Pour /var/spool/cyrus/data et les autres volumes IO, rester sous 10 ms sur les IOPS.
• Taille de bloc : sur les installations BlueMind, on observe généralement que 80 % des e-mails font moins de 128 Ko et 95 % moins de 1 Mo. Des tailles de bloc surdimensionnées (blocs de 4 Mo côté Ceph, DiskMaxIOSize à 1 Mo côté VMware, etc.) amplifient inutilement chaque IO et dégradent les performances, tout particulièrement pour la base PostgreSQL qui travaille sur des pages de 8 Ko.
• Performances nominales et observées : les IOPS annoncés ne reflètent pas forcément ceux réellement disponibles pour la VM une fois le cache saturé ou en présence d'autres charges sur le cluster.
• Événements cluster : les opérations de rééquilibrage (rebuild, rebalance) côté Ceph ou vSAN peuvent dégrader ponctuellement les performances vues par la VM.
• Découpage des flux réseau : le réseau utilisé pour joindre le stockage doit être différencié du trafic utilisateur.
  Ainsi, par exemple, le téléchargement d'une pièce jointe volumineuse par un Outlook ne doit pas pouvoir influencer la performance des requêtes SQL ni celle des écritures sur le volume d'e-mails → Dédier des interfaces et/ou des VLAN distincts au stockage.

Alternative à latence locale : un hyperviseur tel que Proxmox associé à ZFS sur disques locaux NVMe offre la latence d'un disque directement attaché, tout en conservant snapshots, réplication asynchrone et intégrité des données. C'est une approche pertinente lorsque la performance IO prime sur la mobilité à chaud des VMs.

Retour à un snapshot antérieur

Restaurer l'instance BlueMind à un snapshot hyperviseur ou ZFS antérieur n'est pas neutre pour les clients déjà configurés :

• Clients mapi (Outlook) : les états client et serveur se désynchronisent, avec un risque de doublons, d'éléments manquants ou de resynchronisation complète de la boîte.
• Applications mobiles / MailApp : les identifiants d'objets (UID, sync keys) remontent dans le temps, les clients peuvent rejouer ou omettre des modifications.

Pour revenir en arrière, il faut donc privilégier une restauration via DataProtect plutôt qu'un snapshot.

Les snapshots restent en revanche adaptés comme filet de sécurité lors d'une mise à jour, à deux conditions :

• le flux utilisateur est coupé en amont de BlueMind avant la prise du snapshot (pas de client mapi, mobile ou webmail actif pendant la fenêtre)
• les snapshots sont atomiques sur l'ensemble des VMs composant l'infrastructure, pour garantir un retour cohérent inter-services

Performances et volumétrie minimales des disques

Le stockage se dimensionne sur deux axes : les IOPS¹ et la latence.

Exemple

À titre d'illustration, un disque comme le Samsung PM1733 NVMe SSD (2022) répond parfaitement à ces pré-requis en attachement direct.

Dès que ce même disque est masqué derrière une couche de stockage réseau (Ceph, vSAN, SAN iSCSI ou NVMe-oF...), la latence introduite par la couche et le paramétrage de ces briques pour un usage messagerie font toute la différence (voir la section Virtualisation du stockage).

BlueMind a donc ajouté un tampon IO dédié, monté sous /var/mmap-pool (cf. ligne correspondante dans le tableau des points de montage ci-dessous).
ℹ️ Fonctionnement : Ce tampon garde un maximum de données en mémoire, et quand l'écriture sur disque devient nécessaire, il regroupe les opérations en gros blocs mieux digérés par les couches sous-jacentes. Cela permet de rendre le système plus tolérant qu'un service IO-naïf vis-à-vis des stockages virtualisés ou réseau (vSAN, Ceph, NFS, SAN iSCSI ou NVMe-oF).

L'espace de stockage est quant à 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.).

Points de montages

Point de montage	Description	Type NFS	Type Object Storage S3/Scality Ring	Volumétrie minimale
/tmp	Fichiers temporaires	❌	❌	1.2Go pour l'installation de BlueMind. Cela est dû à la décompression de l'installeur.
/usr		❌	❌	8Go pour contenir les modules et applications web.
/var/backups/bluemind	Sauvegardes DataProtect	✅	❌	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 e-mails. Vous pouvez utiliser un système de sauvegarde tiers et/ou la corbeille double fond.
/var/lib/alloy	Collecte et rapport de métriques pour la supervision	❌	❌	3Go sur chaque serveur de l'installation
/var/lib/mimir	Base Mimir/Promotheus (métriques de supervision)	❌	❌	10 Go sur le serveur qui porte le tag bm/monitoring
/var/lib/postgresql	Base de données PostgreSQL	❌	❌	5% du volume de /var/spool/cyrus/data + /var/spool/bm-hsm. NB : l'espace utilisé sur cette partition est doublé durant une Restauration unitaire - DataProtect.
/var/lib/valkey	Base Valkey/Redis (cache interne, remplace /var/spool/bm-hollowed)	❌	❌	2 Go minimum, à adapter en fonction du nombre de sessions concurrentes et de la taille de l'annuaire (photos et certificats S/MIME compris).
/var/log	Journaux systèmes et applicatifs	❌	❌	50 Go
/var/mmap-pool	Tampon IO de BlueMind : l'espace est réservé sur disque mais les écritures effectives ne se déclenchent qu'en fonction de la pression mémoire du système (voir ci-dessus).	❌	❌	20 Go
/var/spool/bm-docs	Stockage des vignettes utilisateurs, ressources...	❌	❌	1 Mo par entité avec vignette
/var/spool/bm-elasticsearch	Données des index Elasticsearch	❌	❌	10% du volume de /var/spool/cyrus/data + /var/spool/bm-hsm.
/var/spool/bm-mail	Envoi des e-mails via EAS/mapi	❌	❌	2 Go
/var/spool/bm-mapi	Dossiers temporaires du service bm-mapi	❌	❌	2 Go
/var/spool/cyrus/data	Espace de stockage des e-mails	❌	✅	Espace le plus volumineux, à déterminer en fonction de la volumétrie e-mail attendue.
/var/spool/bm-hsm	Hérité de la v4 : espace de stockage secondaire des e-mails (voir Stockage hiérarchisé (HSM)) ; il reste présent pour assurer la compatibilité lors des migrations v4 → v5. Pour une nouvelle installation v5, ne pas activer le HSM intégré : BlueMind recommande que la hiérarchie de stockage soit gérée en dessous de l'application, soit en stockage objet (où la hiérarchie est paramétrable au niveau du bucket), soit en confiant la gestion d'un pool RAM / NVMe / disques mécaniques aux équipes spécialisées.	⚠️	❌
/var/spool/postfix	File d'attente des e-mails	❌	❌	2 Go

Pourquoi /var/spool/cyrus/data ?

La version 4 de BlueMind s'appuyait sur cyrus-imapd comme moteur de stockage IMAP. À partir de la v5, Cyrus disparaît au profit d'une solution interne : le protocole IMAP reste pris en charge comme mode d'accès au même titre qu'ActiveSync, MAPI ou CalDAV, mais ce n'est plus le composant qui stocke les messages.

Pour faciliter la migration depuis la v4 et coller aux allocations d'espaces déjà en place chez nos clients, les e-mails continuent d'être stockés (hors stockage objet) sous /var/spool/cyrus/data.

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 ou NVMe-oF).

Stockage objet

Les e-mails peuvent être placés sur un système objet S3-compatible (ou Scality Ring natif). C'est l'option à privilégier afin d'alléger le serveur PostgreSQL et déléguer la hiérarchisation du stockage (RAM / NVMe / disques mécaniques) à la couche objet plutôt qu'au HSM intégré.

Les systèmes objet les plus couramment déployés avec BlueMind sont :

Système	Modes d'accès	Contexte typique
Ceph	S3 (RadosGW)	On-premise, clusters internes
Scality Ring	Ring natif (sproxyd) ou S3	On-premise, gros volumes
Scality Artesca	S3	Pré-productions
Outscale Object Storage	S3	Cloud souverain
MinIO	S3	On-premise
SeaweedFS	S3	On-premise

Chacun de ces systèmes vient avec ses propres contraintes (consistance, taille de bloc minimale, latence, gestion des classes de stockage, intégration TLS, gestion des clés, montée en charge, comportement en rééquilibrage...) et un même backend ne se configure pas de la même manière selon ce qu'on lui demande de stocker : un cluster réglé pour servir des vidéos de plusieurs Go en streaming n'est pas nécessairement le plus adapté à un bucket e-mail, où la majorité des objets font moins de 1 Mo.
Le choix du backend et son paramétrage doivent donc être réalisés avant de figer l'architecture.

Bande passante

La bande passante nécessaire n'est pas facilement prévisible : elle dépend majoritairement du trafic e-mail, lui-même très variable suivant les usages et les événements (newsletters, communications de masse...). Les éléments ci-dessous visent à donner des ordres de grandeur et un cadre d'analyse plutôt que des valeurs normatives.

Exemple sur une installation réelle

Le graphique ci-dessous représente le trafic réseau externe observé sur une installation BlueMind SaaS sur une semaine.

À noter

Les utilisateurs étant tous externes à l'infrastructure, leur trafic transite donc par internet.
Le trafic réseau interne n'est pas comptabilisé.
Le trafic spam est par ailleurs bloqué en amont par un équipement dédié et n'apparaît donc pas dans l'entrant mesuré ici.

Trafic entrant/sortant sur une semaine, exprimé en MiB²

Caractéristiques de l'installation mesurée :

• 10 000 utilisateurs messagerie seule
• 2 000 utilisateurs collaboratif avancé
• > 2 000 smartphones connectés via EAS
• Mix clients mail : 70 % MailApp, 30 % Thunderbird

Ce que l'on en retient :

• Asymétrie marquée : le trafic sortant (serveur → clients) est nettement supérieur au trafic entrant.
  Cela s'explique par le fait que les utilisateurs téléchargent davantage qu'ils n'émettent (réception d'e-mails, téléchargement de pièces jointes, etc.). Il s'agit là des usages habituels.
• Cycle jour/nuit : l'activité retombe presque à zéro la nuit et les week-ends, puis remonte brutalement le matin.
  Il s'agit là aussi d'un usage classique, les utilisateurs se reconnectent le matin dans un créneau horaire restreint et travaillent le jour.
• Pics de diffusion à plusieurs centaines de MiB²/s en sortie.
  Cela est typique des envois de masse : une communication est envoyée à l'ensemble des utilisateurs.
• Plateau de journée de quelques dizaines de MiB²/s en sortie.
  Cela représente l'activité courante de la messagerie pendant les heures de travail.

Bonnes pratiques

Dimensionner pour le pic de charge

Un système doit être dimensionné pour son pic de charge et non pour le rythme de croisière ou pour la charge moyenne.

Comme le montre l'exemple ci-dessus, une messagerie d'entreprise présente des pics caractéristiques qui doivent être pris en compte :

• Arrivées matinales : la majorité des utilisateurs se connectent sur la même tranche horaire en début de journée et déclenchent la synchronisation de l'ensemble des messages reçus depuis la veille.

💡 Penser également aux newsletters et autres communications diffusées à l'ensemble du personnel, qui arrivent donc simultanément dans toutes les boîtes.

• Migration big bang : lors d'une bascule, toutes les boîtes sont synchronisées le même jour. Or, même avec une population uniquement webmail, les synchronisations différentielles doivent être initialisées : les listes d'e-mails des différents dossiers sont rapatriées, même si les contenus ne sont pas téléchargés à ce stade.

Planification de la capacité de stockage des e-mails

Le volume quotidien des e-mails entrants doit être connu et intégré au dimensionnement des disques, indépendamment des quotas des utilisateurs.

Les mécanismes de rétention (corbeille double fond, sauvegardes, archivage) conservent une copie des messages au-delà de leur traitement côté utilisateur.

Ainsi par exemple pour 20Go d'e-mails entrants par jour et 30 jours de rétention double fond, il faut prévoir a minima 600Go pour absorber ce trafic, même si ces e-mails sont lus et supprimés dans la journée par leurs destinataires.

Limiter la taille maximale des messages

Pour rappel, sur les installations BlueMind 80% des messages font moins de 128Ko et 95% font moins de 1 Mo.

La taille maximale configurée pour les e-mails est utilisée par le système comme indicateur pour préréserver de l'espace disque : le protocole SMTP transmet les données sans en annoncer la taille à l'avance, BlueMind doit donc dimensionner son tampon de réception à la valeur haute autorisée (présentation simplifiée, le mécanisme réel est plus subtil, avec un mmap-pool dédié et des optimisations dépendant de la pression mémoire).

Par ailleurs, les tiers avec qui les utilisateurs échangent n'accepteront généralement pas des e-mails de 100 Mo. BlueMind propose donc le détachement des pièces jointes et l'interconnexion avec Nextcloud pour partager des fichiers volumineux (voir la section Hébergement de fichiers).

Recommandation : éviter d'autoriser plus de 30 à 35 Mo par message. Au-delà, des messages peuvent s'empiler dans les boîtes d'envoi et des incompréhensions apparaissent côté utilisateurs (les destinataires internes reçoivent, les externes non par exemple).

Exemple de dimensionnement

Cette section déroule l'application des règles ci-dessus sur quatre architectures concrètes. Les chiffres sont indicatifs et destinés à être recalibrés à partir des observations terrain : ils servent de base de réflexion plus que de prescription.

Du dimensionnement théorique au dimensionnement opérationnel

Les tables de cette page produisent un dimensionnement calculé pour le pic de charge (voir ci-dessus). C'est le dimensionnement cible théorique, qui sécurise une installation neuve sans connaître son régime réel.

En pratique, BlueMind peut très bien tourner sur des configurations sensiblement plus légères. Une fois qu'on observe la charge effective d'une installation cible (volumétrie réelle, mix d'usages, distribution horaire, comportement des clients), beaucoup de prérequis théoriques peuvent être relâchés sans dégrader l'expérience utilisateur.

Seul un test mené avec nos intégrateurs permet de savoir précisément où prendre ces marges et de combien : c'est l'étape qui transforme un dimensionnement théorique en dimensionnement opérationnel optimisé pour le contexte client.

Hypothèses retenues

Utilisateurs

💡 Les coûts en unités s'appuient sur le principe des unités plus haut dans cette page.

Pour cet exemple :

Population de l'exemple	Profil retenu	Unités
Utilisateur TB ou MailApp avec smartphone connecté	Messagerie + collaboratif intensif (4 Go)	2
Utilisateur TB ou MailApp sans smartphone connecté	Messagerie seule (2 Go)	1
Utilisateur Outlook full collaboratif (MAPI 10 Go)	Messagerie + collaboratif + MAPI (10 Go)	5
Compte avec gros quota (top 2 %, 50 Go)	Messagerie + collaboratif + MAPI (50 Go)	25
Compte peu actif (boite de service, alias, employé sans ordinateur...)	≈ 30 % d'une "messagerie seule"	0,3

Distribution observée des quotas

Sur les installations existantes, on retrouve un histogramme de quotas assez stable :

• environ 2 % de boîtes en quota étendu 50 Go (cadres dirigeants, archivage, communication, comptes spécifiques)
• 10 % en quota 10 Go (collaboratif intensif, typiquement Outlook MAPI)
• le reste entre 1 et 2 Go.

Pour les calculs ci-dessous :

• la cohorte 10 Go est représentée explicitement par les utilisateurs Outlook full collaboratif dans les architectures B et C, et est absente par construction dans A (pas de MAPI déployé)
• la cohorte 50 Go est ajoutée à chaque architecture comme 2 % du total des boîtes : elle n'est pas négligeable côté unités (× 25) ni côté disque (× 50 Go), même quand il n'y a pas de déploiement MAPI massif

La pondération 0,3 unité appliquée aux boîtes peu actives est l'hypothèse la plus incertaine de l'exemple : elle reflète l'idée que ces boîtes ne sont pas connectées en permanence (boîtes fonctionnelles, alias, postes sans station de travail dédiée). C'est généralement la valeur à recalibrer en premier sur une installation comparable.

Smartphones connectés à BlueMind

Connecter son téléphone à la messagerie pro est une décision individuelle (téléphone pro fourni, BYOD, droit à la déconnexion). Sur les installations observées, on note ainsi qu'environ 30 % des utilisateurs réels (boîtes "humaines", hors boîtes partagées) connectent leur téléphone.

Architecture A — 20 000 boîtes, Thunderbird + MailApp

Il s'agit d'une organisation orientée messagerie + collaboratif léger, sans MAPI déployé.
La cohorte 10 Go est absente ; la cohorte 50 Go (2 %) reste présente (archives, comptes spécifiques).

Données terrain : sur l'installation de référence, 2 300 utilisateurs sur 5 000 disposent d'un smartphone connecté à BlueMind (≈ 46 %) ; les 2 700 autres accèdent à leur boîte en webmail ou client IMAP uniquement :

Population	Effectif	Unités/profil	Total unités
Utilisateur TB ou MailApp avec smartphone (4 Go)	2 300	2	4 600
Utilisateur TB ou MailApp sans smartphone (2 Go)	2 700	1	2 700
Comptes gros quota (top 2 %, 50 Go)	400	25	10 000
Boîtes peu actives	14 600	0,3	4 380
Total	20 000		21 680 unités

Application des tables :

• CPU : au-dessus de 6 000 unités : 2 cœurs pour 1 000 unités ⇒ ~ 44 cœurs Zen 4 référence (~ 36 cœurs sur un Xeon Gold 6542Y ou ~ 34 cœurs sur un EPYC 9755).
  cf. Équivalences entre générations de CPU
• RAM : tranche 10 000+ unités ⇒ 96 Go par nœud, Elasticsearch déporté requis.
• Volume e-mails (max théorique aux quotas) : 2 300 × 4 Go + 2 700 × 2 Go + 400 × 50 Go + 14 600 × 2 Go = ≈ 64 To ⇒ prévoir 19-32 To utiles, le remplissage observé habituellement étant de 30 à 50 %.
  NB : En stockage objet, ce volume vit dans le bucket (cf. Stockage objet associé ci-dessous) ; en stockage local, il occuperait /var/spool/cyrus/data.
• /var/lib/postgresql : ~5 % du volume e-mails ⇒ 1,0-1,6 To.
• /var/spool/bm-elasticsearch : ~10 % du volume e-mails ⇒ 1,9-3,2 To.

Proposition de découpage en VMs (e-mails en stockage objet) :

VM / rôle	vCPU	RAM	Stockage local
Cœur BlueMind	20	96 Go	200 Go NVMe (OS, /var/log, /var/spool/bm-mail, /var/spool/bm-mapi, /tmp, caches)
PostgreSQL (base bj-data)	16	40 Go	2,1 To NVMe pour /var/lib/postgresql (≈ 2 To, OS / logs ≈ 0,1 To — les blobs e-mail sont en objet)
Elasticsearch	8	32 Go	4 To NVMe pour /var/spool/bm-elasticsearch
Total	44	168 Go	≈ 6,3 To

Référence³

Stockage objet associé :

Volume / bucket	Volumétrie estimée	Description
Bucket e-mails	19-32 To	Stockage des messages, accédé en S3 par BlueMind

Architecture B — 8 000 boîtes, parc Outlook MAPI

Organisation orientée Outlook full collaboratif (cohorte 10 Go), avec un complément de boîtes fonctionnelles et la cohorte 50 Go habituelle.

Population	Effectif	Unités/profil	Total unités
Outlook full collaboratif (MAPI)	5 000	5	25 000
Comptes gros quota (top 2 %, 50 Go)	160	25	4 000
Boîtes fonctionnelles / de service	2 840	0,3	852
Total	8 000		29 852 unités

Smartphones connectés à BlueMind : 30% des utilisateurs (voir ci-dessus), soit ~1 550 smartphones sur cette architecture (≈ 1 240 EAS + 310 IMAP simples).

Application des tables :

• CPU : 29 852 unités ⇒ ~60 cœurs Zen 4 référence (~ 49 sur un Xeon Gold 6542Y, ~ 46 sur un EPYC 9755).
• RAM : tranche 10 000+ unités ⇒ 96 Go par nœud, Elasticsearch déporté requis.
• Volume e-mails (max théorique aux quotas) : 5 000 × 10 Go + 160 × 50 Go + 2 840 × 2 Go ≈ 64 To max ⇒ 20-32 To réalistes.
  En stockage objet, ce volume vit dans le bucket (cf. Stockage objet associé ci-dessous) ; en stockage local, il occuperait /var/spool/cyrus/data.
• /var/lib/postgresql : ~5 % du volume e-mails ⇒ 1,0-1,6 To.
• /var/spool/bm-elasticsearch : ~10 % du volume e-mails ⇒ 2,0-3,2 To.
• Sauvegarde DataProtect : volume e-mails > 1 To ⇒ désactiver DataProtect sur les e-mails à ce volume et basculer vers une stratégie de sauvegarde tierce + corbeille double fond.

Proposition de découpage en VMs (e-mails en stockage objet) :

VM / rôle	vCPU	RAM	Stockage local
Cœur BlueMind	28	96 Go	200 Go NVMe (OS, /var/log, /var/spool/bm-mail, /var/spool/bm-mapi, /tmp, caches)
PostgreSQL (base bj-data)	20	48 Go	2,1 To NVMe pour /var/lib/postgresql (≈ 2 To, OS / logs ≈ 0,1 To — les blobs e-mail sont en objet)
Elasticsearch	12	48 Go	4 To NVMe pour /var/spool/bm-elasticsearch
Total	60	192 Go	≈ 6,3 To

Référence³

Stockage objet associé :

Volume / bucket	Volumétrie estimée	Description
Bucket e-mails	20-32 To	Stockage des messages, accédé en S3 par BlueMind

À cette échelle, éclater les rôles pour rester dans des tailles de VM raisonnables

À 29 852 unités (~60 cœurs Zen 4), une seule VM agrégeant cœur, PostgreSQL et Elasticsearch sortirait largement des tailles de VM recommandées par les hyperviseurs (typiquement ~8 vCPU). Le dimensionnement doit donc séparer les rôles lourds : un serveur Elasticsearch dédié et un serveur PostgreSQL dédié, ce qui ramène chaque VM à une taille confortable.

Si cela est possible, placer ES et/ou la VM PostgreSQL sur des hyperviseurs distincts (et des cartes réseau distinctes) ajoute en plus de la résilience face à une panne d'hôte.

Le serveur PostgreSQL héberge la base bj-data qui regroupe l'essentiel des tables BlueMind liées à la messagerie.
Avec un stockage objet, les blobs des e-mails partent dans le bucket et la VM PostgreSQL devient nettement plus légère : c'est dans ce contexte que sa séparation du cœur est la plus simple à mettre en œuvre (le tableau de découpage ci-dessus l'illustre : 16-20 vCPU, 40-48 Go, ~2 To de /var/lib/postgresql, et c'est tout).
En stockage local au contraire, on garde PostgreSQL et le filesystem des e-mails sous /var/spool/cyrus/data sur la même machine : déporter PostgreSQL ferait passer chaque accès message par un saut réseau supplémentaire entre la base et les blobs, pour un coût en performance qui dépasse l'intérêt d'une VM séparée. À grande échelle, cette même machine porte alors base et blobs et concentre la majorité des IO ; on lui dédie le matériel adapté (NVMe rapide, IO soutenues, RAM) plutôt que de scinder la fonction.

Architecture C — 1 000 boîtes, petit parc Outlook MAPI

Petite organisation MAPI, avec une part importante de boîtes partagées, de personnel sans poste et la cohorte de 50 Go habituelle réduite à quelques comptes.

Population	Effectif	Unités/profil	Total unités
Outlook full collaboratif (MAPI)	500	5	2 500
Comptes gros quota (top 2 %, 50 Go)	20	25	500
Boîtes partagées / personnel non écran	480	0,3	144
Total	1 000		3 144 unités

Smartphones connectés à BlueMind : 30% des utilisateurs (voir ci-dessus), soit ~155 smartphones (≈ 125 EAS + 30 IMAP simple).

Application des tables :

• CPU : tranche 3 000-6 000 unités ⇒ 12 cœurs Zen 4 référence (~ 10 cœurs sur un 6542Y, ~ 9 cœurs sur un 9755).
• RAM : tranche 2 500-5 000 unités ⇒ 48 Go.
• /var/spool/cyrus/data : 500 × 10 Go + 20 × 50 Go + 480 × 2 Go ≈ 7 To max ⇒ 2-3,5 To réalistes.
• /var/lib/postgresql : ~5 % ⇒ ~0,1-0,2 To.
• /var/spool/bm-elasticsearch : ~10 % ⇒ ~0,2-0,4 To.

Proposition de découpage en VMs (mono-VM, stockage local) :

VM / rôle	vCPU	RAM	Stockage local
VM unique BlueMind	12	48 Go	5 To NVMe (/var/spool/cyrus/data ≈ 3,5 To, bm-elasticsearch ≈ 0,4 To, postgresql ≈ 0,2 To, OS / logs / autres ≈ 1 To)

Référence³

L'architecture C tient confortablement sur une VM unique appuyée sur le stockage présenté par l'hyperviseur : à cette échelle, le surcoût opérationnel d'un cluster multi-serveurs ou d'un backend objet ne se justifie pas.

Architecture D — 3 000 boîtes Thunderbird, mono-VM

Cette architecture illustre une organisation de 3 000 utilisateurs Thunderbird avec un smartphone par personne (EAS ou IMAP), un quota uniforme de 10 Go par boîte, sans MAPI et sans stockage objet — l'objectif étant de tenir sur une seule VM appuyée sur le stockage présenté par l'hyperviseur.

Population	Effectif	Unités/profil	Total unités
Thunderbird + smartphone (10 Go)	3 000	2	6 000
Total	3 000		6 000 unités

À 10 Go par boîte sans MAPI, on retient 2 unités par utilisateur : c'est la borne basse de l'estimation, IMAP/EAS sollicitant nettement moins le serveur que MAPI à quota équivalent. Sur un usage très intensif (gros volumes de pièces jointes synchronisées sur smartphone, recherches plein-texte fréquentes), il peut être prudent de viser 2,5-3 unités, ce qui pousserait à passer Elasticsearch sur un serveur dédié.

Application des tables :

• CPU : 6 000 unités ⇒ 12 cœurs Zen 4 référence (~ 10 cœurs sur un Xeon Gold 6542Y, ~ 9 cœurs sur un EPYC 9755) — accessible sur un seul socket moderne.
• RAM : la table positionne 5 000-10 000 unités à 64 Go avec ES déporté. Pour héberger Elasticsearch sur la même VM, prévoir 96 Go afin d'absorber sa heap sans pression mémoire.
• /var/spool/cyrus/data : 3 000 × 10 Go = 30 To max ⇒ 9-15 To réalistes (30-50 % de remplissage), parfaitement adressables sur le stockage présenté par l'hyperviseur (vSAN, datastore VMFS, NFS performant...).
• /var/lib/postgresql : ~5 % ⇒ 0,5-0,8 To.
• /var/spool/bm-elasticsearch : ~10 % ⇒ 0,9-1,5 To.

Proposition de découpage en VMs (mono-VM, stockage local) :

VM / rôle	vCPU	RAM	Stockage local
VM unique BlueMind	12	96 Go	18 To NVMe (/var/spool/cyrus/data ≈ 15 To, bm-elasticsearch ≈ 1,5 To, postgresql ≈ 0,8 To, OS / logs / autres ≈ 1 To)

Référence³

Cette architecture tourne très bien sur un hyperviseur VMware vSphere : VM unique de 12 vCPU + 96 Go appuyée sur le stockage présenté par l'hyperviseur (vSAN, datastore SAN, NFS performant...), et vMotion pour déplacer la VM à chaud entre hôtes lors des opérations de maintenance, sans interruption pour les utilisateurs. Pour rentrer sous le plafond de 8 vCPU imposé par certaines options HA (typiquement VMware Fault Tolerance), une architecture alternative déporte Elasticsearch : VM principale à 8 vCPU + 64 Go et VM ES à 4 vCPU + 32 Go (voir l'encart Pourquoi déporter bm-elasticsearch ?).

Haute disponibilité

Sur les architectures décrites plus haut, la haute disponibilité est principalement assurée par la couche d'hyperviseur et les briques de stockage en dessous, sans configuration spécifique côté BlueMind :

• VMware vSphere : vMotion déplace les VMs à chaud entre hôtes pour les opérations de maintenance (sans interruption utilisateur) ; vSphere HA redémarre automatiquement une VM sur un autre hôte en cas de perte du nœud, avec une courte coupure le temps du redémarrage.
• Proxmox + Ceph : la réplication multi-nœuds de Ceph protège les blocs de données et la live migration de Proxmox permet le déplacement à chaud des VMs entre hôtes du cluster.
• Proxmox + ZFS local : les snapshots et la réplication ZFS asynchrone vers un nœud secondaire couvrent la perte d'hôte avec un RPO de quelques minutes, en conservant la latence d'un disque local.

Ce socle couvre les pannes les plus fréquentes (perte d'un hôte, maintenance planifiée) avec des RPO et RTO de l'ordre de quelques secondes à quelques minutes.

Aller au-delà (réplication synchrone d'instances BlueMind ou basculement applicatif intersites) est possible, mais toute réplication synchrone sans perte est conditionnée par le réseau sous-jacent. La latence des écritures intersites s'ajoute aux écritures synchrones de PostgreSQL et de la base e-mails, et peut dégrader sensiblement les performances perçues dès que les sites sont éloignés ou que la latence dépasse quelques millisecondes.

Le choix d'un schéma HA est donc un compromis entre deux dimensions :

• Type de clients connectés :
  • Outlook (MAPI) tolère mal les réplications asynchrones, vues comme un retour dans le temps en cas de bascule brutale. Cela peut entraîner re-synchronisation lourde, des doublons ou des éléments manquants.
  • Les clients MailApp et ActiveSync se reconnectent plus souplement et encaissent mieux une coupure courte ou un changement d'IP.
• RPO et RTO requis :
  • Un RPO de quelques minutes (réplication asynchrone) couvre la plupart des besoins métier sans impact sur les performances.
  • Un RPO proche de zéro impose une réplication synchrone, donc des contraintes réseau fortes (latence sub-milliseconde inter-sites, redondance des liens, bande passante dimensionnée pour la pointe d'IO).

C'est un sujet à discuter avec nos intégrateurs en fonction du contexte client : sites, latence inter-sites disponible, mix de clients, exigences contractuelles RPO/RTO...

À calibrer en conditions réelles

Les chiffres ci-dessus appliquent les tables sans correction. Les postes à confronter en priorité au terrain sont :

• Coût des boîtes peu actives (0,3 unité retenu) : à recalibrer en regardant le ratio "sessions concurrentes / boîtes ouvertes" sur une installation comparable. Selon les usages (présence ou non d'un client mobile, fréquence de consultation, etc.) la fourchette réaliste peut aller de 0,1 à 0,5.
• Part de la cohorte 50 Go (2 % retenu) : selon la politique d'archivage et la présence ou non de comptes "exception" (juridique, RH, direction), cette part peut varier de 0,5 % à 5 %. Cela peut s'avérer très impactant côté unités (× 25) et côté disque (× 50 Go par compte).
• Part d'utilisateurs avec smartphone connecté : 46 % retenu pour A (calibré sur une installation existante : 2 300 / 5 000), ~30 % pour B et C (sur la population humaine, hors boîtes fonctionnelles), 100 % pour D (hypothèse explicite : un téléphone par personne). C'est une donnée qui peut varier fortement d'une organisation à l'autre et chaque utilisateur bascule de 1 unité (sans) à 2 unités (avec), le coefficient est donc sensible.
• Quotas réels vs quotas théoriques : les volumes e-mails sont calculés au quota maximum ; le remplissage observé tourne plutôt autour de 30-50 %.
• Pic de charge matinal : le dimensionnement doit absorber les arrivées simultanées 8h-9h et les diffusions de masse, pas la moyenne journalière (cf. Bonnes pratiques > Dimensionner pour le pic de charge).
• Architecture multi-serveurs : au-dessus de 6 000 à 10 000 unités, la séparation des rôles lourds (Elasticsearch dédié, PostgreSQL dédié) devient plus pertinent qu'une seule grosse VM. La séparation de PostgreSQL est la plus simple en présence d'un stockage objet : la base est alors légère (sans les blobs locaux). En stockage local au contraire, on garde PostgreSQL et le filesystem mail sur la même machine, pour éviter un saut réseau coûteux à chaque accès aux blobs.

Pour aller plus loin

Consultez la documentation BlueMind en relation

• Stockage S3
• Prérequis à l'installation

Footnotes

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

2. MiB : L'unité MiB (MebiByte) est un multiple du byte (octet) à différencier du MB (megabyte, ou Mo mégaoctet) : il représente 1024 kebibytes, lui-même représentant 1024 bytes (octets). Ainsi 9 MiB sont équivalents à 9,43718 MB (Mo). ↩ ↩² ↩³

3. vCPU exprimés en cœurs Zen 4 9654 de référence (cf. Équivalences entre générations de CPU) ; stockage calibré sur NVMe Samsung PM1733 en attachement direct — les couches de virtualisation et les stockages réseau introduisent une latence supplémentaire absorbée en grande partie par le tampon /var/mmap-pool (cf. Performances et volumétrie minimales des disques). ↩ ↩² ↩³ ↩⁴