{include:DSEE Banner}
{toc:type=flat|separator=bracket}
h1. Introduction
The [Lightweight Directory Access Protocol | http://en.wikipedia.org/wiki/Ldap] (LDAP) is a light-weight, standard extensible TCP/IP protocol. LDAP was designed to provide access to X.500 directories using fewer resources. LDAP is an extensible protocol, and RFCs exist that describe extensions. Since LDAP accesses occur in near real time, the quality of the user experience is affected by the following qualities of the Directory Services Infrastructure (DSI):
* performance
* availability
[Sun Java Enterprise System Directory Server | http://www.sun.com/software/products/directory_srvr_ee/dir_srvr/index.xml], when properly configured, maintained, and monitored provides extremely high performance in almost every area. This article and related articles give designers guidelines and tools for achieving the highest possible performance and availability of Directory Server, and administrators tools and understanding needed for the proper care and feeding of Directory Server. This article strengthens understanding of Directory Services technical topics, provides a discussion of Directory Services best practices, and discusses networking considerations and helps the reader understand how the recommended architecture yields:
* Performance
* Availability
* Resilience
* Maintainability
h1. Directory Server
The Sun Java Enterprise System Directory Server Enterprise Edition provides all the software necessary to create a powerful, high-performance, highly-available, highly secure DSI for authentication and authorization of users and applications, assigning roles, and grouping people, places, and things. Additional hardware in the form of networking components will be necessary for a completely seamless fail-over-capable infrastructure. Directory Services provide a centralized repository for account data, user data, employee data, customer data, and other types of data. The data is accessed via the LDAP or the Directory Services Markup Language (DSML) Both of these services may be accessed via [SSL | http://en.wikipedia.org/wiki/Transport_Layer_Security] or in the clear.
Infrastructures based on LDAP are used as the database for:
* user entries and profile data
* group membership
* policy information.
h1. Directory Proxy Server
h1. Directory Services Infrastructure
h2. Analysis and Planning
h3. Business and Technical Analysis
h3. Planning Directory Data
h3. Planning Directory Schema
h3. Planning Directory Information Tree (DIT)
h3. Planning Topology and Replication Strategy
h3. Planning Security Policies
h3. Planning Indexing
h2. Availability
*Highly available* or *fault-resistant* systems are systems that can quickly recover from a single identified failure. The method to be used in creating an architecture for Directory Services Infrastructure is to separate functionality vertically, and scale horizontally. Directory Services architectures are typically constructed of multiple layers, using vertical layering to separate functionality which provides enhanced availability - vertical layering eases the task of mitigating risk of a component failure in a layer or tier - and horizontal scaling adds capacity and redundancy to a component in the horizontal layer. Failure of any one device in a layer is mitigated by redundancy of components, for example, should a load-balancer in a layer fail, the other load-balancer takes over. Failure of a single component may result in degraded performance until the tier components are restored to full capacity.
h3. Load Balancing and Directory Proxy Server Components
In this section, the term "load-balancer" or "load-balancing devices" refers to an Layer 4 LDAP-aware device. The use of LDAP-aware load-balancing devices mitigates the risk/impact of a failure of a downstream component affecting the service as a whole. When a component directly downstream from the load-balancing device fails, the load-balancer(s) remove it from the load-balanced list. Applications are then directed to the remaining component for service. Applications that use "pooled connections" will have to reconnect. The load-balancers send a TCP reset (RST) in the event a client has open connection(s) to a downstream component that has failed so that those applications can reconnect when the next need for that service arises, and configured to have no idle timeouts on connections. These features provide enhanced scalability for Enterprise LDAP (or any TCP protocol) services.
Directory Proxy Server provides an additional layer of isolation and load-balancing and is ideally placed between load-balancing appliances and the Directory Server farm.
h3. Multi-master Replication Topologies
Multi-Master Replication (MMR) is a strategy by which two or more Directory Servers act as both replica and supplier, and maintain synchronicity with each other. These master (Supplier) Directory Servers may also replicate "downstream" to Consumer (replica) Directory Servers that serve as LDAP search service providers. MMR provides higher availability than a single Master configuration because at least one master (supplier) server will be available. If MMR is not configured and if a server fails, *there will be an outage*, no matter what level of support the customer pays for. With Directory Server in a correctly designed and maintained MMR topology, possibly supported by Directory Proxy Server (DPS) and hardware load balancing components, service outages are a thing of the past.
h3. Networking Considerations
h4. IP Multi-pathing
h4. Switches and Routers
h2. Scalability
h2. Replication
Replication is the process by which directory database contents are *replicated*, that is, reproduced exactly, in another directory server database. Replication is controlled by replication agreements by which two directory servers agree to be Consumer and Supplier. The Supplier directory server, also known as a Master contains the authoritative data. The Consumers (in MMR, the supplier participants perform a dual role of suppliers and consumers) contain replicas of the authoritative data. See the discussion on Multi-Master Replication above.
Using the replication feature should be used because replication provides the following benefits:
* Load balancing. Replication to a consumer reduces loads on the supplier
* Performance increase. Replication to a closer consumer improves response times
* Local data management. Data can be managed locally and then shared across the replicated landscape.
h2. Performance
h3. Distributed Databases and Directory Proxy Server
h2. Ancillary Systems and Functions
h3. Monitoring
* [Directory Server Monitoring]
h1. Related Articles
* [The Search Tune Parameter in Directory Server 5.2]
* [Cascaded Replication Topology]
* [BigAdmin Naming Service Guide, Part 1 | http://wikis.sun.com/x/Y4J1 ]
h1. Resources
* [Data Sheet | http://www.sun.com/software/products/directory_srvr_ee/ds_directory_srvr_ee.pdf]
* [Sun Java System Directory Server FAQ]
h1. Contributors
{contributors-summary}
{toc:type=flat|separator=bracket}
h1. Introduction
The [Lightweight Directory Access Protocol | http://en.wikipedia.org/wiki/Ldap] (LDAP) is a light-weight, standard extensible TCP/IP protocol. LDAP was designed to provide access to X.500 directories using fewer resources. LDAP is an extensible protocol, and RFCs exist that describe extensions. Since LDAP accesses occur in near real time, the quality of the user experience is affected by the following qualities of the Directory Services Infrastructure (DSI):
* performance
* availability
[Sun Java Enterprise System Directory Server | http://www.sun.com/software/products/directory_srvr_ee/dir_srvr/index.xml], when properly configured, maintained, and monitored provides extremely high performance in almost every area. This article and related articles give designers guidelines and tools for achieving the highest possible performance and availability of Directory Server, and administrators tools and understanding needed for the proper care and feeding of Directory Server. This article strengthens understanding of Directory Services technical topics, provides a discussion of Directory Services best practices, and discusses networking considerations and helps the reader understand how the recommended architecture yields:
* Performance
* Availability
* Resilience
* Maintainability
h1. Directory Server
The Sun Java Enterprise System Directory Server Enterprise Edition provides all the software necessary to create a powerful, high-performance, highly-available, highly secure DSI for authentication and authorization of users and applications, assigning roles, and grouping people, places, and things. Additional hardware in the form of networking components will be necessary for a completely seamless fail-over-capable infrastructure. Directory Services provide a centralized repository for account data, user data, employee data, customer data, and other types of data. The data is accessed via the LDAP or the Directory Services Markup Language (DSML) Both of these services may be accessed via [SSL | http://en.wikipedia.org/wiki/Transport_Layer_Security] or in the clear.
Infrastructures based on LDAP are used as the database for:
* user entries and profile data
* group membership
* policy information.
h1. Directory Proxy Server
h1. Directory Services Infrastructure
h2. Analysis and Planning
h3. Business and Technical Analysis
h3. Planning Directory Data
h3. Planning Directory Schema
h3. Planning Directory Information Tree (DIT)
h3. Planning Topology and Replication Strategy
h3. Planning Security Policies
h3. Planning Indexing
h2. Availability
*Highly available* or *fault-resistant* systems are systems that can quickly recover from a single identified failure. The method to be used in creating an architecture for Directory Services Infrastructure is to separate functionality vertically, and scale horizontally. Directory Services architectures are typically constructed of multiple layers, using vertical layering to separate functionality which provides enhanced availability - vertical layering eases the task of mitigating risk of a component failure in a layer or tier - and horizontal scaling adds capacity and redundancy to a component in the horizontal layer. Failure of any one device in a layer is mitigated by redundancy of components, for example, should a load-balancer in a layer fail, the other load-balancer takes over. Failure of a single component may result in degraded performance until the tier components are restored to full capacity.
h3. Load Balancing and Directory Proxy Server Components
In this section, the term "load-balancer" or "load-balancing devices" refers to an Layer 4 LDAP-aware device. The use of LDAP-aware load-balancing devices mitigates the risk/impact of a failure of a downstream component affecting the service as a whole. When a component directly downstream from the load-balancing device fails, the load-balancer(s) remove it from the load-balanced list. Applications are then directed to the remaining component for service. Applications that use "pooled connections" will have to reconnect. The load-balancers send a TCP reset (RST) in the event a client has open connection(s) to a downstream component that has failed so that those applications can reconnect when the next need for that service arises, and configured to have no idle timeouts on connections. These features provide enhanced scalability for Enterprise LDAP (or any TCP protocol) services.
Directory Proxy Server provides an additional layer of isolation and load-balancing and is ideally placed between load-balancing appliances and the Directory Server farm.
h3. Multi-master Replication Topologies
Multi-Master Replication (MMR) is a strategy by which two or more Directory Servers act as both replica and supplier, and maintain synchronicity with each other. These master (Supplier) Directory Servers may also replicate "downstream" to Consumer (replica) Directory Servers that serve as LDAP search service providers. MMR provides higher availability than a single Master configuration because at least one master (supplier) server will be available. If MMR is not configured and if a server fails, *there will be an outage*, no matter what level of support the customer pays for. With Directory Server in a correctly designed and maintained MMR topology, possibly supported by Directory Proxy Server (DPS) and hardware load balancing components, service outages are a thing of the past.
h3. Networking Considerations
h4. IP Multi-pathing
h4. Switches and Routers
h2. Scalability
h2. Replication
Replication is the process by which directory database contents are *replicated*, that is, reproduced exactly, in another directory server database. Replication is controlled by replication agreements by which two directory servers agree to be Consumer and Supplier. The Supplier directory server, also known as a Master contains the authoritative data. The Consumers (in MMR, the supplier participants perform a dual role of suppliers and consumers) contain replicas of the authoritative data. See the discussion on Multi-Master Replication above.
Using the replication feature should be used because replication provides the following benefits:
* Load balancing. Replication to a consumer reduces loads on the supplier
* Performance increase. Replication to a closer consumer improves response times
* Local data management. Data can be managed locally and then shared across the replicated landscape.
h2. Performance
h3. Distributed Databases and Directory Proxy Server
h2. Ancillary Systems and Functions
h3. Monitoring
* [Directory Server Monitoring]
h1. Related Articles
* [The Search Tune Parameter in Directory Server 5.2]
* [Cascaded Replication Topology]
* [BigAdmin Naming Service Guide, Part 1 | http://wikis.sun.com/x/Y4J1 ]
h1. Resources
* [Data Sheet | http://www.sun.com/software/products/directory_srvr_ee/ds_directory_srvr_ee.pdf]
* [Sun Java System Directory Server FAQ]
h1. Contributors
{contributors-summary}