enable/disable vs up/down

I sent the earlier message too soon. I wanted to add the following question as well.

 

 

5. After setting a virtual server or node to a disabled state, I want to check on if the ongoing connections have finished. It seems getting the statistics and checking for the number of current connections to be zero is one way to do it. Is that the right way?

 

Thanks,

 

Karthic.

the set_availablity() method should be used to "bleed" connections from a node. This means that no NEW connections will be processed to that server. This equates to the "Enable/Disable Sessions" option in the GUI. From the GUI docs:

 

 

If sessions are disabled, no new sessions can be sent to the node. Clients with persistent connections remain connected to the node and can start new sessions until they timeout based on the persistens setting for the pool the node is a member of.

 

 

The set_state() method is used to sever all connections to a back end server. Again, from the GUI docs.

 

 

If connections are disabled, no traffic can be sent to the node. This is a Forced Down state. To take the node down without interrupting current client sessions, set the availablility to disabled. Once all traffic has timed out from the node, disable connections to stop all further traffic to the node

 

 

As for determining the traffic a node is receiving, you should use the current connections in the connection statistics and monitor this until the count reaches zero after you have set the availablitity to disabled.

 

 

-Joe

Joe,

 

In your reply, should set_state() and set_availability() swap places?

 

 

When you say GUI docs, I take it you mean the documentation that pops up when we click on the “help” icon on the configuration utility GUI. Right?

 

 

Anyway, I looked at that documentation and I have a follow-up question:

 

When I call set_availability() with “Down” to set the state to “forced down”, are current TCP connections severed too? I thought only new connections would not be sent to the node. Am I wrong?

 

 

Thanks,

 

Karthic.

Joe,

 

I don't mean to harp on this point....but, when I call set_state() with "Disabled", the "Enable Sessions" box becomes unchecked. When I call it back with "Enabled", the "Enable Sessions" box becomes checked. Is that consistent with your explanation? I think not.

 

 

Also, the GUI docs has "If connections are disabled, no traffic can be sent to the node", do they mean "no new traffic"? I.e. doesn't BIG-IP continue to send traffic pertaining to existing connections to the node??

 

 

Thanks,

 

Karthic.

I think I got it right in my response. set_availability() corresponds to the "Enable Sessions" in the GUI. The set_state() corresponds to the "Enable Connections" in the GUI.

 

 

"Enable Sessions == get/set_availability()

 

If sessions are enabled, the BIG-IP sends traffic to the node as usual based on the load balancing method you chose. If sessions are disabled, no new sessions can be sent to the node. Clients with persistent connections remain connected to the node and can start new sessions until they timeout based on the persistence setting for the pool the node is a member of.

 

 

Enable Connections == get/set_state()

 

If connections are disabled, no traffic can be sent to the node. This is a Forced Down state. To take the node down without interrupting current client sessions, leave the Enable Connections box checked and clear the Enable Sessions box. Once all traffic has timed out from the node, clear the Enable Connection check box, stopping all traffic to the node."

 

 

And, yes, when I say GUI docs, I refer to the online help when accessing the product via the GUI administration.

 

 

As for your follow-up Q? Calling set_availbility() with AVAILABILITY_DOWN will cause all new connections to be routed to another node in the pool. Current or persistent connections will continue to be routed to that given node.

 

 

-Joe

By all means, please harp. In this case I'm glad you did as I had the actions reversed. I just verified this with the developer who wrote the code and it matches with what you are seeing.

 

 

ITCMLocalLB::Node.set_availability(AVAILABILITY_DOWN) immediately performs a forced-down to all nodes connected to the disabled node. This basically stops all traffic (including persistent connections) from being sent to the node. This maps to the GUI's "Enable Connections" checkbox being unchecked.

 

 

ITCMLocalLB::Node::set_state(STATE_DISABLED) allows current connections to stay connected, but stops the node from accepting new connections. This maps to the GUI's "Enabled Sessions" checkbox being unchecked.

 

 

I appologize for the confusion.

 

 

-Joe