Guest Blog: Data Migration – Choosing Your Approach

This is the second part of a three-part series in which we will discuss the “mechanics” of data migration. First, we will cover the host-based approach and give you three things to consider when pondering this option. Second, we’ll cover an appliance-based data migration technique, focusing on the Data Migration Server (DMS) from Cirrus Data Solutions.

In Part 1, we discussed the elements of Planning and Discovery which includes:

1. Documentation of the environment

2. Migration event planning and POCs

3. Replication considerations

4. Remediation

Data Migration Approach – Which One?

As with most things in life, there is more than one way to achieve the end result of a successful data migration. It’s no different here. However, there may be technical issues, business limitations, or associated costs that might sway someone’s decision. As described in this recent SSGNOW Outlook Report for “Data Migration Services, Hardware and Software”, some use cases might suggest that using a host-based approach using different types of data migration tools would be the better route versus a controller or appliance-based approach. We’ll give you a few things to consider when narrowing down your choices..

The host-based approach
Why choose a host-based approach to data migration? A few things that might indicate that this is the best approach:

The operating systems and logical volume managers (LVMs) in use in your environment. If you’re running AIX and/or Linux in your data center, they already include an LVM. Perhaps you have Veritas Volume Manager (VxVM) running on Solaris or Windows. If you are using an LVM and it is possible to attach your production servers to both old and new storage simultaneously, the LVM command set can be used to mirror volumes and move data. This is the low- to no-cost approach to data migration.

The challenge of scheduling downtime for production servers. There is a cut-over process which requires downtime for the controller or appliance based approach. If you are able to use an LVM, there is no need to take an outage, however, you may still need to schedule an outage either before or after migration to take care of any remediation indicated during the Planning and Discovery phase of the project.

The cost associated with software licensing. If you are migrating data between storage arrays from the same vendor, there are controller-based methods available which require the licensing of software to get the job done. The licensing cost is often times not insignificant.

The controller- or appliance-based approach
Why choose the controller- or appliance-based approach? There are usually technical reasons for taking this approach. Here are a few:

1. VMware is using Raw Device Mapping (RDM) volumes. Storage vMotion cannot be used on these devices to migrate data from old to new storage.

2. Microsoft Windows is not using dynamic disks. In order to mirror volumes in Windows, you must be using or willing to convert your basic disks to dynamic disks.

3. Risks associated with simultaneous attachment of server to old and new SAN/storage. Older versions of HBA firmware and drivers may not be supported on the new SAN/storage. If you can’t remediate prior to migration, you run the increased risk of encountering a problem during migration using LVM. The operating system must be capable of rescanning new storage without rebooting the server.

4. Prefer that data migration be as non-intrusive as possible. Mirroring of data on the server can incur high I/O on production volumes and the LVM usually does not have a way of controlling when and how data is copied. The Data Migration Server (DMS) from Cirrus Data Solutions is capable of intercepting I/O in a non-intrusive manner and Quality of Service (QoS) parameters can be set on migration jobs such that I/O can be better controlled during certain times of the day.

Data Migration Server from Cirrus Data Solutions

As mentioned above, the Cirrus Data Solutions DMS provides a solution to non-intrusively migrate data from a source storage array to a destination storage array. An outage is still required when the final cutover of the server is done (covered in Part 3 of this article) to drop access to the old storage and switch to the new.

Insertion into the data path.
There are a number of ways to insert the DMS into the data path between the server(s) and storage, the most common of which is on the storage side of the data path. There are four options for storage side insertion:

1. Physical – the cable from the source storage port is connected to a downstream port on the DMS. This requires that the source storage port be capable of FC-AL connectivity.

2. Physical (switch) – a DMS “extender” switch is used to insert the DMS appliance between the source storage port and the downstream port on the DMS. This option is available when either the source storage port is not capable of FC-AL, or it won’t automatically switch modes.

3. Physical (switch/multi-target) – a DMS “extender” switch is used here as well and allows a single DMS downstream port to access multiple source storage ports simultaneously.

4. Logical – this method uses either VSAN or Logical Switch capability on Cisco and Brocade fiber channel switches, respectivly to connect the DMS downstream port to multiple source storage ports.

Regardless of the insertion method, it is imperative that multi-pathing be configured and functional on your servers in order to mitigate the risk of losing storage access when the DMS is inserted into the data path.

How does the DMS work?

The DMS uses dual-port HBAs with specialized drivers. The HBA drivers contain patented algorithms that transparently intercept I/O coming from the server initiators and storage targets. The combination of the HBA and specialized driver is called a Nexus. One port of the Nexus serves as an upstream path (the server side), the other port serves as a downstream path (the storage side).

After insertion, the target port of the storage array appears on the upstream side. The server continues to function as before, with the server initiator communicating with the storage target port as if the DMS were not there. The diagram below illustrates this concept.

Once the DMS is inserted, it is then a simple matter of creating a migration job with appropriate QoS settings to copy data from old storage to new storage. Once initial copy is completed, the DMS will then periodically perform delta updates until you are ready to do the final sync and cutover of the server.

Conclusion

There are host-based and controller/appliance-based approaches to data migration. Consider the technical reasons, limitations, and advantages of each approach. You may conclude that the host-based approach is good for some servers, while the appliance-based approach is good for the rest. The DMS from Cirrus Data Solutions is a non-intrusive, transparent means of fulfilling your data migration needs.

Part 3 of this series will cover the final step in data migration, the host cut-over process.

This post – Data Migration: Choosing Your Approach [A Step By Step Guide] – originally appeared on the Headwaters Group blog and is reprinted here by permission. The first part of this Step-By-Step Guide was posted last week, here. Headwaters Group is an authorized Cirrus Data Solutions Inc. Partner. To learn more about the CDS Data Migration Server, visit the DMS Product Page, or contact Cirrus Data Solutions Inc. or Headwaters Group.