Unsolved
This post is more than 5 years old
15 Posts
0
1661
May 15th, 2015 12:00
Device size / Geometry on 3par storage to match VMAX3 luns
Hi,
Can someone let me know the disk geometry difference between EMC devices and 3PAR devices.
We will be having migration from 3PAR array to VMAX3 array using VPLEX.
I will be creating target luns on VMAX3 array which should be matching to source luns which
are on 3PAR (T800) array.
My question - How to create matching lun size on vmax3 as per matching source luns which are on 3par- VT800 array.
Is there any specific criteria to create same size luns on VMAX3 same as 3PAR luns.
Thanks.
No Events found!
Nirvik
15 Posts
0
May 26th, 2015 07:00
Still waiting for expert comments.. anyone ?
Nirvik
15 Posts
0
May 26th, 2015 09:00
Yes. We are planning to encapsulate both arrays behind VPLEX and do a data mobility.
Most of the hosts are Windows hosts and will be doing data mobility. Not the host based migration.
Thank you so much for your valuable points and suggestion. It really helps.
echolaughmk
2 Intern
•
522 Posts
0
May 26th, 2015 09:00
Are you planning to encapsulate the both arrays behind VPLEX and then do a data mobility job for the migration?
VMAX3 LUNs are based on cylinders, with 1 cylinder equaling 1920K. If you utilize "blocks" to create your LUNs on the 3PAR, then you can see if their current sizes fit into what you can create within VMAX3 by ensuring they are divisible by 3840 blocks. For example, if you have a 10GB LUN on the 3PAR in blocks, it would be 10,737,418,240 bytes or 20971520 blocks. But in a VMAX3 a 10GB LUN cannot be made of that same exact size ( 10485760K /1920K = 5461.3 cylinders) and you can't make a device with fractional cylinders. So if the devices match when you do that comparison, then you can use the native array LUNs based on cylinder size.
For the situations where they won't match, you will need to create VMAX3 LUNs slightly larger in their native cylinder sizes and then perform the same time of computation for creating extents manually in VPLEX that will ensure an exact match during the data mobility job (you can also migrate to a larger device and just ignore the unused space if desired). For example, if you have a 10GB LUN in 3PAR comprised in 512-byte blocks, it would be 10,737,418,240 bytes or 20971520 blocks. If you created a slightly larger VMAX3 target device, then you could go ahead and create an extent on that storage volume in bytes:
extent create -d VMAX3_LUN -s 10737418240
You could get this from the GUI on the 3PAR LUN as well, but I think that is in a 4K blocksize so you would have just do the math to convert to bytes if you chose to do it that way.
With all of that being said, I would suggest a host-based migration where only the VMAX3 is presented through the VPLEX to the host with the native 3PAR LUNs on it already. This will give you the added flexibility listed here:
1. This will remove the need for all the conversion above
2. This will allow you to change the layout/size of your target LUNs if desired
3. This will allow you to perform the migration online in many cases (LVM and other utilities per OS are often online)
4. This will save you the hassle of having to cleanup all 3PAR storage volumes claimed just to enable the migration
5. This could save some time/overhead on masking/zoning within the array element managers
Typically in a situation like yours involving a Symmetrix target, I opt for migrating with a host-based method for the benefits described above with my customers.
HTH,
-K