Home > Storage > PowerScale (Isilon) > Product Documentation > Management and Migration > Dell PowerScale: Non-Disruptive Upgrade Best Practices > Upgrade types
There are three options available for upgrading OneFS:
The details of each upgrade type will be explained in the following sections.
A simultaneous upgrade installs the new operating system and restarts all nodes in the PowerScale cluster concurrently.
Simultaneous upgrades are faster than rolling upgrades but require a temporary interruption of service during the upgrade process. All client connections to the cluster must be terminated prior to initiating the upgrade and data is inaccessible until the installation of the new OneFS operating system is complete and the cluster is back online. Based on this, OneFS simultaneous upgrade is a disruptive upgrade path as all of the cluster services will be offline during the upgrade process.
A rolling upgrade individually upgrades and restarts each node in the PowerScale cluster so that only one node is offline at a time.
A rolling upgrade takes longer to complete than a simultaneous upgrade. You can specify the order in which nodes are upgraded by using the --nodes parameter of the isi upgrade cluster start command. The –nodes parameter can also be used in the scenario to upgrade a specific subset of nodes. The following example command starts a rolling upgrade on logical node number (LNN) 1, 3 and 5 in that order:
isi upgrade cluster start <install-image-path> --nodes 1,3,5
The following example commands use a dash-separated range to upgrade LNN 1 to node 5
isi upgrade cluster start <install-image-path> --nodes 1-5
It is required to upgrade all the nodes in order to install a patch, do a node firmware upgrade and do the next OneFS upgrade. If you only upgrade several nodes in the cluster, a weekly alert is sent to confirm that the upgrade is making progress if you have subscribed to the corresponding alert channel. Do not leave the cluster in a partially upgraded state for a prolonged period. Some new features in the upgrade might not be available until all the nodes in the cluster have been upgraded and the upgrade is committed. Refer to the release notes for the OneFS version that you are upgrading to for information about features that require the cluster to be committed to the upgraded version of OneFS.
To add new nodes to a running upgrade process, use the following command:
isi upgrade cluster add-nodes –nodes=2,4,6
To add all the remaining nodes to an upgrade process, use the following command:
isi upgrade cluster add-remaining-nodes
If you do not specify an order, nodes are upgraded in ascending order from the node with the lowest Array ID to the node with the highest Array ID. Because Array IDs are never reused, a node's Array ID might not be the same as the node's logical node number (LNN). To check each node's Array ID, run the following command:
isi_nodes "%{name}: LNN %{lnn}, Array ID %{id}"
A typical outcome of the above command is as below, and in this case, LNN matches Array ID.
tme-sandbox-1: LNN 1, Array ID 1
tme-sandbox-2: LNN 2, Array ID 2
tme-sandbox-3: LNN 3, Array ID 3
Important: During a rolling upgrade, nodes that are not actively being upgraded remain online and can continue serving clients. However, clients that are connected to a restarting node are disconnected and reconnected. How the client connection behaves when a node is restarted depends on several factors including client workload type, client configuration (mount type, timeout settings), IP allocation method, and how the client connected to the cluster. Usually, NDU requires specific configurations on either the PowerScale side or the client-side. For detailed client behavior and the recommended configurations, see the section Client behavior in an upgrade.
Rolling upgrades are not available between all OneFS versions. See the section Supported upgrade path for information about which types of upgrades are supported between OneFS versions.
The parallel upgrade is introduced in OneFS 8.2.2. It provides some extent of parallelism which is to upgrade at most one node per neighborhood at any time. By doing that, it can reduce upgrade duration and ensure that the end-user can still continue to have access to their data.
As shown in Figure 1, this feature can be enabled through WebUI.
You can also leverage the CLI to enable this feature through OneFS upgrade:
# isi upgrade start --parallel /ifs/install.tar.gz
The parallel upgrade can dramatically improve the OneFS upgrade efficiency without impacting the data availability. You can use the following formula to estimate the duration of the parallel upgrade:
ùê∏ùë†ùë°ùëñùëöùëéùë°ùëñùëúùëõ ùë°ùëñùëöùëí = (ùëùùëíùëü ùëõùëúùëëùëí ùë¢ùëùùëîùëüùëéùëëùëí ùëëùë¢ùëüùëéùë°ùëñùëúùëõ) √ó (‚Ñéùëñùëî‚Ñéùëíùë†ùë° ùëõùë¢ùëöùëèùëíùëü ùëúùëì ùëõùëúùëëùëíùë† ùëùùëíùëü ùëõùëíùëñùëî‚Ñéùëèùëúùëü‚Ñéùëúùëúùëë)
In the above formula:
#sysctl efs.lin.lock.initiator.coordinator_weights
The following is an example:
In a 150 node PowerScale cluster, ideally, there are 15 neighborhoods with 10 PowerScale nodes each. Neighborhood 1st with node number 1 to 10 and Neighborhood 2nd with node number 11 to 20 and so on.
During the parallel upgrade, the upgrade framework will pick at most one node from each neighborhood, to run the upgrading job simultaneously. So in this case, node 1 from neighborhood 1st, node 11 from neighborhood 2nd, node 21 from neighborhood 3rd, and so on, will be upgraded simultaneously. Considering, they are all in different neighborhoods or failure domain, it will not impact the current running workload. After the first pass completes, it will go to the 2nd pass and then 3rd, and so on.
So, in this example the estimated duration of the parallel upgrade is 200 minutes:
ùê∏ùë†ùë°ùëñùëöùëéùë°ùëñùëúùëõ ùë°ùëñùëöùëí = (ùëùùëíùëü ùëõùëúùëëùëí ùë¢ùëùùëîùëüùëéùëëùëí ùëëùë¢ùëüùëéùë°ùëñùëúùëõ) √ó (‚Ñéùëñùëî‚Ñéùëíùë†ùë° ùëõùë¢ùëöùëèùëíùëü ùëúùëì ùëõùëúùëëùëíùë† ùëùùëíùëü ùëõùëíùëñùëî‚Ñéùëèùëúùëü‚Ñéùëúùëúùëë) = 20 √ó 10
= 200 ùëöùëñùëõùë¢ùë°ùëíùë†