With the release of version 1.9, Ansible now includes a module named
gluster_volume for managing Gluster distributed file system volumes. The new module offers significant improvements over using shell commands including less code, better error handling, clearer declarative statements, and idempotency, the ability to apply an operation once and only once.
With my recent patch that adds support for multiple Gluster bricks, or backing directories on the storage nodes, I’ve been able to refactor our Ansible playbooks to use the new
Setting up Gluster with Ansible is now dead simple:
The playbook above does the following:
- Specifes the bricks, volume name, and number of replicas as variables
- Adds the Gluster repository to yum
- Installs the Gluster packages
- Starts the Gluster service
- Creates a volume
- Starts the volume
Creating a volume is a bit complicated and warrants some explanation. The
cluster parameters take strings seperated by commas. (The machines specified in the
cluster parameter are used for peer probing).The
force parameters allows us to specify bricks in the same partition as
/ (for use in VMs). The
present state tells the
gluster_volume module to create the volume. The
run_once parameter specified that the task is run on only one machine rather than on each machine.
gluster_volume builds the brick list by iterating over each host and then each brick. For example, the brick list for two hosts and two bricks would be
host1:/brick1 host2:/brick1 host1:/brick2 /host2:/brick2
When R replicas, N nodes, and M bricks are used, Gluster groups every (N * M) / R bricks into a replica. With 2 replicas, the first replica would consist of
host2:/brick1 while the second replica would consist of
/host2:/brick2. Thus, we must be careful to coordinate the ordering of the bricks and the number of nodes and bricks with the number of replicas.
In the future, I would like to improve the
gluster_volume API to make the specification of replica and striping groups more explicit and provide some error checking.