<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello all,</p>
<p>This email is by no means an "Educate me step by step" query, But
more of an inquiry about which direction to go based on your
experience. I've been working with Dovecot for some years now, so
the configuration of that piece is no stranger. However, Choosing
the right style of shared storage has proven to be somewhat of a
challenge. <br>
</p>
<p>A bit of background of what I need to provide service for:<br>
</p>
<p>~80,000 users, that will potentially grow throughout the future</p>
<p>~100 unique domains<br>
</p>
<p>Ability to scale horizontally. As resources grow, adding a node
(or group of nodes) with the exact configuration as the other
nodes. Director should be able to send the connection to a node
that has the same data as it's neighbors, Allowing high
availability.<br>
</p>
<p><br>
</p>
<p>What I've experimented with so far:<br>
</p>
<p><u>Server pairs, using dsync to replicate data between the nodes
- Director to send users to a specific pair (director_tag
returned from passdb)<br>
</u></p>
<p> Pros:<br>
</p>
<p> - Easy way to replicate data, without the need for external
tools<br>
</p>
<p> Cons:</p>
<p> - Limited to one pair of nodes</p>
<p> - dsync doesn't replicate all sieve files, for example, one
file that tracks out of office replies has not been replicated in
my experience<br>
</p>
<p><br>
</p>
<p><u>NFS storage managed by corosync and pacemaker - Director to
send users to any backend<br>
</u></p>
<p> Pros:<br>
</p>
<p> - One location for all data. New nodes that get stood up will
be easy to configure</p>
<p> Cons:</p>
<p> - Complex to set up</p>
<p><br>
</p>
<p>In your experience, what did you choose for mail storage?</p>
<p><br>
</p>
<p>Thanks.<br>
</p>
</body>
</html>