Intro
I was working with a customer recently on their new clustered Data OnTap
environment. They upgraded from 7-mode and were working on their Disaster
Recovery solution. In a 7-mode world, copying SMB shares and NFS exports from
a source FAS into a DR target FAS is really just a file copy. The customer
environment is relatively small and they like to keep it simple. So doing a
simple file compare of /etc/exports
works for them.
Of course cDOT changes things. But you can still take a similar approach to making sure your DR storage virtual machines stay in sync with their sources. NFS exports and SMB shares are SVM-local items so those don’t transit a SnapMirror. So you want to have everything mounted and ready to go should you ever have to pull the trigger on breaking a snapmirror.
I found
this post
on datacenterdude.com that covers taking this approach for SMB. They even
provide a -printOnly
parameter to output the powershell commands for the
restore rather than running it. So I whipped up a similar appraoch for NFS
exports. Note that these scripts will get the export policies and rules for
-Protocol nfs
or -Protocol any
or even -Protocol cifs
but you should
use the datacenter dude SMB-specific scripts for the latter.
So I’ll show how to use these scripts
Script download
- my fork of the datacenterdues github repo containing the scripts reference below
- The datacenter dudes original repo . My pull request was accepted and these scripts may also be found there.
Example cluster policies and rules
Here are the example policies and rules in my OnTap 8.3 simulator
sharney@zenarcade:~/tmp$ ssh admin@192.168.2.13
Password:
cluster1::> export-policy show
Vserver Policy Name
--------------- -------------------
vs1 default
vs1 rwpolicy
2 entries were displayed.
cluster1::> export-policy rule show
Policy Rule Access Client RO
Vserver Name Index Protocol Match Rule
------------ --------------- ------ -------- --------------------- ---------
vs1 rwpolicy 1 any 0.0.0.0/0 any
vs1 rwpolicy 2 nfs 0.0.0.0/0 any
2 entries were displayed.
cluster1::>
Backup the policies/rules
Run a backup, saving to xml files suitable for a future import. You can also
pass a -csv
parameter to save the policies and rules to csv. This is useful
for an “eyeball audit” of things. I used verbose output as well in the example.
PS Z:\tmp> .\backupExportPolicyRules.ps1 -s 192.168.2.13 -u admin -p netapp123 -v vs1 -ep policy.xml -er rules.xml -sp m
ore
************************EXPORT POLICIES START*****************************************
NcController : 192.168.2.13
PolicyId : 8589934593
PolicyName : default
Vserver : vs1
PolicyIdSpecified : True
NcController : 192.168.2.13
PolicyId : 8589934595
PolicyName : rwpolicy
Vserver : vs1
PolicyIdSpecified : True
************************EXPORT POLICIES END*****************************************
************************EXPORT RULES START*****************************************
Vserver : vs1
AnonymousUserId : 65534
ClientMatch : 0.0.0.0/0
ExportChownMode : restricted
ExportNtfsUnixSecurityOps : fail
IsAllowDevIsEnabled : False
IsAllowSetUidEnabled : True
NcController : 192.168.2.13
PolicyName : rwpolicy
Protocol : {any}
RoRule : {any}
RuleIndex : 1
RwRule : {any}
SuperUserSecurity : {any}
VserverName : vs1
IsAllowDevIsEnabledSpecified : True
IsAllowSetUidEnabledSpecified : True
RuleIndexSpecified : True
Vserver : vs1
AnonymousUserId : 65534
ClientMatch : 0.0.0.0/0
ExportChownMode : restricted
ExportNtfsUnixSecurityOps : fail
IsAllowDevIsEnabled : True
IsAllowSetUidEnabled : True
NcController : 192.168.2.13
PolicyName : rwpolicy
Protocol : {nfs}
RoRule : {any}
RuleIndex : 2
RwRule : {none}
SuperUserSecurity : {none}
VserverName : vs1
IsAllowDevIsEnabledSpecified : True
IsAllowSetUidEnabledSpecified : True
RuleIndexSpecified : True
************************EXPORT RULES END*****************************************
Delete rules and policies from cluster
Note that you can’t delete the default policy.
cluster1::> export-policy rule delete -vserver vs1 *
2 entries were deleted.
cluster1::> export-policy rule show
This table is currently empty.
cluster1::> export-policy delete -vserver vs1 -policyname rwpolicy
Error: command failed: Ruleset is in use by a volume
cluster1::> vol modify testvol2 -policy default
Volume modify successful on volume testvol2 of Vserver vs1.
cluster1::> export-policy delete -vserver vs1 -policyname rwpolicy
cluster1::>
As you can see the volume testvol2
is using one of the policies. Here’s a
way to check this from Powershell rather than the cluster CLI.
PS Z:\tmp> Get-NcVol -vserver vs1 | Select Vserver,Name,@{N="Export Policy"; E={ $_.VolumeExportAttributes.Policy }}
Vserver Name Export Policy
------- ---- -------------
vs1 rootvol default
vs1 testvol default
vs1 testvol2 rwpolicy
Restore using the scripts
First let’s just look with -printOnly
parameter
PS Z:\tmp> .\restoreExportPolicyRules.ps1 -s 192.168.2.13 -u admin -p netapp123 -v vs1 -ep policy.xml -er rules.xml -sp
less -po true
=====================================================================================
EXPORT POLICIES
=====================================================================================
PolicyName PolicyId Vserver
---------- -------- -------
default 8589934593 vs1
rwpolicy 8589934595 vs1
=====================================================================================
--------------------
New-NcExportPolicy -VserverContext vs1 -Name "rwpolicy"
--------------------
=====================================================================================
EXPORT RULES
=====================================================================================
Vserver : vs1
AnonymousUserId : 65534
ClientMatch : 0.0.0.0/0
ExportChownMode : restricted
ExportNtfsUnixSecurityOps : fail
IsAllowDevIsEnabled : False
IsAllowSetUidEnabled : True
NcController : 192.168.2.13
PolicyName : rwpolicy
Protocol : {any}
RoRule : {any}
RuleIndex : 1
RwRule : {any}
SuperUserSecurity : {any}
VserverName : vs1
IsAllowDevIsEnabledSpecified : True
IsAllowSetUidEnabledSpecified : True
RuleIndexSpecified : True
Vserver : vs1
AnonymousUserId : 65534
ClientMatch : 0.0.0.0/0
ExportChownMode : restricted
ExportNtfsUnixSecurityOps : fail
IsAllowDevIsEnabled : True
IsAllowSetUidEnabled : True
NcController : 192.168.2.13
PolicyName : rwpolicy
Protocol : {nfs}
RoRule : {any}
RuleIndex : 2
RwRule : {none}
SuperUserSecurity : {none}
VserverName : vs1
IsAllowDevIsEnabledSpecified : True
IsAllowSetUidEnabledSpecified : True
RuleIndexSpecified : True
=====================================================================================
New-NcExportRule -VserverContext vs1 -Policy "rwpolicy" -Index 1 -Protocol "any" -ClientMatch "0.0.0.0/0" -Anon "65534"
-ReadOnlySecurityFlavor "any" -ReadWriteSecurityFlavor "any" -SuperUserSecurityFlavor "any" -ChownMode "restricted" -N
tfsUnixSecurityOps "fail" -DisableDev -EnableSetUid
--------------------
New-NcExportRule -VserverContext vs1 -Policy "rwpolicy" -Index 2 -Protocol "nfs" -ClientMatch "0.0.0.0/0" -Anon "65534"
-ReadOnlySecurityFlavor "any" -ReadWriteSecurityFlavor "none" -SuperUserSecurityFlavor "none" -ChownMode "restricted"
-NtfsUnixSecurityOps "fail" -EnableDev -EnableSetUid
--------------------
Note that the default policy is skipped here by the restore script. We get commands which would be suitable for a cut and paste perhaps with modifications.
Now do it for real:
PS Z:\tmp> .\restoreExportPolicyRules.ps1 -s 192.168.2.13 -u admin -p netapp123 -v vs1 -ep policy.xml -er rules.xml -sp
none
=====================================================================================
PolicyName PolicyId Vserver
---------- -------- -------
rwpolicy 8589934596 vs1
=====================================================================================
Check the results
This time check from powershell instead of the cluster CLI.
PS Z:\tmp> Get-NcExportPolicy -Vserver vs1
PolicyName PolicyId Vserver
---------- -------- -------
default 8589934593 vs1
rwpolicy 8589934596 vs1
PS Z:\tmp> Get-NcExportRule -Vserver vs1
PolicyName RuleIndex ClientMatch Protocol RoRule RwRule Vserver
---------- --------- ----------- -------- ------ ------ -------
rwpolicy 1 0.0.0.0/0 {any} {any} {any} vs1
rwpolicy 2 0.0.0.0/0 {nfs} {any} {none} vs1
Now reset the volume export policy. First we check via powershell, then we
make the update using Update-NcVol
. Note that the method used is derived
from the help page examples for the cmdlet. Then check again to verify the change.
PS Z:\tmp> Get-NcVol -vserver vs1 | Select Vserver,Name,@{N="Export Policy"; E={ $_.VolumeExportAttributes.Policy }}
Vserver Name Export Policy
------- ---- -------------
vs1 rootvol default
vs1 testvol default
vs1 testvol2 default
PS Z:\tmp> $q = get-ncvol -template
PS Z:\tmp> Initialize-NcObjectProperty $q VolumeIdAttributes
PS Z:\tmp> $q.VolumeIdAttributes.Name = "testvol2"
PS Z:\tmp> $q.VolumeIdAttributes.OwningVserverName = "vs1"
PS Z:\tmp> $a = Get-NcVol -Template
PS Z:\tmp> Initialize-NcObjectProperty $a VolumeExportAttributes
PS Z:\tmp> $a.VolumeExportAttributes.Policy= "rwpolicy"
PS Z:\tmp> Update-NcVol -Query $q -Attributes $a
NcController : 192.168.2.13
SuccessCount : 1
FailureCount : 0
SuccessList : {testvol2}
FailureList : {}
PS Z:\tmp> Get-NcVol -vserver vs1 | Select Vserver,Name,@{N="Export Policy"; E={ $_.VolumeExportAttributes.Policy }}
Vserver Name Export Policy
------- ---- -------------
vs1 rootvol default
vs1 testvol default
vs1 testvol2 rwpolicy
This seems a bit trickier at first but made sense to me once I got the hang of what the man page example showed.
Wrap up
I’m much more of a Linux guy and spent a lot of time with Perl, Bash, and ssh managing 7-mode filers. This presented me an opportunity to get a little more acquainted with Powershell and the rich API NetApp exposes. I could have done the same with Perl or Python and the API as well. But NetApp has put a lot of work and some higher-level functionality into the cmdlets. I was able to take a workflow pattern that I’ve used a lot in 7-mode (to migrate 100’s of SMB shares and NFS exports to NetApp) in cDOT with PowerShell, There are lots more ways of doing this and some of those are probably more elegant. The point here, however, was to use simple tools to accomplish a relatively simple task. Automation is built on simple building blocks like this.
In addition to the excellent datacenterdudes.com, I also found this series on practical-admin.com to be informative.