PrakashCSC
2 Bronze

Data Migration from VMAX to Xtreme IO

Jump to solution

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.

0 Kudos
1 Solution

Accepted Solutions
echolaughmk
3 Zinc

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

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 <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 <diskgroup> drop disk <asm_diskname>). 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

0 Kudos
10 Replies
Highlighted
Avi3
3 Zinc

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

Open replicator is fully supported for the data push from VMAX to XtremIO. Is that what you are asking?

echolaughmk
3 Zinc

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

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
2 Bronze

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

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.

0 Kudos
PrakashCSC
2 Bronze

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

Hi echolaughmk,

Thank you for listing out those methods, I am looking for a solution that is tested on VMAX to XtremeIO.

0 Kudos
echolaughmk
3 Zinc

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

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?

0 Kudos
PrakashCSC
2 Bronze

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

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.

0 Kudos
Avi3
3 Zinc

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

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
2 Bronze

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

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.

0 Kudos
echolaughmk
3 Zinc

Re: Data Migration from VMAX to Xtreme IO

Jump to solution

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 <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 <diskgroup> drop disk <asm_diskname>). 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

0 Kudos