New VG in modular and legacy package

[yash123]

To add new volume group in SG cluster package can be running if it is modular package.
In case of legacy package need to halt the package.
In both the case we need to update cluster and package config files.
Serciceguard experts kindly explain why this.

[g3jza]

Hi,
modular packages are / will be the preffered method of creating packages. Legacy style package as it's name suggests, may be obsolete in next releases of SG and removed.

Since SG 18/19, this different approach to packages(modular) allows many other modifications to the package to be made online, without the need to bring the package down.

I don't know whether your question is of any use, you just have to admit the fact that creating modular packages makes life easier to you, as many modifications can be made online :) and different type of mechanism is used when creating/modifying/starting/halting packages.

There's also command cmmigratepkg (#man cmmigratepkg) which can help you to migrate existing legacy packages to modular style packages.

[Vivek_Pendse]

1. In legacy package, no need to halt the package. Just create vg & lvs. Then make entries in control file & activate vg in exclusive mode & mount the lvs on required mount points.
In future, when you restart the package, it will automatically mount the file systems.

2. This is not the case with modular package. Even through, you make entries in conf file, then also, you have to run the checkconf/applyconf to enable it in restarting package.

Hope, this helps you.

Thanks,
Vivek

[yash123]

Thanks for reply
I know this. I am in search of how modular package is working.
Please help me?

Vivek, to make use of newly added vg need to restart the package otherwise it wonâ t mount.

[yash123]

Hi melvyn burnard ,Stephen Doud I am really sorry to disturb you. Coud you please advice.

[Vivek_Pendse]

Modular package has modules for each of the service like vg, lv or package ip. Need to define the required modules.

[Stephen Doud · Accepted solution]

I am not certain I understand your question.

According to table 7-3 (page 393) in the most recent Managing Serviceguard manual at http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02437444/c02437444.pdf , you may add a VG to a running modular package:
Add a volume group: modular package ->
Package can be running.

Both legacy and modular packages must reference package-specific volume groups (if used) in either the package control script (legacy) or package configuration file (modular) in order for Serviceguard to activate/deactivate the volume group(s).
The legacy script is only run when the package is started or stopped.
The modular package configuration file is only used to update the cluster binary file (cmapplyconf), which is consulted when a package is started or stopped. Modular packages manage volume groups by invoking /etc/cmcluster/scripts/sg/volume_group.sh when the package is started/stopped.

[yash123]

Thanks for the reply..
cmapplyconf package config file call the vg script and activate the new VG. Package halt/start is required only for testing the failover.
Please correct if I am wrong.

[Mel Burslan]

with the legacy packages, you can create the volume group, activate it, create LVs and mount them on the node running the packages and proceed like nothing has happened and package will be happy to use the new mount points if you make the application see the new volumes without bringing it down and up again.

One caveat: when you utilize this method, your new VG is not in cluster controlled mode. Next time you halt your package and bring it back up, you will get a boat load of error messages, regarding the activation of this VG followed by not being able to access the LVs it contains.

After you run cmhaltpkg command, you need to remember to run commands:

vgchange -a n
vgchange -c y

then you can start your package as usual.

[Mel Burslan]

oh by the way, you need to do the vgexport and vgimport to balance the LVM volumes, seen by each member of the cluster, which is needed to run the package. This is the most overlooked part of clustered disk management and always comes back to bite you in the rear end. As you can see, I forgot it in my first response. Guess what happens, when you have short time to mess with the cluster and get excited once everything starts working. You simply forget. Please DON'T !

[Vivek_Pendse]

When the pkg conf will be created, there is a parameter:
failover_policy CONFIGURED_NODE

Where, the pkg running node halts/shuts down due to any hardware issues, then package fails over automatically on the configured_node.

Instead of pkg halt/start, you can do node halt, so the pkg will failover to the fail over node, & you can do your testing.

[Viktor Balogh]

Mel,

...
> One caveat: when you utilize this method, your new VG is not in cluster controlled mode.
...
>vgchange -a n
>vgchange -c y
...


As far as I remember, one can easily add the cluster flag to the vg while the package is online. (that's the "vgchange -c y" command)
After this, you can attach the vg to the package without bringing it offline, but you need to activate it in exclusive mode. (vgchange -a e). That's exactly what the package control script does at startup.

So by doing this, you can avoid those "boat load of error messages" at the next package start.

[Stephen Doud]

The legacy package configuration file identifies the package control script, in which the volume groups, logical volumes, mount directories and options are called out.
When cmapplyconf is performed on the package configuration file, the cluster binary is updated with the path the legacy package control script.
The modular package configuration file does not have a package control script specifier because
a) the modular packages uses standard scripts in /etc/cmcluster/scripts/sg (for volume groups, /etc/cmcluster/scripts/sg/volume_group.sh) which already exist on each node in the cluster.
b) the VGs, LVOLs, mount directories and mount options are specified directly in the modular package configuration file.

Starting and stopping the package on each node validates (or invalidates) it's ability to run on that node.