[Dovecot] High Availability strategies
Hi,
we have a medium setup (8000 pop and imap users using almost every available client, 800GB of stored mails using maildir on a Celerra NFS server, with index files on local disks, and procmail for local delivery), being served by a Dell PowerEdge 2850 (2GB RAM and dual P4 Xeon 3,2GHz).
Our current not-so-high availability setup is based on a similar server with the same setup and a easy but manual process to switch from one server to another.
We are thinking about setting up some kind of serious high availability, but for every strategy we think about some problems appear, and I'd like to hear your opinions about them:
- The recommended setup, with each user being sent always to the same server, is not possible because our load balancers (Cisco Catalyst
- can't do that.
We could put both servers behind the load balancer, and keep local index files on each server. Usually the same ip we'll be redirected to the same server, so few problems will arise. When a user is sent to a new server, index will be rebuilt so performance will be bad but we should not expect other problems, right?
We could also put the index files on a nfs share. No problems, but pretty bad performance.
We could also get more ram for the servers and keep indices in memory.
How can we compare these solutions? Apart from performance, are other problems expected? Using deliver instead of procmail could improve performance?
- We've also thought about some more or less weird setups, like setting up a GFS filesystem for the index files, or setting up a proxy on every server which redirect users to their fixed server, but they seem too complex for few advantages.
Any recommendations? How are you doing this?
Joseba Torre. Vicegerencia de TICs, área de Explotación
Joseba Torre schrieb:
Hi,
we have a medium setup (8000 pop and imap users using almost every available client, 800GB of stored mails using maildir on a Celerra NFS server, with index files on local disks, and procmail for local delivery), being served by a Dell PowerEdge 2850 (2GB RAM and dual P4 Xeon 3,2GHz).
Our current not-so-high availability setup is based on a similar server with the same setup and a easy but manual process to switch from one server to another.
We are thinking about setting up some kind of serious high availability, but for every strategy we think about some problems appear, and I'd like to hear your opinions about them:
- The recommended setup, with each user being sent always to the same server, is not possible because our load balancers (Cisco Catalyst
- can't do that.
We could put both servers behind the load balancer, and keep local index files on each server. Usually the same ip we'll be redirected to the same server, so few problems will arise. When a user is sent to a new server, index will be rebuilt so performance will be bad but we should not expect other problems, right?
We could also put the index files on a nfs share. No problems, but pretty bad performance.
We could also get more ram for the servers and keep indices in memory.
How can we compare these solutions? Apart from performance, are other problems expected? Using deliver instead of procmail could improve performance?
- We've also thought about some more or less weird setups, like setting up a GFS filesystem for the index files, or setting up a proxy on every server which redirect users to their fixed server, but they seem too complex for few advantages.
Any recommendations? How are you doing this?
search the list archive, this was disscussed before a ha balance setup with gfs like filesystem is possible and working, sorry about cisco i only did small tests plain ha linux setups with a layout of 4 servers 2 ha loadbalancers and 2 postfix/dovecot servers on ubuntu with one cluster ip, but posibilities are serveral ways to goal what you need, so fitting to local network layouts is always needed as well as hard testing before production stage
is always needed
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Joseba Torre wrote:
Hi,
we have a medium setup (8000 pop and imap users using almost every available client, 800GB of stored mails using maildir on a Celerra NFS server, with index files on local disks, and procmail for local delivery), being served by a Dell PowerEdge 2850 (2GB RAM and dual P4 Xeon 3,2GHz).
Our current not-so-high availability setup is based on a similar server with the same setup and a easy but manual process to switch from one server to another.
If you don't care about keeping an active/standby setup and you're happy with what you've currently got going on, you can easily automate the process with heartbeat.
~Seth
On Jul 24, 2009, at 5:00 AM, Joseba Torre wrote:
we have a medium setup (8000 pop and imap users using almost every available client, 800GB of stored mails using maildir on a Celerra NFS server, with index files on local disks, and procmail for local delivery), being served by a Dell PowerEdge 2850 (2GB RAM and dual P4 Xeon 3,2GHz).
Our current not-so-high availability setup is based on a similar server with the same setup and a easy but manual process to switch from one server to another.
So you currenly have a single server serving all imap/pop3 users?
- The recommended setup, with each user being sent always to the same server, is not possible because our load balancers (Cisco Catalyst
- can't do that.
- We could put both servers behind the load balancer, and keep local index files on each server. Usually the same ip we'll be redirected to the same server, so few problems will arise. When a user is sent to a new server, index will be rebuilt so performance will be bad but we should not expect other problems, right?
If a single server can handle all users fine, I wouldn't try anything
special here. Just have them work as a master/slave and install some
kind of a heartbeat to switch between them.
- We could also put the index files on a nfs share. No problems, but pretty bad performance.
If there's only a single server accessing the mails, you can use
mail_nfs_*=no and the performance shouldn't be that bad.
- We could also get more ram for the servers and keep indices in memory.
I'd say local disk is much better.
Using deliver instead of procmail could improve performance?
http://wiki.dovecot.org/LDA/Indexing
- We've also thought about some more or less weird setups, like setting up a GFS filesystem for the index files, or setting up a proxy on every server which redirect users to their fixed server, but they seem too complex for few advantages.
Assuming still a master/slave setup, you could use DRBD to replicate
indexes between local disks.
I think there is a whitepaper from Dovecot's current main sponsor (before they were called Rackspace) which described their architecture using pairs of servers and DRBD between them. Each server is moderately loaded and active. If one server fails then half the users don't notice and the other half get switched over to what is really their slave server.
Seemed like an elegant architecture...
Is this stuff archived anywhere Timo?
Ed W
Ed W wrote:
I think there is a whitepaper from Dovecot's current main sponsor (before they were called Rackspace) which described their architecture using pairs of servers and DRBD between them. Each server is moderately loaded and active. If one server fails then half the users don't notice and the other half get switched over to what is really their slave server.
Seemed like an elegant architecture...
It's stupidly simple but it works. If you have two spare systems to make a lab out of you'll be surprised how easy it really is. The only thing I hate about it is the idle slave hardware just because I feed bad about powerful machines sitting around waiting for something to happen.
~Seth
On Mon, 2009-07-27 at 10:22 -0700, Seth Mattinen wrote:
Ed W wrote:
I think there is a whitepaper from Dovecot's current main sponsor (before they were called Rackspace) which described their architecture using pairs of servers and DRBD between them. Each server is moderately loaded and active. If one server fails then half the users don't notice and the other half get switched over to what is really their slave server.
The whitepaper is pretty outdated, I don't think we want to show it to people anymore. :)
Seemed like an elegant architecture...
It's stupidly simple but it works. If you have two spare systems to make a lab out of you'll be surprised how easy it really is. The only thing I hate about it is the idle slave hardware just because I feed bad about powerful machines sitting around waiting for something to happen.
Another possibility is to do cross-replication, i.e. server a is replicating to b, and b is replicating to a. The problem with that is that if either one breaks, the other server now handles twice the number of users..
BTW. http://dovecot.org/talks/berlin-2009-07-02.pdf has a list of some possible ways to cluster Dovecot.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 27 Jul 2009, Timo Sirainen wrote:
BTW. http://dovecot.org/talks/berlin-2009-07-02.pdf has a list of some possible ways to cluster Dovecot.
IMO You should place all slides and conference papers online - at least I did not found them on dovecot.org ... . Some people asked me lately about how professional Dovecot is.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSnAY8HWSIuGy1ktrAQJJNgf/bNkRmQPSzN+scVAaHmnRVp4Q+BZaCETF ybDsZo6THC6xAG73ZDcGHJQpIt5F9WFo4Gvft4JK/m3cL86LQ2fa2qlZgOo6vPgJ FsXhtUHRPd5AyC6UgbRMgjNj5u1H9L86dz+XM1DSDKYUCMZuwD+jBahCXhMMzBNC FoeENhx+XgU2T8JsaPTXMS2Z0qpjTblyT7WwarKk69F9q1BsCT1IdDgvLwOkIq+G 4WghwWNM5MW6NjLLmGjGP/jfdSa5LB1gs6DFBqmTuK7FHB9nR6OqCWagUninBPlS T2ILMVtNhsTx3/D/q97QDBQN7TMKSOk5Okmn6rpUlRn2uvwU3YhCvw== =4C0o -----END PGP SIGNATURE-----
On Jul 29, 2009, at 5:39 AM, Steffen Kaiser wrote:
On Mon, 27 Jul 2009, Timo Sirainen wrote:
BTW. http://dovecot.org/talks/berlin-2009-07-02.pdf has a list of
some possible ways to cluster Dovecot.IMO You should place all slides and conference papers online - at
least I did not found them on dovecot.org ... . Some people asked me lately about how professional Dovecot is.
There aren't really many yet. Slides about the couple of talks are in / talks/..
Thanks a lot for all the answers. We already have high availability on the storage, so we'll go with Timo's proposal, mainly because it's the closer one to our current situation.
Thanks!
El Sábado 25 Julio 2009 a las 01:58, Timo Sirainen escribió:
On Jul 24, 2009, at 5:00 AM, Joseba Torre wrote:
we have a medium setup (8000 pop and imap users using almost every available client, 800GB of stored mails using maildir on a Celerra NFS server, with index files on local disks, and procmail for local delivery), being served by a Dell PowerEdge 2850 (2GB RAM and dual P4 Xeon 3,2GHz).
Our current not-so-high availability setup is based on a similar server with the same setup and a easy but manual process to switch from one server to another.
So you currenly have a single server serving all imap/pop3 users?
The recommended setup, with each user being sent always to the same server, is not possible because our load balancers (Cisco Catalyst 6000) can't do that.
We could put both servers behind the load balancer, and keep local index files on each server. Usually the same ip we'll be redirected to the same server, so few problems will arise. When a user is sent to a new server, index will be rebuilt so performance will be bad but we should not expect other problems, right?
If a single server can handle all users fine, I wouldn't try anything special here. Just have them work as a master/slave and install some kind of a heartbeat to switch between them.
- We could also put the index files on a nfs share. No problems, but pretty bad performance.
If there's only a single server accessing the mails, you can use mail_nfs_*=no and the performance shouldn't be that bad.
- We could also get more ram for the servers and keep indices in memory.
I'd say local disk is much better.
Using deliver instead of procmail could improve performance?
http://wiki.dovecot.org/LDA/Indexing
- We've also thought about some more or less weird setups, like setting up a GFS filesystem for the index files, or setting up a proxy on every server which redirect users to their fixed server, but they seem too complex for few advantages.
Assuming still a master/slave setup, you could use DRBD to replicate indexes between local disks.
-- Joseba Torre. Vicegerencia de TICs, área de Explotación
participants (6)
-
Ed W
-
Joseba Torre
-
Robert Schetterer
-
Seth Mattinen
-
Steffen Kaiser
-
Timo Sirainen