Defining Unified

The word “unified” in Unified Storage is meant to mean a unification of the common access protocols; block and file. Typically, many arrays cover only a subset of available storage access methods – CIFS/NFS, iSCSI and/or Fibre Channel. However, take a look “under the hood” and you will see that many of these products – from a physical perspective – are not unified at all.  EMC’s VNX is a marketing triumph, bringing the CLARiiON and unloved Celerra platforms together into what is sold as a magical single product.  In truth it’s far from that, with the two separate products still existing in physically separate shelves, albeit with a shiny new bezel.  Having a single management interface, of course does help to complete the illusion.

Probably the only big vendor selling a true unified platform is Netapp.  They have pretty much always offered the standard range of protocols, including iSCSI at no extra cost.  However, even this platform isn’t a perfect solution; in previous years I’ve done performance and capacity comparisions of Netapp versus the competition for block storage and found it significantly lacking in horsepower, something I know they’ve worked on in recent years.

Should we care if the hardware isn’t fully integrated?  Does it matter that we’re putting components together like a 1970′s hi-fi system?  Well, like everything, it depends.  Building a hi-fi system out of individual components is pretty straightforward; the standards and links between each piece are well defined and consistent.  Pulling together NAS gateways and storage from different vendors is fraught with support issues and taking a single “unified” product guarantees support is from a “single throat to choke”, even if each piece isn’t best of breed.  It also means simplified management too.

Market Positioning

Unified storage products are great for smaller organisations, especially those without dedicated storage teams.  However where performance and scale are important, unified arrays are probably not the optimum solution.  As with everything in IT, there’s no right or wrong way, just many shades of grey.

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.

So, as part of their rebuttal, Netapp employees pointed me to two features; snapmirror migrate and Data Motion.  In the spirit of fairness, I have researched these two features using the only tools available to me – Netapp documentation – and here’s what I found.

SnapMirror Migrate

This feature is similar in nature to the concept of “failover” on large EMC arrays where a remote array takes over operation of a local LUN.  As the operation is taking place on NAS, things are slightly different.  Here’s a direct quote from the Data ONTAP System Command Reference:

“The first thing migrate will do is check the source and destination sides for readiness. Then, it will stop NFS and CIFS service to the source. This will prevent changes to the source volume’s data, which will make it appear to clients as though nothing has changed during the migration. It will run a regular SnapMirror transfer between the two volumes. At the end of the transfer, it will migrate the NFS filehandles, bring the source offline, and make the destination volume writable.”

So what does this mean?  Presumably the first thing that happens is that all I/O operations are suspended and the hosts are unable to write to their target volumes.  This introduces a whole range of concerns about data integrity and data loss if any kind of outage occurs while the copy is taking place.  It isn’t clear whether the volume effectively becomes unavailable.  Here’s the next quote:

“The migrate process will not take care of renaming or exporting the destination volume.
As a result of this process, the source volume home will be taken offline, and NFS service to this filer will be stopped during the transfer. CIFS service on the source volume will be terminated and CIFS will have to be set up on the destination.”

Clearly not a transparent, non-distruptive migration then.  I’d suggest that SnapMirror Migrate is purely an extension the ability to move data to other filers and not an “in-filer” migration function due to the impacts on file handles and I/O.  Imagine moving 16TB volumes around using this approach; no thank you.

Data Motion

There’s not much to say about this product – and this time I quote from the Data ONTAP 8.0 7-mode release notes:

“Data Motion is not supported

Data Motion was introduced in a previous release, but it is not supported in Data ONTAP 8.0 7-Mode.
The Data Motion feature integrates virtual storage, mirroring, and provisioning software technologies so that you can perform data migrations non-disruptively in both physical and virtual environments.”

Whoops!  Guys, don’t try and sell me on a technology you’ve since discontinued!  I’d be pretty miffed if I’d built my process around this tool and was then told I could no longer use it.  The release notes imply Data Motion will be back again as a feature in future releases.  It really demonstrates that the ONTAP code is struggling when features have to be removed and re-introduced over time.

