Replacing package control scripts by softlinks

[Ralph Grothe]

Hi,

I'm currently revising the configuration of one of our clusters.
Editing the packages' control scripts I came to the conclusion that in their main parts they were all just repetitions with little very variation.
This is because the packages all follow the naming scheme b[01][0-9], and each package has a VG named accordingly vgb[01][0-9] with just one LV that is mounted as /b[01][0-9].
These are 14 instances of Oracle DBs that are started and stopped all the same way.
So there were only slight modifications in the customer_defined functions necessary to make a generic version.

As an example of those variable entities please have a look at the attachment.

If any changes to the control scripts become necessary this is imho too much fuss for me to maintain 14 different files every time.

This all said and done, I would like to make sure if SG can live with just symbolic links for most of the package control scripts.
I can see no reason why this shouldn't work, but better have the experts asked here before.

Regards
Ralph

[Ralph Grothe]

Addendum,

as it stays all in the same filesystem it could of course also be hardlinks (probably even a better choice?)

[Robert Gamble]

Ralph,

I understand what you are attempting to do. It sounds nice from a Sys Admin's point of view to be able to make changes to all the packages at once when that is needed.

However, by doing this, you have also added an element of risk that needs be evaluated by business/process owners. It would now be possible to corrupt/destroy/render unusable all 13 highly availiable packages with a single typo. My business/process owners would never allow that.

HTH, Good Luck!

[Ralph Grothe]

Hi Robert,

good point, your concerns about possibly defeating HA of all other 13 packages by introducing a single point of failure source through my links.

Were it a sound HA cluster I'd totally agree and I would have never come up with such a nasty quirk.

To tell the truth, this SG cluster hosts an application which isn't really "clusterable".
But I think here the customer's application developers are to blame for coming up with a really big sort of distributed Oracle DBMS application that doesn't cling to MC/SG standards.

There will never be a situation where any of the 13 packages will (and can) run on their own, because all can only live as long as the kind of master package b00 is up and running.
That's why during a cluster start one has to make sure that package b00 is started as first and all other packages held waiting until it is up and running.
I "solved" this by placing this ugly idling loop in the customer_defined_run_commands() of package control scripts b01 through b13:

# idle until master package b00 is up
until [ "$(/usr/sbin/cmviewcl -p b00|awk '$1=="b00" {print $3}')" = "running" ]
do
sleep 10
done


Of course, the reverse scheme has to be followed on a cluster shut down, i.e. b00 has to be halted last after all other packages.

My hack to fulfill this condition was by placing this silly idling loop in the customer_defined_halt_commands() of b00:

# idle loop until all other packages are down
while /usr/sbin/cmviewcl -l package|awk '$1~/^b/ && $1!="b00" {print $3}'| grep -q -e running -e halting;do
echo "$PACKAGE waiting for all other packages to reach STATE halted"
sleep 10
done


I can almost see the shudder of disgust of the SG experts whoever took time to read this thread.
But we sysadmins had never been asked by the "solution providers" when this application was designed, and now have to come to terms with reality.

[Ralph Grothe]

Addendum,

I wasn't sure what would happen when I distribute my linked collection of package control scripts to the other cluster nodes.
I thought rcp would silently ignore them.
But I'm gladly surprised to see that rcp made real copies whenever it found a link.
That's sort of soothing :-)