Hardware sizing
The data provided here is for information purposes only. Usage may vary for a same number of users, depending on hardware structure and use habits. The number of emails, their size, the number of recipients in the emails, the number of appointments, planning... this all is very different from one installation to another.
About units
A BlueMind system is made up of multiple components that use up resources.
The basic calculation "per user" is not valid, because a user who only uses the mail section will not use the system in the same way as a user who uses mail and collaborative tools (calendar, …), or a user who uses mapi.
As a result, hardware sizing is calculated "per unit", on the following basis:
| User profile | Cost per Unit |
|---|---|
| Mail only | 1 |
| Mail + intensive collaboration | 2 |
| Mail + collaborative + mapi | 5 |
Similarly, for the same number of units, a mail-only application will not consume the same amount of resources as a mail + collaborative application (for half the number of users). Mail, for example, is more IO-dependent than CPU-dependent, which is generally the opposite of the case for collaborative tools.
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.
Note that allocating too many CPUs can lead to other problems on virtualized environments.
| Units | Number of cores |
|---|---|
| 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
We recommend a minimum of 24 GB RAM.
| Units | Ram |
|---|---|
| 1-1000 | 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 relocation of the bm-elasticsearch service to a dedicated server
Storage / IO Performance
Disc type
An email system is very demanding on disks, for reading and writing small files, but also for message processing (indexing, read/write statuses, etc.). The quality and speed of disks is a key factor in high-performance mail.
The use of SSD/nvme disks is strongly recommended. Mechanical / rotational disks have high latencies that are incompatible with the software. The latter can eventually be used for backups or in hierarchical storage, behind high-performance SSDs/nvmes.
Minimum performance and volume of disks
Storage is sized in Input/Output Operations Per Second (IOPS)1, as a messaging service is a heavy consumer of IO.
Depending on the end use, not all disks need to have the same level of performance, nor the same volume.
The minimum volumes given below are estimates and may vary according to the installation and the evolution of the organization. It is therefore preferable to use technologies that allow simple expansion of FS (LVM, etc.).
Mount Point | Description | NFS Type | Block Device Type | Object Storage S3/Scality Ring Type | Minimum IOPS | Minimal size |
|---|---|---|---|---|---|---|
/var/spool/cyrus/data | Email storage | ✅ | ✅ | ✅ | 6,000 iops | Largest space, to be determined based on the expected mail volume. |
/var/spool/bm-hsm | Optional** secondary storage space for 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 (The space used on this partition is doubled during a DataProtect restore) |
/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% of free space, unless data protection is disabled for ES. We recommend using 2 distinct partitions, of equal sizes, attached to the subfolders: |
/var/spool/bm-mail | Sending emails via EAS/mapi | ✅ | ✅ | ❌ | 6,000 iops | 2 GB |
/var/backups/bluemind | Backups DataProtect | ✅ | ✅ | ❌ | 6,000 iops | Sum of: /var/spool/cyrus/data, /var/spool/bm-hsm, /var/lib/postgresql and /var/spool/bm-elasticsearch/data. For sizes of /var/spool/cyrus/data + /var/spool/bm-hsm greater than 1 TB, we recommend deactivating the DataProtect backup of emails. You can use a third-party backup system and/or the double bottom trash. |
/var/spool/bm-mapi | Temporary service folders bm-mapi | ✅ | ✅ | ❌ | 6,000 iops | 2 GB |
/var/spool/bm-hollowed | Internal Cache | ✅ | ✅ | ❌ | 10,000 iops | 1 Go |
/var/spool/bm-docs | Storage of user thumbnails, resources, etc... | ✅ | ✅ | ❌ | 6,000 iops | 1 MB per entity with thumbnail |
/var/spool/postfix | Email Queue | ✅ | ✅ | ❌ | 6,000 iops | 2 GB |
/var/log | System and application logs | ✅ | ✅ | ❌ | 10,000 iops | 50 GB |
/tmp | Temporary files | ✅ | ✅ | ❌ | N/A | 1.2GB of disk space is required to install BlueMind. This is due to installer unzipping |
/usr/share | ✅ | ✅ | ❌ | N/A | 8GB are required for web modules and applications. |
Examples
Core/RAM distribution over several servers (virtual or otherwise) is not described here:
- up to 24 GB RAM, we believe it's a good idea to install them all on the same platform.
- beyond 24 GB RAM, the architecture can be distributed
- to manage populations of tens of thousands of users or more, the mail section and the database (very much in demand for collaborative work / mapi) need to be separated.
Users / Units | Node | CPU (cores) | RAM in GB | IOPS / Disk |
|---|---|---|---|---|
25 users / 5 with mapi 45 units (20 + 25) | 2 | 24 | 13,5 SSD | |
150 users / 50 collaborative, including 25 with mapi 225 units (100+25 * 2+25 * 5) | 4 | 24 | 67,5 SSD | |
300 users / 100 collaborative / 30 mapi 490 units (200 + 70 * 2 + 30 * 5) | 4 | 24 | 147 SSD | |
600 users / 200 collaborative / 50 mapi 950 units (400 + 150 * 2 * 50 * 5) → 4 CPUs, 24 GB of RAM | Core | 2 | 20 | 285 SSD, Bay or other system |
Edge | 2 | 4 | ||
1000 users / 250 collaborative / 100 mapi 1300 units (750 + 150 * 2 + 100 * 5) → 6 CPUs, 32 GB of RAM | Core | 2 | 20 | 390 SSD, Bay or other system |
BM-ES | 2 | 8 | Dedicated ES from 1TB of mail and archives | |
Edge | 2 | 4 | ||
2000 users / 500 collaborative / 200 mapi 3100 units (1500 + 300 * 2 + 200 * 5) → 12 CPUs, 48GB of RAM | Core | 6 | 20 | 930 Bay (2000 IOPS) |
BM-ES | 2 | 12 | Dedicated ES from 1TB of mail and archives | |
Mail backend | 2 | 12 | Dedicated backend for 2TB or more of mail and archives | |
Edge | 2 | 4 | ||
4000 users / 1000 collaborative / 300 mapi 5900 units (3000 + 700 * 2 + 300 * 5) → 12 CPUs, 64GB of RAM | Core | 6 | 36 | 1770 Bay (2-3000 IOPS) |
BM-ES | 2 | 12 | Dedicated ES from 1TB of mail and archives | |
Mail backend | 2 | 12 | Dedicated backend for 2TB or more of mail and archives | |
Edge | 2 | 4 | ||
4000 users / 1000 collaborative / 1000 mapi 8000 units (3000 + 1000 * 5) → 16 CPUs, 64GB of RAM | Core | 6 | 36 | 2400 SAN / other technology |
BM-ES | 4 | 12 | Dedicated ES from 1TB of mail and archives | |
Mail backend | 4 | 12 | Dedicated backend for 2TB or more of mail and archives | |
Edge | 2 | 4 | ||
4000 users / 4000 collaborative / 1000 mapi 11000 units (3000 * 2 + 1000 * 5) → 22 CPUs, 96GB of RAM | Core | 10 | 44 | 3300 SAN / other technology |
BM-ES | 4 | 24 | Dedicated ES from 1TB of mail and archives | |
Mail backend | 6 | 24 | Dedicated backend for 2TB or more of mail and archives | |
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)
So:
- Client to server: 215 bytes/sec (1,067+5,388)/30
- Server to client: 56 bytes/sec (293+1,398)/30
| 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
ActiveSync ratios are provided by Microsoft: 1.04kb /sec/user. i.e. for 100 smartphones: 104KB, or 13KB/s.
Taking a reasonable margin of x2, we will then count:
- 100 smartphones == 26KB/s
- 1,000 smartphones == 260KB/s
Footnotes
-
IOPS: "In/Out per second". ↩