QUESTION:
Can you tell me why for HACMP/6000 the executables for a program
cannot be on the shared disk? Please elaborate with examples, etc.
The guidelines I have states that only data can be on the shared disks.
I am sure the programs will run being on a shared disks and will
probably have to be started manually after a takeover, but there must
be a way to automatically start a database for example whose executables
are on shared disks.
---------- ---------- ---------- --------- ---------- ----------
A:
Current HACMP/6000 training emphasizes a configuration prohibition on
placing binary executables on shared media claiming that "problems
would result" if this program was running at the time that a fail-over
occurred. From a conventional perspective, I can't understand why a
read-only disk copy would be altered in any way. The copy in memory
would be lost, as well as all of its pointers and file-opens, but when
a new copy was read into a new memory on the acquiring machine, the end
result doesn't seem any different to me than if it had been read from
one of its own disks or the shared disks. Could you please explain the
rationale for this advice?
Answer:
It is recommended that executable modules are not placed and run
from a shared disk for the following reasons:
A. Licensing
Even though the instance of an application is running on a
single CPU at any one time, some SW vendors take issue with the
potential of a single copy of the application running on multiple
CPUs. Some vendors require a unique copy for each CPU that will
run the application, and even go as far as to license protect the
application by incorporating CPU specific information (Vital
Product Data) into the application at install time. This would
prevent a "fallover" CPU from restarting the application in
response to a failure.
It is prudent to query vendors during the planning stage to
identify such restrictions.
B. Application Invocation
Some applications (such as databases) have configuration files
that are tailored during installation, and stored with the
binaries. These configuration files usually provide startup
information, such as databases to be loaded, log files to be
opened, etc.
To put these configuration files on a shared filesystem usually
requires additional tailoring. Logic needs to be added to
determine which system is actually invoking the application.
This issue becomes particularly acute in Mutual Takeover scenarios,
where both systems are running different instances of the same
application (different databases), and would be standing by for
one another. Conflicts in the location and access of control files
can occur.
Much of the tailoring can be avoided by placing slightly different
startup files on local filesystems on either system. This would
allow context information to be static, instead of calculated each
time the application is invoked.
C. Reintegration
When a previously failed node is ready to rejoin the cluster,
the other CPU must gracefully give up the disk resources it
had acquired at the time of fallover. In order to do this,
it must unmount the file systems and varyoff the volume groups.
If there are active binaries on the shared disk, it is necessary
to shutdown the processes and remove the users from the file
systems in order for the unmount to succeed.
We have experienced some applications that have difficulties
in being shutdown gracefully. If a binary process cannot
be killed with a supplied command, the fallover server is unable
to unmount the the shared filesystem in preparation for the
varyoff of the volume group and the giveback of resources.
This will cause the reintegration process to fail and
manual intervention is required. This is an issue to be
researched with the provider of the application.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q658116 CRDFN
Additional search words:
CRDFN DISKS EXECUTABLES HACMP IX MAY94 OP OZNEW PROG PROGRAM
PROGRAMMABLE PROGRAMMER PROGRAMMING RISCOSO RISCSYSTEM SHARE
SOFTWARE SYS 6000
WWQA: ITEM: RTA000041834 ITEM: RTA000041834
Dated: 11/1996 Category: RISCOSO
This HTML file was generated 99/06/24~12:43:16
Comments or suggestions?
Contact us