I have to get everything off an old EMC 3430 and a Clariion 4500 and get it all onto an EMC 8530.
My 'challenges':
All but one vg was created with a PE size of 4Mb. The new EMC 8530 is coming in with 8Mb PE. To add insult to injury - the only vg created with an 8Mb has the default Max PV at 16, so I can't add the new disks and just do a mirror/sync and then split off the old disks.
<Why is it the person who sets up these boxes up is never there when they must be migrated..?>
One host has it's 2 fiber connections going 1 to the old EMC array and one to the Clariion array. The other hosts are dual fibered to the old EMC array.
My Thoughts...
BACKUP BACKUP first !
Create fresh vgexport mapfiles (use -s option) for old volume groups since I will have to move fiber cables around on that one host.
Remove 1 fiber cable from host to old array and use this for single fiber connection to new array.
Create new vg for everything, thus setting the 8Mb PE and Max PV.
Then mount the new vg to dummy mount points; copy all the data from the old volume group (can't tar or cpio cause many files over 2gb) to new vg.
Then once everything looks solid on the new vg, umount everything and remount the new vg to the correct mount points.
Make new mapfiles..
Lastly vgexport the old vg and cleanup disks on old array.
Remove 2nd fiber connection from old array and add the 2nd fiber from new array..
Cleanup loose ends....
Rita
Note: If you are the author of this question and wish to assign points to any of the answers, please login first.For more information on assigning points ,click
here
Does loose ends include setting up alternate pathing?
ie. Extend all disks in VG to include alternate paths,
export the Primary path for every second disk, then re-extend the Disk back into the VG?
Thought - if your machine is SAN connected, why not leave the old Disks idle and simply restore the pre-implementation Backup to the new Disks? With the tapes streaming it should not take long.
As usual, you have thought this out well. I agree with your plan. (Too bad the person who first implemented the volume group didn't plan for the future).
For moving your data, I'd use 'fbackup/frecover' since it supports largefiles, 'uid' values greater than 65K, *and* it will handle sparse files. I suggest:
Unfortunately I don't see many ways out of this. I think you got the right idea. The only thing I'm wondering is how much downtime are you going to take for that?
The only other solution I could propose to you, but then again that would mean more hardware, is to have another server setup to be able to do your copy there.
So basically if you have BCVs on both EMC, you have both BCVs seen by this server, you do your copies there, and when you are ready, you vgexport all your VG, create your new ones and sync from those BCVs.
It looks like a great plan. The only thing I can think of is that you might have to do a vgreduce on your disks to the old array that use the fibre connection that you are going to plug into the new array. Since you'll be picking up new disk devices on that controller it might confuse things if the old disk devices for the old array are still out there.
Verify that you don't have any sparse files or you may unexpectedly use up more space when you do your copy. fbackup can handle the sparse files with the "frecover -s" option.
Ian -Yes alternate path will be done..but as for SAN. Yes (sort of) the 8530 is 1 of 2 arrays. Unfortunately 'mgmt' made decision to put DR site through a switch, but here just to fiber to host. arghgh!
My apps are Oracle - Share away with any tips on what you mentioned. I'm no DBA ! How much data...about a terbyte. Most on 1-2 instances, rest on several small db's.
Pete - Your more than welcome to come play and clean this mess up..ha ha. pvmove-been there, then I figured add disk and mirror, then drop old disk and remove from vg. But only vg I could do that w/had the MaxPV of 16...brickwall again!
JRF - Thanks, I'll print and keep your suggestion !!
Marco - Downtime is always an issue here..I'm going to have to do this a db at a time ( there's goes any life outside here )& earplugs in so I don't hear the complaints.
John - that is why I have to vgexport with the -s option, so the mapfiles will have the vgid. Since on 1 box I must drop & flip cables back and forth to get things off the Clariion and then off the old array. Thus the security of my mapfiles if I must vgimport when I unplug/replug cables.
Martin - yep...you and Jim agree. Looks like it's in the plan.
If you were some place sunny and warm like Florida or Arizona, I'd be there in a flash. However, I think you're probably as much in the deep freeze as we've been up here in the "Green" Mountains (that seem to be awful damn white lately).
Let me explain the point I was trying to make. Let's say you have an existing VG with two disks and two PV links [two fibre connections to your old array]. The disks look like this:
c6t0d0
c8t0d0 PV link
c8t0d1
c6t0d1 PV link
Now, if you unhook the fibre cable for the HBA that gives you the c8 drives, your PV links will take care of you and you'll run everything to the c6 drives. Cool. But now, you plug in that fibre cable to the new array. What PVs will the box see now? More c8 disks? But those will be the PVs on the new array. Plus, your existing VG will know about the old c8 disk devices and expect them to have the LVM info about the existing VG. Oops. I understand all about why you are doing the 'vgexport -s', but I don't think it will save you. That's why I suggested doing the 'vgreduce' to get rid of the c8 PVs so that your existing VG will be happy. Plus, if the PVs on the new array come in as c8 disks, will you have to do an 'rmsf' on the old c8 device files before plugging the cable into the new array, and then do an 'ioscan' and 'insf' to pick up the new PVs?
I'm not trying to be a pain [well, not too much anyway], but I've been through things like this before and learned it the hard way. :)
Printable version
