Storage Virtualization Showdown (Part 3): Data Mobility

In this part of the Storage Virtualization Showdown series, I’ll be discussing storage virtualization capabilities that enhance the commoditization of storage

Why Data Mobility?

Before we can take advantage of the performance and technological enhancements of new storage equipment, and benefit from the better cost structures of more efficient and dense hardware, we must first move our data from the old systems onto the new. 

However, storage migrations are quite complex.  As greater numbers of applications are deployed and datasets increase in size, the time and labor overhead to coordinate successful migrations increase as well.  For many organizations, much of their staff’s time is spent in the continual migration of data from old to new hardware.  We are not talking about time spent as storage admins wait on robocopy or rsync commands to complete—that is negligible.  The real investment is in the change control and project management processes along with the coordinated efforts of Application Admins, DBAs, Storage Admins as rolling downtimes are performed during scheduled maintenance windows.

This is where Data Mobility comes in.  If we can leverage storage virtualization capabilities to non-disruptively move data from old arrays to new arrays completely transparently to hosts and applications, we can do away with much of the labor time previously required to coordinate migrations.  This can essentially reduce the time required for an array refresh from 6 months to a few weeks and free up staff to focus on more important tasks.

Let’s take a look at the competition:

NetApp Data Motion

NetApp storage systems, including V-Series, leverage a relatively new capability called Data Motion to enable the non-disruptive migration of block devices (LUNs) from aggregate to aggregate.  NetApp leverages its SnapMirror replication, the same technology for long-distance replication, in a more automated Data Motion facility.  The process is performed at a flex-volume level and will migrate all LUNs within the flex-volumes.

While NetApp is the only product in consideration that includes native block and NAS capabilities, the process of non-disruptive migrations is different with each protocol.  Data Motion only supports block objects while vFiler Migrate is required for file protocols.  This is slightly disappointing as it adds some complexity, however the vFiler Migrate facility does provide some useful features such as migrating NAS volumes non-disruptively across geographies.   Another consideration is the granularity of migrations.  If a customer would like to granularly migrate all LUNs individually, they would need to create a flex-volume for each LUN.  This would result in hitting the array 500 flex-volume limit much more quickly than grouping LUNs with similar requirements into larger volumes and migrating them together.  NetApp does not support LUN Encapsulation of existing external LUNs that already contain user data, which limits the flexibility some other products have when migrating into a storage virtualization platform.

EMC VPLEX

VPLEX supports both extent and device migration.  Extent migrations are useful to migrate extents between External LUNs, such as if you would like to better balance performance.  Device migrations are useful to migrate to external LUNs of different sizes that may require a new extent layout.  Both device and extent migrations are fully non-disruptive. Device migrations also allow the migration of data between VPLEX clusters within a VPLEX Metro-Plex.  This is a nice capability that demonstrates how VPLEX was designed with storage federation in mind. Due to the manual extent-based device mapping, you can expect a bit more complexity during mass migrations as admins do the work of pre-determining extent layouts rather than just pointing at a target pool of storage which is common with competitive products.

VPLEX also supports a capability called LUN Encapsulation.  This enables non-VPLEX LUNs to be brought under VPLEX’s control and re-virtualized without requiring the data to be migrated into VPLEX. LUN Encapsulation can reduce the downtime required to migrate larger LUNs.  Hosts experience a short downtime while the LUN is re-virtualized, then applications can be resumed while VPLEX carries out the actual data-migration in the background.  

IBM SVC

SVC also supports volume or extent level migration which are both fully non-disruptive.  As with VPLEX, extent level migrations are useful when evacuating an external LUN or when trying to balance load across a storage pool and eliminate hot spots.  Rather than only allowing an extent-by extent migration, SVC also includes a nice capability that allows the removal of an entire MDisk (external LUN) from a pool which invokes an automatic migration/rebalance of the extents on that LUN.  This can reduce some of the management overhead of extents by allowing administrators to focus on the back-end migration/refresh of storage without as much consideration of the applications or volumes provisioned from that pool.  A volume migration capability which enables data migration between storage pools is also available.  This does require both storage pools have the same extent size—a reason why most SVC clusters share the same extent size across all pools (more on extent sizes later in the series).  Volume mirroring is an option as well, if extent sizes differ.

Like VPLEX, SVC allows for LUN Encapsulation through an Image Mode MDisk configuration.  During encapsulation, existing user data is left in-tact while the volume is re-virtualized through the SVC appliance.  The host can then access data stored on the LUN while the SVC migrates the Image Mode disk to a fully Managed Mode disk transparently in the background.  Again, this is useful when migrating into (or out of) storage virtualization platforms—especially when applications require minimum downtime.

HDS VSP

HDS supports volume level migration between storage pools as well as page optimization within a pool.  When new external LUNs are added to a pool, pages can be automatically redistributed to balance performance.  With such a small page size, I/O is well distributed across all backend LUNs, eliminating the need to rebalance hotspots.  Volume level migrations are useful when refreshing back-end storage and replacing a pool and also useful when volume service levels change and another pool can better meet the performance requirements.  Both rebalancing and migration options are fully non-disruptive.

The VSP does not support LUN encapsulation, which limits some migration options into the platform, so you may need to use some HDS or 3rd party tools to migrate your existing data to the VSP.  

Next Up

Data Mobility is essential to achieve a great deal of the time and complexity reductions a storage virtualization platform offers.  Feel free to share your thought or experiences with Data Mobility as well, or correct any items I may have misstated.

In the next post on the series, I’ll be discussing Storage Efficiency and how the platforms compare when it comes to reducing RAW storage costs.