Server Sizing and Other Hardware Issues
Novell Cool Solutions: Feature
By Scott Jones
Digg This -
Posted: 15 Feb 2002
Version: BorderManager 3.5/3.6
Note: Check out the new Q&A about this article.
The most significant factor in hardware selection is which services will be in use on the Novell BorderManager (NBM) server. NAT, packet filtering, VPN, and the IP Gateway are processor-intensive vice RAM-intensive. Cache, of course, is primarily RAM-intensive. All BorderManager services, however, are communication-intensive. For a large number of users, isolate proxy/cache services and have other NBM services on dedicated boxes. The proxy boxes should have the maximum amount of RAM that the mainboard will support (and certainly not less than 1GB for 5000+ users).
Any single contemporary CPU is more than adequate. Once NetWare has a multithreaded IP stack and file system, multiple CPU's will offer an advantage. For now, they are an extravagance. (Note: The multithreaded IP Enhancement Pack is available, but has not been evaluated in production by Novell Consulting.)
Any BorderManager server should have a minimum of 128MB RAM dedicated to BorderManager. That is, 128MB above the requirements of the OS and other services. 256MB is a recommended minimum total. In a hierarchical cache, more RAM should be employed in higher-level cache servers, with the primary cache devices containing the maximum supported by the mainboard.
Network Interface Cards
High-quality server NIC's are a must. Remember that a BorderManager server is a network infrastructure device. It's more of a "router" than a "server". Place NIC's on high-priority interrupts (usually 10 and 11; verify with system board documentation). On a proxy/cache server, place the private NIC on the higher-priority interrupt (since it will have more traffic). Even if a proxy server will be inside the private network, still have a Public and Private NIC on different logical segments if possible. This will divide the traffic load and effectively double the server's communication capacity.
Important Note: Never rely on auto detection of line speed and duplex setting. Force the desired settings in the board configuration and on the hub/switch port(s) the server is connected to. Auto detection can result in a big performance hit, causing frame alignment errors, collisions (even on a switched segment!), and thousands of ECB's being allocated even under light load conditions.
When selecting proxy/cache server machines, focus on the drive subsystem. The bottleneck in Novell caching solutions is the storage subsystem. When selecting machines as proxy/cache servers, emphasis should be on technologies such as Ultra-3 Wide SCSI, hardware RAID (striping), I2O, and high RPM drives. These high performance storage systems produce a great deal of heat and require sufficient cooling to ensure optimum throughput. Therefore, case design, placement, and adequate data center ventilation are important.
The following is recommended:
- Two drives in a RAID 1 array (purely for fault tolerance) containing the SYS and LOG volumes. 4GB each suits most implementations.
- Two or more drives, possibly in a RAID 0 array (for performance enhancement), containing the cache volume(s). Do not use RAID 5 for the cache volume(s); a drive failure will bring disk I/O to a crawl. See below regarding volume size.
- Novell Consulting no longer recommends using four or more drives in a RAID 0/1 array for cache volumes (to combine performance enhancement with fault tolerance). Cache volume fault tolerance is an extravagance. Since cache data is transient, there is little point in allocating expensive hardware resources to protecting specific cache objects. Having multiple cache volumes on different physical hard drives already protects against a drive failure bringing down the proxy/cache service.
Cache Volume Configuration
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 works is 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 busses.
NTS 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.
David G. wrote: The article on sizing a BorderManager server was very good (and helpful!). I do have a question about it. One tip was that the cache volume ought to be the size of about one week's worth of data served. Can you give me a pointer as to how to find that out? Is there a way for me to (for example) clear the cache and then one week later look at statistics? If so, which specific screens (and fields on those screens) would I look at? Any suggestions would be appreciated. Thanks!
Scott Jones: At the server, hold down Ctrl and Esc at the same time to see a list of active screens. Type in the number from the list for "Proxy Console" and hit enter. Select #1, "Display current activity."
This screen shows all proxy activity from the last time PROXY.NLM was loaded.
Scott Jones, Master CNE, is the product manager of Novell BorderManager. If you have any questions for Scott, you may e-mail him at email@example.com
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com