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
