Conference smurf::ase

    
    but, you should really read the Doug FRANK's white paper "ASE: theory
    of operation". A pointer is existing in this notefile but I don't 
    remember it (xirtlu.zk3.dec.com:/pub/ase/doc ???)
    
    He explains in details this kind of operations...
    
    Manu.

Manu,

thanx for the pointer. Unfortunately, I work from a remote home office and
don't have easy access to a PS printer. Does anyone know where there
might be a text version of the doc, or could someone summarize the
portion about when stop and start scripts are run for me?

thanx.

John McDonald
Atlanta CSC
[Posted by WWW Notes gateway]

There is a pdf file there...

theory13.pdf

does that help?

After reading .1 above, I copied theory_of_operations_13.ps down and 
read it.  On page 33 in the section on "Shutting down" it states:

    When it receives the shutdown message, the Afent (the original
instance, that is) executes the stop scripts for the services running
on that server.

I was on-site for the problem reported in .0 of this note and we
observed that the Agent executed the stop scripts for ALL services,
two of which were running on another member of the cluster.  This
caused us problems because of the intricate nature of the services.

I understood that the writer of .0 had reproduced the behavior.

Clair Garman
[Posted by WWW Notes gateway]

    Running the stop scripts is not the same as stopping the service.
    You should not have a problem running the stop script on a
    system when the service is actually residing someplace else...
    if you do then there is something that needs to be fixed in
    the stop script.
    
    

>     Running the stop scripts is not the same as stopping the service.
>     You should not have a problem running the stop script on a
>     system when the service is actually residing someplace else...
>     if you do then there is something that needs to be fixed in
>     the stop script.

The customer desires NFS access on member-2 to disks that are part of
a disk service running on member-1.  Assume that we then relocate the
service to member-2.  The stop script for that service
needs to:
	rsh member-2 umount /data
    
When the service starts on member-2, ASE will mount the disks locally.
That will be impossible if the stop script did not already umount the
NFS.

If the service is running on member-1 and one shuts down member-2 and
the service stop script executes on member-2, the above umount will
umount the directory /data from the disk service - a catastrophe.

We developed a work-around.  This is not a show-stopper.

The question remains:	Why is ASE stopping a service that is not
	running on that member?

Clair Garman
Washington, DC

<The customer desires NFS access on member-2 to disks that are part of
<a disk service running on member-1.  Assume that we then relocate the
<service to member-2.  The stop script for that service
<needs to:
<	rsh member-2 umount /data

    I think you have misunderstood something about how nfs services
    work here. It's too much detail for me to go into at this time
    in this conference but the short version is that if you are
    running an NFS service you should not have to perform this
    step.
    
         
<When the service starts on member-2, ASE will mount the disks locally.
<That will be impossible if the stop script did not already umount the
<NFS.

    ASE will mount the disks locally at its own mount point of
    /var/ase/mnt/servicename/data (or something like that)... but
    service nfs mount requests to data@servicealias as if the disks
    are really at /data.  Thus, you need to ensure that you are
    exporting from one mount point (say /datasource) and mounting
    to a mount point (say /data) at the client side. 
    
    To keep things simple and neat you should always nfs mount
    /datasource@servicealias to /data regardless of where the disks
    are at the moment... this means that if the service is on member-1
    then you will have an 'nfs loopback mount' on that system...
    if the disks move to member-2 then you will have an nfs loopback
    mount on that system. It's supposed to work.
        
<If the service is running on member-1 and one shuts down member-2 and
<the service stop script executes on member-2, the above umount will
<umount the directory /data from the disk service - a catastrophe.

    right... don't do it.
    
<We developed a work-around.  This is not a show-stopper.

<The question remains:	Why is ASE stopping a service that is not
<	running on that member?

    The answer remains: ASE is NOT stopping the service. It is
    calling the stop script. Not the same thing.
    

Dave,

I'm working the issue with Clair on this issue. A couple of points:

1. The customer isn't using an nfs service, they're using a disk
service. They tried using nfs and mounting it using nfs on both
members, but the performance was lousy (about 10 times slower).
The fact remains they still need both systems to access the filesystems.

2. What they're trying to do probably isn't the most optimum approach,
but there is nothing in any documentation anywhere that says it's
not supported.

3. The problem is that both Clair and I were totally unaware that ase
rans ALL stop scripts when a member was shutting down normally via
'shutdown' or 'init 0'. This fact isn't stated in any document THAT A
CUSTOMER HAS ACCESS TO. (That wasn't screaming, it's for emphasis 8-))

The result is that they used a solution that, according to what they
knew, should have worked. What would be a good thing to have is an additional
parameter that gets passed to the stop script in addition to RUNNING and
BOOTING
, something like 'SHUTDOWN'.

Thanx for all the feedback so far.

John McDonald
Atlanta CSC

[Posted by WWW Notes gateway]

    re: <<< Note 2003.8 by NNTPD::"[email protected]" "John McDonald" >>>
                               -< Clarification >-
