Skip Headers
Oracle® Internet Directory Administrator's Guide,
10g Release 2 (10.1.2)
B14082-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

18 Directory 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:

18.1 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. They do this 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:

As the directory becomes more central to the operation of the network and its services, deployment choices become critical.

18.2 Logical Organization Of Directory Information

Oracle Internet Directory serves as a shared repository for the entire Oracle Identity Management infrastructure. A carefully planned logical structure of the directory enables:

18.3 Physical Distribution: Partitions, Replicas, and High Availability

You can distribute directory data in two ways:

This section contains these topics:

18.3.1 An Ideal Deployment

Although it would be simpler and more secure to store all naming contexts in one central directory, this central directory would then be a single point of failure.

One 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. Because administrators would need to use a different data management procedure for each partition, this could mean a lack of uniformity in the administrative policies among the partitions.

Fortunately, because multimaster replication allows "update anywhere" configurations, it is more efficient and less costly to consolidate the directory rather than to maintain 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:

"High Availability Considerations" for a discussion of redundancy

18.3.2 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, connect one partition to another by using a knowledge reference.


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.

18.3.3 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 Oracle Database Advanced Replication.

  • 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.


    See Also:

    The section on planning the physical deployment of Oracle Internet Directory in Oracle Identity Management Concepts and Deployment Planning Guidefor more information about replicated directory configurations

18.3.4 High Availability 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.

  • Multiple installations of Oracle Internet Directory on one host

    You can run more than one installation of Oracle Internet Directory on a single host and then replicate between them. This can be useful in providing up-to-date directory data on the same machine by automatically backing up that data. It also enables you to provide for failover by using only two nodes: If one node fails, then both instances of Oracle Internet Directory can run on the other node.

Because Oracle Internet Directory is a client of the Oracle Database, other failover technologies, such as Oracle Real Application Clusters, are also available.


See Also:


18.4 Oracle Directory Integration and Provisioning

You can reduce administrative time and costs by integrating your applications and directories—including third-party LDAP directories—with Oracle Internet Directory. Directory Integration and Provisioning, a component of Oracle Identity Management, enables you to do this. For example, you might need to do the following:

Throughout the integration process, the Directory Integration and Provisioning ensures that the applications and other directories receive and provide the necessary information in a reliable way.

You can integrate with various directories, including Microsoft Active Directory and SunONE Directory Server. For example, in an Oracle Application Server environment, where access to Oracle components relies on data stored in Oracle Internet Directory, you can still use Microsoft Active Directory as the central enterprise directory. Users of that directory can still access Oracle components because the Directory Integration and Provisioning can synchronize the data in Microsoft Active Directory with that in Oracle Internet Directory.

18.5 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:

This section contains these topics:

18.5.1 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.

18.5.2 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, Table 18-1 indicates the approximate level of CPU power required for various deployment scenarios for Oracle Internet Directory.

Table 18-1 CPU Power for Various Deployment Scenarios

Usage Active Connections Num CPUs SPECint_rate95 baseline System

Departmental

0-500

2

60 to 200

Compaq AlphaServer 8400 5/300 (300Mhz x 2)

Organization wide

500-2000

4

200 to 350

IBM RS/6000 J50 (200MHz x 4)

Enterprise wide

2000+

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. Table 18-2 gives the approximate disk space requirements for variously sized DITs.

Table 18-2 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 buffer cache that a deployment site desires. Often, the size of the database buffer cache is directly proportional to the number of entries in the DIT. Table 18-3 provides estimates of the memory requirements for various DIT sizes.

Table 18-3 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


18.5.3 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 buffer cache, which is part of the SGA. In some cases, allocating a very large database buffer 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 buffer 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 21, "Tuning Considerations for the Directory" for further details on various tuning tips and techniques