W E K A
4.0
4.44.34.24.14.03.14
4.0
4.44.34.24.14.03.14
  • WEKA v4.0 documentation
  • WEKA System Overview
    • About the WEKA system
    • SSD capacity management
    • Filesystems, object stores, and filesystem groups
    • Weka networking
    • Data lifecycle management
    • Weka client and mount modes
    • Weka containers architecture overview
    • Glossary
  • Getting Started with Weka
    • Quick installation guide
    • Manage the system using the Weka CLI
    • Manage the system using the Weka GUI
    • Run first IOs with WekaFS
    • Getting started with Weka REST API
  • Planning & Installation
    • Prerequisites for installation
    • Weka installation on bare metal
      • Planning a Weka System Installation
      • Prepare the system for Weka installation
        • SR-IOV enablement
      • Obtain the Weka software installation package
      • Weka cluster installation
      • WEKA legacy system installation process
      • Add clients
    • Weka installation on AWS
      • Self-service portal
      • CloudFormation template generator
      • Deployment types
      • AWS outposts deployment
      • Supported EC2 instance types
      • Add clients
      • Auto scaling group
      • Troubleshooting
  • Performance
    • Weka performance tests
      • Test environment details
  • WekaFS Filesystems & Object Stores
    • Manage object stores
      • Manage object stores using the GUI
      • Manage object stores using the CLI
    • Manage filesystem groups
      • Manage filesystem groups using the GUI
      • Manage filesystem groups using the CLI
    • Manage filesystems
      • Manage filesystems using the GUI
      • Manage filesystems using the CLI
    • Attach or detach object store buckets
      • Attach or detach object store bucket using the GUI
      • Attach or detach object store buckets using the CLI
    • Advanced data lifecycle management
      • Advanced time-based policies for data storage location
      • Data management in tiered filesystems
      • Transition between tiered and SSD-only filesystems
      • Manual fetch and release of data
    • Mount filesystems
    • Snapshots
      • Manage snapshots using the GUI
      • Manage snapshots using the CLI
    • Snap-To-Object
      • Manage Snap-To-Object using the GUI
      • Manage Snap-To-Object using the CLI
    • Quota management
  • Additional Protocols
    • NFS
      • Manage NFS networking using the GUI
      • Manage NFS networking using the CLI
    • SMB
      • Manage SMB using the GUI
      • Manage SMB using the CLI
    • S3
      • S3 cluster management
        • Manage the S3 service using the GUI
        • Manage the S3 service using the CLI
      • S3 buckets management
        • Manage S3 buckets using the GUI
        • Manage S3 buckets using the CLI
      • S3 users and authentication
        • Manage S3 users and authentication using the CLI
        • Manage S3 service accounts using the CLI
      • S3 rules information lifecycle management (ILM)
        • Manage S3 rules using the CLI
      • Audit S3 APIs
        • Configure audit webhook using the GUI
        • Configure audit webhook using the CLI
        • Example: How to use Splunk to audit S3
      • S3 supported APIs and limitations
      • S3 examples using boto3
  • Operation Guide
    • Alerts
      • Manage alerts using the GUI
      • Manage alerts using the CLI
      • List of alerts and corrective actions
    • Events
      • Manage events using the GUI
      • Manage events using the CLI
      • List of events
    • Statistics
      • Manage statistics using the GUI
      • Manage statistics using the CLI
      • List of statistics
    • System congestion
    • Security management
      • Obtain authentication tokens
      • KMS management
        • Manage KMS using the GUI
        • Manage KMS using the CLI
      • TLS certificate management
        • Manage the TLS certificate using the GUI
        • Manage the TLS certificate using the CLI
      • CA certificate management
        • Manage the CA certificate using the GUI
        • Manage the CA certificate using the CLI
      • Account lockout threshold policy management
        • Manage the account lockout threshold policy using GUI
        • Manage the account lockout threshold policy using CLI
      • Manage the login banner
        • Manage the login banner using the GUI
        • Manage the login banner using the CLI
    • User management
      • Manage users using the GUI
      • Manage users using the CLI
    • Organizations management
      • Manage organizations using the GUI
      • Manage organizations using the CLI
      • Mount authentication for organization filesystems
    • Expand and shrink cluster resources
      • Expand and shrink overview
      • Workflow: Add a backend host
      • Expansion of specific resources
      • Shrink a Cluster
    • Background tasks
    • Upgrade Weka versions
  • Billing & Licensing
    • License overview
    • Classic license
    • Pay-As-You-Go license
  • Support
    • Prerequisites and compatibility
    • Get support for your Weka system
    • Diagnostics management
      • Traces management
        • Manage traces using the GUI
        • Manage traces using the CLI
      • Protocols debug level management
        • Manage protocols debug level using the GUI
        • Manage protocols debug level using the CLI
      • Collect and upload diagnostics data
    • Weka Home - The Weka support cloud
      • Local Weka Home overview
      • Local Weka Home deployment
      • Set the Local Weka Home to send alerts or events
      • Download the Usage Report or Analytics
  • Appendix
    • Weka CSI Plugin
    • Set up the Weka-mon external monitoring
    • Set up the SnapTool external snapshots manager
  • REST API Reference Guide
