8. Common Configurations for Parents and Siblings

8.1 Being a Parent

When acting as a parent cache for someone else, the first thing to take care of is the access controls. Your child caches need to provide you with their cache hostnames or addresses. You need to communicate to your child cache(s) exactly which requests you will allow. We generally recommend that parent caches do NOT handle CGI and other non-cachable requests. If the child caches use ICP, then it is important to have your ICP and HTTP access controls match. It would be frustrating at best to allow all ICP queries and then deny specific HTTP requests. Finally, do not use miss_access for your child caches.

Sample configuration:

        acl KIDS src cache.isp1.net cache.isp2.net cache.isp3.net
        acl CGI urlpath_regex cgi \?
        icp_access allow KIDS !CGI
        http_access allow KIDS !CGI
        ...
        ...
        icp_access deny all
        http_access deny all

We would also recommend that parent caches use the ICMP features of Squid. This means compiling Squid with the USE_ICMP option defined in src/Makefile. The ICMP measurements can assist your child caches in selecting the optimal parent cache for a given origin server.

There is really no need for parent and child caches to have the same refresh_pattern configurations. We usually recommend that parent caches use conservative refresh rules. However, this is not really important since Squid always includes the first cache's freshness requirements in the Cache-Control: Max-Age header.

Note that parent caches tend to have lower hit rates than their child caches. This will be especially true if the parent cache has only a few child caches as clients. The hit rate increases with the number of clients, so quite many child caches may be required to achieve reasonable hit rates in the parent.

8.2 Being a Sibling

Access controls are just as important for sibling caches as for parents. In addition to the http_access and icp_access, you will also need to carefully consider miss_access. If you do not trust your sibling peers enough to not use miss_access, then every cache should use the same refresh_pattern rules. Failure to do so will result in unexpected ``access denied'' error messages.

You will receive many more ICP queries than HTTP requests from your sibling peers. For every 100 ICP queries, you might receive as few as 5 HTTP requests. Note that, by default, ICP queries are also written to the access.log. This may cause your logfile to grow to unmanageable proportions. You can disable ICP logging with the log_icp_queries option.

Sample configuration:

        acl SIBS src cache.isp1.net cache.isp2.net cache.isp3.net
        acl CGI urlpath_regex cgi \?
        icp_access allow SIBS !CGI
        http_access allow SIBS !CGI
        #miss_access deny SIBS
        ...
        ...
        icp_access deny all
        http_access deny all

8.3 Running a Cluster of Caches

If you want to operate a cluster of caches such that any URL is only kept in one of the caches, you need to enable the icp_hit_stale option. Recall this causes Squid to return ICP_HIT for stale objects, which means you can not have true sibling relationships with other caches outside of your administrative control.

Each cache's configuration needs to specify all the other caches as siblings. For example, with a cluster of three, the first would include:

        cache_host cache2.mydomain.net 3128 3130
        cache_host cache3.mydomain.net 3128 3130
        icp_hit_stale on

Note that you have to be careful with the visible_hostname option in a cache cluster. You might want the visible_hostname to be the same for all caches, perhaps to hide the details of your cluster configuration. However, this will confuse Squid's loop-detection scheme. Squid inserts the visible_hostname into outgoing requests, so if one of your caches forwards a request to another, the second one will think it has detected a forwarding loop. The best way to alleviate this problem is to append a unique identifier to the visible_hostname in each configuration, such as:

        visible_hostname cache.mydomain.net/1

8.4 Mutual Parents

A pair of caches can not specify each other as parents, unless they use the cache_host_domain restrictions. Without those restrictions, the hierarchy has a forwarding loop.

Consider an example where two organizations want to utilize each other's caches as parents, but only for servers local to their respective domains. The first cache can specify:

        cache_host cache.a.net parent 3128 3130
        cache_host_domain cache.a.net a.net

        cache_host cache.b.net parent 3128 3130
        cache_host_domain cache.b.net b.net