Capacity planning for Scalix installation

[seany]

Hi,

I've searched around but not found anything about this.

We are about to test migrating from Lotus Notes to Scalix for 300 users. I'm trying to find hints on how to spec out a server and configuration that will handle this with room to spare.

We currently have around 500gb of mail in Notes that will be migrated, and will be authenticating using OpenLDAP / Kerberos on a seperate server. A small number of users are wedded to their PDAs so will be using Outlook, whereas the rest will be connecting using Thunderbird and (hopefully) Lightnine / CalDAV.

Can anybody point out any useful resources on this topic?

Thanks,

Sean

[seany]

*bump*

Could anybody give me any real-world numbers for this please?

Thanks!

[Valerion]

Most current server setups (Dell, Sun, etc) should suffice. I have some numbers, but they applied to Scalix 9, not 11, so I won't quote them here.

First of all, you need at least 2GB of RAM in my experience. More is better, of course, but after this it is not as critical any more. Secondly, Scalix is extremely IO-bound. It continually reads and writes small files. You need a disk setup that can handle it. I would recommend SAS (since SCSI is no more) over a PATA/SATA setup (better seek times), and Scalix recommends a RAID-10 configuration above RAID-5. Plan to have at least double your current needs in storage, so you have room to expand.

The least important factor is CPU. For your number of users any modern CPU will suffice, server-class machines are usually dual-core or better anyway.

[seany]

Most current server setups (Dell, Sun, etc) should suffice. I have some numbers, but they applied to Scalix 9, not 11, so I won't quote them here.

First of all, you need at least 2GB of RAM in my experience. More is better, of course, but after this it is not as critical any more. Secondly, Scalix is extremely IO-bound. It continually reads and writes small files. You need a disk setup that can handle it. I would recommend SAS (since SCSI is no more) over a PATA/SATA setup (better seek times), and Scalix recommends a RAID-10 configuration above RAID-5. Plan to have at least double your current needs in storage, so you have room to expand.

The least important factor is CPU. For your number of users any modern CPU will suffice, server-class machines are usually dual-core or better anyway.

Thanks for the reply!

You've sort of confirmed what I suspected, which is that it'll be i/o bound. We're replacing a Domino server and the current data will need to be migrated in. It currently stands at around 540gb, with 300 users. My main concern is that one mailbox apparently has > 100000 items in an imap folder. I assume this is a spam drop or admin log mailbox (need to check), which won't be read via imap, but will this amount of stuff in one directory/imap folder hurt performance too?

Thanks again for your help.

Sean

[Valerion]

Performance will only be an issue when that mailbox is being read. And IMAP does have a cache, speeding up access somewhat (in SWA's case, a lot). There was a problem with earlier versions where a folder could not contain more than 32k items, but it has been rectified in Scalix 11. That folder needs to be tested, but I can't see any problems offhand.

On disk, Scalix stores files in body parts. Each message is stored as a container file, then the header, the body and each attachment are saved seperatedly, with the container file pointing to them and the order. A pointer to the container file is then written into each mailbox. So you end up with an enormous amount of small files very quickly. Check your inodes (if your filesystem has that concept) every now and again.

When you do an IMAP migration a duplicate of each message currently gets stored. Never been an issue for me, but I also haven't migrated 500GB this way myself. I know Scalix is working on solving this, but I can't give you timeframes on this.

<EDIT>

I suggest you have your reseller talk to Florian and/or Chris (if you are in EMEA) on this issue and advise you properly.