John,
    
1. The customer isn't using an nfs service, they're using a disk
service. They tried using nfs and mounting it using nfs on both
members, but the performance was lousy (about 10 times slower).
The fact remains they still need both systems to access the filesystems.

    ??? You mean that if they NFS mount with ASE doing the dirty
    work they get worse performance then NFS mounting themselves?
    THat sounds a bit suspicious to me... but okay.
    
    
2. What they're trying to do probably isn't the most optimum approach,
but there is nothing in any documentation anywhere that says it's
not supported.
    
    Perhaps I have not followed what they are trying to do...
    
    more explicit information would be helpful... like the output
    of the asemgr -dv servicename for starters... also the contents
    of /etc/fstab and the start and stop scripts. Post that stuff
    here and I'd bet you'd get responses from Manu at least telling
    you exactly what is wrong and why.
    

3. The problem is that both Clair and I were totally unaware that ase
rans ALL stop scripts when a member was shutting down normally via
'shutdown' or 'init 0'. This fact isn't stated in any document THAT A
CUSTOMER HAS ACCESS TO. (That wasn't screaming, it's for emphasis 8-))

    Hmmmm.. most people get upset when they discover that 
    "shutdown -r"
    does not call the shutdown scripts in init.d and therefor the
    ASE stop scripts don't get called. This probably could all
    be documented more clearly - but that would leave so little
    fun for us in the field.
        
The result is that they used a solution that, according to what they
knew, should have worked. What would be a good thing to have is an additional
parameter that gets passed to the stop script in addition to RUNNING and
BOOTING
, something like 'SHUTDOWN'.

    Perhaps so. Most service action scripts know to keep their
    activities limited to the node they are running on...
    
    d

    Hi Clair,
    
    I understand your question about the stop scripts being executed at the
    shutdown time. I don't know if it is described somewhere in the
    documentation, but it's a fact. You said you have a workaround so I
    will not tell you that you can know which service(s) is running on the
    shutdown node by looking in the /var/ase/tmp directory for file(s) like
    SERVICENAME_IS_RUNNING. 
    
    For you Dave, I think you missed the fact that the second node is NFS
    mounting the DISK service filesystem of the first node on THE SAME MOUNT 
    POINT than the first node, so Clair is right, it must be dis-mounted 
    before the relocation. But, anyway, thanks for your bet ... :-)
    
    Manu.

re: .-1
    
.        For you Dave, I think you missed the fact that the second node is NFS
.    mounting the DISK service filesystem of the first node on THE SAME MOUNT 
.    POINT than the first node, so Clair is right, it must be dis-mounted 
.    before the relocation. But, anyway, thanks for your bet ... :-)
 
    Manu,
    
    You are right - I didn't see that it was a disk service until
    it was pointed out later. Of course, a disk service can also
    have its mount point umounted automagically by ASE... just as
    long as they are careful to find the processes with open files
    on the locally mounted file systems and kill them first, of course.
    
    I am at a loss, however, to understand why they would want
    to do the umount on member-1 (via rsh) when a stop gets issued to the script
    member-2. The stop script on member-1 should be perfectly able
    to to the umount when IT is called on its own node.
    
    Am I missing something?
    
    
    
    

    Dave,
    
    A drawing is better than thousand words...
    
    	SYSTEM-1				SYSTEM-2
    
    	/data					/data
    
    Locally mounted			      NFS mounted
    
    In case you try to relocate the service from SYSTEM-1 to SYSTEM-2, ASE can
    dismount /data from system-1, but when the service is starting on
    SYSTEM-2, ASE will not be able to mount /data on the local disk,
    because /data IS ALREADY A NFS MOUNT POINT ON THIS SYSTEM. So, Clair is
    right to "rsh SYSTEM-2 umount /data" in the stop script in anticipation
    of the arrival of the service on SYSTEM-2.
    
    Am I clear ?   Sometimes it is not easy for me to explain the things
    correctly in English...
    
    Manu.
    to start on SYSTEM-2

    Seems to me that a cleaner alternative would have been to do
    your own umount/mount in the start script - tell ase that
    the mount point is NONE.  You can do all kinds of fancy stuff
    in the start and stop scripts... but do it to the local node
    only.
    
    d

    Dave,
    
    The user defined start script run after ASE tries to mount its
    service defined mounts.  Thus, the NFS /data mount on system-2
    (using Manu's diagram in .12) will not be unmounted when ASE tries
    to mount the local disk onto /data.  Due to this the start will fail.
    
    -- Greg

    This is all great stuff and I get the picture of what's happening in
    the background but my problem is that I haven't a clue on how to write
    START/STOP scripts to all of this!  I would like to do the same thing
    that Clare and Manu seem to want to do.  That is, have scripts that
    work to unmount and delete the mount point for an NFS service on
    member-2 so that if member-1 should die, ASE can create a link and
    mount the service locally.
    
    Are there any examples of how to do this anywhere?
    I don't see them in the manuals I have. 
    
    -Tony