SnapMirror Interoperability in ONTAP

wt2

A few releases ago, ONTAP introduced a new SnapMirror engine (XDP) that changed how things replicated a bit, but also enabled the ability to perform SnapMirrors to non-ONTAP NetApp platforms like AltaVault and SolidFire. It also provided a well-received benefit of being able to perform SnapMirrors between ONTAP releases regardless of whether the versions were the same, within a few releases of one another (also known as version independent SnapMirror).

However, there was also some confusion introduced. Which ONTAP versions could SnapMirror to other ONTAP versions? Could older (DP) SnapMirror relationships be version independent? What about non-disruptive volume moves?

Well, we have answers, courtesy of the SnapMirror product manager, Chris Winter!

This covers both DR (Mirror) and Backup (Vault) versions of SnapMirror/SnapVault.

Before we start, let’s level-set on how ONTAP releases are now handled, because that impacts how SnapMirror interop is handled…

6-Month Cadence

ONTAP has a new release every 6 months, with a new feature payload. This started in ONTAP 9.0 out of a need to be more agile in development and provide more value to customers out of upgrades.

So, what changed?

  • Major ONTAP releases used to occur every 18 months or so.
    That meant it took a year and a half to wait for new features.
  • Release timing wasn’t super predictable, which meant storage admins couldn’t plan accordingly for upgrades.
    They’d usually wait a release or two for upgrades. So, they’d be a year to three years behind.
  • Major releases (i.e., 8.0, 8.1, 8.2 etc) would often have several “maintenance” releases (i.e., 8.1.1, 8.1.2, 8.1.3, etc) where bugs were fixed, but new features were *rarely* added.
    In addition, we’d also have patch releases (P), which did smaller bug fix roll ups and even development releases (D), which were controlled emergency patches for major bugs. This took up a lot of dev time and money and didn’t really offer much more in stability than a faster cadence. Plus, it kind of made things confusing for storage admins…
  • The introduction of long-term and short-term releases. 
    See below for more information…

So, what does the new 6-month cadence offer?

  • More features, faster.
    No more waiting nearly two years for new stuff.
  • Predictable releases every May/June and November/December.
    This helps upgrade planning immensely.
  • Fewer maintenance releases.
    We still have RC and patch releases, but those are fewer in quantity.

Long term/regular releases

For official information on this, see:

https://mysupport.netapp.com/info/web/ECMP1147223.html

In addition to the 6-month cadence, ONTAP releases are now broken up into two categories.

  • Regular releases are the even numbered releases (i.e., 9.2, 9.4 and so on… Spring releases) and provided 1 year of full support and 2 years of “limited support.” Limited support in this case means that we’ll still offer official support via the regular channels, but won’t be releasing new patch releases after a year.
  • Long term support releases are odd numbered (i.e., 9.1, 9.3 and so on… Fall/NetApp Insight releases). This means you get 3 years of full support and then 2 more years of limited support.

The idea of having long-term releases isn’t unique to NetApp; many other software vendors have the same idea. The value in doing this is in simplicity, cost savings for software dev and support, stability in releases and incentive for storage administrators to upgrade to take advantage of the latest and greatest features ONTAP has to offer.

In addition, this also helps storage admins make educated decisions on which releases they should standardize on.

  • Want to ensure more frequent upgrades? Standardize on a regular release cycle.
  • Want to keep a code base for a longer time period? Standardize on  the long term release cycle.

I mention the long term release cycle in this blog because it directly impacts SnapMirror interoperability.

All new SnapMirror Unified Replication (XDP) releases will support the immediately prior ONTAP release and the two ONTAP LTS releases before that.

That means if you are running, say, ONTAP 9.11 (which doesn’t exist… it’s just an example), then you’d be able to use XDP SnapMirror to/from the following releases:

  • 9.10 (regular release, immediately prior)
  • 9.7, 9.9 (LTS, prior)

And to the following future releases:

  • 9.12 (because 9.11 is the immediately prior release)
  • 9.13 (because 9.12 is the prior and 9.11 is one of the two LTS releases)
  • 9.15 (because 9.14 is the prior, and 9.13 and 9.11 are the two LTS releases)
  • 9.16 (because 9.15 is the prior and 9.13 and 9.11 are the two LTS releases)

Here are two examples.

sm-interop-example1.png

sm-interop-example2.png

There are a couple exceptions, though.

