Simple reversed http check

===

> 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

> SO am looking for ways to use , for example, a scripted monitor. Soms some form of expect, so this could be an alternative. Do I have ip address of the node/poolmember available in there?

I have been working in Support for 7 years, and have never looked at scripted monitors.

Nothing I have seen leads me to believe that it supports anything more than send/expect commands - ie they do not support the full range of TCL scripting available in expect.

> I'm still a bit worried about possible performance impact when using this on al larger scale.

All you can do is scale it up and monitor - keep the check intervals large.

Irule triggers exist in the context of connections through a virtual server. Irules do not trigger for monitors which are managed by an external (to traffic processing) process called bigd.