Cyrus, clusters, GFS - HA yet again

[Scott Adkins]

--On Monday, October 30, 2006 10:38 AM +0200 Janne Peltonen <janne.peltonen at helsinki.fi> wrote:

>> IIRC there are people running
>> Cyrus servers that way on other systems like Tru64 or Veritas cluster.
>
> And that's precisely what I'm trying to find out: since there are people
> that have succeeded in running Cyrus in an enviroment that's essentially
> the same as mine, I'd like to know how they have found their way around
> the DB error and other obstacles mentioned on this list in earlier
> posts.

Since my name has already come up on this thread, and I have weight in
a number of times on the clustering, I will throw my hat into the ring
right now and hopefully get some more time tonight or tomorrow to look
at all the messages and offer some opinions.

I can say that I solved the above problem by dumping BerkeleyDB. :) Even
though it is not recommended to use (at least the last time I remember
the recommendation to be) Skiplist for mailboxes.db, that is exactly what
I use.  The performance hit for using Skiplist is negligible to the amount
of problems I saw when using various versions of BerleleyDB on Tru64.  I
don't necessarily believe it is BerkeleyDB that is fully the problem, but
maybe BerkeleyDB's interaction with Tru64 that is the problem.

In any case, I have been MUCH happier dumping BerkeleyDB across the board.

Here is my configuration in my /etc/imapd.conf file:

  # Duplicate Suppression
  duplicatesuppression: no

  # Database Formats
  annotation_db: skiplist
  duplicate_db: skiplist
  mboxlist_db: skiplist
  ptscache_db: skiplist
  quota_db: quotalegacy
  seenstate_db: skiplist
  subscriptions_db: flat
  tlscache_db: skiplist

We receive a lot of e-mail in our environment, and taking the time to
suppress duplicate messages wasn't worth it considering the problem it
invited, and particularly the time it took to manage the write locks
on that database given the high rate or incoming e-mail being delivered.
However, turning off duplicate suppression breaks sieve, so I had to
modify the code to allow sieve to continue using the duplicate_db,
even when duplicate suppression has been turned off.  So, we still
use the database a little bit, but that is it... Which, makes skiplist
just fine for that.

Anyways, if there are any questions you have about our environment, feel
free to e-mail off-list and ask me.  I will do my best to help.  As I
eluded to above, we are a Tru64 show and their CFS has worked wonders
for us.  We have an e-mail project under way that will migrate Cyrus off
Tru64 into Linux (RedHat) with Polyserve as the cluster filesystem.  We
have Polyserve purchased but not deployed.  I will be happy to share our
deployment document once we have completed the project (which is likely
at least in the next summer timeframe).

Scott
-- 
 +-----------------------------------------------------------------------+
      Scott W. Adkins                http://www.cns.ohiou.edu/~sadkins/
   UNIX Systems Engineer                  mailto:adkinss at ohio.edu
        ICQ 7626282                 Work (740)593-9478 Fax (740)593-1944
 +-----------------------------------------------------------------------+
     PGP Public Key available at http://www.cns.ohiou.edu/~sadkins/pgp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20061101/a78dbc7b/attachment.bin