Skip to main content
Install and maintain

Shut down the controllers - AFF A700


To replace the chassis, you must shutdown the controllers.

Option 1: Shut down the controllers

This procedure is for 2-node, non-MetroCluster configurations only. If you have a system with more than two nodes, see How to perform a graceful shutdown and power up of one HA pair in a 4-node cluster.

Before you begin

You need:

  • Local administrator credentials for ONTAP.

  • NetApp onboard key management (OKM) cluster-wide passphrase if using storage encryption.

  • SP/BMC accessability for each controller.

  • Stop all clients/host from accessing data on the NetApp system.

  • Suspend external backup jobs.

  • Necessary tools and equipment for the replacement.

Note If the system is a NetApp StorageGRID or ONTAP S3 used as FabricPool cloud tier, refer to the Gracefully shutdown and power up your storage system Resolution Guide after performing this procedure.
Note If using FlexArray array LUNs, follow the specific vendor storage array documentation for the shutdown procedure to perform for those systems after performing this procedure.

As a best practice before shutdown, you should:

  1. Log into the cluster through SSH or log in from any node in the cluster using a local console cable and a laptop/console.

  2. Turn off AutoSupport and indicate how long you expect the system to be off line:

    system node autosupport invoke -node * -type all -message "MAINT=8h Power Maintenance"

  3. Identify the SP/BMC address of all nodes:

    system service-processor show -node * -fields address

  4. Exit the cluster shell: exit

  5. Log into SP/BMC over SSH using the IP address of any of the nodes listed in the output from the previous step.

    If your're using a console/laptop, log into the controller using the same cluster administrator credentials.

    Note Open an SSH session to every SP/BMC connection so that you can monitor progress.
  6. Halt all nodes in the cluster:

    system node halt -node * -skip-lif-migration-before-shutdown true -ignore-quorum-warnings true -inhibit-takeover true.

    Note For clusters using SnapMirror synchronous operating in StrictSync mode: system node halt -node * -skip-lif-migration-before-shutdown true -ignore-quorum-warnings true -inhibit-takeover true -ignore-strict-sync-warnings true
  7. Enter y for each controller in the cluster when you see Warning: Are you sure you want to halt node "cluster name-controller number"? {y|n}:

  8. Wait for each controller to halt and display the LOADER prompt.

  9. Turn off each PSU or unplug them if there is no PSU on/off switch.

  10. Unplug the power cord from each PSU.

  11. Verify that all controllers in the impaired chassis are powered down.

Option 2: Shut down a node in a two-node MetroCluster configuration

To shut down the impaired controller, you must determine the status of the controller and, if necessary, switch over the controller so that the healthy controller continues to serve data from the impaired controller storage.

About this task
  • You must leave the power supplies turned on at the end of this procedure to provide power to the healthy controller.

  1. Check the MetroCluster status to determine whether the impaired controller has automatically switched over to the healthy controller: metrocluster show

  2. Depending on whether an automatic switchover has occurred, proceed according to the following table:

    If the impaired controller…​ Then…​

    Has automatically switched over

    Proceed to the next step.

    Has not automatically switched over

    Perform a planned switchover operation from the healthy controller: metrocluster switchover

    Has not automatically switched over, you attempted switchover with the metrocluster switchover command, and the switchover was vetoed

    Review the veto messages and, if possible, resolve the issue and try again. If you are unable to resolve the issue, contact technical support.

  3. Resynchronize the data aggregates by running the metrocluster heal -phase aggregates command from the surviving cluster.

    controller_A_1::> metrocluster heal -phase aggregates
    [Job 130] Job succeeded: Heal Aggregates is successful.

    If the healing is vetoed, you have the option of reissuing the metrocluster heal command with the -override-vetoes parameter. If you use this optional parameter, the system overrides any soft vetoes that prevent the healing operation.

  4. Verify that the operation has been completed by using the metrocluster operation show command.

    controller_A_1::> metrocluster operation show
        Operation: heal-aggregates
          State: successful
    Start Time: 7/25/2016 18:45:55
       End Time: 7/25/2016 18:45:56
         Errors: -
  5. Check the state of the aggregates by using the storage aggregate show command.

    controller_A_1::> storage aggregate show
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    aggr_b2    227.1GB   227.1GB    0% online       0 mcc1-a2          raid_dp, mirrored, normal...
  6. Heal the root aggregates by using the metrocluster heal -phase root-aggregates command.

    mcc1A::> metrocluster heal -phase root-aggregates
    [Job 137] Job succeeded: Heal Root Aggregates is successful

    If the healing is vetoed, you have the option of reissuing the metrocluster heal command with the -override-vetoes parameter. If you use this optional parameter, the system overrides any soft vetoes that prevent the healing operation.

  7. Verify that the heal operation is complete by using the metrocluster operation show command on the destination cluster:

    mcc1A::> metrocluster operation show
      Operation: heal-root-aggregates
          State: successful
     Start Time: 7/29/2016 20:54:41
       End Time: 7/29/2016 20:54:42
         Errors: -
  8. On the impaired controller module, disconnect the power supplies.