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.

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	Cost per Unit
Email only	1
Mail + intensive collaboration	2
Email + collaborative services + smartphone	5

Likewise for the same number of units, only email usage will not have the same resource consumption as an email + collaborative use (for half 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

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

:::info 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.

:::

info

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 the end use, not all disks need to have the same level of performance, nor the same volume.

info

These are mere estimates, which may vary depending on your install and your organization's evolution. We therefore recommend that you use technologies that enable you to increase the size of your file system easily...).

Mount Point	Description	NFS Type	Block device type	Minimum IOPS	Minimum storage capacity
/var/spool/cyrus/data	Email storage space	✅	✅	6,000 IOPS	The largest storage space; to be determined based on expected email volume.
/var/spool/bm-hsm	Optional space for secondary storage of emails	✅	✅	6,000 IOPS
/var/spool/cyrus/meta	Email metadata	❌	✅	10,000 IOPS	5% of the volume of /var/spool/cyrus/data /var/spool/bm-hsm
/var/lib/cyrus	MBX and Conversation Information	❌	✅	10,000 IOPS	5% of the volume of /var/spool/cyrus/data /var/spool/bm-hsm
/var/spool/sieve	Email Filtering Rules	✅	✅	6,000 IOPS	1 MB per user + shared mbx
/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 doubles 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 Be sure to leave at least 50% of the space free, unless Dataprotect is disabled for ES. We recommend using 2 distinct partitions, of equal sizes, attached to the subfolders: /var/spool/bm-elasticsearch/data /var/spool/bm-elasticsearch/repo
/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 /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 emails. You can use a third-party backup system and/or double bottom trash can
/var/spool/bm-mapi	Temporary directories for the bm-mapi service	✅	✅	6,000 IOPS	2 GB
/var/spool/bm-hollowed	Internal cache	✅	✅	10,000 IOPS	1 GB
/var/spool/bm-docs	Storage for user thumbnails, resources, etc.	✅	✅	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 storage space is required to install BlueMind. This is related to decompressing the installer
/usr/share		✅	✅	N/A	8 GiB is required to store the modules and web applications.

IOPS data for storage devices (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

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 in GB	IOPS / Disk
25 users / 5 with smartphones 45 units (20 + 25)		2	16	13.5 / any disk
150 users / 50 collaborative users, including 25 with smartphones 225 units (100 + 25 × 2 + 25 × 5)		4	16	67.5 SATA 7200 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 CPUs, 24 GB of RAM	Core	2	20	285 SSD, Bay, or other system
	Edge	2	4
1,000 users / 250 collaborative devices / 100 smartphones 1,300 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 plan starting at 1 TB of emails and archives
	Edge	2	4
2,000 users / 500 collaborative devices / 200 smartphones 3,100 units (1,500 + 300 * 2 + 200 * 5) → 12 CPUs, 48 GB of RAM	Core	6	20	930 Array (2,000 IOPS)
	BM-ES	2	12	Dedicated ES plan starting at 1 TB of emails and archives
	Cyrus	2	12	Cyrus is available for 2 TB or more of emails and archives
	Edge	2	4
4,000 users / 1,000 collaborative devices / 300 smartphones 5,900 units (3,000 + 700 * 2 + 300 * 5) → 12 CPUs, 64 GB of RAM	Core	6	36	1770 Array (2–3,000 IOPS)
	BM-ES	2	12	Dedicated ES plan starting at 1 TB of emails and archives
	Cyrus	2	12	Cyrus is available for 2 TB or more of emails and archives
	Edge	2	4
4,000 users / 1,000 collaborative devices / 1,000 smartphones 8,000 units (3,000 + 1,000 * 5) → 16 CPUs, 64 GB of RAM	Core	6	36	2,400 3,000 IOPS SAN / other technologies
	BM-ES	4	12	ES plan for 1 TB or more of emails and archives
	Cyrus	4	12	Cyrus is recommended for 2 TB or more of emails and archives
	Edge	2	4
4,000 users / 4,000 collaborative devices / 1,000 smartphones 11,000 units (3,000 * 2 + 1,000 * 5) → 22 CPUs, 96 GB of RAM	Core	10	44	3300 BAY 3000 IOPS SAN / other technologies
	BM-ES	4	24	ES plan for 1 TB or more of emails and archives
	Cyrus	6	24	Cyrus is recommended for 2TB or more of emails and archives Second Cyrus node to consider
	Edge	2	4
5,000 users and more (10,000, 100,000, etc.)	The system must be distributed, and its architecture must be designed according to the specific context.

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

for 100 smartphones: 104KB, or 13KB/s

For which we will be taking a reasonable margin of x2, which gives the following:

100 smartphones == 26KB/s

1,000 smartphones == 260KB/s