Installation guide

<service name="foo">
<fs name="1" mountpoint="/mnt/foo" device="/dev/sdb1" fsid="12344">
<nfsexport ref="exports"> <!-- nfsexport's path and fsid
attributes are inherited from the mountpoint and fsid
attribute of the parent fs resource -->
<nfsclient ref="bob"/> <!-- nfsclient's path is inherited
from the mountpoint and the fsid is added to the options
string during export -->
<nfsclient ref="jim"/ >
</nfsexport>
</fs>
<fs name="2" mountpoint="/mnt/bar" device="/dev/sdb2" fsid="12345">
<nfsexport ref="exports">
<nfsclient ref="bob"/> <!-- Because all of the critical
data for this resource is either defined in the resources block
or inherited, we can reference it again! -->
<nfsclient ref="jim"/>
</nfsexport>
</fs>
<ip address="10.2.13.20"/>
</service>
If the service were flat (that is, with no parent/child relationships), it would need to be configured as
follows:
The service would need four nfsclient resources — one per file system (a total of two for file
systems), and one per target machine (a total of two for target machines).
The service would need to specify export path and file system ID to each nfsclient, which
introduces chances for errors in the configuration.
In Example D.5, “ NFS Service Set Up for Resource Reuse and Inheritance” however, the NFS client
resources nfsclient:bob and nfsclient:jim are defined once; likewise, the NFS export resource
nfsexport:exports is defined once. All the attributes needed by the resources are inherited from parent
resources. Because the inherited attributes are dynamic (and do not conflict with one another), it is
possible to reuse those resources — which is why they are defined in the resources block. It may not
be practical to configure some resources in multiple places. For example, configuring a file system
resource in multiple places can result in mounting one file system on two nodes, therefore causing
problems.
D.4 . Failure Recovery and Independent Subt rees
In most enterprise environments, the normal course of action for failure recovery of a service is to
restart the entire service if any component in the service fails. For example, in Example D.6, “ Service
foo Normal Failure Recovery” , if any of the scripts defined in this service fail, the normal course of
action is to restart (or relocate or disable, according to the service recovery policy) the service.
However, in some circumstances certain parts of a service may be considered non-critical; it may be
necessary to restart only part of the service in place before attempting normal recovery. To
accomplish that, you can use the __independent_subtree attribute. For example, in
Example D.7, “ Service foo Failure Recovery with __independent_subtree Attribute” , the
__independent_subtree attribute is used to accomplish the following actions:
If script:script_one fails, restart script:script_two and script:script_one.
If script:script_two fails, restart just script:script_two.
If script:script_three fails, restart script:script_one, script:script_two, and script:script_three.
If script:script_four fails, restart the whole service.
Red Hat Ent erprise Linux 5 Clust er Administ rat ion
116