Operating System - HP-UX
1754952 Members
2726 Online
108827 Solutions
New Discussion

Adding Disk to Package-owned VG without disruption??

 
SOLVED
Go to solution
chisle
Advisor

Adding Disk to Package-owned VG without disruption??

I need to know the proper way to extend a VG in SG (A.11.20 on B.11.31, latest gold pack).

 

I use /dev/vgDBsg for my DB package

I use Agile disk naming, and use CDSF device files in my VGs (/dev/cdisk/...)

 

How do I:

A. add a disk to an active SG VG that is part of an active package so that it would be available to any node the package will fall over to, without disrupting the package to do so

b. create a new file system in the VG in such a way that it will be availble on any node the package will fall over to, without disrupting the package when I add it

 

I've tried to find this procedure in the latest edition (19) of Managing ServiceGuard, but have failed to locate it.

 

At present, the only option I have is to scan the disk on all the servers, redistributed the CDSF configuration, then bring the package offline, export the vg and import on all the nodes, etc.

 

This is very non-elegant.

5 REPLIES 5
Stephen Doud
Honored Contributor
Solution

Re: Adding Disk to Package-owned VG without disruption??

This topic is one of the most common topics, except you refer to agile addresses rather than legacy device special files.

Volume groups activated in exclusive mode allow you to add disks to the volume group as you normally would.  Use the agile address when using vgextend to add a disk.  
If you need to add new logical volumes, do that too, on the node where the VG (and package) is active.

Then create an LVM map file for the volume group (vgexport -pvs -m <vgname>.map /dev/<vgname>) and copy it to the other nodes in the cluster.

Use that map file on the other nodes to re-import the volume group:
OTHERNODE:
ll /dev/*/<vgname>    # copy down the minor number ~ oxNN0000  (the NN part)

vgexport <vgname>

mkdir /dev/<vgname>

mknod /dev/<vgname>/group  c 64 0xNN0000  (use the NN values from above)

vgimport -vs -m <vgname>.map /dev/<vgname>

 

chisle
Advisor

Re: Adding Disk to Package-owned VG without disruption??

I assume, then, that there is no elegant solution to this (ServiceGuard commands or WebUI), but I'm left to vgexport the vgs on the inactive nodes and re-import them every time we make an extension to the vg or add an lvol.

 

If that's the case, I think I need to know where the upgrade suggestions box is! :D My customer will be making lots of requests for changes to vgs in this environment, and it's going to be a process fraught with error, I'm afraid.

 

Thanks.

Stephen Doud
Honored Contributor

Re: Adding Disk to Package-owned VG without disruption??

I create scripts for actions that I perform frequently. You customer may wish to do the same.

If you really want to request an enhancement to the Serviceguard lab, please open a Support Center case to relay your suggestion to the lab.
chisle
Advisor

Re: Adding Disk to Package-owned VG without disruption??

Thank you for your response. I also found a tech doc that pretty much said the same as you had indicated above, and confirm that there is no other way to do this.

Yes, using the Agile disk does mean, along with cdsf, that there are some small alterations to the process, but overall you do have to export/import on the inactive nodes, and there is no way around that.

Thank you for your input! Much appreciated.
Steven E. Protter
Exalted Contributor

Re: Adding Disk to Package-owned VG without disruption??

Shalom,

 

I think there is a way to accomplish the goal.

 

You need to make sure the package is running on only one system then:

 

pvcreate the new disk.

vgextend the volume group.

vxexport with the -p preview option an -m create a map file.

 

Copy the map file to the other nodes and vgimport.

 

You will get some complaints but if the disk is visible you should get throug it.

 

Then you can extend the logical volume on the system running the package and use OnlineJFS (fsadm) to extend the file system.

 

Taking care of this is much easier with a downtime, but I belive it is possible without package disruption.

 

I would howver have a warning out to the user community in case something goes awry. Things do happen unexpected in IT environments.

 

SEP

 

Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com