From a whitepaper by Michael Melore.
{toc:type=flat}
h1. Introduction
One of the rich features of the DSEE6 offering allows for unlimited master directory servers. The intent of this document is to provide benefits and considerations in deploying an exclusive multi-master topology in comparison to a master,consumer and replication hub directory topology.
Selection of an exclusive multi-mastered directory deployment
* Mitigates all risk in isolating existing application write behavior
* Provides the greatest aggregate performance in a highly distributed and balanced model
* Lowers administrative burden in fail-over and recovery requirements
Customers utilizing their DS5.x master(s) for read traffic typically satisfy one or more of the following models. To qualify read and write operations, write operational traffic is considered new directory object creations (in a typical user model, new user creations), object modifications (password, telephone, surname changes), or object deletions (user purging). Read operational traffic is considered search operations (in a typical user model, authentications, authorizations, and entitlements).
h1. Legacy Master Read Operation Usage Models
h2. Limited Server Architectures
Customers may combine read and write traffic on the same physical server(s) typically within the DS5.2 framework, this model is used to save in hardware costs. Services are potentially impacted during peak usage and maintenance. Degraded performance may be realized to provisioning (write) applications during heavy read operation load, and alternatively when heavier write demand impacts read/search availability. Higher availability is generally not a key business requirement in these DS5.2 models.
h2. Applications Conducting Read and Write Operations
Profiles in this model typically includes, customers with limited knowledge of the behavior or capabilities of their business applications and may direct all operations to masters to avoid write referral requirements.
Application owners may independently direct new applications to the master(s) without consent of the Directory owners/administrators. They are sometimes only identified when observing directory server read operation statistics.
Bulk provisioning applications directed to the Master(s) conduct minimal required Read Operations to manipulate
target directory objects.
Within this model multiple DS5.x Directory Proxy Server instances are sometimes deployed, one or more designated for bulk provisioning applications utilizing weighted or fail-over routing, the other(s) designated for everything else including random writes distributed across a balanced routing table.
h1. DSEE6 Rich Feature Set (specific to write operations)
A number of enhancements are introduced within the DSEE6 offering specific to Write Operational performance and agility, and may be considered during the architectural definition stage.
* Faster Write Acceptance
* Unlimited Master Directories Supported
* Increased Write Speed Realized by distributing Write Operations
* Write Affinity Ability
* Enhanced Replication Ability and Speed
* Support of Full and Partially Meshed Replication Topologies
* Increased Management and Administration of Replication
* Operational Based Routing Ability
* Enhanced Proxy Routing Based on Availability
* Enhanced Memory and Cache Management
* Global User Lockout on Failed Password Attempts
h1. Write Referral Risk / Mitigation
Some DS5.x customers have experienced risk related to applications and clients unable to effectively follow write referrals when write operations are requested from a Consumer (read-only) directory server. This risk was mostly mitigated through use of Sun's Directory Proxy Server(s) as the Directory Proxy Server may be defined to follow write referral requests on behalf on clients and applications. This transparent proxy operation is successful except where some applications as written do not generate the appropriate return codes. In these cases a few options existed to mitigate this risk, mostly around small adjustments in the application code, or through application environmental variables. Another mitigation historically used is to direct these specific applications/clients to master directory servers where write referrals are not presented or required. This risk can be further mitigated within the DSEE6 offering.
DSEE6 supporting an exclusive Multi-Mastered Directory architecture with unlimited masters can avoid write referral requirements as each master will have the ability to accept localized write operations. The DSEE6 Directory Proxy Server also has the ability to direct Write Operations to the master directory servers. This may be defined according to design preference where a primary master may be thought of as the target or may be routed via a balanced or weighted definition across the master directory servers. DS5.x also supported an exclusive Multi-Mastered Directory architecture with a supported limit of 4 Multi-Mastered Directory servers.
h1. New DSEE6 Multi-Master Considerations
Full exclusive use of master directory servers will be a common deployment practice within DSEE6 use. It is expected that "Read Only" consumer directories may only be deployed addressing specific business requirements. A full master topology will provide such high availability, increased aggregate performance advantages and growth flexibility that it's expected read-only consumer directories may be less desirable and may only be utilized to fulfill specific business requirements. It's expected that Replication Hubs frequently used within DS5.x architectures may become less significant in DSEE6 deployments. Support of full and meshed replication topologies and the enhanced management of replication agreements are likely to make Replication Hub components less relevant, and without cost advantage.
Customers would likely replace this replication hub concept in their legacy deployments with an additional multimaster directory so as to gain additional aggregate performance in a load balanced strategy, and provide additional unattended fail-over redundancy within their framework. Failed "password attempt counts" synchronization is achieved via writable Master Directory servers. Consumer directory servers may be leveraged in a failed password retry count model when operational routing is used directing authentications to Masters. Comparisons between exclusive master directory models and master to consumer models are indicated later within this document.
h1. Potential DSEE6 Consumer Directory Deployment Models - (read only)
h2. Fractional Replication Consumer Directory Servers
Directories deployed with a minimal set of user attributes, in a read only state, these servers may be positioned in unsecured openly accessible areas (DMZ's) . These fractionally replicated consumer directory servers may be configured with lower hardware requirements than the masters based on their limited data sets, potential for lower indexing and cache, and lack of a change log database.
h2. Highly Secured Consumer Consideration
Consumer directory servers are not capable of accepting write operations. These servers can be further protected by prohibiting indirect client/application writes via blocked write referrals when Directory Proxy Servers are used. Consistent protections can be provided in an exclusive master deployment as well through options available within the directory proxy servers and native directory server. A typical use case for a restricted consumer read only topology where writes can not be introduced even indirectly via referrals, may be one where the authoritative source of data exists in a back-end data repository pushed to the LDAP directory. Manipulation of data will never be initiated within the LDAP architecture by LDAP clients or applications. The LDAP architecture in this model is basically a consumer of changes made from other data sources, pushed to the LDAP directory.
h2. Light Weight Consumer Consideration
Consumers may be deployed in a combined master to consumer directory model consistent with the past DS5.x model. There is little gained in this two directory server profile model (three profiles when replication hubs are used), and includes a loss of some of the benefits gained in a full exclusive master deployment. The emphasis in a consumer model related to performance is typically to reduce directory server overhead by not maintaining a localized change log database. Read only consumer directory servers do not maintain the replication
synchronization change logs.
A master or multi-master to consumer model may include DSEE6 operational based routing or write referral handling via the new DSEE6 Directory Proxy Services.
See the [Comparison of Exclusive MMR Deployments vs. Cascaded Replication Topologies] article.
h1. Contributors
{contributors-summary}
{toc:type=flat}
h1. Introduction
One of the rich features of the DSEE6 offering allows for unlimited master directory servers. The intent of this document is to provide benefits and considerations in deploying an exclusive multi-master topology in comparison to a master,consumer and replication hub directory topology.
Selection of an exclusive multi-mastered directory deployment
* Mitigates all risk in isolating existing application write behavior
* Provides the greatest aggregate performance in a highly distributed and balanced model
* Lowers administrative burden in fail-over and recovery requirements
Customers utilizing their DS5.x master(s) for read traffic typically satisfy one or more of the following models. To qualify read and write operations, write operational traffic is considered new directory object creations (in a typical user model, new user creations), object modifications (password, telephone, surname changes), or object deletions (user purging). Read operational traffic is considered search operations (in a typical user model, authentications, authorizations, and entitlements).
h1. Legacy Master Read Operation Usage Models
h2. Limited Server Architectures
Customers may combine read and write traffic on the same physical server(s) typically within the DS5.2 framework, this model is used to save in hardware costs. Services are potentially impacted during peak usage and maintenance. Degraded performance may be realized to provisioning (write) applications during heavy read operation load, and alternatively when heavier write demand impacts read/search availability. Higher availability is generally not a key business requirement in these DS5.2 models.
h2. Applications Conducting Read and Write Operations
Profiles in this model typically includes, customers with limited knowledge of the behavior or capabilities of their business applications and may direct all operations to masters to avoid write referral requirements.
Application owners may independently direct new applications to the master(s) without consent of the Directory owners/administrators. They are sometimes only identified when observing directory server read operation statistics.
Bulk provisioning applications directed to the Master(s) conduct minimal required Read Operations to manipulate
target directory objects.
Within this model multiple DS5.x Directory Proxy Server instances are sometimes deployed, one or more designated for bulk provisioning applications utilizing weighted or fail-over routing, the other(s) designated for everything else including random writes distributed across a balanced routing table.
h1. DSEE6 Rich Feature Set (specific to write operations)
A number of enhancements are introduced within the DSEE6 offering specific to Write Operational performance and agility, and may be considered during the architectural definition stage.
* Faster Write Acceptance
* Unlimited Master Directories Supported
* Increased Write Speed Realized by distributing Write Operations
* Write Affinity Ability
* Enhanced Replication Ability and Speed
* Support of Full and Partially Meshed Replication Topologies
* Increased Management and Administration of Replication
* Operational Based Routing Ability
* Enhanced Proxy Routing Based on Availability
* Enhanced Memory and Cache Management
* Global User Lockout on Failed Password Attempts
h1. Write Referral Risk / Mitigation
Some DS5.x customers have experienced risk related to applications and clients unable to effectively follow write referrals when write operations are requested from a Consumer (read-only) directory server. This risk was mostly mitigated through use of Sun's Directory Proxy Server(s) as the Directory Proxy Server may be defined to follow write referral requests on behalf on clients and applications. This transparent proxy operation is successful except where some applications as written do not generate the appropriate return codes. In these cases a few options existed to mitigate this risk, mostly around small adjustments in the application code, or through application environmental variables. Another mitigation historically used is to direct these specific applications/clients to master directory servers where write referrals are not presented or required. This risk can be further mitigated within the DSEE6 offering.
DSEE6 supporting an exclusive Multi-Mastered Directory architecture with unlimited masters can avoid write referral requirements as each master will have the ability to accept localized write operations. The DSEE6 Directory Proxy Server also has the ability to direct Write Operations to the master directory servers. This may be defined according to design preference where a primary master may be thought of as the target or may be routed via a balanced or weighted definition across the master directory servers. DS5.x also supported an exclusive Multi-Mastered Directory architecture with a supported limit of 4 Multi-Mastered Directory servers.
h1. New DSEE6 Multi-Master Considerations
Full exclusive use of master directory servers will be a common deployment practice within DSEE6 use. It is expected that "Read Only" consumer directories may only be deployed addressing specific business requirements. A full master topology will provide such high availability, increased aggregate performance advantages and growth flexibility that it's expected read-only consumer directories may be less desirable and may only be utilized to fulfill specific business requirements. It's expected that Replication Hubs frequently used within DS5.x architectures may become less significant in DSEE6 deployments. Support of full and meshed replication topologies and the enhanced management of replication agreements are likely to make Replication Hub components less relevant, and without cost advantage.
Customers would likely replace this replication hub concept in their legacy deployments with an additional multimaster directory so as to gain additional aggregate performance in a load balanced strategy, and provide additional unattended fail-over redundancy within their framework. Failed "password attempt counts" synchronization is achieved via writable Master Directory servers. Consumer directory servers may be leveraged in a failed password retry count model when operational routing is used directing authentications to Masters. Comparisons between exclusive master directory models and master to consumer models are indicated later within this document.
h1. Potential DSEE6 Consumer Directory Deployment Models - (read only)
h2. Fractional Replication Consumer Directory Servers
Directories deployed with a minimal set of user attributes, in a read only state, these servers may be positioned in unsecured openly accessible areas (DMZ's) . These fractionally replicated consumer directory servers may be configured with lower hardware requirements than the masters based on their limited data sets, potential for lower indexing and cache, and lack of a change log database.
h2. Highly Secured Consumer Consideration
Consumer directory servers are not capable of accepting write operations. These servers can be further protected by prohibiting indirect client/application writes via blocked write referrals when Directory Proxy Servers are used. Consistent protections can be provided in an exclusive master deployment as well through options available within the directory proxy servers and native directory server. A typical use case for a restricted consumer read only topology where writes can not be introduced even indirectly via referrals, may be one where the authoritative source of data exists in a back-end data repository pushed to the LDAP directory. Manipulation of data will never be initiated within the LDAP architecture by LDAP clients or applications. The LDAP architecture in this model is basically a consumer of changes made from other data sources, pushed to the LDAP directory.
h2. Light Weight Consumer Consideration
Consumers may be deployed in a combined master to consumer directory model consistent with the past DS5.x model. There is little gained in this two directory server profile model (three profiles when replication hubs are used), and includes a loss of some of the benefits gained in a full exclusive master deployment. The emphasis in a consumer model related to performance is typically to reduce directory server overhead by not maintaining a localized change log database. Read only consumer directory servers do not maintain the replication
synchronization change logs.
A master or multi-master to consumer model may include DSEE6 operational based routing or write referral handling via the new DSEE6 Directory Proxy Services.
See the [Comparison of Exclusive MMR Deployments vs. Cascaded Replication Topologies] article.
h1. Contributors
{contributors-summary}