Moving RAID storage subsystem from HP K box --> L class server

[Victor Balenton]

We are planning to replace HP K Class server with L class. We have SCSI based RAID storage subsystem which we want to connect to new server.The Storage subsystem has Oracle database and the vol.groups,log.vols,file systems are configured only for this application,and nothing for HPUX OS.The HP K server is on 10.20 version while the L class server will have 11.0 operating system.I was looking out for the best option to migrate the storage subsystem to new server with minimum downtime and activity.
I can think of two options :
a)Deleting all existing information on the RAID box, connecting to new HP server and recreating from scratch. This will require more time and also lot of activities.

b)Do vgexport and then vgimport on new server.I am not sure will this bring all information specifically the existing filesystems (on HPUX 10.20 system )can be mounted on HPUX 11.0 system ?. If it is then I guess this will require less time and activity.

Also on the hardware interface part do I need to convert the RAID storage box to PCI interface since the L class servers supports this ?
Thanks much in advance for suggestions or inputs in this regard.

[Patrick Wallek]

Doing the vgexport will be your best bet and it will be easy too.

You will want to do a vgexport -m mapfilename -v -s -p vg##

You can then move the disk array from your K box to your L box, assuming you have the appropriate SCSI adapter on your L box. You should not need to do anything to the array. If the array is FWD SCSI then you will need an adapter that supports that on your L box.

Once the array is hooked up, copy the mapfilename file from your K to your L box and then run vgimport (vgimport -m mapfilename -s -v vg##.

Contrary to what the man pages for vgimport/vgexport say, you do not need the -p option when you use the -s option. Use of the -s option writes the VGID # to the map file on vgexport. On vgimport the -s option looks at the VGID # in the mapfile and imports all devices that have that particular VGID# on them. This eliminates you having to specify each specific device file in the vgimport. I have used this numerous times and it works like a charm.

After you do the vgimport, you will need to make the appropriate entries in your /etc/fstab file and you will then be ready to mount your data from the RAID array.

[Bill McNAMARA_1]

Just to add to Patricks comments,
which are perfect, you will also have
to recreate the special files for the vg
in /dev that are not done automatically
by the vgimport.
ie:

ll /dev/*/group
choose a unique 0x0Y0000 (major number Y)
mkdir /dev/vgname
mknod /dev/vgname/group c 64 0x050000
where 5 is an example unique vg identifier

and then vgimport vgname -m map ....

Ifyou don't export with the mapfile option you
will a. loose all lvol names and
b. have to specify device files for the
disk/luns to import. You will find these
from the new devices seen on the L
from ioscan.

Note. since it's SCSI don't forget to
power off the L and the SC10 before reconnection.
Then reboot the SC10, wait for it to power up
and then power on the host. The device files
will be created during the ioinit as
part of the bootup process.

Later,
Bill

[Patrick Wallek]

Very good point about (re)creating the /dev/vg?/group file Bill. For some reason that step always slips my mind, but I get reminded of it very quickly when I try to do an import and it doesn't work the first time.

[Dave Wherry]

I'll add my assurances and just one more thing to Patrick and Bill's comments.

I too have done it and it works great.
Had a K running 10.20, disks on an XP256. Followed the export steps and shutdown the K. Then did the import steps on my V2500 and in maybe less than 10 minutes had my 150GB Oracle database up and running.
One gotcha to watch for. Sorry I can't be very specific, this was about a year ago. In my mapfiles, the first line which is the VGID was causing me some problems. The vgimport kept failing. We removed the first line from the mapfile and the vgimport worked. Maybe it had something to do with going from a 10.20 box to an 11.0 box. I do it periodically from two 11.0 boxes and have no trouble.

So I too suggest the vgexport/vgimport method. Unless there is any LVM rework you want to do. See if you want to resize any logical volumes or change volume group parameters. Parameters like MAX PE per PV" can not be changed after the volume group is created. Think ahead if this might be a problem for you in the future. It might be better to fix it now before your database grows and it becomes a longer task later.

[Victor Balenton]

Thanks guys for your valuable suggestions,since I am planning to do this in coming month so I cannot comment now on the outcome of this job.
I appreciate and it helped me to decide the procedure of doing this.