Unsolved
This post is more than 5 years old
2 Intern
•
356 Posts
2
20646
February 21st, 2014 13:00
LUN migration process
Hey,
does anyone have directions for how to migrate LUNs from one Pool to another? Does anyone know if this is a relatively quick process? If not what determines whether its a short process or a long one?
Some insight... We currently have 2 pools that have to be reconfigured. In order for me to do so I will have to move the LUNs from the current Pool (Pool 1) to Pool 0. Destroy Pool 1 and rebuild it to its final configuration. Plus this will free up the disk required for the other RAID groups and Pools I need to create. This was going to be my write up. Please let me know if I have this correct.
- Unmount the LUNs hosted on VNX from the HPC
- Deleted the LUNs that once supported the HPC testing to make room for the migrated LUNs on Pool 1
- Migrate the existing LUNs on Pool 1 to Pool 0
- Confirm LUNs successfully migrated.
- Delete Pool 1
- Create Pool 2
- Populated Pool 2 with the prearranged number and type of disks already pre-determined.
- Migrate the existing LUNs on Pool 0 to their new and permanent home on Pool 2.
- Confirm LUNs successfully migrated.
- At this point we can Create Pool 1
- Populated Pool 1 with the prearranged number and type of disks already pre-determined.
- Expand Pool 0 with the remaining number of predetermined disk.
Pool Layout:
- Pool 0 (Home of the HPC LUNs) (Roughly 30TB before RAID)
- Pool 1 (Home of the VDI infrastructure LUNs) (Roughly 50TB before RAID)
- Pool2 (Existing Brocade Infrastructure LUNs) (Roughly 25TB before RAID)
Now again the question is if anyone has performed a LUN migration how long would these task steps 1 - 7 take if I were able to do it straight through? Could it be performed during the day when systems are using the LUNs? Currently we have LUNs supporting a VMware environment, Symantec SEPM, and Microsoft WSUS database on another. Let me know.
Thank you,
benconrad1
105 Posts
1
February 21st, 2014 14:00
I've done this a lot in the past 12 months:
1. ID all source luns and their size
2. Create new LUNs in the destination pool with similar name (name_tomigrate) and same or larger size (may need 1GB larger)
3. Right click each LUN in Unisphere > Migrate and select the proper destination LUN
It takes a long time even when set to 'High'. For example, a 10TB LUN might take 1-2 days. I've run these migrations during the day (doing some now since last night) and even when auto tiering is running. Auto tiering does throw some errors but it's ok.
I've done this so much that I created a powershell module to help out with it. Or you can setup a series of naviseccli commands (your best bet) to run the commands.
Ben
chjatwork
2 Intern
•
356 Posts
0
February 21st, 2014 19:00
Ben,
Thank you for the response. So I will have to create brand new LUNs on the Pool I plan to migrate the existing LUNs to? And your suggesting that I make these new LUNs about 1GB larger then the current LUN? Only at that point will I be able to migrated the data from the sources LUN to the new LUN? I am not sure why I thought that the disk themselves would just migrate to the new Pool verse the data from the LUNs on the source Pool actually moving off the LUN to a destination LUN on the target Pool. This sounds like it could take some time. We have a 8 to 12TB of LUN space to migrate, but I dont believe we are using all that space on each LUN though.
Do you know if there is a help out there for this process?
Thank you,
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
February 21st, 2014 19:00
yes you will need to create new LUNs, they can be either identical size or larger (if you plan to extend file system after migration). What help do you need with LUN Migrator ?
chjatwork
2 Intern
•
356 Posts
0
February 21st, 2014 20:00
I just need to make sure I have the right steps. Click by click steps. I think I have found a video that gives some insight. Let me know if this looks right? http://youtu.be/3vXaEouOl_c
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
February 21st, 2014 20:00
looks good, if you are concerned of the impact to production, you can change priority up and down. You could crank it up at night when it's relatively quite and then turn it back down in the morning.
chjatwork
2 Intern
•
356 Posts
0
February 24th, 2014 08:00
Hey,
sorry to add another level of complication to this question. I got a rough estimate on how long it would take a 10TB LUN to migrate... but that's just one LUN. How would I factor a Multiple LUN migration at the same time? i.e. can I kick off 12 simultaneous migration at the same time all LUNs totaling 12TB (not all used space, just mainly all thick allocated). Can I migrated that many LUNs at the same time? I gather it would take a significant performance hit to the VNX?
Thank you,
gvaidman
20 Posts
0
February 24th, 2014 11:00
Depends on your array model. The VNX5100 can do 8 simultaneous migrations (and queue 248), VNX5300 and up can do 16-24 simultaneous and queue up 488-1000 more, depending on model. You could initiate them all no matter which array you have, it's just that on the 5100, the 9th migration wouldn't start until one of the first 8 completed, etc.
Regarding thick/thin allocation/utilization (from the Unisphere help for LUN Migration): "The migration operation detects the zeros on the source LUN and deallocates them on the target LUN which frees up more storage capacity on the target LUN. For better performance and improved use of space, make sure that the target LUN is a newly created LUN with no existing data."
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
February 24th, 2014 13:00
thanks, so it still requires host work just like described here (using native Windows tools), minus doing LUN Migration.
https://www.emc.com/collateral/white-papers/h12204-vp-for-new-vnx-series-wp.pdf
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
February 24th, 2014 13:00
you don't have to do any "pre-work" in the OS itself to release those empty block prior to using LUN Migration ?
gvaidman
20 Posts
0
February 24th, 2014 13:00
The documentation says "zeroes" specifically, not empty. If it's a freshly populated filesystem, then they're the same. Otherwise, you might want to look at a tool like SDelete with the "-z" option (for Windows OS).
chjatwork
2 Intern
•
356 Posts
0
February 25th, 2014 06:00
Vaidman,
We have the VNX5500
chjatwork
2 Intern
•
356 Posts
0
February 25th, 2014 07:00
The system the Pool0 is currently connected to is a HPC (Linux RedHat) which we carved out 2 LUNs from Pool0 for. So your both saying that we will have to have GPFS write zeros to both LUNs first? Then unmount both LUNs (As usual). I will be deleting these 2 LUNs on Pool0 before recreating new ones that will be used for the LUN migration of the LUNs from Pool1. This should be fine right?
Thank you,
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
February 25th, 2014 11:00
i am not familiar with GPFS to tell you exactly what process to use to write zero's to un-used data. But as far as your LUN Migration question is concerned, you don't need to unmount source LUN during LUN Migration ..it's an online process. Create new LUNs and perform LUN MIgration, upon completion source LUNs get deleted while new LUNs take on source LUN identity (LUN number)
chjatwork
2 Intern
•
356 Posts
0
February 26th, 2014 05:00
Dynamox,
Ok I think I may have lost you. I get it you don't have to move data from your LUNs in order to migrate them, but you do have to have available space on the SAN in order to migrate a LUN, right? Currently there is no available space on the SAN, so we have to blow away the LUNs supporting the HPC for now to support the migration. Granted we have not started using the HPC yet so to delete the LUNs in support of reconfiguring the disk on in Pool1 is no big deal, because we will need the disk that is in Pool1 to support the new HPC RAID Groups.
With that said I am going to unmount and delete the LUNs on in Pool0 that currently support the HPC (Which we are not currently using in production yet), so that I am able to create new LUNs in support of migrating the productions LUNs we have in Pool1 to Pool0. After that this will give me the ability to delete Pool1 and do what I need to do with the disk it once had.
After configuring the new Pool2 and RAID groups from the disk once used in Pool1 I should then be able to migrate the LUNs that where migrated to Pool0 to the new Pool2. Then recreate the supportive disk for the HPC using the new RAID groups, which is recommend.
Makes since?
dynamox
11 Legend
•
20.4K Posts
•
87.4K Points
0
February 26th, 2014 07:00
make sense, is there a performance reason to go with traditional RAID groups for LUNs that will be used for HPC. Is it because you want to use FAST Cache for pool LUNs and want to disable it for traditional LUNs ? (As you probably know you can't disable FAST Cache on pool LUNs, you have to disable it for the entire pool).