I’ve twice posted now on Data ONTAP 8.0 shortcomings and this evening I did a little more research with the IBM version of Netapp’s hardware, the N-Series products. Fortunately, IBM are slightly more generous and informative in their documentation than Netapp and this document (freely available online) provides more background information on the “DOT8″ transition process. So, I’ve tried to produce a more in-depth objective view of the steps to move to “DOT8″. Firstly the following diagram provides a clue as to how Data ONTAP has migrated to the current release.
Data ONTAP History
At the point of reaching DOT8, Data ONTAP has been re-written to run off FreeBSD as the original GX code did. This is a departure from the original Berkeley Net/2 code as documented in this post from Dave Hitz. I have no idea how much of this version of the code was a re-write, but presumably porting over WAFL with all the bells and whistles it now has wasn’t an easy task. This may go towards explaining why the current release of ONTAP took so long to come out.
Although the diagram shows the code base as being a single product, it isn’t. There are still two modes, 7-mode, emulating 7G and cluster-mode emulating the GX product line. These modes are non-interchangeable; you choose the one you want to use at system installation time and it’s fixed; no chance to change in the future. As the IBM document explains (quote) “If a customer decides to change from one mode to another, the change is a transition rather than an upgrade (or downgrade). Dual boot capabilities are not present, so the transition requires total reconfiguration of the storage system. This can include backup and restore of user data”.
I think it would have been fairer to draw two parallel lines here as it appears there are still to pretty separate versions of code masquerading as a single marketing version. So, the remainder of this discussion focuses on 7-mode.
Upgradeability
What happens if you want to take an existing system and upgrade it? Well, depending on your hardware, you may or may not be able to perform an upgrade. Systems such as the 6xxx models, 3×70 & 3×40 models are upgradeable, devices such as the 2050 are not. There are also restrictions on the disk shelves that can be used too. Should you choose to upgrade from your current 7G release, you can only move to 7-mode or build a new 8.0 installation, presumably on new hardware as you wouldn’t want to trash your existing environment. Be aware though, that upgrade actually removes certain features. For instance, SMB 2.0, IPv6 & IPSec are not supported. They will reappear in a future release. Does this mean writing these features in the ported version of WAFL was too hard or was taking too long? Why else would you remove features from an upgrade only to replace them later? One final upgradeability gotcha — Performance Acceleration Modules (PAM) are not supported with the initial version of 8.0.
Aggregates
As mentioned in my previous post, aggregates move to 100TB in size. However there are many restrictions.
- Volume SnapMirror will not replicate between unlike aggregate types; so you can’t replicated to/from 32-bit to 64-bit aggregates.
- aggr copy and vol copy commands will not work between different formats.
- Flexvol size for volumes using de-duplication in 64-bit aggregates is limited to 16TB
- System root volumes can only reside on 32-bit aggregates.
On the positive side, Qtree SnapMirror and SnapVault do work between aggregate formats.
Aggregate Migration
Here’s IBM’s statement on migration of data: “Currently there is no direct migration path or conversion from 32-bit to 64-bit aggregates. The following options can be used to migrate the data: qtree SnapMirror, SnapVault, ndmpcopy”. Each of these options also has limitations, which I don’t have time to go into, but you can read in the referenced document.
Benefits
I’ve been trying to find any benefits of upgrading to DOT8 from the customer’s perspective. For new installations, the increased aggregate size is obviously a benefit, but does come with restrictions. There are now interface groups rather than VIFs and it appears snapshots can now be named. Excluding these, I can’t see that DOT8 is anything more than a positioning exercise as Netapp continue to get the real features they wanted in this version into future releases. This has been hinted at by other commentators.
Whilst I can see the benefits to Netapp of this move, I fail to see the benefit to the customer, who will have to suffer major migration headaches to realise what are small improvements from a major version upgrade. I suspect many customers will chose to wait for 8.0.1, 8.1 or whatever version actually integrates the real improvements. During that time, it offers more opportunities for the competition to be snapping closer to Netapp’s heels.
