Shulou(Shulou.com)06/01 Report--

This article mainly introduces "case analysis of GlusterFS client-side and server-side arbitration mechanism". In daily operation, I believe that many people have doubts about the case analysis of GlusterFS client-side and server-side arbitration mechanism. The editor consulted all kinds of materials and sorted out simple and useful operation methods, hoping to help you answer the doubts of "case analysis of GlusterFS client-side and server-side arbitration mechanism". Next, please follow the editor to study!

Client arbitration applies only to duplicate volumes, and server arbitration applies to all volumes.

The number of replica volumes is preferably odd, and the number of server-side volumes is preferably odd, not less than 3.

Client-side arbitration

Client-side arbitration applies to fuse, gfapi, nfs.

The client-side arbitration function is implemented in the AFR repeater, so as long as the repeater is loaded, it can provide client-side arbitration function.

The arbitration test is naturally carried out by the AFR repeater.

If the check fails, the client cannot write and an EROFS error is returned.

A write operation in progress will fail because the number of brick does not meet the arbitration requirement, and FOP will return an EROFS error, and subsequent write operations will return the same error, so the error in this case will be returned immediately and there is no wait timeout mechanism.

The arbitration status is determined by the number of active (active) plates (brick) seen by the client.

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 are present. If value is "auto" only allow writes if more than half of bricks, or exactly half including the first, are present.

If set to "fixed", write is only allowed when the number of quorum-count plates (bricks) is online.

If set to "auto", only more than half of the plates are allowed to write while 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 will OVERWRITE this value.

If quorum-type is set to "fixed", only the number of plates (brick) can be written when online.

If quorum-type is set to a different value, the set quorum-count value is invalid and will be overwritten.

The brick itself will always exist unless the corresponding process is dead.

Server-side arbitration

The server-side arbitration is performed by the glusterd process, but it is determined by the glusterfsd process.

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

The server side is responsible for arbitration detection.

Option: cluster.server-quorum-type

Default Value: (null)

Description: This feature is on the server-side i.e. In glusterd. Whenever the glusterd on a machine observes that the quorum is not met, it brings down the bricks to prevent data split-brains. When the network connections are brought back up and the quorum is restored the bricks in the volume are brought back up.

Description: this function is implemented on the server side, that is, in the glusterd process. When glusterd detects that the server side does not reach a quorum, it stops the brick to prevent data cracking. When the network recovery reaches 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 can continue to be written, and the unsuccessful bricks will be set to read-only or stopped directly. When the arbitration is successfully launched again, the data will be automatically repaired, thus preventing brain cracking and ensuring data consistency.

problem

Which is better, client-side arbitration or server-side arbitration?

If server-side arbitration is enabled, data can still be written to the volume when a brain crack occurs. Server-side arbitration in order to more effectively avoid conflicts with volume configuration, when arbitration becomes an unwritable node, the execution of volume set, peer probe and other commands is prohibited.

If you want to avoid cracked brain files appearing in the volume, it is best to use client-side arbitration.

Can two kinds of arbitration be used at the same time? What is the recommended configuration?

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

At this point, the study on "GlusterFS client-side and server-side arbitration mechanism case analysis" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.