How to replicate snapshots using Qtree SnapMirror and PowerShell?

by on ‎2013-02-05 05:08 PM

Problem

As you might know (or experienced it personally), there is no way to SnapMirror volume from higher version of DataOnTap to the lower version (i.e. 8.1.2 -> 8.0.3 won’t work). You can go the other way around without any issues, but once you decide to upgrade your source storage system you’ll have to upgrade destination filer first if you want to preserve Volume SnapMirror (VSM) relationships. For VSM to work you have to have destination (first two - 8.1.x) DoT version numbers the same or higher (i.e. 8.1.2 -> 8.1.1 or 7.3.6 -> 8.1.1 will work). This can throw a monkey wrench in your system, especially if your destination filer is tied for a particular (older) version of DoT. It can easily happen due to older MK2 shelves or other reasons.

Solution

We recently purchased couple SSD shelves and I wanted to upgrade our DoT to 8.1.2 in order to setup FlashPools (Hybrid Aggregates). We ran into the problem since we had several VSM relationships used for DR purposes. I felt like a kid who has a nice and fast car in the garage but wasn’t able to take it out for a ride. The thought of spending so much money on SSD shelves and having them sitting idle was haunting me, so I decide to do something. Obvious solution was to leverage Qtree SnapMirror (QSM). There are several considerations and requirements. The major downside of QSM is that it can’t replicate snapshots from the source volume. It is logical replication and as such less efficient then VSM. I decided to create the PowerShell scripts (which draws a lot from my previous - PowerShell Script for managing SnapVault backups, updates, archiving and restoring). As you might know SnapVault is in essence Qtree SnapMirror. There’re few minor differences.

Notes

I’m using SnapManager for SQL to create consistent volume snapshots on the source filer. You’ll see reference to a ‘sqlsnap’ key word in one of the steps. I use this keyword to pull the last consistent snapshots created by SMSQL. You can replace it with whatever you have in your environment. I created QSM relationships prior to running this script and set the update interval at one hour. You will have to run a baseline transfer, but since it's QSM you'll be pushing far less data (especially if you have volatile environment). We use VIFs so I have hardcoded its name in $PrimaryPath variable that is built on the fly (SOURCE_FILER-mp01_e0a_e0b:...). I also hardcoded qtree names in $PrimaryPath and $SecondaryPath.

If you follow my example you’ll have to supply five variables: source and destination filers, volume names and number of days you want to keep snapshots on destination filer.

Let me know if you have any questions.

Good luck!

--Ivan

####################################################################################

###                                                                                                                                                       

### PowerShell Script for managing Qtree Snap Mirror.                                                                         

###                                                                                                                                                       

### Script below requires installation of DataONTAP PowerShell Toolkit available for                 

### download at URL below. I used version 1.7. You will need PowerShell 2.0 installed on         

### your workstation/server and DoT version 7.3+ on the filer to support all cmdlts.                   

###                                                                                                                                    

### https://communities.netapp.com/community/products_and_solutions/microsoft/powershell 

###                                                                                                                                   

### NOTE: Supply source and destionation filers, volume names and  number of days to keep snapshots on destination.                                     

####################################################################################

Import-Module DataONTAP

# Declare variables (source, destination, volume name, number of days).
$PrimaryNa = 'SOURCE_FILER'
$SecondaryNa = 'DESTINATION_FILER'
$PrimaryVol = 'source_volume_name'

$SecondaryVol = 'destination_volume_name'

$DaysOld='-7'

# The rest of the variables are built on the fly.
$PrimaryPath = $PrimaryNa+'-mp01_e0a_e0b:/vol/'+$PrimaryVol+'/qtree'
$SecondaryPath = $SecondaryNa+':/vol/'+$SecondaryVol+'/qtree'
$Date = Get-Date
$DatetoDelete = $Date.AddDays($DaysOld)

# Pulls the last (consistent) SnapManger for SQL snapshot (using 'sqlsnap' keyword) from the volume on the source.
Connect-NaController $PrimaryNa
$LastSnapshot = get-nasnapshot $PrimaryVol | ? { $_.Name -imatch "sqlsnap" } | Sort-Object AccessTimeDT -Descending | Select-Object -first 1

# Initiates QSM update from destination using last snapshot.
Connect-NaController $SecondaryNa
Invoke-NaSnapmirrorUpdate -Destination $SecondaryPath -Source $PrimaryPath -SourceSnapshot $LastSnapshot.Name

# Simple time loop that will wait until update on destination is done, before creating snapshot.
# This script loops every X seconds until QSM transfer status shows “Idle”.
$var = $null
while (!$var -or ($var.status -ine "idle"))
{
  $var = Get-NaSnapmirror $SecondaryPath
  start-sleep -seconds 60
}

# Creates snapshot on destination using the source snapshot name.
New-NaSnapshot $SecondaryVol $LastSnapshot

# Deletes snapshots on destination older than X days ($DaysOld).
Get-NaSnapshot $SecondaryVol | ? { $_.Created -lt $DatetoDelete } | Remove-NaSnapshot -Confirm:$false

Comments
vinith Former NetApp Employee

NIce Job.

Salutes to Ivan!

Henry

Warning!

This NetApp Community is public and open website that is indexed by search engines such as Google. Participation in the NetApp Community is voluntary. All content posted on the NetApp Community is publicly viewable and available. This includes the rich text editor which is not encrypted for https.

In accordance to our Code of Conduct and Community Terms of Use DO NOT post or attach the following:

  • Software files (compressed or uncompressed)
  • Files that require an End User License Agreement (EULA)
  • Confidential information
  • Personal data you do not want publicly available
  • Another’s personally identifiable information
  • Copyrighted materials without the permission of the copyright owner

Files and content that do not abide by the Community Terms of Use or Code of Conduct will be removed. Continued non-compliance may result in NetApp Community account restrictions or termination.