Using Layered Architectures to Create Highly Available Infrastructures

[ Scenarios ] [ Scenario One: Clients Connect Directly To Directory Server ] [ Scenario Two: Clients Connect to Directory Server via Load Balancers ] [ Scenario Three: Clients Connect To Directory Servers via Load Balancers and Directory Proxy Server ] [ Contributors ]

Use load balancers and [Sun Java System Directory Proxy Server] to create high available infrastructures. Adding isolation between layers of servers increases the chances of components detecting failures in components below them. This allows administrators to create infrastructures that can be modified without knowledge to service clients.

Scenarios

Scenario One: Clients Connect Directly To Directory Server

When clients connect directly to Directory Server:

  • Clients have knowledge of directory services infrastructure, IP addresses and hostnames
  • No encapsulation of service infrastructure
  • Client must provide own failure detection and failover mechanisms - increasing client complexity
  • Uncommanded service termination causes an outage
  • Clients must provide own load balancing - increasing client complexity
  • No virtualization capability
  • Unpredictable service uptime results in unclear service level objectives
  • Simplistic solution suitable for non-critical environments
  • Replication latency and loose consistency play major roles
  • Commanded outages require at least notification of application server operators, possibly configuration change because applications have knowledge of the infrastructure
  • Might need SSL accelerators on hardware

Scenario Two: Clients Connect to Directory Server via Load Balancers

  • Better than Scenario One from an availability perspective
  • Client has no knowledge of directory services infrastructure, IP addresses and hostnames
  • Encapsulation of service infrastructure, easier to change the infrastructure without client knowledge
  • Load balancer provides load balancing and service interruption detection
  • Uncommanded service termination may not cause an outage - except for persistent connections
  • Commanded service termination possible without outage - except for persistent connections
  • Increased complexity and cost but higher availability
  • Still no virtualization capability
  • Slightly predictable service uptime
  • Replication latency and loose consistency play major roles
  • [SSL] sessions can be terminated at load balancers

Scenario Three: Clients Connect To Directory Servers via Load Balancers and Directory Proxy Server

  • Highest availability than the previous two Scenarios
  • Client has no knowledge of directory services infrastructure, IP addresses and hostnames
  • Encapsulation of service infrastructure, easier to change the infrastructure without client knowledge
  • Load balancer provides load balancing and service interruption detection, DPS provides LDAP sensitive routing
  • Uncommanded service termination may not cause an outage
  • Commanded service termination possible without outage
  • Very complex environment, requires multiple monitoring tools/agents
  • Virtualization possible
  • More predictable service uptime
  • Complex interactions realized via Directory Proxy Server
  • Isolated environment increases availability and latency
  • In some cases (but not all) replication latency not a factor due to client affinity.

Contributors

UserEditsCommentsLabels
ff1959 3010

Labels

dsee dsee Delete
ds ds Delete
directoryserver directoryserver Delete
dps dps Delete
directoryproxyserver directoryproxyserver Delete
availability availability Delete
layers layers Delete
architecture architecture Delete
redundancy redundancy Delete
clientaffinity clientaffinity Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

Copyright 1994-2009 Sun Microsystems, Inc.
Powered by Atlassian Confluence
Sun Guidelines on Public Discourse Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact