ONTAP 9.14

to Japanese version

Automated nondisruptive ONTAP upgrade using the CLI

For automated upgrades, ONTAP automatically installs the target ONTAP image on each node, validates the cluster components to ensure that the cluster can be upgraded nondisruptively, and then executes a batch or rolling upgrade in the background based on the number of nodes.

You can use the command line interface (CLI) to verify that the cluster can be upgraded nondisruptively, install the target ONTAP image on each node, and then execute an upgrade in the background.

If you do not plan to monitor the progress of the upgrade process, it is a good practice to request EMS notifications of errors that might require manual intervention.
Before you begin
  • You should prepare for your upgrade.

  • You should download the ONTAP software image for your target ONTAP release.

  • For each HA pair, each node should have one or more ports on the same broadcast domain.

    If you have 8 or more nodes, the batch upgrade method is used in the automatic nondisruptive upgrade. In ONTAP 9.7, if the batch method is used, LIFs are migrated to the HA partner of the node being upgraded. If the partners do not have any ports in the same broadcast domain, then the LIF migration fails.

    In ONTAP 9.8 and later, if the batch method is used, LIFs are migrated to the other batch group.

  • If you are performing a direct multi-hop upgrade, you must have obtained both of the correct ONTAP images required for your specific upgrade path.

Modifying the setting of the storage failover modify-auto-giveback command option before the start of an automatic nondisruptive upgrade (ANDU) has no impact on the upgrade process. The ANDU process ignores any preset value to this option during the takeover/giveback required for the update. For example, setting -autogiveback to false prior to beginning ANDU does not interrupt the automatic upgrade before giveback.

Step 1: Load the target ONTAP software image into the cluster package repository

To begin your ONTAP software upgrade process, you must make the target ONTAP software image available in the cluster package repository.

Steps
  1. Delete the previous ONTAP software package:

    cluster image package delete -version previous_ONTAP_Version
  2. Load the target ONTAP software image into the cluster package repository:

    cluster image package get -url location
    cluster1::> cluster image package get -url http://www.example.com/software/9.13.1/image.tgz
    
    Package download completed.
    Package processing completed.

    If you are performing a direct multi-hop upgrade, you also need to load the software package for the intermediate version of ONTAP required for your upgrade. For example, if you are upgrading from 9.8 to 9.13.1, you need to load the software package for ONTAP 9.12.1, and then use the same command to load the software package for 9.13.1.

  3. Verify that the software package is available in the cluster package repository:

    cluster image package show-repository
    cluster1::> cluster image package show-repository
    Package Version  Package Build Time
    ---------------- ------------------
    9.13.1              MM/DD/YYYY 10:32:15

Step 2: Execute automated pre-upgrade checks

Optionally, before you perform an automated upgrade of your ONTAP software, you can use the cluster image validate command to verify that the cluster can be upgraded successfully. The cluster image validate command runs a series of checks against your cluster components, then provides a list of the specific validations that were performed and a list of any corrective actions that need to be taken before proceeding with the upgrade.

  1. Execute the automated pre-upgrade checks:

    cluster image validate -version package_version_number
    • If you are performing a direct multi-hop upgrade,use the target ONTAP package for verification. You do not need to validate the intermediate upgrade image separately. For example, if you are upgrading from 9.8 to 9.13.1, you should use the 9.13.1 package for verification. You do not need to validate the 9.12.1 package separately.

    • If you are upgrading a two-node or four-node MetroCluster configuration, you must run this command on both clusters before proceeding.

      cluster1::> cluster image validate -version 9.13.1
      
      WARNING: There are additional manual upgrade validation checks that must be performed after these automated validation checks have completed...
  2. Monitor the progress of the validation:

    cluster image show-update-progress
  3. Complete all required actions identified by the validation.

Step 3: Upgrade the ONTAP software

  1. Generate a software upgrade estimate:

    cluster image update -version package_version_number -estimate-only

    The software upgrade estimate displays details about each component to be updated, and the estimated duration of the upgrade.

  2. Perform the software upgrade:

    cluster image update -version package_version_number
    • If you are performing a direct multi-hop upgrade, use the target ONTAP version for the package_version_number. For example, if you are upgrading from ONTAP 9.8 to 9.13.1, use 9.13.1 as the package_version_number.

    • If the cluster consists of 2 to 6 nodes, a rolling upgrade is performed. If the cluster consists of 8 or more nodes, a batch upgrade is performed by default. If desired, you can use the -force-rolling parameter to specify a rolling upgrade instead.

    • After completing each takeover and giveback, the upgrade waits for 8 minutes to enable client applications to recover from the pause in I/O that occurs during the takeover and giveback. If your environment requires more or less time for client stabilization, you can use the -stabilize-minutes parameter to specify a different amount of stabilization time.

    • For any MetroCluster configuration, except a 2-node MetroCluster system, the ONTAP upgrade process starts simultaneously on the HA pairs at both sites (the local site and the disaster recovery site) after the user initiates and provides confirmation on the command line. For a 2-node MetroCluster system, the update is started first on the disaster recovery site, that is, the site where the upgrade is not initiated. After the update is fully completed on the disaster recovery site, the upgrade begins on the local site.

      cluster1::> cluster image update -version 9.13.1
      
      Starting validation for this update. Please wait..
      
      It can take several minutes to complete validation...
      
      WARNING: There are additional manual upgrade validation checks...
      
      Pre-update Check      Status     Error-Action
      --------------------- ---------- --------------------------------------------
      ...
      20 entries were displayed
      
      Would you like to proceed with update ? {y|n}: y
      Starting update...
      
      cluster-1::>
  3. Display the cluster update progress:

    cluster image show-update-progress

    If you are upgrading a 4-node or 8-node MetroCluster configuration, the cluster image show-update-progress command only displays the progress for the node on which you run the command. You must run the command on each node to see individual node progress.

  4. Verify that the upgrade was completed successfully on each node.

    cluster image show-update-progress
    cluster1::> cluster image show-update-progress
    
                                                 Estimated         Elapsed
    Update Phase         Status                   Duration        Duration
    -------------------- ----------------- --------------- ---------------
    Pre-update checks    completed                00:10:00        00:02:07
    Data ONTAP updates   completed                01:31:00        01:39:00
    Post-update checks   completed                00:10:00        00:02:00
    3 entries were displayed.
    
    Updated nodes: node0, node1.
  5. Trigger an AutoSupport notification:

    autosupport invoke -node * -type all -message "Finishing_NDU"

    If your cluster is not configured to send AutoSupport messages, a copy of the notification is saved locally.

  6. Verify that the cluster is enabled for automatic unplanned switchover:

Top of Page