3.1: Multiple networks and Client access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Udo,

It sounds to me like a firewall is blocking access to the Gluster system preventing some of the traffic from happening.  Please see:

http://www.gluster.com/community/documentation/index.php/Gluster_3.1:_Installing_GlusterFS_on_Red_Hat_Package_Manager_%28RPM%29_Distributions

This lists the ports that need to be open both between Gluster storage nodes and between the client.  This also needs to be open on all storage nodes to all clients.

Please try this and let us know if this helps.

-Jacob

----- Original Message -----
From: "Udo Waechter" <udo.waechter at uni-osnabrueck.de>
To: gluster-users at gluster.org
Sent: Saturday, October 16, 2010 5:07:15 AM
Subject: 3.1: Multiple networks and Client access

Hello all,
I just ran over Gluster 3.1 and got it up and running in notime. Thanks for the great FS.

I have a question regarding multiple network.

We have all our servers connected via an non-routed internal switch (a private subnet through which only the servers shall communicate with each other), additionally the official subnet to enable their reachability from the outside world.

The internal IPnetwork is 10.10.x.x and the external shall be 192.168.x.x (for the sake of the question).

I have now set up 3 servers as a GlusterFS. With a Striped Volume over the 10.10.x.x network.
All clients that are within this network can mount and use the volume.

The problem arises with the clients from the other 192.168.x network. They can mount the volume via:

mount -t glusterfs 192.168.x.x:volname /mnt

but they fail to use the mountpoint (ls and so)

I have read another post (http://bit.ly/a3Tm6n) but the solution mentioned there does not seem to work with version 3.1 any more.
The server(s) complain about "transport.socket..." not being allowed in the volume file.

The client from the 192.168.x.x network tries to contact the bricks via the 10.10.x network and not via 192.168.x.x (which would work)

Is there a solution to this problem? 

As I understand it, I would need to define the bricks with their 192.168.x.x ip-adresses but this would mean that the internal network won't be used. 

Can I define one brick with both ip-adresses (or 0.0.0.0).
Setting the "auth.allow" option to both subnets did not solve the problem (except for the mount being possible after setting it)

Any help is highly appreciated.
Thanks,
udo.
-- 
---[ Institute of Cognitive Science @ University of Osnabrueck
---[ Albrechtstrasse 28, D-49076 Osnabrueck, 969-3362
---[ Documentation: https://doc.ikw.uni-osnabrueck.de



_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/gluster-users


[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux