On 3/11/20 1:18 AM, Phil Pennock via Exim-users wrote:
> Caveat: the guarantee of SMTP is that you have responsibility once you
> accept the message, so think carefully about the resiliency of the spool
> directory for the servers in front of the NAS, and how you'd recover if
> a machine or VM dies.
Thanks Phil! I think I have this mostly covered as the MX's and their
storage have some HA/availability/redundancy worked into them. We'll
certainly slip the spool path into a backup plan now. Thanks for the tip.
> If you're avoiding a dependency on the NAS to avoid a single-point of
> failure, think about the datastore for the lookups. Resilient RDBMS is
> one approach, but building a directory of CDB files and distributing
> them might be another approach. One thing I've done in the past is to
> have a symlink for the current CDB dir pointing to the current
> generation, then for updates copy the current generation, rsync the
> updates, then once the rsync is done update the symlink atomically.
Recovering from a NAS failure is already planned. We will be using ZFS
storage with snapshot and replication to another host. In the event the
whole NAS died we'd be able to clone out the snapshot and move the
mountpoint to the other server with minimal loss.
I guess at this point it's a matter of how much downtime we're willing
to tolerate to make that manual switch. We have several thousand
mailboxes so we'll be splitting the load over two or more NAS
appliances, so we would have to account for any one of them failing and
taking their mailboxes offline for a period of time...
On way might be to make the POP/IMAP access tied to the storage in which
their mailboxes reside. That way if we lose a single NAS only a subset
of users mailboxes are unavailable and not everyone. Doesn't help, but
limits the fault domain.
> There are front-end application-layer proxies for IMAP/POP3 which let
> you assemble a bunch of mailstores on separate servers into one unified
> namespace, so that you can present `imap.example.org` for the entire
> domain. Or, you might just tell the customer which server is theirs,
> but still think about keeping those names virtual, so that you can move
> servers without needing customers/clients to all update.
I think we're thinking along the same lines above... (sort of)
--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:
https://pgp.inoc.net/rblayzor/
