Very moving....

Chris has posted an interesting piece about migrations and length of time that it takes. We've recently done a number of migrations to remove some legacy DMX/Clariion from our estate and our experience suggests that this is mostly a server team piece of work. I guess it depends on the split of the responsibilities, but in our world, the storage team is responsible for the environment up to the HBA.

He does a great job of listing the processes and procedures; the things you need to do but I think there are some additional things to consider.

1) When migrating; consider your current LUN sizes. I suspect that if you have a lot of legacy arrays, you will find that you have extremely small LUN sizes. Take the chance now to review and revisit. This will potentially create extra work at migration time but it will be worth doing. As Chris says, this will make it more time consuming and complex but if you don't do it at this time; when will you do it? Once the data is in-place and migrated; you almost certainly won't get the chance to revisit. Try and do it now!

2) Use of thin-provisioning technologies; if you want to leverage thin provisioning technologies, you are going to struggle with the current migration methodologies; see if you can rightsize file-systems but this might require an outage. Your choice of technology if you want to go Thick-Thin is rather limited at the moment. cue: Farley's obligatory 3Par plug.

3) Tiering; you can use this as an opportunity to right tier your data. Moving from Tier-1 to Tier-2 may be possible. But make sure you understand your transaction profiles and I/O rates but odds are you can probably migrate all that RAID-1 to RAID-5.

4) Be aggressive if you want to realise savings; you could be paying maintenance on the array until it is turned off, so that piddly little system which doesn't get moved could cost you thousands.

5) Negotiate maintenance holidays; if you are migrating and not changing vendor, you might find that you can negotiate a maintenance holiday on the arrays you are migrating from. But see 4), these offers are almost always time-bounded.

6) Find out what unsupported really means!! If you are like most big shops, you will find that you've got a load of hosts which are down-rev and no-one wants to touch! So you have a couple of options, keep an old legacy array about and consolidate the down-rev onto that. Or talk to the vendor and find out what unsupported means, does it mean it won't work? Try and force an RPQ but be aware there's a lot of stuff out there which is running quite happily even though theoretically it's not supported.

How quickly can you do it? Well after a couple of months of planning; we consolidated 10 arrays down to two in a couple of months. The bulk of the work was the Veritas scripts and very few outages were needed.

I would like to think that you should be planning your exit from any kit from the moment that you deploy! I am a realist and you probably won't!

Comments

[tim burlowski]

Good stuff.

All too often planning the exit strategy resolves to "hope I'm not employed here when I have to migrate".

[Jeff Wasilko]

This is why I love Veritas Volume manager. I had to do a couple of migrations earlier this year and it was great to do it all w/o any downtime.

[Jered Floyd]

Another thing to consider is deploying an architecture that will never require fork-lift migrations to occur. We're NAS, not SAN, but at Permabit we've built a grid architecture that never needs replacing. Our Enterprise Archive consists of independent servers all connected together via Gigabit Ethernet backplanes. New nodes of whatever the current technology is can be added at any time, and older nodes can be removed at any time. Data motion internal to this system is entirely automatic.

Over a period of, say, 20 years you'll have replaced all the hardware in your system between four and six times, but you'll never have had to do the sort of painful migration planning because it happens automatically and continuously, a few nodes a month, quarter, or year. New nodes incorporate new interconnects, like 10GbE, so that doesn't become the limitation either. I don't know of anyone else who has this sort of flexibility today.

Of course, from a SAN background you would need to do an initial migration to a NAS-attached tier, but I've found that this is very attractive to customers I've met with. We're not trying to replace Symmetrix for transactional database information, but anything else is candidate to be put on an archive tier. (I also hear the terms "value tier", "tier 2/3/4", and others depending on who I talk with.) Our archive tier of storage delivers massive cost savings and provides truly scalable deduplication, so cost savings can be higher. I have more details on this over at my blog.

As for Farley, you won't get a 3Par pitch from him. He works for us now. ;-)

Regards,
Jered Floyd
CTO, Permabit Technology Corp.

[Jered Floyd]

My mistake, I got the wrong Farley; I guess you mean Marc Farley who you link to. I meant Bob Farley, our well-known NY rep.

--jered

[Martin G]

Jered, looks interesting but you always need to be considering the exit from any architecture you put in place.

There are quite a few grid/cloud architectures which are beginning to appear; some early days, some more mature. It's going to get crowded and it'll be interesting to see who wins out.

But at some point, it isvery likely that a multi-petabyte migration looms large in a lot of storage managers' futures