Openldap cluster on Linux

Linux servers have the following features: low cost, excellent performance, and open code. More and more enterprises are preparing or adopting Linux to take on the important responsibilities of enterprise application servers. This article describes how to deploy a high-reliability LDAP authentication service in Linux and other open suites.

The software used by the system includes:
◆ Red Hat 7.2;
◆ OpenLDAP 2.1, www.openldap.org;
◆ Heartbeat 1.04, www.linux-ha.org.

Reasonable process to provide high reliability

OpenLDAP is used in the network application system of the system to provide unified identity authentication services for all applications, including querying other information such as mail routing, address, and contact information. As a special database, LDAP optimizes and processes read and query operations to ensure the query speed, therefore, it is particularly suitable for unified authentication services of enterprises, so as to standardize the same login identity and password of various business systems. Of course, its disadvantages are as obvious as its advantages. For example, it is not good at update and insert operations, but if it is used as a central authenticated database, you can use its strengths to circumvent its weaknesses.

Because the system uses LDAP as the Central Authentication database for all applications, once the LDAP server fails, all applications dependent on the database in the system network environment will be affected, or even stop providing corresponding services. To avoid this situation, we need to establish a high-reliability Authentication database cluster through two LDAP servers, and provide a unified database access network interface for other application systems. System Network Structure 1.

Figure 1 System Network Structure

As shown in figure 1, the entire system is divided into three layers: Application Server, database intermediate engine, and OpenLDAP database cluster. All application servers access 192.168.1.200 through the database intermediate engine (MIDD) and access the LDAP database through this unified database network interface. The system requires that the master server (192.168.1.100) be bound to 192.168.1.200 to provide services normally, and the slave server is in the STANDBY state. If the master fails, the slave can automatically take over the tasks, at the same time, the system administrator is notified through a certain communication method (such as email or SMS ).

Here, the MIDD database intermediate engine is a simple tool based on your needs. It can be used for the following purposes:
◆ Unify the interface for applications on the application server to access various databases. For example, you may replace the background LDAP database with other databases, such as Oracle. In this case, you only need to change the MIDD configuration file without making any changes to the application.
◆ Process pool is used to provide the application query speed. MIDD can automatically adjust the number of processes in the process pool by loading access to the front-end applications. At the same time, each process in the process pool maintains a persistent connection with the LDAP database in the background. This avoids the resource waste and delay of opening a connection for each query under normal conditions.
◆ A midd is deployed on each application server. In this way, the application communicates with MIDD through the local IPC each request, avoiding the overhead of TCP connection.
◆ Application Mode of MIDD in active-Active Mode of two LDAP databases. MIDD can automatically differentiate read and write requests based on the startup parameters. It will allocate write requests to the master LDAP database because the slave LDAP database can only perform read operations. When the network load is large and two LDAP databases provide services at the same time, the MIDD mode is used, can I avoid the slave LDAP database being unable to change the data, so that the two servers are not able to perform the downnp service without quality?

According to the requirements of the above process, the system must solve two problems. First, because the two servers used as LDAP databases do not achieve storage sharing, therefore, the master and slave database servers must be synchronized in real time to ensure that the complete service can be provided once the slave takes over the task. Second, the master and slave must be able to detect the health status of the other Party in real time. Once the other party is found to be faulty, they can take over various tasks, including switching the virtual IP address and LDAP Service (changed to the master LDAP service, this means that it can perform write operations, so that the master server must first perform a data synchronization with slave after recovery ), and use rsh to run the MIDD startup mode (in active-active mode) on other remote application servers ).

The above two problems will be solved: Data Synchronization and task taking over.

Master and slave LDAP Server Data Synchronization

Openldap provides a replication mechanism to ensure data synchronization between master and slave nodes on the network. The slurpd daemon implements this function. It regularly checks log files on the master server master and checks whether data on the master is updated. If there is an update, the updated data is transmitted to each slave server. Read (query) requests can be responded by any server in the LDAP Data Group, but write operations (update and insert) can only be performed on the master server, this is why the MIDD database intermediate engine must adopt different startup modes for read/write processing.

The following describes the configuration process of the master and slave LDAP servers. For the OpenLDAP installation process, you can view the installation documentation on the http://www.openldap.org, which is not described here. Install OpenLDAP on the two servers and configure the master and slave servers respectively.

1. The configuration file on the master LDAP Server (master) is as follows. This is a simple configuration example.
Configuration File Name: slapd. conf
File Content:

