> On Feb 21, 2017, at 11:12 PM, Christian Balzer <ch...@gol.com> wrote:
> But even if you were to implement something that can handle 1 million or > more sessions per server, would you want to? > As in, if that server goes down, the resulting packet, authentication > storm will be huge and most like result in a proverbial shit storm later. > Having more than 10% or so of your customers on one machine and thus > involved in an outage that you KNOW will hit you eventually strikes me as > a bad idea. The idea would be to store session state in an external database like Redis. I use Redis for PHP session data on the web servers and Redis is implemented as a high-availability cluster (using Redis Sentinels). If the IMAP session state is maintained externally in a high-availability datastore, then rebooting a mail server or having it go down unexpectedly should not mean that all existing sessions are “kicked” and the clients would need to log in again. Rather, a backup mail server or servers could take the load and just use the high-availability datastore to manage the sessions that were on the old server. One potential problem, if not using shared storage for the mailboxes, is that dovecot replication is asynchronous so a small number of IMAP sessions might be out of date with the data on the replacement server, so some of the data in Redis might need to be re-cached to reflect the state of the backup mailstore. Other than that, I don’t think there would be much of a "proverbial shit storm” caused by the failure of one mail server, even if that server were to handle 1 million or more sessions per server. The remaining mail servers in the cluster would need to be able to absorb the load (maybe cluster in 3 server clusters would be the norm so each remaining server would only have to be able to take 50% of the sessions from the failed server while it is unavailable). Kevin
