Serviceguard Package vgextend

[SR_2006]

Hi ,
I am having 2 servers in Serviceguard.One server is running Database & Omnibackup & other is running application.I want to extend the VG of Omnibackup Package.
For this is it requd. to down the cluster or just halt the concenred package.
My plan of action is :-
1. Down the concenred package using cmhaltpkg -v package_name.
2.Do vgextend of that vg.
3.Vgexport on Ist node.
4.vgimport on IInd node.
5.Again start the package.
One more thing for this vgextend I have created Lun but when ioscan & insf is run it is not creating device files in /dev/dsk.I am using VA7400 array.
For this I used ioscan -fnC disk & insf -e.
Can somebody give me step by step procedure for this activity.
Thanks in advance.

[Steven E. Protter]

Shalom,

You need to sometimes boot your system after creating a new LUN to make it fully usable with device files and ioscan.

There are ways of making it happen without booting, but ove rtime they have proven unreliable to me.

try:

insf -C disk

Then the rest of your planned procedure is fine.

SEP

[Darrel Louis]

Sanjay,

When new disks has been added to a server we do the following:
# ioscan -fn
# insf -e
For EMC
# symcfg disco
We only have to reboot if the Instance number or out of sync, create a identical ioconfig file on all cluster nodes.
When extending a VG we don't always stop the cluster package.
The steps specified or OK.

Goodluck

Darrel

[SR_2006]

Hi steven & Dareel,
thanks for ur response.
One thing I want to share that before creating this lun9 of 6 Gb I have deleted previous lun9 of 100 Gb space.
so the files which was created in /dev/dsk on mar 19 are c13t1d1 & c12t1d1 (alternate link) may be of 100 gb lun.But when I created 6 Gb lun on Yesterday these device files date is not updatated.when I use diskinfo for these device files it is showing 6 Gb space.
So how I confirm that these device files are of 6 gb lun which created yesterday.Because these files creation date is showing as Mar 19.
Thanks.

[Darrel Louis]

Sanjay,

If diskinfo display 6 Gb than you're oke.

But to be sure you can perform the following, the disk shouldn't belong to a VG:
rmsf -H (HW-Path of the 6Gb disk.)
Check if the device file has been removed(ll /dev/dsk).
Than perform the following: insf -e.

Darrel

[Albert_31]

Hello Sanjay,

What you are seeing is the correct..

a) Initially you have deleted teh lun9 from the va..however the device files were not deleted.. the device file as per you was cxt1d1

b) Now you have created a new lun "9" on the VA so the device file remains the same on the OS..since the device files (txdy) are generated based on the LUN number..which in ur case remains the same..

Even diskinfo is showing you the same,..incase you need more confirmation..please post the following

a) armdsp -a
b) ioscan -fn

regards

albert

[rariasn]

Hi Sanjayl,

Your plan is correct.

Prior to start package, probe you activate VG and mount FS in second server.

rgs,

ran

[Stephen Doud]

Very common question.

The method:
Under normal operation, LVM commands do NOT require the server be rebooted.
If such is required, seek LVM cumulative and commands patches.

Commands run on the node where the VG is active
1. vgextend only works when the target VG is active. This mean that the
vgextend can be performed while a package is accessing the VG.

WARNING: INSURE THE DISK IS NOT ALREADY ALLOCATED TO ANOTHER
VOLUME GROUP IN ANOTHER CLUSTER!

On the node where the volume group is active, use this syntax to prepare
the target disk for LVM:

# pvcreate -f /dev/rdsk/c4t4d0

If the disk has a PV-link (another path through another I/O adapter) and
I/O bus load balancing is an issue, vgextend the disk's paths into
/etc/lvmtab in the order that LVM should access them. Example:

# vgextend vg07 /dev/dsk/c4t4d0 /dev/dsk/c2t4d0

An less-used alternative method is to set the primary path using the
pvchange command:

# pvchange -s /dev/dsk/c2t4d0


