Tuesday, February 12, 2008

LUN Migration




LUN Migration

The process of a LUN Migration has been available in Navisphere as of Flare Code or Release 16. The LUN Migration is a move of a LUN within a Clariion from one location to another location. It is a two step process. First it is a block by block copy of a “Source LUN” to its new location “Destination LUN”. After the copy is complete, it then moves the “Source” LUNs location to its new place in the Clariion.

The Process of the Migration.

Again, this type of LUN Migration is an internal move of a LUN, not like a SANCopy where a Data Migration occurs between a Clariion and another storage device. In the illustration above, we are showing that we are moving Exchange off of the Vault drives onto Raid Group 10 on another Enclosure in the Clariion. We will first discuss the process of the Migration, and then the Rules of the Migration.

1. Create a Destination LUN. This is going to be the Source LUN’s new location in the Clariion on the disks. The Destination LUN is a LUN which can be on a different Raid Group, on a different BUS, on a different Enclosure. The reason for a LUN Migration might be an instance where we may want to offload a LUN from a busy Raid Group for performance issues. Or, we want to move a LUN from Fibre Drives to ATA Drives. This we will discuss in the RULES portion.

2. Start the Migration from the Source LUN. From the LUN in Navisphere, we simply right-click and select Migrate. Navisphere gives us a window that displays the current information about the Source LUN, and a selection window of the Destination LUN. Once we select the Destination LUN and click Apply, the migration begins. The migration process is actually a two step process. It is a copy first, then a move. Once the migration begins, it is a block for block copy from the Source LUN (Original Location) to the Destination LUN (New Location). This is important to know because the Source LUN does not have to be offline while this process is running. The host will continue to read and write to the Source LUN, which will write to Cache, then Cache writing out to the disk. Because it is a copy, any new write to the source lun will also write to the destination lun. At any time during this process, you may cancel the Migration if the wrong LUN was selected, or to wait until a later time. A priority level is also available to speed up or slow down the process.

3. Migration Completes. When the migration completes, the Source LUN will then MOVE to it’s new location in the Clariion. Again, there is nothing that needs to be done from the host, as it is still the same LUN as it was to begin with, just in a new space on the Clariion. The host doesn’t even know that the LUN is on a Clariion. It thinks the LUN is a local disk. The Destination LUN ID that you give a LUN when creating, will disappear. To the Clariion, that LUN never existed. The Source LUN will occupy the space of the Destination LUN, taking with it the same LUN ID, SP Ownership, and host connectivity. The only things that may or may not change based on your selection of the Destination might be the Raid type, Raid Group, size of the LUN, or Drive Type. The original space that the Source LUN once occupied is going to show as FREE Space in Navisphere on the Clariion. If you were to look at the Raid Group where the Source LUN used to live, under the Partitions tab, you will see the space the original LUN occupied as a Free. The Source LUN is still in the same Storage Group, assigned to the Host as it was before.
Migration Rules

The rules of a Migration as illustrated above are as follows.
The Destination LUN can be:
1. Equal to in size or larger. You can migrate a LUN to a LUN that is the exact same block count size, or to a LUN that is larger in size, so long as the host has the ability to see the additional space once the migration has completed. Windows would need a rescan, reboot of the disks to see the additional space, then using Diskpart, extend the Volume on the host. A host that doesn’t haven’t the ability to extend a volume, would need a Volume Manager software to grow a filesystem, etc.

2. The same or a different drive type. A destination LUN can be on the same type of drives as the source, or a different type of drive. For instance, you can migrate a LUN from Fibre Drives to ATA Drives when the Source LUN no longer needs the faster type drives. This is a LUN to LUN copy/move, so again, disk types will not stop a migration from happening, although it may slow the process from completing.

3. The same or a different raid type. Again, because it is a LUN to LUN copy, raid types don’t matter. You can move a LUN from Raid 1_0 to Raid 5 and reclaim some of the space on the Raid 1_0 disks. Or find that Raid 1_0 better suits your needs for performance and redundancy than Raid 5.

