Block Storage Migration

Today migrating volumes of data between block storage systems is a big customer pain point because the process is complex, error-prone and often disruptive to business applications. Thus, making it a prime candidate for the automation and abstraction offered by software-defined storage solutions, such as ViPR.

There are three basic reasons why today’s Data Centers move block storage around:
1. Technology Refresh
2. Service Change
3. Load Balancing

Block_Storage_1
Technology Refresh is the most common use case. Most storage volumes in long-term use must be migrated every three or four years to the latest and greatest new array technology. Service change migrations occur when a volume needs either higher or lower classes of data services than it is currently consuming, such as moving a volume to an all-flash array to achieve higher throughput. Load balancing is invoked when provisioning or monitoring storage, to ensure the storage receives the level of service it expects/needs. As the data center becomes more automated and service oriented, this use case is going to become more and more frequent.

Block storage migration is often disruptive to the applications using the storage. However, it is possible, at least some of the time, for these migrations to be done in a way that is non-disruptive, in that the application keeps running while the data is moved and the application does not need to be restarted or reconfigured before or after the data is moved.

Fundamental to making a block storage migration non-disruptive to the application is that the “name” the application uses to locate and access the data cannot change because of the migration. (Name is a loose way of referring to it. How an application accesses data on a block storage device is specific to the Operating System on the virtual or physical host where the application is running. Sometimes, a label written on the block storage device, rather than an actual name identifies block storage.) There are three types of techniques that can be used during a migration that preserve the “name” used by the application:

  1. Back end
  2. Host Indirection
  3. Front end

The back end type of technique keeps the SCSI identity presented by an array or appliance to the host constant and changes the storage destination that name represents. This technique has been used for many decades to move block storage from place to place within a single array in order to balance load across spindles or change service type (RAID 1 to RAID 5, for instance). More recently, appliances have come along that insert a virtualization layer into the data path between the host and the array, allowing this same technique to be used to migrate storage between arrays. EMC’s VPLEX is an example of this sort of appliance.

Host indirection makes use of the I/O stack within a host Operating System above the SCSI layer. Within this I/O stack, the opportunity exists for mapping from one naming system to another. As long as the name that is higher in the stack is location-independent, remapping that higher-level name from one lower-level name to another allows migration without disruption. Host-based volume managers have been used to perform non-disruptive migrations using this technique for many years. PowerPath Migration Enabler also uses this type of technique to provide non-disruptive block storage migration.

Neither back end nor host indirection techniques work in all cases, because they depend on the presence of proprietary software or hardware at a specific location in the I/O stack. In contrast, the front end technique takes a standards based approach to solving the problem of migration disruption. With the front end technique, the SCSI identity used between the host and the array is moved along with the data during the migration. Because both hosts and arrays in the data center interact with this SCSI identity, this technique for achieving non-disruption relies on a set of specific rules and behaviors that could be implemented by multiple participants in a non-disruptive migration ecosystem. The most important of these are:

  • The SCSI identity presented on the front end (that is between the storage array or appliance and the host) must be location independent and movable between physical storage locations. This SCSI identity consists of the Vendor ID, Product ID and Logical Unit ID. The Vendor ID and Product ID must connote that the Logical Unit is capable of front end migration, rather than pointing to a specific manufacturer and product identity. The LU ID must be globally unique and transferable between physical entities, such as arrays or appliances.
  • With the front end technique, the cut over from origin to destination becomes more complex. During a migration, cut over is the point in time when the I/O stops flowing to the origin volume and starts flowing to the destination volume. For back end migration, cut over is hidden behind the unchanging front end SCSI identity. For host indirection, the cut over occurs at the point of remapping and is controlled on the host. For the front end technique, cut over includes elements on both the host and the storage. The SCSI standard ALUA (Asymmetric Logical Unit Access) enables a controlled cut over involving both the multipathing software on the host and the storage.
  • The SCSI behavior of every front end migratable logical unit must be common regardless of which actual physical storage currently contains the data for the logical unit. All participants in the ecosystem have to agree to implement this common behavior.

There are lots of other details involved in creating an ecosystem capable of non-disruptive migration, but these are the main features. The initial migration into front end migratable logical units may be disruptive, or may use host indirection to be non-disruptive. Once the ecosystem of host multipathing software and front end migratable storage devices is deployed in a data center, all migrations will be non-disruptive. If this idea is adopted across the industry, we’ll have a more permanent and very flexible solution going forward – one that is based on standard behavior rather than something that is proprietary.

For all three techniques that avoid disruption to applications, there is a need to bring automation and orchestration to the migration process. Software-Defined Storage Systems, such as ViPR are ideal tools to use for automating and orchestrating any migration process and for allowing the user to express her migration request with a simple, high-level command. With Technology Refresh, for instance, the user might ask to move all the storage volumes used by Consistency Group C that are located on physical Array A to physical Array B. ViPR could orchestrate the migration of Consistency Group C’s volumes to Array B and when this completes successfully, ViPR could de-provision the origin volumes as part of cleaning up.

This picture illustrates what a service for block storage migration might look like (not intended to represent present or future product).

Block_Storage_Migration_2

ViPR fulfills some of our vision for block storage migration services. For any volume with VPLEX in the data path, a ViPR API exists to migrate data non-disruptively. In addition, theChange Pool Catalog Order is available for migrating between Virtual Pools. ViPR can also make it easier to insert VPLEX into your data center (though this part is disruptive). Once you have the physical cabling in place, there is a single API to insert an existing data volume under the control of VPLEX and another simple API to connect the new VPLEX volume to the host. (Work may be required on the host to configure the application to the new volume, depending on the host software.)

For cases where VPLEX is not in the datapath, the EMC ViPR Migration Services – Host Migration Utility is another option for non-disruptive migrations. This downloadable script runs on a non-ESX host with PowerPath and uses proven PowerPath Migration Enabler technology to move the data (first trying to do it within ViPR using VPLEX). Provisioning and de-provisioning are done through ViPR commands. The Host Migration Utility also can fulfill an on-boarding use case, when the user wants to actually move data from where it is outside of ViPR onto ViPR managed storage. For instance, the user might not want to ingest the origin array into ViPR. Since the origin volume in this case is not part of ViPR, this use case can’t be satisfied by ViPR alone, but the Host Migration Utility uses ViPR to provision the destination storage and then uses PowerPath Migration Enabler to move the data from the origin to the destination without application disruption.

These two examples demonstrate just some of how ViPR helps with automation while making block storage migrations easier for customers.

About the Author: Helen Raizen