On 28/05/11 05:02, Tory M Blue wrote:
On Fri, May 27, 2011 at 1:39 AM, Amos Jeffries<squid3@xxxxxxxxxxxxx> wrote:
On 27/05/11 10:05, Tory M Blue wrote:
Seems to be some confusion.
Stale vs non-stale content is a matter for the website cache control HTTP
headers. Squid *will* serve stale content according to RFC 2616.
Proxy up/down merely determines how much lag the client gets exposed to as
unavailable peers get contacted for data.
A peer is unavailable if either its box is down OR you manually dropped it
out. It can't be available while shutdown, for instance.
Now why does the Squid box being up/down matter independently of Squid
itself?
Say Squid crashes, my icmp host check will succeed and with no other
check in place the squid server continues to be passed end user
requests that it can't hope to fulfill.So end users get errors.
(Remember the F5 accepted the connection and passed it on to a now
defunct server, so there is no real client side retransmission or
other, the user will get a 404 or other error.).
Aha. Yes. There is the real problem. The F5 itself now knowing the VIP
needs updating.
Another scenario I have a monitor check that grabs an image from a
cache_peer through squid, it succeeds squid is up and running, the LB
leaves squid in the VIP. Now we take the cache_peers down, or they
fail, overloaded or something<shrug>, the LB tries to pull a test
image through squid, it fails (cache_peer is not available), the LB
pulls the squid cache(s) out of the VIP as well. I'm now completely
down, vs having sometime for the caches to serve data from it's local
store (I believe with my testing, that if the cache_peer is not
available and Squid has the requested image, it will serve it up,
regardless of age (could be stale, can't revalidate it etc). Am I
mistaken?
You are partialy correct. For cacheable objects that is true.
Non-cacheables not being stored at all will just fail.
Then there are a few things in the config file and some in HTTP itself
which can force files out of storage to start producing errors.
Squid has a set of icons which it loads for FTP directory listings etc.
They are configured in the /etc/squid/mime.conf configuration file.
If you need a test image loaded by Squid the URL
http://$host/squid-internal-static/icons/unknown.gif
should come back from squid-2 with a question-mark icon.
Your a prince, but who is Anthony?
squid-internal-static/icons/anthony-unknown.gif :)
Doh. Been playing with the new ones to much :)
monitorurl doesn't quite do it, since I'm looking for a test from a
3rd party device.
monitorurl takes any URL you want *through* the cache_peer link. If it comes
back okay the peer is assumed to be accessible and ready to accept traffic.
Yes, but as you can see I'm trying to verify that the squid process is
working, I have other checks to verify that the cache_peers are up and
running (Again another LB monitor that checks for a status file,
up/down (for maintenance reasons).
But.. So what happens if the monitorurl fails?
The peer is declared "dead" and the querying Squid starts selecting
another peer server until the test starts working again.
I think I got a little confused because you have two layers of scenario
going on. client->F5->Squid (icon test F5->Squid) and Squid->peer
(monitorurl test)
-Thanks again sir, I owe you a beer/coffee/soda/some variety of flavored water
Tory
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.7 and 3.1.12.1
