From: Thomas Northup (thomaslnorthup@yahoo.com)
Date: Sat Aug 06 2005 - 08:04:10 EDT
Here was my original question:
We have some HP-UX 11i systems on our EMC CX600 SAN and we are going to move them to a new SAN, which is an EMC CX700.
Can you tell me what steps I need to do and in what order so when the WorldWideNames change which will cause the device names (cXtXdX) to change I will be ready.
A lot of people wondered why I was not concerned with the data on the SAN so I up data my post with this:
Sorry... I guess I left out the part where EMC will be doing the SAN copy and the other necessary step on the SAN. The HP-UX box goes down and then comes back up on the new SAN with different disk presented to it but the data is there.
I will try doing all the steeps from the post that starts off "We did the following:"
Plus make some backup copies as suggested in other post.
Thanks to everyone who responded!!!
Here were the responses:
If you have HP MirrorUX and both EMC boxes are on the same SAN I would
assign the new disks and mirror to those disks and then break mirror,
or
use pvmove (don't need MirrorUX for this), does about the same thing.
You end up moving each LV this way, I did it moving between two SAN
Storage devices a while back.
--- We did the following: edited fstab for affected filesystems - committed them out unmounted filesystems affected vgchange -a n vgname (for each vg) vgexport -s -v -m vgname.map vgname (for each vg) (this made a file that will import without knowing the new names) shutdown and let the SAN change reboot after SAN change check that all volumes are back mkdev /dev/vgname (for each vg) cd /dev/vgname (for each vg) mknod group c 64 0xYY0000 (for each vg) (were YY is 01 for first group and 02 for second - etc) vgimport -s -v -m vgname.map vgname (for each vg) vgchange -a y vgname (for each vg) edit fstab to put back file systems mount -a And you are done. Some other things we did just incase we needed them. vgdisplay -v bdf inq ioscan -fnCdisk We printed the output in case there was a problem. We did not have any except it took a couple of boots to allow the SAN group to get the zoning right. ---- There is an unsupported HP utility ioconfig_dump which you can probably get from the response center. This utility will dump the ioconfig file into an ascii file such that you can edit the instance numbers of the new FC's and load it back to the ioconfig – it will require one reboot in maintenance mode. This can save the whole export import as you will be able to keep the same device files – providing the scsi ids will remain the same --- We have done this a number of times. The way we like to do it is to have the new disk presented to the sever before EMC performs the SAN copy. We create new volume groups using the new disk that duplicate the existing volume groups using some naming variation (e.g.: existing volume group = vg02, new volume group = vg02n) and new minor numbers. Once this is done, we create import scripts for the new volume groups (we have a script that will do this for us automatically). Next we export the new volume groups and let EMC start the SAN copy. While the copy is going on, we edit the import scripts we created above and change the volume groups names to their "real" names and minor numbers to match what is currently being used. At the time of cut over, we quiesce everything, export the existing volume groups then use the import scripts to import the new volume groups (which will now have the same name and minor number as the old volume groups). Assuming everything went correctly with the SAN copy, we are back up in running in a very short amount of time. Note - We typically create import scripts of the existing volume groups as well so we can re-import them in case something goes wrong with the SAN copy. --- In that case you can just do a vgexport with -m to create a map file and then vgimport with the -m option once the disks are moved. It won't matter that the names of the disks are not the same. vgimport will look at the header of the disks. --- I have had problems with old Clariions that they can not do low level search of disk on an HP box. May not apply to you. Be sure to have full vgdisplay outputs of all your VG's ON PAPER Be sure to have a ioscan of the disks. ON PAPER create a file per fs with the name of the fs, If really confused it may help. example touch /opt/MYNAME.opt I think the vgexport/import relies on none usually accessable information on the disk, I owuldn't trust it too much due to the copy. Ask EMC if the copy is a 'dd' like of the rdsk or the dsk, if dsk only, it may not be good enough. Oh yes, record a map of all the disks on the clariion before disconnecting it. You may be able to get that via navcli, depends on the level of software/hardware. Thomas Northup thomaslnorthup@yahoo.com --------------------------------- Start your day with Yahoo! - make it your home page -- ---> Please post QUESTIONS and SUMMARIES only!! <--- To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl Name: hpux-admin@dutchworks.nl Owner: owner-hpux-admin@dutchworks.nl Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse only) http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse & search)
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:49 EDT