Upgrade WEKA versions

This page describes how to upgrade to the latest Weka software version.

Overview

The WEKA upgrade process supports upgrading to higher minor and major versions of a WEKA system deployed in a multi-container backend architecture (MCB). MCB is supported from version 4.0.2. MCB enables non-disruptive upgrades (NDU).

Always upgrade to the latest minor version in the new major version when upgrading to a major version. This may require first upgrading to a specific minor version in the current software version, as follows:

• To upgrade to WEKA software version 4.1.x, the minimum source version must be 4.0.2 in MCB architecture. If the source system is not in MCB architecture, it is required to convert the cluster architecture to MCB. Contact the Customer Success Team for assistance.

• To upgrade to WEKA software version 4.0.x, go through version 3.14.1 or above

• To upgrade to WEKA software version 3.14.x, go through version 3.13.1 or above

• To upgrade to WEKA software version 3.13.x, go through version 3.12.1 or above

Warning: Customers running WEKA clusters on AWS with auto-scaling groups must contact the Customer Success Team before converting the cluster to MCB.

Note: Backend servers with Intel E810 NIC are not supported on MCB architecture, so the cluster remains in the legacy architecture (single container architecture). Contact the Customer Success Team for assistance.

What is a non-disruptive upgrade (NDU)?

In MCB architecture, each container serves a single type of process, drive, frontend, or compute function. Therefore it is possible to upgrade one container at a time (rolling upgrade) while the remaining containers continue serving the clients with one exception that the compute containers are upgraded at once in a very short time with a minimal impact on serving IOs.

Note: Some background tasks, such as snapshot uploads or downloads, must be postponed or aborted. See the prerequisites in the upgrade workflow for details.

Internal upgrade process

Once you run the upgrade command in ndu mode, the following occurs:

1. Downloading the version and preparing all backend servers.

2. Rolling upgrade of the drive containers.

3. Upgrading all compute containers at once.

4. Rolling upgrade of the frontend and protocol containers and the protocol gateways.

NDU process at a glance

Related topics

WEKA containers architecture overview

Upgrade workflow

1. Verify prerequisites for the upgrade

2. Prepare the cluster for upgrade

3. Prepare the backend servers for upgrade (optional)

4. Upgrade the backend servers

5. Upgrade the clients

6. Check the status after the upgrade

Note: Upgrading a Weka cluster with a server used for more than one of the following protocols, NFS, SMB, or S3, is not allowed. In such a case, the upgrade does not start. Contact the Customer Success Team to ensure only one additional protocol is installed on each server.

1. Verify prerequisites for the upgrade

Before upgrading the cluster, ensure the following prerequisites. Otherwise, the NDU is not possible:

1. The backend servers meet the prerequisites and compatibility of the target version.

2. If you perform a non-disruptive upgrade (NDU), ensure the source version is configured in a multiple containers architecture. If not, contact the Customer Success Team to convert the source version from a single container architecture to a multiple containers architecture. This prerequisite only applies to an upgrade from source version 4.0.2 and above to 4.1.x.

3. All the backend servers are online.

4. Ensure you are logged in as a Cluster Admin (using a weka user login).

5. Any rebuild has been completed.

6. There are no outstanding alerts that still need to be addressed.

7. There is at least 4 GB of free space in the /opt/weka directory.

8. The NDU process requires the following tasks to be stopped. If these tasks are planned, postpone them. If the tasks are running, perform the required action.

Task	Required action	Backgrounk task name
Upload a snapshot	Wait for the snapshot upload to complete, or abort it.	STOW_UPLOAD
Create a filesystem from an uploaded snapshot	Wait for the download to complete or abort it by deleting the downloaded filesystem or snapshot. If the task is in the snapshot prefetch metadata stage, wait for the prefetch to complete or abort it. It is not possible to resume the snapshot prefetch metadata after the upgrade.	STOW_DOWNLOAD_SNAPSHOT STOW_DOWNLOAD_FILESYSTEM FILESYSTEM_SQUASH SNAPSHOT_PREFETCH
Sync a filesystem from a snapshot	Wait for the download to complete or abort it by deleting the downloaded filesystem or snapshot.	STOW_DOWNLOAD_SNAPSHOT
Detach object store bucket from a filesystem	Detaching an object store is blocked during the upgrade. If it is running, ignore it.	OBS_DETACH

