[Gluster-users] expanding volumes produce weird results

[Burnash, James]

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: [Gluster-users] 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