LDAP Server Availability


LDAP is a data store-based system that's somewhat like a database but instead of being object-orientated or relational, it's directory based. The key to an LDAP environment is that it's a high-read, low-write infrastructure. Tuning an LDAP environment is about ensuring that Input/Output (I/O) is distributed across many disks and that caching and network infrastructure are optimized and sized correctly.

WebSphere supports several LDAP servers:

  • IBM Secureway Directory Server

  • Novell eDirectory server

  • Lotus Domino Enterprise Server

  • Sun ONE Directory Server

  • Windows 2000 Active Directory (with LDAP extensions)

You'll now look at some LDAP servers and how they integrate with WebSphere.

Options and Considerations

In this chapter, I'll assume you have a working understanding of each of these platform technologies. I'll focus on what to consider when integrating WebSphere with these technologies in a highly available manner.

Too often I've been involved with WebSphere implementations that are pear-shaped because of poorly performing or low-availability third-party systems. Although an external interfacing system with long transaction times (for example, greater than five seconds) isn't necessarily a bad thing, solid application architecture and design needs to insulate the online WebSphere applications from the slower performing external application. An example of this is having a splash screen that presents a message to the user saying "Please wait " or prefetching the required information, if possible, while the user is logging into the application and thus hiding (masking) any high-latency transactions.

In a LDAP and WebSphere mixed environment, if your WebSphere applications require constant access to the LDAP environment, then the LDAP servers should be clustered. Like WebSphere clustering techniques, there are three forms of clustering available for LDAP environments:

  • Hardware clustering

  • LDAP server clustering

  • A combination of both

As you saw in earlier chapters, hardware clustering is the use of third-party "clusterware" products that provide failover and active-standby (or active-active) clustering solutions. By using a clusterware solution such as Hewlett-Packard's MC/ServiceGuard, Veritas Cluster Server, or something similar (see Chapter 7), you're able to set up a high-availability cluster with a master/slave configuration. Should one of the nodes fail, the clusterware would "Internet Protocol (IP) address failover" the LDAP service to another, working server. WebSphere clients would autonomously switch over to the remaining server.

LDAP server clustering is a byproduct of the LDAP technology. LDAP lends itself to being a highly available and robust technology at a fundamental level. Because it's a high-read, low-write technology, the synchronization sophistication isn't as complex and involved as it is for relational or object-oriented database systems such as Oracle, DB2, and ObjectStore.

Therefore, the inherent nature of LDAP means that you can gain some availability advantages when using it. In LDAP vendor-speak, an LDAP server is predominantly either a master or a replica (there are other subtypes , but I'll leave these out for the moment). If you're running an LDAP server that's being relied on by WebSphere online-based applications, use master/replica configurations to ensure that you have a failover device available should the master fail.

The third form of implementing LDAP availability is to use a combination of both IP failover clusterware and the inherent or built-in LDAP master/replica availability features.

You'll now look at the implementation of a highly available LDAP cluster in a WebSphere environment.

Implementation and Performance

It's important to remember that like any failover-capable system, there's a need to be able to control and manage transactions that may be "inflight" during the point of failure. The application developers need to write application code that supports LDAP connection failure exceptions and timeouts and that handles transaction failures and transaction rollbacks .

It's not uncommon nowadays to use LDAP over Secure Sockets Layer (SSL), meaning that you'll also need to employ some form of SSL engine on both sides of your LDAP server. This form of LDAP (sometimes referred to as LDAPS) will incur a performance hit with the overhead of SSL. Consider using SSL offloaders or SSL-compatible crypto cards that are available from most leading server vendors .

If your application is a distributed application, such as the example of a site in Seattle and a site in Washington, configuring an LDAP farm using LDAP master/replica data replication techniques is probably the best option to use for failover. This way, you're not only implementing a failover-supportive LDAP environment, but you're also employing a design that promotes performance with each site potentially having its own local LDAP replica server.

In terms of maintaining a master across all the LDAP servers in your environment, either you can use a load balancer that'll simply redirect your LDAP requests from your WebSphere hosts to the most appropriate LDAP instance or you can use the hardware-clustered solution to support a derivative of IP failover.

In this scenario, you can set up the LDAP cluster to have a master and replica LDAP architecture, as well as a master and secondary configuration in the clusterware layer. Your cluster can then expose a generic server name such as myLDAPCluster.mydomain.com , which, using IP address failover cluster configurations, will only need to communicate to myLDAPCluster.mydomain.com . Figure 8-1 illustrates this approach.

click to expand
Figure 8-1: High-availability LDAP implementation

The model used in Figure 8-1 provides a solid performing and highly available LDAP farm for your WebSphere-based applications. In this example, the load balancers distribute the requests to the most appropriate LDAP instance. The configuration also supports the ability to distribute requests based on a master-secondary configuration that's mastered by the active-standby cluster. This provides the ability for clients to interface either via a global name (for example, LDAPCluster.mydomain.com ) using the cluster or by having LDAPCluster.mydomain.com as a virtual IP managed by the load balancers.

You can configure your WebSphere application to talk to the closest LDAP node first (the local node), which may be a replica, or you can configure it to communicate with the cluster-assigned primary. You could take the implementation a step further and set up weighted round- robin connection management so that all requests are sent to the local LDAP server first (high weighting ), and if it times out because it's down, the request is sent onto the master LDAP server in the cluster.




Maximizing Performance and Scalability with IBM WebSphere
Maximizing Performance and Scalability with IBM WebSphere
ISBN: 1590591305
EAN: 2147483647
Year: 2003
Pages: 111
Authors: Adam G. Neat

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net