1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
Does the Cyrus Murder support High Availability configurations?
---------------------------------------------------------------
The :ref:`Cyrus Murder <murder>` clustering solution drastically
increases system-wide reliability as compared to a traditional
standalone IMAP server. However, this configuration is not a true High
Availability/Redundancy solution (nor is such a beast trivial to
implement given the constraints on traditional Email systems).
The frontends of the CyrusMurder are, in every sense, 100% redundant. No
server-specific data is maintained on them, and one is as good as any
other from the point of view of a user.
The mupdate server is indeed a single point of failure, however a
failure at this point only prohibits message delivery (via the LMTP
proxies that are querying it for up-to-date mailbox data) and certain
mailbox operations (create, delete, setacl, and so on). Mail can still
be accessed by all users of the system, and incoming mail will receive
temporary failures, so the sending MTA should continue to queue the
mail.
The failure of a backend will result in a partial system wide failure --
the mailboxes that were stored on that backend will no longer be
available for use by any users. Delivery of new mail will again be
tempfailed, and queued by the sending MTA.
Some people have suggested shared storage and the use of hot spare
backends to combat this solution. The Cyrus authors do not generally
recommend the use of shared storage in the Cyrus environment. However
people have reported success in various configurations. The shared
filesystem still needs to support file locking, and it is highly
recommended that it have an efficient mmap implementation.
|
