3
Planning and Deployment Guidelines

This chapter provides an overview of the issues you should consider before deploying a directory. For detailed information about how to deploy Oracle Internet Directory, see Part VI of Oracle Internet Directory Administrator's Guide.

The chapter covers the following topics:

• What Do You Put in a Directory?
• Designing an Effective Directory Tree and Choosing Entry Names
• Physically Distributing the Directory: Partitions and Replicas
• Designing for High Availability and Failover
• Capacity Planning, Sizing, and Tuning
• Designing Directory Security

What Do You Put in a Directory?

The most important factor to consider when trying to decide what to store in a directory is that a directory is no substitute for a database. Because directories are designed for read operations, you should avoid using them as repositories for information that will change often. By keeping write operations in a directory to a minimum, you improve search performance. Directories are fine for single operations involving one directory entry, operations that involve relatively static information such as administrative metadata. But for transactional operations involving multiple data items and more than one operation, databases are the preferred repository.

The following are suitable candidates for directory storage:

• Contact information such as phone numbers, e-mail addresses, and geographical addresses
• Employee profiles that consist of information about a worker's salary, job title, manager, and department
• Software configuration information
• Software preferences
• Nontransactional billing information such as credit limits, credit card numbers, customer contact information
• Pointers to large objects, which are not suitable for directory storage, objects such as JPEG images and Java applications

Designing an Effective Directory Tree and Choosing Entry Names

Designing an effective directory information tree and assigning effective names for entries requires careful planning and enterprise-wide coordination. An effective directory structure incorporates the following features:

• It borrows rules for assigning names and numbers to employees from a company's Human Resources Department, whose policies are valid throughout the enterprise. The alternative is to come up with unique names, a process that adds administrative overhead.
• It avoids organizing entries by corporate hierarchy, preferring instead to include a person's organizational information as an attribute in his or her directory entry. By not using the corporate hierarchy as the measure of how the directory is organized, you avoid the administrative disruptions that frequent corporate reorganizations cause.
• It organizes the directory information tree to reflect data ownership boundaries. This practice makes it easier to develop effective access control and replication policies. For example, a multinational corporation that wants to consolidate its global directory can accomplish this goal by dividing the directory into naming contexts that correspond with geographic regions, each subject to its own access control and replication policies.

Physically Distributing the Directory: Partitions and Replicas

The model of a centralized, consolidated directory, and the cost savings associated, cannot be achieved without multimaster replication. Using this technology, two or more directory nodes in a network store a copy of the directory and each of them updates the directory and replicates the changes to the other nodes. Because replication can occur at the level of a naming context, the organization can avoid the administrative burden associated with partitioning the directory across different servers.

A strong, centralized directory has the following features:

• It consists of a network of two or more directory nodes, each containing all the naming contexts, all bound by a multimaster configuration.
• Its nodes are deployed, one in each geographic region, to suit the corporate data network connectivity. For example, if a region is connected to the rest of the network by way of a slow link, it is better to locate a dedicated directory server for use by the clients in that region.
• Its regional servers are each configured for failover and recovery.

Reasons to Replicate

Directory replication is desirable under the following circumstances:

• The organization consists of widely dispersed data centers that require a common directory but are interconnected with low bandwidth links involving multiple intermediate routers.
• The number of clients accessing the directory server exceeds server capacity, and load balancing is required.
• The organization wants to ensure system availability in the event that the directory server fails.

  See Also: Chapter 14, "Managing Directory Replication" in Oracle Internet Directory Administrator's Guide

Reasons to Partition

Partitioning a directory over two or more servers is expensive because each partition must have its own plan for backup, recovery, and other data management functions. Unless the partitions of your directory are characterized by the following conditions, you should plan to replicate it.

• The partition corresponds to administrative and data ownership boundaries that are better left independent.
• The organization consists of widely dispersed data centers that are interconnected with low bandwidth links but have only local access needs.
• The partition is not integral to the organization at large.
• The expense of maintaining replicas of entire directories is insupportable.

Designing for High Availability and Failover

Multimaster replication ensures that a directory is always available, and it provides a failover remedy, but you should also be aware of two other backup and recovery methods, Intelligent Client Failover and Intelligent Network Level Failover. Both of these are options where Oracle Internet Directory is installed.

Intelligent Client Failover enables clients connecting to Oracle Internet Directory to contact alternate server instances of Oracle Internet Directory if their connection to a given server instance fails.

Intelligent Network Level Failover is a technology that detects failure in the server hosting Oracle Internet Directory and reroutes connection requests to other servers. It has load balancing and failover capabilities.

Capacity Planning, Sizing, and Tuning

Determining the load and capacity requirements of any given directory node requires foresight and careful planning. It consists of three discrete processes: capacity planning, sizing, and tuning.

This section contains the following topics:

• Capacity Planning
• Sizing
• Tuning

Capacity Planning

Capacity planning involves determining the load that a directory server will bear and the capacity it must have. These are a function of the following factors:

• The type of LDAP client applications accessing the server
• The number of users accessing these applications
• The kind of LDAP operations that these applications perform
• The number of entries in the directory information tree
• The type of operations the directory server performs
• The number of concurrent connections to the directory server
• The peak rate at which the directory server must perform operations
• The average latency tolerable under peak load conditions

  See Also: Chapter 17, "Capacity Planning," in Oracle Internet Directory Administrator's Guide

Sizing

Once you have determined the load and capacity requirements of a directory server, you can determine system requirements. Pay attention to the following factors:

• The type and number of CPUs for the directory server computer
• The type and size of disk subsystems for the directory server computer
• The amount of memory required by the directory server computer
• The type of network used for LDAP messages from clients

  See Also: Chapter 17, "Capacity Planning," in Oracle Internet Directory Administrator's Guide

Tuning

Before actually using your directory, you should test it, using as test data the applications that will interact with it. Any tool that you devise for testing should use overall throughput and the average latency of operations as a measure of how tuning should be performed.

The more commonly tuned properties are:

• CPU usage

  This is contingent on the number of directory servers deployed and the number of database connections that each server opens.

• Memory usage

  In the case of Oracle Internet Directory, the biggest consumer of memory is the database cache. It should be tuned so that physical memory is always available. Too large a cache causes paging, which impedes performance. Too small a cache causes excessive disk I/O, which also impedes performance.

• Disk usage

  If the data returned by the directory resides in database tablespaces, you can do the following to improve data throughput:

  • Balance tablespaces on different logical and physical drives
  • Stripe logical volumes onto multiple physical volumes
  • Distribute disk volumes across several I/O controllers

    See Also: Chapter 18, "Tuning," in Oracle Internet Directory Administrator's Guide

Designing Directory Security

When designing directory security, do the following:

• Grant the least amount of access that you can.
• Think carefully about the kind of access control lists (ACLs) that you place at the root of the directory tree because such placement determines the kind of access that users have to the rest of the tree.
• Use groups instead of individuals in ACLs as much as possible.
• Note that group permissions at a higher level of the directory tree cannot currently be reversed at a lower level.

  See Also: Chapter 12, "Managing Directory Access Control," in Oracle Internet Directory Administrator's Guide