Exception #1: If you are running ONTAP 9.3, XDP SnapMirror will work across all prior ONTAP 9.x releases. Any ONTAP release prior to 9.0 will need to be upgraded to ONTAP 9.0.

Exception #2: If you are running ONTAP 9.4, XDP SnapMirror will work across all prior ONTAP 9.x releases except for ONTAP 9.2, which was the first “regular release” in ONTAP. ONTAP 9.0 is treated like a LTS release. Any ONTAP release prior to 9.0 will need to be upgraded to ONTAP 9.0.

This matrix covers up to the latest ONTAP release. I won’t be updating this matrix, because they’re essentially patterns and you can fill in the blanks based on the general logic stated above.

sm-xdp-interop

What about SnapMirror DP/Volume move support?

SnapMirror DP relationships (the older SnapMirror/block based engine) and volume move (which uses SnapMirror DP) have different restrictions than XDP, as they’re not considered eligible for version-independent SnapMirror replication.

  • As such, to use SnapMirror DP relationships across ONTAP clusters, the ONTAP versions all have to be within 2 releases after one another. For example, if you’re on ONTAP 9.3 and use DP mirrors, then you can replicate to/from ONTAP 9.3 or ONTAP 9.4.
  • Non-disruptive volume moves will all have to operate on the same ONTAP versions to be considered supported.

The following charts show a matrix of DP mirror interop support for current ONTAP versions. I won’t be updating these, because they’re essentially patterns and you can fill in the blanks based on the general logic stated above.

sm-dp-interop

volmove-dp-interop.png

How do I get my current SnapMirror relationships from DP to a more flexible XDP?

DP SnapMirror definitely has some limitations, particularly in version interoperability. But the good news is, it’s easy and relatively non-disruptive to go from DP to XDP!

https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.pow-dap%2FGUID-898A828D-B69E-4951-98AD-C8BF7D6DB7BA.html

Keep in mind that you can’t go from XDP to DP without having to rebaseline, however.

If you have any questions, feel free to comment below and I’ll find answers for you!

Advertisements

Backing up/restoring ONTAP SMB shares with PowerShell

486042-636355594290390040-16x9

A while back, I posted a SMB share backup and restore PowerShell script written by one of our SMB developers.  Later, Scott Harney added some scripts for NFS exports. You can find those here:

https://github.com/DatacenterDudes/cDOT-CIFS-share-backup-restore

That was back in the ONTAP 8.3.x timeframe. They’ve worked pretty well for the most part, but since then, we’re up to ONTAP 9.3 and I’ve occasionally gotten feedback that the scripts throw errors sometimes.

While the idea of an open script repository is to have other people send updates of scripts and make it a living, breathing and evolving entity, that’s not how this script has ended up. Instead, it’s gotten old and crusty and in need of an update. The inspiration was this reddit thread:

So, I’ve done that. You can find the updated versions of the script for ONTAP 9.x at the same place as before:

https://github.com/DatacenterDudes/cDOT-CIFS-share-backup-restore

However, other than for testing purposes, it may not have been necessary to do anything. I actually ran the original restore script without changing anything of note (changed some comments) and it ran fine. The errors most people see either have to do with the version of the NetApp PowerShell toolkit, a syntax error in their copy/paste or their version of PowerShell. Make sure they’re all up to date, else you’ll run into errors. I used:

  • Windows 2012R2
  • ONTAP 9.4 (yes, I have access to early releases!)
  • PowerShell 4.0.1.1
  • Latest NetApp PowerShell toolkit (4.5.1 for me)

When should I use these scripts?

These were created as a way to fill the gap that SVM-DR now fills. Basically, before SVM-DR existed, there was no way to backup and restore CIFS configurations. Even with SVM-DR, these scripts offer some nice granular functionality to backup and restore specific configuration areas and can be modified to include other things like CIFS options, SAN configuration, etc.

As for how to run them…

Backing up your shares

1) Download and install the latest PowerShell toolkit from https://mysupport.netapp.com/tools/info/ECMLP2310788I.html?productID=61926

ps-toolkit

2) Import the DataONTAP module with “Import-Module DataONTAP”

(be sure that the PowerShell window is closed and re-opened after you install the toolkit; otherwise, Windows won’t find the new module to import)

3) Back up the desired shares as per the usage comments in the script. (see below)

