Comparison between GlusterFS client and server-side quorum mechanism

Client-side quorum applies only to replica volumes, and server Quorum applies to all volumes.

The number of replicas is best for odd number, the number of server side is not less than 3 odd.

• Client Quorum

Client-side quorum applies to fuse, GFAPI, NFS.

The client quorum feature is implemented in the AFR Repeater, so as long as the repeater is loaded, the client quorum function can be provided.

The quorum detection is naturally handled by the AFR Repeater.

If the check fails, the client cannot write and returns a erofs error.

A write operation fails because the number of plates (brick) does not meet the quorum requirement, and FOP returns a erofs error, and subsequent writes return the same error, so the error in this case returns immediately without waiting for the timeout mechanism.

The quorum state is determined by the number of active (active) plates (brick) that the client sees.

The specific rules are determined by Quorum-type and Quorum-count.

Option:cluster.quorum-type Default Value:none Description:if value is ' fixed ' only allow writes If quorum-count bricks be present. If value is ' auto ' only allow writes if more than half of bricks, or exactly half including the first, be present. If set to "fixed", only the quorum-count number of plates (bricks) are allowed to be written online. If set to "Auto", only more than half of the plates are allowed to be written online, or only half of the plates are allowed to continue writing after the first write. Option:cluster.quorum-count Default Value: (NULL) Description:if quorum-type is ' fixed ' only allow writes If this many bricks or present. Other quorum types would OVERWRITE this value. If Quorum-type is set to "fixed", only the set number of plates (brick) can be written online. If Quorum-type is set to a different value, the Quorum-count value set is not valid and will be overwritten.

The plate (brick) itself will persist unless the corresponding process is hung.

• Server-side Quorum

Server-side quorum is performed by the glusterd process, but the GLUSTERFSD process is judged.

Enable server-side quorum: server-quorum-type=server

Server-side responsible for quorum detection

Option:cluster.server-quorum-type Default Value: (NULL) Description:this feature is on the server-side i.e. Glusterd. Whenever the glusterd on a machine observes that the quorum was not met and it brings down the bricks to prevent data split-br Ains. When the network connections was brought back up and the quorum was restored the bricks in the volume was brought back up. Description: This function is implemented on the server side, that is, in the glusterd process. When Glusterd detects that a quorum is not reached on the server side, it stops brick to prevent data from splitting the brain. When the network resumes to a quorum, the corresponding brick will be restored. Option:cluster.server-quorum-ratio Default Value: (NULL) Description:sets the quorum percentage for the trusted storage pool.

The successful bricks of the arbitration can continue to write, the unsuccessful bricks will be set to read-only or stop directly, and when the arbitration is successfully launched, the data will be repaired automatically, thus preventing the splitting of the brain and ensuring data consistency.

To learn more about server quorum, view server quorum test method: Http://www.gluster.org/community/documentation/index.php/Features/Server-quorum

• Problem

Client quorum and server-side quorum that good?

If server-side quorum is enabled, data can still be written to the volume when a split-brain condition occurs. Server-side quorum for more efficient avoidance and volume configuration conflicts, the volume set, peer probe, and so on are forbidden when the quorum becomes a non-writable node.

If you want to avoid splitting the brain files in the volume, it is best to use client-side quorum.

Can the two arbitrations be used at the same time? What are the recommended configurations?

In my personal humble opinion, client-side quorum is sufficient, but client-side quorum can only be used to replicate the volume environment. Of course, two arbitration mechanisms can be used simultaneously. Server-side quorum kills brick directly, and brick even allows read access.

Translation summary from Gluster mailing list:

[Gluster-users] Client vs Server Quorum

If there are errors or irregularities, please point out the discussion.

This article is from the "Members Doukua" blog, make sure to keep this source http://dangzhiqiang.blog.51cto.com/7961271/1702214

Comparison between GlusterFS client and server-side quorum mechanism