| Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) Part Number B15991-01 |
|
|
View PDF |
| Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) Part Number B15991-01 |
|
|
View PDF |
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:
Physical Distribution: Partitions, Replicas, and High Availability
|
See Also:
|
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:
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
As the directory becomes more central to the operation of the network and its services, deployment choices become critical.
Oracle Internet Directory serves as a shared repository for the entire Oracle Identity Management infrastructure. A carefully planned logical structure of the directory enables:
Enforcement of security policies that meet the requirements of your deployment
A more efficient physical deployment of the directory service
Easier configuration of synchronization of a third-party directory with Oracle Internet Directory
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 connecting them by using knowledge references
This section contains these topics:
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.
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. |
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.
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 |
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:
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:
|
You can reduce administrative time and costs by integrating your applications and directories—including third-party LDAP directories—with Oracle Internet Directory. Oracle Directory Integration Platform, a component of Oracle Identity Management, enables you to do this. For example, you might need to do the following:
Keep employee records in Oracle Human Resources consistent with those in Oracle Internet Directory. Oracle Directory Integration Platform provides this synchronization through the Oracle Directory Synchronization Service.
Notify certain LDAP-enabled applications—such as OracleAS Portal—whenever changes are applied to Oracle Internet Directory. Oracle Directory Integration Platform provides this notification through the Oracle Directory Provisioning Integration Service.
Throughout the integration process, the Oracle Directory Integration Platform 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 Oracle Directory Integration Platform can synchronize the data in Microsoft Active Directory with that in Oracle Internet Directory.
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 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.
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 22-1 indicates the approximate level of CPU power required for various deployment scenarios for Oracle Internet Directory.
Table 22-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 22-2 gives the approximate disk space requirements for variously sized DITs.
Table 22-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 22-3 provides estimates of the memory requirements for various DIT sizes.
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:
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.
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.
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 25, "Tuning Considerations for the Directory" for further details on various tuning tips and techniques |
