Hardware Sizing
The data in this page 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.
About units
A BlueMind system is made up of multiple components that use up resources.
A typical "per user" calculation cannot be applied because a user who only uses email will not generate the same system workload as a user using email and collaborative services (Calendar, etc.) and a smartphone.
As a result, hardware sizing is calculated "per unit", on the following basis:
| User profile | Units |
|---|---|
| Email only | 1 |
| Email + intense collaborative use | 2 |
| Email + collaborative services + smartphone | 5 |
Also, for a same amount of units, a use of email only won't consume the same amount of resources as a use of email and collaborative services: unlike collaborative tools, email, for example, relies more heavily on IO than on CPU.
CPU
CPU is stated in number of cores. Reference values are based on recent Xeon-type server CPU.
BlueMind has multiple services, as a result we recommend a minimum of 2 cores.
Please note that too much CPU can cause other issues on virtualized environments (https://techan.fr/problemes-de-performance-sur-vmware-du-a-du-cpu-ready.html).
| Units | Number of core(s) |
|---|---|
| 1-200 | 2 |
| 200-1,000 | 4 |
| 1,000-2,000 | 6 |
| 2,000-3,000 | 8 |
| 3,000-6,000 | 12 |
| 6,000+ | 2 / 1,000 units |
RAM
| Units | RAM |
|---|---|
| 1-250 | 16 GB |
| 250-1,000 | 24 GB |
| 1,000-2,500 | 32 GB |
| 2,500-5,000 | 48 GB |
| 5,000-10,000 | 64 GB* |
| 10,000+ | 96 GB* |
*With the Cyrus service and bm-elasticsearch on dedicated servers
Storage / IO Performance
Disks and performance
An email system is very demanding on disks, for reading and writing small files, but also for message processing (indexing, read/write statuses, etc.). Disk quality and speed are key to an email system's performance.
IOPS = "Input/Output Operations Per Second"
Minimum disk performance
Storage is sized in IOPS as email is a heavy user of IO, whereas storage space directly depends on client requirements (quotas, etc.)
Depending on final usage, all disks will not require the same performance levels. Below are the minimum IOPS required for any installation:
| Mount Point | Description | NFS Type | Block Device Type | Minimum IOPS |
|---|---|---|---|---|
| /var/lib/postgresql | PostgreSQL database | ❌ | ✅ | 10,000 iops |
| /var/spool/cyrus/meta | email metadata | ❌ | ✅ | 10,000 iops |
| /var/spool/cyrus/data | emails | ❌ | ✅ | 6,000 iops |
| /var/spool/bm-hsm | archived emails | ✅ | ✅ | 6,000 iops |
| /var/spool/bm-elasticsearch | search index | ❌ | ✅ | 10,000 iops |
| /var/spool/bm-mail | EAS/mapi mail service ±2 GB | ✅ | ✅ | 6,000 iops |
| /var/log | logs | ✅ | ✅ | 6,000 iops |
| /var/backups/bluemind | backups | ✅ | ✅ | 6,000 iops |
For all installations with more than 2,000 users, anticipated iops can be calculated based on the number of users and usage:
:::
Mount point | Description | Type NFS | Type block device | Type Object Storage S3/Scality Ring | Minimum IOPS | Minimum volume |
|---|---|---|---|---|---|---|
/var/spool/cyrus/data | Email storage space | ✅ | ✅ | ✅ | 6,000 iops | Largest space, to be determined according to expected mail volume. |
/var/spool/bm-hsm | optional space for secondary storage emails | ✅ | ✅ | ❌ | 6,000 iops | |
/var/lib/postgresql | PostgreSQL database | ❌ | ✅ | ❌ | 10,000 iops | 5% of the volume of /var/spool/cyrus/data + /var/spool/bm-hsm |
/var/spool/bm-elasticsearch | ElasticSearch index data | ❌ | ✅ | ❌ | 10,000 iops | 10% of the volume of /var/spool/cyrus/data + /var/spool/bm-hsm Plan to leave at least 50% free space, except if ES dataprotect is disabled. We recommend using 2 separate partitions of equal size, attached to the sub-folders:
|
/var/spool/bm-mail | Send emails via EAS/mapi | ✅ | ✅ | ❌ | 6,000 iops | 2 GB |
/var/backups/bluemind | Backups DataProtect | ✅ | ✅ | ❌ | 6,000 iops | Sum of:
For /var/spool/cyrus/data + /var/spool/bm-hsm sizes greater than 1 TB, we recommend disabling DataProtect mail backup. You can use a third-party backup system and/or the [double bottom] recycle garbage can(/resolution_of_problems/problems_d_emission_and_reception_of_messages.md#restore) |
/var/spool/bm-mapi | Temporary service folders bm-mapi | ✅ | ✅ | ❌ | 6,000 iops | 2 Go |
/var/spool/bm-hollowed | Internal cache | ✅ | ✅ | ❌ | 10,000 iops | 1 Go |
/var/spool/bm-docs | Storage for user thumbnails, resources... | ✅ | ✅ | ❌ | 6,000 iops | 1 Mb per entity with thumbnail |
/var/spool/postfix | Mail queue | ✅ | ✅ | ❌ | 6,000 iops | 2 Gb |
/var/log | System and application logs | ✅ | ✅ | ❌ | 10,000 iops | 50 Gb |
/tmp | Temporary files | ✅ | ✅ | ❌ | N/A | 1.2G of volume is required to install BlueMind. This is related to unzipping the installer |
/usr/share | ✅ | ✅ | ❌ | N/A | 8GiB are required to contain web modules and applications. |
IOPS data for storage devices (Wikipedia)
| Device | Type | IOPS | Interface | Notes |
|---|---|---|---|---|
| 7,200 rpm SATA drives | HDD | ±75-100 IOPS [2] | SATA 3 Gbit/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 |
Source: http://en.wikipedia.org/wiki/IOPS
Checking disk performance
Caution
Make sure you follow these instructions carefully when performing these tests. Not applying caution may result in data loss or impact server performance.
To check your disks' performance, follow this test procedure:
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 is sensible.
Above this threshold, and to manage populations in the tens of thousands of users or more, the architecture must be distributed.
Also, the email part as well as the database (which collaborative use/smartphone places heavy demands on) must be kept separate from the rest.
Users / Units | Node | CPU #cores | RAM | IOPS / Disk |
|---|---|---|---|---|
25 users / 5 with smartphones 45 units (20 + 25) | 2 | 16 | 13.5 / all disks | |
150 users / 50 collaborative users of which 25 with smartphones 225 units (100+25 * 2+25 * 5) | 4 | 16 | 67,5 SATA 7,200 minimum | |
300 users / 100 collaborative users / 30 smartphones 490 units (200 + 70 * 2 + 30 * 5) | 4 | 24 | 147 2 * 10K rpm SAS 1 * 15K rpm SAS | |
600 users / 200 collaborative users / 50 smartphones 950 units (400 + 150 * 2 * 50 * 5) → 4 CPU, 24 GB of RAM | Core | 2 | 20 | 285 SSD, Bay or other system |
Edge | 2 | 4 | ||
1,000 users / 250 collaborative users / 100 smartphones 1,300 units (750 + 150 * 2 + 100 * 5) → 6 CPU, 32 GB of RAM | Core | 2 | 20 | 390 SSD, Bay or other system |
BM-ES | 2 | 8 | dedicated ES for more than 1TB of emails and archives | |
Edge | 2 | 4 | ||
2,000 users / 500 collaborative users / 200 smartphones 3,100 units (1500 + 300 * 2 + 200 * 5) → 12 CPU, 48GB of RAM | Core | 6 | 20 | 930 Bay (2000 IOPS) |
BM-ES | 2 | 12 | dedicated ES from 1TB of emails and archives | |
Cyrus | 2 | 12 | Cyrus dédié à partir de 2To de mails et archives | |
Edge | 2 | 4 | ||
4,000 users / 1000 collaborative users / 300 smartphones 5,900 units (3000 + 700*2 + 300*5) → 12 CPU, 64GB of RAM | Core | 6 | 36 | 1770 Bay (2-3000 IOPS) |
BM-ES | 2 | 12 | dedicated ES from 1TB of emails and archives | |
Cyrus | 2 | 12 | dedicated Cyrus from 2TB of emails and archives | |
Edge | 2 | 4 | ||
4000 users / 1000 collaborative users / 1000 smartphones 8000 units (3000 + 1000 * 5) → 16 CPU, 64Go de RAM | Core | 6 | 36 | 2400 Bay 3000 IOPS SAN / other technonoly |
BM-ES | 4 | 12 | dedicated ES from 1TB of emails and archives | |
Cyrus | 4 | 12 | dedicated Cyrus from 2TB of emails and archives | |
Edge | 2 | 4 | ||
4000 users / 4000 collaborative users / 1000 smartphones 11000 units (3000 * 2 + 1000 * 5) → 22 CPU, 96Go de RAM | Core | 10 | 44 | 3300 Bay 3000 IOPS SAN / other technology |
BM-ES | 4 | 24 | dedicated ES from 1TB of emails and archives | |
Cyrus | 4 | 24 | dedicated Cyrus from 2TB of emails and archives consider 2 cyrus nodes | |
Edge | 2 | 4 | ||
5000+ users (10 000, 100 000,..) | 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.
You should note that the data on bandwidth usage of the BlueMind calendar and smartphones below clearly shows the prevalence 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 using 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 |
Including a safety margin, for 1,000 Calendars running in web browsers, this adds up to:
- 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:
- one ping every 5 seconds
- one "bmc" every 30 seconds
If we double the measured value to get a comfortable safety margin, the bandwidth would be 288 bytes per second for a user with the Contacts application open.
Smartphone bandwidth
Microsoft provides the following ActiveSync ratios: 1.04KB/s/user
i.e. for 100 smartphones: 104KB, or 13KB/s
With a comfortable safety x2 margin, this adds up to:
- 100 smartphones == 26KB/s
- 1,000 smartphones == 260KB/s