Novell Home

Hierarchical Cache: Using Novell BorderManager and Volera Excelerator together

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 6 Dec 2001
 

Version: BorderManager 3.6

Network speed and security are critical to the success of your business. In the age of video conferencing, Voice over IP (VoIP) and streaming media, the content transmitted across intranets, extranets and the Internet is growing exponentially. At the same time, the bandwidth available for corporate use remains fairly constant. Within individual network environments, such as business enterprises and large corporations, increased network traffic over limited bandwidth can drastically reduce network performance and user productivity. To improve the speed at which users can access mission-critical information, you must find a way to eliminate non-business related traffic and redundant content requests.

Novell® BorderManager® and Volera* Excelerator, combined in a hierarchical proxy/ cache infrastructure, can enable you to improve user productivity and network perform- ance without the huge investment of a new network infrastructure. This solution extends Novell's one Net vision by providing your organization with unparalleled caching and employee Internet-usage management capabilities. Working together, Novell BorderManager and Volera Excelerator simplify and accelerate user access to online content across a company's intranet and extranet, as well as the Internet. In addition, these products offer a highly reliable, scalable, fault-tolerant solution that protects you from potential security and liability risks by enabling you to filter the content brought onto your private network.

BUSINESS BENEFITS:
NOVELL BORDERMANAGER—VOLERA EXCELERATOR COMBINED PROXY SOLUTION

Enhance User Productivity

Not surprisingly, HTTP traffic consumes the majority of IP network bandwidth. This traffic typically consists of redundant requests for online content, as well as requests for recreational URLs (such as news and entertainment Web sites).

If users are accessing recreational content on company time, they are unproductively limiting the bandwidth available to other employees. Also, any business-related content that is repeatedly requested by users should be cached locally to ensure that valuable bandwidth is available for other business-related purposes.

Used together, Novell BorderManager and Volera Excelerator provide you with granular control over users' access to online content. You also receive a superior caching service that can support tens of thousands of users. As a part of its management offering, Novell BorderManager 3.6 enables you to set rules that limit users' access to online content. For example, you can manage user activity by service, node or network address, URL, time of day, content category, user identity, group membership and a variety of other criteria. This ensures that your network bandwidth is only used for productive, business- related activities.

In addition, Volera Excelerator 2.1 enables you to cache frequently requested Web pages that support HTTP, FTP and a variety of other protocols. Caching commonly visited Web pages significantly reduces traffic on Internet links caused by requests to origin servers. By imple- menting the access control and high-performance caching capabilities of a Novell BorderManager— Volera Excelerator combined proxy solution, users will stay focused on the challenges at hand and have fast access to the resources that they need to be successful.

Decrease Exposure to Liability

Many laws hold businesses liable for illegal activity done on their private networks, even if it occurs against company policy and without the knowledge of management. To prevent this type of activity, Novell BorderManager filters illegal and questionable sites, reducing the likelihood that you may be held accountable for the illegal actions of employees.

Since BorderManager supports user authentication and executes access rules based on the user's identity in Novell eDirectory™, it also has the ability to log Internet activity by user name. Accurate, detailed logging and reporting can also reduce exposure to liability in the event of disciplinary action or possible litigation.

Increase Network Performance

Internet access patterns show that most requests sent to Web servers are for a small number of often-accessed objects such as images, border frames and redundant text. If you do not have a reliable caching platform in place, requests for redundant online content could result in network congestion, latency and even the possibility of a client's request being denied.

A robust caching infrastructure helps eliminate poor network performance by storing frequently accessed content on strategically placed cache devices within your private network. By combining the high-speed caching services of Volera Excelerator with the identity-based access-control capabilities of Novell BorderManager, you bring cached online content closer to the user. This enables you to accelerate user access to Web content and to significantly reduce network traffic.

Even dynamic URL requests can access cached content that includes static HTML and graphics. When dynamic URLs are cached, typically a minority of the returned data is non-cacheable and must be retrieved from the origin server. The following table illustrates how even highly interactive Web pages contain a significant amount of redundant, cacheable data.

