I think you mean that your RLP and source luns are in the same raid group and not storage group. RLP are private lun's so you wouldnt be able to add them to a storage group.
To move the source luns out of that raid group, you can do a lun migration. create a new lun of same size (make sure it is block size identical) and then just right click the source lun and select migrate. select the new lun and there you go. This is all don on the array and has no effect on the host. depending on the speed you run the migration at, you could have some array performance hits. So start it at High and see how it looks. if your goign to do this during low I/O hours, then run it at ASAP.
I think what I will do is setup my mirrored LUNS just like I would any other Mirrored LUN, and then target migrate to it. I'm actually setting up a test run first.
Great information. I have built two test mirrored LUNS. They are synchorized already as I made them small. I'm going to stumble though some tests with these LUNS while enjoying that I wont down our entire organizaiton because they are test.
So I do need to setup the mirror first prior to trying to migrate to it right?
I created two mirrored test LUNS in the same RAID group. (Wanted to test twice). Then I made a LUN of equal size in another RAID group. I then simply right clicked on one of the mirrored LUNS and chose "migrate" and pointed it to the LUN in the other RAID group. It did it with no problems. Then I went to the secondary site and did the same thing with the respective secondary LUN and it moved over. No need to do a admin fracture. Looks good!!
You can migrate a data LUN that is being mirrored (or is the destination of a Mirror). You just create new LUN in the new location that is the same size or bigger, then initiate a LUN Migration against the mirrored LUN. Mirrorview will automatically follow the LUN as it is migrated. You cannot increase the size of the mirrored LUN though so if you migrate into a larger LUN you will find the “user” capacity is the same as the original LUN and you can’t increase it. To expand a LUN you’d need to remove it from the mirror first.
You cannot migrate a LUN that is part of a Reserve LUN Pool. If you want to move the Reserve LUN Pool LUNs, you would need to create new RLP LUNs, remove the old LUNs from the Pool and add the new LUNs into the pool. The challenge here is that you can’t have any snapshots active while you remove the LUNs and add new since active snaps track data in the RLP LUNs. Mirrorview/A also uses snaps. You’d have to at least Admin Fracture the mirrors and destroy any Snap Sessions to do this.
That is what I would expect to happen. LUN Migration is very non-disruptive. It can impact performance if the LUN is busy and the migration priority is high, but you can adjust priority as needed.
kenn2347
3 Apprentice
•
542 Posts
0
February 4th, 2011 13:00
I think you mean that your RLP and source luns are in the same raid group and not storage group. RLP are private lun's so you wouldnt be able to add them to a storage group.
To move the source luns out of that raid group, you can do a lun migration. create a new lun of same size (make sure it is block size identical) and then just right click the source lun and select migrate. select the new lun and there you go. This is all don on the array and has no effect on the host. depending on the speed you run the migration at, you could have some array performance hits. So start it at High and see how it looks. if your goign to do this during low I/O hours, then run it at ASAP.
STAI
1 Rookie
•
81 Posts
0
February 4th, 2011 14:00
What if the LUNS are being mirrored? (MirrorView).
kenn2347
3 Apprentice
•
542 Posts
1
February 4th, 2011 14:00
I would say that since you are migrating to a lun of the same block size it should not matter. Mirrorview lun's need to be block identical.
Been a while since i messed with Mirrorview but i think you wont have to do anything with the secondary images. maybe someone from EMC will confirm
STAI
1 Rookie
•
81 Posts
0
February 4th, 2011 14:00
thanks Ken,
I think what I will do is setup my mirrored LUNS just like I would any other Mirrored LUN, and then target migrate to it. I'm actually setting up a test run first.
thanks.
STAI
1 Rookie
•
81 Posts
0
February 4th, 2011 15:00
Thank you Richard,
Great information. I have built two test mirrored LUNS. They are synchorized already as I made them small. I'm going to stumble though some tests with these LUNS while enjoying that I wont down our entire organizaiton because they are test.
So I do need to setup the mirror first prior to trying to migrate to it right?
STAI
1 Rookie
•
81 Posts
0
February 4th, 2011 15:00
SUCCESS !!!
I think I was anyways. Here is what I did.
I created two mirrored test LUNS in the same RAID group. (Wanted to test twice). Then I made a LUN of equal size in another RAID group. I then simply right clicked on one of the mirrored LUNS and chose "migrate" and pointed it to the LUN in the other RAID group. It did it with no problems. Then I went to the secondary site and did the same thing with the respective secondary LUN and it moved over. No need to do a admin fracture. Looks good!!
What does anyone think? Does this make sense?
Storagesavvy
474 Posts
1
February 4th, 2011 15:00
You can migrate a data LUN that is being mirrored (or is the destination of a Mirror). You just create new LUN in the new location that is the same size or bigger, then initiate a LUN Migration against the mirrored LUN. Mirrorview will automatically follow the LUN as it is migrated. You cannot increase the size of the mirrored LUN though so if you migrate into a larger LUN you will find the “user” capacity is the same as the original LUN and you can’t increase it. To expand a LUN you’d need to remove it from the mirror first.
You cannot migrate a LUN that is part of a Reserve LUN Pool. If you want to move the Reserve LUN Pool LUNs, you would need to create new RLP LUNs, remove the old LUNs from the Pool and add the new LUNs into the pool. The challenge here is that you can’t have any snapshots active while you remove the LUNs and add new since active snaps track data in the RLP LUNs. Mirrorview/A also uses snaps. You’d have to at least Admin Fracture the mirrors and destroy any Snap Sessions to do this.
Richard Anderson
Storagesavvy
474 Posts
0
February 4th, 2011 15:00
That is what I would expect to happen. LUN Migration is very non-disruptive. It can impact performance if the LUN is busy and the migration priority is high, but you can adjust priority as needed.