Ensuring High Performance and Availability from NetWare 4.x and 5.x Servers
Articles and Tips: article
Primary Support Engineer
Novell, Inc.
bratliff@novell.com
01 Dec 2001
This AppNote discusses numerous ways to enhance the efficiency and availability of Novell NetWare servers. Although the recommendations in this AppNote are geared towards NetWare 5.x servers, NetWare 4.x servers would also benefit from any applicable settings, especially those in the Performance/Tuning section.
- Introduction
- Keeping Up-to-Date with Patches
- Performance Tuning
- Time Synchronization
- Service Location Protocol (SLP)
- Schema
- Miscellaneous Checks and Actions
- Conclusion
|
Topics |
NetWare 4.x, NetWare 5.x, eDirectory, performance tuning, SLP, time synchronization |
|
Products |
Novell NetWare |
|
Audience |
network administrators |
|
Level |
intermediate |
|
Prerequisite Skills |
NetWare server support, implementation, and administration |
|
Operating System |
NetWare 4.x, 5.x |
|
Tools |
DSREPAIR, MONITOR, SERVMAN |
|
Sample Code |
no |
Introduction
If you are like most network administrators, it has been a long time since you installed the NetWare servers that are currently in production in your computing environment. Or, when you install new servers, you simply accept the default settings. Either way, the server parameters are usually not tuned for maximum performance in your environment. If your servers are experiencing abnormal behavior like high utilization, losing time synchronization, excessive dirty cache buffers, numerous pending disk requests, slow replica synchronization, or even Abends (Abnormal End errors), the problem is most likely not with the robust operating system you are running, but with the limited boundaries under which you are allowing it to run. NetWare can handle a tremendous amount of work if given the appropriate environment to do so.
This AppNote provides a detailed outline of some of the major tuning parameters and other factors that affect server performance. When these parameters are set properly for your environment, they will ensure that your NetWare servers are running as efficiently as they can and providing the highest availability possible.
Keeping Up-to-Date with Patches
Installing every patch Novell puts out is certainly unadvisable. You should only install a patch if you are experiencing the exact problem the patch resolves. However, some patches are critical for everyday server operations and are therefore considered a must to install.
The following is a list of patches that are required for the specified operating system versions.
NetWare 4.x
NW4SP9 (NetWare 4 Support Pack 9)
TSA5UP7 (patches and updates for NetWare SMS Services)
NetWare 5.0/5.1
NW5SP2A (NetWare 5 Support Pack 2a) along with:
OS5PT2A (updated SERVER.EXE to resolve Pentium III issue)
FLSYSFT3 (updated FILESYS.NLM for NetWare 5.x)
NICID157 (NICI crypto upgrade v1.5.7 - domestic)
TSA5UP7 (patches and updates for NetWare SMS Services)
WSOCK4F (Winsock update for NetWare 5.0/5.1)
or
NW51SP3 (NetWare 5.1 Support Pack 3)
WSOCK4F (Winsock update for NetWare 5.0/5.1)
Note: Patches can become outdated rather quickly. Check Novell's technical support Web site at http://support.novell.com regularly for the latest patches.
Performance Tuning
Because the default settings for NetWare servers are inadequate for many environments, performance tuning is a must. The settings listed in this section are recommended for all NetWare 4.x and 5.x servers. These settings will sustain you through NetWare 5.1 with eDirectory 8.5 (DS 85.xx).
Note: If your server settings have already been changed for a specific reason to values greater than those recommended in this AppNote, leave them as they are.
With any of the recommended changes in this AppNote, you should monitor the server performance for a short period of time after they are made. If your servers are already registered with an SLP Directory Agent, you will have to "bounce" the server to get it to re-register with your changes. Other settings will be activated either immediately or at the next reboot. After a few days, look at your Free Cache Buffers (% Free) and LRU sitting time. The LRU sitting time should be no lower than 30 minutes. If it is, you need to add memory.
Note: Although most of these settings are dynamic, some require a reboot of the server. Be sure to schedule the reboot at a time when it will not impact your production environment.
Important: When making these changes on a NetWare 5.x server, the settings will be stored in a registry file on the local drive of the server. Remember to comment out or remove any exact settings that may be in the server's AUTOEXEC.NCF file.
Detailed descriptions of NetWare SET parameters can be found online at http://www.novell.com/documentation/lg/nw5/usreflib/utlrfenu/data/hgdzhwr7.html.
Communications
Maximum Pending TCP Connection Requests = 4096
Maximum Packet Receive Buffers = 10000
Minimum Packet Receive Buffers = 3000
Maximum Physical Receive Packet Size = 2048
This packet size setting is for Ethernet environments only. If you have a different topology, set the value accordingly.
Directory Caching
Maximum Concurrent Directory Cache Writes = 500
Directory Cache Allocation Wait Time = 1 sec
Directory Cache Buffer NonReferenced Delay = 30 sec
Maximum Directory Cache Buffers = 200000
Minimum Directory Cache Buffers = 1000
Maximum Number Of Internal Directory Handles = 1000
Maximum Number Of Directory Handles = 100
Disk
Enable Disk Read After Write Verify = OFF
File Caching
Minimum File Cache Buffers = 200
Maximum Concurrent Disk Cache Writes = 2000
Dirty Disk Cache Delay Time = 0.5 sec
File System
Deleted Files Compression Option = 0
If you are experiencing high utilization situations, you might consider turning OFF compression for deleted files, depending on how often you purge your deleted data. The default setting is 1 (ON), which will cause the server to compress deleted files that have not been purged.
Licensing Services
NLS Search Type = 1
Store NetWare 5 Conn SCL MLA usage in NDS = Off
The MLA usage switch is for MLA (Master License Agreement) customers only. Regular and CLA customers will need to leave this ON.
Locks
Maximum Record Locks Per Connection = 10000
Maximum Record Locks = 100000
Miscellaneous
Minimum Service Processes = 100
Maximum Service Processes = 750
New Service Process Wait Time = 1 sec
CPU Hog Timeout Amount = 1 min
Upgrade Low Priority Threads = OFF
Note: Leave the Upgrade Low Priority Threads parameter set to ON if you have a NetWare 4.x SMP server. If you have a NetWare 5.x server that is not running multiple processors, look at the MODULES list and in the STARTUP.NCF file to make sure you unload all SMP/MPK modules. These should have a *.PSM extension.
NCP
NCP Protocol Preferences = TCP UDP IPX
Client File Caching Enabled = OFF
Consider turning this parameter OFF if you still experience high utilization after applying the settings in this AppNote to your servers. This parameter allows for "Client" Open files to be cached at the server.
Service Location Protocol
SLP DA Discovery Options = 4
SLP Cache Timeout = 1800
SLP Scope List = GLOBAL
This implies that you have a STATIC scope called GLOBAL. If not, apply the STATIC scope name.
Note: You will need to have a "named" scope to support SLP v2.0!
Novell Storage System (NSS)
To optimize the performance of any NSS volumes, type the following commands at the console prompt:
NSS /NameCacheSize=64000
NSS /ClosedFileCacheSize=1536
NSS /CacheBalance=20
Make sure your server has adequate memory for the CacheBalance setting.
Additional Parameters
Packet Type 20 = 0
This setting can be changed in INETCFG if your LAN drivers are configured there. If not, you can modify it by typing Set NetBIOS Replication Option = 0 at the console and then FLUSH CDBE.
IPX Sockets = 10020
This setting can be changed in INETCFG if your LAN drivers are configured there. If not, add the following to your AUTOEXEC.NCF file: LOAD SPXCONFG Q=1 I=10020
SET Maximum Concurrent Opens Per File and Connection =1000000
SET TCP IP Maximum Small ECBs = 65534
Set this parameter at the console, then type "FLUSH CDBE".
Important: After above changes are made, type FLUSH CDBE at the console prompt of every NetWare 5.x server to write the changes to the registry file. The FLUSH CDBE command can be done after any parameter changes. If you make changes and for some reason the server is not shut down gracefully (via the DOWN command), the settings will not be saved.
Here's a helpful hint for NetWare 5.x servers. You can create an .NCF file with all the above settings and then push it out to all your servers. Remember to put FLUSH CDBE at the end of the .NCF file and remove any "like" parameters from the AUTOEXEC.NCF file.
Time Synchronization
Time synchronization is very important to the stability and health of your network and Directory Services. Server time should be checked periodically and definitely before any replica or partition operations.
Important: The types of Time Providers are Reference, Single, and Primary time servers. As a general rule, networks with less than 40 servers should only have one Single time provider. Also be careful not to have too many Primary time servers (no more than 16 per Reference server) and limit your tree to only one Reference time provider.
The latest TIMESYNC.NLM can poll NTP time sources and, if such a time source is available, it should be configured to do so. You might want to find out if your network contains a Unix box or other system that already gets its time from an atomic clock source. If so, point the Reference server to it; if not, you can use one or more of the following:
MIT - 129.7.1.66:123
NIST Central Computer Facility - 129.6.16.36:123
Sony - 198.93.3.1:123
Note: For all servers with IP, set the last server in the configured time source list as TIME SOURCE = 127.127.1.0. This is the Loopback address for TIMESYNC.NLM. For NetWare 4.x or 5.x servers without IP, put the server name instead of the IP address in the time source list.
Following are the recommended SYS:SYSTEM\TIMESYNC.CFG files for the different types of time servers.
For a Reference time server:
Configured Sources = ON Directory Tree Mode = ON Hardware Clock = ON Polling Count = 3 Polling Interval = 600 Service Advertising = ON Synchronization Radius = 2000 Type = REFERENCE # TIMESYNC Configured time source list TIME SOURCE = 129.6.16.36:123 (or your favorite NTP source) TIME SOURCE = (1 PRIMARY) TIME SOURCE = 127.127.1.0
For a Primary time server:
Configured Sources = ON Directory Tree Mode = ON Hardware Clock = ON Polling Count = 3 Polling Interval = 600 Service Advertising = ON Synchronization Radius = 2000 Type = PRIMARY # TIMESYNC Configured time source list TIME SOURCE = IP_address_of_Reference_server TIME SOURCE = (1 PRIMARY) TIME SOURCE = 127.127.1.0
For all Secondary time servers:
Configured Sources = ON Directory Tree Mode = ON Hardware Clock = OFF Polling Count = 3 Polling Interval = 600 Service Advertising = ON Synchronization Radius = 2000 Type = SECONDARY # TIMESYNC Configured time source list TIME SOURCE = (1 PRIMARY) TIME SOURCE = 127.127.1.0
Time Synchronization Checklist
Following is a Time Synchronization checklist:
Create a TIMESYNC.CFG file and push it out to all corresponding servers (Reference, Primary, Single, and Secondary).
At the console prompt, type "UNLOAD TIMESYNC" and then "LOAD TIMESYNC".
Load DSREPAIR and check Time Synchronization.
Note: If you are experiencing yo-yo problems (time synchronization lost and established repeatedly) or significant time drift problems, the SET Timesync Correction Floor parameter could help. Issue the following command at the console prompt of each server: SET Timesync Correction Floor = 200.
TIMSYNC is currently being engineered to support a complete NCP protocol infrastructure, multiple NCP time sources, and many other enhancements. Keep checking Novell's Web site for new versions and modify your environment accordingly. Most importantly, if you experience time drifts and servers being out of time synchronization, you should look at redesigning your network's time synchronization setup and upgrading to the latest version of TIMESYNC.NLM.
Service Location Protocol (SLP)
SLP design is crucial for a NetWare 5.x Pure IP environment, even if you still have IPX on your servers. The basic configuration is to create a Directory Agent (DA) with a static scope named GLOBAL (this could be any name except for "Unscoped"). All of the NetWare 5.x IP servers will have an SLP.CFG file that advertises its resources to the DA, including the server hosting the DA.
Note: There is no room in this AppNote to even begin to explain the complexities of SLP in the NetWare environment. For further information on SLP design, reference TID #10062474 at http://support.novell.com.
SLP Checklist
Following is an SLP checklist:
Verify that all NetWare servers running IP are in your DNS (Domain Name System).
Note: Check the HOSTS file in the SYS:ETC directory and make sure it has no alias of the server.
Create a DA with a Static scope. Make sure the server that hosts the DA has a replica of the partition containing the DA object and SLP Scope.
Create a SYS:\ETC\SLP.CFG file containing the following line:
DA IPV4, IP_address_of_DA
Distribute the SLP.CFG to all servers (including the DA server) participating in SLP.
Verify that the Discovery Option is set to 4 on all servers participating in SLP. (This change may have been made while implementing the recommendations listed in the Performance Tuning section of this AppNote.)
Schema
The Schema should not be overlooked or underestimated, as it contains the rules that govern all objects in an eDirectory tree. It must be identical on all servers throughout the tree. Here is a quick way to check the consistency of your Schema.
From the server containing the Master replica of the tree's [Root] partition, issue the following commands at the console prompt:
SET DSTRACE=ON
SET DSTRACE=NODEBUG
SET TTF=ON
SET DSTRACE=*R
SET DSTRACE=+SCHEMA
SET DSTRACE=*SSD
SET DSTRACE=*SSL
SET DSTRACE=*SSA
Watch the DSTRACE screen until the synchronization completes, then type SET TTF=OFF. You now have a DSTRACE.DBG file in the SYS:SYSTEM directory that shows you the status of Schema Synchronization in your tree. If the file reports that the Schema did not synchronize on some servers, you need to fix this problem immediately. Begin fixing any problem servers by running a local repair with the Rebuild Operational Schema option set. You can also issue a Reset Local Schema command.
Miscellaneous Checks and Actions
This section contains a conglomeration of miscellaneous server checks and actions to further ensure the efficiency and availability of your network servers. As with any server changes, schedule them for a time when they will not affect users in a production environment.
DS Versions
Make sure you don't have more than two DS versions in your tree. The current versions as of 21 November 2001 are:
DS 6.13
DS 7.55e
DS 8.77g
DS 85.20c (eDirectory)
Obituaries
Stuck and orphaned obituaries in eDirectory can occur because of several reasons, but most often are the result of poor communication. While some of these are harmless, others can prevent you from doing any partition and replica operations. The detrimental types are Inhibit_Move (TYPE 3) or Move_Tree (TYPE A) obituaries.
The following DSREPAIR option will check your servers' external references and report any Obituaries:
LOAD DSREPAIR -A | Advanced Options | Check External References
If any Obituaries are detected, report them as soon as possible.
External Reference Objects
To ensure that you have no corrupted or invalid external reference/backlinked objects, you can zero them out and recertify them. Here are the steps to do this:
Type "LOAD DSREPAIR -XK3 -RD" and wait until it finishes.
Type "SET DSTRACE=*B".
To view the backlinks being recertified, type the following commands and switch to the DSTRACE screen:
SET DSTRACE=ON
SET DSTRACE=NODEBUG
SET DSTRACE=+BLINK
Bindery Emulation
Bindery emulation was added to NetWare 4.x for backwards compatibility with the NetWare 3.x bindery. This emulation was intended for short-term use during migration until customers had transitioned all of their bindery connections to NDS. Since Bindery-related traffic can cause high utilization and sluggish performance, you should try to minimize Bindery traffic.
If you have bindery emulation requirements, you can monitor the load by filtering on the Bindery Emulation traffic using DSTRACE. Enter the following commands at the console prompt:
SET DSTRACE=ON
SET DSTRACE=NODEBUG
SET DSTRACE=+EMU
This filter will allow you to see Bindery Emulation traffic on the server. If the traffic is significant, you should re-evaluate the need for Bindery connections such as printers and users and replace them with NDS-enabled versions wherever possible.
Replica Placement
If your NDS tree was designed some time ago, you should re-evaluate the design. You should have the standard three replicas of every partition for redundancy. Another good thing to do, wherever possible, is to limit the number of Subordinate References on the network.
Repair Network Addresses
After making any SLP or protocol changes, it is a good idea to repair all network addresses, as NetWare uses these to resolve requests to other servers.
To do this on NetWare 5.x servers, type "LOAD DSREPAIR -A" and then select Advanced Options | Servers Known To This Database. Press <Enter> on any server, and then select Repair All Network Addresses.
Purging Deleted Files
Although many network administrators have different ideas about purging deleted files, I recommend that you purge all volumes at least once a month. I also recommend that you flag volumes and directories to Purge Immediate on GroupWise Queue Directories, Print Queue Directories, and BorderManager/ICS Cache Volumes.
Search Policies
The optimum configuration if you are using ZENworks for Desktops is to locate the Policy objects in the partitions where you need them and have the Search Policy option go only to the Root of that partition. This will eliminate a lot of unnecessary tree walking and will improve client performance.
Note: The NetWare Client 3.3 ignores ZENworks Workstation Manager search policies unless you apply Client 3.3 SP3.
High Utilization from NDS
High utilization on a server can be caused by excessive values being stored in the WM:Registered Workstation attribute. This is caused by NetWare Clients adding multiple values to a container's WM:Registered Workstation attribute. If the ZENworks Workstation Manager component of the NetWare Client is installed, the Client will add a cookie to the user's container to register the workstation for importation. If the workstation is not imported, the Client will continue to add values to this attribute, even though it is not visible using NWAdmin32. A value is added each time a user in the container logs in. If the number of values added becomes large, NDS synchronization of these multiple values can cause the server to experience high utilization.
To check for too many values on the WM:Registered Workstation attribute, type "LOAD DSREPAIR -CV100" at the server console and then review the DSREPAIR.LOG file.
To remove the multiple values, run "DSREPAIR -WM" and repair the local database.
Backing Up Directory Services
Last, but certainly not least, is the "DSREPAIR -RC" option that creates a backup of your Directory Services information. The file(s) are stored on the server's SYS volume. You cannot restore these files on your own, but if you experienced a major disaster a Novell technician can restore them. I recommend that you run this option nightly if you can, but at the minimum once a week. This option will lock the NDS database, so schedule this backup operation carefully.
Conclusion
With so many administrators performing upgrades to servers and experimenting with all the exciting new technology Novell is coming out with, it is easy to forget the pillars of Novell networks: the servers themselves. This AppNote has addressed some areas relating to performance that may have been overlooked or forgotten. It will also serve as a guideline for setting up new servers and standardizing existing ones. Above all, the recommendations herein will help your NetWare servers deliver the highest availability possible in your environment.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.