WEB CONTENT PERCENT CACHEABLE
Microsoft* DirectAccess knowledgebase search page 100%
Search results from above, "Win98SE general protection fault" 85%
Yahoo!* Main page 100%
Yahoo! search results, "NetWare®" 69%
ABCNews.com main page 100%
ABCNews.com quick poll results 70%
Dell* online purchase (8 pages) 52%

Strengthen Network Security

Novell BorderManager brings powerful security features to a combined proxy/cache solution. BorderManager includes robust firewall services, Single Sign-On (SSO) capability and support for strong authentication mechanisms, such as ActivCard* tokens. While not the focus of this white paper, these features can be leveraged in a proxy/cache design to complement content filtering and deliver a broad-spectrum security solution.

Many Web sites contain scripts, applets, "Web bugs" and other code that can have malicious intent. Even when the intent is benign, such code can damage corporate workstations or transmit proprietary data back to the origin server. By blocking potentially dangerous sites, access-control features in BorderManager can be used to prevent users from unintentionally compromising corporate data.

For enhanced security, BorderManager's SSO technology reduces the chances that passwords will be compromised. Token authentication can further ensure that only authorized users are able to access the Internet via the proxy/cache system.

Provide High Scalability

A cache hierarchy using Novell BorderManager and Volera Excelerator can scale to tens of thousands of users. At the lower levels of a hierarchy, the proxy/cache load is distributed across the BorderManager servers at remote sites; therefore, multiple servers are handling authenti- cation, access control and logging. At the Internet connecting points, Volera Excelerator's cache- optimized hardware and operating system are leveraged as a dedicated-function cache to provide maximum throughput for the entire organization.

Offer Reliable Fault Tolerance

Volera Excelerator natively supports clustering, thus enabling you to provide fully automated fault tolerance at the most critical places in the cache hierarchy.

For example, you can implement two Volera Excelerator platforms where your network connects to your ISP. If one of these platforms experiences a failure, the clustering capabilities of Volera Excelerator enable the failed platform's resources to be absorbed by the backup platform. This provides your organization with an "always- available" caching system, minimizing downtime and maximizing user productivity.

The hierarchical structure itself also provides fault tolerance for devices at the lower levels. For example, if a BorderManager server at a remote site fails, Internet traffic can be redirected to an upstream server. For BorderManager servers at critical locations, Novell Cluster Services™ is an available option.

IMPLEMENTING NOVELL BORDERMANAGER—VOLERA EXCELERATOR COMBINED PROXY SOLUTION

The optimal implementation of a Novell BorderManager—Volera Excelerator combined proxy solution is a three-level hierarchical cache system.

How Novell BorderManager and Volera Excelerator Work Together in a Hierarchical Cache System

Hierarchical caching is a server-configuration scheme that increases network performance and scalability by grouping servers into large, cooper- ating cache groups with defined relationships. These relationships can be either horizontal (peer-to-peer) or vertical (parent-child).

The structure of a cache hierarchy starts at the Internet connecting points and follows the structure of the physical network; therefore, hierarchical structures start at the primary ISP links and flow down to core sites at the second level. And, if warranted by the number of additional subordinate sites, the hierarchy continues further down to a tertiary level. Adding more than three levels to a hierarchy can actually reduce performance, due to communication latency between the levels within the hierarchy.

Protocols Used

Novell BorderManager and Volera Excelerator support a combination of Internet Caching Protocol (ICP) and CERN protocols. This is what allows the two products to work cooperatively in a cache hierarchy. ICP is an advanced protocol that supports both parent-child and peer-to-peer relationships. Within a dynamic caching infrastructure, ICP is used to locate the optimal cache neighbor (parent-child or peer-to-peer) to service a URL object.

CERN supports only single parent-child relationships between servers in the hierarchy and has very little overhead. CERN should be employed at the tertiary-cache level and below to prevent remote site peers from exchanging data with each other across slow wide area network (WAN) links.

The following illustration shows a three- level hierarchical cache. The following section discusses each level of the hierarchy—the primary, secondary and tertiary cache. These are also referred to as Level 1, Level 2 and Level 3.

Primary Cache (Excelerator Cluster)

  • Moves requested Web content into the private network
  • Eliminates redundant requests on the ISP link
  • Increases the life span of the connecting- point infrastructure

A primary proxy/cache in a hierarchical configuration typically shows a hit rate that ranges from 6 to 18 percent, with an average of 12 percent. This is due to the fact that the secondary and tertiary caches have already processed the more popular objects.

When Novell BorderManager and Volera Excelerator are configured in the same hierarchy, an Excelerator cluster serves as the primary cache device. Volera Excelerator appliances are implemented on the primary-cache level for the following reasons:

  • Exceptional performance: one hundred times faster than BorderManager on a conventional NetWare file server
  • Native clustering support: provides load balancing as well as fault tolerance to support tens of thousands of users

Volera Excelerator does not support Novell eDirectory authentication or identity-based access rules. Both are unnecessary at Level 1 in a cache hierarchy. As a dedicated-function cache device, Volera Excelerator's processing speeds are enhanced and network performance is increased.

Secondary Cache (BorderManager Servers)

  • Moves relevant content into regional proximity with the users
  • Eliminates redundant requests on expensive aggregation WAN links
  • Increases the life span of intermediate WAN infrastructures

Secondary level caches in a hierarchical configuration typically show a hit rate that ranges from 12 to 37 percent, with an average of 25 percent. This is because the tertiary caches have already processed the more frequently requested objects.

The second level in the cache hierarchy should consist of multiple, dedicated-function NetWare 6 servers running BorderManager 3.6. Each Level 2 BorderManager cache server acts as a hierarchical child to the Level 1 Excelerator cluster. Where there are subordinate (Level 3) cache servers, the Level 2 cache server also acts as a hierarchical parent to its subordinate cache servers.

To maximize communication efficiency, each Level 2 BorderManager cache server should connect to the local network via two network interface cards, thereby distributing the load of upstream and downstream traffic. By implementing the BorderManager proxy-cache server on the second level of the hierarchy, you can bring cached content closer to each remote site, thereby speeding user access to online content. This cache level also assumes identity-based access rule functions and prevents illegal URL requests from being sent to the Volera Excelerator platform.

Tertiary Cache (BorderManager Platforms)

  • Moves relevant content closer to the users for faster response times
  • Eliminates redundant requests from local users on the local WAN
  • Increases the life span of remote-site WAN infrastructures

The third level in the proxy-cache hierarchy also consists of multiple, dedicated-function NetWare 6 servers running BorderManager 3.6. Each server on this level provides cache services, local authentication and rule execution for a single remote site.

Each Level 3 BorderManager cache server acts as a hierarchical child to the Level 2 cache immediately upstream in the WAN structure and is connected to the local network by a single interface.

Tertiary caches typically experience hit rates that range between 25 and 75 percent, with an expected average of 50 to 55 percent. The difference in hit rates is caused by the varying amounts of content needed within a diversified user population. Because corporations are made up of multiple departments with different online needs, the tertiary-level caching platforms receive the most URL object requests.

BorderManager runs on standard NetWare, which can provide an advantage at remote sites. The proxy/cache may be installed on an existing file/print server, or the BorderManager server may be deployed to provide multiple services, including file/print, local DNS/DHCP, ZENworks®, etc.

Single Sign-On (SSO)

A Novell BorderManager—Volera Excelerator combined proxy solution incorporates BorderManager Single Sign-On (SSO, not to be confused with the separate Novell product of the same name) to provide single sign-on network access to all users. BorderManager Single Sign-On is for users who have the Novell Client™ and normally log into Novell eDirectory. When initiating a dialogue with a proxy server, PROXY.NLM communicates with a small applet running in the user's system tray. Client Trust then verifies with Novell Client that the user is authenticated to Novell eDirectory and obtains the user's user name. The reply is forwarded to PROXY.NLM and the user is authenticated. Client Trust can be easily delivered to the desktop using a forced-run ZENworks policy.

Load Balancing

