A little late in responding to this, but to address the same issue (server1 being down when a mount is attempted), I've created a DNS entry for the Gluster storage pool as a whole, and all mounts use that DNS name. It in turn points to a virtual IP managed by the UCARP daemon running on each of the servers - in case the first server goes down, the virtual IP fails over to its mirror. I'm not yet completely clear on how seamlessly I can bring the virtual IP BACK to the first server - but I'm testing that scenario as I get a chance - I know it's doable - I just had weird problems when I first tested it. James Burnash, Unix Engineering -----Original Message----- From: gluster-users-bounces at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of Steve Wilson Sent: Monday, January 31, 2011 2:41 PM To: gluster-users at gluster.org Subject: Re: expanding volumes produce weird results On 01/31/2011 02:03 PM, Graeme Davis wrote: >> On Wed, 2010-11-03 at 13:05 -0500, Craig Carl wrote: >> >/ Samuele - >> />/ You don't need to create a client vol file with 3.1. Please >> delete >> />/ it from the clients and follow these instructions to mount - />/ >> http://www.gluster.com/community/documentation/index.php/Gluster_3.1: >> _Manually_Mounting_Volumes >> />/ >> / >> thanks, >> but this then lead to a question: how can i provide to a client a >> pool of server to use for ha without relying to hearbeat/rhcs or >> other cluster suite ? i assumed - correct me if i'm wrong - that by >> using the vol file client would be able to go to the next server if one was down . >> >> many thanks >> Samuele > > I've come across this same issue (I was using vol files thinking they > would tell the client how to mount without relying on one hostname). > > For example, I have a test distributed-replicated cluster of 10 > servers and 2 client set up. If I have the client set up to "mount -t > glusterfs server1:/volume /mnt/volume" and I take down server1, > everything still works. But if I try and mount server1 again (with > the above command) on another client it will complete the mount > command but then just sit there and hang the machine if you try and do > df or cd into /mnt/volume. > > Basically I want to have a reliable way of mounting from clients just > in case a machine tries to mount a Gluster volume when one of the > servers in the cluster is down. > > Ideas? > > Thanks, > > Graeme This is pretty basic but it works for me. I've written a script to do the mount for me. It will first test if a server is running before attempting a mount from that server. If the server isn't running, it will go on to the next server in the list. Here's the main part of the script: server_list="server1 server2" test_port=24007 # Check if something is already mounted at this mount point. mountpoint -q /mnt/volume if [ $? -ne 0 ]; then for server in $server_list; do # Test if the server is responding on the first Gluster TCP port netcat -z $server $test_port if [ $? -eq 0 ]; then mount -tglusterfs $server:/volume /mnt/volume break fi done fi Steve DISCLAIMER: This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this in error, please immediately notify me and permanently delete the original and any copy of any e-mail and any printout thereof. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. NOTICE REGARDING PRIVACY AND CONFIDENTIALITY Knight Capital Group may, at its discretion, monitor and review the content of all e-mail communications. http://www.knight.com
