Hi,
I'm looking for a sanity check on my AFR setup and a fix for an error.
I have 2 servers running a web front end using gluster for a redundant shared
content area. I'm running Gluster 2.0.6 built from source on Ubuntu 6.06.
This is the server, running on 192.168.0.1-2:
volume sharedcontent
type storage/posix
option directory /var/sharedcontent
end-volume
volume locks
type features/locks
subvolumes sharedcontent
end-volume
volume server
type protocol/server
option transport-type tcp/server
option auth.ip.locks.allow 192.168.0.*,192.168.1.1
option auth.ip.sharedcontent.allow 192.168.0.*,192.168.1.1
subvolumes locks
end-volume
This is the client, running on the same machines (and possibly others in
future):
volume www1
type protocol/client
option transport-type tcp/client
option remote-host 192.168.0.1
option remote-subvolume locks
end-volume
volume www2
type protocol/client
option transport-type tcp/client
option remote-host 192.168.0.2
option remote-subvolume locks
end-volume
volume sharedcontent
type cluster/afr
subvolumes www1 www2
end-volume
Does this look right? I had to add the locks volume to make it work after
upgrading from 1.3.12. Is there some sensible naming scheme - ending up with the
top-level volume 'locks' is very counterintuitive, and means I need to
change the clients if I add filters on the server.
Are the auth.ip settings right? Do I need auth set on the
'sharedcontent' volume given that the clients only talk to
'locks'? Is the format right for allowing multiple address ranges
(I've only found examples, no authoritative docs on this)?
I have the feeling that I'm missing out on some other features that gluster
could use to improve performance on this, e.g. caching. Am I better off relying
on OS-level caching?
Those two machines are working fine for now, but I'm having trouble adding a
third. I'm getting "Transport endpoint is not connected" errors. I
can telnet from the client into both servers, so it's not a firewall
problem. I'm seeing this in logs:
[2010-03-07 21:18:40] D [client-protocol.c:6290:notify] www1: got
GF_EVENT_CHILD_UP
[2010-03-07 21:18:40] D [client-protocol.c:6290:notify] www1: got
GF_EVENT_CHILD_UP
[2010-03-07 21:18:40] D [client-protocol.c:5508:client_setvolume_cbk] www1:
failed to get 'process-uuid' from reply dictionary
[2010-03-07 21:18:40] D [client-protocol.c:5514:client_setvolume_cbk] www1:
SETVOLUME on remote-host failed: No version number specified
[2010-03-07 21:18:40] D [client-protocol.c:6290:notify] www2: got
GF_EVENT_CHILD_UP
[2010-03-07 21:18:40] D [client-protocol.c:5508:client_setvolume_cbk] www1:
failed to get 'process-uuid' from reply dictionary
[2010-03-07 21:18:40] D [client-protocol.c:5514:client_setvolume_cbk] www1:
SETVOLUME on remote-host failed: No version number specified
[2010-03-07 21:18:40] D [client-protocol.c:6290:notify] www2: got
GF_EVENT_CHILD_UP
[2010-03-07 21:18:40] D [client-protocol.c:5508:client_setvolume_cbk] www2:
failed to get 'process-uuid' from reply dictionary
[2010-03-07 21:18:40] D [client-protocol.c:5514:client_setvolume_cbk] www2:
SETVOLUME on remote-host failed: No version number specified
[2010-03-07 21:18:40] D [client-protocol.c:5508:client_setvolume_cbk] www2:
failed to get 'process-uuid' from reply dictionary
[2010-03-07 21:18:40] D [client-protocol.c:5514:client_setvolume_cbk] www2:
SETVOLUME on remote-host failed: No version number specified
The new client is running Ubuntu 9.10 and uses the standard glusterfs-client
package, which is 2.0.2. Is that OK for connecting to a 2.0.6 server? I've
seen various comments about version compatibility and the above errors but
nothing conclusive. I'd like to stick to standard packages to ease
management. If that won't work, are there any Ubuntu repos for later
versions of gluster so I can avoid building from source?
Thanks for some great software!
Marcus
--
Marcus Bointon
Synchromedia Limited: Creators of http://www.smartmessages.net/
UK resellers of info at hand CRM solutions
marcus at synchromedia.co.uk | http://www.synchromedia.co.uk/