[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::ase

Title:ase
Moderator:SMURF::GROSSO
Created:Thu Jul 29 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2114
Total number of notes:7347

1938.0. "ASE_PARTIAL_MIRRORING only during startup?" by DOOSJE::HERTA (For something fulfilled this hour, loved, or endured) Tue Mar 11 1997 11:27

Re:1501.0 Peter Flack
>                        I thought that ASE_PARTIAL_MIRRORING was ONLY used
>    during the startup of a service - I was told by a senior support
>    engineer that it also has the effect of attempting to relocate a
>    service to the other system if a plex on a mirrored volume goes "out to
>    lunch"!

The replies to the topic indicated that Peter's problem at the time had nothing
to do with ASE_PARTIAL_MIRRORING, but there was no negation or confirmation of
the above statement.

Could someone in engineering please comment?

Herta
T.RTitleUserPersonal
Name
DateLines
1938.1It is wrongANNECY::CHABORD_DDominique CHABORD @AEOTue Mar 11 1997 14:5811
    
    The tests we performed showed that stopping on line disks has no
    effect on services whatever the flag value is. Only a script is
    activated.
                                                 
    The flag is global to a server (not a service) and only considered at
    startup time.
    
    It would be useful an engineer blesses this answer and tells us if it
    can change in future releases.
              
1938.2You are correctNETRIX::"myrdal@zk3.dec.com"Gregory P. MyrdalWed Apr 02 1997 15:1347
Sorry for the delayed answer on this topic.

Yes, ASE_PARTIAL_MIRRORING is only used at the start of a service.  There
might be some confusion here, as the original shipment of ASE looked at this
variable when the service was running.  This was changed by me, I think in
version V1.2.  We do not look at this variable any longer when a service is
running.

I took a quick look at note 1501 and at Doug's reply.  I think Doug hit the 
nail on the head with his evaluation.  The lsm_lv_action script timed out
trying to determine if the failure of a disk should cause a relocation of
the service.   ASE_PARTIAL_MIRRORING had nothing to do with this service
stop.  It "appears" that we timed out faster than lsm_lv_action could come
back with a response or there was something wrong in the system which caused
its delay.  If this needs to be fixed in a future release then we need to
see a QAR filed.  

For those not understanding this variable, here is a quick explanation.

The ASE_PARTIAL_MIRRORING rcmgr variable is set per member.  ASE uses this
variable to determine if it should start a service in which not all of its
plexes are good.  

If a service is runing and a disk which serves as a plex to
a LSM volume goes bad, ASE does not (and should not) look at this variable
to see if the service should continue to run.  This is why we set up the LSM
mirroring in the first place.  ASE does run the lsm_lv_action script to 
determine if the service should be relocated just as we would if this was
the only disk in the service.  If this disk is only assicated with plexes
of LSM volumes we allow the service to continue to run without disruption.  

The time in which ASE looks at this variable is when a service starts.  If a
service is starting and a service has "bad" disk, ASE runs the lsm_lv_action
script to determine if it should start the service.  If the bad disk only
effects plexes of volumes in that service, the ASE_PARTIAL_MIRRORING value
tells ASE if the service should be started or not.  The conservative and
shipped value of this variable is off.  If the disk is indeed really bad,
then there is no harm in starting the service.  However, if the disk can
not be seen by the starting member due to a scsi problem and other systems
can indeed see the disk we might introduce a problem.  Only the admin can
tell this situation so we allow them to tell us through this variable.

I hope this help more than it confuses.

-- Greg
[Posted by WWW Notes gateway]
1938.3BACHUS::DEVOSManu Devos DEC/SI Brussels 856-7539Wed Apr 02 1997 18:454
    Thanks Greg to confirm what I already explained to   Herta...
    
    Manu
    
1938.4thanks gregUSCTR1::ASCHERDave AscherThu Apr 03 1997 15:467
Greg,
    
    Many many thanks for clearing that up. The little historical
    note about when the change happened was particularly helpful
    to me.
    
    d