Configuring the Master-Slave Replication

Symas CDS replication is used to address high availability and performance requirements. Although the CDS server is optimal for handling querying operations, with the help of replication, the CDS server can also provide performance improvement, reduce query latency by locating replicas “close” to clients, and assist with lowering the risk of a single point of failure.

In most cases, the optimal, scalable solution is the master-slave replication configuration, in which one master manages all directory update operations and the slave servers handle all directory query operations. This configuration is supported natively by OpenLDAP, and therefore, CDS. Additional slave servers can be added with limited effort after the CDS server is configured and running.

The CDS server supports two mechanisms for the master-slave replication: first, a typical implementation by slurpd daemon and second, a new method from OpenLDAP version 2.2 called content-synchronization or “syncrepl”. This document focuses on the new syncrepl method. For more information about the two replication methods, visit the Web site at:

http://www.openldap.org/faq/data/cache/1170.html

The syncrepl method uses the LDAP content synchronization protocol as the synchronization protocol to maintain a Directory Information Tree (DIT) fragment copy of the master CDS server. The syncrepl engine is a slave-side replication engine, which supports both polling and listening modes of synchronization. If the refreshOnly mode is used, the syncrepl engine is triggered periodically and checks whether to perform synchronization operations. If the refreshAndPersist mode is used, the engine is always ready to handle persistent synchronization messages from the master server.

Setting Up the Replication

The syncrepl method uses a slave-side replication engine. To set up a syncrepl replication in refreshOnly mode, enable the syncrepl engine on the CDS slave server. Additionally, enable the syncprov overlay feature on the CDS master server.

The following example provides the detailed steps required to set up a syncrepl replication for contents under binddn ‘dc=example, dc=com’ in refreshOnly mode:

To configure the slave server's slapd.conf file, add the following contents:

database bdb
...
index entryCSN,entryUUID eq
syncrepl rid=1 provider=ldap://master_side_IP binddn=“dc=example,dc=com” 
bindmethod=simple credentials=secret searchbase=“dc=example,dc=com” 

type=refreshOnly interval=00:00:02:00

For more information, see the slapd.conf(5) manpage.

To enable the syncprov “overlay” feature on the master server, use the following configuration in the master server's slapd.conf file:
moduleload syncprov.la ... database bdb ... index entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
For more information, see the slapo-syncprov(5)manpage.
After setting the configurations, restart the master-side server and then restart the slave-side servers.
At this point, the binddn directory contents of the slave server should be the same as the master server. Adding or removing the corresponding contents on the master server leads to the same results on the slave server after the ‘interval’ period.

Monitoring the Replication Status

There is no formal tool to monitor the syncrepl replication status. However, there are two methods you can use to verify that the replication is complete.

Use the slapd debugging level to view slapd debug information.
Use the ldapsearch command and compare the contextCSN of the master and slave servers. The syncrepl method stamps each write operation with a Change Sequence Number (CSN). Each CDS server maintains a contextCSN attribute which records the largest CSN stored. You can determine whether the replication is complete by comparing the contextCSN for both the master and slave servers.

Using the slapd Debugging Level

Start the slave-side slapd process with debugging enabled, for this example set the debug level to 'syncrepl consumer processing ' (level 16384), by entering the following command:

# /etc/init.d/cdssserver start –d 16384

Once a replication occurs, the message do_syncrep2: displays.

If a replication finishes, the following messages display:

syncrepl_entry: 'dn_of_the_last_entry' syncrepl_entry: be_add(0)




	NOTE: For a list of the different levels of debugging messages, see “Debugging the CDS Server”.

Using the contextCSN Method for Comparison

List the contextCSN by entering the following commands:

For the following commands:

# ldapsearch –x –D dc=example,dc=com –w secret –H \

ldap://slave_side_IP –b dc=example,dc=com –s base contextCSN

# ldapsearch –x –D dc=example,dc=com –w secret –H \

ldap://master_side_IP –b dc=example,dc=com –s base contextCSN

Compare the contextCSN tags. If they are the same, the replication is finished, otherwise the replication is not finished.




	NOTE: The contextCSN on the slave server only synchronizes with the master server. It does not change during the initial replication process, which happens right after the CDS slave server is started, because the contextCSN on the master server is not changing at this time.

Scaling CDS Using a Load Balancer

Replication can scale out CDS with the help of a load balancer, such as the Linux Virtual Server (LVS). LVS defines the network packet stream that goes through a certain network port as a service. It simply intercepts these packets and distributes them to different servers. For the installation and configuration of LVS, see the LVS documentation at:

http://www.linuxvirtualserver.org/Documents.html

Figure 1illustrates a typical CDS scale-out configuration. In this case, the LDAP clients send query requirements through the client network to the application server, and then LVS receives the read requests and sends them to the CDS slaves with the “round robin” assigned policy.