Creating a Peer Cache

For small operations in a single location, one cache server may be
sufficient. For more complicated scenarios, Squid and many other
cache servers allow communictions between caches. With this
capability you can deploy a mesh of cache servers, where parent
and sibling caches share their content with one another using the Internet Cache Protocol. This can be useful for load balancing and redundancy.

It can also be used to set up a distributed cache infrastructure,
where remote offices with slow network connections need their own
local cache. Traffic on the slow network connections can be reduced
by creating a parent cache at the Internet connection and child caches
at each remote office. You can also join an existing mesh of caches
on the Internet if appropriate (see section four of the Squid FAQ).

For our example configuration, we'll set up a single sibling server
named proxy2 in addition to proxy1, already configured.
We'll assume that the Domain Name System (DNS) configuration will handle resolution of a
single cache server name to the two physical servers. The hardware
configuration for proxy2 should be at least as capable as
proxy1 but there's no requirement that they be identical.
After configuring proxy2, the two servers can be made siblings
by making the following Squid configuration changes (with the
appropriate domain names):

In squid.conf on proxy1:

icp_access allow all
cache_peer proxy2.my.domain sibling 3128 3130

In squid.conf on proxy2:

icp_access allow all
cache_peer proxy1.my.domain sibling 3128 3130

After a restart of both Squid processes, the servers should begin
checking each other's caches before going to origin servers on the
Internet. You should see new output in the access log relating to the
sibling server.

Log Rotation

On an active proxy server, access logs can get extremely large. If
allowed to grow unchecked, they can become difficult to work
with. Worse, they could quickly fill the partition holding the log
directory. Implementing a scheme to rotate logs frequently will help
to prevent this scenario.

Squid is capable of doing its own log rotations. Though you could
use other facilities to handle it, a single signal to the running
Squid process will do the rotation for you neatly and cleanly. To
enable it, first choose the number of old logs you wish to keep and
enter it in squid.conf:

logfile_rotate 15

After restarting Squid, you can initiate the rotation with this
command:

# /usr/local/squid/bin/squid -k rotate

By putting this command into the daily cron configuration (or in
root's crontab) we'll fully automate the rotation process.

As the logs are rotated, they are given numeric extensions. The
log currently in service is access.log. Yesterday's file
would be access.log.0. The file from three days ago would be
access.log.2, and so on up to the maximum specified in
squid.conf. Squid's own server-information logs
(cache.log)
are rotated in the same way. After the logs reach the maximum
assigned in squid.conf, the oldest files are deleted by the
rotation. This should help keep the log partition from getting too
full.

Further Reading

The procedures presented in these two articles should be enough to
get Squid running on your network. Next, you may want to implement
some monitoring and tune Squid to your particular needs. A good place
to start is the Squid User's
Guide. This document is a little outdated, but provides a nice
foundation for understanding Squid and caching in general. The Squid FAQ is
also a must-read document. The Squid Mail
Archive may also be of interest

You may also enjoy reading this detailed
review of Squid and its deployment.

Conclusion

I hope that this introductory tutorial has been interesting and useful
to you. Of course, Squid has far more capability than has been
explored here, and you are encouraged to review the resources linked
above for further information. If you choose to implement Squid for
your enterprise you should find it to be robust and easy to manage.
Good luck.

Jeff Dean is an engineering and IT professional currently writing a Linux certification handbook for O'Reilly and Associates.