[HPADM] SUMMARY: Easing Impact of SAN Changes to HW/Device Paths

• Previous message: Ben Le: "[HPADM] [SUMMARY] Software Maintenance - Micro Focus Cobol on HP-UX 11.11"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: hpux-admin@dutchworks.nl
Date: Mon, 25 Jul 2005 09:45:59 -0400

My original post is at the very bottom.

I received several replies. Thanks go to:

* Mike Whitton
* Shyam Hazari
* M. Fearer
* Gary Paveza
* Stuart Abramson

I had already mostly written scripts to handle my vgexports and vgimports,
but they weren't working for a simple reason: I wasn't using the "-s"
option with vgexport, so my map files weren't recording VGID's. Once I
realized this, I added it, and my scripts now seem to work fine. I have
attached the following scripts:

* vgsnapshot (creates map files and can export VG's, including unmounting
filesystems and doing other things)
* vgrecover (uses map files to import VG's)
* load_balance (balances the load across controllers when the load has all
been shoved to one controller)

These are lengthy, detailed scripts. Use a "-h" option for information
about vgsnapshot and vgrecover, which doesn't execute anything but the help
feature. To learn more about load_balance, execute the script, and then ^c
after the information page appears.

I've written these scripts in a fashion where they should work pretty much
in any HP-UX/SAN environment without any changes to them. However, these
scripts are provided without any promises that they will be flawless in your
environment, so exercise caution.

The scripts are very LONG. This is so they can be pretty much a no-brainer
for junior SA's to use.

I'm also including a couple scripts that Mike Whitton and M. Fearer
graciously sent to me.

Following are the responses I received, in the order I received them:

==========
From : Mike Whitton <mike@eng.wayne.edu>
Sent : Wednesday, July 20, 2005 2:46 PM
To : "Dave T." <davidlt77@hotmail.com>
Subject : Re: [HPADM] Easing Impact of SAN Changes to HW/Device Paths

Go to previous message | Go to next message | Delete | Inbox
Attachment : disk.pl (< 0.01 MB)

I wrote the attached script. After you attach and zone the new switch and
reboot the server you can look up what the old disk controllers were in the
LVMTAB and then enter them into this script. Once run, it will recreate all
of the old disk ctd numbers with the new info. Make sure to manually delete
the old ctd numbers prior to running...

mike

#!/opt/perl/bin/perl
#
#
#
#

open(LS, "ls -al /dev/dsk/c21*|");

# brokenpath is the new path after the controller has changed
$brokenpath = "c21t";
# use oldpath with the prior disks name in vgdisplay
$oldpath = "c17t";

while(<LS>)
        {
        #print $_ . "\n";
        @lsvalue = split;
        print $lsvalue[5] . " " . $lsvalue[9] . "\n";
        $lsvalue[9] =~ s/$brokenpath/$oldpath/;
        print $lsvalue[9] . "\n";
        print "mknod $lsvalue[9] b 31 $lsvalue[5]\n";
        system("mknod $lsvalue[9] b 31 $lsvalue[5]");
        }

==========

From : Shyam Hazari <shazari@gmail.com>
Reply-To : Shyam Hazari <shazari@gmail.com>
Sent : Wednesday, July 20, 2005 2:59 PM
To : "Dave T." <davidlt77@hotmail.com>
Subject : Re: [HPADM] Easing Impact of SAN Changes to HW/Device Paths

Go to previous message | Go to next message | Delete | Inbox

If you move a server from one switch another, it would definitely
change the devices. If that happenes, I would just rebuild the
/etc/lvmtab using vgscan.

cp /etc/lvmtab /etc/lvmtab.old
mv /etc/lvmtab /etc/lvmtab.orig

vgscan( becareful with vgscan)

Mount the filesystems

-Shyam

==========

From : <mfearer@cox.net>
Sent : Wednesday, July 20, 2005 2:59 PM
To : "Dave T." <davidlt77@hotmail.com>
Subject : Re: [HPADM] Easing Impact of SAN Changes to HW/Device Paths

Go to previous message | Go to next message | Delete | Inbox

Dave,

Here is something that we use in our environment. With a little tweaking,
perhaps you could use these:

[root@zerg: action]# cat vgexport_zerg.ksh | more
#!/usr/bin/sh
#
# terran:/var/adm/move/terran/action/vgexport_.ksh
#
# vgexport the local VGs from terran:
#

. /usr/usd/scripts/move/.moverc

HOST=$( hostname )

# Don't run this if Oracle is running

ps -ef | grep ora_pmon | grep -v grep
if (( $? == 0 ))
then
        # Oracle is running, halt !
        print "Oracle is running. Don't vgexport anything!"
        exit
fi

# Ask SA if he wants to vgexport volumes on this server..
read ANSWER?"Do you want to vgexport live VGs (yes/no): "
typeset -l LOW_ANSWER=$ANSWER

if [[ $LOW_ANSWER != "yes" ]]
then
        print "You didn't enter 'yes'. Script will exit without vgexport."
        print "If you want to vgexport VGs, run script again and answer
'yes'."
        exit 1
fi

# Answer was yes. vgexport

print "You answered 'yes'. vgexports will run right now."

bdfm.ksh # bdf before umountall
umountall ; mount /stand
bdfm.ksh # bdf after umountall

strings /etc/lvmtab | grep /dev | grep -v -e dsk -e vg00 | while read VG
        do
                vgchange -a n $VG
                vgexport $VG
        done

if [[ $LOW_ANSWER != "yes" ]]
then
        print "You didn't enter 'yes'. Script will exit without vgexport."
        print "If you want to vgexport VGs, run script again and answer
'yes'."
        exit 1
fi

# Answer was yes. vgexport

print "You answered 'yes'. vgexports will run right now."

bdfm.ksh # bdf before umountall
umountall ; mount /stand
bdfm.ksh # bdf after umountall

strings /etc/lvmtab | grep /dev | grep -v -e dsk -e vg00 | while read VG
        do
                vgchange -a n $VG
                vgexport $VG
        done

print "vgexport successfully run!"

[root@zerg: action]# cat vgimport_zerg.ksh | more
#!/usr/bin/sh
#
# zerg:/move.zerg/scripts/vgimport_zerg.ksh
#
# vgimport the local VGs to zerg:
#
# VG Minor #
#

HOST=$(hostname)
. /usr/usd/scripts/move/.moverc

function vgimpf {
        VG=$1
        typeset -Z2 MN=$2
        mkdir /dev/$VG
        mknod /dev/$VG/group c 64 0x${MN}0000
        vgimport -s -m $MOVEHOST/mapfiles/mapfile.$HOST.$VG $VG
        vgchange -a y $VG
        vgcfgbackup $VG
     }

vgimpf vg01 01

==========

From : Paveza, Gary <gary.paveza@AIG.COM>
Sent : Wednesday, July 20, 2005 9:25 PM
To : "'Dave T.'" <davidlt77@hotmail.com>
Subject : RE: [HPADM] Easing Impact of SAN Changes to HW/Device Paths

Go to previous message | Go to next message | Delete | Inbox

I would suggest that you create export map files for all your disks:

vgexport -m <mapfile> -s -p -v /dev/vg*

This creates a file to be used in vgimport and more importantly puts the
VGID on each disk in the volume group.

If you have a problem that changes the device files, do the following:

vgexport /dev/vg*

mkdir /dev/vg*
mknod /dev/vg*/group c 64 0xYY0000
vgimport -m <mapfile> -s -v /dev/vg*

---------------------------------------------------------
Gary Paveza, Jr.
Senior Systems Administrator - HP-UX CSE
(302) 252-4831 - phone

==========

From : Stuart Abramson <stuarta46@yahoo.com>
Sent : Sunday, July 24, 2005 3:18 PM
To : "Dave T." <davidlt77@hotmail.com>
Subject : Re: [HPADM] Easing Impact of SAN Changes to HW/Device Paths

Go to previous message | Go to next message | Delete | Inbox
Whenever we are going to make SAN changes we record the VG info of the VGs
(minor number, PVs, map files, LVs, etc..). That way if the device file
names change, then we can vgexport/vgimport and get them back.

We also record the Veritas Netbackup tape information with Veritas Netbackup
commands, (I forget their names now, tpautoconf, or someting like that.) to
recover later.

I can send them to you if you want them...

----Original Message Follows----
From: "Dave T." <davidlt77@hotmail.com>
To: hpux-admin@dutchworks.nl
Subject: [HPADM] Easing Impact of SAN Changes to HW/Device Paths
Date: Wed, 20 Jul 2005 14:38:14 -0400

Environment:

HP-UX 11i servers
Brocade SAN switches
VA7410 disk arrays
SureStore tape libraries

When changes are made to the ports on the SAN switches that route to the
disk or tape devices, it changes the hardware and device paths to them in
the OS. Whenever this happens, it has been a laborious process to recover
everything. Has anyone found an easy way to handle this? Does anyone have
scripts that ease the pain when the paths change?

Dave

--
             ---> 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)

--
             ---> 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)

• application/octet-stream attachment: load_balance

• application/octet-stream attachment: vgsnapshot

• application/octet-stream attachment: vgrecover

• Previous message: Ben Le: "[HPADM] [SUMMARY] Software Maintenance - Micro Focus Cobol on HP-UX 11.11"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]