Things to verify before you revert
Suggest changes
PDFs
Before revert, you should verify your cluster health, storage health, and system time. You should also delete any cluster jobs that are running and gracefully terminate any SMB sessions that are not continuously available.
Verify cluster health
Before you revert cluster, you should verify that the nodes are healthy and eligible to participate in the cluster, and that the cluster is in quorum.
-
Verify that the nodes in the cluster are online and are eligible to participate in the cluster:
cluster showcluster1::> cluster show Node Health Eligibility --------------------- ------- ------------ node0 true true node1 true true
If any node is unhealthy or ineligible, check EMS logs for errors and take corrective action.
-
Set the privilege level to advanced:
set -privilege advancedEnter
yto continue. -
Verify the configuration details for each RDB process.
-
The relational database epoch and database epochs should match for each node.
-
The per-ring quorum master should be the same for all nodes.
Note that each ring might have a different quorum master.
To display this RDB process… Enter this command… Management application
cluster ring show -unitname mgmtVolume location database
cluster ring show -unitname vldbVirtual-Interface manager
cluster ring show -unitname vifmgrSAN management daemon
cluster ring show -unitname bcomdThis example shows the volume location database process:
cluster1::*> cluster ring show -unitname vldb Node UnitName Epoch DB Epoch DB Trnxs Master Online --------- -------- -------- -------- -------- --------- --------- node0 vldb 154 154 14847 node0 master node1 vldb 154 154 14847 node0 secondary node2 vldb 154 154 14847 node0 secondary node3 vldb 154 154 14847 node0 secondary 4 entries were displayed.
-
-
Return to the admin privilege level:
set -privilege admin -
If you are operating in a SAN environment, verify that each node is in a SAN quorum:
event log show -severity informational -message-name scsiblade.*The most recent scsiblade event message for each node should indicate that the scsi-blade is in quorum.
cluster1::*> event log show -severity informational -message-name scsiblade.* Time Node Severity Event --------------- ---------- -------------- --------------------------- MM/DD/YYYY TIME node0 INFORMATIONAL scsiblade.in.quorum: The scsi-blade ... MM/DD/YYYY TIME node1 INFORMATIONAL scsiblade.in.quorum: The scsi-blade ...
Verify storage health
Before you revert a cluster, you should verify the status of your disks, aggregates, and volumes.
-
Verify disk status:
To check for… Do this… Broken disks
-
Display any broken disks:
storage disk show -state broken -
Remove or replace any broken disks.
Disks undergoing maintenance or reconstruction
-
Display any disks in maintenance, pending, or reconstructing states:
storage disk show -state maintenance|pending|reconstructing -
Wait for the maintenance or reconstruction operation to finish before proceeding.
-
-
Verify that all aggregates are online by displaying the state of physical and logical storage, including storage aggregates:
storage aggregate show -state !onlineThis command displays the aggregates that are not online. All aggregates must be online before and after performing a major upgrade or reversion.
cluster1::> storage aggregate show -state !online There are no entries matching your query.
-
Verify that all volumes are online by displaying any volumes that are not online:
volume show -state !onlineAll volumes must be online before and after performing a major upgrade or reversion.
cluster1::> volume show -state !online There are no entries matching your query.
-
Verify that there are no inconsistent volumes:
volume show -is-inconsistent trueSee the Knowledge Base article Volume Showing WAFL Inconsistent on how to address the inconsistent volumes.
Verifying the system time
Before you revert, you should verify that NTP is configured, and that the time is synchronized across the cluster.
-
Verify that the cluster is associated with an NTP server:
cluster time-service ntp server show -
Verify that each node has the same date and time:
cluster date showcluster1::> cluster date show Node Date Timezone --------- ------------------- ------------------------- node0 4/6/2013 20:54:38 GMT node1 4/6/2013 20:54:38 GMT node2 4/6/2013 20:54:38 GMT node3 4/6/2013 20:54:38 GMT 4 entries were displayed.
Verify that no jobs are running
Before you revert the ONTAP software, you must verify the status of cluster jobs. If any aggregate, volume, NDMP (dump or restore), or Snapshot jobs (such as create, delete, move, modify, replicate, and mount jobs) are running or queued, you must allow the jobs to finish successfully or stop the queued entries.
-
Review the list of any running or queued aggregate, volume, or Snapshot jobs:
job showcluster1::> job show Owning Job ID Name Vserver Node State ------ -------------------- ---------- -------------- ---------- 8629 Vol Reaper cluster1 - Queued Description: Vol Reaper Job 8630 Certificate Expiry Check cluster1 - Queued Description: Certificate Expiry Check . . . -
Delete any running or queued aggregate, volume, or Snapshot copy jobs:
job delete -id job_idcluster1::> job delete -id 8629
-
Verify that no aggregate, volume, or Snapshot jobs are running or queued:
job showIn this example, all running and queued jobs have been deleted:
cluster1::> job show Owning Job ID Name Vserver Node State ------ -------------------- ---------- -------------- ---------- 9944 SnapMirrorDaemon_7_2147484678 cluster1 node1 Dormant Description: Snapmirror Daemon for 7_2147484678 18377 SnapMirror Service Job cluster1 node0 Dormant Description: SnapMirror Service Job 2 entries were displayed
SMB sessions that should be terminated
Before you revert, you should identify and gracefully terminate any SMB sessions that are not continuously available.
Continuously available SMB shares, which are accessed by Hyper-V or Microsoft SQL Server clients using the SMB 3.0 protocol, do not need to be terminated before upgrading or downgrading.
-
Identify any established SMB sessions that are not continuously available:
vserver cifs session show -continuously-available No -instanceThis command displays detailed information about any SMB sessions that have no continuous availability. You should terminate them before proceeding with the ONTAP downgrade.
cluster1::> vserver cifs session show -continuously-available No -instance Node: node1 Vserver: vs1 Session ID: 1 Connection ID: 4160072788 Incoming Data LIF IP Address: 198.51.100.5 Workstation IP address: 203.0.113.20 Authentication Mechanism: NTLMv2 Windows User: CIFSLAB\user1 UNIX User: nobody Open Shares: 1 Open Files: 2 Open Other: 0 Connected Time: 8m 39s Idle Time: 7m 45s Protocol Version: SMB2_1 Continuously Available: No 1 entry was displayed. -
If necessary, identify the files that are open for each SMB session that you identified:
vserver cifs session file show -session-id session_IDcluster1::> vserver cifs session file show -session-id 1 Node: node1 Vserver: vs1 Connection: 4160072788 Session: 1 File File Open Hosting Continuously ID Type Mode Volume Share Available ------- --------- ---- --------------- --------------------- ------------ 1 Regular rw vol10 homedirshare No Path: \TestDocument.docx 2 Regular rw vol10 homedirshare No Path: \file1.txt 2 entries were displayed.
NVMe in-band authentication
If you are reverting from ONTAP 9.12.1 or later to ONTAP 9.12.0 or earlier, you must disable in-band authentication before you revert. If in-band authentication using DH-HMAC-CHAP is not disabled, revert will fail.