Thank you all for replies!!! Some missing infos... - As load balancer I'm using a pair of keepalived with simple setup and not the DNS - Load balancer algorithm is "Weighted Least-Connection" - About 20 domains and 3000 email - I'm monitoring my backend servers with poolmon - The backend servers are virtual machine (vmware) with datastore on "all flash" storage based on yours notes, I think the better choice is Replication. Correct? Thanks, Andrea Il 16/07/20 01:43, Gerald Galster ha scritto:>> I built an email system using a proxy / director pair (IMAP, POP3, LMTP) >> and a backend pair. >> >> To have an HA system, I would like to understand if it is better to use >> an NFS export or replication to save emails and index files >> >> NFS is provided by a NAS (in HA), while for replication I would use the >> local backend disks >> >> Which of the two systems is more reliable? Are there any drawbacks for >> one or the other? > This decision is more about how many users you have in total and how you > can partition them. > > A) 200 domains with 10 IMAP accounts each > > For high availability two dovecot servers with replication are sufficient, > no director/nfs needed. Return both server ips via dns for imap.domain.com > and you get active/active load balancing for free. > > There is no shared storage which means no locking problems. > Dovecot can use optimizations like mmap which is not possible with nfs. > > > B) 200000 IMAP accounts, all within the same domain > > You cannot partition by domain and a single server cannot handle the load. > > Here imap.domain.com could return e.g. 5 ips via DNS that point to your directors. > The director's job is to send all connections of one particular user to the > same backend, i.e. Outlook at work, Thunderbird at home and K9 Mail on a > mobile phone could be active at the same time, but all are directed to the > same backend server. This way locking issues with nfs are avoided because > only one server is accessing the mailbox at a time. > > IIRC you need to monitor your backend servers and add/remove them on failure. > > If the nfs mount is not available on the backend, dovecot may create > a new (empty) mailbox, which could break things. You need to set permissions > in a way that cannot happen. > > > C) like B) but with a static proxy mapping where users are assigned to a > certain backend server by configuration, that could be replicated like A) > without nfs. > > > While A) in principle has a higher performance due to local disks and > optimizations B) can have a higher overall performance as dedicated > storage appliances usually have a lot more disks (ssd caching, ...) > and 10G+ networking. > > C) avoids nfs but may introduce more complexity when software like pacemaker > is used to provide failover. > > See https://wiki2.dovecot.org/Director and https://wiki2.dovecot.org/NFS > > > Best regards > Gerald > > > >-- __________________________ One person's error is another person's data. __________________________ TIM San Marino S.p.A. Andrea Gabellini Engineering R&D TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188 -- Informativa Privacy Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a privacy at telecomitalia.sm. Avviso di Riservatezza Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge.
> Some missing infos... > > - As load balancer I'm using a pair of keepalived with simple setup and > not the DNS > - Load balancer algorithm is "Weighted Least-Connection" > - About 20 domains and 3000 email > - I'm monitoring my backend servers with poolmon > - The backend servers are virtual machine (vmware) with datastore on > "all flash" storage > > based on yours notes, I think the better choice is Replication. Correct?In my experience it's best to keep complexity low because the fewer components you have, the fewer can fail. With replication you basically have two independent servers that asynchronously sync emails. While it would work with loadbalancers/keepalived/director they are not necessary. If this is the way you want to go you should configure the loadbalancer to always send the same source-ip to the same backend (ip stickyness). Mailclients do open several connections in parallel and they should see the same data. With DNS this happens automatically because ips are rotated by resolvers and the mailclient gets the same ip for all its connections. Failover is builtin as mailclients just connect to the second ip when the first is not reachable. Replication works reliable with mdbox/sdbox but you should avoid maildir. Best regards Gerald
Il 16/07/20 12:40, Gerald Galster ha scritto:>> Some missing infos... >> >> - As load balancer I'm using a pair of keepalived with simple setup and >> not the DNS >> - Load balancer algorithm is "Weighted Least-Connection" >> - About 20 domains and 3000 email >> - I'm monitoring my backend servers with poolmon >> - The backend servers are virtual machine (vmware) with datastore on >> "all flash" storage >> >> based on yours notes, I think the better choice is Replication. Correct? > In my experience it's best to keep complexity low because the fewer > components you have, the fewer can fail. With replication you basically > have two independent servers that asynchronously sync emails.I completely agree!!!> > While it would work with loadbalancers/keepalived/director they are not > necessary. If this is the way you want to go you should configure the > loadbalancer to always send the same source-ip to the same backend > (ip stickyness). Mailclients do open several connections in parallel > and they should see the same data.In my setup the load balancers do exactly this, and the director map the same username/email (not the same source IP) to the same backend server. Director setup is not so complex and I trust it> With DNS this happens automatically because ips are rotated by resolvers > and the mailclient gets the same ip for all its connections. Failover > is builtin as mailclients just connect to the second ip when the first > is not reachable.I don't trust DNS load balancing. I saw too many times a client stuck with the wrong (down) IP... This is my experience ;-)> > Replication works reliable with mdbox/sdbox but you should avoid maildir.I'm using and I like Maildir. There are some documentation about to don't use it with replication? Which are the drawbacks? Thanks, Andrea> > Best regards > Gerald-- __________________________ A picture tells a thousand words. To make a picture costs more than a thousand words. A picture is slower than a thousand words. __________________________ TIM San Marino S.p.A. Andrea Gabellini Engineering R&D TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188 -- Informativa Privacy Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a privacy at telecomitalia.sm. Avviso di Riservatezza Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge.