Upgrading Cluster

The Live Upgrades feature allows you to upgrade the managed devices and APs in a cluster to the latest ArubaOS version. Managed devices in a cluster can be seamlessly upgraded by specifying the new image file and a target partition. This is a real-time network upgrade where managed devices and APs upgrade automatically without any planned maintenance downtime.

You can also schedule an upgrade to a specified time to avoid manual intervention. The cluster is upgraded automatically at the scheduled time. You can view, delete, or reschedule the scheduled cluster upgrade.

The live upgrade process is optimized to take less time to upgrade all the devices. The upgrade process skips mesh point and mesh portal upgrade during live upgrade but these APs will go standard upgrade when the last managed device in the cluster successfully upgrades.

Starting from ArubaOS 8.8.0.0, the flash storage on the Mobility Conductor is used as a file server for live upgrade and this locally stored image will be downloaded by the managed devices using HTTP Hypertext Transfer Protocol. The HTTP is an application protocol to transfer data over the web. The HTTP protocol defines how messages are formatted and transmitted, and the actions that the w servers and browsers should take in response to various commands. protocol. You can upload firmware images from the WebUI of the Mobility Conductor by downloading it from the Aruba website.

When a cluster is upgraded, the following actions take place:

1. The cluster upgrade manager sends information of the APs to AirMatch.
2. The AirMatch creates logical groups of APs and updates the cluster upgrade manager with this information.
3. A target managed device is assigned to all APs in each partition.
4. The managed devices download the new firmware. The following events happen after the firmware download:
   1. For each managed device, irrespective of the partitions, AP image preload is initiated for a small capacity of the AP platform. For example, 1/8th capacity of the AP platform at a time.
   2. Once all the APs preload for each managed device, the next few APs are preloaded and this step is repeated till all the APs are preloaded.
5. Once all the APs are preloaded, a target managed device is selected and rebooted.
6. After the target managed device boots up, partition targeted to this managed device is selected and an AP move is initiated. Once all the APs are rebooted, the next partition is selected and an AP move is initiated.
7. Once all the partitions targeted to the targeted managed device are upgraded successfully, another target managed device is selected and step 6 is repeated till all the managed devices are rebooted successfully.

Following section describes how to configure Live upgrade and the limitations of live upgrade:

Configuring Live Upgrade

The following procedure describes how to upgrade the cluster:

1. Log in to a Mobility Conductor.
2. In the Managed Network node hierarchy, navigate to Maintenance > Software Management..
3. Select one or multiple clusters from the table. The table only lists the clusters and not the cluster members.

   The table displays the Name of the cluster, the number of managed devices, the number of APs in the cluster, and the version of software running on the managed devices of the cluster.

4. In the INSTALLATION SETTINGS > When menu, select Now.
5. In the Image File section, specify the image file location, name, and the protocol to use. Enter values for the following parameters:
   • Server IP address—IP address of the server. Both IPv4 and IPv6 addresses are supported.
   • Image path—Path of image file
   • Software to Install—Version to upgrade to
   • Protocol—Protocol to use to transfer file. Valid values are: FTP File Transfer Protocol. A standard network protocol used for transferring files between a client and server on a computer network. , TFTP Trivial File Transfer Protocol. The TFTP is a software utility for transferring files from or to a remote host. , and SCP Secure Copy Protocol. SCP is a network protocol that supports file transfers between hosts on a network.. Default value is TFTP Trivial File Transfer Protocol. The TFTP is a software utility for transferring files from or to a remote host. .
   • Username—Username of the account on the image server.
   • Password—Password of the account on the server.

6. In the Partition to upgrade section, specify the managed device partition where you want to install the firmware and where you want it to boot from. Select any one of the following partitions:
   • Partition 0
   • Partition 1
   • auto

7. Click Install to initiate an upgrade.
8. To check the status of the upgrade, in the Managed Network node hierarchy, navigate to Configuration > Services > Cluster.
9. The upgrade status for cluster name section is displayed with the status of the upgrade. The status of the upgrade can be any of the following values:
   • Upgrade pending
   • AP partitioning in progress
   • Upgrade in progress
   • Upgrade failed
   • Upgrade completed