Although Volera Excelerator appliances are not general-purpose NetWare servers, they are designed to communicate with other Volera Excelerator caching devices. This allows a Volera Excelerator platform to evenly distribute workloads across all of the Excelerator platforms within your infrastructure. They can therefore be easily integrated into a mixed BorderManager/ Excelerator hierarchy to provide reliable load balancing at the primary level.

Other load-balancing options for a Novell BorderManager—Volera Excelerator combined proxy solution include DNS round robin, Layer 4 switches and WCCP routers for the Volera Excelerator devices.

Fault Tolerance

The table below gives a possible configuration for a fault-tolerant cache server implementation.

Failover from the perspective of child proxy/cache servers should be automatic. Level 2 servers view the Volera Excelerator cluster as a single device. Also, in the hierarchy configuration for Level 3 server, parents are specified by IP address, not DNS host name. For each Level 3 server, its parent's failover device is listed as a secondary parent, which is used if the parent is unavailable.

In this example, the Volera Excelerator cluster is placed at the primary site—close to the connecting ISP—and is physically connected to the network by both a public and a private interface to maximize communications efficiency.

LEVEL LOCATION FAIL OVER DEVICE METHOD AUTOMATIC/MANUAL
L1 Primary site Secondary Excelerator Excelerator native clustering Automatic
L2 Primary site Secondary server DNS round robin with ping check Automatic
  Core sites with WAN links
to each other
Peer server DNS change Manual for workstations;
Automatic for child cache servers
  Core sites with WAN links
to only the primary site
Primary site's server DNS change Manual for workstations;
Automatic for child cache servers
L3 Tail sites Parent server DNS change Manual

 

In addition, Volera Excelerator supports Cisco's* Web Cache Control Protocol (WCCP). WCCP does true smart load balancing by predicting which cache device is most likely to have a requested object; therefore, it is the recommended technology for fault tolerance at the ISP connecting point. When connected to a WCCP-enabled Cisco router, two or more clustered Volera Excelerator appliances at the ISP connecting point ensure optimum performance and eliminate the possibility of server failure.

BORDERMANAGER SERVER CONFIGURATION

