<div dir="ltr"><div>Hi,</div><div><br></div><div>Agree that Squid is a specialized proxy and more optimal architecture for the purpose and trying to achieve HA on the Browser side is certainly a bad idea.</div><div><br></div><div>Talking specifically of a reverse proxy scenario, whether one uses Squid or Apache mod_proxy or something else may well depend upon what other features are needed and the traffic volumes. In many reverse proxy environments where more complex control is needed, mod_proxy seems to be often used with modules like mod_rewrite. My understanding of Squid is that it does great as a proxy but does not provide these features, as that is not its purpose.  Does Squid have its own production level extensions for some scenarios which may be typically addressed by Apache modules?</div><div><br></div><div>Thanks!</div><div><br></div><div>- Ashish</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 30, 2015 at 8:02 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 30/08/2015 3:58 p.m., Ashish Mukherjee wrote:<br>
> Why should Squid take care of HA though? Isn't it the responsibility of the<br>
> Website to ensure its uptime? Even if used as a reverse proxy, Apache may<br>
> do a better job at this, since one can do more sophisticated configurations<br>
> with mod_proxy.<br>
<br>
The hint is in the name of that module: mod_*proxy*.<br>
<br>
HA is an outcome of using any one or more of several _proxy features_.<br>
<br>
Squid is a proxy. The purpose of mod_proxy is to hack/squash/ proxy<br>
gateway capabilities (ie Squid functionality) into a piece of origin<br>
server software (Apache).<br>
<br>
Would you expect a dedicated/designed piece of proxy software or an<br>
'other' software design with add-on tacked into it to actually be better<br>
at the proxying functionality?<br>
<br>
Sure you can use the other softwares add-on *if* it performs the<br>
function correctly and sufficiently for your needs. But that does not<br>
make it the function any less a proxy mechanism.<br>
<br>
On the other end Browsers also have HA functionality they call "Happy<br>
Eyeballs". Varuous downloaders and app update serices try to do IP-based<br>
filovers and recovery. And it call causes no end of trouble to the real<br>
proxies in the middle just doing their job properly.<br>
<br>
Amos<br>
<br>
><br>
> On Sun, Aug 30, 2015 at 3:56 AM, Kinkie wrote:<br>
><br>
>> Hi,<br>
>>   please see <a href="http://wiki.squid-cache.org/Features/MonitorUrl" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/Features/MonitorUrl</a>.<br>
>> It's available in squid 2.6 , and is one of the last few features who<br>
>> haven't yet made it to Squid 3.X. If anyone is interested, code and<br>
>> sponsorships are always welcome :)<br>
>><br>
>> On Thu, Aug 27, 2015 at 12:10 PM, Imaginovskiy wrote:<br>
>><br>
>>> Hi all,<br>
>>><br>
>>> Bit of a strange one but I'm wondering if it's possible to have squid<br>
>>> redirect a site to a secondary backend server if the primary is down.<br>
<br>
Yes it is. This is one of the core functionalities of proxying and so<br>
well integrated there is *no* special configuration needed. In fact you<br>
have to explicitly configure alternative if you want to avoid it.<br>
<br>
>>> Have<br>
>>> been looking into this but haven't seen much similar to this. Currently I<br>
>>> have my setup along the lines of this;<br>
>>><br>
>>> Client -> Squid -> Backend1<br>
>>><br>
>>> but in the event that Backend1 is down, the following should be done;<br>
>>><br>
>>> Client -> Squid -> Backend2<br>
>>><br>
>>> Is squid capable of monitoring connections to peer or redirecting based on<br>
>>> an ACL looking for some HTTP error code?<br>
<br>
I would almost bet you already have it setup in your squid.conf:<br>
<br>
 cache_peer <a href="http://Backend1.example.com" rel="noreferrer" target="_blank">Backend1.example.com</a> ...<br>
 cache_peer <a href="http://Backend2.example.com" rel="noreferrer" target="_blank">Backend2.example.com</a> ...<br>
<br>
<br>
Backend2 will be used only if Backend1 is detected as unavailable, or<br>
starts getting overloaded/slow (yes the HA includes latency optimization<br>
too), or starts returning some retriable status responses (most common<br>
is 502).<br>
<br>
<br>
Yes, simply the line order itself. Everything else is just tuning of the<br>
HA parameters.<br>
<br>
To prevent flapping there is a default of 10 requests that need to have<br>
failed (in a row) before the 'dead' detection kicks in to send 100% to<br>
Backend2. Those 10 will make TCP connect attempts to Backend1 before<br>
retrying with Backend2 (if enough time remains in the forward_timeout).<br>
That is configurable, see cache_peer documentation for timeouts and<br>
failure options. background-ping may also be of interest to you.<br>
<br>
<br>
You can improve further by using DNS-based HA availability. Pointing<br>
each Backend1 and Backend2 domain names at multiple IPs. But be wary of<br>
those Browsers and their (overly) "Happy eyeballs".<br>
<br>
Amos<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div><br></div>