10. The status of each managed device is displayed. Similarly, the status for each AP in the cluster is also displayed.

You can perform a live upgrade using the Mobility Conductor file server by executing the following commands:

To check the status of the upgrade, for Cluster1, execute the following show commands:

Alternatively, you can also execute the following command to trigger the cluster upgrade in the Mobility Conductor:

• cluster_name: The configured cluster profile name; corresponds to the managed devices and APs associated to the cluster that needs to be upgraded.
• img_version: The target image version, such as 8.2.1_XXXXX.
• partition_id: The partition on the managed device to which the new image is to be copied, valid values are 0 or 1 and this is optional. If the partition is not specified, it automatically picks the alternate boot partition.

Upgrading using Mobility Conductor File Server

Traditionally, a live upgrade could not be performed without using an external file server. However, starting from ArubaOS 8.8.0.0, the flash storage on the Mobility Conductor is used as a file server for live upgrade and this locally stored image will be downloaded by the managed devices using HTTP Hypertext Transfer Protocol. The HTTP is an application protocol to transfer data over the web. The HTTP protocol defines how messages are formatted and transmitted, and the actions that the w servers and browsers should take in response to various commands. protocol. You can upload firmware images from the WebUI of the Mobility Conductor by downloading it from the Aruba website. For more information, see Scheduling Upgrade of Managed Devices.

Optimizing Live Upgrade

Following are the optimizations performed to improve the upgrade times:

AP Image Preload

During live upgrade, if the AP fails to preload within 5 minutes, the AP is marked as Image preload Failed Retry pending temporarily. Once all the AP image are preloaded, a retry is performed for all the pending APs with a wait time of 5 minutes. If the preload fails again, these APs are marked as image preload failed and no further retries are performed. This mechanism reduces the overall AP image preload time taken by 60% compared to older releases.

Controller and AP Reboot Failure

In previous versions, if a controller fails to reboot within 30 minutes, the controller was marked as reboot failure and cluster upgrade was aborted. Due to this, the cluster will have few controllers in the upgraded image and few in the old image. From ArubaOS 8.8.0.0 release, even if a controller fails to reboot, the cluster upgrade is not aborted and the rest of the controllers are upgraded. Also, the initial controller reboot time is reduced to 15 minutes from 30 minutes.

Similarly, AP reboot waiting time is reduced from 15 minutes to 8 minutes without any retry.

Cluster unstable Timer Retries Reduction

If a cluster is not stable, the system starts the cluster unstable timer of 3 minutes with a maximum tries of 6. In previous releases, the maximum tries was set to 15. Therefore, this helps declare the cluster unstable in 18 minutes instead of 45 minutes.

Limitation

This feature has the following limitations:

• As there is an image preload limitation, cluster upgrade cannot be done with two different versions without reloading the managed devices. Only one preload per managed device reboot is allowed currently.
• The state of the AP preload is not displayed in the WebUI during the cluster upgrade.
• Cluster upgrade cannot be triggered if a previous upgrade resulted in split subclusters.
• Cluster Rolling Upgrade is not supported on mesh nodes. Therefore, a cluster upgrade cannot be performed for mesh deployments.
• It is not recommended to use live upgrade in MultiZone deployments. Each zone can use live upgrade but the upgrade on datazone is not hitless.
• Live Upgrade is not supported on Remote APs due to the following reasons:
  • When Remote APs are preloaded, rebooted, and moved to the upgraded managed device as part of live upgrade process, the preloaded Remote APs are moved to managed device using managed device switch IP instead of public IP. Due to which, the Remote APs fail to come up on the cluster.

  • Cluster live upgrade takes a very long time in a Remote AP deployment because there is no contiguous RF Radio Frequency. RF refers to the electromagnetic wave frequencies within a range of 3 kHz to 300 GHz, including the frequencies used for communications or Radar signals. domain and due to which, there could be too many channel partitions for Remote APs. Since, each partition will be preloaded, rebooted, and then moved to the upgraded managed device, it will take a long time to complete the upgrade process.