[Kolab-devel] Cyrus Murder and kolab

[Martin Konold]

Am Freitag, 13. Mai 2005 12:44 schrieb Markus Heller:
> Dear List,
>
> > >No, mailbox contents are intentionally not replicated as this would hurt
> > >network performance in most cases.
> > >
> > >High availability is imho best achieved using a shared storage cluster
> > > based on something like Heartbeat.
> >
> > You're right : We made some (quite intensive) tests, and storage cluster
> > is more efficient than agregating by using Murder.
> > Murder works really well but has some limitations, and the
> > synchronization concept is really complex.
> >
> > To Christophe, about the usability in multi-location mode (and Murder),
> > I can confirm this is completly transparent from the user point of view.
> >
> > By using a well designed storage solution and Kolab in multi location
> > mode, we can avoid using Murder in most of cases.
>
> There are two issues:
> a) replication and backup
> b) High Availability
> which are related, but require different technical concepts:
>
> ad a)
> the question is whether one can replicate the contents of an imap
> repository in a consistent state, whereby the target of the replication may
> either be another imap storage or a backup system.
>
> I have not up to now found any solution to this issue. The Murder guys
> (sounds 100% nice, eh?) have written on their website that replication is
> an open issue of development.
>
> ad b)
> HA needs two imap servers, one active (read/write) and the other ready to
> take over. Both access the same data, where this may be archieved through
> common storage: For example, if you have the imap spool directory on a
> netapp filer, or on a storage array with a shared scsi bus, where one
> server mounts the raid system rw and the other only read and remounts it as
> soon as the primary host is down.
>
> The open question is this: Can an imap server operate fine if it receives
> inconsistent data? Which means are there to return to consistent data and
> how long does this take? When the primary imaps fails and leaves an
> inconsistent dataset in the spool directory, which steps need to be taken
> to bring it up and transfer everything in a consistent state?
>
> The rest of the whole takeover operation like cutting off electricity for
> the deceased primary is technical stuff and has been documented
> elsewhere...
>
> So I would like sum up my questions:
> a) hot replication of an imap repository _without_ stopping/starting the
> imapd? -> seems to me that this is still unsolved
> b) resuming imap operation from an inconsistent repository? -> seems
> possible to me through certain commands (I don't know by heart, but I've
> read about that)
>
> I have asked a question on the info-cyrus mailing list: In case the imapd
> would not store its data in the file system but in a database instead, the
> replication (abd also backup) could be easier, since databases have
> checkpointing algorithms. Though, I have not yet received a clearly
> positive answer.
>
> Best wishes,
> Markus
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
-- martin

-- 
"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- 2004, Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n - Stuttgart, Germany
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker