Setting up client access to news caches and distributing requests over news caches are much the same for Web caches and news caches. You can set up client access to a news cache in the following ways:
You would need to manually configure client browsers to point directly to one of the following:
See Chapter 2, Strategies for Client Access to NetCache.
Some considerations that affect how many NetCache appliances you need are as follows:
If, for example, your goal is to reduce bandwidth consumption, deploying a news cache close to your users can reduce the volume of news requested over a WAN.
You can configure a NetCache appliance to operate in more than one mode--for example, as a Web cache and a news cache. However, if you expect your news cache to handle a substantial load, for example, the volume of an ISP Data Center, Network Appliance recommends that you dedicate a NetCache appliance to news caching. By doing so, you avoid conflicts between different software programs, and performance and reliability are better.
Your Network Appliance sales engineer can help you determine the number of NetCache appliances you need to meet your goals and handle the number of client connections that you expect for news traffic.
If you need uninterrupted news service, you can implement one or more of the following failover strategies:
If you are using an L4 or L7 switch and you are concerned about failure of your switch, you can deploy two switches in a failover pair.
When determining the number of news caches that you need, plan for one news cache in addition to the number you think you need to handle the news traffic. That way, if one news cache goes down, the remaining news caches can still handle the volume of news traffic.
It might not be possible to set up failover in case all news caches go down. Typically, the load of connections that a Reader server can handle is vastly less than the number of connections that a news cache can handle. If your Reader server can handle the volume of client requests that your news caches can handle, you can set up your deployment so that news requests fail over to the Reader server if all news caches go down. However, if your Reader server cannot handle the traffic that your news caches can handle, your news service will be unavailable or news service performance will be poor if the Reader server takes over.
The following illustration shows an example of news caches and failover when transparent proxying is deployed with an L4 or L7 switch.
You could set up your switch so that if all news caches go down, news service fails over to the news server. However, because news servers typically cannot handle nearly the number of connections that a news cache can, you run the risk of overloading your news server.
If you want to load balance the news service traffic across multiple news caches, you can do the following:
You can deploy your news cache so that one news cache points to another news cache, and the "higher-level" news cache points to the Reader server component of the news server. This type of deployment enables you to add an extra "level" of news caching, which can result in a better cache hit rate and protect your news server's Reader server from traffic overload. In the following illustration, News cache A and News cache B are deployed at the POPs and News cache C is deployed at the data center.
Deploying news caches in a hierarchy is helpful for an ISP with many POPs (points of presence). If the news caches at the POPs are experiencing a low hit rate, the hit rate can most likely be increased by deploying a news cache in the ISP's data center also and having the POPs send cache misses to the data center news cache. Although cache misses from the POPs could be sent directly to the Reader server, the Reader server might not be able to handle the number of connection attempts.
To implement this type of deployment, in your news cache configuration you identify the news server (or higher-level news cache) to which the news cache connects. This identification enables the news cache to send cache misses to the news server (or higher-level news cache).
Deploying one news cache to point to another news cache, as shown in the previous illustration, can help protect your Reader servers from too much traffic. However, avoid deploying a chain of news caches for the following reasons:
The configuration of each news cache includes settings for how often NetCache is to check the news server for new articles and how often NetCache is to check for canceled articles. If there is a chain of caches, the time period for checking for new articles is the total of the specified time period on all the caches. Likewise, the time period for checking for canceled articles is the total of the specified time period on all caches.
News articles become inconsistent on the news caches if the time periods for the check for new articles and the check for canceled articles are not set the same way on all the news caches.
Copyright © 1994-2002, Network Appliance, Inc. All rights
reserved.
Part No. 210-00372
File: nntpdpl6.htm
Last updated: 11/13/02 18:11:44