Failover Support (IBM Security Verify Directory)

Content Platform Engine supports LDAP failover for authorization when IBM Security Verify Directory is the configured directory server.

Security Directory Server failover support for authorization

If your Content Cortex requires continuous availability and a high degree of reliability, you should configure failover for authorization. By configuring Security Directory Server failover you eliminate a single point of failure by switching automatically to another directory server when the current one becomes unavailable. This can happen for a variety of reasons, including system failure, decommissioning the directory server, stopping the server for maintenance, or changing its host name. Because failover happens automatically and no application restart is necessary, users usually do not experience service disruption.

To provide failover support for authentication, that is, for login, use the features of the Content Platform Engine application server. Consult your application server documentation.

Failover using virtual IP

A load balancer with a virtual IP address can be used to distribute directory service workload. When connecting to the virtual IP, the request is routed to a directory server behind it. If you configure session affinity on your load balancer, requests from the same client always get routed back to the same server. When that directory server is brought down, the connection is lost and the ongoing LDAP operation errors out. However, by using virtual IP failover, Content Platform Engine will catch the error and send a connection retry request back to the load balancer which dispatches the request to a different directory server still in service

Failover using a list of host:port pairs

The failover list method is useful if you have a preferred order of servers for your failover sequence. A failover list consists of one or more host:port pairs, for example, host1:389 host2:389 host3:389. The host can be a host name or an IP address. The host name can be either a short name such as host1 or a fully-qualified DNS name such as host1.mydomain.com. Although it is possible to specify only one pair in the failover list, you should have two or more pairs to create a true failover sequence.

For best performance, you should create your failover list by using a Security Directory Serverthat is local to your Content Platform Engine servers, that is, at the same network site. If you must specify remote a Security Directory Server and you are using the host:port pair method, place the remote servers at the end of the failover list.

When Content Platform Engine is started, it attempts to connect to each pair in order from left to right until it finds a working pair. Content Platform Engine then uses this pair for LDAP access until the server that is specified by this pair becomes unavailable for some reason. Content Platform Engine then starts the failover process again by going back to the beginning of the failover list and trying each pair from left to right. If it cannot connect to any pair in the list, various types of errors are generated on the client, depending on the point of failure. For example, it might be a DNS error such as UnknownHost, a network error, or a connection refused error.

Specify a failover list in the DirectoryServerHost property of the DirectoryConfiguration class. Because each pair contains a port number, Content Platform Engine ignores any value in the DirectoryServerPort property. Separate each pair with a space character. The following table shows examples of a failover list:

Table 1. Failover configuration example that uses host:port pairs
Properties in Administration Console for Content Platform Engine	Value
Host	`host1:389 host2:389 host3:389` (for nonsecured connection) `host1:636 host2:636 host3:636` (for SSL connection)
Port	Content Platform Engine ignores any value in the Port property

Failover using multiple IP host name

In DNS server, you can create a host name that maps to multiple IP addresses, and each IP represents Security Directory Server. It can be configured so that Content Platform Engine server retrieves those IP addresses by its host name, and fail over among those IPs. For an extended example, make the following assumptions:

You have three Security Directory Servers that replicate to each other.
Their IP addresses are 10.10.10.11, 10.10.10.12, and 10.10.10.13.
Their port numbers are 389.

For this example, create the following records in your DNS server:

Name           Type            Data
==========================================
tdsServers     Host (A)        10.10.10.11
tdsServers     Host (A)        10.10.10.12
tdsServers     Host (A)        10.10.10.13

Notice that the host name tdsServers is mapped to three IP addresses. Using Administration Console for Content Platform Engine, you can set tdsServers as the value of Host field, and 389 as the value of Port field. During the failover process, Content Platform Engine performs the following steps:

Content Platform Engine searches DNS server by host name tdsServers and gets back the following three IP addresses.
- 10.10.10.11
- 10.10.10.12
- 10.10.10.13
Content Platform Engine pings all three IPs at the same time, and chooses the first that responds. Assume 10.10.10.12 responds first and is chosen by Content Platform Engine.
Content Platform Engine connects to URL ldap://10.10.10.12:389 for each LDAP operation.
If TDS server 10.10.10.12 is brought down, Content Platform Engine starts the failover process again, beginning from Step 1.

The benefit of using multiple IP host name for failover is that you do not need to modify a failover list when you decommission a Security Directory Server or change its host name. Instead, the DNS data will be updated in DNS Server, and Content Platform Engine will read the latest DNS data when it needs to fail over to another Security Directory Server.

In some cases, this method is preferable to the host:port pairs method. For example, if you have many applications communicating with many directory servers and a directory server is decommissioned or its host name is changed, you change it in the DNS server and all applications will use the updated DNS data to perform failover. No application restart is necessary. Also, the multiple IP host name method uses the services of the DNS server and can require less maintenance than other methods.