[Kolab-devel] Cyrus Murder and kolab

[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