Linux服务器具有低成本、性能卓越、代码开放等特性。越来越多的企业正在准备或已经采用Linux担起了企业应用服务器的重任。本文要介绍的是笔者在实际工作中，采用Linux和其它开放套件共同部署高可靠性LDAP认证服务的实例。
系统所要用到的软件包括：
◆ Red Hat 7.2；
◆ OpenLDAP 2.1，www.openldap.org；
◆ Heartbeat 1.04，www.linux-ha.org。
合理的流程提供高可靠性
OpenLDAP在该系统的网络应用体系中用于对所有应用提供统一的身份认证服务，还包括如邮件路由、地址、联系人信息等其它信息的查询。LDAP作为一种特殊的数据库，通过对读取、查询操作进行特别的优化和处理，以保证在查询速度方面的优势，所以特别适合用来统一企业的各种认证服务，从而规范各种业务系统的同一登录身份和口令。当然，它的缺点和优点一样明显，比如不善于update、insert等操作，但是如果把它作为中央认证数据库，则正好可以利用它的长处而回避它的弱点。
由于系统采用了LDAP作为所有应用的中央认证数据库，一旦该LDAP服务器失效，则系统网络环境中所有依赖于该数据库的应用都会受到影响，甚至停止提供相应的服务。为了避免这种情况的发生，就要通过两台LDAP服务器建立一个高可靠性的认证数据库集群，同时对其它应用系统提供统一的数据库访问网络接口。系统网络结构图如图1。
图1 系统网络结构图
从图1可以看到，整个系统分为三层：应用服务器、数据库中间引擎和OpenLDAP数据库集群。所有的应用服务器通过数据库中间引擎（midd）来访问192.168.1.200，并通过这一统一的数据库网络接口来访问LDAP数据库。对于系统的要求是，正常情况下master服务器（192.168.1.100）绑定在192.168.1.200上提供服务，slave服务器处于备机状态，一旦master发生故障，slave能够自动接管任务，同时通过某种通信方式通知系统管理员（如邮件、手机短信）。
这里，midd数据库中间引擎是根据需要编写的一个简单工具，使用它要达到以下几个目的：
◆ 统一应用服务器上的应用程序访问各种数据库的接口。例如，以后有可能将后台的LDAP数据库换为其它数据库，如Oracle等，这时只需要更改midd的配置文件，而不需要对应用程序进行任何更改。
◆ 通过采用进程池的方式来提供应用程序的查询速度。midd能通过对前端应用程序的访问负载，自动调节进程池的进程数量。同时进程池中的每个进程和后台的LDAP数据库保持一个长连接，这样可以避免一般条件下每次查询都要开一个连接的资源浪费和延时。
◆ 每个应用服务器上都部署一个midd。这样应用程序每次请求的时候都是通过本地IPC与midd进行通信，避免了TCP方式连接的开销。
◆ midd在两台LDAP数据库active-active模式下的应用模式。midd根据启动时的参数能够自动区别读、写请求，会将写请求分配到Master LDAP数据库上，这是由于Slave LDAP数据库只能进行读操作。在整个网络负载大、两台LDAP数据库同时提供服务的情况下，使用midd的这一模式，可以避免Slave LDAP数据库不能更改数据导致两台服务器不能保质萃降奈侍狻?
根据以上流程的要求，系统必须解决两个问题，首先是由于作为LDAP数据库的两台服务器并没有实现存储共享，因此要求master和slave两台数据库服务器的数据必须实时同步，才能保证一旦slave接管任务后能够提供完整的服务。其次，master和slave必须能够实时检测对方的健康状态，一旦发现对方有故障，自己能够接管各种任务，包括切换虚拟IP地址、LDAP服务（变为主LDAP服务，意味着其能对写进行操作，从而要求master服务器恢复后必须先和slave进行一次数据同步），以及通过rsh方式来执行其它远程应用服务器上的midd启动模式（在active-active模式下）。
下面就将解决以上数据同步和任务接管两个问题。
主、从LDAP服务器的数据同步
OpenLDAP本身提供了一种复制机制来保证网络上主、从节点之间的数据同步。slurpd守护程序实现了这一功能，它通过定期活动检查主服务器master上的日志文件，检查master上的数据是否有更新。如果有更新，那么把更新的数据传递到各个从服务器。读（查询）请求可以由LDAP数据群中的任一服务器应答，但写操作（update、insert）只能在主服务器master上进行，这就是为什么midd数据库中间引擎必须采用不同的启动模式来处理读写的原因。
下面主要说明主、从LDAP服务器的配置过程。有关OpenLDAP的安装过程可以查看http://www.openldap.org上的安装文档，本文不再赘述。将OpenLDAP安装到两台服务器上，并对它们分别进行主、从配置。
1．主LDAP服务器（master）上的配置文件如下，这是一个简单的配置例子。
配置文件名：slapd.conf
文件内容：
include /Opt/LDAP/etc/openldap/schema/core.schema
include /Opt/LDAP/etc/openldap/schema/corba.schema
include /Opt/LDAP/etc/openldap/schema/cosine.schema
include /Opt/LDAP/etc/openldap/schema/inetorgperson.schema
include /Opt/LDAP/etc/openldap/schema/java.schema
include /Opt/LDAP/etc/openldap/schema/nis.schema
include /Opt/LDAP/etc/openldap/schema/misc.schema
include /Opt/LDAP/etc/openldap/schema/mail.schema
include /Opt/LDAP/etc/openldap/schema/openldap.schema
access to *
by self write
by dn.base="cn=Manager,dc=yourdomain,dc=com" write
by * read
pidfile /Opt/LDAP/var/slapd.pid
argsfile /Opt/LDAP/var/slapd.args
# ldbm database definitions
#database bdb
database ldbm
suffix "dc=yourdomain,dc=com"
rootdn "cn=Manager,dc=yourdomain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw test
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd/tools. Mode 700 recommended.
replogfile /Opt/LDAP/var/slapd.replog
directory /Opt/LDAP/var/ldbm
# Indices to maintain
access to attr=userPassword
by self write
by anonymous auth
by dn.base="cn=Manager,dc=yourdomain,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Manager,dc=yourdomain,dc=com" write
by * node
index objectClass eq
replica host=slave:389
binddn="cn=Manager,dc=yourdomain,dc=com"
bindmethod=simple credentials=test |
2．从LDAP服务器（slave）上的配置文件。
配置文件名：slapd.conf
文件内容：
include /Opt/LDAP/etc/openldap/schema/core.schema
include /Opt/LDAP/etc/openldap/schema/corba.schema
include /Opt/LDAP/etc/openldap/schema/cosine.schema
include /Opt/LDAP/etc/openldap/schema/inetorgperson.schema
include /Opt/LDAP/etc/openldap/schema/java.schema
include /Opt/LDAP/etc/openldap/schema/nis.schema
include /Opt/LDAP/etc/openldap/schema/misc.schema
include /Opt/LDAP/etc/openldap/schema/mail.schema
include /Opt/LDAP/etc/openldap/schema/openldap.schema
access to *
by self write
by dn.base="cn=Manager,dc=yourdomain,dc=com" write
by * read
pidfile /Opt/LDAP/var/slapd.pid
argsfile /Opt/LDAP/var/slapd.args
# ldbm database definitions
#database bdb
database ldbm
suffix "dc=yourdomain,dc=com"
rootdn "cn=Manager,dc=yourdomain,dc=com"
rootpw test
#replogfile /Opt/LDAP/var/slapd.replog
directory /Opt/LDAP/var/ldbm
access to attr=userPassword
by self write
by anonymous auth
by dn.base="cn=Manager,dc=yourdomain,dc=com" write
by * none
access to *
by self write
by dn.base="cn=Manager,dc=yourdomain,dc=com" write
by * read
index objectClass eq
access to *
by self read
by dn="cn=Manager,dc=yourdomain,dc=com" write
by * none
updatedn "cn=Manager,dc=yourdomain,dc=com" |
分别对主、从LDAP数据库进行配置后，初始化主LDAP数据库中的数据，可以利用OpenLDAP本身提供的工具完成。
3．数据同步。
在运行主、从模式前，必须先将主、从LDAP服务器上的数据同步。可以通过把master上的数据文件（本例中是ldbm目录下的所有文件）直接拷贝到从LDAP服务器上，实现节点数据的完全一致。
4．启动服务
分别启动服务，测试数据的同步是否有效。先启动主LDAP服务器上的两个进程：
#/opt/LDAP/libexec/slapd -f /opt/LDAP/etc/openldap/slapd.conf -d 5 > /dev/null 2>&1 &
#/opt/LDAP/libexec/slurpd -f /opt/LDAP/etc/openldap/slapd.conf -d 5 > /dev/null 2>&1 &
然后启动从LDAP服务器上的进程：
#/opt/LDAP/libexec/slapd -f /opt/LDAP/etc/openldap/slapd.conf -d 5 > /dev/null 2>&1 &
对主LDAP服务器上的数据进行各种更新操作，包括增加、删除、修改等动作，然后在从LDAP服务器上查看数据是否保持与主LDAP服务器同步更新。通过以上测试，主、从LDAP数据库服务器已经达到了数据同步复制的效果。
使用Heartbeat实现自动检测和任务接管
1．Linux下HA软件简要介绍
（1）The High Availability Linux Project
其Heartbeat软件不仅可以作为高可靠性的HA软件独立使用，也可以配合其它IP分发器做Balancing Cluster应用。参见http://www.linux-ha.org。
（2）Lifekeeper
Lifekeeper是一款著名的高可靠性软件，能支持32个节点的应用，支持Linux、x86 Solaris和Windows等操作系统。参见http://oss.missioncriticallinux.com/projects/kimberlite。
（3）SRRD
SRRD（Service Routing Redundancy Daemon），支持PKI、SSL的通信认证。参见http://srrd.org/。
这里选择Linux-HA提供的Heartbeat HA软件来实现该系统的高可靠性，软件名Heartbeat，当前最新版本为1.2。Heartbeat通过监控几个节点的状态来进行管理操作，监控方式支持串行线和以太网作为媒介的通信，这里使用以太网链路。在集群中的每个节点运行一个守护程序进程，名为heartbeat。主守护程序派生子进程，以对每个heartbeat媒介进行读写，并派生状态进程。当检测到节点终止时，heartbeat运行Shell脚本实现资源任务的切换和接管，从而保证了整个系统的高可靠性。
2．下载安装Heartbeat
可以从http://www.linux-ha.org/download/下载最新的安装包，包括src和rpm。本例下载了heartbeat-1.0.4.tar.gz包进行安装，具体操作如下：
#./configure -prefix=/opt/ha #make #make install |
在此过程中，系统可能会提醒安装其它依赖软件包，比如libnet等，按照提示进行下载安装即可。安装完成后在/opt/ha目录下将产生相关子目录。进入/opt/ha/etc/ha.d，在该目录下创建以下文件：ha.cf、authkeys、haresources、myexec。
3．master配置说明：
（1）ha.cf
logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 30 warntime 10 initdead 120 ucast eth0 192.168.1.101 nice_failback on//保证slave变为master后， 即使master恢复启动服务也不转移，从而保证LDAP数据同步。 node master node slave |
（2）authkeys
auth 3
3 md5 test
（3）haresources
master 192.168.1.200 myexec
（4）进入/opt/ha/etc/ha.d/resource.d，创建执行脚本myexec。
当Heartbeat软件监控到其它节点出现故障时，会执行该脚本并完成以下工作：如果本机是主LDAP服务器，则必须以某种方式（邮件或手机短信）来通知系统管理员，备用服务器出现故障；如果是从服务器监控到主服务器不可用状态，则必须以主LDAP模式启动LDAP服务，并通过rsh重新启动远程midd启动模式。
主LDAP服务器上的myexec文件内容如下：
MASNODE='master'
PIDFILE=/Opt/LDAP/var/slapd.pid
APP=/Opt/LDAP/libexec/slapd
SLURP=/Opt/LDAP/libexec/slurpd
MASTER=/Opt/LDAP/etc/openldap/slapd.master.conf
SLAVE=/Opt/LDAP/etc/openldap/slapd.slave.conf
. /opt/ha/etc/ha.d/shellfuncs
test_start () {
# first we kill everything possible
ha_log "info: $0: Starting"
if [ -f $PIDFILE ]; then
PID=`head -1 $PIDFILE`
ha_log "info: $0: Appears to already be running, killing [$PID]"
kill -9 $PID > /dev/null
rm $PIDFILE
fi
# slurpd should die when the slapd process does, but just in case:
for i in `ps -ef | grep slurp | grep -v grep | awk '{print $2}' `
do
kill -9 $i
done
# slight delay to allow for stability
sleep 2
# now we will attempt to start as a master
$APP -f $MASTER //启动slapd
if [ ! -f $PIDFILE ]; then
ha_log "warn: $0: Slapd did not start properly"
#exit 1
fi
# Now we determine if this is the primary or secondary node
# first wait a bit for stability
sleep 10
# if we are secondary, do nothing: otherwise
if [ $HA_CURHOST == $MASNODE ]; then
/usr/bin/rsh slave '/opt/ha/etc/ha.d/resource.d/slapd.slave '
&//启动从服务器上的LDAP
/usr/bin/rsh mailserver '/opt/sbin/midd -m master -s slave' & //启动midd
$SLURP -f $MASTER //启动主服务器上的复制进程
else
ha_log "warn: $0: slave node is not responding"
fi
}
test_stop () {
ha_log "info: $0: Shutting down"
if [ -f $PIDFILE ]; then
PID=`head -1 $PIDFILE`
kill -9 $PID > /dev/null
rm $PIDFILE
fi
# Let's be sure it's dead, Jim
for i in `ps -ef | grep slap | grep -v grep | awk '{print $2}' `
do
kill -9 $i
done
for i in `ps -ef | grep slurp | grep -v grep | awk '{print $2}' `
do
kill -9 $i
done
}
# See how we were called.
case "$1" in
start)
test_start
;;
stop)
test_stop
;;
restart)
$0 stop
$0 start
;;
status)
if [ -f $PIDFILE ]; then
echo running
else
echo stopped
fi
;;
*)
echo "Usage: $0 {start|stop|restart|status}"
exit 1
esac
exit 0 |
（5）创建/opt/ha/etc/ha.d/resource.d/slapd.slave文件。
#/bin/sh /opt/LDAP/libexec/slapd -f /opt/LDAP/etc/openldap/ slapd.slave.conf -d 5 > /dev/null 2>&1 & |
至此，主服务器配置完成。
slave服务器上的配置和master服务器的完全一样，差别仅在于将“master”改为“slave”。同时要注意，一是两台服务器上必须能够执行rsh；二是在几个节点中，能通过设置的主机名互相解析到对方的IP地址。这样，整个系统的HA就配置完成。
（6）启动heartbeat
首先执行#kill slapd，再启动master上的heartbeat:
#/etc/init.d/heartbeat start
然后启动slave上的heartbeat:
#/etc/init.d/heartbeat start
执行#tail -f /var/log/ha-log，确定服务是否正常启动。如果正常运行，那么当前的状态是master提供主LDAP服务；slave提供从LDAP服务。
测试
1．假设master服务器上的heartbeat停止服务
执行#/etc/init.d/heartbeat stop。该测试期望的状态是，由slave接替master的服务，变为主LDAP服务。可以通过查看日志来确定是否发生了预期的结果。
在这种情况下，由于master本身没断线，只是heartbeat服务停止，所以当slave变为主LDAP服务时，会同时通过rsh命令把master作为从LDAP服务启动。这时即使master重新启动heartbeat，当前的主、从模式也不会改变，即slave服务器还是作为主LDAP服务运行，而master服务器作为从LDAP服务运行，从而保证了两台服务器的数据同步不会因此发生混乱。
2．假设master系统的网络出现故障（拔掉网线）
测试中将master的网线拔掉，但是各种进程依然在运行。当slave变为主LDAP服务时，由于slave检测到master死去，所以在变为主LDAP服务的时候没有启动slurpd数据同步进程。这时更新slave上的数据，然后恢复master的网络（插上网线），观察发现master重新变为主LDAP服务器，slave重新变为从LDAP服务器。这会导致数据同步出现问题，当slave是主服务时更新的数据，没有在master中更新。
3．假设master系统完全崩溃（断掉电源）
两台服务器正常启动后，reboot主服务器master。这时的slave会和第2种情况一样，变为主LDAP服务器，也没有启动slurpd进程。更新此时的LDAP数据库，当master重新启动后，在没有启动heartbeat进程的情况下，slave服务没有任何变化。启动master上的beartbeat服务，仍然没有变化。这时，只能在保持slave为主LDAP服务的前提下，手工启动两个LDAP进程来恢复数据同步。具体做法是，在slave服务器上启动slurpd，在master服务器上启动slapd slave模式的服务，以达到数据同步的目的。
同步后，停止启动master上的heartbeat，对slave上的heartbeat服务实行restart。这时的结果是满意的，master又重新获得了主LDAP服务的控制权，slave作为从LDAP服务进程启动，同时不间断LDAP服务。
通过以上测试可知，要解决的问题是第2种情况下怎样才能保证数据同步，以及第3种情况下master服务器启动后slave能够自动启动slurpd服务。
对于第2种情况，由于两个节点间通信的失败导致两台机器都以为对方出现故障，从而试图由自己充当主节点，最终导致资源出现竞争状态和数据同步发生混乱。解决这个问题的一个办法是，通过多种通信手段来实现网络检测，从而避免由于暂时的网络问题导致这种情况的出现。
对于第3种情况，可以不管master是否存在，只要服务器作为主LDAP启动时启动slurpd进程，就可以保证slurpd进程的存在（修改slapd脚本）。对于从故障中恢复的服务器，可以手工启动从LDAP服务模式，也可以放在系统启动脚本中，来保证恢复后LDAP服务的存在。