On 29/12/10 15:45, Colin Coe wrote:
Hi all
I'm currently redesigning an environment I've inherited. The
environment consists of two main sites with limited replication. Each
site is effectively a replica of the other.
The environment was built with four proxy servers at each site (so
eight in total) with 2 being forwarding proxies and two being reverse
proxies. I'd like to consolidate these into either a single proxy or
a HA cluster of two proxies at each site, I'm still deciding. The
current platform is RHEL5 (squid 2.6), the new platform will likely be
RHEL6 (squid 3.1.4).
My squid fu is weak and as both reverse proxies have
https_port 80 defaultsite=server1.company.com
key=/etc/ssl/server1.company.com.key
cert=/etc/ssl/server1.company.com.crt protocol=http
https_port 443 defaultsite=server1.company.com
key=/etc/ssl/server1.company.com.key
cert=/etc/ssl/server1.company.com.crt protocol=https
and
http_port 80 defaultsite=server2.company.com
https_port 443 defaultsite=server2.company.com
key=/etc/ssl/server2.company.com.key
cert=/etc/ssl/server2.company.com.crt protocol=http
I've no idea if the consolidation is possible or not.
I've searched the archive and googled but not seen anything to tell me
if I can do this.
Any ideas?
At a minimum add the "accel vhost" options to those http_port and check
the rest of the config logics are based on dstdomain.
http://wiki.squid-cache.org/ConfigExamples/Reverse/VirtualHosting
Whether they are combinable after that will depend on the client
software visitig. If they are HTTP/1.1 compliant enough to send Host:
header you can (most do).
The forward-proxy can be merged in easily (with squid-2.6 or later) as
long as care is taken to place the forward-proxy config later in the
config file than the reverse-proxy config. The difference may be that
the forward proxy traffic reduces the caching efficiency overall which
the reverse-proxy sees.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.10
Beta testers wanted for 3.2.0.4