Powered by GitBook
On this page
  • Upgrade prerequisites
  • Supported upgrade paths
  • Prepare the cluster for upgrade
  • Prepare the backend servers for upgrade (optional)
  • Upgrade the backend servers
  • Upgrade the clients
  • Check the status after the upgrade
  • Upgrade revert on failure
  1. Operation Guide

Upgrade Weka versions

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

Upgrade prerequisites

Before upgrading your cluster, ensure the following:

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

  2. All the backend servers are online.

  3. Any rebuild has been completed.

  4. There are no outstanding alerts that haven't been addressed.

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

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 aRUNNING state.

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

Supported upgrade paths

The Weka upgrade process supports upgrading to higher minor versions and major versions of the Weka software.

When upgrading to a major version, always upgrade to the latest minor version in the new 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.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

  • To upgrade to Weka software version 3.12.x, go through version 3.11.0 or above

  • To upgrade to Weka software version 3.11.x, go through version 3.10.0 or above

For more information, contact the Customer Success Team.

Prepare the cluster for upgrade

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

  • From the backend server, run weka version get <new-version> where <new-version> is the name of the new version (for example,4.0.1), followed by 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.0.1 version from get.weka.io using a token as follows: 

    weka version get 4.0.1 --from https://[GET.WEKA.IO-TOKEN]@get.weka.io

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

Prepare the backend servers for upgrade (optional)

When working with many backend servers, it is possible to prepare the backend servers separately from the upgrade process in advance 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 (as described above), run the following CLI command:

weka local run --in <new-version> upgrade --prepare-only

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:

weka local run --in <new-version> upgrade

where <new-version> is the name of the new version (for example,4.0.1).

The upgrade command skips the download and preparation operations if you already ran the preparation step.

You can control the upgrade window time by setting the following parameters in the upgrade command:

Parameters

Name

Type

Value

Limitations

Mandatory

Default

--stop-io-timeout

String

Maximum time in seconds to wait for IO to stop successfully

No

90s

--host-version-change-timeout

String

Maximum time in seconds to wait for a host version update

No

180s

--disconnect-stateless-clients-timeout

String

Maximum time in seconds to wait for stateless clients to be marked as DOWN and continue the upgrade without them

No

60s

--prepare-only

Boolean

Download and prepare a new software version across all servers in the cluster without performing the actual upgrade

No

False

--health-check-timeout

String

Maximum time in seconds to wait for the health check to complete

No

10s

Note: To run the upgrade command, ensure you are logged in as a Cluster Admin (using a weka user login).

Before switching the cluster to the new 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 the 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 size of the cluster.

Note: In large deployments of Weka with many backend servers and hundreds or thousands of clients, it is recommended to adjust the following timeout parameters:

  • Set host-version-change-timeout to 600s

  • Set disconnect-stateless-clients-timeout to 200s

  • Set health-check-timeout to 30s

If further assistance and adjustments are required, contact the Customer Success Team.

Upgrade the clients

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

For a stateless client, once it 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.

For client source versions 4.0.1 and above, add the --prepare-driver flag to the command.

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

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.0.1:

# weka status Weka v4.0.1 ...

Note: Once the upgrade completes successfully, contact the Customer Success Team to convert the cluster from a single-container Backend (SCB) to a multi-container backend (MCB) architecture.

Upgrade revert on failure

The disruptiveness of the upgrade procedure is limited to a defined window of 10 minutes. Weka system ensures that either the upgrade process to the new version finishes successfully or the version is automatically reverted to the old one within this window.

If a failure occurs, the version is automatically reverted on the backends. In this case, verify that all the backends are reverted to the old version by running the weka cluster host command.

PreviousBackground tasksNextLicense overview

Last updated 1 year ago