[Dovecot] Dovecot and SATA Backend

[Nicolas GRENECHE]

2009/11/16 Eric Jon Rostetter <eric.rostetter at physics.utexas.edu>:
> Quoting Nicolas GRENECHE <nicolas.greneche at gmail.com>:
>
>> I plan to run a dovecot IMAPS and POPS service on our network. We
>> handle about 3 000 mailboxes. I thought first buying a topnotch server
>> (8 cores and 16 Go RAM) with equalogic iSCSI SAN SAS 15K for storage
>> backend.
>
> Sounds like overkill to me, but if you have the money go for it. :)
>

I prefer disk space to useless storage velocity ;-)

> I run mine on an 8 core (dual quad core) system with 4G RAM, using
> SATA (would have preferred SAS, but cost was an issue for us).
>
>> created on a separete local filesystem. My question is : for 3000
>> users, is it possible to have only a SATA backend attached to my
>> topnotch server (to handle bigger mail quotas) by storing index on
>> local hard drives (SAS drives) ?
>
> Sure.  If you only have one dovecot server without any failover this
> is fine.  If you have multiple (active or passive) servers then more care
> is required, and you need to decide on the level of risk you want to take.
>
>> Extra question, what is the better : iSCSI SATA backend or NFS share ?
>
> iSCSI would be better than NFS IMHO.
>
>> NFS share is more convenient to have a failover server.
>
> If you introduce NFS and/or a failover server, your local index question
> gets much more complex...
>

I know it, index may be handled on NFS server on fast local hardrives.
The whole stuff should be exported to dovecot server.

> Is that a design requirement, desire, or future option?
>

It should be a future option, but index management will be more tricky
as you stated.

>> Thanks for your help.
>>
>> Regards,
>>
>> --
>> Nicolas Grenèche - Orléans University - France
>> http://blog.garnett.fr (in french)
>
>
> --
> Eric Rostetter
> The Department of Physics
> The University of Texas at Austin
>
> This message is provided "AS IS" without warranty of any kind,
> either expressed or implied.  Use this message at your own risk.
>