Gluster users - Mar 2015 - Quorum setup for 2+1

On 10. 03. 2015 14:52, Jeff Darcy wrote:
>> I wold like to setup server side quorum by using the following setup:
>> - 2x storage nodes (s-node-1, s-node-2)
>> - 1x arbiter node (s-node-3)
>> So the trusted storage pool has three peers.
>>
>> This is my volume info:
>> Volume Name: wp-vol-0
>> Type: Replicate
>> Volume ID: 8808ee87-b201-474f-83ae-6f08eb259b43
>> Status: Started
>> Number of Bricks: 1 x 2 = 2
>> Transport-type: tcp
>> Bricks:
>> Brick1: s-node-1:/gluster/gvol0/brick0/brick
>> Brick2: s-node-2:/gluster/gvol0/brick0/brick
>>
>> I would like to setup the server side quorum so that any two nodes
would
>> have quorum.
>> s-node-1, s-node-2 = quorum
>> s-node-1, s-node-3 = quorum
>> s-node-2, s-node-3 = quorum
>> According to the Gluster guys at FOSDEM this should be possible.
>>
>> I have been fiddling with the quorum options, but have not been able to
>> achieve the desired setup.
>> Theoretically I would do:
>> # gluster volume set wp-vol-0 cluster.server-quorum-type server
>> # gluster volume set wp-vol-0 cluster.server-quorum-ratio 60
>>
>> But the cluster.server-quorum-ratio option produces an error:
>> volume set: failed: Not a valid option for single volume
>>
>> How would I achieve the desired setup?
> Somewhat counter-intuitively, server-quorum-type is a *volume* option
> but server-quorum-ratio is a *cluster wide* option.  Therefore, instead
> of specifying a volume name on that command, use this:
>
>      # gluster volume set all cluster.server-quorum-ratio 60
Thanks for the tip. Now the volume is accessible/writable whenever 2 out 
of 3 peers are connected to each other.
I have set up the folowing:
# gluster volume set wp-vol-0 cluster.server-quorum-type server
# gluster volume set all cluster.server-quorum-ratio 60

I have a follow-up question.
When a node is disconnected from the rest, the client gets an error 
message "Transport endpoint is not connected" and all access is 
prevented. Write access must not be allowed to such a node. I understand 
that.
In my case it would be a desired feature to be able to at least read 
files. Is it possible to retain read-only access?

Kind regards,
Mitja

> I have a follow-up question.
> When a node is disconnected from the rest, the client gets an error
> message "Transport endpoint is not connected" and all access is
> prevented. Write access must not be allowed to such a node. I understand
> that.
> In my case it would be a desired feature to be able to at least read
> files. Is it possible to retain read-only access?
Client-side quorum can do this with the cluster.quorum-reads option, but
it lacks support for arbiters.  The options you've set enforce quorum at
the server side, by killing brick daemons if quorum is lost.  I suppose
it might be possible to add the read-only translator instead of killing
the daemon, but AFAIK there's no plan to add that feature.