[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Linux-cluster] <script> and <fs> as child resource of <fs> resource

This is related to my earlier post where I asked about
start/stop ordering.

I have a setup where my application code is installed on a
SAN volume.  Furthermore, the data directory appears as a
subdirectory of install root but is actually on another SAN
volume.  Taking Apache as an example, let's say it's
installed under /opt/apache and web pages are under

The directories correspond to devices like this:

/dev/sda1 - /opt/apache
/dev/sdb1 - /opt/apache/htdocs

To start Apache I need to first mount /dev/sda1, then mount
/dev/sdb1, and finally invoke /opt/apache/bin/apachectl
start.  To stop I would do things in reverse. 
Particularly, I can't unmount /opt/apache before unmounting
/opt/apache/htdocs.  (rgmanager doesn't deal with failed
umounts well.)

In cluster.conf, this dependency can be expressed like

        <fs name="/opt/apache" device="/dev/sda1" ... />
        <fs name="/opt/apache/htdocs" device="dev/sdb1" ...
        <script name="apachectl"
    <resourcegroup name="rg1">
        <fs ref="/opt/apache">
            <fs ref="/opt/apache/htdocs">
                <script ref="apachectl"/>

This is currently not possible because the only child
resource type allowed inside <fs> is <nfsexport>.  But the
rule can be easily changed by adding:

    <child type="fs"/>
    <child type="script"/>

to /usr/share/cluster/fs.sh file.  After the change things
work as expected.  But is that a safe change?  What are the

It seems we can allow any root resource to contain children
of any other root type.  Not every case will have a
practical use case but many will.  For example, <ip> can be
configured as a child of <script>, to bring up the IP
address only when the application is ready, and to remove
the IP address and therefore stop any more incoming clients
before shutting down the application.

What do folks think?  Are there reasons we shouldn't do


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]