Forum Discussion

Joe_Pruitt's avatar
Sep 21, 2004

How to take down a node...

This question has come up several times since the release of 9.0 so I thought it warranted a post here. The question is about the new methods call that were previously set_state (traffic or no traffic) and set_availability (new sessions, no new sessions). Here's the results directly from the developer who implemented the features:

 

 

In v9.0, for both LocalLB::NodeAddress and LocalLB::PoolMember, the following rules apply:

 

 

- set_session_enabled_state - sets the state that determines whether to allow new sessions to be established. If disabled, this allows current connections to stay connected, but stops the node from accepting new connections. This corresponds to the set_state method in 4.5x.

 

 

- set_monitor_state - sets the availability state, i.e. UP/DOWN. If disabled, this immediately performs a forced-down to all node addresses/pool members.. This basically stops all traffic (including persistent connections) from being sent to the node addresses/pool members. This corresponds to the set_availability method in 4.5x.

 

 

- get_session_enabled_state returns the state (enabled/disabled) that we set in set_session_enabled_state, but to get the true computed/propagated status of that operation, get_session_status should be called. Note that the SessionStatus enum returned by get_session_status has more than just the enabled/disabled status.

 

 

For example, if you call NodeAddress::set_session_enabled_state (10.10.10.100, disable), calling PoolMember::get_session_status (pools), where pools contains member 10.10.10.100:80, will return a SessionStatus of SESSION_STATUS_ADDRESS_DISABLE, even though PoolMember::get_session_enabled_state might return an Enabled state for that pool member.

 

 

The same thing applies to set_monitor_state, i.e. you call this method to set the availability for the object, but you'll need to call get_monitor_status to get the actual availability status

 

 

-Joe

2 Replies

  • Hi,

     

     

    I was looking for exactly this info, so thanks for the post... My only question is on checking the status after the call to set_monitor_state(). (Yes, I know it's an old post...)

     

     

    For the set_monitor_state() call, I need to send an enum of EnabledState, STATE_ENABLED or STATE_DISABLED. I want to check the status after the call to check for success. When I call get_monitor_status() with my array of IP addresses, I get a MonitorStatus enum return... Can I assume that any return other than MONITOR_STATUS_UP is a successful call to set_monitor_state( STATE_DISABLED ), and vice versa?

     

     

    Thanks in advance for the help...

     

     

    Jim Novak

     

    jnovak@visicu.com
  • Jim,

     

     

    You can assume that if you did not get a SOAPFault back on the request with an appropriate error code, then the call succeeded so you shouldn't have to code a check to verify that fact.

     

     

    As for your question about states, it will never be MONITOR_STATUS_UP when you call with STATE_DISABLED. Disabling an object will never (as far as I know) enable that object.

     

     

    With that being said, the monitor_status is a tricky beast becuase it can have multiple values after your call with STATE_ENABLED.

     

     

    Here are the values of the MonitorStatus enum

     

     

    MONITOR_STATUS_UNCHECKED - Status of an enabled object that is not being monitored.

     

    MONITOR_STATUS_CHECKING - Initial status of a object until its monitors report.

     

    MONITOR_STATUS_UP - Status of an enabled object when its monitors succeed.

     

    MONITOR_STATUS_DOWN - Status of an enabled object when its monitors fail.

     

    MONITOR_STATUS_FORCED_DOWN - Status of a object when it's forced down manually.

     

    MONITOR_STATUS_MAINT - Status of an object when in maintenance mode.

     

    MONITOR_STATUS_ADDRESS_DOWN - Status of an object whose node address monitor fails.

     

     

    If you make a call to set_monitor_status() with STATE_DISABLED, it will result in a MONITOR_STATUS_FORCED_DOWN status.

     

     

    If you call it with STATE_ENABLED, it's value can be one of the other values depending on the status of the monitor subsystem (whether you have monitors attached to the pool member, whether they have failed, whether the node address is down, etc). So, calling with STATE_ENABLED doesn't necessarily mean that the status will be MONITOR_STATUS_UP. It will only be MONITOR_STATUS_UP if it is enabled AND all the attached monitors succeed. STATE_ENABLED just tells the montior subsystem that it can do it's work as usual.

     

     

    Make sense???

     

     

    -Joe