New Master/Slave configuration of openldap-2.4)

Master/Slave configuration for openldap-2.4 version

PS: I recently worked on LDAP. When I was configuring the master and slave nodes, I found that the 2.4.23 version was installed without the slurpd daemon enabling command. Then I searched the internet and improved the master-slave mode and master-master mode after version 2.4. Then, read the official documents and record the records. Of course, this article has a serious understanding, So if you make an error, please forgive me! Can point out the best.

Disadvantages of synchronous replication before OpenLDAP v2.3:

The slurpd daemon operates in Push mode: the master server pushes changed data to the slave server (unreliable)

Extremely sensitive to the order of records in replog

Synchronization is easy to lose. In this case, manual intervention is required to re-Synchronize the slave server database from the main directory.

If a slave server is down for a long time, the replog may become too large to be processed by slurpd.

It only works in the push mode (you can also set it to the PULL mode, but this is similar to connecting the data on the master to the slave quickly)

You need to stop and restart the master server to increase the number of slave servers.

Only single master Server replication is supported (one master-to-multiple-slave)

Synchronization After OpenLDAP v2.4:

PS: The biggest function of the new version is to achieve two-way replication, that is, dual-master, multi-master mode, no matter which master is down, will not affect the use.

The new Master/Slave configuration is available in five ways. Here, the most basic and simple Master/Slave configuration of syncrepl and the N-way multi-master (Multi-master) mode of mirror mode are described.

Syncrepl	This method is used by the slave server to synchronize master user data in PULL mode. Disadvantages of this method: When you modify an attribute value in an entry (or a massive 10-Level Attribute Value of one attribute value), it is not simply synchronized to these attributes, instead, the modified entries are synchronously updated.
Delta-syncrepl	Compared with the previous one, the following features are available: Log-based synchronization: Each time you change one record on the master node, one log will be generated, and the slave will modify the log through your master, which overcomes the disadvantages of the previous one.
N-way multi-Master	Synchronize LDAP information in multiple master Modes
Invalid Mode	This means that the server pushes information to each other to synchronize user data. Worker mode only supports two master nodes (two master nodes can + n slave nodes). However, if you have to add three or four master nodes, the rest can only obtain data from the first two masters, but cannot push the data. You can also use this method if you have similar requirements. (For example, you can use it if your enterprise has more scattered nodes and does not want to have the modification function)
Syncrepl proxy	Proxy synchronization. This means that the master is hidden, and the master user data is synchronized from the master host by means of syncrepl on the proxy. When the current host changes, the LDAP of the proxy host updates data to the subordinate slave LDAP server. Slave LDAP only has read permission on the proxy LDAP server.

Openldap v2.4 synchronization function example:

①. Syncrepl

Because syncrepl is the PULL mode (to pull data to the master), you can configure the slapd. conf file on the slave side in the configuration file. There are two initialization operations: 1. Through the configuration file, when the syncrepl engine is enabled, data is pulled to the master; 2. Data is backed up from the master server and copied to the slave. When initializing backup data, you do not have to worry about data aging because syncrepl automatically performs verification and then modifies and synchronizes the data. (When copying a large-scale "record", we recommend that you initialize it from the backup)

1. Configure master LDAP

As mentioned above, there are five synchronization modes, so we need to first define one. In addition, we need to define contextcsn (which should be a synchronization status comparison) and session log. The following is an example:

database bdbsuffix dc=Example,dc=comrootdn dc=Example,dc=comdirectory /var/ldap/dbindex objectclass,entryCSN,entryUUID eqoverlay syncprovsyncprov-checkpoint 100 10         #contextCSNsyncprov-sessionlog 100            #session log

2. Configure the slave LDAP

database hdbsuffix dc=Example,dc=comrootdn dc=Example,dc=comdirectory /var/ldap/dbindex objectclass,entryCSN,entryUUID eqsyncrepl rid=123        provider=ldap://provider.example.com:389        type=refreshOnly        interval=01:00:00:00        searchbase="dc=example,dc=com"        filter="(objectClass=organizationalPerson)"        scope=sub        attrs="cn,sn,ou,telephoneNumber,title,l"        schemachecking=off        bindmethod=simple        binddn="cn=syncuser,dc=example,dc=com"        credentials=secret

In this example, slave will connectLDAP: // provider.example.com: 389For synchronization, he will useSimpleAuthentication (passwd secret) to verify and bindCN = syncuser, Dc = example, Dc = com.