2. On the same node, add logical volumes to the volume group as needed, or
extend current logical volumes.
NOTE - Online JFS is required to extend logical volumes that are
active.

# lvcreate -L 600 vg07 (creates a 600MB logical volume)
# newfs -F vxfs /dev/vg07/rlvol1 (if not a raw database lvol)

Mount the new lvol:

# mount /dev/vg07/lvol1 /data7

Load the new lvol with data as needed. Umount it when complete.

3. Create a new LVM map file:
# vgexport -pvs -m /etc/lvmconf/vg_shared.map /dev/vg_shared

NOTE: the -s option adds the unique VGID to the top of the map file. It
will be used by the vgimport process to identify disks labeled with this
VGID, to eliminate the need to specify the actual physical disks to import.
The -s option is NOT available with HP-UX 10.01. In that case, you must
explicitly list every disk that belongs to the volume group during the
vgimport.

4. Copy the map file to the other adoptive node(s)
# rcp /etc/lvmconf/vg_shared.map nodeB:/etc/lvmconf


Commands run on the other node where the VG is not active
5. Record the group minor number for the VG to which you added the disk.

# ll /dev/vg*/group
crw-r----- 1 root root 64 0x000000 Sep 19 1996 /dev/vg00/group
crw-rw-rw- 1 root sys 64 0x020000 Jun 4 12:39 /dev/vg07/group
^
Record eg:0x02 <--

6. The lvmtab on the second node must be updated to reflect the VG ownership
of the new disks. The proper method to update it is to vgexport the old
set, and vgimport the current set of disks. The following vgimport
command takes advantage of the -s option, which expects the top line in
the map file to contain the VGID of the volume group. Using the VGID as
a reference, the vgimport command given below will not expect a list of
disks, but will instead scan the backplane, looking for disks that
contain the same VGID. Finding one, it will add it to lvmtab for the
indicated VG.

vgexport the volume group.
# vgexport /dev/vg07

It will remove /dev/vg07 and all special files in the directory.

7. Recreate the directory and group file:
_ from step 5
# mkdir /dev/vg07 /
# mknod /dev/vg07/group c 64 0x020000

8. Reimport the VG using the new map file.
# vgimport -vs -m /etc/lvmconf/vg07.map /dev/vg07

This command will cause LVM to query ALL PV's (Physical disks) on the
system, inspecting them for a VGID that matches the one listed in the top of
the map file. It adds all matching disks into the /etc/lvmtab. It also
adds new lvols. If you want your pvlinks listed in a particular order, do
NOT use the -s option, but individually specify the sequence of disks.

9. On the original node, update the package control script with the additional
lvols and mountpoints and distribute the control script to all adoptive
nodes.

Example listing of lines added in the control script. Note the sequentially
increasing array index numbers :

LV[0]="/dev/vg06/lvol1"; FS[0]="/vg06/lvol1_mount"
LV[1]="/dev/vg06/lvol2"; FS[1]="/vg06/lvol2_mount"
LV[2]="/dev/vg07/lvol1"; FS[2]="/vg07/lvol4_mount"
LV[3]="/dev/vg07/lvol2"; FS[3]="/vg07/lvol5_mount"
LV[4]="/dev/vg07/lvol3"; FS[4]="/vg07/lvol6_mount"
LV[5]="/dev/vg07/lvol4"; FS[5]="/vg07/lvol7_mount" <<<----

Note the index number must be increamented for the script to work properly

10. Test the new logical volume actuation on all adoptive nodes by restarting
the package on all nodes.

See doc. ID UXSGLVKBAN00000002

[Thomas J. Harrold]

You do not necessarily need to take an outage to the MC/SG package. You can extend an existing VG/LV in place, and do your VG export/import on the second node.

You'll need to modify the SG package only if you are changing the LVM structure of the package.

That being said, you need to TEST, TEST, TEST the first opportunity for a planned downtime. I've seen MANY SG clusters break due to changes that were NOT tested!

-tjh

[SR_2006]

