Comparaison des versions

Ancienne version 2

changes.mady.by.user Marie Piochon

Sauvegardée le

comparé à

Nouvelle version 3

changes.mady.by.user Marie Piochon

Sauvegardée le

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.
Commentaire: Published by Scroll Versions from space DA and version BM-3.5
Sv translation
languagefr

Présentation

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.

Volet
borderWidth3

Sur cette page :

Sommaire
maxLevel2

En rapport :

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

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

 

Profil d’utilisateur

Coût en unité

Messagerie seule

1

Messagerie + collaboratif intensif

2

Messagerie + collaboratif + PDA

5

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.

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.

Unités

nombre de cœurs

1-50

2

50-1000

4

1000+

1 coeur / 250 unités

 

RAM

Unités

Ram

1-50

6 Go

50-500

12 Go

500+

12 + 1G / 500 unités  

Stockage / IO

Info

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

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

Unités

IOPS par unité

1

.3  

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

 

Device  

Type  

IOPS  

Interface  

Notes  

7,200 rpm   SATA drives

HDD  

~75-100 IOPS [2]  

SATA 3 Gb/s  


 

10,000 rpm SATA drives

HDD

~125-150 IOPS [2]  

SATA 3 Gbit/s


 

10,000 rpm SAS drives

HDD

~140 IOPS [2]  

SAS


 

15,000 rpm SAS drives

HDD

~175-210 IOPS [2]  

SAS

 

Exemples

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

Users / unités

CPU

#cœurs

RAM

IOPS / Disque

25 utilisateurs / 5 avec PDA

45 unités (20 + 25)

2

6

13,5 / tout disque

150 utilisateurs / 50 collaboratifs dont 25 avec PDA

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

4

12

67,5

SATA 7200 minimum

300 utilisateurs / 100 collaboratifs / 30 PDA

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

4

12

147

2 * 10K rpm SAS

1 * 15K rpm SAS

600 utilisateurs / 200 collaboratifs / 50 PDA

950 unités (400 + 150*2 * 50*5)

4

14

285

SSD, Baie ou autre système

1000 util. / 250 collaboratifs / 100 PDA

1300 unités (750 + 150 * 2 + 100 * 5)

6

15

390

SSD, Baie ou autre système

2000 util. / 500 collaboratifs / 200 PDA

3100 unités (1500 + 300*2 + 200 * 5)

13

16

930

Baie (2000 IOPS)

4000 util. / 1000 collaboratifs / 300 PDA

5900 unités (3000 + 700*2 + 300*5)

24

22

1770

Baie (2-3000 IOPS)

4000 util. / 1000 collaboratifs / 1000 PDA

8000 unités (3000 + 1000*5)

32

26

2400

BAIE 3000 IOPS

SAN / autre techno

4000 util. / 4000 collaboratifs / 1000 PDA

11000 unités (3000*2 + 1000*5)

44

32

3300

SAN / autre techno

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.

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.

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 actifs

client vers serveur

serveur vers client

1

215 octets/s

56 octets/s

100

21 ko/s

6 ko/s

1 000

210 ko/s

60 ko/s

10 000

2,1 Mo/s

600 ko/s

Avec de la marge, pour 1000 agendas ouverts dans les navigateurs :

  • Client vers serveur: 500ko/sec.
  • Serveur vers client: 150ko/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 PDA

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

Sv translation
languageen

Introduction

Data is provided for information purposes only. Usage may vary for a same number of users, depending on hardware structure and use habits. Many factors can affect usage: email volume, email size, number of recipients, number of events, event scheduling, etc.

Volet
borderWidth3

On this page:

Sommaire
maxLevel2

Related:

About units

Several BlueMind components use up resources. A typical "per user" calculation cannot be applied because a user who only uses messaging will not generate the same load for the system as a user using messaging and collaborative services (Calendar, etc.) and a PDA.

As a result, sizing is calculated "per unit", on the following basis:

User profile

Units

Messaging only

1

Messaging + intense collaborative use

2

Messaging + collaborative services + PDA

5

Also, for a same amount of units, a use of messaging only won't consume the same amount of resources as a messaging+collaborative use: unlike collaborative tools, messaging, for example, is more heavily dependent on IO than on CPU.

CPU

CPU is stated in number of cores. Reference values are based on recent Xeon-type CPU.

BlueMind has several services, as a result we recommend a minimum of 2 cores.

Units

Number of core(s)

1-50

2

50-1000

4

1000+

1 / 250 units

 

RAM

Units

RAM

1-50

6 GB

50-500

