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

15 thoughts on “SnapMirror Interoperability in ONTAP

  1. Hello Justin,
    thanks for the great explaination. Do it’s always true that DP snapmirror is a better choice for high file count with spinning drives environment?
    Cheers

    Like

  2. Hi Justin,

    should your XDP matrix not look symmetrical, i.e. also allowing the destination to be of a higher (but supported) release?

    I’ll mail you my corrected table…

    Sebastian

    Like

    • No, the matrix in the blog is correct. The releases listed are due to resource constraints that go along with qualifying every release. And the docs *are* a disaster, which is why I created this blog until they can be corrected.

      Like

  3. Also regarding DP relationships, I’d add, that the (major) destination version (DV) must be >= source version (SV):

    SV <= DV <= SV+2

    Sebastian

    Like

  4. Just curious anyone noticing that after a DP to XDP conversion the destination side volume grows in size a bit? I’ve only converted one volume so far.
    For example: Source:49.50TB vs. Destination 49.72TB after conversion to XDP.
    Verified snapshot size on destination is only ~2MB and small on source as well. Volume options are identical as far as I can tell. I’m using the default XDP MirrorAllSnapshots policy. It just seems odd to me. For other DP relationships the sizes are identical.

    Like

  5. Hi Justin, this bit is wrong “If you are running ONTAP 9.4, XDP SnapMirror will work across all prior ONTAP 9.x releases except for ONTAP 9.2”. It will work (I’ve tested it myself) going from 9.4 to 9.2 and vice versa, just not supported. It would be correct if you replace “will work” with “will be supported”. Cheers, VC. PS If you think about it (not saying you haven’t thought about it), it makes zero sense that 9.4 to 9.1 works say, but 9.4 to 9.2 doesn’t, then 9.4 to 9.3 does.

    Like

      • Hi Lorenzo, it’s supported so it will have been thoroughly tested by NetApp Engineering. XDP snapmirror is such an outstanding piece of engineering, that it would probably still work fine all the way from 9.4 to 8.2 (when XDP first came out) – of course that is not supported. Cheers, VC

        Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s