>>>>> On Wed, 20 Mar 2002 10:40:20 +0100, >>>>> Birger Toedtmann <[EMAIL PROTECTED]> (bt) writes:
bt> If you want a production system that scales and is high available/has failover bt> capablilities, set up several boxes with _separate_ userspace and multiplex bt> all connections to and from it according to the userspace definition. bt> You can then provide high availability for each box with shared disk access bt> and an additional _offline_ cyrus (only jumping in mounting the shared disk bt> in a failover situation). I've been following these threads pretty closely because it is an issue I'm interested in as well. Based on what I've seen, the glimpses I've had into the code, and my gut, at least right now I'd have to concur: it is definitely a possibility to have host failover in a cluster, but true load-balancing raises several nasty issues. Even if true multi-node cluster load-balancing were possible, I fear the performance might suck pretty bad. No matter how much clustering improves, there will always be a performance penalty for all that overhead, at least from what I've seen. Some have suggested MySQL as db backend. Is it now possible to have MySQL shared between two nodes, a parallel database server? If not, then you have that as a single point of failure. Will the extra overhead of a full-sized SQL engine be a bottleneck? I dunno. I did happen to notice that Sleepycat now offers "Berkeley DB High Availability" which apparently supports a clustered environment. Could possibly that in conjunction with a SAN lead the way to a fully clustered Cyrus environment? I dunno. Though, I will say this: we recently switched to skiplist for mailboxes.db and at least so far, it beats the pants off of Berkeley DB. So as much as a clustered Berkeley DB intrigues me, I fear performance will be the deciding issue. As for Berkeley DB performance, I suspect the only way---and once again this is more my gut speaking than anything else---to get better performance is to fully thread Cyrus so that it is just one process and cache the hell out of Berkeley DB in memory. At least this seems to be what the Netscape folks did with Directory Server a while ago. (I believe they also highly customized Berkeley DB, but maybe some of those tweaks eventually found their way to Sleepycat. I dunno.) Even if all of this was done, would Berkeley DB performance be acceptable in the end compared to what we're currently seeing with skiplist? I dunno. I kinda doubt it. Well, that's my rambling for this morning. -- Amos