Dear all,
Vgextend done when package was running because when package is halted that vg was not active.
Now I am facing one problem that vgextend is extended on node I & also /etc/lvmtab updated on Node I.But when map file is imported on Node II it is imported but /etc/lvmtab is not updating the entry of c5t1d3 & c13t1d3 (Alternate link)which is used for extending vg on node I.Because now if my node I gets failed then it will create problem for me.

Thnks in advance.

Sanjay

[Albert_31]

Hello Sanjay,

First.. when the package is halted, you need to activate the volume group

a) make it cluster un-aware
vgchange -c n
b) activate the vg
vgchange -a y
c) carryout the changes
d) export and import the VG activities
e) on any one node
vgchange -a n
vgchange -c y

Since now that you have done it online. and you are saying that it if failing on node2..can you post the following
Node 2
a) strings /etc/lvmtab
b) vgimport -p -v -s -m

[SR_2006]

Hi albert,
I had created lun9 for vgextend & this lun is showing in armdsp -a from second node.Is it also requd. to run insf & ioscan on node II so that it will create these device files & will update lvmtab after vgimport.
Because how IInd node will aware of these device files.Is this care taken by mapfile?

[Albert_31 · Accepted solution]

Hello Sanjay,

vgexport -s will put the vgid in the map file.

then vgimport with the -s option will take probe all the luns and will automatically import all the luns which are part of the volume group based on the vgid..incase it fails then you can keyin the device files along with the vgimport command.

on node 1, where all the activity is complete

# vgexport -p -v -s -m
# rcp the file to the other node

node 2
# ioscan -fnC disk (check if the device is available)
#insf -e (to create teh device file)
# strings /etc/lvmtab (check if the vg is present or not..if not present then directly to the vgimport command)
# mkdir /dev/vgname
# mknod /dev/vgname/group c 64 0xYY0000
here YY = is the same as node 1..
# vgimport -p -v -s -m
if no errors then, you will get an error regarding CPUID etc..not exactly clear what it is :)
# vgimport -v -s -m

if the above vgimport complains that it is not able to import the vg due to disks
# vgimport -p -v -s -m /dev/dsk/devices ....
if no error then

# vgimport -v -s -m /dev/dsk/devices ....

strings /etc/lvmtab to confirm that everything is OK..
ll /dev/vgname
to check that all the lvols are in order :)

[SR_2006]

pl. find attached /etc/strings & map file of node 2.
thanks.

sanjay...........

[SR_2006]

After running ioscan & insf, device files for lun9 are created on Node II .
Now Node II should update lvmtab file for extended vg after vgimport.
Did i again required to run vgexport & vgimport?
thanks in advance.

[Albert_31]

Hello Sanjiv,

Teh volume group vgsec is present in the lvmtab file on the node2

# since the volume is not activated on this node do the following

# cp -p /etc/lvmtab /etc/lvmtab.
# vxexport -v -s -m /tmp/vgsec..orig /dev/vgsec

# mkdir /dev/vgname
# mknod /dev/vgname/group c 64 0xYY0000
here YY = is the same as node 1..
# vgimport -p -v -s -m
if no errors then, you will get an error regarding CPUID etc..not exactly clear what it is :)
# vgimport -v -s -m

if the above vgimport complains that it is not able to import the vg due to disks
# vgimport -p -v -s -m /dev/dsk/devices ....
if no error then

# vgimport -v -s -m /dev/dsk/devices ....

strings /etc/lvmtab to confirm that everything is OK..
ll /dev/vgname
to check that all the lvols are in order :)

[SR_2006]

Thanks Albert.
One more thing ,if the vgimport complains that it is not able to import the vg due to disks then u suggested to use-
vgimport -v -s -m /dev/dsk/devices ....
Here which device file I have to use either node I or Node II.Because for lun 9 device files are different from both nodes.
I think it should be of Node II.
thanks-sanjay

[Albert_31]

sanjay,

You should use the device files of node2.

[SR_2006]

Thnks to all.
sanjay.....