[HPADM] SUMMARY EMC SAN move (update)
From: Thomas Northup (thomaslnorthup_at_yahoo.com)
Date: 08/06/05
- Previous message: Marc Thoelen: "[HPADM] console issues for Itanium-servers ?"
- In reply to: Justin Willoughby: "[HPADM] Re: EMC SAN move (update) [opps]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 6 Aug 2005 05:04:10 -0700 (PDT) To: hpux-admin@dutchworks.nl
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)
- Previous message: Marc Thoelen: "[HPADM] console issues for Itanium-servers ?"
- In reply to: Justin Willoughby: "[HPADM] Re: EMC SAN move (update) [opps]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