12 GB

500+

12 + 1 GB / 500 units  

Storage / IO Performance

Info

IOPS = "Input/Output Operations Per Second"

The messaging service is a heavy user of IO, as a result storage is sized in IOPS . As for storage space, it depends on client requirements (quotas, etc.)

Units

IOPS per unit

1

.3  

IOPS data for storage devices

Device  

Type  

IOPS  

Interface  

Notes

7,200 rpm SATA drives

HDD

~75-100 IOPS

SATA 3 Gb/s 


10,000 rpm SATA drives

HDD

~125-150 IOPS

SATA 3 Gb/s

 

10,000 rpm SAS drives

HDD

~140 IOPS

SAS

 

15,000 rpm SAS drives

HDD

~175-210 IOPS

SAS


   

Source: http://en.wikipedia.org/wiki/IOPS#Examples

Examples

Core/RAM distribution over several servers (virtual or otherwise) is not described here.

However, for up to 16/24 cores, we believe that a single-platform installation makes sense.

Above this threshold, and to manage populations of tens of thousands of users or more, the architecture must be distributed.

Also, the messaging part as well as the database (which collaborative use/PDA places heavy demands on) must be kept separate from the rest.

Users / Units

CPU

#cores

RAM

IOPS / Disk

25 users / 5 with PDAs

45 units (20 + 25)

2

6

13.5 / all disks

150 users / 50 collaborative users of which 25 with PDAs

225 units (100+25*2+25*5)

4

12

67.5

SATA 7,200 minimum

300 users / 100 collaborative users / 30 PDAs

490 units (200 + 70*2 + 30*5)

4

12

147

2 * 10K rpm SAS

1 * 15K rpm SAS

600 users / 200 collaborative users / 50 PDAs

950 units (400 + 150*2 * 50*5)

4

14

285

SSD, Bay or other system

1,000 users / 250 collaborative users / 100 PDAs

1,300 units (750 + 150 * 2 + 100 * 5)

6

15

390

SSD, Bay or other system

2,000 users / 500 collaborative users / 200 PDAs

3,100 units (1500 + 300*2 + 200 * 5)

13

16

930

Bay (2,000 IOPS)

4,000 users / 1000 collaborative users / 300 PDAs

5,900 units (3000 + 700*2 + 300*5)

24

22

1,770

Bay (2-3,000 IOPS)

4,000 users / 1000 collaborative users / 1000 PDAs

8,000 units (3000 + 1000*5)

32

26

2,400

Bay 3,000 IOPS

SAN / other technology

4,000 users / 4,000 collaborative users / 1000 PDAs

1,1000 units (3,000*2 + 1,000*5)

44

32

3,300

SAN / other technology

5,000+ users (10,000; 100,000; etc.)

The system must be distributed and the architecture designed on an ad-hoc basis.

   

Bandwidth

Bandwidth requirements cannot be predicted as they largely depend on mail traffic.Please note that the data on bandwidth usage of the BlueMind calendar and PDAs below clearly shows the preponderance of mail traffic.

BlueMind Calendar bandwidth

For a user with the Calendar application open in their web browser, in http and in bytes (measured on the network with Wireshark):

  • every 30 seconds: one doSync 1067 / 293 (sends local modifications and retrieves changes)
  • every 5 seconds: one ping: 898 / 233, i.e. 5388 / 1398 in 30s (one keepalive)

Client to server: 215 bytes/sec (1,067+5,388)/30

Server to client: 56 bytes/sec (293+1,398)/30

Number of active users

Client to Server

Server to Client

1

215 B/s

56 B/s

100

21 KB/s

6 KB/s

1,000

210 KB/s

60 KB/s

10,000

2.1 MB/s

600 KB/s

With room for maneuver, for 1,000 Calendars running in web browsers:

  • Client to server: 500KB/s
  • Server to client: 150KB/s

Contacts bandwidth

For a user with the Contacts application running in their browser, in http and in bytes:

144 bytes/second

Specifically:

  • a ping every 5 seconds
  • a "bmc" every 30 seconds

By doubling the value measured to ensure a comfortable safety margin, we calculate a bandwidth of 288 bytes per second for a user who has launched the Contacts application.

PDA bandwidth

Microsoft provides the following ActiveSync ratios: 1.04KB/s/user

i.e. for 100 PDAs: 104Kbit, or 13KB/s

By taking a sensible safety margin of x2, we calculate:

  • 100 PDAs == 26KB/s
  • 1,000 PDAs == 260KB/s

Enregistrer

Enregistrer

Enregistrer