What is a hierarchy?

About a request resolution hierarchy

Through NetCache configuration, you can logically define different levels of NetCache appliances to create a request resolution hierarchy. This structure enables a NetCache appliance to forward a request it cannot resolve to specific NetCache appliances, third-party proxy-cache servers, and nontransparent firewalls for request resolution. The purpose of a hierarchy, therefore, is to enable you to define what is to happen when the NetCache appliance you are configuring cannot resolve a request--that is, what that appliance is to do when a cache miss occurs. Hierarchy configuration affects traffic outbound from the NetCache appliance on which you configure the hierarchy, not the request traffic from clients.

Note
A hierarchy cannot be used for resolving NNTP and DNS requests.

The following illustration shows an example of a simple hierarchy.

You can include in a hierarchy multiple levels of parents and multiple parents for a particular child. If desired, you can define parents to be in a logical cluster to take advantage of distribution through a hashing function (see Request distribution in a cluster). You can also include NetCache appliances at the same level as siblings. However, because ICP is used for communication between caches at the same level, Network Appliance does not recommend including appliances at the same level in your hierarchy. The reason is that ICP is not as efficient as TCP.

Functions of hierarchy members

Consider the following when planning a hierarchy:

A parent cache can fetch objects directly from the origin server. If you define multiple levels of parents, however, the request must be passed up through the hierarchy, with the top-level parent being the one that fetches the request directly. If the top-level parent is inside a nontransparent firewall running as a proxy, the request must be sent through the firewall to the origin server.
A child cannot fetch objects directly from the origin server, only through a parent. In the preceding illustration, NetCache appliance A sends requests that it cannot resolve to NetCache appliance B, its parent in the hierarchy.
Child caches fetch noncacheable objects directly from the origin server, unless network security policies prevent the child from accessing the origin server directly, or unless you explicitly configure the child not to fetch noncacheable objects directly from the origin server.

You should devise an overall plan for the interaction among all of your NetCache appliances for resolving cache misses. You will, however, configure each NetCache appliance individually, with its individual view of the hierarchy. For example, NetCache appliance A in the previous illustration is configured to be aware only of NetCache appliance B as its parent and, therefore, can pass its cache misses only to NetCache appliance B. If other NetCache appliances were in the hierarchy above its parent NetCache appliance B, NetCache appliance A would not be configured with any information about them.

Request distribution in a cluster

The following example shows a hierarchy from the viewpoint of NetCache A, that is, the hierarchy as it is configured on NetCache A. In this case, four NetCache appliances are identified as a parent cluster so that a hashing function on the child (NetCache A), by looking at the URL, can determine which of the four appliances in the cluster should receive the request. If the parents were not identified as part of a cluster, NetCache A would query each one individually for cache misses, which is not as efficient.

The hashing function that NetCache uses enables NetCache to distribute requests optimally among the members of the cluster, thereby minimizing duplication of objects among cluster members.

The NetCache appliances in the cluster are not configured to be aware of the cluster. The reason is that it is not efficient for caches at the same level to query each other for objects; it is faster for them to send requests directly to the next level or to the Internet to obtain the objects.

Example 1: cluster used with transparent Web caching provides an example of a deployment using a cluster.

Note
NetCache clusters are similar to other Web caches that use Microsoft's Cache Array Protocol (CARP).

Failover to another cluster member

A NetCache appliance distributes requests over any cluster members that are available.

With the preceding illustration, assume that NetCache appliance A had been sending cache misses for Web server www.abc.com to cluster member C (because the hashing function determined that C could handle the URL in the request most efficiently). If C goes down, A sends a cache miss for www.abc.com to another cluster member.

When C comes back up, NetCache resumes sending cache misses for www.abc.com to C. NetCache returns to its "preferred algorithm" as soon as possible.

If all the members in the cluster go down, the child cache to the cluster (A in this example) sends requests directly to the Internet if security policies allow this failover approach.