Skip to main content
Version: 3026.4

Rolling upgrade for Fusion SMB Clusters

Overview​

This article covers the configuration and node ordering requirements when upgrading a scale-out cluster from versions of Fusion SMB.

warning

Fusion SMB clusters must be upgraded to 3025.4.1 before upgrading any further! If your cluster is on any version prior to 3025.4.1, you must first upgrade to this version before going further.

CA Path Configuration During Upgrade to 3025.4.1​

As of Fusion SMB 3025.4.1, a fully updated scale-out cluster no longer requires the path parameter in the ca_params per-share option, because the server now uses an in-memory distributed database. However, during a rolling upgrade, the path parameter must remain configured to maintain backward compatibility with nodes still running the older software.

Ensure the following is present in your configuration throughout the upgrade process:

ca = true
ca_params = path=/path_to_file_system_open_db_storage

Alternatively, you may set the equivalent global option:

ca_path = /path_to_file_system_open_db_storage
important

Once all nodes in the cluster have been upgraded to 3025.4.1, remove the path parameter (or ca_path global option). Leaving either configured forces the CA database onto shared storage rather than the in-memory distributed database introduced in 3025.4.1. This negates a performance improvement and adds unnecessary operational complexity to your cluster.

Node Upgrade Order​

When performing a rolling upgrade, the node with the lowest Node ID must be upgraded last.

To identify Node IDs before beginning the upgrade, run the following on any cluster node:

sudo corosync-quorumtool

Example output:

Quorum information
------------------
Date:             Tue May 27 23:47:34 2025
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          3232266935
...

Membership information
----------------------
    Nodeid      Votes Name
3232266804          1 vm-ubuntu
3232266935          1 vm-ubuntu-2 (local)

In this example, vm-ubuntu (Node ID 3232266804) has the lowest Node ID and should be the last node upgraded.

Upgrading Each Node​

Repeat the following procedure for each node, following the order established in Node Upgrade Order. Upgrade the lowest Node ID node last.

Procedure:

  1. Place the node in standby: pcs node standby <nodename>
  2. Swap the tsmb-server binaries to the new version
  3. Remove standby: pcs node unstandby <nodename>
  4. Verify the node has rejoined the cluster: sudo corosync-quorumtool
Do not proceed to the next node until the current node is confirmed healthy and quorum is intact.

Rolling Back a Node During Upgrade​

A node can be rolled back to its previous version as long as at least one other node in the cluster is still running the older version.

Procedure:

  1. Place the node in standby: pcs node standby <nodename>
  2. Swap the tsmb-server binaries back to the previous version
  3. Remove standby: pcs node unstandby <nodename>
warning

Once all nodes have been upgraded, per-node rollback is no longer possible. Rolling back at that point requires bringing the entire cluster offline first.

Summary Checklist​

StepAction
1Confirm ca_params includes path= (or ca_path is set globally) before starting
2Run corosync-quorumtool to identify the node with the lowest Node ID
3Upgrade all nodes except the lowest Node ID node first
4Upgrade the lowest Node ID node last
5After full upgrade, remove path from ca_params / remove ca_path