NDS eDirectory Design, Implementation, and Maintenance Guidelines
Articles and Tips: article
Corporate Technology Strategist
Novell Systems Engineering
jutaylor@novell.com
01 May 2000
Thanks to all those at Novell who contributed to this document: Blair Thomas, Jeff Hughes, Richard Moore, Duane Bourgeois, Vince Hanchon, Doc Hodges, Darin Cable, Gary Anderson, Maurice Smulders, Ty Hendrickson, Paul Corriveau, Mark Greer, Ed Anderson, and Nick Nikols.
The X.500 directory services standard that was created in 1988 had a great deal of promise, but yielded little in the way of practical application. Novell was one of the first companies to see the vision of what directory services were capable of, and in 1992 introduced the concept of using directory services in the corporate networking world. The solution that Novell delivered has since become the standard for managing enterprise networks: Novell Directory Services (NDS).
Since its initial release eight years ago, NDS has continued to evolve to meet changing customer needs. NDS eDirectory is the latest evolution of NDS. Based on NDS v8 that was released in May of 1999, NDS eDirectory delivers a "Full Service Directory" that provides for flexible and extensible discovery, rich security tools, an extremely scalable storage engine, and the ability to manage relationships, whether they be internal or external to your organization.
Over the years, many design documents have been created to address how NDS trees should be designed, implemented, and maintained. With the recent release of Novell's new NDS eDirectory solution, there is a need for some updates in the area of design guidelines. This AppNote presents new design, implementation, and maintenance recommendations for NDS eDirectory--both for corporate networks and in the arena of Internet-based e-business and identity/profile management.
This information is adapted from a document entitled "NDS eDirectory Design 2000". This document, along with other information about NDS eDirectory, can be found on Novell's NDS Web site at:
http://www.novell.com/products/nds
NDS eDirectory Design
Many factors contribute to a properly designed NDS environment. Some are technological, while others are political or cultural. In all cases, however, there are certain design-related questions that need to be answered. These include:
How many trees should I create?
How large a tree can NDS eDirectory sustain? What does Novell recommend?
Where should I partition the tree?
Should I have few or many replicas of my partitions?
How will my design affect application usage?
This section will answer these questions.
Note: Throughout this document, the terms NDS and NDS eDirectory are used interchangeably. Unless otherwise noted, NDS eDirectory is the version of NDS that is being discussed. Care should be taken when applying these guidelines to previous versions of NDS.
Number of Trees
Since the release of NDS, Novell has been of the opinion that a single tree works best for the majority of organizations. After all, a directory service is designed to represent a particular organization, which is typically a single entity. Novell itself is a worldwide organization that spans the globe with a single NDS tree. The benefits of one tree include a single user identity on the network, simpler administration of security, and a single point of management.
Note: This recommendation for a single tree for business use does not preclude creating additional trees for testing and development purposes.
Some organizations may decide that they need to have multiple trees. For example, an organization that is made up of several autonomous business units may have a need to create more than one tree. Such a requirement may derive from legal needs or corporate cultural aspects when dealing with worldwide organizations. Lastly, there may be political or "authoritative" bounds within an organization that need to be respected to the point of having separate trees.
While this AppNote deals mainly with how to design NDS eDirectory in single-tree environments, Novell is currently developing several integration solutions to aid its customers who need to have multiple trees. These solutions include DirXML and NDS Federation.
DirXML. DirXML is Novell's solution for enterprise-wide directory integration. This allows for organizations with multiple NDS tree or other directories to synchronize data between them. Using the Extensible Markup Language (XML), administrators can create rules that dictate the business logic of how and what information should be shared between directories.
Figure 1 demonstrates a user named "John" being synchronized between two NDS eDirectory trees. The new user John in the ACME_HQ tree can now be granted rights to resources in the new tree. The NDS-to-NDS driver that ships with DirXML even allows for passwords to be synchronized between trees in the form of RSA public/private keys.
Figure 1: DirXML synchronizes data from one tree to another.
DirXML is not limited to just synchronizing between NDS eDirectory trees. It can also integrate disparate directories such as Microsoft's Active Directory, Netscape's iPlanet Directory Service, Microsoft Exchange, and Lotus Notes. Third parties, ISVs, and internal developers can also create custom drivers using the Novell DirXML Driver Toolkit.
For more information on DirXML, visit Novell's NDS Web site at http://www.novell.com/products/nds.
NDS Federation. For those customers who do not want to synchronize data between trees but still want to grant users access to resources in another tree, Novell's NDS federation solution will allow users in one tree to be granted access to resources in another (see Figure 2).
Figure 2: NDS Federation allows objects in one tree to be granted rights in another tree.
NDS Tree Size
In NDS eDirectory, tree size limitations are a thing of the past. While in previous versions of NDS it was common to be wary of tree size due to database scalability, NDS eDirectory has been tested to over 1 billion objects in a single tree, making it the most scalable directory service on the planet. The only limitations to tree size in NDS eDirectory are physical disk space and disk input/output speeds.
Here is some information that will help you determine your disk size and memory requirements. A typical object in NDS eDirectory is 3 to 5 kilobytes (KB) in size. Using this number, you can quickly calculate disk space requirements for the number of objects you desire. It is important to realize that this is an estimate based on average NDS implementations. Your disk space needs may differ depending upon how many attributes are filled with data and what that data is. If objects will hold BLOB (binary large object) data such as pictures, sounds, or biometrics, the object size will grow accordingly.
Tech Tip: The NDS eDirectory database is sometimes referred to as a DIB Set. DIB is an acronym for Directory Information Base. To determine the size of your DIB Set, you can do the following: For NetWare, download TOOLBOX.NLM from Novell's Website. This will allow you to see the SYS: _NETWARE directory on your server. For Windows NT, you can find the DIB Set at \NOVELL\NDS\DIBFiles. For Sun Solaris, the DIB Set location may vary depending on the path you specified during the installation.
Partition Boundaries
One of the unique features of NDS is its ability to be segmented into smaller pieces called partitions, while still maintaining a single namespace. Over the years, Novell has recommended that these partition boundaries be created for two reasons:
To minimize traffic over WAN Links. A typical NDS tree design consists of top-level organizational units (OUs) representing the different geographic areas that the business operates in. This design permits organizations to segment the namespace into partitions at the geographic level. Subsequent partitions can then be placed on the appropriate servers in each location. It is crucial to note that this recommendation does not reflect any limitation of NDS, but is a design guideline to ensure that replication traffic between different sites does not unnecessarily consume precious WAN bandwidth.
To limit partition size. In previous versions of NDS, the size of the partition was another important consideration. Since the underlying database was not practical for large partitions of 10,000 or more objects, it was recommended that additional boundaries be created to limit the partition size.
NDS eDirectory no longer has these limitations, due to its highly scalable backend. For NDS eDirectory, Novell recommends the following design limits for partitions:
|
Limitation
|
Recommendation
|
|
Partition size |
Unlimited number of objects |
|
Total number of partitions in tree |
Unlimited |
|
Number of child partitions per parent |
150 partitions |
|
Number of replicas per partition |
50 replicas |
|
Number of replicas per Replica Server |
250 replicas |
These rules generally apply to distributed environments such as corporate enterprises. They may not apply to eBusiness scenarios, as typical eBusiness uses require that all the data be stored on a single server. This is common in white page solutions and when using NDS to provide authentication and identity management over the Internet. In most cases, eBusiness systems will have a single partition with all the data within it, since everything needs to be on the same server. (See the "Replica Placement" section for additional information.)
Novell's next release of NDS eDirectory (code-named "Tao") will allow for filtered replicas that can contain a subset of objects and attributes from different areas of the tree. This will solve the same eBusiness needs without requiring that all data be stored on the server. (See the "Application-Specific Design Issues" section for additional information.)
Tree design will favorably or adversely affect your ability to create an effective partitioning strategy. You should always follow these rules:
Design the top of the tree based on the WAN infrastructure.
Design the bottom of the tree based on the organization of network resources.
Partition the top of the tree based on the WAN infrastructure.
Do not create a partition that spans your WAN infrastructure. (In other words, "Don't span the WAN.")
Figure 3 shows an example of how to follow these design rules in a corporate network environment.
Figure 3: NDS eDirectory corporate tree design example.
When designing a tree for eBusiness use, most of these rules are not needed. Since there is no real way for you to know where a particular user is coming in from over the Internet, the typical eBusiness deployment of NDS eDirectory involves storing all the data on a single server. With this type of design, you would have a relatively shallow and flat structure.
Note: Even though eBusinesses need to have all the data on a single server, this does not negate the need to replicate the data for fault tolerance and load balancing.
Replica Placement
The placement of replicas is extremely important for two reasons: accessibility and fault tolerance. As more and more data is stored in NDS, the value of NDS grows. From an accessibility standpoint, that data needs to be available as quickly as possible, and subsequently needs to be copied in several places to ensure accessibility and fault tolerance.
The basic rules of NDS eDirectory replica placement are as follows:
Replicate locally first. Keeping two to three replicas at the local site. In each case, there should be at least two local replicas of the local partition if possible. There is no need for more than three replicas unless you want to provide for accessibility of the data at other locations. This could also be done in eBusiness cases where the directory information is being accessed by countless numbers of users and you want to have multiple instances of the data for load balancing.
Keep the master replicas in central locations. It may seem logical to keep masters at the remote site. However, since master replicas are used for partition operations (such as creating a new partition or merging a partition), it is wise to keep them where the partition operation will occur. Novell recommends that operations such as partitioning be handled by one person or administrative body in a central location. This ensures that errors are not made that could have adverse effects on NDS operations. This methodology also provides for a central backup of the master replicas.
Replicas should only be placed in non-local sites for three reasons: (1) to ensure fault tolerance if you are not able to have the recommended two or three local replicas, (2) to provide for accessibility, and (3) to provide for centralized management and storage of master replicas. This will help to ensure that replication traffic is controlled and limited over slow WAN links. If you are replicating the master replicas to a remote site or are forced to place replicas over the WAN for accessibility or fault tolerance purposes, be mindful of the bandwidth that will be used for replication. It is wise to utilize Novell's WAN Manager (WANMAN) tool to control the replication of NDS eDirectory traffic over WAN links.
Figure 4 demonstrates these basic rules of NDS eDirectory replica placement. In this example, notice that all masters are stored on a server named PRV-DSMSTR. It is a common practice in large environments to have a central master server that holds all the master replicas of your tree.
Figure 4: NDS eDirectory basic replica placement.
Application-Specific Design Issues
NDS eDirectory serves as a data store that many applications retrieve data from. Application needs may therefore affect some of the aspects of NDS eDirectory design, usually those dealing with partitioning and replication. Applications typically function better when all the data they will need is quickly available. This may affect your replication design, since you would have to take this into account.
To help in this area, Novell is currently creating a new replica type known as the "filtered replica" (see Figure 5). This type of replica allows for an administrator to create a replica that is both sparse(contains only the objects classes that you specify) and fractional(only holds the attributes you specify). This allows applications that need a global view of the data stored in NDS eDirectory to get fast response without requiring referrals to other servers.
Figure 5: NDS eDirectory corporate tree design example.
Solutions that will benefit greatly from filtered replicas include DirXML and Novell's eGuide, an LDAP white pages application. For more information regarding Novell's eGuide solution, visit the product Web site at http://www.novell.com/products/eguide.
NDS eDirectory Implementation
After an effective design, the next step with NDS eDirectory is the proper implementation. In this section we will cover hardware requirements, new ways to ensure load balancing, and parameter settings for tuning NDS eDirectory.
Hardware Requirements
Determining hardware requirements for NDS eDirectory is a difficult issue because each implementation is different. For example, a base install of NDS eDirectory with the standard schema requires roughly 74 MB of disk space for every 50,000 users. But if you were to add a new set of attributes or completely fill in every existing attribute, the object size will grow. This will affect the disk space, processor, and memory requirements.
Tech Tip: For best results, try to cache as much of the DIB set as possible. The ideal is to get as close to a 1:1 ratio of DIB size to memory as possible.
As far as processor requirements are concerned, NDS scales well on a single processor. NDS itself is not processor intensive, but it is network I/O intensive. On the other hand, DSREPAIR is disk and processor I/O intensive. Adding processors in a NetWare-on-Intel implementation yields dramatically better performance with NDS eDirectory.
Here are the hardware recommendations for typical Intel-based implementations (NetWare, Windows NT, and Linux).
|
Objects
|
Processor
|
Memory
|
Hard Disk
|
|
100,000 |
Pentium III 450-700 MHz (single) |
384 MB |
144 MB |
|
1 million |
Pentium III 450-700 MHz (dual) |
2 GB |
1.5 GB |
|
10 million |
Pentium III 450-700 MHz (two to four) |
2 GB + |
15 GB |
Here are the hardware recommendations for typical Sparc-based implementations (Solaris).
|
Objects
|
Processor
|
Memory
|
Hard Disk
|
|
100,000 |
Sun Enterprise 4500 |
384 MB |
144 MB |
|
1 million |
Sun Enterprise 5500 |
2 GB |
1.5 GB |
|
10 million |
Sun Enterprise 6500 with multiple processors |
2 GB + |
15 GB |
Remember that processor requirements may be greater depending upon additional services available on the server and the number of authentication reads and writes the server is handling. Items such as encryption and indexing can be processor intensive. Additional memory will always help since NDS will be able to cache more of the directory into memory. Hard disk space suggestions are based upon 74 MB for every 50,000 users. As mentioned before, as new attributes are added to the directory and are subsequently utilized, the requirements will increase to handle the load.
Load Balancing
Load balancing for NDS in a corporate environment is typically not a problem. NDS works extremely well in these environments and even in the case of older versions works well with large global, highly distributed trees. This is taken care of via replication on multiple servers. Using the Novell Client32, administrators can setup default servers to help control the authentication and NDS resource utilization as needed. Novell's ZENWorks solution for desktop management can help in this regard as well.
In the area of Internet and eCommerce deployments such as white pages, portals, content management, identity management and profiling, several new methods can be used to get high performance for eCommerce applications.
DNS Round Robin. For eBusiness solutions where users and applications are using the Internet to retrieve services, a DNS Round Robin configuration will work well (see Figure 6). This involves entering multiple IP addresses for a given host within DNS. Most DNS servers will then respond with one of the IP addresses doing this in a round robin.
Figure 6: DNS round robin.
Applications that utilize NDS eDirectory will use the IP address that is returned by DNS to access NDS eDirectory off of the appropriate server. This method provides for dynamic changes and in most cases will work fine.
Static Configuration. The one flaw with the DNS Round Robin is the added latency (delay) of the DNS response. To get around this, you can statically map different services to individual NDS servers in your environment or create a process that will do this locally without resolving to the DNS server.
Tuning NDS eDirectory
Tuning NDS is extremely important. Even with the best hardware that money can buy, it will not perform to its full potential unless it is properly tuned.
The following is a list of settings that will optimize NDS eDirectory for a variety of uses. These parameters are recommended for NetWare implementations:
|
Setting
|
Recommendation
|
|
Maximum Pending TCP Connection Requests |
4096 |
|
Maximum Packet Receive Buffers |
10,000 |
|
Minimum Packet Receive Buffers |
3000 |
|
Maximum Physical Receive Packet Size |
2048 |
|
Maximum Concurrent Disk Cache Writes |
2000 |
|
Dirty Directory Cache Delay Time |
0 |
|
Maximum Concurrent Directory Cache Writes |
500 |
|
Maximum Directory Cache Buffers |
200,000 |
|
Maximum Number of Internal Directory Handles |
1000 |
|
Maximum Number of Directory Handles |
100 |
|
Maximum Record Locks Per Connection |
10,000 |
|
Maximum Record Locks |
100,000 |
|
Maximum Outstanding NCP Searches |
500 |
|
Enable File Compression |
Off |
|
Immediate Purge of Deleted Files |
On |
The setting that most affects NDS eDirectory performance is the cache. With NDS, administrators can configure the amount of RAM that will be used as cache. As mentioned before, you should try to get as close to a 1:1 ratio of cache to DIB Set as possible. For best performance, exceed this ratio.
To set the cache level, perform the following operation on your NDS server:
|
Platform
|
Location
|
Steps
|
|
NetWare |
Console screen |
Enter this command:Set DSTRACE=!MB<amount of RAM to use in MB< |
|
Windows NT |
_NDSDB.INI |
Create a _NDSDB.INI file in the \Novell\NDS directory. Enter this command:CACHE= amount of RAM to use in MB |
|
Solaris |
ndstrace screen |
Launch ndstrace from the Sun Solaris server. Enter this command:Set DSTRACE=!MB<amount of RAM to use in<MB< |
NDS eDirectory Maintenance
After the design and implementation are complete, the final step is the maintenance of your design implementation. In this section we will cover disaster recovery, keeping NDS eDirectory healthy, and monitoring NDS.
Disaster Recovery
There are several important considerations regarding the issue of backup and restore. The usual purpose for providing backups is to restore the data when a server fails. This is the standard consideration for environments such as file services or standard databases. One of NDS's distinctive advantages is the survivability of the data that NDS contains. This is again one of the reasons for replication. Standard operating procedure in most organizations is to utilize the directories replication services as the primary form of fault tolerance. Organizations that need higher levels of fault-tolerance can utilize Novell Clustering Services for NetWare to provide high availability of their NDS data.
Novell recommends that all customers use a combination of replication and off-line backups to protect their directory data. An off-line backup at regular intervals is the only way to insure that the tree can be restored in the event of a catastrophic disaster. Remember that replication while automatic and very reliable is not fool proof. If there is a severe disruption in the tree it may be replicated to the other replicas. Also, a user with the rights to delete vast portions of the tree could accidentally destroy large numbers of records and an off-line backup would be required to retrieve the data.
It is important to choose the right strategy for your backup needs as well as the appropriate software and hardware. Administrators can perform three types of backups in their environments:
Full. A full backup backs up all data in the directory regardless of whether it has changed. If you are mostly concerned with ensuring that all the data is safe, a full backup is the preferred method. Full backups are easy to restore since it will be one set of media. However, to back up a large tree will take considerably longer than to simply back up the changes. Restorations will also be longer since you are restoring all of the data.
Incremental. Incremental backups back up only the data that has changed since the last full backup. These types of backups get progressively longer since theoretically more and more data will be backed up every day. When it comes time to restore the tapes, you will need the last full backup and the incremental tape.
Differential. In this form of offline storage, the backup records only changes made since your last backup. If you are looking to have the fastest backup speed, differential is your best choice. However, you will pay during the restoration portion of the process since you will need to restore the last full backup and all the differential backups since the last full backup. This typically involves using numerous tapes to get all the changes from the last full backup.
The question is not which backup method you should use, but what your strategy will be to actually perform the backup. Your strategy will depend on whether your organization is distributed, centralized, or both. You should also consider whether each site needs to have its own backup or whether one backup at a central point can suffice. Figure 7 summarizes the three backup strategies.
Figure 7: NDS eDirectory backup strategies.
One large Novell customer uses a model of a maintenance replica that backups and maintenance are run against. This replica can be taken offline for quick repairs (for example, telling DSREPAIR to "Lock the Database") and is the central point for backups using Legato on NetWare and backing up to a disk farm running on Solaris.
Note: DSREPAIR is Novell's multi-platform directory maintenance utility. On NetWare, load DSREPAIR.NLM. On Windows NT, launch DSRepair from the NDS Services icon in Control Panel. For Solaris and Linux, run ndsrepair. Keeping NDS eDirectory Healthy
The health of the directory service is vital to any organization that is deploying it in any fashion. The tools and techniques used to keep NDS healthy are well documented in Novell's Certified Directory Engineer (CDE) Course 991: Advanced NDS Tools and Diagnostics. This course is currently available from any Novell Authorized Education Center (NAEC). In this course you will learn how to:
Perform NDS health checks
Perform NDS operations properly
Properly diagnose, troubleshoot, and resolve NDS issues
Utilize NDS troubleshooting tools and utilities
To learn more about this course and about Novell's new Certified Directory Engineer certification program, or to find an NAEC near you, visit the Novell Education Web site at http://education.novell.com.
Novell Consulting Services also provides NDS eDirectory Health Checks for customers. More information on this option can be obtained at http://services.novell.com.
Monitoring NDS
A healthy NDS tree is usually the product of a strong monitoring strategy. There are two approaches to monitoring NDS: reactive and proactive.
The reactive approach involves simply responding to problems. For example, when users can't access a particular part of the tree, an IS engineer attempts to find out why by monitoring NDS, usually via the DSTRACE utility on the appropriate platform.
The proactive approach involves closely monitoring the NDS operations over time to create baseline performance figures that can be used when troubleshooting or when making decisions regarding future enhancements.
Novell recommends proactive monitoring of NDS whenever possible. The DSTRACE utility now runs on NetWare, Windows NT, Solaris and Linux. This tool will assist in the monitoring of the vast resources of NDS eDirectory. However, it is usually wise to invest in third-party products that Novell's partners create. These tools allow for proactive management of your NDS eDirectory environment. Here are a few of these partners.
BindView--http://www.bindview.com
Blue Lance--http://www.bluelance.com
NetPro--http://www.netpro.com
For more information on Novell's partners, visit the Novell partners Web site at http://www.novell.com/partners/novell.html.
If you need to monitor or audit certain characteristics of NDS for which our partners do not provide the necessary tools, Novell Consulting Services can leverage the Novell Event System to provide customized assessment and auditing solutions that precisely fit customer needs.
Conclusion
NDS has come a long way since its inception some eight years ago. In this age of the Internet and eBusiness, NDS eDirectory has become a powerful tool of change in a world that is changing rapidly. Novell will continue to update NDS eDirectory to meet the changing needs of both corporate networks and eBusiness environments. As NDS progresses, this document will be updated to include new recommendations as necessary to ensure your continued success with NDS eDirectory.
* 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.