[Gluster-users] Problem mounting on second NIC

Sean Davis sdavis2 at mail.nih.gov
Wed Dec 10 18:47:28 UTC 2008


On Wed, Dec 10, 2008 at 1:41 PM, Amar S. Tumballi <amar at zresearch.com> wrote:
> Hi Sean,
>
> Is glusterfs servers started on all 'remote' nodes? (I see its started fine
> on just 192.168.8.104, on other nodes, it may not be started, or a firewall
> is preventing a connection. check the status of connection by 'netstat -nt'

That was the issue.  Thanks, Amar.

Sean


> 2008/12/10 Sean Davis <sdavis2 at mail.nih.gov>
>>
>> I'm asking a lot of questions--sorry about that.
>>
>> I have a cluster setup with most of the nodes having two NICs, one for
>> a local network running over an internal GigE switch and the other to
>> our institutional network (also GigE).  I have configured four bricks
>> to run in unify on the internal network.  The resulting file system is
>> mounted on each node via the local network:
>>
>> volume remote1
>>  type protocol/client
>>  option transport-type tcp/client
>>  option remote-host 192.168.8.104
>>  option remote-subvolume brick
>> end-volume
>>
>> volume remote2
>>  type protocol/client
>>  option transport-type tcp/client
>>  option remote-host 192.168.8.102
>>  option remote-subvolume brick
>> end-volume
>>
>> .....
>>
>> volume unify0
>>  type cluster/unify
>>  option scheduler rr # round robin
>>  option namespace remote-ns
>>  #option block-size *:1MB
>>  subvolumes remote1 remote2 remote3 remote4
>> end-volume
>>
>> I have a second set of machines that are not on the internal network
>> but communicate over the institutional network.  I have modified the
>> client configuration to use the IP addresses for the institutional
>> network for each of the bricks.  However, when I try to mount the file
>> system using this configuration, I get this in the glusterfs.log.
>>
>> 2008-12-10 13:22:32 W [client-protocol.c:332:client_protocol_xfer]
>> remote2: not connected at the moment to submit frame type(1) op(34)
>> 2008-12-10 13:22:32 E [client-protocol.c:4430:client_lookup_cbk]
>> remote2: no proper reply from server, returning ENOTCONN
>> 2008-12-10 13:22:32 W [client-protocol.c:332:client_protocol_xfer]
>> remote3: not connected at the moment to submit frame type(1) op(34)
>> 2008-12-10 13:22:32 E [client-protocol.c:4430:client_lookup_cbk]
>> remote3: no proper reply from server, returning ENOTCONN
>> 2008-12-10 13:22:32 W [client-protocol.c:332:client_protocol_xfer]
>> remote4: not connected at the moment to submit frame type(1) op(34)
>> 2008-12-10 13:22:32 E [client-protocol.c:4430:client_lookup_cbk]
>> remote4: no proper reply from server, returning ENOTCONN
>> 2008-12-10 13:22:32 W [client-protocol.c:332:client_protocol_xfer]
>> remote-ns: not connected at the moment to submit frame type(1) op(34)
>> 2008-12-10 13:22:32 E [client-protocol.c:4430:client_lookup_cbk]
>> remote-ns: no proper reply from server, returning ENOTCONN
>> 2008-12-10 13:22:32 E [fuse-bridge.c:468:fuse_entry_cbk]
>> glusterfs-fuse: 6: (34) / => -1 (2)
>> 2008-12-10 13:22:32 W [client-protocol.c:332:client_protocol_xfer]
>> remote2: not connected at the moment to submit frame type(1) op(34)
>> 2008-12-10 13:22:32 E [client-protocol.c:4430:client_lookup_cbk]
>> remote2: no proper reply from server, returning ENOTCONN
>> 2008-12-10 13:22:32 W [client-protocol.c:332:client_protocol_xfer]
>> remote3: not connected at the moment to submit frame type(1) op(34)
>> 2008-12-10 13:22:32 E [client-protocol.c:4430:client_lookup_cbk]
>> remote3: no proper reply from server, returning ENOTCONN
>> 2008-12-10 13:22:32 W [client-protocol.c:332:client_protocol_xfer]
>> remote4: not connected at the moment to submit frame type(1) op(34)
>> 2008-12-10 13:22:32 E [client-protocol.c:4430:client_lookup_cbk]
>> remote4: no proper reply from server, returning ENOTCONN
>> 2008-12-10 13:22:32 W [client-protocol.c:332:client_protocol_xfer]
>> remote-ns: not connected at the moment to submit frame type(1) op(34)
>> 2008-12-10 13:22:32 E [client-protocol.c:4430:client_lookup_cbk]
>> remote-ns: no proper reply from server, returning ENOTCONN
>> 2008-12-10 13:22:32 E [fuse-bridge.c:468:fuse_entry_cbk]
>> glusterfs-fuse: 6: (34) / => -1 (2)
>>
>>
>> Any suggestions as to what is going on?  I didn't an answer to this
>> anywhere in the docs and google came up pretty dry, also.
>>
>> Thanks again,
>> Sean
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>>
>
>
>
> --
> Amar Tumballi
> Gluster/GlusterFS Hacker
> [bulde on #gluster/irc.gnu.org]
> http://www.zresearch.com - Commoditizing Super Storage!
>




More information about the Gluster-users mailing list