应用Linux上的 OpenLDAP集群 -3

 

ChinaITLab收集整理

    主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服务的存在。