LDAP复制方式比较.docVIP

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进程会周期性地唤醒，并检查主服务器上的日志文件，从而确定是否有任何更新。这些更新然后会传播到从服务器上。读请求可以由任何一个服务器进行解 析，而更新请求则只能由主服务器进行解析。客户机需要负责在推荐地址上重试更新操作。SSlurpd配置： 主服务器上 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模式 客户端消费者服务器配置 suffix?“ou people,dc example,dc com?” rootdn “