Hi all,
Originally I thought this was a bug, but now I think it is working as intended.
I am sharing my findings in case anyone else has been confused/surprised by
this behavior. If you already understand Alive/HAport functionality, please
read my summary below.
Please see attached file for configuration example, just update the listener
and BackEnds with real IP addresses or FQDNs.
Pound version = 2.5
Steps to recreate:
- Have at least two BackEnds
- Have at least one listener
1) Stop Pound
2) Have one BackEnd in a known "dead" state. Example: just stop Apache or IIS
so it won't be accepting any connections
- In my example, 192.168.x.x is in an dead state
3) Have the other BackEnd up and running accepting connections
- In my example, 192.168.x.y is in an Alive state
4) Start Pound
- Using poundctl, notice that both BackEnds are marked 'Alive'
5) Wait 'Alive' seconds
- Notice that after Alive seconds the dead BackEnd is NOT marked as
dead.
- This can be verified using poundctl or by checking your logfiles
6) Issue a GET to your Pound listener
- http://192.168.x.z
7) Run poundctl
- Notice that the dead BackEnd is now marked as dead
- When I made the request I saw this:
Apr 7 18:28:31 192.168.x.z pound: (414d5940) BackEnd
192.168.x.x:80 connect: Connection refused
Apr 7 18:28:31 192.168.x.z pound: (414d5940) BackEnd
192.168.x.x:80 dead (killed)
8) Start the BackEnd, 192.168.x.x
9) Using poundctl or tail your logfile to see that after 'Alive' seconds the
BackEnd is resurrected
In Summary:
Pound is NOT actively checking for dead BackEnds, unless you use the HAport
parameter. The Alive parameter is "how often Pound will check if a DEAD BackEnd
is now ALIVE", not "how often Pound will check if an ALIVE host is DEAD". This
means, Pound is only aware a BackEnd is Dead when 1) HAport is used or 2) In
realtime when the connection fails to the BackEnd. Makes sense now after
working through the example and writing this email. I can appreciate the
advantages of separating the functionality into two parameters.
However, I will disagree with the documentation as it was misleading and
initially uninformative.
Quote: "It never makes sense to have the HAport identical to the main back-end
port: this would only generate extra, unncecessary activity (CPU, network
traffic) for no good reason whatsoever."
Saying this, just like saying "...using a RootJail directive is only for extra
security bonus points" is not necessary. In fact, some uninformed users might
shy away from these features by *almost* baseless comments like this. Please
consider removing these non-technical comments or revise them to be more
useful. Such as why performance would be affected.
I haven't measured the load generated from a single TCP (SYN, SYN-ACK, ACK)
packet every 'Alive' seconds, but I bet its negligible on today's modern
hardware. The most simple check is pointing the HAport at the BackEnd port. I
understand HAport should be driven by a complex script/application checking for
other error conditions, but if a BackEnd isn't even listening, Pound should be
aware in 'Alive' seconds. Knowing that a BackEnd is dead in 'Alive' seconds is
useful. Otherwise, one might not know the Backend is dead until a request is
made. During slow periods of the day it may be possible that a BackEnd could be
down for a long time before a request is made. This means that reacting to the
failure is delayed for no good reason. Let's say the Administrator is alerting
against the output of "poundctl -X" and pound is NOT using the HAport
parameter. The keyword "dead" will only appear when a request fails for a
BackEnd. As mentioned previously this could have been minutes or h
ours since the last request and the entire time there was no alerting because
Pound was reporting "Alive".
Thanks for listening,
- Chris
________________________________
This e-mail message, including any attachments, from Verrus Mobile Technologies
Inc. or Verrus UK Limited (collectively, "Verrus") is confidential and for the
personal use of the recipient(s) identified above. This message may also be
legally privileged. If it is not intended for you, do not disclose, copy or
distribute the message but delete it immediately and notify the sender by
e-mail or telephone +1 866 783 7787 or +44 1453 760000 (UK).
Any views or opinions expressed in this message are those of the author and not
necessarily those of Verrus. The message shall not form part of any legally
binding contract or obligation.
Verrus electronic communication systems are monitored without user consent to:
investigate or to detect unauthorized use; prevent or detect crime; establish
the existence of facts relevant to Verrus; or ascertain compliance with
regulatory practices relevant to the business of Verrus.
This e-mail has been scanned for viruses by a third party e-mail management
provider. Verrus cannot accept liability for any damage which you may suffer as
a result of virus infection. We recommend that you carry out your own virus
checks before opening any attachment.
--
To unsubscribe send an email with subject unsubscribe to [email protected].
Please contact [email protected] for questions.
