LDAP复制方式比较.doc

LDAP复制方式比较内容简述：本文比较了LDAP的slurpd复制和syncrepl复制之间的区别。Syncrepl可以使用从服务器端向主服务器LDAP数据库信息目录树全部或局部内容的“拉”式复制。消费方同步前初始目录可以为空，同步后以一定间隔向提供者“轮询”条目变化。正文： OpenLDAP是美国密歇根大学开发的开源LDAP软件。在2.3版本前使用slurpd这种复制方式，slurpd使用LDAP协议和slapd“绑定”在一起。OpenLDAP版本2.3引进了对一种新的LDAP内容同步协议的支持。而且从2.4版本开始这已经成为唯一得到支持的复制性能（slurpd样式现在已经过时了）。LDAP内容同步协议是由RFC 4533定义的，从它控制slapd.conf文件的指令syncrepl就可以知道了。LDAP内容同步复制协议不但提供一流的主从复制而且从2.4版本开始允许多主复制。协议使用术语provider（相当于master）定义复制更新的源服务器，使用术语consumer（相当于slave）来定义一个更新的目的服务器。一 Slurpd复制主服务器上的Slurpd进程会周期性地唤醒，并检查主服务器上的日志文件，从而确定是否有任何更新。这些更新然后会传播到从服务器上。读请求可以由任何一个服务器进行解 析，而更新请求则只能由主服务器进行解析。客户机需要负责在推荐地址上重试更新操作。Slurpd是一种“推”式的复制，同步进程都是由主服务器发起的。Slurpd配置：（1） 主服务器上 replogfile /var/lib/ldap/openldap-master-replog replica uri=ldaps:/master:636 binddn=“cn=replicator,dc=example,dc=com” bindmethod=simple credentials=secret(2) 从服务器上 updatedn “cn=replicator,dc=example,dc=com” updateref ldaps:/master:636从服务器上的updatedn和主服务器上的binddn一定要一致。复制用户不要求在主服务器上有读写权限，但要求在从服务器上有写权限。复制用户可以不在LDAP用户数据库中。实际上master上的slurpd使用从服务器上的replicator来绑定到从服务器的LDAP数据库。主服务器用向一个高于1024的端口向slave的 LDAP端口（普通389，ssl636）发送标准的LDAP修改或添加请求。所以对于slave而言updatedn一定要有写入权限，来自Master的数据请求和来自普通用户的修改请求没有区别。updateref 表示用户对slave的更新操作将交由Master处理，然后再同步回slave。但是不在LDAP数据库中的超级管理员rootdn不受此限。同时，在同步前主辅服务器内容应该完全一样。 我虚机上的截图：主LDAP服务器192.168.10.5复制结束后显示连接状态“keepalive”备份192.168.10.6连接不过状态“keepalive”*如果跨广域网传送数据端口始终打开，也许会有隐患。二 syncrepl复制Syncrepl复制使用LDAP同步复制协议。LDAP同步协议允许一个客户端保存一个同步的DIT部分副本。LDAP同步操作由一组控制和别的扩展LDAP搜索操作的协议内容所定义。更多的信息可以参考互联网草案LDAP同步协议通过定义两个独立的同步操作:refreshOnly和refreshAndPersist既支持客户端轮询也支持服务器监听变化。轮询由refreshOnly操作执行。客户端（消费机）副本在轮询时同步到服务器副本。如同正常的搜索在结束操作时，服务器通过回复“SearchResultDone”完成搜索操作。监听通过“refreshAndPersist”操作来实现。在服务器上不是在返回目前所有匹配搜索标准的条目之后就结束搜索，而是依然持续进行同步搜索。到服务器上后续内容的更新会让增加的条目更新内容被传送到客户端上。在syncrepl模式复制中，无论是“推”还是“拉”总是由消费方来初始更新进程，不象在slurpd模式那里是由master （provider）来初始更新进程。消费者服务器可以配置为从提供者周期性的拉更新材料（refreshOnly）或者请求提供者推送更新（refreshAndPersist）。在所有状态下，为了明白无误的提交一个对象，服务器端必须要为一个DIT中的每一个条目维护一个通用唯一数（entryUUID）。refreshOnly模式-客户（slaver）通过轮询实现拉式复制客户端消费者服务器配置suffix“ou=people,dc=example,dc=com”rootdn “uid=admin,ou=People,dc=example,dc=com”syncrepl provider=ldaps:/master:636type=refreshOnlyinterval=00:00:05:00 -间隔时间5分钟 searchbase=“ou=People,dc=example,dc=com” -向主服务器搜索的范围 scope=sub attrs=“*,+” schemachecking=off bindmethod=simple binddn=“uid=admin,ou=People,dc=example,dc=com” credentials=secret updateref ldaps:/master:636 提供者主服务器配置ACL访问控制表access to attrs=userPasswd,shadowLastChange by anonymous auth by dn=“cn=Manager,dc=example,dc=com” write by dn=”uid=admin,ou=People,dc=example,dc=com” write by self writeaccess to * by dn=“cn=Manager,dc=example,dc=com” write by dn= “uid=admin,ou=People,dc=example,dc=com” read by self write index entryUUID，entryCSN eqoverlay syncprovsync-checkpoint 100 10syncprov-sessionlog 100绑定用户admin一定要在LDAP用户数据库中存在或是主服务器超级管理员（不推荐）并据有对相应复制DIT的“读”权限。和slurpd不同，因为是客户端先发起的所以绑定用户是主服务器上有相应DIT“读”权限的用户。和slurpd相反此时slave的大于1024的高位端口连接主（提供者）的LDAP端口（389或636）。同步后消费者和提供者之间的连接中断，只有当消费者在时间间隔后“轮询”提供者时才会重新由从服务器向主服务器建立连接。提供者并不要求维护每一个消费者的状态信息。而是在一个同步会话结束时，提供者发送一个同步cookie（SyncCookie 11）-这个cookie包含一个变化序列号（contextCSN）。本质上是一个标明上一次发给消费者端的时间戳，这可以看成是一个变化或同步的检查点。当消费者端开始一个会话时，它从提供者处收到的上一个cookie会用来向提供者表明这次同步会话的界限。取决于消费者方是如何启动的，消费者方第一次开始通信时它可能没有一个同步Cookie。因此这个初始同步覆盖提供者DIT上的所有纪录。这个过程的副产品允许复制中消费者方从一个空的DIT开始启动。可以看出syncrepl的refreshOnly复制有三个优点：（1） 从服务器可以在LDAP数据库DIT数为空时启动。（2） 启动从服务器加入复制后不必重启主LDAP服务器（3） 同步后连接中断，有利于在广域网中的安全传输。 refreshAndPersist-syncrepl复制中由提供者实时“推送”变化。配置选项其它不动type改为refreshAndPersist。此时初始启动仍然由消费者端发起，只不过在refreshAndPersist类型的复制状态下，只有在提供方，消费方或者网络中有一个故障时彼此间才会中断联系并进行再连接，否则连接将永久保持下去。我虚机上的截图，两端连接都“keepalive”slapd进程对slapd进程总结：syncrepl