I stick by my assertion that Data ONTAP is becoming unwieldy and I’m obviously not the only one of this opinion.  Netapp need to pull some serious rabbits out of the colloquial hat otherwise they seriously risk losing ground to better competition.

Lots of people will be quick to point out to me that Netapp sell lots of products.  Well, yes they do and the majority of those relate to a single core product – Data ONTAP running on some kind of bespoke hardware.  There are a few other bits and pieces out there – DataFort and SANScreen for example, but most software and hardware products still revolve around the core function of providing Networked Attached Storage.

Two thoughts intrigue me:

• Despite Netapp’s “reputation”, people still continue to buy from them.  By “reputation” I mean, complexity and price – I won’t even mention the sales culture.
• Competition in the sector must surely mean that growth in the single NAS product can’t continue forever, when newer products that have been developed with the benefit of hindsight are available in the marketplace and those vendors become more established.

It’s the second of these points that probably concerns me most.  Data ONTAP has some technical issues in performance and scalability.  The time taken to develop Data ONTAP 8 has demonstrated that integrating new features into the existing code base is a time consuming and presumably expensive exercise.  Netapp have no other product line to rely on and aren’t introducing new hardware/software as successors to the existing product line.

Compare Netapp to other vendors, specifically their arch-nemesis EMC.  EMC have fundamentally re-invented storage array technology with the introduction of V-Max.  Over the years they invested in technology other than their main Symmetrix range; CLARiiON, Centera, Celerra, Iomega, RecoverPoint are only a few that spring to mind.  There are many more.  The software portfolio of technology unrelated to Symmetrix is even greater.  Netapp remain fixed on their core product platform and the Data ONTAP architecture, attempting to make one hardware device fit all flavours of storage.

Despite the apparent flaws in Netapp’s technology, customers continue to buy and that is reflected in continued growth.  But surely it’s just a matter of time before their market share begins to erode.  Perhaps rather than acquiring technology that further expands features of their current platform (like Data Domain) they should branch out and buy into technology in other areas by acquiring 3Par, Compellent or Pillar perhaps.  Of course the only problem with following this direction is that it admits defeat in using the existing Data ONTAP platform as an all-protocol encompassing storage platform.  When you’ve spend years criticising the competition, you’ve pretty much painted yourself into a corner that becomes very difficult to get out of.

I may be being a little unfair.  From experience Netapp is good and bad in the efficiency stakes; we all know about the 10% WAFL overhead and the default 20% snapshot reserve, but do we know that Netapp rounds down drives to a consistent size?  Do we know how many un-needed snapshots we have lying around or how many flexclones we created for testing, but don’t need any more?

On the positive side, snapshots are efficient; LUNs and shares can be thin provisioned; I can clone volumes from one another using Flexclone at an initial minimal or no cost in terms of extra storage.  Backups with SnapVault are efficient as they’re effectively an incremental forever design.

Unfortunately perception doesn’t always reflect reality.  Whilst the Netapp product range does undoubtedly offer many space reduction features, these may be poorly implemented by customers, leading to a view that Netapp technology is inefficient. 

So does this mean that vendors are to blame for not communicating the message about the efficiency of their products?  Well, I think there’s blame on both sides.  Going back to Netapp, I’m sometimes bewildered by the number of software features available in Data ONTAP, most of them beginning with Snap or Flex.  What complicates things further is the interaction (or not) of these features with each other.  I like to think I’m reasonably intelligent, however even as a consultant I struggle to understand the options and I’ve had discussions with Netapp previously where even their top people couldn’t definitively confirm whether certain products could be used in conjunction with each other.  This creates customer confusion and helps to perpetuate the myth of Netapp inefficiency.  

On the other hand, customers have an obligation to keep their own house in order; badly thought out designs and poorly implemented management practices also add fuel to the fire on the efficiency myth and you can’t blame the vendor for that.

Is there a solution?  For Netapp, perhaps some unbiased feature reviews would be good – I may choose to do a series on that in the near future.  Here’s another idea – let’s start a Storage Myths site – then we can confirm or knock down these myths one by one just like watching Myth Busters!  Send me your Storage Myths and we’ll compile a list….