Introduction
Before we get into how to mount GlusterFS volumes natively, let’s first talk about what GlusterFS is and why it is so important. GlusterFS is an open-source, scalable, network-attached storage system that lets you store data in a powerful and flexible way. It combines different storage servers connected by Ethernet or Infiniband RDMA into a large, parallel network file system. The system unifies data storage by using a global namespace. One of the best things about GlusterFS is that it can grow horizontally. When you need more storage space, you can just add more machines to the storage pool.
But how do you get to the files that are stored in a GlusterFS volume? Using the native GlusterFS client, which lets you mount GlusterFS volumes directly onto your file system, is a common way to do this. Before reading this article, if you don’t know much about GlusterFS, you can read my articles on GlusterFS Installation GlusterFS Installation on Ubuntu 22.04 and volume types GlusterFS Volume Types: A Comprehensive Guide to learn how it works and how to make different types of GlusterFS volumes.
GlusterFS Native Mount
The native client for GlusterFS is a FUSE-based client that runs in user space. When we mount GlusterFS volume using native client, the mounted GlusterFS volume behaves like any other local file system. This lets applications use standard system calls to work with data. A native mount is a way to access GlusterFS volumes without going through third-party layers like NFS or Samba. The main benefit of a native mount is that it can give you better performance and more options than these other options.
Native mount uses the File system in Userspace (FUSE) module, which lets a user to create file system. This is the advantage of by the client-side implementation of GlusterFS, which turns file and directory operations into GlusterFS operations. The GlusterFS native client is better than other ways to access GlusterFS, like NFS or SMB, because it is faster and supports GlusterFS features like self-healing and re-balancing.
Mounting GlusterFS Volume Using Native Client Procedure
Let’s dive into the steps of mounting a GlusterFS volume natively. We are using the GlusterFS volume named “glsfsvolume” created as replicated volume across three GlsuterFS nodes glsfshost01, glsfshost02, glsfshost03 on mount point /mountdir on our client machine. We have already demonstrated volume creation procedure in previous article GlusterFS Installation on Ubuntu 22.04.
Installation of GlusterFS Client
Before you start installing the Gluster Native Client, you need to make sure that the FUSE module is loaded on the client and has access to the required modules.
$ sudo modprobe fuse$ sudo dmesg | grep -i fuse[ 1.437043] fuse: init (API version 7.34) [ 8.604181] systemd[1]: Starting Load Kernel Module fuse... [ 9.081027] systemd[1]: modprobe@fuse.service: Deactivated successfully. [ 9.084800] systemd[1]: Finished Load Kernel Module fuse. [ 9.207665] systemd[1]: Mounting FUSE Control File System... [ 9.353664] systemd[1]: Mounted FUSE Control File System.
After confirmation the fuse module is present we can proceed for GlusterFS client installation. The exact command will depend on your Linux operating system’s distribution and package manager.
On Ubuntu:
$ sudo apt-get install glusterfs-clientOn CentOS/Red Hat:
$ sudo yum install glusterfs-clientCreate a Mount Point
First we will create a directory on client’s local file system where we will mount the GlusterFS volume. We are creating /mountdir directory on our client for this demonstration.
$ sudo mkdir /mountdir
Mounting the Volume
Once we have the GlusterFS client installed and mount directory created on our client, we can mount the volume using the mount command. Put the GlusterFS nodes entries to client /etc/hosts file or use DNS server to resolve GlusterFS nodes by names. To mount GlusterFS volume only one host name/ip address is enough. Once the volume is mounted GlusterFS nodes take care the replication, availability and redundancy within peer nodes.
$ sudo mount -t glusterfs glsfshost01:/glsfsvolume /mountdirAfter mounting, use the ‘mount’ and 'df -h‘ command to confirm that the GlusterFS volume is properly mounted.
$ sudo mount... glsfshost01:/glsfsvolume on /mountdir type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072,_netdev) ...
$ sudo df -h
... glsfshost01:/glsfsvolume 30G 554M 30G 2% /mountdir ...
Automating the Mount
To make sure the GlusterFS volume is mounted every time the system starts, we can add an entry to the '/etc/fstab‘ file. We must be cautious when editing the ‘/etc/fstab' file as incorrect entries can lead to system boot failure.
glsfshost01:/glsfsvolume /mountdir glusterfs defaults,_netdev 0 0GlusterFS Client Communication Fail-over
When a client connects to a particular Gluster server node, it gets information about all the nodes. After that, it starts communicating with the rest of the nodes at the same time. So when one node dies, it doesn’t “fail-over”; it just loses that node but keeps talking with the others. But if the specified node failed at the time of mount, mounting would fail. To avoid this, we can use the backupvolfile-server option when mounting the fuse client. If the first volfile server fails, the server listed in the backupvolfile-server option mount the client.
Manual mount with option to fail-over to glsfshost02 node in case of failure of primary node glsfshost01.
$ sudo mount -t glusterfs -o backupvolfile-server=glsfshost02 glsfshost02:/glsfsvolume /mountdir
Automatic mounting with failover option uisng ‘/etc/fstab‘.
glsfshost01:/glsfsvolume /mountdir glusterfs backupvolfile-server=glsfshost02,_netdev 0 0Benefits of Native Mount
The benefits of using this style of communication are numerous. Here are some of the benefits in particular:
Full Functionality Set: Unlike other protocols, the native client fully supports every GlusterFS feature, including striping, replication, and other capabilities.
Performance: Native mounting improves read and write performance by reducing the overhead caused by NFS or Samba. The native client offers greater performance because it communicates with the server directly, reducing overhead and delay in comparison to other access methods.
Fail-over Support: Native mounts make use of GlusterFS’s built-in fail-over features to provide fail-over support. The client can immediately connect to a different server if one goes down.
Scalability: The client can use more servers without having to change its configuration if you add them to a GlusterFS volume. The native client is suitable for deployments that need to grow up quickly and dynamically because it can easily manage GlusterFS’s scalability.
Conclusion
In conclusion, native mounting in GlusterFS offers a technique of accessing your distributed data that is powerful, flexible, and efficient. Using the GlusterFS native mount is critical for managing high-traffic websites, cloud storage, and data-intensive applications. Users have access to a solution that is both dependable and high-performing thanks to native mounting of GlusterFS volumes. This demonstrates both the adaptability and effectiveness of GlusterFS as a storage solution that can scale. As more companies manage enormous data sets, GlusterFS and native mounts will remain market leaders.