El mi�, 21-01-2004 a las 18:54, Chris Shenton escribi�: > identical.You could do the same, if you exported your main box via NFS > to the smaller box. Doesn't protect you against the > fire/coke/tripping single-point-of-failure though :-(
That's the point (no pun intended). We want to configure this backup system in order to avoid having a SPOF on the server without moving the SPOF somewhere else (the NFS server in your scenario). > You're cloning mail delivered to the main box via SMTP on the backup > box using QMQP. You could hack your POP/IMAP server to do likewise, > proxying POP/IMAP commands to the backup's mailboxes in addition to > changing the main server -- but that doesn't seem trivial. We've been I still haven't taken a look at the source code, at this point we're only trying to figure out the best way to do this... but as far as I understand how the qmail-ldap clustering works (and I've never used it, just read some docs and this list), whenever a server in a cluster receives a POP/IMAP connection for a mailbox which is stored on another server of the cluster, it proxies the connection to the right place instead of doing local access to the mailbox. We would only have to modify the behaviour of all this so that all the implied processes do both things: local delivery/access _and_ proxying to the backup. It shouldn't be that hard to make a quick-and-dirty(tm) hack, providing that the code to do everything we want to is already there. Maybe Claudio could sched some light about this... Of course we would also have to deal with errors on the connection with the backup, and provide some kind of mechanism (another queue?) to re-sync the backup whenever there's been a network glitch. How to do all this, don't break a thing and keep it compatible with qmail-ldap clustering is another story. :) > worrying the same issues, but want our backup server(s) at a remote > location: data copying over the WAN becomes expensive. For POP and IMAP we only need to forward the DELE commands to the backup (or forward everything and make the backup ignore everything but the DELEs), and for SMTP we could use compressed QMQP. :m Just a thought. > If you don't use shared storage, you're gonna have file > synchronization problems after you use your backup server, then your > main server comes up. Need to make sure clients only change one Yes, of course. As of now we only plan to have manual switches to and from the backup server. Before moving back to the primary server from the backup after a disaster, we could turn all the services down for a while wile we rsync the content of the mailboxes on the backup back to the primary server. > Gracias. De nada. :) Regards -- Vicente Aguilar <[EMAIL PROTECTED]> Departamento de Sistemas Tlf.: 965 98 71 92 Recursos en la Red, S.L.U. http://www.renr.es
