How To Add A New Load-Sharing Mirror on NetApp Cluster Mode using PowerShell

To protect the Storage Virtual Machine (SVM) namespace root volume, you can create a load-sharing mirror volume on every node in the cluster, including the node in which the root volume is located. Then you create a mirror relationship to each load-sharing mirror volume and initialize the set of load-sharing mirror volumes. As you add new nodes to the cluster, you may choose to add a new load-sharing mirror to a set of existing load-sharing mirrors.

New-NcVol
PS>New-NcVol -Name root_vs01_m3  -Aggregate sas_aggr1 -JunctionPath $null -Type dp -Size 1g -VserverContext vs01

Name          State       TotalSize  Used  Available Dedupe Aggregate   Vserver  
----          -----       ---------  ----  --------- ------ ---------   -------
root_vs01_m3  online      1.0 GB     0%    1023.9 MB False  sas_aggr1   vs01

 

Create the destination load-sharing mirror volume by using the New-NcVol cmdlet with the -type parameter set to DP (data-protection volume). The destination volume that you create must be the same size or greater than the SVM root volume.

New-NcSnapmirror
PS>New-NcSnapmirror  //vs01/root_vs01_m3 //vs01/root_vs01 -Type ls 

SourceLocation               DestinationLocation             Status       MirrorState  
--------------               -------------------             ------       -----------
ntap-clus01://vs01/root_vs01 ntap-clus01://vs01/root_vs01_m3 idle         uninitialized

 

Use the New-NcSnapmirror cmdlet with the -type LS parameter to create a load-sharing mirror relationship between the source volume and a destination volume.

Note: The -Schedule parameter does not need to be used, because Data ONTAP automatically applies the same schedule to the set of all load-sharing mirrors that share the same source volume.

Get-NcSnapmirror
PS>Get-NcSnapmirror | Select sourcelocation, destinationlocation, relationshipstatus, relationshipType, ishealthy, schedule | ft -a

SourceLocation               DestinationLocation              RelationshipStatus RelationshipType IsHealthy Schedule  
--------------               -------------------              ------------------ ---------------- --------- --------
ntap-clus01://vs01/root_vs01 ntap-clus01://vs01/root_vs01_m1  idle               load_sharing          True 5min  
ntap-clus01://vs01/root_vs01 ntap-clus01://vs01/root_vs01_m2  idle               load_sharing          True 5min  
ntap-clus01://vs01/root_vs01 ntap-clus01://vs01/root_vs01_m3                     load_sharing               5min

 

Use the Get-NcSnapmirror cmdlet with the parameters listed to confirm the relationship has been created, as well as the health of the relationship.

Invoke-NcSnapmirrorInitialize
PS>  Invoke-NcSnapmirrorInitialize -DestinationVolume root_vs01_m3 -DestinationVserver vs01 | Get-NcJob

JobId JobName                        JobPriority JobState   JobVserver           JobCompletion  
----- -------                        ----------- --------   ----------           -------------
70    SnapMirror initialize          exclusive   queued     vs01


PS>  Get-NcJob 70

JobId JobName                        JobPriority JobState   JobVserver           JobCompletion  
----- -------                        ----------- --------   ----------           -------------
70    SnapMirror initialize          exclusive   success    vs01       SnapMirror: done  

 

Use the Invoke-NcSnapmirrorInitialize cmdlet specifying the DestinationVolume and DestinationVserver to perform the initial update of a SnapMirror relationship.

Note: Do not use the Invoke-NcSnapmirrorLsInitialize cmdlet. The Invoke-NcSnapmirrorLsInitialize cmdlet is for initializing volumes for an entire set of load-sharing mirrors, not for initializing an individual volume.

Invoke-NcSnapmirrorLsUpdate
PS>  Invoke-NcSnapmirrorLsUpdate ntap-clus01://vs01/root_vs01 | Get-NcJob

JobId JobName                        JobPriority JobState   JobVserver           JobCompletion  
----- -------                        ----------- --------   ----------           -------------
87    SnapMirror Loadshare update    exclusive   queued     vs01

PS>  Get-NcJob 87

JobId JobName                        JobPriority JobState   JobVserver           JobCompletion  
----- -------                        ----------- --------   ----------           -------------
87    SnapMirror Loadshare update    exclusive   success    vs01                 SnapMirror: done  

 

Upon job completion, update the LS set by using the Invoke-NcSnapmirrorLsUpdate cmdlet specifying the source endpoint to update destination volumes of the set of load-sharing mirrors. The cmdlet makes destination volumes in the group of load-sharing mirrors up-to-date mirrors of the source volume. Separate SnapMirror transfers are performed from the source volume to each of the up-to-date destination volumes in the set of load-sharing mirrors.

Use the Get-NcSnapmirror cmdlet once more to confirm the health of the relationship.

PS>  Get-NcSnapmirror | Select sourcelocation, destinationlocation, relationshipstatus, relationshipType, ishealthy, schedule | ft -a

SourceLocation               DestinationLocation              RelationshipStatus RelationshipType IsHealthy Schedule  
--------------               -------------------              ------------------ ---------------- --------- --------
ntap-clus01://vs01/root_vs01 ntap-clus01://vs01/root_vs01_m1  idle               load_sharing          True 5min  
ntap-clus01://vs01/root_vs01 ntap-clus01://vs01/root_vs01_m2  idle               load_sharing          True 5min  
ntap-clus01://vs01/root_vs01 ntap-clus01://vs01/root_vs01_m3  idle               load_sharing          True 5min  

 

Further reading:

  1. Adding a load-sharing mirror to a set of load-sharing mirrors
  2. Initializing an individual load-sharing mirror

Failed to change NetApp volume to data-protection (volume busy)

This relationship had been intentionally broken for some testing on the destination volume and when resync was issued, it had failed due to volume busy.

                            Healthy: false
                   Unhealthy Reason: Scheduled update failed to start. (Destination volume must be a data-protection volume.)
           Constituent Relationship: false
            Destination Volume Node: 
                    Relationship ID: aa9b0b54-64d9-11e5-be3f-00a0984ad3aa
               Current Operation ID: 1bed480d-1554-11e7-aa85-00a098a230de
                      Transfer Type: resync
                     Transfer Error: -
                   Current Throttle: 103079214
          Current Transfer Priority: normal
                 Last Transfer Type: resync
                Last Transfer Error: Failed to change the volume to data-protection. (Volume busy)

To check the snapshots on the volume for busy status and dependency:
snapshot show -vserver 'vserver_name' -volume 'volume_name' -fields busy, owners  

In this case, a running NDMP backup session was preventing the resync.

To list NDMP backup sessions:
system services ndmp status  

The system services ndmp status command lists all the NDMP sessions in the cluster. By default it lists the following details about the active sessions:

To list details for a NDMP backup session:
system services ndmp status -node 'node_name' -session-id 'session-id'  

From here you can confirm this is the NDMP session you need to kill by referencing the ‘Data Path’ field. This should be the path to the volume that is failing the resync.

To kill NDMP backup session:
system services ndmp kill 'session-id' -node 'node_name'  

The system services ndmp kill command is used to terminate a specific NDMP session on a particular node in the cluster. This command is not supported on Infinite Volumes.

After clearing the busy snapshot application dependency, I was able to successfully issue the resync as per normal operations.