Cyrus IMAP and MySQL mailboxes (Building load-balancing
cluster)
Simon Matter
simon.matter at invoca.ch
Thu Nov 23 02:42:16 EST 2006
> Marcelo et al,
>
>> -----Original Message-----
>> From: info-cyrus-bounces at lists.andrew.cmu.edu
>> [mailto:info-cyrus-bounces at lists.andrew.cmu.edu] On Behalf Of
>> Marcelo Maraboli
>>
>> thanks for the input, I know wishing 100% is only available
>> with a gooooogle size amount of money ;), but I am looking
>> for a CYRUS IMAP server solution similar to a load balancing
>> web server farm...i.e:
>>
>> - a Load balancing server (PEN in Freebsd if you like) that
>> will direct an IMAP session to ANY of a group of IMAP servers,
>> all of which have access to a central storage of user MBOXs.
>>
>> So if any of the IMAP (backend) server dies, the load balancer with
>> automatically not forward any new requests to that server
>> and users won´t notice any downtime..
>>
>> this is diferent from Andrew´s solution number 1, since ANY of
>> the backend IMAP server should accept connections for ANY user.
>>
>> examples:
>> http://siag.nu/pen/vrrpd-linux.shtml
>> http://redundancy.org/fbsd_lb.html
>>
>> can IMAP be set up this way ??
>>
>> regards,
>>
>
> This need is why I suggested beefy servers rather than the Murder, which I
> don't consider sufficiently highly available due to actually being a
> number of discrete servers at the back end. Great for load balancing,
> useless for instant failover in case of server loss.
>
> In short, as I understand it Cyrus cannot be set up this way. Only a
> single machine can have write privileges to the mailboxes database at a
> time. The only way I can see to do this is to use NFSv4 which is supposed
> to get the locking correct. Then, assuming the database is closed between
> changes (can a developer please confirm whether it is kept open by master
> or not?) you should be able to run multiple IMAP servers over the same
> filesystem stored on a NAS (network-attached storage, as opposed to SAN).
> That is the only way I can think of to do what you are after. You would
> need two NAS boxes, ideally in separate buildings, with live mirroring (10
> Gb fibre or copper connection between) and a bunch of cheap servers in
> each building all load-balanced. You should be able to lose a complete
> data centre and just keep running at 50% capacity as long as your network
> is properly routed (with redundancy in case of an idiot with a spade
> cutting through your fibre of course).
>
> It's expensive, but it should work if the database is not held open. If it
> is, then you need to look at a different email product. Cyrus is a great
> server, but if you need five 9s reliability then you have to pay for it.
> You could always look at an appliance - dedicated hardware is often more
> reliable and at least if it goes down you can scream at the vendor and
> cover your butt that way.
Hi Sarah,
I'm really confused now.
1) You are talking about NAS as a possible solution and I don't know how
that should work if NFS doesn't work. Until now I thought a NAS device is
an embedded fileserver which can be accessed using different network
filesystems like SMB/CIFS, NFS or whatever. As long as it doesn't provide
proper locking (which may only be true if it provides NFSv4), it will
never work as a shared storage among more than one cyrus-imapd server.
2) Several people on this list have confirmed that they are running
cyrus-imapd clusters on shared storage (SAN) which works fine with a
cluster filesystem. That tells me that shared access to cyrus databases
works fine as long as the filesystem used provides proper locking, which
means in case of a cluster that the cluster filesystem has to coordinate
locking among all cluster members. Isn't that the main reason why those
filesystems exist?
3) I don't think the reliability of an appliance hardware is any better
than good server and SAN components. In fact most appliances I saw are
simply relabeled DELL or Intel OEM hardware. What you say may be true for
the installed software but I don't think it's true for the hardware.
The whole high availability thing has been discussed on this list so many
times and I'm a bit confused again. It's a really interesting topic.
Simon
More information about the Info-cyrus
mailing list