[Kolab-devel] Cyrus Murder and kolab

[Martin Konold]

Am Freitag, 13. Mai 2005 12:44 schrieb Markus Heller:

Hi Markus,

sorry about the other posting (I accidentally hit the send button)

> 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.

> HA needs two imap servers, one active (read/write) and the other ready to
> take over.

This is correct in the case of a stand-by configuration though also hot-hot 
configurations are possible.

> 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

Please don't use a NFS based storage with Kolab. We explicitly don't support 
such configurations though I have to admit that the netapp filers are the 
best NFS servers to my knowledge.

> , 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.

I have experience with Dual Host SCSI storage (like cheap SATA RAID Arrays or 
the Compaq MSA 500). In addition FC RAIDS are an option.

> The open question is this: Can an imap server operate fine if it receives
> inconsistent data?

No it will have problems.

> Which means are there to return to consistent data and 
> how long does this take?

This depends on the number of mailboxes but the times are typically relativly 
small. All steps required are in the cyrus documentation

> 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?

In the range of some minutes for very large servers.

> The rest of the whole takeover operation like cutting off electricity for
> the deceased primary is technical stuff and has been documented
> elsewhere...

This is well known HA stuff. With Linux Hearbeat and Stonith provide the 
required functionality.

> a) hot replication of an imap repository _without_ stopping/starting the
> imapd? -> seems to me that this is still unsolved

IMHO it is rather straight forward with IMAP. Technically dIMAP does exactly 
this. 

Please have a look at several packages offering imap synchronization
	
> 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.

Technically the imap store is a database though no relational but a 
hierarchical database which is well suited to replication.

Regards,
-- 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