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/
