Skip to main content

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 virtualized environments.

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 profileCost per Unit
Mail only1
Mail + intensive collaboration2
Mail + collaborative + mapi5

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.

UnitsNumber of cores
1-2002
200-1,0004
1,000-2,0006
2,000-3,0008
3,000-6,00012
6,000+2 / 1,000 units

RAM

We recommend 24 GB RAM minimum.

UnitsRam
1-100024 GB
1,000-2,50032 GB
2,500-5,00048 GB
5,000-10,00064 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.

Please Note

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/cyrus/data + /var/spool/bm-hsm.
Note: the space used on this partition is doubled during a Single-user restoration - DataProtect Navigator.

/var/spool/bm-elasticsearch

ElasticSearch index data

10% of the volume of /var/spool/cyrus/data + /var/spool/bm-hsm.

/var/spool/bm-mail

Sending emails via EAS/mapi

2 GB

/var/backups/bluemind

DataProtect backups

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 disabling DataProtect backup of e-mails. You can use a third-party backup system and/or double bottom trash can.

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

NFS

Favoring object storage for better results than NFS mounts, especially if the block storage used is network-based (e.g. Ceph, iSCSI SAN).

Virtualized environments

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 usersClient to ServerServer to Client
1215 B/s56 B/s
10021 KB/s6 KB/s
1,000210 KB/s60 KB/s
10,0002.1 MB/s600 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

  1. IOPS: "In/Out per second".