Re: Redundant mail storage
Hack Kampbjørn schrieb am Fri, Mar 08, 2002 at 10:52:26AM +0100: [...] > > I'm planning an starting implementing a redundant mail system in 6 > months (maybe a year) so it's still only in the ideas fase. One thing I > wanted to test was using coda as storage and let coda's replication take > care of the mail storage synchronization. If cyrus was one single > threaded application there could be problems with file lock and caches, > but since cyrus is a combination of several daemons that already are > aware that the files get updated externally -- it may just work 8-) Well, this also depends on how your system is supposed to scale, but if you are planning to do more than just 10 mail accounts: Don't use coda for it. Maybe coda has changed A LOT in the last couple of weeks and I am dead wrong, but as far as I had a look on it regarding data snychronisation, going there is waste of time because: * coda is slow * coda cannot handle huge data stores - remember that coda keeps all structures is one (!) file If you want to do software data synchronisation, I recommend rsync (not very fast, but usable) or intermezzo (still buggy, but getty better and better). I think intermezzo is definitely the future but needs some more testing. Regards, Birger
Re: Redundant mail storage
Roland Pope wrote: > > From: "Birger Toedtmann" <[EMAIL PROTECTED]> > > Second (esp. if you cannot afford the hardware described above) you may > > set up the heartbeat package from www.linux-ha.org. It is very easy to > > create failover mechnisms with heartbeat, but there is still the problem > > of data synchronisation (heartbeat does not deal with that). I myself use > > heartbeat together with rsync, which is surely unidirectional but can be > > turned into somewhat "bidirectional" in combination with heartbeat: The > > "active" machine will permanently send its data to the backup machine > > (simple as that: I use a cronjob that tests whether we are active or not). > > Upon failfailover, the situation will reverse, which leaves data intact > > and up-to-date. However, note that rsync is slow, if you have lots of > > data, you should definitely think over the first alternative. > > > Birger, > > I am looking at implementing something like this at present. Would you be > able to provide a summary of what you had to do, and maybe any scripts you > had to build to get this to work? > > Thanks > Roland Pope I'm planning an starting implementing a redundant mail system in 6 months (maybe a year) so it's still only in the ideas fase. One thing I wanted to test was using coda as storage and let coda's replication take care of the mail storage synchronization. If cyrus was one single threaded application there could be problems with file lock and caches, but since cyrus is a combination of several daemons that already are aware that the files get updated externally -- it may just work 8-) -- Med venlig hilsen / Kind regards Hack Kampbjørn
Re: Redundant mail storage
From: "Birger Toedtmann" <[EMAIL PROTECTED]> > Second (esp. if you cannot afford the hardware described above) you may > set up the heartbeat package from www.linux-ha.org. It is very easy to > create failover mechnisms with heartbeat, but there is still the problem > of data synchronisation (heartbeat does not deal with that). I myself use > heartbeat together with rsync, which is surely unidirectional but can be > turned into somewhat "bidirectional" in combination with heartbeat: The > "active" machine will permanently send its data to the backup machine > (simple as that: I use a cronjob that tests whether we are active or not). > Upon failfailover, the situation will reverse, which leaves data intact > and up-to-date. However, note that rsync is slow, if you have lots of > data, you should definitely think over the first alternative. > Birger, I am looking at implementing something like this at present. Would you be able to provide a summary of what you had to do, and maybe any scripts you had to build to get this to work? Thanks Roland Pope
Re: Redundant mail storage
Paul Dekkers schrieb am Thu, Mar 07, 2002 at 02:11:11PM +0100: > Hi > > I'm looking for a redundant mail storage. Not just a seconday MX where mail > is temporarily stored on a second server, but just that when one server > crashes another server goes on with its normal tasks. > For mail I think it would be nice if all new messages go to both servers, > and when a message is read, it is removed from both servers. During downtime > then one server goes on with the normal tasks, and after some time the > server sends the server that is back up the data it missed. > > Using a single mailfile this is not possible I think, unless you write > something with a procmail script that delivers to two mailfiles, and hack > the pop3-daemon to delete files from both hosts. > With maildir however, this looks much better. Something like unison would be > nice then, since it seems to support bidirectional synchronisation; and > since there is no central database of the messages stored, it uses a diff to > change the other server. (Rsync is worse, because of the unidirectional > synchronisation I think... I might be wrong.) > Maybe also coda is a solution, but I never looked at it soo close, and it > looked a bit complex at first. You have two possible solution that I know workingi in reality. It depends on your money you'd like to spend which one you choose. First you can "cluster" two systems together via single SCSI bus and then use www.missioncritical.com's kimberlite to set up services that'll be switched upon failure. Data will reside on one partition which is mounted by the machine that deems itself active. This is a very smart solution, I have tested it with collegues. Anyway, it's somewhat expensive. Second (esp. if you cannot afford the hardware described above) you may set up the heartbeat package from www.linux-ha.org. It is very easy to create failover mechnisms with heartbeat, but there is still the problem of data synchronisation (heartbeat does not deal with that). I myself use heartbeat together with rsync, which is surely unidirectional but can be turned into somewhat "bidirectional" in combination with heartbeat: The "active" machine will permanently send its data to the backup machine (simple as that: I use a cronjob that tests whether we are active or not). Upon failfailover, the situation will reverse, which leaves data intact and up-to-date. However, note that rsync is slow, if you have lots of data, you should definitely think over the first alternative. Regards, Birger
Redundant mail storage
Hi I'm looking for a redundant mail storage. Not just a seconday MX where mail is temporarily stored on a second server, but just that when one server crashes another server goes on with its normal tasks. For mail I think it would be nice if all new messages go to both servers, and when a message is read, it is removed from both servers. During downtime then one server goes on with the normal tasks, and after some time the server sends the server that is back up the data it missed. Using a single mailfile this is not possible I think, unless you write something with a procmail script that delivers to two mailfiles, and hack the pop3-daemon to delete files from both hosts. With maildir however, this looks much better. Something like unison would be nice then, since it seems to support bidirectional synchronisation; and since there is no central database of the messages stored, it uses a diff to change the other server. (Rsync is worse, because of the unidirectional synchronisation I think... I might be wrong.) Maybe also coda is a solution, but I never looked at it soo close, and it looked a bit complex at first. However, my favorite pop/imap-server at the moment is Cyrus :-) With Cyrus I also see single files per message, but also a centralized database per folder. I think this is my problem. This file is changed on both hosts if e.g. a mail is delivered to both hosts when they aren't able to reach eachother... Is there any solution to this problem? (Except switch to a mail server that uses Maildir's like qmail...) Thank you in advance, Paul
