Josip Rodin wrote:
Returning to the original problem, in my pool of two fail-over home servers I now have both of them set up with "status_check = none".
2.1.7 has some changes in proxy fail-over. The *first* packet that discovers that a home server is dead is no longer rejected. Instead, it fails over to the second home server. This makes proxying more robust.
My upstream proxy maintainers refuse to implement decent status checks, so I'm forced to do this for now. I can do a status check with an entry from a particular HL RADIUS that I happen to control, but that just creates a daisy-chain of SPoFs. :/ They insist that I not do anything like this, but that I set up my server so that it stubbornly tries their first server, then if that fails their second server, for each request.
That's stupid. It increases latency, bandwidth used, and decreases reliability. The Status-Server draft says that using Status-Server is preferable to the alternatives. Maybe they'll follow it once it becomes an RFC.
Now, when a request comes through that gets discarded by the first proxy (because it itself times out on a random HL RADIUS), that one gets marked as a zombie. Strangely enough, my server keeps it marked as a zombie even after several minutes (long past any of the zombie_period and revive_interval periods I've kept in the configuration). My server keeps talking only with the second server which is in the 'alive' state, and ignores the zombie.
Hmm... the "zombie_period" timers depend on continued packet streams. If the NAS doesn't re-transmit packets, then it could stay zombie for a while. I'll have to take a look at that.
After re-reading proxy.conf comments, this actually looks logical - there is no kind of a status check that would unmark it as a zombie. revive_interval can resurrect it from the 'dead' state, but not from the zombie state. Also this part of the revive_interval comment is a bit confusing:
# As a result, we recommend enabling status checks, and # we do NOT recommend using "revive_interval". # # The "revive_interval" is used ONLY if the "status_check" # entry below is not "none". Otherwise, it will not be used, # and should be deleted.
So it's supposed to be a crutch only for people who *have* status checks, but not a crutch for those of us who do *not* have status checks.
Huh? That's not what it says. It says "revive_interval" is ONLY for people who have "status_check = none". i.e. no status checks.
What is a crutch for this situation? A cron job that keeps doing radmin -e 'set home_server state X Y alive'? :)
If you don't have status-checks, then the "revive_interval" should apply. If it's not being applied, that should be fixed. Alan DeKok.