Lessons of a Datacenter Administrator
Snapshots are one of the core features of ONTAP, and something that many, many people rely on every day to protect their data from accidental (or malicious…) deletion and corruption. The NetApp PowerShell Toolkit can help us to manage the configuration of snapshot policies, the application of those policies to volumes, and creating/deleting/reverting snapshots too.
This post will cover:
There are multiple ways to do authentication to NetApp systems when using the PowerShell Toolkit. This ranges from the simple and obvious one-time connection, to securely storing credentials for future use. Saving credentials can be useful when executing scripts from a host non-interactively, such as with scheduled tasks or triggered through another script.
The Connect-NcController is the standard method of connecting to a clustered Data ONTAP controller. Connect-NaController is the 7-mode equivalent and works identically. Additionally, the same credential rules apply for the Invoke-NcSsh and Invoke-NaSsh cmdlets as well.
Arguably the most common method of connecting to a controller is by simply providing the hostname:
|
1 2 3 |
# this will attempt to connect to the specified controller using stored credentials, or if none # are found, will prompt for credentials. it will also default to HTTPS, with a fallback to HTTP Connect-NcController $myController |
If you are connecting to an SVM’s management interface this will work as expected, though some cmdlets won’t work because of the limited scope. If you want to connect to an SVM by tunneling through the cluster management interface, use the -Vserver parameter.
|
1 |
Connect-NcController $clusterMgmtLif -Vserver $SvmName |
However, there are a number of parameters which change the default behavior.
There’s one particular part of the NetApp PowerShell Toolkit which is not frequently used, but is extremely powerful. Templates can be created for many of the object types which are used to create a query for specific objects, or for limiting the amount of information returned from a particular cmdlet invocation.
To get started, we first need to initialize the object for our query or attribute limiting template. To do this we use the -Template parameter to our cmdlet.
|
1 2 |
# create an empty Aggregate object template $aggrTemplate = Get-NcAggr -Template |
If we were to look at this object it is empty:
Many of the properties associated with an object, such as an aggregate, volume, or LUN, are objects themselves. If we want to use a property of a child object as the query filter then we need to initialize that property in the template object.
|
1 2 3 4 5 6 7 8 |
# create an empty Aggregate object template $aggrTemplate = Get-NcAggr -Template # initialize a property of the template Initialize-NcObjectProperty -Object $aggrTemplate -Name AggrRaidAttributes # alternatively, initialize all properties during template creation $aggrTemplate = Get-NcAggr -Template -Full |
Our template object now has a property object which has been populated:
At this point we’re ready to use the template, let’s look at how to use it as a query or to limit the attributes returned.
I recently encountered a posting on the NetApp Community asking about, among other things, allocated capacity for an aggregate. As you can see in my response, I created a quick scriptlet which displays the information regarding total volume capacity allocated, but this is only part of the potentially thin provisioned capacity. LUNs can also be thin provisioned inside the volume. Additionally, some may find how much overcommitment exists with no storage efficiency applied as well (this can help with IOPS density calculations, for example).
To address this, I created a function which will display the total, used, saved, and committed capacity for an aggregate…
|
1 |
Get-NcAggr | ?{ $_.Name -notlike "*root" } | Get-NcAggrOvercommitReport | Format-Table -AutoSize |
|
1 |
Get-NcAggr | ?{ $_.Name -notlike "*root" } | Get-NcAggrOvercommitReport | ?{ $_.CommittedPercent -gt 200 } |
In December I had fun solving the “riddles” at Advent Of Code and a large number of them (starting with number 1) had strings for input that needed to be parsed. So, posting this for myself, cause I can never remember it….
|
1 2 3 4 5 6 7 8 9 10 |
# the input string $string = "This is a string" # convert it to a character array $array = $string.ToCharArray() # now we can iterate like any array foreach ($char in $array) { $char } |
The output:
|
1 2 3 4 5 6 7 8 |
# the input string $string = "This is a string" # create an array from an arbitrary separator, in this case a space $array = $string.split(" ") # this will also work $array = $string -split " " |
This also works with regular expressions…
|
1 2 3 4 5 6 7 |
$string = "a1b2c3d4e5f6" # split on numbers - remember, this will remove the numbers from the output $string -split "\d" # split on letters - this will remove the letters from the output $string -split "\D" |
Environmental information, for example temperature, fan speed, etc., provide critical information about the health of your clustered Data ONTAP system. Depending on your version of ONTAP, you can query the environmental information different ways to find out the status.
With ZAPI version 1.21 and above (cDOT 8.2.3+) the environment-sensors-get-iter API exists, which makes it excessively easy to collect environmental information about the controllers. We can take the same approach with environmental sensors as performance information:
Performance monitoring is a complex topic, but it’s something that is vital to the successful implementation and maintenance of any system. In the past I’ve had several posts about using Perl for gathering performance statistics from a 7-mode system (using ONTAP 7.3.x, which is quite old at this point), so I thought it might be a good time for an update.
I originally documented some of this information in a response on the NetApp Community site. This post expands on that a bit and documents it externally.
The NetApp PowerShell Toolkit has three cmdlets which we can use to determine what objects, counters, and instances are available, and a fourth cmdlet to actually collect the data.
One of the challenges when using the NetApp vRO Package for WFA has been making the inputs dynamically populate with the correct information from WFA. If you add a new volume, aggregate, SVM, or other entity to your NetApp, you want it to show up in your workflows to be able to take advantage of it. There are workarounds, such as using the database or creating a filter/finder to retrieve the information, but each of those was flawed, primarily because they would not be updated to use new query parameters automatically if the WFA admin updated the workflow. Fortunately, WFA 3.0 has fixed this by adding a new REST method to the workflows namespace which will return the valid values back for you.
To take advantage of this we need a helper action to retrieve the values from WFA, and another helper to provide the dependent inputs and extract the information we want from the response and put it into the correct format for a vRO input.
Just a quick tip today. While setting up a lab I had the need to mount a cDOT (8.3.0) export from behind a NAT gateway. When attempting the mount operation I got a relatively unhelpful error:
After some digging, I found that the cause of this is a setting on the storage virtual machine (a.k.a. SVM, formerly vserver). The problem is that by default cDOT expects that a port <= 1024 will be used for the mount operation. When NAT happens between you and the export, you are at the mercy of the gateway device for the port to be used. By setting the SVM NFS option mount-rootonly to disabled, this requirement is lifted.
To fix the problem from the cluster shell:
|
1 |
vserver nfs modify -vserver svmName -mount-rootonly disabled |
To fix the problem using the NetApp PowerShell toolkit:
|
1 2 3 4 5 6 |
# create the config parameter template $serviceConfig = Get-NcNfsService -Template $serviceConfig.IsMountRootonlyEnabled = $false # update the SVM configuration Get-NcVserver $svmName | Set-NcNfsService -Attributes $serviceConfig |
Not too long ago we released a new version of the vRealize Integration Package for OnCommand WFA v3.0, which had a significant number of improvements around speed, flexibility, and overall robustness.
The vRealize Integration Package is a series of vRO workflows which take advantage of Workflow Automation’s REST interface for executing workflows. Version 3 of the package has been almost completely rewritten to be faster and easier to use than previously. This was done by implementing functionality using scriptable tasks, storing the WFA REST host connection and referencing it, and improving the debug log output.
New with this version is the vRealize Orchestrator action getUserInputValues. This action relies on functionality found in WFA version 3.0+ where the REST API has the ability to return valid values for WFA inputs which are “query” fields. This action makes it easy to add dynamic, real-time population of workflow inputs based on the actual WFA data.
Update (2016-02-01) – The package is now available on the NetApp Toolchest! This is the best location to get it from as it will always be up-to-date.