Is it possible to get response time of node?

No problem on the questions, that is what we are here for B-).

 

 

Q1. Is it possible to get response time of node using iControl SDK?

 

 

I want to display node status as good or bad.

 

If response time is short, node status may be good. If not, it may be bad.

 

I can only know the information of connection, bits in out, packets in out about node. Hmm, right? Any other idea?

 

 

I saw a demo program F5 network. At there I saw node status displayed as good or bad. I want to do, too

 

 

It is not possible to retrieve the response time as a metric from either the SDK, the GUI, or the command line. Our packet processing uses this value to determine load balancing in the "Fastest" lb modes. What you are referring to for the state is probably just the ITCMLocalLB::Node::get_availability() method that returns AVAILABILITY_UP or AVAILABILITY_DOWN depending on whether or not the node is available for load balancing. ITCMLocalLB::Node::get_state() is another method you can check and that one returns whether or not the Node is being included in lb decisions (STATE_ENABLED) or not (STATE_DISABLED).

 

 

 

Q2. ITCMGlobalLB.BaseServer.get_server_availability returns StatColor.

 

Does StatColor mean that server state is good or bad. STAT_BLUE is good and STAT_RED is bad?

 

 

Looks like the comments for those in the SDK are missing. We'll get that corrected in the next version. Here's the breakdown:

 

 

 

STAT_BLUE : 0 : No contact (meaning 3-DNS hasn't attempted contact)

 

STAT_GREEN : 1 : Up and running (A-OK).

 

STAT_YELLOW : 2 : Admin out-of-service (Disabled by admin intervention)

 

STAT_RED : 3 : Down. (Cannot connect to server).

 

STAT_GRAY : 4 : Not in our control.

 

STAT_PURPLE : 5 : Not used

 

STAT_ORANGE : 6 : Not used

 

STAT_WHITE : 7 : Not used

 

 

 

Q3. At Q2, "server" means BIG-IP machine or virtual server?

 

 

"server" represnts a BIG-IP, another 3-DNS, or a host system. Virtual Servers in 3-DNS are similar to Virtual Servers in BIG-IP, they are just virtual IP's.

 

 

-Joe

Does it mean that node is disconnected or disable for load balancing?

The ITCMLocalLB::Node::set_availability() with AVAILABILITY_DOWN and AVAILABILITY_UP is an admin function used to control whether traffic gets routed to the nodes. This is set either in the GUI, CLI or iControl. It is independent on the current traffic characteristics or performance of the node.

 

 

By calling ITCMLocalLB::Node::get_availability() you can determine the current state of the node with regards to load balancing decisions. These values are determined from a combination of routing and monitor reporting.

 

 

The following Availability states can be returned (these are documented in the SDK):

 

 

AVAILABILITY_UNCHECKED 0 The node has not been checked for availability.

 

AVAILABILITY_DOWN 1 The node is not available.

 

AVAILABILITY_UP 2 The node is available.

 

AVAILABILITY_CHECKING 3 The node is currently being checked for availability.

 

AVAILABILITY_FORCED_DOWN 4 The node has been forced down manually.

 

AVAILABILITY_ADDR_DOWN 5 The node address for a node server is down.

 

AVAILABILITY_UNKNOWN 6 An unknown, undecipherable state has been received for the node.

 

AVAILABILITY_MAINT 7 Maintenance mode.

 

AVAILABILITY_ENABLED 8 The node is enabled.

 

AVAILABILITY_DISABLED 9 The node is disabled.

 

AVAILABILITY_ADDR_DISABLED 10 The node address is disabled.

 

AVAILABILITY_PORT_DISABLED 11 The node service is disabled.

 

 

So, to specifically answer your questions:

 

 

Q: If traffic is heavy on a specific node, does the node state go to AVAILABILITY_DOWN?

 

 

No. If the node is reachable from our traffic load balancing, the state will be AVAILABILITY_UP. If the bandwidth exceeds the capability of the node and BIG-IP has no more nodes in the pool to load balance to, then the connections will be queued up and then eventually if that queue becomes too large the connections will be dropped.

 

 

Q: If the node is available for load balancing, can I say that the node status is good? Otherwise if the node is not available, can I say the node status is bad?

 

 

Yes. If the states are STATE_ENABLED and AVAILABILITY_UP, then the node is in good shape. Otherwise traffic will not be routed to it.

 

 

Q: With AVAILABILITY_DOWN and AVAILABILITY_UP, can I display node status as bad and good?

 

 

Again, it is a combination of AVAILIBILITY_UP and STATE_ENABLED.

 

 

Hope this helps...

 

 

-Joe

I'm not sure I understand your question? I'll take a shot at it and if I am not on the right track, let me know.

 

 

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.

 

 

-Joe

If traffic is heavy on a specific node, does the node state go to AVAILABILITY_DOWN?

 

 

If the node is available for load balancing, can I say that the node status is good? Otherwise if the node is not available, can I say the node status is bad?

 

 

With AVAILABILITY_DOWN and AVAILABILITY_UP, can I display node status as bad and good?

ITCMLocalLB::Node::set_state(STATE_DISABLED) allows current connections to stay connected, but stops the node from accepting new connections.

 

 

Does "STATE_ENABLED" mean that additional connections are possible on node correctly?

 

 

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.

 

 

Does "AVAILABILITY_UP" mean that node can accept traffic (packets and bits)?

 

 

"enable" and "available" meanings are not clear to me :-(

 

 

Your comment is very helpful. Thank you for your kindness.

 

 

Best Regards,

Q: Does "STATE_ENABLED" mean that additional connections are possible on node correctly?

 

 

Yes. As long as new connections don't exceed the connection limit imposed on the node. The default for this is "0" which means no limit. If the limit is reached then the state will still be STATE_ENABLED but no new connections will be routed to the node until the current connection counter is lowered below the connection limit.

 

 

Q: Does "AVAILABILITY_UP" mean that node can accept traffic (packets and bits)?

 

 

Yes.

 

 

-Joe

Actually,

 

 

I think it's a bit more complex than fast response time is good and slow response time indicates a problem. An example to illustrate:

 

 

You have a pool of 10 servers. You are using fastest response (I prefer observed) for load balancing between them. You are not using anything other than basic monitors to determine if a node is available. The page weight of your index page in the doc root is 60k.

 

 

One of your servers has gotten foosed (that's a technical term) and is returning a 500 response. What happens?

 

 

The answer is that you will be serving a lot of bad pages very fast. In this scenario the Bigip will send more traffic to the bad node than to the good nodes. The same thing would happen if you were serving a 404 from one of the servers. Bigip will show all the nodes as up and available even though you are not properly serving the customer.

 

 

The other metric that might be of interest is the ratio of bits in to bits out for each node in a pool. The ratio should be roughly the same for each node (even if the absolute numbers vary because a node was temporarily out of service). We pull the data off the Bigip (to minimize load) and do some massaging to alert on variations outside of defined parameters. It's not perfect but we get very few false positives and do catch problems fairly quickly.

 

 

Dotzero

Great point. The response time either lower or higher can be good depending on the situation.

 

 

-Joe