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…
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:
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!
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!
22 thoughts on “SnapMirror Interoperability in ONTAP”
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?
Better as in it might be a bit faster, sure. XDP has a conservative recommendation of 10 million files, but we’ve seen customers do 30-50 million files in XDP with no issues.
I think we’re totally out of recommendation, our top 3 “inode champions” have this usage:
Currently using XDP…
So how’s it working for you?
We’re happy, but always improving 😉
FlexVol or FlexGroup? FlexGroup would help in XDP because it would spread those 100+ million files across multiple relationships.
FlexVol, most of them are 7-mode transitioned to cluster mode (production ones). Some of them have more than 20TB used… a nightmare, more or less. I’ve read about FlexGroup, but I’ve to find an appropriate use case in our environment.
Well, 100 million files sounds like an appropriate use case. 😛 You could always stand one up in the same SVM and start kicking the tires.
Great article as usual 😉
I think there is an issue in your XDP matrix table
Dest=9.3 compatible with 9.0,9.1,9.2,9.3
IMAO you need to invert source and replcation colors
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…
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.
Also regarding DP relationships, I’d add, that the (major) destination version (DV) must be >= source version (SV):
SV <= DV <= SV+2
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.
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.
Hi Vidad and Justin, do anyone had chance to test if version flexible snapmirror will work, for instance, from 9.4 (or 9.3) to 9.1?
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
For data migration purpose only, is possible to create a snapmirror relationship from source Ontap 8.3 to destination Ontap 9.5? i know that is not supported, but will work?
No, this isn’t possible.
which licenses are needed for unified replication? Do can I snapmirror if I have SnapMirror/SnapVault license on the source cluster and SnapVault only on destination cluster? (9.1 and above)
I tried to find this on the docs but I can’t find anything…
Should only need one, as per this: https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.pow-dap%2FGUID-90A46DC2-C432-43D7-A890-EE342FC8C382.html
Hi, the docs you linked says: “A SnapMirror license is required on both the source and destination clusters, with limited exceptions as defined below. A SnapVault license is not required if a SnapMirror license is already installed.”
It’s not clear if SnapMirror is mandatory, I think I’ll try 😉
unfortunately if I try creating XDP MirrorAllSnapshots/MirrorAndVault relationship I obtain the following error: “SnapMirror_DP license check failed for cluster [DST Cluster]. Reason: SnapMirror DP License not found.”
With XDPDefault (policy type vault), I can initialize snapmirror.