<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>From my phone, so excuse brevity and top-posting, but Fastmail running murder would be a huge bonus. I not-so-fondly recall the intimate relationship I developed with gdb debugging murder issues when we upgraded from 2.3 to 2.4 :)</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div style="font-size:9px; color:#575757">Sent via the Samsung GALAXY SŪ 5, an AT&T 4G LTE smartphone</div>
</div>
<div></div>
<br>
<br>
-------- Original message --------<br>
From: Bron Gondwana <brong@fastmail.fm> <br>
Date:03/13/2015 6:50 PM (GMT-05:00) <br>
To: Cyrus Devel <cyrus-devel@lists.andrew.cmu.edu> <br>
Cc: <br>
Subject: What would it take for FastMail to run murder <br>
<br>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">So I've been doing a lot of thinking about Cyrus clustering, with the<br>
underlying question being "what would it take to make FastMail run a<br>
murder". We've written a fair bit about our infrastructure - we use<br>
nginx as a frontend proxy to direct traffic to backend servers, and have<br>
no interdependencies between the backends, so that we can scale<br>
indefinitely. With murder as it exists now, we would be pushing the<br>
limits of the system already - particularly with the globally<br>
distributed datacentres.<br>
<br>
Why would FastMail consider running murder, given our existing<br>
nice system?<br>
<br>
a) we support folder sharing within businesses, so at the moment we are<br>
limited by the size of a single slot. Some businesses already push<br>
that limit.<br>
b) it's good to dogfood the server we put so much work into.<br>
<br>
Here are our deal-breaker requirements:<br>
<br>
1) unified murder - we don't want to run both a frontend AND a backend<br>
imapd process for every single connection. We already have nginx,<br>
which is non-blocking, for the initial connection and auth handling.<br>
2) no table scans - anything that requires a parse and ACL lookup for<br>
every single row of mailboxes.db is going to be a non- starter when<br>
you multiply the existing mailboxes.db size by hundreds.<br>
3) no single-point-of-failure - having one mupdate master which can stop<br>
the entire cluster working if it's offline, no thanks.<br>
<br>
Thankfully, the state of the art in distributed databases has moved a<br>
long way since mupdate was written. We'd have to at least change the<br>
mupdate protocol anyway to handle newly added fields, so why not just do<br>
away with it and have every server run a local node of a distributed<br>
database protocol for its mailboxes.db.<br>
<br>
Along with this, we need a reverse lookup for ACLs, so that any one user<br>
doesn't ever need to scan the entire mailboxes.db. This might be hooked<br>
into the distributed DB as well, or calculated locally on each node.<br>
<br>
And that's pretty much it. There are some interesting factors around<br>
replication, and I suspect the answer here is to have either multi-<br>
value support or embed the backend name into the mailboxes.db key<br>
(postfix) such that you wind up listing the same mailbox multiple<br>
times. We already suppress duplicates in the LIST command, so all we<br>
need then is logic for choosing the actual master. Rob N has done some<br>
work with consul and etcd already at FastMail, and we would use either<br>
that or a flag in the distributed DB to drive master choice for backend<br>
connection purposes.<br>
<br>
There are a bunch of "nice to have"s on top of this, but I think this<br>
would be enough for us to convert our existing standalone servers over<br>
to a murder.<br>
<br>
Bron.<br>
<br>
-- <br>
Bron Gondwana<br>
brong@fastmail.fm<br>
</div>
</span></font>
</body>
</html>