Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what are the problems related to glusterfs volume management". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Q: what are the commonly used commands?

Create a volume:

Gluster volume create NAME stripe SCOUNT replica RCOUNT transport TYPE BRICKLIST

NAME is the name of volume; SCOUNT,RCOUNT is the number of stripe,replica; transport is the transport type (tcp/rdma); BRICKLIST is the brick list in the form of HOME:PATH

Enable volume: gluster volume start NAME

Deactivate volume: gluster volume stop NAME

Delete volume: gluster volume delete NAME

View volume information: gluster volume info

View information about the volume runtime: gluster volume statedump Name

= =

Q: what did you eventually do to create / enable / deactivate / delete volume?

(1) the visible result of creating volume is that glusterd creates a directory with the name of volume under the vols directory of the working directory (default is / var/lib/glusterd), and creates relevant files to record volume information in this directory; the invisible result is that volume information is also recorded in the glusterd program. (2) the result of enabling volume is to start the glusterfsd and glusterfs processes on the node of the specified brick (note: if multiple brick are under the same node, there will be multiple glusterfsd processes, but only one glusterfs process), and update the recorded volume-related information in the log file. (3) the result of deactivating volume is to end the glusterfsd and glusterfs processes. (4) deleting volume removes all the relevant file information about the creation of volume.

= =

Q: what files are created when you create a volume? What kind of information are recorded separately?

When creating a volume, a directory with the name volume is created under the vols directory of the glusterd working directory (default is / var/lib/glusterd), and these files are created in this directory:

Info file: save the replication type of volume, the number of brick of volume, the details of brick, the number of stripe, the number of replica, the type of transfer, the unique ID of volume, and the user name password used internally. These are basically the parameter information specified by the creation volume.

The status information of the node_state.info:rebalance, triggered by the gluster volume rebalance command (not fully determined).

The status information of the rb_state:rebalane-brick, triggered by the gluster volume-brick command (not fully determined).

Cksum: check valu

Name-fuse.vol/trusted-Name-fuse.vol (Name is the name of volume): volume corresponds to the configuration file of glusterfs, which is read when the process starts.

Name.Host.Path.vol (Name is the name of volume, Host is the hostname of brick, and Path is the storage path'/'to'-'of brick):

Volume corresponds to the glusterfsd configuration file of brick, which is read when the process starts.

Bricks/Host:Path (Host is the hostname of brick, Path is the storage path of brick'/ 'converted to' -'): information about birck, including the hostname of brick, the file storage path, the listening port corresponding to glusterfsd, and the connection status.

When volume is enabled, the pid information of the glusterfsd process corresponding to brick is logged to the run/HOST-PATH.pid file.

= =

Q: what is the internal implementation of these commands handled by glusterd?

Like peer node management, glusterd maintains a linked list of events and a state machine for volume operations, as well as a corresponding state array and event handling array. When there is an operation request for volume, add an event to the event list, and according to the change of the state machine, find the corresponding event handling function from the event handling array of the corresponding state, and complete the actual processing action. Node management is based on the state of each peer node as a finite state machine change, while volume management is to have a global variable (opinfo) to record the corresponding state.

Because the brick may be a remote node, glusterd interacts with the glusterd of the remote node while processing it locally. From the transformation of the state machine above, we can see that the processing of a request can be understood as the execution of a transaction, including locking, committing, releasing locks, etc., which is equivalent to the commit of 2pc. Show.

= =

Q: what is the question mentioned at the end of this article?

This is because when creating volume, two extended attributes "trusted.glusterfs.volume-id" and "trusted.gfid" are added to the corresponding storage directory of brick. When deleting volume, these two attributes are not removed. When you create again, check the storage directory of brick and find that there are extended attributes, so there will be a prompt that brick is already a part of volume.

You can view the extended properties of these storage paths through the getfattr command

This is the end of the content of "what are the issues related to glusterfs volume management"? thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.