[Gluster-users] Feedback and Questions on afr+unify

[Prabhu Ramachandran]

Hi,

Thanks for the response.

Krishna Srinivas wrote:
>>  - This one is very minor. It wasn't explicitly clear from the docs that to
>> use unify one needed (a) locking and (b) the namespace.  The place this is
>> mentioned is in "Understanding unify translator" which isn't the first place
>> a user would look.  Would be nice if this were mentioned somewhere.
> 
> Unify needs namespace, what do you mean by "locking" here?

The fact that I need to turn the posix-locks feature on.

volume brick1
   type features/posix-locks
   option mandatory on          # enables mandatory locking on all files
   subvolumes posix1
end-volume

Without it I was running into problems.

>>  - There are a lot of options to choose from and without Anands initial help
>> in person I would be lost trying to choose a scheduler.  It would be great
>> if there were some recommended solutions.  I understand the software is
>> rapidly growing but this would make life easier for new adopters.
> 
> True. We will give "cookbook" recommended setups in our documentation.

That would be great!

>> 2008-12-18 00:25:40 E [addr.c:117:gf_auth] auth/addr: client is bound to
>> port 59327 which is not privilaged
>> 2008-12-18 00:25:40 E [authenticate.c:193:gf_authenticate] auth: no
>> authentication module is interested in accepting remote-client
>> 10.24.1.4:59327
>> 2008-12-18 00:25:40 E [server-protocol.c:6842:mop_setvolume] server: Cannot
>> authenticate client from 10.24.1.4:59327
>>
>>  I worked around this problem by exposing the machine as a DMZ host from the
>> router but this is not ideal.  Is there something I can do to fix this?
> 
> http://www.gluster.org/docs/index.php/GlusterFS_Translators_v1.3#Authenticate_modules
> 
> You can use "login" based authentication to get around this problem.

Thanks, yes, that would work but for some reason I feel a 
username/password is weaker than restricting it to an IP.

>>  - What would happen if I change the scheduler to something else? Would that
>> hose the data?  I haven't moved all my data yet so I can experiment
>> currently.  I am not likely to tinker with the setup later on though since
>> this will contain important data.
> 
> Changing schedulers will not cause any problem.

Interesting, so any existing data on the disks will not be affected? 
How does that work?  Does this mean I can fill the disks a-priori before 
unifying them?

>>  - What would happen if I added another brick, say another disk to the
>> existing set on one of the machines?  Would it break the round-robin
>> scheduler that I am using?  I see from the FAQ that this should work with
>> the alu but will it work with rr?
> 
> ALU will be useful when you add servers later. i.e it will see free
> diskspace and schedule creation of new files there. RR will just
> round-robin.
> 
> You can experiement with the new "DHT" translator in place of unify.

OK, I can do that, I see dht does not need the extra namespace disk, so 
I guess I can clear out that directory.

> You can go with a more standard setup of
> unify->afr->client instead of afr->unify->client

Sorry, I am not sure what you mean by the above, the arrow directions 
aren't completely clear to me.  My understanding of the setup currently 
is that I have unify->afr->client (I unify 4 partitions on one machine, 
afr them across machines and then mount that as a client) which is what 
you have mentioned too above.  I am confused now that you mention that I 
have afr->unify->client instead.

> When you have afr over unify and one of unify subvol goes down, afr's
> selfheal will create missing files which you don't want to happen.

OK, so you are saying I need to simply switch to using dht, remove the 
namespace directory and continue with the setup and this problem will 
not occur?

cheers,
prabhu