SAN migration strategy, preparation and execution

SAN migration requires strategic thinking, detailed planning, effective preparation and careful execution. The keys to SAN migration success include tasks such as ensuring firmware and driver upgrades are carried out and ensuring you work hand-in-glove with the business to minimise disruption.

In this interview, SearchStorage.co.UK Bureau Chief Antony Adshead speaks with Chris Evans, an independent consultant with Langton Blue, about the key tasks in SAN migration, the key challenges and how to overcome them.

You can read the transcript below or listen to the podcast on SAN migration.

SearchStorage.co.UK: What are the key tasks involved in SAN migration?

Evans: Firstly, we need to define what we mean by SAN migration. It could mean replacement of a storage array or it could mean replacement of the fabric that supports it.

You really need to split the [migration] work … into two parts. There are a certain number of pre-work steps you need to do, and then there’s the actual execution of the migration.

In the pre-work section, you would be looking at things like certification, developing your migration strategy and doing performance testing. We’ll talk about those in more detail.

[Regarding] certification, as you migrate onto new technology there’s a good chance that at the host or possibly the fabric level, you would need to do some migrations and upgrades of the technology. [Typically, that would be] HBA, firmware and driver upgrades.

You need to go through and look at the target environment you’re moving to and make sure that all of your software and hardware matches that and is certified by the vendor that you’re moving to.

You also need to look at your migration strategy. Obviously, people have different setups. Some people have servers that are doing disaster recovery, some people have production and development environments, and as a consequence each of those servers may have a different migration strategy. That obviously applies to virtualised environments as well.

What you’re looking to do is [to carry out the migration] without impacting existing DR strategies or the production day or so on. You are looking for the best solution for each of those platforms. Usually, what people do is build a migration strategy workbook and then apply that to each of the target servers being migrated.

You may want to also do performance testing so as you move on to a new environment, you take a few servers and test them in the new target environment to make sure you’re happy that the environment works.

Clearly, you need to look at scheduling; [when’s the best time to move your servers], and how can we fit it into [the] schedule?

All of that is classed as pre-work.

For execution, you’ll be taking the data and migrating it across. There’ll be a lot of work involved in getting change control sorted. You may have to do recabling if you’re doing a fabric migration. You may have to replug cables to hosts in order to achieve that.

You may want to do other things as well, [such as restructuring] the size of the LUNs, and that might dictate how you do that migration process.

Finally, you’ll be doing this over a number of weeks or months depending on the type of migration you’re doing, and in that case you’re building a run book with all the migration steps, all the servers and where you’ve got them to.

SearchStorage.co.UK: What are the main challenges in SAN migration and how do you overcome them?

Evans: So, let’s just split those into two environments: fabric and array. Usually, the array migrations are slightly easier, but [issues could arise]. For example, you could have scenarios where the driver firmware support between the source and target array are not the same. Or, you may be moving to another fabric.

In that instance you may have to look at other migration techniques. Some people may use a virtualisation appliance, for instance Hitachi’s USP-V as a migration tool. Other people might look at [IBM’s] SVC as a migration technique.

With fabric replacement you could well have to recable onto a new fabric and in that instance what you may have to look at is putting one-half of the multi-path setup for a server onto the second fabric, migrate the data and then move the second connection across. Clearly, it’s an impact because you’re having to physically recable as part of the migration, and that may entail more downtime. So, you need to think through the steps in detail.

One thing that comes up time and again is change control. You may have laid out your plans of when you intend to migrate and done a lot of pre-work in terms of zoning and all the upfront work you need to get the migration completed. Then you may find at the last minute the customer changes their mind or can’t make the [scheduled] weekend, so clearly it’s very important to liaise with the client you’re moving the data for and to be in touch … in case any of those scenarios come up.

Finally, you should consider the volume of data you’re migrating. You may be moving large quantities of data to a new array and need to keep the old scenario in place [while it takes] a long time to copy that data. You may be moving to another location, in which case the migration will take time.

The best way to deal with things like that is to look at the actual migration in detail [and] break it down and see whether you can do some of the replication ahead of time while the server is up and running and then at the last minute flip the connectivity so that you move to the new data at the last moment.

All of these are strategies to get around operational issues and without a doubt you have to deal with the customer and make sure you’ve got that liaison at all times.