This document describes the plan for adding GlusterFS support inside Ganeti.
Gluster is a “brick” “translation” service that can turn a number of LVM logical volume or disks (so-called “bricks”) into an unified “volume” that can be mounted over the network through FUSE or NFS.
This is a simplified view of what components are at play and how they interconnect as data flows from the actual disks to the instances. The parts in grey are available for Ganeti to use and included for completeness but not targeted for implementation at this stage.
It is the administrator’s duty to set up the bricks, the translators and thus the volume as they see fit. Ganeti will take care of connecting the instances to a given volume.
The gluster mountpoint must be whitelisted by the administrator in /etc/ganeti/file-storage-paths for security reasons in order to allow Ganeti to modify the filesystem.
Working with GlusterFS in kernel space essentially boils down to:
Since it is not strictly necessary for Gluster to mount the disk if all that’s needed is userspace access, however, it is inappropriate for the Gluster storage class to inherit from FileStorage. So the implementation should resort to composition rather than inheritance:
- In order not to further inflate bdev.py, Filestorage should join its helper functions in filestorage.py (thus reducing their visibility) and add Gluster to its own file, gluster.py. Moving the other classes to their own files like it’s been done in lib/hypervisor/) is not addressed as part of this design.
- Before attempting a mount, we should check if the volume is not mounted already. Linux allows mounting partitions multiple times, but then you also have to unmount them as many times as you mounted them to actually free the resources; this also makes the output of commands such as mount less useful.
- Every time the device could be released (after instance shutdown, OS installation scripts or file creation), a single unmount is attempted. If the device is still busy (e.g. from other instances, jobs or open administrator shells), the failure is ignored.
In order to address the shortcomings of the generic shared file handling of instance disk directory structure, Gluster uses a different scheme for determining a disk’s logical id and therefore path on the file system.
The naming scheme is:
...bringing the actual path on a node’s file system to:
This means Ganeti only uses one folder on the Gluster volume (allowing other uses of the Gluster volume in the meantime) and works better with how Gluster distributes storage over its bricks.
Ganeti has a number of storage types that abstract over disk templates. This matters mainly in terms of disk space reporting. Gluster support is improved by a rethinking of how disk templates are assigned to storage types in Ganeti.
This is the summary of the changes:
|Disk template||Current storage type||New storage type||Does it report storage information to...|
|gnt-node list||gnt-node list-storage||iallocator|
|Shared file||File||Shared file (new)||No.||Yes.||No.|
|RBD (for reference)||RBD||No.||No.||No.|
Gluster or Shared File should not, like RBD, report storage information to gnt-node list or to IAllocators. Regrettably, the simplest way to do so right now is by claiming that storage reporting for the relevant storage type is not implemented. An effort was made to claim that the shared storage type did support disk reporting while refusing to provide any value, but it was not successful (hail does not support this combination.)
To do so without breaking the File disk template, a new storage type must be added. Like RBD, it does not claim to support disk reporting. However, we can still make an effort of reporting stats to gnt-node list-storage.
The rationale is simple. For shared file and gluster storage, disk space is not a function of any one node. If storage types with disk space reporting are used, Hail expects them to give useful numbers for allocation purposes, but a shared storage system means disk balancing is not affected by node-instance allocation any longer. Moreover, it would be wasteful to mount a Gluster volume on each node just for running statvfs() if no machine was actually running gluster VMs.
As a result, Gluster support for gnt-node list-storage is necessarily limited and nodes on which Gluster is available but not in use will report failures. Additionally, running gnt-node list will give an output like this:
Node DTotal DFree MTotal MNode MFree Pinst Sinst node1.example.com ? ? 744M 273M 477M 0 0 node2.example.com ? ? 744M 273M 477M 0 0
This is expected and consistent with behaviour in RBD.
An alternative would have been to report DTotal and DFree as 0 in order to allow hail to ignore the disk information, but this incorrectly populates the gnt-node list DTotal and DFree fields with 0s as well.
Configurable at the cluster and node group level (gnt-cluster modify, gnt-group modify and other commands that support the -D switch to edit disk parameters):
The IP address or hostname of the Gluster server to connect to. In the default deployment of Gluster, that is any machine that is hosting a brick.
The port where the Gluster server is listening to.
The volume Ganeti should use.
Configurable at the cluster level only (gnt-cluster init) and stored in ssconf for all nodes to read (just like shared file):
Where the Gluster volume should be mounted.
The default values work if all of the Ganeti nodes also host Gluster bricks. This is possible, but not recommended as it can cause the host to hardlock due to deadlocks in the kernel memory (much in the same way RBD works).
In no particular order: