13
Deployment Considerations

This chapter discusses issues to consider when deploying Oracle Internet Directory. It helps you assess enterprise directory requirements and make effective deployment choices. Although the recommendations in this chapter are primarily for directories in medium to large enterprises and Internet Service Providers (ISPs), the principles apply to other environments as well.

This chapter contains these topics:

• The Expanding Role of Directories

• Logical Organization Of Directory Information

• Physical Distribution: Partitions and Replicas

• Failover Considerations

• About Capacity Planning, Sizing, and Tuning

The Expanding Role of Directories

Today, most enterprises are at various stages of deploying centralized and consolidated LDAP-compliant directories. Some have had non-LDAP-compliant directories--for example, NDS or ISO X.500--and are now converting to the corresponding LDAP-enabled versions. This is either to accommodate LDAP-reliant Internet clients, such as those embedded in Web browsers, or to consolidate the increasing number of platforms and services that use directories.

The increased numbers of LDAP-enabled applications make availability and performance requirements for LDAP-compliant directories critical. Most environments need to update their deployments.

Enterprises should plan a robust and flexible deployment to accommodate:

• The increased volume of information in the directory

• The number of applications that rely on the directory

• Such load characteristics as concurrent access and throughput

Choosing a directory product that can function as an enterprise backbone is a serious decision. As the directory becomes more central to the operation of the network and its services, deployment choices also become critical.

Logical Organization Of Directory Information

Establishing an effective policy for directory information tree (DIT) structure and naming requires enterprise-wide coordination and planning. For example, the following questions can arise:

• How do you choose your enterprise directory naming and organization?

• Should the choice reflect the corporate organizational structure or geographic and national boundaries?

• Does the choice work seamlessly for NOS directories such as Novell's eDirectory solution and Microsoft Active Directory?

This section contains these topics:

• Directory Entry Naming

• DIT Hierarchy and Structure

Directory Entry Naming

Typically, most enterprises have a Human Resources department that establishes rules for assigning unique names and numbers for employees. When choosing a unique naming component for directory entries, it is good to exploit this administrative infrastructure and use its policies. By contrast, the advantage of making DNs more "user friendly" is outweighed by the proliferation of administrative policies it would require.

DIT Hierarchy and Structure

A DIT is hierarchical in structure, similar to the DNS (Domain Name System). It is possible to organize the DIT to reflect any logical hierarchy associated with an enterprise. The choice should accommodate the following:

• The DIT structure and naming policies for the enterprise as a whole should be compatible with the rules and restrictions of departmental NOS directories. For example, some directory products define domains, and then require organizational units and localities to be logically subordinate to those domains. Also, some directory products require directory name uniqueness within a domain, even for entries that are not siblings.

• The directory organization should facilitate clear and effective access control and replication policies. In an enterprise where delegation of ACL administration is required, it is better to organize the DIT to reflect the data ownership boundaries.

  For example, consider a corporation which has an autonomous data center for each major geographic region: one for the Americas (North and South), one for Europe, and one for Asia Pacific. Suppose that this corporation wants to consolidate its global directory, while retaining the administrative autonomy of its regional data centers. It should organize the directory in naming contexts corresponding to each region. This makes it easier to develop access control and replication policies that suit regional needs.

• It may be tempting to organize the directory hierarchy to reflect either the corporate divisional structure or the organizational hierarchy. Usually, this is not advisable because most corporations undergo frequent reorganization and divisional restructuring. It is more manageable to capture a person's organizational information as an attribute of the person's directory entry.

Physical Distribution: Partitions and Replicas

You can distribute directory data in two ways:

• By maintaining the entire directory on one server

• By hosting different naming contexts on different servers and maintaining knowledge references, also called referrals, between them

  See Also: "Distributed Directories: An Overview"

This section contains these topics:

• An Ideal Deployment

• Partitioning Considerations

• Replication Considerations

An Ideal Deployment

In an ideal world, it would be simpler and more secure to store all naming contexts in a central consolidated directory server. The problem is that this central directory server would then be a single point of failure.

A simple solution might be to implement redundant LDAP servers and their associated databases. However, even redundancy might not provide the needed connectivity, accessibility, and performance that most global organizations need at all their regions and sites. These requirements might, in fact, call for replicas physically located at various regions across the corporate geography.

If Oracle Internet Directory supported only single-master configuration, then logical consolidation of the directory would be difficult. Each region or group would want to store the master replica for the naming context on which that group relies. This, in turn, could mean a lack of uniformity in the administrative policies among the partitions. Administrators would need to use a different data management procedure for each partition.

However, Oracle Internet Directory's multimaster replication makes logical consolidation of the directory easier. It allows "update anywhere" configurations, which makes consolidating the directory more efficient and less costly than maintaining multiple partitions.

Here is a simple and practical recommendation for a robust centralized corporate directory:

• Establish a network of two or more directory nodes, each holding all the naming contexts. Set up these nodes in a multimaster configuration.

• Deploy these individual nodes, 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, then it is better to locate a dedicated directory server for use by the clients in that region.

• Individually configure each regional server for failover and recovery.

Remember: Even if all the naming contexts are consolidated, you can still achieve administrative autonomy for various logical naming contexts. You do this by establishing appropriate access control policies at the root of each naming context.

See Also: "Failover Considerations" for a discussion of redundancy

Partitioning Considerations

A directory with too many partitions generally has more administrative overhead than benefits. This is because each partition requires you to plan backup, recovery, and other data management functions.

Typically, the reasons for maintaining partitions are:

• They correspond to administrative and data ownership boundaries that are better left independent

• The enterprise network has regions that are connected with expensive or low-speed links and many partitions have only local access needs

• The lack of availability of a partition does not have a larger impact

• Maintaining an entire corporate directory in a certain region is too expensive

When you use partitioning, interconnect the partitions with knowledge references.

Note: LDAP does not support automatic chaining of knowledge references by the LDAP server. The majority of client side LDAP APIs support client-driven knowledge reference chasing. However, there is no guarantee that knowledge references will be supported in all the LDAP tools. The lack of consistent knowledge reference support across all available tools is a factor to consider before deciding to use partitions.

Replication Considerations

LDAP directory replication architecture is based on a loose consistency model: Two replicated nodes in a replication agreement are not guaranteed to be consistent in real time. This increases the overall flexibility and availability of the directory network, because a client can modify data without all interconnected nodes being available. Suppose, for example, that one node is unavailable or heavily loaded. With multimaster replication, the operation can be performed on an alternate node, and all interconnected nodes synchronize in due course.

There are many reasons to implement a replicated network, including the following:

• Local accessibility and performance requirements

  Most corporations have operations in many regions in the world, and those operations need a common directory. Suppose that the regions were interconnected with low bandwidth links involving multiple intermediate routers. A client accessing a directory server from outside the region could experience a very high latency, and even inadequate throughput.

  In such cases, a regional replica--enabled by multimaster replication to receive updates-- is essential. Moreover, the replication data transfer can be scheduled for off-peak hours in the underlying Advanced Symmetric Replication (ASR).

• Load balancing

  When directory access exceeds the capacity of an existing server, an additional server must share the load. With Oracle Internet Directory, two such systems can be deployed in a multimaster replication mode. In fact, even when planning the directory deployment to meet a specific estimated load, it can be less costly to maintain two relatively low-end systems than one high-end system. In addition to load balancing, such configurations also contribute to higher system availability.

• Failure tolerance and higher overall system availability

  One of the most important reasons to implement directory replication is to increase overall system availability. When one server is unavailable, the traffic can be routed to other available servers. This can be transparent to clients.

Failover Considerations

Because a directory service has a critical function in an enterprise, deployment should take failure recovery and high availability into consideration. This includes developing backup and recovery strategies for individual nodes.

In addition to multimaster replication, consider the following failover and high-availability options for potential deployment at any Oracle Internet Directory installation:

• Intelligent Client Failover

  All LDAP clients connecting to Oracle Internet Directory can maintain a list of alternate server instances of Oracle Internet Directory to contact if their connection with a given server instance is abruptly broken.

• Intelligent Network Level Failover

  There are several hardware and software solutions that can detect the failure of the system hosting Oracle Internet Directory. These solutions can intelligently reroute future connection requests to an alternate server. Some of these solutions balance the load of incoming connection requests with alternate servers, while also providing the necessary failover capabilities.

Because Oracle Internet Directory is a client of Oracle8i, other failover technologies, such as Oracle Parallel Server, are also available.

See Also: Chapter 16, "High Availability And Failover" for further details about high-availability and failover options available with Oracle Internet Directory.

About Capacity Planning, Sizing, and Tuning

When estimating enterprise-wide and regional requirements for directory usage, plan for future needs. Depending on other configuration choices for replication and failover, there could be more than one directory node, each with its own load and capacity requirements. In this case, you must individually size each directory node.

As an enterprise increases its directory usage, more applications rely on Oracle Internet Directory to serve their requests in a timely manner. Ensure that the Oracle Internet Directory installation can live up to the performance and capacity expectations of those applications.

You can influence the capacity and performance of a given Oracle Internet Directory installation in two phases of the deployment process:

• Planning phase

  During this phase, gather the requirements of all directory users and establish a unified performance and capacity requirement. This consists of capacity planning and system sizing.

• Implementation phase

  Once you have the hardware, tune the Oracle Internet Directory software stack for best use of the hardware resources. This improves the performance of Oracle Internet Directory and of the LDAP client applications.

This section contains these topics:

• Capacity Planning

• Sizing Considerations

• Tuning Considerations

Capacity Planning

Capacity planning is the process of determining performance and capacity requirements. You base these on typical models of directory usage in the enterprise.

When trying to estimate the required capacity of an Oracle Internet Directory installation, consider:

• The type of LDAP client applications

• The number of users accessing those applications

• The nature of LDAP operations those applications perform

• The number of entries in the DIT

• The type of operations performed against the Oracle directory server

• The number of concurrent connections to the Oracle directory server

• The peak rate at which operations need to be performed by the Oracle directory server

• The average latency of operations required under peak load conditions

While estimating these details, allow room for future increases in directory usage.

Sizing Considerations

Once you have established the fundamental capacity and performance requirements, translate them into system requirements. This is called system sizing. Some of the details to consider in this phase are:

• The type and number of CPUs for the Oracle Internet Directory server computer

• The type and size of disk subsystems for the Oracle Internet Directory server computer

• The amount of memory required for the Oracle Internet Directory server computer

• The type of network used for LDAP messages from the clients

Based on current experience, the following table indicates the approximate level of CPU power required for various deployment scenarios for Oracle Internet Directory:

Usage	Num CPUs	SPECint_rate95 baseline	System
Departmental	2	60 to 200	Compaq AlphaServer 8400 5/300 (300Mhz x 2)
Organization wide	4	200 to 350	IBM RS/6000 J50 (200MHz x 4)
Enterprise wide	4+	350+	Sun Ultra 450 (296 MHz x 4)

The amount of disk space required for an installation of Oracle Internet Directory is directly proportional to the number of entries stored in the DIT. The following table gives the approximate disk space requirements for variously sized DITs.

Number of Entries in DIT	Disk Requirements
100,000	450MB to 650MB
200,000	850MB to 1.5GB
500,000	2.5GB to 3.5GB
1,000,000	4.5GB to 6.5GB
1,500,000	6.5GB to 10GB
2,000,000	9GB to 13GB

The data in this table makes the following assumptions:

• There are approximately 20 cataloged attributes

• There are approximately 25 attributes for each entry

• The average size of an attribute is approximately 30 bytes

The amount of memory required for Oracle Internet Directory is mostly governed by the amount of database cache that a deployment site desires. Often, the size of the database cache is directly proportional to the number of entries in the DIT. The following table provides estimates of the memory requirements for various DIT sizes:

Directory Type	Number of Entries	Minimum Memory
Small	Less than 600,000	512MB
Medium	600,000 to 2,000,000	1GB
Large	Greater than 2,000,000	2GB

Tuning Considerations

Oracle Corporation recommends that you properly tune Oracle Internet Directory before using it in a production environment. Before tuning, ensure that there are adequate testing mechanisms and sample data in the directory to simulate a real world usage scenario. Perhaps you can use the applications that rely on the directory for testing purposes.

Any tool for testing the performance of Oracle Internet Directory must be able to show:

• The overall throughput it is noticing

• The average latency of operations

In this way, the tool provides a feedback mechanism for determining the effects of tuning and providing direction to the overall tuning effort.

Some of the commonly tuned properties of an Oracle Internet Directory installation include:

• CPU usage

  This is determined, to a large extent, by:

  • The number of Oracle directory servers

  • The number of database connections opened by each server

  On the one hand, too large a number of Oracle directory servers and database connections can cause too much contention for available CPU resources. On the other hand, too small a number of Oracle directory servers and database connections can leave much of the CPU power under-utilized. Consider adjusting these numbers to the appropriate levels based on available CPU resources and the expected peak load.

• Memory usage

  The main consumer of memory in an Oracle Internet Directory installation is the database cache, which is part of the SGA. In some cases, allocating a very large database cache can eliminate much disk I/O for Oracle data files. However, it can also cause paging, which is detrimental to performance. Alternatively, having a small database cache causes too much disk I/O, and that is also detrimental to performance. Tune the memory usage of the system so that all consumers of memory in the system can get physical memory without needing to use paging.

• Disk usage

  Because all of the data served by Oracle Internet Directory resides in database tablespaces, pay attention to any tuning that can increase the I/O throughput. Common techniques for disk tuning include:

  • Balancing tablespaces on different logical and physical drives

  • Striping logical volumes onto multiple physical volumes

  • Distributing disk volumes across multiple I/O controllers

    See Also: Chapter 15, "Tuning" for further details on various tuning tips and techniques