For details on managing the background tasks, see the Background tasks topic.

Note: If you plan a multi-hop version upgrade, once an upgrade is done, a background process of converting metadata to a new format may occur (in some versions). This upgrade takes several minutes to complete before another upgrade can start. You can monitor the progress using the weka status CLI command and check if there is a data upgrade task in a RUNNING state.

2. Prepare the cluster for upgrade

Download the new software release on one of the backends using one of the following methods:

• From the backend server, run weka version get <new-version> (<new-version> is for example, 4.1.0). Then, run weka version prepare <new-version>.

• If you don't have a distribution server set, you can add it explicitly to the command. For example, to get the 4.1.0 version from get.weka.io, use a token as follows: weka version get 4.1.0 --from https://[GET.WEKA.IO-TOKEN]@get.weka.io Then, run weka version prepare <new-version>.

• From the backend server, run the curl command described in the install tab on the get.weka.io new release page.

• Download the new version tar file to the backend server and run the install.sh command. This method is helpful in environments without connectivity to get.weka.io, such as dark sites or private VPCs.

3. Prepare the backend servers for upgrade (optional)

When working with many backend servers, preparing them separately from the upgrade process in advance is possible to minimize the total upgrade time. For a small number of backend servers, this step is not required.

The preparation phase prepares all the connected backend servers for the upgrade, which includes downloading the new version and getting it ready to be applied.

Once the new version is downloaded to one of the backend servers, run the following CLI command: weka local run --container <container-name> --in <new-version> upgrade --mode ndu --prepare-only

Where:

<new-version>: Specify the new version. For example,4.1.0.

<container-name>: Specify only one container name. For example: drives0.

<upgrade mode>: For a cluster in MCB architecture, specify ndu. For a cluster in legacy architecture, the default is oneshot, so it is not required to specify it.

4. Upgrade the backend servers

Once a new software version is installed on one of the backend servers, upgrade the cluster to the new version by running the following command on the backend server.

If you already ran the preparation step, the upgrade command skips the download and preparation operations.

weka local run --container <container-name> --in <new-version> upgrade --mode <upgrade mode>

Example:

weka local run --container drives0 --in 4.1.1 upgrade --mode ndu

Adhere to the following:

• Before switching the cluster to the new software release, the upgrade command distributes the new release to all cluster servers. It makes the necessary preparations, such as compiling the new wekafs driver.

• If a failure occurs during the preparation, such as a disconnection of a server or failure to build a driver, the upgrade process stops and a summary message indicates the problematic server.

• In a successful process, the upgrade stops the cluster IO service, switches all servers to the new release, and then turns the IO service back on. This process takes about 1 minute, depending on the cluster size.

5. Upgrade the clients

Once all backends are upgraded, the clients remain with the existing version and continue working with the upgraded backends.

Once a stateless client is rebooted, or a complete umount and mount is performed, the stateless client is automatically upgraded to the backend version.

For stateful clients, a manual upgrade is required, usually during a maintenance window.

For a manual upgrade of both stateless or stateful clients, run the following command line on the client:

weka local upgrade

An alert is raised if there is a mismatch between the clients' and the cluster versions.

Add the --prepare-driver flag to the command for client source versions 4.0.1 and above.

Note: Clients with two or more major versions behind the version of the backends are not supported. Therefore, clients must be automatically or manually upgraded before the next cluster software major version upgrade.

6. Check the status after the upgrade

Once the upgrade is complete, verify that the cluster is in the new version by running the weka status command.

Example: The following is returned when the system is upgraded to version 4.1.0:

# weka status Weka v4.1.0 ...