# Usage:
# Run as: .\backupSharesAcls.ps1 -server <mgmt_ip> -user <mgmt_user> -password <mgmt_user_password> -vserver <vserver name> -share <share name or * for all> -shareFile <xml file to store shares> -aclFile <xml file to store acls> -spit <none,less,more depending on info to print>
#
# Example
# 1. If you want to save only a single share on vserver vs2.
# Run as: .\backupSharesAcls.ps1 -server 10.53.33.59 -user admin -password netapp1! -vserver vs2 -share test2 -shareFile C:\share.xml -aclFile C:\acl.xml -spit more 
#
# 2. If you want to save all the shares on vserver vs2.
# Run as: .\backupSharesAcls.ps1 -server 10.53.33.59 -user admin -password netapp1! -vserver vs2 -share * -shareFile C:\share.xml -aclFile C:\acl.xml -spit less
#
# 3. If you want to save only shares that start with "test" and share1 on vserver vs2.
# Run as: .\backupSharesAcls.ps1 -server 10.53.33.59 -user admin -password netapp1! -vserver vs2 -share "test* | share1" -shareFile C:\share.xml -aclFile C:\acl.xml -spit more
#
# 4. If you want to save shares and ACLs into .csv format for examination.
# Run as: .\backupSharesAcls.ps1 -server 10.53.33.59 -user admin -password netapp1! -vserver vs2 -share * -shareFile C:\shares.csv -aclFile C:\acl.csv -csv true -spit more

If you use “-spit more” you’ll get verbose output:

backup-shares

4) Review the shares/ACLs via the XML files.

That’s it for backup. Pretty straightforward. However, our backups are only as good as our restores…

Restoring the shares using the script

I don’t recommend testing this script the first time on a production system. I’d suggest creating a test SVM, or even leveraging SVM-DR to replicate the SVM to a target location.

In my lab, however… who cares! Let’s blow it all away!

delete-shares

Now, run your restore.

restore-shares-acl

That’s it! Happy backing up/restoring!

Tips for running the script

  • Before running the script, copy and paste it into the “PowerShell ISE” to verify that the syntax is correct. From there, save the script to the local client. Syntax errors can cause problems with the script’s success.
  • Use the latest available NetApp PowerShell Toolkit and ensure the PowerShell version on your client matches what is in the release notes for the toolkit.
  • Test the script on a dummy SVM before running in production.
  • Ensure the DataONTAP module has been imported; if import fails after installing the toolkit, close the PowerShell window and re-open it.

Questions?

If you have any questions or comments, leave them here. Also, if you customize these at all, please do share with the community! Add them to the Github repository or create your own repo!

Behind the Scenes: Episode 129 – Cloud Control – Guarding Your SaaS Data

Welcome to the Episode 129, part of the continuing series called “Behind the Scenes of the NetApp Tech ONTAP Podcast.”

tot-gopher

This week on the podcast, we found NiMo!

Niyaz Mohamed (mailto: niyaz@netapp.com) joins us to discuss Cloud Control and how it fits into the NetApp Data Fabric. In addition, check out these helpful resources for more information on Cloud Control!

 

Finding the Podcast

The podcast is all finished and up for listening. You can find it on iTunes or SoundCloud or by going to techontappodcast.com.

This week’s episode is here:

Also, if you don’t like using iTunes or SoundCloud, we just added the podcast to Stitcher.

http://www.stitcher.com/podcast/tech-ontap-podcast?refid=stpr

I also recently got asked how to leverage RSS for the podcast. You can do that here:

http://feeds.soundcloud.com/users/soundcloud:users:164421460/sounds.rss

Our YouTube channel (episodes uploaded sporadically) is here:

Behind the Scenes: Episode 98 – SnapCenter 3.0

Welcome to the Episode 98, part of the continuing series called “Behind the Scenes of the NetApp Tech ONTAP Podcast.”

group-4-2016

This week on the podcast, we check in with John Spinks, SnapCenter TME, to find out what’s in SnapCenter 3.0 – just in time for its release!

Finding the Podcast

The podcast is all finished and up for listening. You can find it on iTunes or SoundCloud or by going to techontappodcast.com.

Also, if you don’t like using iTunes or SoundCloud, we just added the podcast to Stitcher.

http://www.stitcher.com/podcast/tech-ontap-podcast?refid=stpr

I also recently got asked how to leverage RSS for the podcast. You can do that here:

http://feeds.soundcloud.com/users/soundcloud:users:164421460/sounds.rss

You can listen here: