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.
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.
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). 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 utilisée pour les calculs ci-dessous est 1 cœur Zen 4 d'un AMD EPYC 9654 (Genoa, 5 nm, sorti fin 2022) : c'est un CPU récent, largement déployé, et qui restera supporté par son constructeur pendant plusieurs années.
Le CPU retenu doit en effet ê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 bon critère complémentaire 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 "Unités → nombre de cœurs" plus bas 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.
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 pas ses performances réelles.
Jeux d'instructions exploités par BlueMind
Au-delà du nombre de cœurs et de leur fréquence, BlueMind tire parti de plusieurs jeux d'instructions matériels pour des opérations très fréquentes sur un serveur de messagerie. 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 emails, 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é
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
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 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 le logiciel. 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 (réseau, réplication, abstraction) entre la VM BlueMind et les disques physiques. Chacune de ces couches se traduit par un surcoût en latence, qui se cumule sur les IO petits et nombreux caractéristiques d'une messagerie.
Points d'attention :
- Latence : les exigences ne sont pas les mêmes selon les volumes. Pour
/var/lib/postgresql(base transactionnelle, WAL sync), viser < 1 ms sur les écritures synchrones ; au-delà de quelques millisecondes, les performances de l'ensemble de la messagerie souffrent. Pour/var/spool/cyrus/dataet les autres volumes IO, rester sous 10 ms sur les IOPS. La réplication synchrone d'un cluster distribué ajoute mécaniquement des allers-retours réseau à chaque écriture, qui se cumulent sur chacune de ces exigences. - Taille de bloc : sur les installations BlueMind, on observe généralement que 80 % des emails 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 vs observées : les IOPS annoncés par la baie ne reflètent pas 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. Le téléchargement d'une pièce jointe volumineuse par un client Outlook ne doit pas pouvoir influencer la performance des requêtes SQL ni des écritures sur le volume d'emails. Dédier des interfaces et/ou des VLAN distincts au stockage est la règle.
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.
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 de manière cohérente côté clients, 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 IOPS1 et la latence. Un service de messagerie est un gros consommateur d'IO.
À 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).
Cette asymétrie est explicitement prise en compte par BlueMind v5 via un tampon IO dédié monté sous /var/mmap-pool (cf. ligne correspondante dans le tableau des points de montage ci-dessous). Il 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 — ce qui rend le logiciel nettement 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). C'est aussi ce mécanisme qui réconcilie le besoin de performance des écritures messagerie avec les exigences de haute disponibilité, qui imposent presque toujours du stockage virtualisé.
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.
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 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 | Hérité de la v4. Espace de stockage secondaire des emails ; le code 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 préfère 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 stockage rompues à l'exercice. | ⚠️ | ❌ | |
/var/lib/postgresql | Base de données PostgreSQL | ❌ | ❌ | 5% du volume de |
/var/spool/bm-elasticsearch | Données des index ElasticSearch | ❌ | ❌ | 10% du volume de |
/var/spool/bm-mail | Envoi des emails via EAS/mapi | ❌ | ❌ | 2 Go |
/var/backups/bluemind | Sauvegardes DataProtect | ✅ | ❌ | Somme de : |
/var/spool/bm-mapi | Dossiers temporaires du service bm-mapi | ❌ | ❌ | 2 Go |
/var/lib/keydb | Base KeyDB/Redis (cache interne, remplace | ❌ | ❌ | 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/lib/influxdb | Base InfluxDB (métriques de supervision) | ❌ | ❌ | 5 Go, proportionnel au nombre d'utilisateurs (certaines métriques mapi et imap sont collectées par utilisateur). |
/var/mmap-pool | Tampon IO de BlueMind, conçu pour absorber l'écart entre les attentes du logiciel (IO petits, fréquents, faible latence) et les contraintes des stockages virtualisés ou réseau. Garde un maximum de données en mémoire ; quand l'écriture sur disque devient nécessaire, regroupe les opérations en gros blocs mieux digérés par les couches sous-jacentes (vSAN, Ceph, NFS, SAN iSCSI ou NVMe-oF). 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. | ❌ | ❌ | 20 Go |
/var/spool/bm-docs | Stockage des vignettes utilisateurs, ressources... | ❌ | ❌ | 1 Mo par entité avec vignette |
/var/spool/postfix | File d'attente des e-mails | ❌ | ❌ | 2 Go |
/var/log | Journaux systèmes et applicatifs | ❌ | ❌ | 50 Go |
/tmp | Fichiers temporaires | ❌ | ❌ | 1.2Go de volumétrie est nécessaire à l'installation de BlueMind. Cela est relatif à la décompression de l'installeur |
/usr | ❌ | ❌ | 8Go sont nécessaires pour contenir les modules et applications web. |
/var/spool/cyrus/data ?BlueMind v4 s'appuyait sur cyrus-imapd comme moteur de stockage IMAP. À partir de la v5, Cyrus disparaît au profit d'une solution interne BlueMind ; 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 emails continuent d'être stockés (hors stockage objet) sous /var/spool/cyrus/data. Le chemin est conservé ; le logiciel cyrus, lui, n'est plus utilisé.
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 emails BlueMind v5 peuvent être placés sur un système objet S3-compatible (ou Scality Ring natif). C'est l'option à privilégier dès qu'on veut alléger le serveur PostgreSQL — qui héberge la base bj-data et l'essentiel des tables liées à la messagerie — en sortant les blobs des emails de son disque local, 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 :
| 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 | Plutôt sur des 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 email, où l'écrasante majorité des objets fait moins de 1 Mo. Le choix du backend et son paramétrage doivent être cadrés avant de figer une architecture, en particulier sur les points évoqués dans la section Virtualisation du stockage (latence sur petits objets, taille de bloc, événements cluster).
Bande passante
La bande passante nécessaire n'est pas facilement prévisible : elle dépend majoritairement du trafic 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. Les utilisateurs étant tous externes à l'infrastructure, leur trafic transite par Internet ; le trafic réseau interne (accès au stockage objet, etc.) 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.
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, cohérent avec un usage messagerie où les utilisateurs téléchargent davantage qu'ils n'émettent.
- Cycle jour/nuit net : l'activité retombe presque à zéro la nuit et les week-ends, puis remonte brutalement le matin avec les connexions quotidiennes.
- Pics de diffusion à plusieurs centaines de Mib/s en sortie (attention : mégabits, pas mébioctets ; l'axe du graphique est en
Mib), typiques des communications de masse relayées vers des milliers de destinataires simultanément. - Plateau de journée de quelques dizaines de Mib/s en sortie, qui représente l'activité courante.
Le dimensionnement doit être fait sur les pics observés, et non sur la moyenne ni sur le plateau de journée.
Bonnes pratiques
Dimensionner pour le pic de charge
Un système doit être dimensionné pour son pic de charge, pas pour le rythme de croisière ni la charge moyenne. 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 de 15 minutes 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 communications de masse diffusées à tout le personnel, qui arrivent 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. Même avec une population webmail, les synchronisations différentielles doivent être initialisées : les listes d'emails 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 emails 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. 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 emails 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 128 Ko et 95 % moins de 1 Mo.
La taille maximale configurée pour les emails 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 ; cf. la ligne /var/mmap-pool dans le tableau des points de montage).
Par ailleurs, les tiers avec qui les utilisateurs échangent n'accepteront généralement pas des emails de 100 Mo. La messagerie n'est pas un outil de gestion documentaire : BlueMind propose 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).
Exemple de dimensionnement
Cette section déroule l'application des règles ci-dessus sur quatre architectures concrètes, depuis la description en utilisateurs/clients jusqu'aux ressources matérielles à provisionner. Les chiffres sont indicatifs et destinés à être recalibrés à partir des observations terrain : ils servent de base de discussion plus que de prescription.
Les tables de cette page produisent un dimensionnement calculé pour le pic de charge — arrivées matinales simultanées, diffusions de masse, migrations big-bang, etc. C'est le dimensionnement cible théorique, qui sécurise une installation neuve sans connaître son régime réel.
En pratique, BlueMind tourne très bien 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
Les coûts en unités s'appuient sur le tableau des profils 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 gros quota (top 2 %, 50 Go) | Messagerie + collaboratif + mapi (50 Go) | 25 |
| Boîte peu active (service, alias, employé non écran) | ≈ 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, comptes spécifiques), 10 % en quota 10 Go (collaboratif intensif, typiquement Outlook MAPI), et 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 typiquement la valeur à recalibrer en premier sur une installation comparable.
Architecture A — 20 000 boîtes, parc Thunderbird + MailApp
Organisation orientée messagerie + collaboratif léger, sans MAPI déployé. La cohorte 10 Go est absente par construction ; 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 desktop 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 / 1 000 unités ⇒ ≈ 44 cœurs Zen 4 référence (≈ 36 cœurs sur un Xeon Gold 6542Y, ≈ 34 cœurs sur un EPYC 9755 ; cf. Équivalences entre générations de CPU).
- RAM : tranche 10 000+ ⇒ 96 Go avec
bm-elasticsearchdéporté. - 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. Avec un remplissage observé typique de 30 à 50 %, prévoir 19-32 To utiles. 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 mail sont en objet) |
| ElasticSearch | 8 | 32 Go | 4 To NVMe pour /var/spool/bm-elasticsearch |
| Total | 44 | 168 Go | ≈ 6,3 To |
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).
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 : 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, environ 30 % des utilisateurs réels — c'est-à-dire les boîtes humaines, hors boîtes fonctionnelles / de service — connectent leur téléphone, soit ~1 550 smartphones sur cette architecture (≈ 1 240 EAS + 310 IMAP only).
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 : ≫ 10 000 unités ⇒ 96 Go par nœud, ES 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 ⇒ comme indiqué dans le tableau Stockage / IO, 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 mail sont en objet) |
| ElasticSearch | 12 | 48 Go | 4 To NVMe pour /var/spool/bm-elasticsearch |
| Total | 60 | 192 Go | ≈ 6,3 To |
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).
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 |
À 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 éclate alors 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 l'opportunité existe, 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 / personnel non écran et la cohorte 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 réels (hors boîtes partagées / personnel non écran) ⇒ ~155 smartphones (≈ 125 EAS + 30 IMAP only).
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) |
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).
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) |
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).
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, 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 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, doublons ou é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 à cadrer 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 :
- 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), 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 %. 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 décision individuelle (téléphone pro, BYOD, droit à la déconnexion) qui peut varier fortement d'une organisation à l'autre — chaque utilisateur bascule de 1 unité (sans) à 2 unités (avec), donc le coefficient est 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, l'éclatement des rôles lourds (ElasticSearch dédié, PostgreSQL dédié — qui héberge la base
bj-data) 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.