PS: note that slave uses the read/write permission to synchronize to the master!

The master server Load balancer service does not need to be restarted. Contextcsn is automatically generated as needed. It may be initially included in the ldif file, generated when it becomes, or generated when the slave first connects to the master for synchronization. If the ldif file is loaded without contextcsn,-W should be used with slapadd to generate it. This will make slave's first Synchronous Response faster.

This cookie is a comma-separated list of name = values. Currently, the cookie field arecsn of syncrepl is <CSN> andrid = <RID>. <CSN> indicates the current synchronization status of slave. <RID> identify user copies on the customer server locally. It is used to match the cookie with the identifier defined in slapd. conf. The <RID> must have no more than three decimal places. The cookie in the command line overwrites the cookie stored in the user's copy database synchronization.

② Delta-syncrepl

1. Configure master LDAP

Modify the Server Load balancer. conf of the master node: (copy and paste the master node and add the configuration accordingly)

# Give the replica DN unlimited read access. This ACL needs to be# merged with other ACL statements, and/or moved within the scope# of a database. The "by * break" portion causes evaluation of# subsequent rules. See slapd.access(5) for details.access to *by dn.base="cn=replicator,dc=symas,dc=com" readby * break# Set the module path locationmodulepath /opt/symas/lib/openldap# Load the hdb backendmoduleload back_hdb.la# Load the accesslog overlaymoduleload accesslog.la#Load the syncprov overlaymoduleload syncprov.la# Accesslog database definitionsdatabase hdbsuffix cn=accesslogdirectory /db/accesslogrootdn cn=accesslogindex default eqindex entryCSN,objectClass,reqEnd,reqResult,reqStartoverlay syncprovsyncprov-nopresent TRUEsyncprov-reloadhint TRUE# Let the replica DN have limitless searcheslimits dn.exact="cn=replicator,dc=symas,dc=com" time.soft=unlimited time.hard=unlimited size.soft# Primary database definitionsdatabase hdbsuffix "dc=symas,dc=com"rootdn "cn=manager,dc=symas,dc=com"## Whatever other configuration options are desired# syncprov specific indexingindex entryCSN eqindex entryUUID eq# syncrepl Provider for primary dboverlay syncprovsyncprov-checkpoint 1000 60# accesslog overlay definitions for primary dboverlay accessloglogdb cn=accessloglogops writeslogsuccess TRUE# scan the accesslog DB every day, and purge entries older than 7 dayslogpurge 07+00:00 01+00:00# Let the replica DN have limitless searcheslimits dn.exact="cn=replicator,dc=symas,dc=com" time.soft=unlimited time.hard=unlimited site

2. Slave Configuration

# Replica database configurationdatabase hdbsuffix "dc=symas,dc=com"rootdn "cn=manager,dc=symas,dc=com"## Whatever other configuration bits for the replica, like indexing## that you want# syncrepl specific indicesindex entryUUID eq# syncrepl directivessyncrepl rid=0        provider=ldap://ldapmaster.symas.com:389        bindmethod=simple        binddn="cn=replicator,dc=symas,dc=com"        credentials=secret        searchbase="dc=symas,dc=com"        logbase="cn=accesslog"        logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"        schemachecking=on        type=refreshAndPersist        retry="60 +"        syncdata=accesslog        # Refer updates to the masterupdateref ldap://ldapmaster.symas.com

The above configuration assumes that you have defined a replication identifier (bound to the master) in your database. In addition, all databases (primary, replica, And the accesslog storage database) you should also adjust it to meet your needs (db_config file ).

③ N-way multi-Master

In the following example, we will use three master nodes.

Configure the database information as follows:

dn: cn=configobjectClass: olcGlobalcn: configolcServerID: 1dn: olcDatabase={0}config,cn=configobjectClass: olcDatabaseConfigolcDatabase: {0}configolcRootPW: secret

Differences between 2nd and 3 ldapserversOlcserverid:

dn: cn=configobjectClass: olcGlobalcn: configolcServerID: 2dn: olcDatabase={0}config,cn=configobjectClass: olcDatabaseConfigolcDatabase: {0}configolcRootPW: secret

The following configuration sets syncrepl (all three masters need to be configured for mutual synchronization)

dn: cn=module,cn=configobjectClass: olcModuleListcn: moduleolcModulePath: /usr/local/libexec/openldapolcModuleLoad: syncprov.la

Now we start the first master node (replace $ url1/$ url2/* in the following configuration with the actual LDAP URLs)

dn: cn=configchangetype: modifyreplace: olcServerIDolcServerID: 1 $URI1olcServerID: 2 $URI2olcServerID: 3 $URI3dn: olcOverlay=syncprov,olcDatabase={0}config,cn=configchangetype: addobjectClass: olcOverlayConfigobjectClass: olcSyncProvConfigolcOverlay: syncprovdn: olcDatabase={0}config,cn=configchangetype: modifyadd: olcSyncReplolcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple    credentials=secret searchbase="cn=config" type=refreshAndPersist    retry="5 5 300 5" timeout=1olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple    credentials=secret searchbase="cn=config" type=refreshAndPersist    retry="5 5 300 5" timeout=1olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" bindmethod=simple    credentials=secret searchbase="cn=config" type=refreshAndPersist    retry="5 5 300 5" timeout=1-add: olcMirrorModeolcMirrorMode: TRUE

Now that the master is started and the first and second consumption are configured in ldif, it will copyCN = config. You now have n-way-multi-host database configuration.

We need to copy the data, not just the configuration information, so we add it to the host (allConsumption queue/materWill Synchronize this configuration ). In addition, you also need to replace all $ {} for your appropriate environment configuration information.

dn: olcDatabase={1}$BACKEND,cn=configobjectClass: olcDatabaseConfigobjectClass: olc${BACKEND}ConfigolcDatabase: {1}$BACKENDolcSuffix: $BASEDNolcDbDirectory: ./dbolcRootDN: $MANAGERDNolcRootPW: $PASSWDolcLimits: dn.exact="$MANAGERDN" time.soft=unlimited time.hard=unlimited size.soft=unlimitolcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple    credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly    interval=00:00:00:10 retry="5 5 300 5" timeout=1olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple    credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly    interval=00:00:00:10 retry="5 5 300 5" timeout=1olcSyncRepl: rid=006 provider=$URI3 binddn="$MANAGERDN" bindmethod=simple    credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly    interval=00:00:00:10 retry="5 5 300 5" timeout=1olcMirrorMode: TRUEdn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=configchangetype: addobjectClass: olcOverlayConfigobjectClass: olcSyncProvConfigolcOverlay: syncprov

Note: All your master clock must be synchronized!

Note: As in slapd-config, URLs configuration (InolcsyncreplThe URL from which the data must be copied. These must beSlapdThe port listening address is the same. Otherwise, slapd may try to copy from itself, resulting in a loop.

④ Merge Mode

The first step is to configureSyncrepl

Worker mode Node 1:

# Global sectionserverID 1# database section# syncrepl directivesyncrepl rid=001        provider=ldap://ldap-sid2.example.com        bindmethod=simple        binddn="cn=mirrormode,dc=example,dc=com"        credentials=mirrormode        searchbase="dc=example,dc=com"        schemachecking=on        type=refreshAndPersist        retry="60 +"        mirrormode on

Worker mode Node 2:

# Global sectionserverID 2# database section# syncrepl directivesyncrepl rid=001        provider=ldap://ldap-sid1.example.com        bindmethod=simple        binddn="cn=mirrormode,dc=example,dc=com"        credentials=mirrormode        searchbase="dc=example,dc=com"        schemachecking=on        type=refreshAndPersist        retry="60 +"        mirrormode on

The principle is very simple. Each worker mode node has the same settings. The difference is thatServeridThey are unique. Each consumer directs to another server.

Failover configuration

Usually there are two options: 1. Hardware proxy/Server Load balancer or dedicated proxy software; 2. Use the slave LDAP proxy as the syncrepl provider.

650) This. width = 650; "src =" http://s3.51cto.com/wyfs02/M00/41/04/wKiom1PQbRDDbM0BAAEzaaQiqOI802.jpg "Title =" qq 40724101320.jpg "alt =" wkiom1pqbrddbm0baaezaaqiqoi802.jpg "/>

The picture is down. I don't know why. I have time to change the picture to a link.

Common consumer Configuration

The slave configuration is the same. It can be configured as a regularSyncreplMode, which can also beDelta-syncreplMode. (Example above)

Advantages

Now, you will have a directory architecture that provides consistency assurance for all single-master replication and high availability for multi-host replication.

⑤. Syncrepl proxy

(Due to word limit, this one will be written again)

Notice: (2 middle Mode)

Push-based

Pull-based

This article is from the blog of "bean bag", please be sure to keep this source http://407711169.blog.51cto.com/6616996/1529506