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 PDA. Le calcul du dimensionnement s’effectue donc par unité sachant que :
De même pour un même nombre d’unité, 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. |
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.
|
|
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,..)
|
|
La répartition des coeurs / ram sur plusieurs serveurs (virtuels ou non) n’est pas décrite ici. Cependant jusqu’à 16/24 coeurs, 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 / PDA).
|
La bande passante nécessaire n’est pas prévisible car elle dépend en très grande partie du trafic mail. A titre d’informations ci-dessous les informations sur la consommation bande passante de l’agenda BlueMind et des PDA, qui montre bien la prédominance du trafic mail. |
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
Avec de la marge, pour 1000 agendas ouverts dans les navigateurs : Client vers serveur: 500ko/sec. Serveur vers client: 150ko/sec. |
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. |
Les ratios ActiveSync sont fournis par microsoft : 1.04kb /sec/user soit pour 100 PDAs : 104Kb, donc 13Ko/sec
Pour lequel nous prendrons une marge raisonnable de x2, ce qui donne : 100 PDA == 26 Ko/sec 1 000 PDA == 260 Ko/sec |