Mount filesystems from Single Client to Multiple Clusters (SCMC)

Mount a single WEKA client to multiple clusters simultaneously, optimizing data access and workload distribution.

Overview

Mounting filesystems from a single WEKA client to multiple clusters provides several advantages:

  • Expanded cluster connectivity: A single client can connect to up to seven clusters simultaneously, increasing storage capacity and computational capabilities.

  • Unified data access: Provides a consolidated view of data across multiple clusters, simplifying access and management while improving data availability, flexibility, and resource efficiency.

  • Optimized workload distribution: Enables efficient workload distribution across clusters, supporting scalable applications and enhancing overall performance.

  • Seamless integration: WEKA’s SCMC feature ensures smooth and efficient integration for clients accessing multiple clusters.

Mount filesystems from multiple clusters on a single client

Bandwidth division considerations in SCMC

The bandwidth division in SCMC is a universal consideration based on the specific NIC's bandwidth. It applies across various NIC types, including those using DPDK or specific models like the X500-T1.

During SCMC mounts, each active connection can use the bandwidth available on its associated NIC port. This is true during peak usage and idle cases. In scenarios where NICs are dual-ported, each connection operates independently, leveraging its dedicated port.

When working with low-bandwidth NICs such as the X500-T1, a 10Gb/s NIC, consider bandwidth calculations. In the context of SCMC, each container (representing connectivity to a different cluster) uses half of the available bandwidth (5Gb/s) for a shared port. Note that a dual-port NIC has a dedicated port for each container, optimizing bandwidth distribution. Keep these factors in mind for an optimal SCMC setup.

When a stateless client mounts a filesystem in a cluster, it creates a client container with the same version as provided by the cluster. Because there may be situations where some of the clusters run a different WEKA version than the others, such as during an upgrade, it is required to set the same client target version on all clusters. The client target version is retained regardless of the cluster upgrade.

Procedure:

  1. Connect to each cluster and run the following command to set the client target version.

weka cluster client-target-version set <version>

Where: <version> is the designated client target version, which will be installed on the client container upon the mount command. Ensure this version is installed on the backend servers.

  1. To display the existing client target version in the cluster, run the following command:

weka cluster client-target-version show
  1. To reset the client target version to the cluster version, run the following command:

weka cluster client-target-version reset

Mount a stateless client container on multiple clusters

Use the same commands as with a single client.

mount -t wekafs <backend-name> <fs-name> <mount-point> -o container_name=<container-name>

To mount a stateless client using UDP mode, add -o net=udp -o core=<core-id> to the command line. For example:

mount -t wekafs backend-server-0/my_fs /mnt/weka -o net=udp -o core=2 -o container_name=frontend0

Mount persistent client containers on multiple clusters

For persistent client containers, the client-target-version parameter is not relevant. The version of the client container is determined when creating the container in the WEKA client using the weka local setup container command. Therefore, ensure that all client containers in the WEKA client have the same minor version as in the clusters.

To mount a persistent client container to a cluster, specify the container name for that mount.

mount -t wekafs <fs-name> <mount-point> -o container_name=<container-name>

Run commands from a server with multiple client containers

When running WEKA CLI commands from a server hosting multiple client containers, each connected to a different WEKA cluster, it’s required to specify the client container port or the backend IP address/name of the cluster (linked to that client) in the command.

Consider a server with two client containers:

weka local ps
CONTAINER  STATE    DISABLED  UPTIME    MONITORING  PERSISTENT  PORT   PID    STATUS  VERSION LAST FAILURE
client1    Running  False     3:15:57h  True        False       14000  58318  Ready   4.2.18
client2    Running  False     3:14:35h  True        False       14101  59529  Ready   4.2.18

To run a WEKA CLI command on the second cluster (associated with client2), use either of the following methods:

  • By specifying the backend IP address or name linked to that client container (assuming the backend name is DataSphere2-1):

    weka status -H DataSphere2-1
  • By specifying the client container port:

    weka status -P 14101

This approach ensures that your WEKA CLI command targets the correct WEKA cluster associated with the specified client container.

Manage authentication across multiple clusters with connection profiles

Add clients

Mount filesystems

Last updated