Changes between Version 7 and Version 8 of ServiceOperationalBehaviors


Ignore:
Timestamp:
05/22/11 17:24:21 (3 years ago)
Author:
digimer
Comment:

Fixed the last copy from the old wiki to work on the new Trac syntax.

Legend:

Unmodified
Added
Removed
Modified
  • ServiceOperationalBehaviors

    v7 v8  
    1 These are default behaviors when using classic mode and out-of-the-box {{{central_processing}}} mode. 
     1[[TOC]] 
     2 
     3These are default behaviors when using classic mode and out-of-the-box {{{central_processing}}} mode.  These operations apply to both services and virtual machines, except for the '''migrate''' operation, which only works with virtual machines. 
    24 
    35=== Service Operations === 
     
    79 * '''stop''' - stop the service and place into the ''stopped'' state.   
    810 * '''migrate''' - migrate the virtual machine to another node.  The administrator must specify a target node.  Depending on the failure, a failure to migrate may result with the virtual machine in the ''failed'' state or in the ''started'' state on the original owner. 
     11 * '''convalesce''' - restart any stopped non-critical subtrees of the given service. 
     12 
     13There are also two specific operations and behaviors noted on the ServiceFreeze page. 
    914 
    1015=== Service States === 
    11  * '''disabled''' - The service will remain in the ''disabled'' state until either an administrator re-enables the service or the cluster loses quorum (at which point, the ''autostart'' parameter is evaluated). 
    12  * '''failed''' - The service is presumed dead.  This state occurs whenever a resource's ''stop'' operation fails.  Administrator must verify that there are no allocated resources (mounted file systems, etc.) prior to issuing a ''disable'' request. 
    13  * '''stopped''' - When in the ''stopped'' state, the service will be evaluated for starting after the next service or node transition.  This is a very ''temporary'' measure. 
     16 * '''disabled''' - The service will remain in the ''disabled'' state until either an administrator re-enables the service or the cluster loses quorum (at which point, the ''autostart'' parameter is evaluated).  An administrator may ''enable'' the service from this state. 
     17 * '''failed''' - The service is presumed dead.  This state occurs whenever a resource's ''stop'' operation fails.  Administrator must verify that there are no allocated resources (mounted file systems, etc.) prior to issuing a ''disable'' request.  The only action which can take place from this state is ''disable''. 
     18 * '''stopped''' - When in the ''stopped'' state, the service will be evaluated for starting after the next service or node transition.  This is a very ''temporary'' measure.  An administrator may ''disable'' or ''enable'' the service from this state. 
    1419 * '''recovering''' - The cluster is trying to recover the service.  An administrator may ''disable'' the service to prevent recovery if desired. 
    15  * '''started''' - If a service status check fails, recover it according to the service recovery policy.  If the host running the service fails, recover it following failover domain & exclusive service rules. 
     20 * '''started''' - If a service status check fails, recover it according to the service recovery policy.  If the host running the service fails, recover it following failover domain & exclusive service rules.  An administrator may ''relocate'', ''stop'', ''disable'', and (with virtual machines) ''migrate'' the service from this state.  Services with failed non-critical subtrees will also have a {{{P}}} flag ("partial"). 
    1621 
    1722Note: Other states (starting, stopping, ...) are special cases of the ''started'' state.