> For such a project, I would simply configure the SMTP server do to > protocol-specific replication and use a low-TTL DNS name to publish > the IMAP/Web frontends.Either you know something about mail servers that I would love to know myself, or else this idea won't work. That's because even if you could configure three SMTP servers as relays to each-other (which you cannot), IMAP actions (move, delete etc) do not propagate. So, one day you organise your mail nicely in folders, next day you find all of it back in your inbox. Or you go looking in your Sent folder for that mail you sent last week, and it's just not there. That kind of thing would probably frustrate everyone much more than a bit of latency. Z
Il 2020-12-27 21:58 Zenon Panoussis ha scritto:>> For such a project, I would simply configure the SMTP server do to >> protocol-specific replication and use a low-TTL DNS name to publish >> the IMAP/Web frontends. > > Either you know something about mail servers that I would love > to know myself, or else this idea won't work. That's because > even if you could configure three SMTP servers as relays to > each-other (which you cannot), IMAP actions (move, delete etc) > do not propagate. So, one day you organise your mail nicely > in folders, next day you find all of it back in your inbox. > Or you go looking in your Sent folder for that mail you sent > last week, and it's just not there. That kind of thing would > probably frustrate everyone much more than a bit of latency.Uhm yes, what I wrote was quite confusing. I was really referring to something as that: https://wiki.dovecot.org/Replication Re-reading your original question, I think geo-replication should work: after all, if I understand it right, you would only use the remote/backup copy in case the primary/local server goes down. Right? However, you should carefully test if Gluster is, by itself, capable of the load you are going to put over it: considering that a mailserver can easily store millions of small files and Gluster relatively low file lookup performance, I would thoroughly test it before putting this setup into production. About the closing consideration about a "bit of latency", I think you are *way* over-optimistic for replica volumes: Gluster sync replication is very latency boud and, if things did not changed recently, it was strongly advised against running sync replication between WAN links. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti at assyoma.it - info at assyoma.it GPG public key ID: FF5F32A8
If you have a busy mail setup and your Bricks are spindles, you will have a lot of performance issues even if the Cluster is in a local DC. Dovecot replication works well in Master-Master setup On Mon, Dec 28, 2020 at 12:05 AM Zenon Panoussis <oracle at provocation.net> wrote:> > > For such a project, I would simply configure the SMTP server do to > > protocol-specific replication and use a low-TTL DNS name to publish > > the IMAP/Web frontends. > > Either you know something about mail servers that I would love > to know myself, or else this idea won't work. That's because > even if you could configure three SMTP servers as relays to > each-other (which you cannot), IMAP actions (move, delete etc) > do not propagate. So, one day you organise your mail nicely > in folders, next day you find all of it back in your inbox. > Or you go looking in your Sent folder for that mail you sent > last week, and it's just not there. That kind of thing would > probably frustrate everyone much more than a bit of latency. > > Z > > ________ > > > > Community Meeting Calendar: > > Schedule - > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC > Bridge: https://meet.google.com/cpu-eiue-hvk > Gluster-users mailing list > Gluster-users at gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-users >-- Respectfully Mahdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20201228/a24ca118/attachment.html>