Service Guard automated export import help

[Daryl Yockey]

I am trying to figure out a way to automate a 2 node service guard setup for the disk export and import on 2 machines that have different hardware paths configured.

I am able to do this on identical machines since the device paths are the same and using lssf to grep for the identical path on the standby using information from the primary.

Is there a way to do this when the device paths are not the same.

I am using a VA74XX array for the storage device no scsi.

Any clues or suggestions would be helpfull

[John Meissner · Accepted solution]

vgimport script attached

[John Meissner]

vgexport script attached...

[John Meissner]

after the vgexport script runs it will find and ftp the map files over the the failover server automatically. Then the vgimport scripts can run using these map files.

[Massimo Bianchi]

Hi,
depending on your knoledge of lvm you have many possibilities, like using the vgexport -s option to use the VGID to identify the disks (and let the work at the S.O. !).

Other include extracting the VGID manually, but basically they all refer to this procedur.

Just an add to previuos reply :)

Massimo

[Geoff Wild]

John,

Just a question on your scripts -
Why do you halt the packages on the vgexport?

I only halt when I need to import...

Rgds...Geoff

[John Meissner]

Geoff - True - I didn't need to halt them. I can't remember why I did that. I think I wrote these scripts durring an outage on a Saturday when we were doing disk work. I think we were getting ready to bring the disks over the the failover server and test them.

True... and unnecessary part to accomplish the required job for this case.

[John Meissner]

Also I just noticed a possible problem with the import script ...

in the section that deals with NEXTMINORNUM
I modified it to work differently....

Sorry about the mistake...
##############################

print "Beginning vgimport of map files"
rm -f /tmp/minornum.list
touch /tmp/minornum.list

#verify all vg map files are present according to the variables set earlier vg[0] vg[1] vg[2]
for i in ${VG[@]}
do
if [ -f "$i.map" ]
then
echo "$i.map found"
else
echo "$i.map NOT FOUND. CANNOT PROCEED WITHOUT ALL MAP FILES"
exit 1
fi
done

vgmap_files=$(ls /etc/cmcluster/AEP/*.map | sed 's/\/etc\/cmcluster\/AEP\///g'| sed 's/\.map//g')
print "using map files $vgmap_files"
rm /tmp/minor.tmp
ll /dev/vg*/group | awk '{print $6}' | cut -c 3-4 | sort | tail -1 > /tmp/minor.tmp

for i in $vgmap_files
do
#this will allow for the use of the same minornum if the vg's already exist
ll /dev/vg*/group | grep $i | awk '{print $6,$10}' >> /tmp/minornum.list
if [ $? != 0 ]
then
echo "$i does not previously exist"
fi

newvg=$(ll /dev/vg*/group | grep $i)
if [ "$newvg" = "" ]
then
MINORNUM=$(cat /tmp/minor.tmp)
((NEXTMINORNUM=MINORNUM+1))
print "0x0"$NEXTMINORNUM"0000" $i >> /tmp/minornum.list
print $NEXTMINORNUM > /tmp/minor.tmp

fi
done

# export the old VG's
echo "exporting old VGs"
oldvg=$(cat /tmp/minornum.list | awk '{print $2}')
for i in $oldvg
do
echo "vgexport $i"
vgexport $i
done
#fi


#now mkdir for the new vg's
echo "make directories for VGs"
vgdir=$(cat /tmp/minornum.list | awk '{print $2}')
for i in $vgdir
do
echo "mkdir -p /dev/$i"
mkdir -p /dev/$i
done

#mknod
echo "Make node"
cat /tmp/minornum.list | awk '{print "mknod /dev/" $2 "/group c 64 " $1}' > /tmp/makenod.sh
chmod +x /tmp/makenod.sh
cat /tmp/makenod.sh
/tmp/makenod.sh

#vgimport
echo "importing VGs"
cat /tmp/minornum.list | sed 's/\/dev\///g' | sed 's/\/group//g' > /tmp/minornum.list2
cat /tmp/minornum.list2 | awk '{print "vgimport -m /etc/cmcluster/AEP/" $2 ".map -s -v /dev/" $2}' > /tmp/vgimpt.sh
chmod +x /tmp/vgimpt.sh
cat /tmp/vgimpt.sh
/tmp/vgimpt.sh
print "import of volume group map files complete"

[John Meissner]

Please - no points for my last post... I was just correcting an error

[Daryl Yockey]

Thanks for the information. I have been looking over that option of the vgimport/vgexport command for over 2 years

[Stephen Doud]

Hi Daryl,

Normally, it is not necessary to vgexport and reimport LVM volume groups after the initial cluster setup since volume groups cannot be activated on more than one server at any given time. Therefore I'm curious as to why the need to vgexport and re-import volume groups? Safety concerns?
_Stephen

[Daryl Yockey]

Stephen

Thanks for your concern.

The need is for unfamiliar users to be able to upgrade machines from one class to another in a rolling type fashion just following a document.

This would create a scenario where one machine in the cluster will be a different class then the other and the hardware paths and devices would be different. The end users of the script would need to have a minimal amount of interaction so manually finding the drives and specifying this on a command line would not be an option.

Daryl