Moving Vdisks online across EVA Disk Groups?

[SAKET_5]

Hi All,

I thought I knew this one pretty well but some questions have been raised and I am after forum support to either approve/deny my theory which I present as below:

On an EVA500 (VCS V.3.028) - once a Vdisk is created from a disk group and presented to a host, it is not possible to migrate this Vdisk to another disk group online. For ex. say Vdisk_DG1 (a vdisk from Disk Group 1) is experiencing heavy I/O load and it is determined that by migrating this Vdisk to DG2 (Disk Group 2) - I/O load can be handled better as this disk group is not being used heavily - how would one go about achieving this goal? My understanding is - you could either create a Snapclone of the original Vdisk but create the clone in the disk group you want - shut down the host - unpresent the original Vdisk and present the clone with the same LUN (Logical Unit Number) and you are done! Note that the procedure I describe is not online as host downtime is concerned.

It seems on an EMC CX700 such operations can be performed online while the host continues to run (?)...

Your thoughts, guys?

Regards,
Saket.

[Mike Reznak]

Hi,

I don't know for what OS you wish to do it, but for OpenVMS it is possible to do it on EVA without rebooting the server. The changed disk has to be unmounted first. And there has to be no mistake with LUN number. If you change it, then reboot is necessary. I don't have much experience in Windows, but I'd try it the same way.

Mike

[Luk Vandenbussche]

Hi,

On HPUX it is also online possible if you umount the filesystems, export and import the volumegroup

[SAKET_5]

Am I missing something here guys?...if you unmount the filesystem first - it is not really an online/seamless operation is it??...and never in my original query did I provide an assumption that the Vdisks at the host end only map to data partitions - try unmounting your root filesystem or boot volume and call the operation online!SAN boot is obviously heavily used - we are dealing with Tru64/Linux/Windows/Solaris - as far as I understand this has to be an array level feature - forget what one would do at the OS end just for the moment!

[Uwe Zessin]

I don't see any chance to do it today, sorry.

And I don't see this even remotely on any roadmap I am afraid, double sorry.


> Your thoughts, guys?

If you try a snapclone, I am sure you are aware that it will get a new UUID and thus a new LUN WWID which is not a good thing for Tru64 Unix? Just a friendly reminder to save the original's WWID and apply it to the new copy, but never present the original and the copy to the same host!

[Mike Reznak]

I forgot to mention, what you've just picked up. I have never tried it with on-line system disk or a disk with accessed files and I doubt, it's possible to do it on EVA.
But I had tried it with unaccessed mounted disk, and it worked so I might give it a try with accessed one. But I haven't heard about this possibility.
If CX700 does it, then it's another step forward.

Mike

[Uwe Zessin]

Eh, don't forget that most operating systems don't have a feature like OpenVMS' mount verification. I have seen Tru64 Unix panics when the system device was not available. Windows can hang when access to the page file takes too long and so on...

[SAKET_5]

Thanks Uwe...yes aware of Tru64 issue...and yep as far as moving Vdisks are concerned, you just re-assured that my original theory is sound.

Consider case closed :-)

Regards,
Saket.

[L. B. Andersen]

If you have needs like this, and you do not have a storage system able to provide this functionality, you should take a look at a feature called DRU (data relocation utiltity), that is able to do online (through the server) migration of data volumes. This is also able to move from dynamic to basic vv.

To the best of my knowledge, it is available for Windows and some Unix flavours

[Edgar_8]

Hi Saket,

What O/S are you running? I know in HPUX what you could do is extend the VG on the new VDISK/LUN. Mirror the data across to the new VDISK/LUN. Reduce existing VDISK/LUN from VG/mirror.

Regards

[Duncan Edmonstone]

Did this issue by any chance come to you from EMC? I know for a fact its one of the points they bang on about in their EVA FUD presentation.

I think you need to understand the context of this issue though:

1) The way you configure a CX700 is with 'lots' of RAID groups (cos its a traditional modular array)

2) The way you configure the EVA is with just one or two disk groups

SO... in a CX system, the requirement to move data around to get better performance is much more important (because of its architecture). On the EVA, if configured correctly you won't need to do this.

So EMC have added a feature to their array to get around a shortcoming, and now tout it as an 'advantage' over the EVA!

HTH

Duncan