This post is more than 5 years old
35 Posts
0
4233
Data Migration from VMAX to Xtreme IO
Hello Folks,
I am looking for a solution to migrate data from VMAX to Xtreme IO,
I am planning to migrate my oracle workloads from VMAX to XtremeIO. Request to share your experience on data migration solutions for this particular hardware.
Appreciate your help folks.
echolaughmk
522 Posts
0
June 19th, 2015 04:00
Hi,
You can go to larger LUNs with ASM rebalancing and you will ideally want multiple LUNs in the ASM diskgroup to begin with due to either the coarse or fine granularity set at the ASM level. If you just have a single LUN, you won't get any of that striping. As Avi said, it is not uncommon for people to increase their LUN size/LUN layout when going to an XtremIO. If you are choosing ASM as the method of migration, then your process would have you just add these new XtremIO LUNs to your existing diskgroup (alter diskgroup add disk '/dev/xxx') and then watch the data as it is rebalanced across the new LUNs:
SQL> select GROUP_NUMBER, OPERATION, STATE, POWER, ACTUAL, SOFAR, EST_RATE, EST_MINUTES, EST_WORK, ERROR_CODE from v$asm_operation;
GROUP_NUMBER OPERA STAT POWER ACTUAL SOFAR EST_RATE EST_MINUTES EST_WORK
------------ ----- ---- ---------- ---------- ---------- ---------- ----------- ---------
2 REBAL RUN 1 1 196 1450 0 689
Where SOFAR is how many Allocation Units have been moved
EST_WORK is the number of Allocation Units left for movement
EST_RATE is the number of Allocation Units/Miniute that are being moved.
This will take a while depending on how much data you have and how many LUNs you are working with since it is a host/DB-based migration method. Once it is all rebalanced, you can then drop the original source volumes (alter diskgroup drop disk ). This will kick off another rebalance at this point to move all the of the extents from the disks you are dropping to the rest in the diskgroup. I would suggest doing this one disk at a time. There are a bunch of other parameters you can tweak during an ASM rebalancing and as you can see it could take much longer than a one-time SAN or LVM migration, but should give you the desired outcome you seek.
Here is an overview that might help: Administering ASM Disk Groups
I would also suggest talking over the game plan with your DBA as they might have some experience or tweaks they can assist with (I'm not a DBA....I just play one on TV and have tested this in labs
)
HTH,
-K
Kumar_A
727 Posts
1
June 17th, 2015 15:00
Open replicator is fully supported for the data push from VMAX to XtremIO. Is that what you are asking?
PrakashCSC
35 Posts
0
June 17th, 2015 16:00
Hi echolaughmk,
Thank you for listing out those methods, I am looking for a solution that is tested on VMAX to XtremeIO.
echolaughmk
522 Posts
2
June 17th, 2015 16:00
Some migration methods to consider:
1. Open Replicator as Avi mentioned - array based
2. PPME - host based
3. Native LVM - host based and most flexible in some cases
4. ASM rebalancing - host based and done at the DB level.
5. Open Migrator for Windows - host based
Those would be the top choices if this is a physical environment. They all have their pros/cons, but pretty exhaustive to list here. I have utilized all of them with great results in previous migrations between VMAX and other arrays (not XtremIO in all cases).
Not sure if that is what you are looking for or not, but reply back if you have any questions.
-K
PrakashCSC
35 Posts
0
June 17th, 2015 16:00
I am looking for a best solution to migrate data from VMAX to XtremeIO.
VMAX hosts Oracle workload. We are planning to move Oracle workload first.
echolaughmk
522 Posts
0
June 17th, 2015 16:00
Hi,
The best solution might be a relative term depending on what you need to accomplish. If you are keeping the target LUNs all the same, Open Replicator or PPME works great since they are LUN based.
If you need flexibility to re-layout VG's or logical volumes/drives given that you are chaning your LUN layout due to the extreme performance of the XtremIO array regardless of LUN size, then native LVM or Open Migrator for Windows might be the way to go since you can change these sizes/layouts with these methods.
Finally, if you need the flexibility of all of the above and want the DBA's to control the migraition, you could simply use ASM rebalancing (this will likely take longer as a background task).
All solutions work great and are proven, the decision really comes down to host-based versus array-based and how fast/comfortable you want to get with the migrations. Some require software installs, some are natively built-in. Some requi SAN work, others just present new LUNs.
That was a long way of saying it depends
. For oracle workloads, all of the methods are supported and will work. Is your target layout on XtremIO changing? If so, how is it designed?
PrakashCSC
35 Posts
0
June 18th, 2015 16:00
Hi echolaughmk,
Xtreme IO layout would be different as we have to get extreme performance. Single volume size should be 3TB. Current single ASM lun size 80GB on VMAX.
PrakashCSC
35 Posts
0
June 18th, 2015 20:00
Hi Avi,
As you pointed about host queuing, I would be reducing the number of luns on Xtreme IO.
Each luns would be around 3TB of size in Xtreme IO, but now only problem would be data migration between different size luns.
VMAX ( lesser size luns) and Xtreme IO ( larger size luns )
My only concern is this.
Kumar_A
727 Posts
1
June 18th, 2015 20:00
Hi Prakash,
Keep in mind that the number of LUNs can be drastically reduced in XtremIO because we dont need a large number of LUNs for performance reasons. We have customers who have reduced the number of LUNs (to help from a management perspective) when they start using XtremIO. You would still need to use a small number of LUNs to help from a host queueing perspective.
PrakashCSC
35 Posts
0
June 22nd, 2015 11:00
Thank you echolaughmk, I would talk to my DBA and figure out a way to do that.