I have been looking into the CSM return code checking feature as suggested by this forum. This is a little closer to what I am looking for but I have question about what happens when there is a failure.
If a 500 code for HTTP is seen three times, for example, and the server is removed from the farm, is the original request from the client tried on the next server? Or is a reset sent back to the client, or the original code, and the client must try again.
I am trying to understand if the client will notice if the CSM noticed X number of a particular error and removed the server from the farm.
Actually no I am not talking about the probes. Sorry for the confusion. On the CSM there is in-band monitoring of the HTTP codes being returned to the client. Documentation says that I can set a threshold and if so many of a particular code is seen the CSM can either remove that server from the rotation of the farm or send a syslog event.
My question is that if the server is removed from the farm due to meeting that threshold, will the client notice that it has been moved to another server? In other words, will CSM retry the original request on the next server in the farm?
I think you are mixing two things up(Inband health monitoring & HTTP return code checking).
The "Inband health monitoring" feature checks for both RSTs from a server and the failure of the server to respond to a SYN. If a SYN ACK response to a SYN is not received,the TCP portion of the code will perform several retries of a SYN before timing it out.
It is configured as follows
CSM(config-module-csm)# serverfarm xyz
CSM(config-slb-sfarm)# health retries 10 failed 50
(Retries are the number of abnormal end sessions that the CSM will tolerate before removing a real server from service. The failed time is the number of seconds that the CSM waits before reattempting a connection to a real server that was removed from service by inband health checking.)
"HTTP Return Code checking" is the CSM feature that can be configured to take a server out of use in response to receiving specific return codes.
When HTTP return code checking is configured, the CSM monitors HTTP responses from all balanced HTTP connections and logs the occurrence of the return code for each real server. The CSM stores return code counts. When a threshold for a return code is reached, the CSM may send syslog messages or remove the server from service.
Unlike "Inband Health monitoring", "Http Return code checking" feature has a small (estimated in 10-15%) impact on CPS setup rate, since it requires parsing L5 information in the server-to-client direction.
If the server is taken out of service, Client's request will be loadbalanced among available servers.
So, the client will receive the server response - whatever it was. Then the CSM will decide to remove the server if the threshold was reached and only the next request from the client will be sent to a new server.
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...