4. A Regular LUN or MetaLUN. The destination LUN only has to be equal in size, so whether it is a regular LUN on a 5 disk Raid 5 group or a Striped MetaLUN spread across multiple enclosures, buses, raid groups for performance is completely up to you.

However, the Destination LUN cannot be:

1. Smaller in size. There is no way on a Clariion to shrink a LUN to allow a user to reclaim space that is not being used.
2. A SnapView, MirrorView, or SanCopy LUN. Because these LUNs are being used by the Clariion to replicate data for local recoveries, replicate data to another Clariion for Disaster Recovery, or to move the data to/from another storage device, they are not available as a Destination LUN.
3. In a Storage Group. If a LUN is in a Storage Group, it is believed to belong to a Host. Therefore, the Clariion will not let you write over a LUN that potentially belongs to another host.

19 comments:

Justin Bennett said...

Thanks for the info. Much obliged!
Justin

Anonymous said...

hi ..

i work with clariion cx series..
we have to cx´s and it is planed to migrate the files from the one to the another one..2 cx are attached to the SAN through FC-Switch..
I think the best way to do this to create mirror on then after syncronizing fracture and promote the secondary mirror as primary and after this include the new lun in the storage group to grant access to the host..

Any body another idea?????

san guy said...

i would prefer sancopy...faster, cheaper...unless you already have the software licensed for mirrorview on both arrays

Anonymous said...

Extremely useful. Thanks!

Anonymous said...

san guy...does the attached host have to be offline during the migration or can the migration be done hot?

san guy said...

LUN Migration can be done on the fly. You will see a performance hit, which only makes sense...it has to make a copy of the entire LUN in a new location.

Anonymous said...

Great post. Would you be able to comment on how long a LUN migration will normally take? I'm looking to migrate approx. 170 GB. We are using a CX3-20.

Anonymous said...

We just migrated 60 GB, 105 GB, 150 GB, 300 GB, 550 GB, and 750 GB MLUN's and it took 30 minutes for the smaller MLUNs up to 9 hours for the 750 GB. 170 GB using ASAP would be approx 2.5 hours depending on priority and 2 or 4 GB backplane. Our times were using a 2 GB backplane.

Anonymous said...

We just migrated two LUNs on a CX4-240. A 252 GB LUN to a 300 GB Meta LUN, and a 338 GB LUN to a 400 GB Meta LUN, both using the high setting (not ASAP). 252-300 took 27 hrs, 338-400 took 36 hrs.

gak

Admin said...

Is there any way to extend the resultant partition in Linux on-line, as easy as it is in Windows?
I know I can use an utility (like gparted or partition magic) to do it after the migration, but the system must be restarted, run the utility, restart it again; and also my concern is that I never tested it with SAN partitions.

Anonymous said...

can we see the new lun with new space after migration with out rebooting the host in windows.

LAC said...

Does the LUN migration look at the raw capacity of the device? I have two 70 GB LUNS. The User Capacity and User Blocks are exactly the same. The Raw Capacity is not. One raid 5 array has more space than the other hence the raw capacity difference.
Thanks

Anonymous said...

lac, raw space is irrelevant, or else you wouldn't be able to move it between different raid levels.

Anonymous said...

I tried migrate 100GB virtualdisk on AX4-5F. migrate can!t stop, becasuse missing Cancel button. Time remaining was 18hr on start.

Anonymous said...

Nice post

crocodile shoes said...

Thanks for sharing,It help me a lot especially I'm looking info about migration.

Unknown said...

Hi! Thanks for the info! I'm about to migrate a set of LUN´s ona VNX, i saw that information is almost the same. I have my doubts about the that migration will take. Do you have any records in order to compare? We are planning to migrate from SAS disk to NL-SAS and still expecting from customer in order to know how many LUN´s /Space is going to migrate.
Thanks in advance!
Regards from Venezuela.

Anonymous said...

Excellent article, keep up the good post!

taiseer said...


India's finest decorative arts for luxury home furniture and interiors. Our collection is custom created for you by our experts. we have a tendency shoe storage solutionsto bring the world's best to our doorstep. welfurn is leading Interior design company that gives exquisite styles excellence in producing and Quality standards. will give door-step delivery and can complete the installation at your home.