[Dovecot] Director questions
In playing with dovecot director, a couple of things came up, one related to the other:
Is there an effective maximum of directors that shouldn't be exceeded? That is, even if technically possible, that I shouldn't go over? Since we're 100% NFS, we've scaled servers horizontally quite a bit. At this point, we've got servers operating as MTAs, servers doing IMAP/POP directly, and servers separately doing IMAP/POP as webmail backends. Works just dandy for our existing setup. But to director-ize all of them, I'm looking at a director ring of maybe 75-85 servers, which is a bit unnerving, since I don't know if the ring will be able to keep up. Is there a scale where it'll bog down?
If it is too big, is there any way, that I might be missing, to use remote directors? It looks as if directors have to live locally on the same box as the proxy. For my MTAs, where they're not customer-facing, I'm much less worried about the latency it'd introduce. Likewise with my webmail servers, the extra latency would probably be trivial compared to the rest of the request--but then again, might not. But for direct IMAP, the latency likely be more noticeable. So ideally I'd be able to make my IMAP servers (well, the frontside of the proxy, that is) be the director pool, while leaving my MTAs to talk to the director remotely, and possibly my webmail servers remote too. Is that a remote possibility?
On 23.1.2012, at 21.13, Mark Moseley wrote:
In playing with dovecot director, a couple of things came up, one related to the other:
- Is there an effective maximum of directors that shouldn't be exceeded? That is, even if technically possible, that I shouldn't go over?
There's no definite number, but each director adds some extra traffic to network and sometimes extra latency to lookups. So you should have only as many as you need.
Since we're 100% NFS, we've scaled servers horizontally quite a bit. At this point, we've got servers operating as MTAs, servers doing IMAP/POP directly, and servers separately doing IMAP/POP as webmail backends. Works just dandy for our existing setup. But to director-ize all of them, I'm looking at a director ring of maybe 75-85 servers, which is a bit unnerving, since I don't know if the ring will be able to keep up. Is there a scale where it'll bog down?
That's definitely too many directors. So far the largest installation I know of has 4 directors. Another one will maybe have 6-10 to handle 2Gbps traffic.
- If it is too big, is there any way, that I might be missing, to use remote directors? It looks as if directors have to live locally on the same box as the proxy. For my MTAs, where they're not customer-facing, I'm much less worried about the latency it'd introduce. Likewise with my webmail servers, the extra latency would probably be trivial compared to the rest of the request--but then again, might not. But for direct IMAP, the latency likely be more noticeable. So ideally I'd be able to make my IMAP servers (well, the frontside of the proxy, that is) be the director pool, while leaving my MTAs to talk to the director remotely, and possibly my webmail servers remote too. Is that a remote possibility?
I guess that could be a possibility, but .. Why do you need so many proxies at all? Couldn't all of your traffic go through just a few dedicated proxy/director servers?
On Mon, Jan 23, 2012 at 11:37 AM, Timo Sirainen tss@iki.fi wrote:
On 23.1.2012, at 21.13, Mark Moseley wrote:
In playing with dovecot director, a couple of things came up, one related to the other:
- Is there an effective maximum of directors that shouldn't be exceeded? That is, even if technically possible, that I shouldn't go over?
There's no definite number, but each director adds some extra traffic to network and sometimes extra latency to lookups. So you should have only as many as you need.
Ok.
Since we're 100% NFS, we've scaled servers horizontally quite a bit. At this point, we've got servers operating as MTAs, servers doing IMAP/POP directly, and servers separately doing IMAP/POP as webmail backends. Works just dandy for our existing setup. But to director-ize all of them, I'm looking at a director ring of maybe 75-85 servers, which is a bit unnerving, since I don't know if the ring will be able to keep up. Is there a scale where it'll bog down?
That's definitely too many directors. So far the largest installation I know of has 4 directors. Another one will maybe have 6-10 to handle 2Gbps traffic.
Ok
- If it is too big, is there any way, that I might be missing, to use remote directors? It looks as if directors have to live locally on the same box as the proxy. For my MTAs, where they're not customer-facing, I'm much less worried about the latency it'd introduce. Likewise with my webmail servers, the extra latency would probably be trivial compared to the rest of the request--but then again, might not. But for direct IMAP, the latency likely be more noticeable. So ideally I'd be able to make my IMAP servers (well, the frontside of the proxy, that is) be the director pool, while leaving my MTAs to talk to the director remotely, and possibly my webmail servers remote too. Is that a remote possibility?
I guess that could be a possibility, but .. Why do you need so many proxies at all? Couldn't all of your traffic go through just a few dedicated proxy/director servers?
I'm probably conceptualizing it wrongly. In our system, since it's NFS, we have everything pooled. For a given mailbox, any number of MTA (Exim) boxes could actually do the delivery, any number of IMAP servers can do IMAP for that mailbox, and any number of webmail servers could do IMAP too for that mailbox. So our horizontal scaling, server-wise, is just adding more servers to pools. This is on the order of a few million mailboxes, per datacenter. It's less messy than it probably sounds :)
I was assuming that at any spot where a server touched the actual mailbox, it would need to instead proxy to a set of backend servers. Is that accurate or way off? If it is accurate, it sounds like we'd need to shuffle things up a bit.
participants (2)
-
Mark Moseley
-
Timo Sirainen