Overview

There are two methods available for mounting a filesystem in one of the cluster hosts:

1. Using the traditional method: See below and also refer to Adding Clients (Bare Metal Installation) or Adding Clients (AWS Installation), where first a client is configured and joins a cluster, after which a mount command is executed.

2. 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.

Traditional Method for Mounting a Filesystem

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/demo
mount -t wekafs demo /mnt/weka/demo

The general structure of amount command for a Weka filesystem is:

mount -t wekafs [-o option[,option]...]] <fs-name> <mount-point>

There are two options for mounting a filesystem on a cluster client: read cache and write cache. Refer to the descriptions in the links below to understand the differences between these modes:

• ​Read cache mount mode​

• ​Write cache mount mode​

Mounting Filesystems Using the Stateless Clients Feature

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 Weka 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 Weka cluster is using the backend IP of 1.2.3.4, running the following command as root on a client will install the agent:

curl http://1.2.3.4:14000/dist/v1/install | sh

On completion, the agent is installed on the client machine.

Invoking the Mount Command

Command: 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

Mount Command Options

Each mount option can be passed with an individual -o flag to mount.

For All Clients Types

Additional Mount Options Available using the Stateless Clients Feature

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 Weka filesystems via the mount-point, e.g., by cd /mnt/weka/ command.

After the execution of anumount command which unmounts the last Weka 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.

Advanced Network Configuration via Mount Options

When using a stateless client, it is possible to alter and control many different networking options, such as:

• Virtual functions

• IPs

• Gateway (in case the client is on a different subnet)

• Physical network devices (for performance and HA)

• UDP mode

Use -o net=<netdev> mount option with the various modifiers as described below.

<netdev> is either the name, MAC address, or PCI address of the physical network device to allocate for the client.

IP, Subnet, Gateway and Virtual Functions

For higher performance, the usage of multiple Frontends may be required. When using a NIC other than Mellanox, or when mounting a DPDK client on a VM, it is required to use SR-IOV to expose a VF of the physical device to the client. Once exposed, it can be configured via the mount command.

When you want to determine the VFs IP addresses, or when the client resides in a different subnet and routing is needed in the data network, usenet=<netdev>/[ip]/[bits]/[gateway].

ip, bits, gateway are optional. In case they are not provided, the Weka system tries to deduce them when in AWS or IB environments, or allocate from the default data network otherwise. If both approaches fail, the mount command will fail.

For example, the following command will allocate two cores and a single physical network device (intel0). It will configure two VFs for the device and assign each one of them to one of the frontend nodes. The first node will receive 192.168.1.100 IP address, and the second will use 192.168.1.101 IP address. Both of the IPs have a 24 network mask bits and default gateway of 192.168.1.254.

mount -t wekafs -o num_cores=2 -o net=intel0/192.168.1.100+192.168.1.101/24/192.168.1.254 backend1/my_fs /mnt/weka

Multiple Physical Network Devices for Performance and HA

For performance or high availability, it is possible to use more than one physical network device.

Using multiple physical network devices for better performance

It's easy to saturate the bandwidth of a single network interface when using WekaFS. For higher throughput, it is possible to leverage multiple network interface cards (NICs). The -o net notation shown in the examples above can be used to pass the names of specific NICs to WekaFS host driver.

For example, the following command will allocate two cores and two physical network devices for increased throughput:

mount -t wekafs -o num_cores=2 -o net=mlnx0,net=mlnx1 backend1/my_fs /mnt/weka

Using multiple physical network devices for HA configuration

Multiple NICs can also be configured to achieve redundancy (refer to Weka Networking HA section for more information) in addition to higher throughput, for a complete, highly available solution. For that, use more than one physical device as previously described and, also, specify the the client management IPs using -o mgmt_ip=<ip>+<ip2> command line option.

For example, the following command will use two network devices for HA networking and allocate both devices to four Frontend processes on the client. Note the modifier ha is used here, which stands for using the device on all processes.

mount -t wekafs -o num_cores=4 -o net:ha=mlnx0,net:ha=mlnx1 backend1/my_fs -o mgmt_ip=10.0.0.1+10.0.0.2 /mnt/weka

Advanced mounting options for multiple physical network devices

With multiple Frontend processes (as expressed by -o num_cores), it is possible to control what processes use what NICs. This can be accomplished through the use of special command line modifiers called slots. In WekaFS, slot is synonymous with a process number. Typically, the first WekaFS Frontend process will occupy slot 1, then the second - slot 2 and so on.

Examples of slot notation include s1, s2, s2+1, s1-2, slots1+3, slot1, slots1-4 , where - specifies a range of devices, while + specifies a list. For example, s1-4 implies slots 1, 2, 3 and 4, while s1+4 specifies slots 1 and 4 only.

For example, in the following command, mlnx0 is bound to the second Frontend process whilemlnx1 to the first one for improved performance.

mount -t wekafs -o num_cores=2 -o net:s2=mlnx0,net:s1=mlnx1 backend1/my_fs /mnt/weka

For example, in the following HA mounting command, two cores (two Frontend processes) and two physical network devices (mlnx0, mlnx1) are allocated. By explicitly specifying s2+1, s1-2 modifiers for network devices, both devices will be used by both Frontend processes. Notation s2+1 stands for the first and second processes, while s1-2 stands for the range of 1 to 2, and are effectively the same.

mount -t wekafs -o num_cores=2 -o net:s2+1=mlnx0,net:s1-2=mlnx1 backend1/my_fs -o mgmt_ip=10.0.0.1+10.0.0.2 /mnt/weka

UDP Mode

In cases were DPDK cannot be used, it is possible to use WekaFS in UDP mode through the kernel. Use net=udp in the mount command to set the UDP networking mode, for example:

mount -t wekafs -o num_cores=0 -o net=udp backend-host-0/my_fs /mnt/weka

Mounting Filesystems Using fstab

Edit /etc/fstab file to include the filesystem mount entry:

• A comma-separated list of backend hosts, with the filesystem name

• The mount point

• Filesystem type - wekafs

• Mount options:

  • Configure systemd to wait for the weka-agent service to come up, and set the filesystem as a network filesystem, e.g.:

    • x-systemd.requires=weka-agent.service,x-systemd.mount-timeout=infinity,_netdev

  • Any additional wekafs supported mount option

# create a mount point 
mkdir -p /mnt/weka/my_fs
​
#edit fstab file
vi /etc/fstab
​
#fstab
backend-0,backend-1,backend-3/my_fs /mnt/weka/my_fs  wekafs  x-systemd.requires=weka-agent.service,x-systemd.mount-timeout=infinity,_netdev   0       0

Reboot the machine for the systemd unit to be created and marked correctly.

The filesystem should now be mounted at boot time.

Mounting Filesystems Using autofs

It is possible to mount a Weka filesystem using the autofs command.

To get started, install autofs on the host:

# On RedHat/Centos
yum install -y autofs

# On Debian/Ubuntu
apt-get install -y autofs

Then run the following commands to create the autofs configuration files for Weka filesystems:

echo "/mnt/weka   /etc/auto.wekafs -fstype=wekafs" > /etc/auto.master.d/wekafs.autofs
echo "*   &" > /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.autofs
echo "*   <backend-1>,<backend-2>/&" > /etc/auto.wekafs

Finally, restart the autofs service:

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 autofs
autofs         0:off 1:off 2:off 3:on 4:on 5:on 6:off

It is now possible to access Weka filesystems using thecd /mnt/weka/<fs-name> command.