The Tours of the Black Prompt series so far:
- NetApp Data ONTAP 7-Mode
- Command line interface (CLI) overview including
- Commands and Privilege Levels
- Command Syntax and Help
- Navigation and Editing
- Command line interface (CLI) overview including
- Clustered NetApp Data ONTAP – Part 1
- CLI overview including
- Commands, Navigation, and Privilege Levels
- Command Syntax and Help
- Command Completion
- Navigation and Editing
- CLI overview including
- Clustered NetApp Data ONTAP – Part 2
- Working with Command History
- Setting Display Preferences
- Clustered NetApp Data ONTAP – Part 3
- Field Options
- Field Filtering
- Queries and Operators
- Clustered NetApp Data ONTAP – Part 4
- Extended Queries
As promised, in this post we’re going to cover some more real-world examples of using Data ONTAP’s cluster shell.
Common Configuration
The following examples were actually used in our just-released deployment guide NVA-1110-FP-DEPLOY. This is the Deployment Guide for NVA-1110-FP: FlexPod Datacenter with NetApp All-Flash FAS and VMware Horizon (with View) for which we released the Design Guide back in October.
Note: in our official documentation examples we will normally use the most complete or verbose version of a command, rather than an abbreviated one, for clarity and easier reading. For even greater efficiency, an administrator can absolutely use some of the abbreviations or shortcuts discussed in Part 1.
One of the areas where you may need to perform a lot of repetitive operational tasks is networking. In an ONTAP cluster, you will typically have multiple physical interfaces per node, and then multiple nodes within the cluster. Modifying a setting on each of these individually is the definition of tedious as well as consuming significant time.
Specifying the correct flow control settings on your interfaces is one of these operations. In the NVA-1110-FP environment, we needed to modify eight interfaces each on two nodes (16 total interfaces). Without using queries and operators, this would have required 16 commands
cluster01::> network port modify -node -port e0a -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0b -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0c -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0d -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0e -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0f -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0g -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node < -port e0h -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0a -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0b -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0c -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0d -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0e -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0f -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0g -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
cluster01::> network port modify -node -port e0h -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
1 entry was modified.
But that’s crazy when we can do it with one command instead:
cluster01::> network port modify -node * -port e0a..e0h -flowcontrol-admin none
Warning: Changing the network port settings will cause a several second interruption in carrier.
Do you want to continue? {y|n}: y
16 entries were modified.
This will modify the range of ports (using the RANGE operator of “..”) starting with e0a and ending with e0h on every node (using the ALL operator of “*”) in the cluster. That’s 15 commands (and quite a bit of time/frustration) eliminated in this environment, but the savings are even more significant as you scale up: no changes to that command are necessary whether we have one node or 24 nodes. Think of that for a moment: 24 nodes with eight interfaces each would be 192 commands – and we’ve reduced that down to a single command. That’s the equivalent of a 99.5% dedupe ratio!
In addition, we are able to apply the same efficiencies to setting the correct MTU on the physical ports:
cluster01::> network port modify -node * -port a0a -mtu 9000
WARNING: Changing the network port settings will cause a serveral second interruption in carrier.
Do you want to continue? {y|n}: y
2 entries were modified.
cluster01::> network port modify -node * -port e0e..e0h -mtu 9000
WARNING: Changing the network port settings will cause a serveral second interruption in carrier.
Do you want to continue? {y|n}: y
16 entries were modified.
In this case, we needed to modify an existing interface group (a0a) on both controllers, and then also modify each of the physical ports on each node.
There were several other areas of the configuration where we were able save steps using the ALL operator.
We needed to enable Cisco Discovery Protocol (CDP) on all nodes in the cluster.
cluster01::> system node run -node * options cdpd.enable on 2 entries were acted on.
If we wanted to completely abbreviate this, it could have been as short as
cluster01::> ru * options cdpd.enable on 2 entries were acted on.
We also needed to modify AutoSupport settings on each node:
cluster01::> system node autosupport modify -node * -state enable -mail-hosts [SMTPserver] -transport https -support enable -to [admin_email] 2 entries were modified.
Finally, we modified some web services for all Storage Virtual Machines in the cluster:
cluster01::> vserver services web modify -name spi|ontapi|compat -vserver * -enabled true 4 entries were modified.
In this case, we used the OR operator of “|” (the pipe symbol) for the “-name” parameter and the ALL operator for the “-vserver” parameter.
Here are a few other examples where I’ve been able to save significant amounts of effort and time thanks to these built-in efficiencies of the cluster shell. You’ll notice that I also indulged in various shortcuts and abbreviations in these examples, but the cluster shell outputs the unabbreviated command to the console for clarity anyway (the line in parentheses just beneath each example command).
Other Networking Configuration
At one point I needed to fix some Logical Interface (LIF) names that I had mis-typed (mis-specified, really) on 16 different SVMs. One command fixed it:
cluster01::> net int rename -vse test_nas* -lif mgmt1 -newname nfs1 (network interface rename) 16 entries were modified.
In another case, I needed to modify the home-ports for the management interfaces (35 in this instance) on all of the SVMs in a cluster. A single command again sufficed:
cluster01::> net int modify mgmt1 -home-port e0d -vse * (network interface modify) 35 entries were modified.
A special note for this example: specifying the home node was not required – the configuration for each LIF stayed on its current home-node and merely the home-port changed. When initially creating these LIFs, you do need to specify both home-node and home-port.
Reconfiguring the physical networking (VLAN interfaces, interface groups, etc.) happens fairly often as well. Here I needed to tear down an interface group, with a corresponding child VLAN interface, on each node in the cluster:
cluster01::> net port vlan delete -node * -vlan-name a0a-100 (network port vlan delete) 4 entries were deleted. cluster01::> net port ifgrp delete -node * -ifgrp a0a (network port ifgrp delete) 4 entries were deleted.
SAN Access Cleanup
Sometimes I just need to be able to clean up someLUNs, volumes, and SAN configuration while validating a solution:
cluster01::> lun offline -vserver svm_vmware -lun * 4 entries were acted on. cluster01::> lun delete -vserver svm_vmware -lun * 4 entries were acted on. cluster01::> igroup delete -vserver svm_vmware -igroup * 1 entry was acted on. cluster01::> volume offline -vserver svm_vmware -volume * Error: This command does not support queries.
I kept the volume command in there as a good example of where, for safety’s sake, operators are not allowed. If a LUN is deleted in error, you will be able to easily recover using a volume Snapshot. It is significantly harder to recover a volume if it has been accidentally deleted.
SnapMirror Operations
Initializing multiple SnapMirrors at once:
cluster01::> snapmirror initialize {-destination-path tours*}
Operation is queued: snapmirror initialize of destination "tours:tours_sm1".
Operation is queued: snapmirror initialize of destination "tours:tours_sm2".
2 entries were acted on.
Modifying all SnapMirror relationships that currently are on a daily schedule to now have an 8hour schedule:
cluster01::> snapmirror modify {-schedule daily} -schedule 8hour
Operation succeeded: snapmirror modify for the relationship with destination "tours:tours_sm1".
Operation succeeded: snapmirror modify for the relationship with destination "tours:tours_sm2".
2 entries were acted on.
The examples above are just a few of the ways that the built-in efficiencies of the cluster shell can dramatically save an administrator’s time, and turn a tedious experience into a fun one. (At least for some of us!)
Data Center Digressions 