This section will discuss the specifics of configuring Novell BorderManager for use in a hierarchical cache. The following configuration principles should be applied during server installation:
  • Before installation, make a final check with the server manufacturer for BIOS/firmware updates, current device drivers for NetWare and support issues/recommendations.
  • Check Novell's support site (support.novell.com) to ensure that you have the latest support packs and other product updates.
  • Disable unused hardware components (I/O ports, etc.).
  • Ensure that IRQ's 2, 9 and 15 are not in use.
  • Network Interface Cards (NIC's) should be placed on priority interrupts, with the downstream interface receiving highest priority in Level 2 servers (since it will theoretically bear the most traffic).
  • DOS startup files must be checked to confirm no memory managers or device drivers are being loaded.
  • Unneeded default components (Management Portal, LDAP, etc.) should be removed from the AUTOEXEC.NCF.
  • IP RIP and OSPF should be disabled (static routing only).
  • On Level 2 servers, name the interfaces "Upstream" and "Dnstream."
  • Force NIC's to the desired speed and duplex settings.
  • If your Novell eDirectory tree design allows, before the installation of Novell BorderManager 3.6, a read/write replica of the Novell eDirectory partition containing the server object should be added locally.
  • If your Novell eDirectory tree design allows, before the installation of Novell BorderManager 3.6 on the first server, a read/write replica of [root] should be added locally to ensure proper schema extension. This may be removed later.

Partitions and Volumes

Ideally, use multiple cache volumes of 6-10GB each. This will reduce the time it takes PROXY.NLM to find and read files for cold fills. Note: The cache volumes must be on different physical drives to accomplish this performance improvement. The reason multiple cache volumes work is because you have more read heads working for you simultaneously. Having multiple volumes on the same physical drive accomplishes nothing. If anything, the overhead of two volumes on the same drive makes things slightly slower than if you had one big cache volume. When possible, also place cache volume drives on different SCSI channels and even different PCI buses.

Novell recommends not having significantly more total cache volume space than the amount of data the proxy fills in a given week. Observe the current activity stats on the proxy server and the amount of data filled for each week. If, for example, the total filled for the week is 21GB, then you will probably want to stick with 24-28GB of total cache volume space.

To summarize, use lots of small volumes on different physical hard drives, and not more than one cache volume per drive. Small hard drives are hard to come by these days, so when you are "stuck" with 18GB+ hard drives, start by partitioning just part of the drive(s), and recreate the partition larger if more cache volume space is needed. Since cache data is transient, blowing out a partition has no significance.

Mirrored NetWare File System partitions can be used for the SYS volumes and a dedicated logs volume. Novell Storage Services (NSS) can be used for dedicated cache volumes. The figure below shows a recommended drive/volume configuration for BorderManager servers.

Optimization File

The following optimization file may be called in the AUTOEXEC.NCF on each proxy/cache server, just after the INITSYS load statement. BMEETUNE.NCF also documents tuning parameters that are used elsewhere in the server's configuration.

;; BMEETune.ncf - (c)2001 Novell Consulting
;; *** Add the following to STARTUP.NCF ***
; set maximum packet receive buffers = 25000
; set minimum packet receive buffers = 10000
; set reserved buffers below 16 meg = 300
; set enable disk read after write verify = off
;; Load nlslsp before initsys.ncf to speed services load up
;; Increase conlog maximum size to 1000k
;; When loading NSS, utilize the /cachebalance switch
;; to pre-allocate RAM for disk cache ***
; nss /cachebalance=65
;; Kernel settings
set maximum interrupt events = 50
set maximum service processes = 1000
set minimum service processes = 500
set new service process wait time = 0.3 sec
set worker thread execute in a row count = 15
set pseudo preemption count = 200
;; File system settings
set enable hardware write back = on
set immediate purge of deleted files = on
set enable file compression = off
set maximum file locks = 100000
;; Memory/cache settings
set garbage collection interval = 5 min
set directory cache allocation wait time = 0.1 sec
set directory cache buffer nonreferenced delay = 60 min
set maximum number of internal directory handles = 500
set maximum directory cache buffers = 10000
set minimum directory cache buffers = 5000
set maximum concurrent directory cache writes = 125
set maximum concurrent disk cache writes = 750
set dirty disk cache delay time = 0.1 sec
;; Communication settings
set new packet receive buffer wait time = 0.1 sec
set maximum pending tcp connection requests = 1024
set tcp ip maximum small ecbs = 65534
set reply to get nearest server = off
;set always allow ip fragmentation = on
;; Load services as follows:
;; aclcheck /s /g /b24
;; brdsrv
;; sys:\etc\cpfilter\cpfilter
;; Settings in NWAdmin:
;; maximum hot unreferenced time = 60 (match "directory cache
;; buffer nonreferenced delay" setting)
;; cache hash table size = 256k
;; maximum number of hot nodes = 50000
;; number of cache directories = 256
;; dns transport protocol = udp
;; read ahead = enabled
;; Add the following to PROXY.CFG:
;; [Extra Configuration]
;; DoNotSaveMemoryCacheDuringUnload=1
;; TurnOffPersistantPassThru=1
;; EnableICSPassThruFix=1

Monitoring Server Performance

Normal principles apply for determining additional server-load requirements:

  • Ensure that cache buffers stay well above 50 percent (after taking into account the amount of RAM allocated to NSS caching)
  • Ensure that processor utilization does not stay above 10 percent for extended periods of time
  • Ensure ample free drive space
  • Heed user feedback

Access Rules

An "allow all and deny by exception" posture is typically assumed for proxy-access rules. This will allow all proxy activity unless expressly denied by company policy. Practice shows that less adminis- trative time is required to block undesirable Web sites than to grant access to sites needed for business reasons.

As with Novell ZENworks, a "functional role" is a group of users with the same operational requirements from a network application or service. Some users, for example, may only require access to a limited number of Web sites for the purpose of ordering parts and materials. Their functional role might be accommodated by access rules that give them access to suppliers' sites and nowhere else. IS personnel, on the other hand, typically require access to a wide variety of hardware and software company sites for research and support. Their functional role might be accommodated by access rules that block adult, sports and entertainment sites, but allow access to most other sites.

To simplify access-rule entry and administration, administrators should identify the fewest number of functional roles that will meet business require- ments. The needs of most organizations, even very large ones, can be met with a handful of Access Levels that can be defined in a corporate policy document. The following table shows an example of Access Level definitions.

Level 1 Unrestricted access Executives and IS staff
Level 2 Adult, gambling, and potentially illegal sites are blocked, but all else is allowed Managers and other professional staff members
Level 3 All recreational categories blocked, including B2C e-commerce sites and general interest news, access allowed only to a specified list of business partner sites Clerical staff, clerks, etc.
Level 4 No access All others

A security analysis or IS&T business processes analysis is an excellent opportunity to fine-tune and codify access-rule policy. All access rules may be placed on server objects. While it is possible to consolidate some rules at the container level, rules that utilize CyberPatrol can only be placed on server objects.

Administration can be simplified by having all rules at the same level (in this case, at the server level) because the correct ordering of rules is easier to manage. Rules may be copy-pasted from server to server to avoid having to manually re-enter similar rules on each server.

Each BorderManager proxy/cache server should contain only access rules that apply to Novell eDirectory groups and/or containers that are physically located within the geographical area that may utilize the proxy. This will prevent unnecessary group-membership checks.

When a server is specified as the backup proxy for another geographical area, it should also contain rules for the Novell eDirectory groups and/or containers that are physically located within that other geographical area. This is necessary to ensure that access rules continue to function as desired during a proxy-server failure.

COMPARATIVE ANALYSIS

A Novell BorderManager and Volera Excelerator combined proxy solution provides several enhanced features. Those features are compared in the table below.


FEATURE NOVELL BORDERMANAGER VOLERA EXCELERATOR
Proxy/cache services for all common protocols Yes Yes
CERN and ICP cache hierarchy support Yes Yes
IP gateway Yes No
SOCKS gateway Yes No
Firewall services Yes No
Dial-up services Yes No
Site-to-site VPN Yes No
Client-to-site VPN Yes No
RADIUS server Yes No
Strong authentication (ActivCard) Yes No
Identity-based access control Yes No
Cisco WCCP support No Yes
Cisco WCCP support No Yes
SSL-izer for reverse proxy No Yes
Native clustering No Yes
Industry-leading performance No Yes

CONCLUSION

Using Novell BorderManager and Volera Excelerator together in a hierarchical cache allows you to take advantage of the key strengths of both products. BorderManager provides identity-based control and monitoring of users' activity on the Internet, using mature, directory-integrated technology. Volera Excelerator provides the scalability and performance needed to provide a fault-tolerance cache at high-traffic Internet connecting points. Together, they provide a robust, reliable proxy-cache and access- management solution that can scale to hundreds of sites and tens of thousands of users.

Together, Novell BorderManager and Volera Excelerator increase employees' productivity by keeping them on task and providing them with a faster network. Network performance is enhanced by eliminating unwanted traffic and caching content close to the users. Because of improved network performance, the usable lifetime of existing Internet links and WAN links is significantly extended. The net result is a high return on investment.

? 2001 Novell, Inc. All rights reserved. Novell, NetWare, BorderManager and iChain are registered trademarks, and eDirectory and NMAS are trademarks of Novell, Inc. in the United States and other countries.

*Pentium is a registered trademark of Intel Corporation. All other third-party trademarks are the property of their respective owners.

Novell Product Training and Support Services

For more information about Novell's worldwide product training, certification programs, consulting and technical support services, please visit: www.novell.com/services

For More Information

Please contact your local Novell Authorized Reseller, system house, or service provider. Or visit us at: www.novell.com/ products/bordermanager

You may also call Novell at:
1 888 321 4272 US/Canada
1 801 861 4272 Worldwide
1 801 861 8473 Facsimile

Novell, Inc.

1800 South Novell Place
Provo, Utah 84606 USA

Download the .pdf document here: www.novell.com/info/collateral/docs/4621223.01/4621223.pdf


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell