SnapMirror Interoperability in ONTAP

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.

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.

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.

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!