Forum Discussion
Tuckson
Altostratus
AltostratusSimple reversed http check
Hi, As first, I am aware similar questions have been asked often and for years now. However, somehow the answers I found tusfar don't satisfy me, so I'll try my own question :-) We run hu...
Simon_Blakely
Employee
Employee> We run hundreds of servers in big numbers of pools on our F5. Our networking department disallows usage of api's, however they want to coöperate in the following:
Using a script and the iControl RestAPI is by far the easiest way to control node availability.
> I define a healthcheck template that checks a page which is the nodename.
You mean you have a single node that provides an appropriate response as to whether a specific node should be available or not?
You would have to do that using a custom external monitor.
If every node had a page (the same page on all nodes) that reported whether it should be enabled or disabled then it might be easier.
K71282813: Overview of BIG-IP EAV external monitors
> Now I would like to know if the nodename is available a as default variable for a monitor?
The NODE_NAME is set as an environmental variable for external monitors
> Also, can I achieve this without using an external monitor? Since there are 100's of members, the extra resource penalty might add up.
Not the way you describe it, and yes - you would be running the external monitor for all nodes, which would be a real performance drain.
If you had a standard http monitor that probed every node to flag whether is should be enabled or disabled, you could use the log messages (via alertd) to trigger an icall script that enables/disables the node.
TucksonAltostratus
Altostratus===
> You mean you have a single node that provides an appropriate response as to whether a specific node should be available or not? You would have to do that using a custom external monitor.
===
The whole idea relies on the use of healthchecks on the F5. There are different forms of health checks. The most basic one is just checking if a listener port is available. If not, node disabled. If so, node enabled.
However a more advanced check is also possible in which a send string is defined en a receive string is captured which can be used to enable or disable a node. We want to make use of this feature.
The idea is that every node in an F5 vip has 2 diffferent healthchecks.
1) The regular Port availability check.
Is the port down then the node must be disabled. If the port comes up, the node should be enabled after a little while.
Suppose we have a VIP1, which contains 2 nodes, ServerA and ServerB (see picture below).
Normally, ServerA and ServerB are running and the VIP is up. Whenever 1 of these 2 servers comes in trouble and the port is no longer available, the port availability check sees so and disables the node in VIP1.
2) The http check.
Inside the environment we run a webserver (listens on port 8000). Let's call it ServerX. This webserver bij default returns a 404 status (page not found) on every request
When we as engineers intentionally want to disable a node, we will let the webserver respond a status 200 to a request with the node's name.
So per example:
ServerA listening on port 8080 is placed in VIP1 on the F5 with 2 healtchecks. The port availability check and the http check. So is ServerB
Now the port availabilty check just checks ServerA:8080
The httpcheck however, sends it's request to http://serverX:8000/ServerA
If a status 200 is returned, the F5 DISABLES ServerA in VIP1. If ANYTHING ELSE is returned the F5 ENABLES ServerA in VIP1.
For ServerD in VIP2, the same principle goes. Suppose the server listens on port 51243
Now the port availabilty check just checks ServerD:51243
The httpcheck however, sends it's request to http://serverX:8000/ServerD
If a status 200 is returned, the F5 DISABLES ServerD in VIP2. If ANYTHING ELSE is returned the F5 ENABLES ServerD in VIP2.
The idea behind this reversed check (enabling on an error status) is that failures involving the webserver itselves should not lead to disabling nodes.
Now, by being able to pass the nodename as a variable, there is no need to define the check specifically for each node.
Ow, and I do not have acces to the restapi
- Simon_Blakely
So ServerX:8000 is the node availability check - you probe serverX:8000 with the node-name to see if the node should be enabled or disabled.
You would need a single external monitor applied to all the nodes that gets the NODE_NAME from the execution environment, and makes the probe, and then marks the node down based on the response code.
Doable, but possibly a resource drag.
I can't see a way to use a standard monitor to do this.