There are two methods available for mounting a filesystem in one of the cluster hosts:
Using the Stateless Clients feature: See Mounting Filesystems Using the Stateless Clients Feature below, which simplifies and improves the management of clients in the cluster and eliminates the Adding Clients process.
This page describes both these options.
To mount a filesystem on one of the cluster hosts, let’s assume the cluster has a filesystem called
demo. To add this filesystem to a host, SSH into one of the hosts and run the
mountcommand as the
root user, as follows:
mkdir -p /mnt/weka/demomount -t wekafs demo /mnt/weka/demo
The general structure of a
mount command for a WekaIO filesystem is:
mount -t wekafs [-o option[,option]...]] <fs-name> <mount-point>
There are three options for mounting a filesystem on a cluster client: coherent, read cache and write cache. Refer to the descriptions in the links below to understand the differences between these modes:
The Stateless Clients feature defers the process of joining the cluster until a mount is performed. Simplifying and improving the management of clients in the cluster, it removes tedious client management procedures, which is particularly beneficial in AWS installations where clients may join and leave in high frequency. Furthermore, it unifies all security aspects in the mount command, eliminating the search of separate credentials at cluster join and mount.
To use the Stateless Clients feature, a WekaIO agent must be installed. Once this is complete, mounts can be created and configured using the mount command, and can be easily removed from the cluster using the unmount command.
Assuming the WekaIO cluster is using the backend IP of
18.104.22.168, running the following command as
root on a client will install the agent:
curl http://22.214.171.124:14000/dist/v1/install | sh
On completion, the agent is installed on the client machine.
mount -t wekafs
Use the following command line to invoke the mount command:
mount -t wekafs -o <options> <backend0>[,<backend1>,...,<backendN>]/<fs> <mount-point>
Parameters in Command Line
See Additional Mount Options below
IP/host name of a backend host
Must be a valid name
Must be a valid name
Path to mount on the local machine
Must be a valid path name
Each mount option can be passed with an individual
-o flag to
Set mode to coherent
Set mode to read cache
Set mode to write cache
Positive number, time in milliseconds
After the defined time period, every metadata cached entry is refreshed from the system, allowing the host to take into account metadata changes performed by other hosts.
Positive number, time in milliseconds
Each time a file or directory lookup fails, an entry specifying that the file or directory does not exist is created in the local dentry cache. This entry is refreshed after the defined time, allowing the host to use files or directories created by other hosts.
Mount filesystem as read-only
Mount filesystem as read-write
32, 64 or auto
Size of the inode in bits, which may be required for 32 bit applications.
Write debug logs to the console
Don't show any logs to console
Can be defined per mount (access can only be degraded if there are ACLs defined but the mount has no ACL)
Amount of memory to be used by the client (for huge pages)
Number of frontend cores to allocate for the client.
If none are specified, the client will be configured with 1 core.
If 0 is specified then you must use
Specify explicit cores to be used by the WekaIO client. Multiple cores can be specified.
This option must be specified for on-premises installation, and must not be specified for AWS installations.
The gateway itself is optional and does not have to be specified when no routing is required in the data network.
In the cluster, device names are generated by the order in which they appear in the command line. For example, if there are two
Network bandwidth limitation for the entire container, in Mb/s.
This limitation is for all nodes running within the container, and an attempt is made to detect it automatically based on the environment e.g., when in AWS. Setting a per-node limitation can be performed in the container definition file.
Number of seconds without connectivity after which the client will be removed from the cluster. Minimum value: 60 seconds.
86,400 seconds (24 hours)
Any subsequent mount commands after the first
mount command (where the client software is installed and the host joins the cluster) can use the same command, or use just the traditional mount parameters as defined in Mounting Filesystems, since it is not necessary to join a cluster.
It is now possible to access WekaIO filesystems via the mount-point, e.g., by
cd /mnt/weka/ command.
After the execution of an
umount command which unmounts the last WekaIO filesystem, the client is disconnected from the cluster and will be uninstalled by the agent. Consequently, executing a new
mount command requires the specification of the cluster, cores and networking parameters again.
It is possible to mount a WekaIO filesystem using the
autofs command. This is useful because mounting a WekaIO filesystem can only be performed after the WekaIO system has started running on a host, i.e., it is not possible to mount WekaIO filesystems at boot time by adding them to
To get started, install
autofs on the host:
# On RedHat/Centosyum install -y autofs
# On Debian/Ubuntuapt-get install -y autofs
Then run the following commands to create the
autofs configuration files for WekaIO filesystems:
echo "/mnt/weka /etc/auto.wekafs -fstype=wekafs" > /etc/auto.master.d/wekafs.autofsecho "* &" > /etc/auto.wekafs
Or run the following commands for stateless clients (which require the backend names as parameters):
echo "/mnt/weka /etc/auto.wekafs -fstype=wekafs,num_cores=1,net=<netdevice>" > /etc/auto.master.d/wekafs.autofsecho "* <backend-1>,<backend-2>/&" > /etc/auto.wekafs
Finally, restart the
service autofs restart
The configuration is distribution-dependent, and it is necessary to ensure that the service is configured to start automatically after the host is rebooted. To verify that the autofs service automatically starts after restarting the server, run the following command:
systemctl is-enabled autofs. If the output is
enabled the service is configured to start automatically.
In Amazon Linux, for example, autofs service can be verified with
chkconfig command. If the output is
on for the current runlevel (can be checked with
runlevel command), autofs will be enabled upon reboot.
# chkconfig | grep autofsautofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off
It is now possible to access WekaIO filesystems using the
cd /mnt/weka/<fs-name> command.