> Marcelo et al, > >> -----Original Message----- >> From: info-cyrus-bounces@xxxxxxxxxxxxxxxxxxxx >> [mailto:info-cyrus-bounces@xxxxxxxxxxxxxxxxxxxx] 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 ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
