Traffic Server can participate in cache hierarchies. Requests not fulfilled in one cache are routed to other regional caches, thereby leveraging the contents and proximity of nearby caches.
This chapter discusses the following topics:
A cache hierarchy consists of cache levels that communicate with each other. Traffic Server supports several types of cache hierarchies. All cache hierarchies recognize the concept of parent and child. A parent cache is a cache higher up in the hierarchy, to which Traffic Server can forward requests. A child cache is a cache for which Traffic Server is a parent.
Traffic Server supports the following hierarchical caching options:
If a Traffic Server node cannot find a requested object in its cache, then it searches a parent cache (which itself can search other caches) before finally retrieving the object from the origin server. You can configure a Traffic Server node to use one or more parent caches so that if one parent is unavailable, then another parent is availale to service requests. This is called Parent Failover. Traffic Server will support parent caching for HTTP and HTTPS requests.
Note: If you do not want all requests to go to the parent cache, then simply configure Traffic Server to route certain requests (such as requests containing specific URLs) directly to the origin server. SImply set parent proxy rules in parent.config.
The figure below illustrates a simple cache hierarchy with a Traffic Server node configured to use a parent cache. In the following scenario, a client sends a request to a Traffic Server node that is a child in the cache hierarchy (because it's configured to forward missed requests to a parent cache). The request is a cache miss, so Traffic Server then forwards the request to the parent cache, where it is a cache hit. The parent sends a copy of the content to the Traffic Server, where it is cached and then served to the client. Future requests for this content can now be served directly from the Traffic Server cache (until the data is stale or expired).
Parent caching
Note: If the request is a cache miss on the parent, then the parent retrieves the content from the origin server (or from another cache, depending on the parent’s configuration). The parent caches the content and then sends a copy to Traffic Server (its child), where it is cached and served to the client.
Traffic Server supports use of several parent caches. This ensures that if one parent cache is not available, another parent cache can service client requests.
When you configure your Traffic Server to use more than one parent cache, Traffic Server detects when a parent is not available and sends missed requests to another parent cache. If you specify more than two parent caches, then the order in which the parent caches are queried depends upon the parent proxy rules configured in the parent.config configuration file. By default, the parent caches are queried in the order they are listed in the configuration file.
To configure Traffic Server to use one or more parent caches, you must complete the following steps:
Note: You need to configure the child cache only. No additional configuration is needed for the Traffic Server parent cache.
records.config
file located in the Traffic Server config
directory. Variable | Description |
---|---|
proxy.config.http.parent_proxy_routing_enable |
Set this variable to 1 to enable the parent caching option. |
records.config
file. parent.config
file located in the Traffic Server config
directory. politics
and the path /viewpoint
directly to the origin server (bypassing any parent hierarchies): url_regex=politics prefix=/viewpoint go_direct=true
mms://host1
to the parent cache parent1
. If parent1
cannot serve the requests, then requests are forwarded to parent2
. Because round-robin=true
, Traffic Server goes through the parent cache list in a round-robin based on client IP address.
dest_host=host1 scheme=mms parent=”parent1;parent2” round-robin=strict
parent.config
bin
directory.traffic_line -x
to apply the configuration changes.The Internet Cache Protocol (ICP) is used by proxy caches to exchange information about their content. ICP query messages ask other caches if they are storing a particular URL; ICP response messages reply with a hit or miss answer. A cache exchanges ICP messages only with specific ICP peers, which are neighboring caches that can receive ICP messages. An ICP peer can be a sibling cache (which is at the same level in the hierarchy) or a parent cache (which is one level up in the hierarchy).
If Traffic Server has ICP caching enabled, then it sends ICP queries to its ICP peers when the HTTP request is a cache miss. If there are no hits but parents exist, then a parent is selected using a round-robin policy. If no ICP parents exist, then Traffic Server forwards the request to its HTTP parents. If there are no HTTP parent caches established, then Traffic Server forwards the request to the origin server.
If Traffic Server receives a hit message from an ICP peer, then Traffic Server sends the HTTP request to that peer. However, it might turn out to be a cache miss because the original HTTP request contains header information that is not communicated by the ICP query. For example, the hit might not be the requested alternate. If an ICP hit turns out to be a miss, then Traffic Server forwards the request to either its HTTP parent caches or to the origin server.
To configure a Traffic Server node to be part of an ICP cache hierarchy, you must perform the following tasks:
records.config
file located in the Traffic Server config
directory. Variable | Description |
---|---|
proxy.config.icp.enabled |
Set this variable to: 0 to disable ICP. 1 to allow Traffic Server to receive ICP queries only. 2 to allow Traffic Server to send and receive ICP queries. |
proxy.config.icp.icp_port |
Set this variable to specify the UDP port that you want to use for ICP messages. The default is 3130. |
proxy.config.icp.multicast_enabled |
Set this variable to: 0 to disable ICP multicast. 1 to enable ICP multicast. |
proxy.config.icp.query_timeout |
Set this variable to specify the timeout used for ICP queries. The default is 2 seconds. |
records.config
icp.config
file located in the Traffic Server config
directory. icp.config
bin
directory. traffic_line -x
to apply the configuration changes.