include /Opt/LDAP/etc/openldap/schema/core.schemainclude /Opt/LDAP/etc/openldap/schema/corba.schemainclude /Opt/LDAP/etc/openldap/schema/cosine.schemainclude /Opt/LDAP/etc/openldap/schema/inetorgperson.schemainclude /Opt/LDAP/etc/openldap/schema/java.schemainclude /Opt/LDAP/etc/openldap/schema/nis.schemainclude /Opt/LDAP/etc/openldap/schema/misc.schemainclude /Opt/LDAP/etc/openldap/schema/mail.schemainclude /Opt/LDAP/etc/openldap/schema/openldap.schemaaccess to * by self write by dn.base="cn=Manager,dc=yourdomain,dc=com" write by * readpidfile /Opt/LDAP/var/slapd.pidargsfile /Opt/LDAP/var/slapd.args# ldbm database definitions#database bdbdatabase ldbmsuffix "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.replogdirectory /Opt/LDAP/var/ldbm# Indices to maintainaccess to attr=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=yourdomain,dc=com" write by * noneaccess to * by self write by dn.base="cn=Manager,dc=yourdomain,dc=com" write by * nodeindex objectClass eqreplica host=slave:389 binddn="cn=Manager,dc=yourdomain,dc=com" bindmethod=simple credentials=test

 

