VMware Cloud Community
CristiCalin
Contributor
Contributor
Jump to solution

Console proxy health check with F5

I'm trying to setup console proxy load balancing with F5 BigIP  and when doing health check on the console according to the documentation, the pool says it's offline.

From what I understand the F5 behavior, it's doing a curl on the /sdk/vimServiceVersions.xml and looking for a text. I've run this command from the F5 system and the output is an XML which I get when I open the console proxy address from Internet Explorer or Firefox, however the F5 considers it is not OK and declares the pool offline.

When using TCP health check the check is polluting the vCD logs and I'm not sure this is absolutely correct since you could have the TCP port open but the service not yet ready.

According to the vCAT 3.1 the correct way is to check the /sdk/vimServiceVersions.xml url on the console proxy. Has anyone deployed the vCD in this scenario and got it to work ?

Thanks,

Cristian

1 Solution

Accepted Solutions
ChrisElsen
Contributor
Contributor
Jump to solution

Hi,

Please use these settings for the "Send String" and "Receive String":

"Send String": GET /sdk/vimServiceVersions.xml HTTP/1.1\r\n\r\n

"Receive String": urn:vim25

I'll post later on explaining how I ended up with these setting. vCD wasn't making it easy.

In a nutshell: it only accepts strict HTTP/1.1 requests and it's very anal about new lines.

But I just verified that it works with these settings.

Give it a try and many thanks for pointing out this shortcoming of my instructions. Really appreciate it.

Chris

View solution in original post

0 Kudos
6 Replies
MTw
VMware Employee
VMware Employee
Jump to solution

Christian, did you try http://<cell.hostname>/cloud/server_status as Send String?

Pretty good explanations are here Using F5 to balance load between your vCloud Director cells - Yellow Bricks and http://edge-cloud.net/2013/05/configuring-f5-big-ip-with-vcd/


Cheers, Michael

0 Kudos
CristiCalin
Contributor
Contributor
Jump to solution

I already had a look at both articles before asking here.

The problem is not the http interface which works fine (the /cloud/server_status is only available on the http interface and not on the console proxy).

Duncan (YB) sugests to use the /sdk/vimServiceVersions.xml but it does not work at least no on my F5 systems and Christian (edge-cloud) uses a simple tcp check which has the downsides I just mentioned above: log polution and improper health detection.

0 Kudos
ChrisElsen
Contributor
Contributor
Jump to solution

Hi Cristian,

I have to admit that I completely ignored the fact that with the standard F5 TCP monitor the vCD cells log files are polluted. That's cause I'm usually ignoring these log files given the usefulness of most of the log messages in it...

But you raise a very valid point: If we can monitor availability with the F5 through the SDK method, without polluting the log files we should do so. Challenge accepted! 🙂

The F5 doesn't actually do a curl on the provided URL, but instead connects to the provided ports and sends the string within the "Send String" field and expects to see what is entered in the "Receive String". That makes the method more generic to be used with most plain text based services, as you can also monitor a service such as e.g. SMTP.

With HTTP one could connect via telnet to the given port and just type (or better copy&paste) the "Send String" to see what the server returns.

But with HTTPS that doesn't work anymore as you need to encrypt the traffic now. On Linux you would therefore use e.g.

openssl s_client -connect cell01.edge-cloud.net:443

then watch the ssl certificate details scroll by and finally enter:

GET /sdk/vimServiceVersions.xml HTTP/1.1
Host: cell01.edge-cloud.net

<new line>

As we are simulating an HTTP client (web browser) this way, the expectation would be to receive the actual XML file back. Because that's what happens if we type https://cell01.edge-cloud.net/sdk/vimServiceVersions.xml into the browser.

But instead we get back read:errno=0, which means that the connection times out. That isn't that useful at all. It only shows that the console proxy isn't behaving like a regular web server.

I need to have a look at the communication between a browser and the URL above to see what's going on there. Then we can build a "Send String" and corresponding "Receive String" and build a custom monitor for the Console Proxy on the F5. As it's SSL encrypted that will take me a tiny bit longer.

Give me a few days to look into this and I'll update you and my original post at http://www.edge-cloud.net/2013/05/configuring-f5-big-ip-with-vcd/ with that method.

Hope that helps.

Chris

ChrisElsen
Contributor
Contributor
Jump to solution

Hi,

Please use these settings for the "Send String" and "Receive String":

"Send String": GET /sdk/vimServiceVersions.xml HTTP/1.1\r\n\r\n

"Receive String": urn:vim25

I'll post later on explaining how I ended up with these setting. vCD wasn't making it easy.

In a nutshell: it only accepts strict HTTP/1.1 requests and it's very anal about new lines.

But I just verified that it works with these settings.

Give it a try and many thanks for pointing out this shortcoming of my instructions. Really appreciate it.

Chris

0 Kudos
CristiCalin
Contributor
Contributor
Jump to solution

Thanks, that worked like a charm.

One more recommendation I got from F5 support was to also add "Connection: Close" in the Send String so the end result looks like this:

GET /sdk/vimServiceVersions.xml HTTP/1.1\r\nConnection: Close\r\n\r\n

0 Kudos
ChrisElsen
Contributor
Contributor
Jump to solution

Glad to hear that it works for you.

I have also updated my post at http://www.edge-cloud.net/2013/05/configuring-f5-big-ip-with-vcd/ with the revised information.

Again, many thanks for pointing out the log file pollution issue.

Chris

0 Kudos