Aller au contenu principal

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 plus 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, …), notamment avec un smartphone.

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

Profil d’utilisateurCoût en unité
Messagerie seul1
Messagerie + collaboratif intensif2
Messagerie + collaboratif + smartphone5

De même pour un même nombre d’unités, 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ésnombre de cœurs
1-2002
200-10004
1000-20006
2000-30008
3000-600012
6000+2 cœurs / 1000 unités

RAM

UnitésRam
1-25016 Go
250-100024 Go
1000-250032 Go
2500 - 500048 Go
5000-1000064 Go*
10000+96 Go*

*avec déport du service Cyrus et bm-elasticsearch sur des serveurs dédiés

Stockage / IO

Disques et performance

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é d'une messagerie performante.

info

IOPS = «In/Out per second», soit «Entrée/Sorties par seconde»

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.

info

Les volumétries minimales indiquées 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...).

Point de montage

Description

Type NFS

Type block device

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 volémetrie mail attendue.

/var/spool/bm-hsm

Espace optionnel de stockage secondaire des emails

6 000 iops

/var/spool/cyrus/meta

Meta données des e-mail

10 000 iops

5% du volume de /var/spool/cyrus/data + /var/spool/bm-hsm

/var/lib/cyrus

Information des BALs et conversations

10 000 iops

5% du volume de /var/spool/cyrus/data + /var/spool/bm-hsm

/var/spool/sieve

Règles de filtrage des mails

6 000 iops

1 Mo par utilisateurs + BAL partagées

/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

10% du volume de /var/spool/cyrus/data + /var/spool/bm-hsm

Prévoir de laisser au moins 50% d'espace libre, sauf si le dataprotect est désactivée pour ES.

Nous conseillons d'utiliser 2 partitions distinctes, de tailles égales, attachées aux sous-dossiers:

  • /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
  • /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 temporaire 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.2G de volumétrie est nécessaire à l'installation de BlueMind. Cela est relatif à la décompression de l'installeur

/usr/share

N/A

8GiB sont nécessaires pour contienir les modules et applications web.

Données sur les IOPS des moyens de stockage (Wikipédia)

Device  Type  IOPS  Interface  Notes
7,200 rpm SATA drivesHDD~75-100 IOPS [2]SATA 3 Gb/s
10,000 rpm SATA drivesHDD~125-150 IOPS [2]SATA 3 Gbit/s
10,000 rpm SAS drivesHDD~140 IOPS [2]SAS
15,000 rpm SAS drivesHDD~175-210 IOPS [2]SAS

Exemples

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

Cependant jusqu’à 16/24 Go de RAM, nous considérons pertinent d’installer l’ensemble sur une même plateforme.

Au dela de ceci, et pour gérer les populations en dizaine ou plus de milliers d’utilisateurs, l’architecture doit être distribuée.

Ensuite, la partie messagerie doit être séparée, ainsi que la base de données (très sollicitée par le collaboratif / smartphones).

Users / unités

Noeud

CPU #cœurs

RAM en Go

IOPS / Disque

25 utilisateurs / 5 avec smartphones

45 unités (20 + 25)

2

16

13,5 / tout disque

150 utilisateurs / 50 collaboratifs dont 25 avec smartphones

225 unités (100+25 * 2+25 * 5)

4

16

67,5

SATA 7200 minimum

300 utilisateurs / 100 collaboratifs / 30 smartphones

490 unités (200 + 70 * 2 + 30 * 5)

4

24

147

2 * 10K rpm SAS

1 * 15K rpm SAS

600 utilisateurs / 200 collaboratifs / 50 smartphones

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 smartphones

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 smartphones

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

Cyrus

2

12

Cyrus dédié à partir de 2To de mails et archives

Edge

2

4

4000 util. / 1000 collaboratifs / 300 smartphones

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

Cyrus

2

12

Cyrus dédié à partir de 2To de mails et archives

Edge

2

4

4000 util. / 1000 collaboratifs / 1000 smartphones

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

Cyrus

4

12

Cyrus dédié à partir de 2To de mails et archives

Edge

2

4

4000 util. / 4000 collaboratifs / 1000 smartphones

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

Cyrus

6

24

Cyrus dédié à partir de 2To de mails et archives

2ème noeud Cyrus à envisager

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

Client vers serveur: 215 octets/sec (1067+5388)/30

Server vers client: 56 octets/sec (293+1398)/30

# utilisateurs actifsclient vers serveurserveur vers client
1215 octets/s56 octets/s
10021 ko/s6 ko/s
1 000210 ko/s60 ko/s
10 0002,1 Mo/s600 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/user

soit pour 100 smartphones : 104 Ko, donc 13 Ko/sec

Pour lequel nous prendrons une marge raisonnable de x2, ce qui donne :

100 smartphones == 26 Ko/sec

1 000 smartphones == 260 Ko/sec