[Gluster-devel] afr :2 HA setup question

[Krishna Srinivas]

Hi!

It should not be behaving that way. The client should work seamlessly.

inline...

On 9/7/07, August R. Wohlt <glusterfs at isidore.net> wrote:
> Hi all -
>
> I have a setup based on this :
>  http://www.gluster.org/docs/index.php/GlusterFS_High_Availability_Storage_with_GlusterFS<http://www.gluster.org/docs/index.php/GlusterFS_High_Availability_Storage_with_GlusterFS>
> but with only 2 machines. Effectively just a mirror (glusterfsd
> configuration below). 1.3.1 client and server.
>
> The problem I am seeing is that if I start up one side of the afr and the
> other side is down, I can only read and write to files that are already
> there. If I try to create a new file, the glusterfsd logs show this:

I am trying to understand your setup. The wiki setup says there are 3
servers, is yours same? because you say you start one side of afr
and other side is down. Pasting spec files will help.

Thanks
Krishna

>
> 07-09-07 11:39:00 D [common-utils.c:194:gf_resolve_ip] resolver: flushing
> DNS cache
> 2007-09-07 11:39:00 D [tcp-client.c:142:tcp_connect] brick-ds-bak: connect
> on 9 in progress (non-blocking)
> 2007-09-07 11:39:00 E [tcp-client.c:171:tcp_connect] brick-ds-bak:
> non-blocking connect() returned: 111 (Connection refused)
> 2007-09-07 11:39:00 W [client-protocol.c:344:client_protocol_xfer]
> brick-ds-bak: not connected at the moment to submit frame type(0) op(34)
> 2007-09-07 11:39:00 D [inode.c:297:__destroy_inode] brick/inode: destroy
> inode(0) [@0x148e8200]
> 2007-09-07 11:39:17 D [client-protocol.c:4211:client_protocol_reconnect]
> brick-ds-bak: attempting reconnect
>
> and the file creation just never returns. ie, if i mount this mirror setup
> on /brick and do: touch /brick/non_exist, an strace of tha tprocess just
> shows it hanging in :
>
>   open("/brick/non_exist", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666
>
> So my question is whether this is indended behavior? The wiki page makes it
> sound like this is an HA setup, but if one side goes down and that makes the
> remaining node useless, it's not much use as an HA setup. Am I missing
> something critical here?
>
>
> thanks,
> august
>
> ------------
> client (mounted on /brick):
>
>
>   volume brick
>      type protocol/client
>      option transport-type tcp/client
>      option remote-host 192.168.16.126
>      option remote-subvolume brick
>      option remote-port 16
>    end-volume
>
>
> server :
>
>  volume brick-ds
>            type storage/posix
>            option directory /.brick-ds
>  end-volume
>
>  volume brick-ns
>            type storage/posix
>            option directory /.brick-ns
>  end-volume
>
>
>     volume brick-ds-bak
>              type protocol/client
>              option transport-type tcp/client
>              option remote-host 192.168.16.254
>              option remote-port 16
>              option remote-subvolume brick-ds
>      end-volume
>
>      volume brick-ns-bak
>              type protocol/client
>              option transport-type tcp/client
>              option remote-host 192.168.16.254
>              option remote-port 16
>              option remote-subvolume brick-ns
>      end-volume
>
>
>     volume brick-ds-afr
>             type cluster/afr
>             subvolumes brick-ds brick-ds-bak
>             option replicate *:2
>     end-volume
>     volume brick-ns-afr
>             type cluster/afr
>             subvolumes brick-ds brick-ds-bak
>             option replicate *:2
>     end-volume
>
>    volume brick-unify
>             type cluster/unify
>             subvolumes brick-ds-afr
>             option namespace brick-ns-afr
>             option scheduler rr
>     end-volume
>
>
>    volume brick
>             type performance/io-threads
>             option thread-count 4
>             option cache-size 64MB
>             subvolumes brick-unify
>     end-volume
>
>    volume server
>      type protocol/server
>      option transport-type tcp/server
>      option bind-address 192.168.16.126
>      option auth.ip.brick-ds.allow 192.168.16.*
>      option auth.ip.brick-ns.allow 192.168.16.*
>      option auth.ip.brick.allow 192.168.16.*
>      option listen-port 16
>      subvolumes brick
>    end-volume
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>