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.
The vCPU and/or RAM resources indicated below are understood to be dedicated to virtual machines. In other words, these resources must be excluded from any sharing with other virtual machines. In fact, particular care must be taken not to place BlueMind instances in a context where the hypervisor(s) is (are) in overcommit status.
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 includes many services, so we recommend 2 cores minimum.
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 24 GB RAM minimum.
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 mandatory for new installations and strongly recommended for upgrades from version 4, unless the existing hardware is fully satisfactory. 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 | Object Storage S3/Scality Ring Type | Minimal size |
---|---|---|---|---|
/var/spool/cyrus/data | Email storage | ❌ | ✅ | Largest space, to be determined based on the expected mail volume. |
/var/spool/bm-hsm | Optional** secondary storage space for emails | ⚠️ | ❌ | |
/var/lib/postgresql | PostgreSQL database | ❌ | ❌ | 5% of the volume of |
/var/spool/bm-elasticsearch | ElasticSearch index data | ❌ | ❌ | 10% of the volume of |
/var/spool/bm-mail | Sending emails via EAS/mapi | ❌ | ❌ | 2 GB |
/var/backups/bluemind | DataProtect backups | ✅ | ❌ | Sum of: |
/var/spool/bm-mapi | bm-mapi temporary folders | ❌ | ❌ | 2 GB |
/var/spool/bm-hollowed | Internal Cache | ❌ | ❌ | 1 Go |
/var/spool/bm-docs | Storage of user thumbnails, resources, etc... | ❌ | ❌ | 1 MB per entity with thumbnail |
/var/spool/postfix | Email Queue | ❌ | ❌ | 2 GB |
/var/log | System and application logs | ❌ | ❌ | 50 GB |
/tmp | Temporary files | ❌ | ❌ | 1.2GB of data is required to install BlueMind. This is due to installer unzipping |
/usr | ❌ | ❌ | 8GB are required for web modules and applications. |
Favoring object storage for better results than NFS mounts, especially if the block storage used is network-based (e.g. Ceph, iSCSI SAN).
The use of fast "full-flash" storage arrays is a good thing. However, special care must be taken to keep latencies low between the BlueMind instance and the storage infrastructure. **BlueMind recommends that IOPS not exceed 10ms.
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
Find out more
Related BlueMind documentation pages
Footnotes
-
IOPS: "In/Out per second". ↩