Gluster users - Jan 2011 - expanding volumes produce weird results

> 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

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

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