2. Configure files from the LDAP server (slave.
Configuration File Name: slapd. conf

File Content:

include /Opt/LDAP/etc/openldap/schema/core.schemainclude /Opt/LDAP/etc/openldap/schema/corba.schemainclude /Opt/LDAP/etc/openldap/schema/cosine.schemainclude /Opt/LDAP/etc/openldap/schema/inetorgperson.schemainclude /Opt/LDAP/etc/openldap/schema/java.schemainclude /Opt/LDAP/etc/openldap/schema/nis.schemainclude /Opt/LDAP/etc/openldap/schema/misc.schemainclude /Opt/LDAP/etc/openldap/schema/mail.schemainclude /Opt/LDAP/etc/openldap/schema/openldap.schemaaccess to * by self write by dn.base="cn=Manager,dc=yourdomain,dc=com" write by * readpidfile /Opt/LDAP/var/slapd.pidargsfile /Opt/LDAP/var/slapd.args# ldbm database definitions#database bdbdatabase ldbmsuffix "dc=yourdomain,dc=com"rootdn "cn=Manager,dc=yourdomain,dc=com"rootpw test#replogfile /Opt/LDAP/var/slapd.replogdirectory /Opt/LDAP/var/ldbmaccess to attr=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=yourdomain,dc=com" write by * noneaccess to * by self write by dn.base="cn=Manager,dc=yourdomain,dc=com" write by * readindex objectClass eqaccess to * by self read by dn="cn=Manager,dc=yourdomain,dc=com" write by * noneupdatedn "cn=Manager,dc=yourdomain,dc=com"

After configuring the master and slave LDAP databases respectively, you can use the tools provided by OpenLDAP to initialize the data in the master LDAP database.

3. Data synchronization.
Before running the master and slave modes, you must synchronize the master and slave data on the LDAP server. You can copy the data files on the master node (all files under the ldbm directory in this example) directly to the slave LDAP server to achieve full data consistency between nodes.

4. Start the service
Start services separately to test whether data synchronization is effective. Start two processes on the master LDAP Server:
#/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 &

Then start the process from the LDAP server:
#/Opt/ldap/libexec/slapd-F/opt/ldap/etc/OpenLDAP/slapd. conf-D 5>/dev/null 2> & 1 &

Update the data on the master LDAP server, including adding, deleting, and modifying the data. Then, check whether the data is synchronized with the master LDAP server. Through the above tests, the master and slave LDAP database servers have achieved the data synchronization replication effect.

Use heartbeat to automatically detect and take over tasks

1. Brief introduction to the HA software in Linux

(1) the high availability Linux Project
Its heartbeat software can not only be used independently as Ha software with high reliability, but also be used with other IP distributors for balancing cluster applications. See http://www.linux-ha.org.

(2) lifekeeper
Lifekeeper is a well-known high-reliability software that supports 32-node applications and operating systems such as Linux, x86 Solaris, and windows. See http://oss.missioncriticallinux.com/projects/kimberlite.

(3) srrd
Srrd (Service Routing redundancy Daemon) supports PKI and SSL communication authentication. See http://srrd.org /.

Choose the heartbeat ha software provided by Linux-ha to achieve high reliability of the system. The software name is heartbeat. The latest version is 1.2. Heartbeat manages operations by monitoring the status of several nodes. The monitoring mode supports communication between the serial line and Ethernet as the media. Here, the Ethernet link is used. Run a daemon process named heartbeat on each node in the cluster. The main daemon sends child processes to read and write each heartbeat media and derive State processes. When it is detected that the node is terminated, heartbeat runs shell scripts to switch and take over resource tasks, thus ensuring the high reliability of the entire system.

2. Download and install heartbeat
You can download the latest installation packages, including srcand rpm, from http://www.linux-ha.org/download. In this example, the heartbeat-1.0.4.tar.gz package is installed as follows:

#./configure -prefix=/opt/ha#make#make install

During this process, the system may remind you to install other dependent software packages, such as Libnet, and download and install them as prompted. After the installation is complete, related subdirectories will be generated under the/opt/ha directory. Go to/opt/HA/etc/ha. D and create the following files in the directory: Ha. Cf, authkeys, haresources, and myexec.

3. Master configuration instructions:

(1) Ha. cf

Logfile/var/log/ha-loglogfacility local0keepalive 2 deadtime 30 warntime 10 initdead 120 ucast eth0 192.168.1.101nice _ failback on // After the Server Load balancer is changed to a master node, the master node will not be transferred even, this ensures LDAP data synchronization. Node masternode slave

(2) authkeys
Auth 3
3 MD5 Test

(3) haresources
Master 192.168.1.200 myexec

(4) enter/opt/HA/etc/ha. d/resource. D and create the execution script myexec.
When the heartbeat software detects a fault on other nodes, it executes the script and completes the following work: if the local machine is a master LDAP server, it must be in some way (via email or SMS) to notify the system administrator that the slave server is faulty. If the slave server is monitored from the server to the unavailable status of the master server, the LDAP service must be started in the master LDAP mode, use rsh to restart the remote MIDD startup mode.

 

The myexec file content on the master LDAP server is as follows:

Masnode = 'master' pidfile =/opt/ldap/var/slapd. pidapp =/opt/ldap/libexec/slapdslurp =/opt/ldap/libexec/slurpdmaster =/opt/ldap/etc/OpenLDAP/slapd. master. confslave =/opt/ldap/etc/OpenLDAP/slapd. slave. conf. /opt/HA/etc/ha. d/shellfuncstest_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 shoshould 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 // start 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 '& // start ldap/usr/bin/rsh MailServer'/opt/sbin/MIDD-M Master-s slave 'on the slave server & // start MIDD $ slurp- F $ master // start the replication process 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 esacexit 0

(5) Create the/opt/HA/etc/ha. d/resource. d/slapd. Slave file.

#/bin/sh/opt/LDAP/libexec/slapd -f /opt/LDAP/etc/openldap/slapd.slave.conf -d 5 > /dev/null 2>&1 &

So far, the master server configuration is complete.

The configuration on the slave server is exactly the same as that on the master server. The difference is that the "master" is changed to "slave ". At the same time, it should be noted that the two servers must be able to execute RSH; the other is that in several nodes, the configured host names can be resolved to the IP addresses of each other. In this way, the HA configuration of the entire system is complete.

(6) Start heartbeat
First run # Kill slapd and then start heartbeat on the master:
#/Etc/init. d/heartbeat start

Then start heartbeat on slave:
#/Etc/init. d/heartbeat start

Run # tail-F/var/log/ha-log to check whether the service is started properly. If it runs normally, the current state is that the master provides the master LDAP service, and the slave provides the slave LDAP service.

Test

1. Assume that heartbeat on the master server stops the service.
Run #/etc/init. d/heartbeat stop. The expected status of this test is that slave takes over the master service and becomes the master LDAP service. You can check the log to determine whether the expected results have occurred.

In this case, because the master itself is not disconnected, but the heartbeat service is stopped, when the slave becomes the master LDAP service, the master will be started from the LDAP service through the rsh command at the same time. At this time, even if the master node restarts heartbeat, the current master and slave modes will not change, that is, the slave server is still running as the master LDAP service, and the master server is running as the slave LDAP service, this ensures that the data synchronization between the two servers will not be chaotic.

2. Assume that the network of the Master System is faulty (unplug the network cable)
Unplug the network cable of the master in the test, but various processes are still running. When slave becomes the master LDAP service, because slave detects that the master is dead, the slurpd data synchronization process is not started when it becomes the master LDAP service. In this case, the data on the slave is updated, and the master network is restored (with a network cable inserted). It is observed that the master is changed to the master LDAP server again, and the slave is changed to the slave LDAP server again. This will cause data synchronization problems. The data updated when the slave is a master service is not updated in the master.

3. Assume that the master system is completely crashed (power off)
After the two servers are started normally, reboot the master server master. In this case, Slave becomes the master LDAP server and does not start the slurpd process. Update the LDAP database at this time. After the master restarts, the slave service does not change when the heartbeat process is not started. Starting the beartbeat service on the master node remains unchanged. At this time, only two LDAP processes can be manually started to restore Data Synchronization while the slave is the master LDAP service. The specific method is to start slurpd on the slave server and Server Load balancer server on the master server to synchronize data.

After synchronization, stop heartbeat on the master and restart the heartbeat service on the slave. At this time, the results were satisfactory, and the master again gained control of the master LDAP service. slave was started as a process from the LDAP service without interrupting the LDAP service.

The above test shows that the problem to be solved is how to ensure data synchronization in 2nd cases, and slurpd service can be automatically started by slave after the master server is started in 3rd cases.

In 2nd cases, the failure of communication between the two nodes causes both machines to think that the other node is faulty, and thus tries to act as the master node by themselves, this eventually leads to competition in resources and data synchronization chaos. One way to solve this problem is to implement network detection through multiple communication means, so as to avoid this situation due to temporary network problems.

In 3rd cases, you can ensure the existence of the slurpd process (modify the slapd script) as long as the server starts the slurpd process as the master LDAP ). For servers recovered from the fault, you can manually start the LDAP service mode or put it in the system startup script to ensure the existence of the LDAP service after recovery.