At 09:12 AM 1/25/2009, Prabhu Ramachandran wrote: >Just to second that I'd really appreciate this too. I've been trying to >setup a couple of machines on a not-too-reliable 100Mbs network with a >set of partitions each, mirror the same data. Thus far I've been >managing this with scripts that do rsync. > >With glusterfs I used unify for the 4 partitions on each machine and >then afr'd the two unified disks but was told that this is not a >reliable way of doing things and that I'd run into problems when one >host goes down. it depends what happens when a host goes down. if the issue is "server crashed" then you should be fine doing this with gluster/HA translator. as long as you unify bricks that are all on one server, and AFR to a unify of bricks all on the other server, then if one server is down, AFR will only use the unify brick of the server that is up. when the other server comes back up, things will auto-heal the server that was down. IF your problem is that a server is temporarily down because an unstable network connection, then you have a more difficult problem. Here, if the network connection fails and is back up in short periods of time you'll alway be experiencing delays as gluster is often waiting for timeouts, then the server is visible again, it auto-heals, then it's not visible and it has to timeout. It'll likely work just fine, but this will seem pretty slow (but no moreso than an NFS mount behind a faulty connection I suppose). Things can be further complicated if you have some clients that can see SERVER 1 and other clients that only see SERVER 2. If this happens, then you will increase the likelihood of a split brain situation and things will go wrong when it tries to auto-heal (most likely requiring manual intervention to get back to a stable state). so the replication features of gluster/HA will most likely solve your problem. if you have specific concerns, post a volume config to the group so people can advise you on a specific configuration. Keith
