Choosing High-Availability Options

There are essentially two options to make your directory service highly available. The first option is to deploy the built-in data replication facility of the Sun ONE Directory Server software. The second option is to deploy Sun Cluster technology.

The replication facility has been available for some time and is well documented, therefore this section only focuses on a new feature in Sun ONE Directory Server software that allows replication over a wide area network (WAN). Replication by itself, does not provide client failover capability, so failover techniques are discussed. Finally, sample deployments of the LDAP data agent for Sun Cluster 3 software are provided.

Wide Area Network (WAN) Replication

Performing reliable and consistent data replication over a WAN presents challenges. This is because WAN links typically operate at much slower speeds than local area network (LAN) speeds that are 100 Mbyte/second or greater. The slower speed produces greater latency that can prevent multi-master replication from working properly, as is the case with the Sun ONE Directory Server 5.1 implementation.

The problem occurs because the supplier needs to wait for an acknowledgement from the consumer to assure that the update was received. While this is not an issue over high speed LANs, the longer latency time over WANs make this implementation unworkable. To get around this problem, Sun ONE Directory Server 5.2 allows you to group changes before they are sent, and to compress the data.

Grouping allows you to specify a certain number of requests that can be sent to the consumer without the supplier having to wait for an acknowledgement from the consumer before continuing. You use the ds5ReplicaTransportGroupSize attribute to specify the number of changes that can be grouped into a single update request and the ds5ReplicaTransportWindowSize attribute to specify the number of sendUpdate requests that can occur before consumer acknowledgement is required. The default group size is 1 and the default window size is 10 , which means that unless otherwise specified, default replication behavior will not group requests, but will allow ten sendUpdate requests to be sent before consumer acknowledgement is required.

The correct window size will depends on the latency and bandwidth of your WAN connection. You should analyze these factors. The group and window sizes are based on the number of entries, not the size of the entries. Therefore, it may be difficult to tune these parameters if your entry sizes vary greatly.

Client Failover

Once you have set up data replication, you need some mechanism to direct your LDAP clients to access an alternative LDAP server if the current one fails. The LDAP specification does not define how client failover should happen, so it is up to you to decide to include client failover and how it should be implemented. The Secured LDAP Client was designed to allow specification of a list of potential servers to contact in case of a problem.

There are three attributes that affect how client failover takes place. These are;

• preferredServerList

• defaultServerList

• bindTimeLimt

The preferredServerList attribute is a list of servers specified in the order you want to contact them. Contact to these servers is attempted before those listed in the defaultServerList attribute. The servers can be listed as IP addresses or fully qualified host names . IP addresses are preferable because they do not rely on a name service.

The defaultServerList attribute contains a list of servers. The default action for Version 1.0 clients is to choose servers on the local subnet first, not by the order specified. This does not apply to Version 2.0 clients.

The bindTimeLimit attribute specifies the amount of time to wait until a connection to an alternate server is attempted. Once it is determined that the primary server is not responding, the alternate is used for subsequent operations. The client occasionally tries the primary server again to see if it is back online.

Note

If you are using SSL server certificates that contain the LDAP server's fully qualified DNS name, the client will have to be able to resolve it. You can still specify the IP address, but need to have DNS running or the FQN specified in /etc/ hosts .

An alternate method of client failover is to use an external device or mechanism such as:

• DNS round- robin

• Load-balancing switch

• LDAP proxy server

DNS round-robin is a technique often used to balance the load access to web sites. The way it works is to have multiple IP addresses listed for a particular DNS host name. When a DNS lookup is performed, the requestor is sent back one of the IP addresses in the list. The next requester is sent to the next IP address in the list, and so on. The problem with using DNS round-robin with Secured LDAP Clients is that the client will cache the IP address returned by DNS and use that one instead of performing additional lookups. You can disable caching, but this can have undesirable side effects.

Load-balancing network switches are very popular. The way they work is to create a virtual internet protocol (VIP) that references a list of real IP addresses. The client always connects to the VIP address, which directs it to one on the list. If a server on the list fails to respond, client requests are not sent to it.

An alternative to using hardware switches is to deploy a software solution like the Sun ONE Directory Proxy Server 5.2 software. This solution provides much more flexibility than load balancing switches and provides complex LDAP filtering. Additional benefits are:

• Provides automatic LDAP referral following that makes it possible to balance across both masters and consumers and have referrals automatically followed if a client writes to a consumer.

• Provides LDAP protocol validation, which prevents malformed requests from reaching the directory servers. This can prevent intentional or unintentional server crashes.

• Detects certain types of denial of service (DoS) attacks and prevents clients from having a significant impact from these attacks.

Note

If you are deploying TLS/SSL with Directory Proxy Server 5.2 software, the server certificate for each LDAP server should contain the DNS name of the VIP, rather than the real DNS name of the LDAP server. Also, TLS/SSL Client Authentication cannot be used.

Sun Cluster 3 Software LDAP Data Services

Sun Cluster 3 technology provides a framework for creating highly available data services. The way this technology works is to place all the application or service data on a shared disk volume and create a VIP that can be transferred to any node in the cluster. Clients access the data service by specifying the VIP instead of the server's real IP address. Data replication is performed at a low levels, mirroring the data disks. A probe is continually run to monitor the health of the server that owns the VIP. If it fails, the VIP is transferred to a healthy server.

To create a cluster that supports the Sun ONE Directory Server, two components are required:

• Sun Cluster 3 core components

• Sun Cluster 3 LDAP data services

The core components provide the software required to perform the hardware failover and the framework for handling generic data services. The LDAP Data Services provide the probe and specific instructions on how to failover the LDAP service. The installation and configuration of Sun Cluster 3 core components is well documented, so it is not covered here. Instead, the focus is on the LDAP Data Service.

The Sun Cluster 3 LDAP data services are contained in two SVR4 packages:

• SUNWasha Administration Server component

• SUNWdsha Directory Server component

The software for these components is placed in /usr/ds/v5.2/bin/cluster . Instructions on how to configure these services can be found in Appendix C of the Sun ONE Directory Server Installation and Tuning Guide .