Thanks
-----Original Message-----
From: rob@xxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Sent: Mon, 9 Apr 2007 2:12 PM
Subject: Re: Enterprise Identity Mapping (EIM) in a High Availability (HA)
environment
From the pmr:
ACTION TAKEN: Here's a short book on the subject of HA EIM culled from
discussions with several customers.
=============
LDAP Fail-over
The approach recommended by the IBM directory (LDAP) teams is to use a
load balancer (WAS Load Balancer Edge Component, or something with
equivalent capability). The idea is that you have multiple LDAP servers
- ldap-1 and ldap-2 in your network, and the load balancer set up as
ldap-router. The load balancer normally routes all new connections to
its LDAP port to ldap-1. If ldap-1 is down, the load balancer routes to
ldap-2. Applications like WAS or EIM are configured with ldap-router as
the LDAP server host name. Under normal operation, all their
connections go through ldap-router to ldap-1. If ldap-1 fails, existing
LDAP connections start getting errors and the applications try
reconnecting. These new connections, and any other new connections, are
now routed to ldap-2.
Normally the load balancer is set up to prefer one server over the other
in this kind of usage.
This kind of approach is widely used to load balance web servers.
Some customers have implemented fail-over via other means:
- IP address takeover in conjunction with replication
- Dynamic DNS updates in conjunction with replication
==================
Multi-master capability
The preferred solution to having multiple master servers is the use
peer-to-peer replication provided in V5R3 and later.
V5R2 is intended to support a single master with one or more read-only
replicas. If fail-over to another master server is required, and V5R2
is required, there is a solution that some customers have implemented.
This solution provides a primary server with a single replica. In event
of a failure, a process is set up to swap the roles of the two servers.
Applications only access one of the servers, using use of the mechanism
described above, with replication keeping the other up to date.
This solution requires a network with two V5R2 LDAP servers: primary and
alternate. In normal operation all LDAP traffic goes to "primary" and
"primary" replicates to "alternate" which is a read-only replica. When
some failure detection process detects that "primary" has failed, the
process changes the configuration of "alternate" so that it is a master,
possibly with "primary" as its replica, and then restart "alternate",
with LDAP traffic now routed to "alternate".
This involves a few tasks:
1. Deciding when to fail-over - I imagine this is handled in various
ways
2. Reconfiguring "alternate" to become a master - converse for "primary"
when it comes back up
3. Setting up the replication information
(1) can be done by periodically trying to connect to the ldap server, or
otherwise monitoring the system and/or LDAP server job.
(2) is pretty straightforward. Look at the QgldChgDirSvrA API, format
CSVR0100:
To convert a replica to a master, call this API with the "server is
replica" field set to 0 and all other fields "unchanged". Then restart
the LDAP server so it reads the new configuration.
To convert a master to a replica, call the same API, but set the
following 3 fields:
"server is replica" = 1
update DN = DN to be used by the master server to connect to this server
for replication
update password
(3) isn't too bad either:
When you add replicas to a V5R2 or ealier server, this information is
represented as directory entries under cn=localhost. The server ignores
these entries if it is configured as a replica. You could temporarily
make a server into a master, add the desired replica information via Op
Nav, then switch it back to an alternate. That server will be ready to
replicate if it is switched back to a master.
Or, you could see what the replica entries in cn=localhost look like on
the existing master (search while connected as the administrator) and
have an application add the entries to the server when it comes back up
as a master.
==============
Putting these together:
The customer should set up replication between two LDAP servers. This
can be simple master/replica topology supported by V5R2, V5R3
peer-to-peer, or the kind of solution I described above.
A load balancer (or alternate solution) is placed in front of these
servers.
EIM is configured on all systems such that the EIM domain controller
host name is the load balancer. Do not use an address that directly
accesses either LDAP server, except when first creating the EIM domain
(if using the EIM wizard to configure the primary LDAP server).
The domain and all registries are created on the primary server, which
replicates this information to the backup server.
In event of a failure, the load-balancer redirects LDAP connections to
the backup server.
Hopefully this gives you the information that you need.
Regards,
(IBM name withheld)
Rob Berendt
midrange.com
