前言
本章提供了关于配置LDAP系统进行复制(replication)、引用(referral)和别名(alias)的信息。
复制(replication)是一种操作特性,通过配置选项来实现。而引用(referral)可以是通用的操作特性,也可以在DIT内通过使用引用(referral object class)对象类显式定义。LDAP服务器是否遵循引用(称为链结)或者返回引用,在服务器内部进行配置。此外,LDAP浏览器通常可以配置为自动遵循引用,或者显示引用条目以进行编辑。
将别名(alias)包含在本节中没什么好理由,只是因为它们展示了类似引用的行为——可以改变DIT的严格层次结构,通过造成“跳转”到用户定义的替代(或别名)条目,这可能存在于DIT中一个看似不相关的分支中。从简单的角度来看,引用(referral)可以视为一个LDAP服务器间的跳转,因为它的引用使用了LDAP URI;别名可以看作是一个LDAP服务器内的跳转,因为它的引用只使用DN。

1.复制和引用概述

LDAP(和X.500)的一个更强大的方面在于,标准本身内在地具有在目录的一部分保持责任的同时,继续将目录视为一个一致和连贯的实体的能力。因此,一个公司目录DIT可以创建一个特定部门目录部分的责任的委托(在LDAP术语中是一个“引用”)到该部门的LDAP服务器。被委托的DIT被认为是从其被引用的DIT“从属”的。并且从其引用的DIT被认为是“上级”。在这方面,LDAP委托几乎完全反映了DNS委托,对于熟悉该概念的人来说。
与DNS系统不同,标准中没有选项可以告诉LDAP服务器遵循(解析)引用(在各种文档中有一个引用的RFC草案)——留给LDAP客户端直接联系新的服务器使用返回的引用。同样,因为标准没有定义LDAP数据组织,所以LDAP服务器遵循(解析)引用和一些LDAP服务器使用通常称为“链结”的过程自动执行此功能,这不违反标准。
OpenLDAP采取标准的字面解释,默认不进行“链结”,它总是返回一个引用。但是,OpenLDAP可以通过使用“链结覆盖”来配置提供“链结”。
LDAP的内置复制功能允许一个或多个目录(DIT)的副本从单个主服务器被复制(或复制),因此内在地创建一个弹性结构。OpenLDAP 2.4版引入了提供完整的N向多主配置的能力。
然而,重要的是要强调LDAP与事务数据库之间的区别。 当在启用LDAP的主目录上执行更新时,更新所有从属目录可能需要一些时间(在计算术语方面)—— 主目录和从属目录可能在一段时间内不同步。
在LDAP环境中,DIT同步的临时缺失被视为不重要。 而在事务数据库中,即使是暂时的同步缺失也被视为灾难性的。 这强调了应在LDAP启用的目录与事务数据库中维护的数据的特性差异。
复制(OpenLDAP和ApacheDS)和引用的配置在本章中进一步描述,并在示例中展示。、

2.LDAP 引用

下图显示cn=cheri,ou=uk,o=grommets,dc=example,dc=com为基础DN的搜索请求,该请求在一个基于引用的LDAP系统中,产生了针对LDAP2和LDAP3服务器的一系列引用:

图1.1-1 - 请求生成对LDAP2和LDAP3的引用

注释:

1. 所有的客户端请求都从全局目录LDAP 1开始
2. 在LDAP 1上,对于任何在DN中具有widgets作为RDN的任何数据的请求都将从LDAP1即时满足,例如:
   dn: cn=thingie,o=widget,dc=example,dc=com
3. 在LDAP 1上,对于任何在DN中具有grommets作为RDN的任何数据的请求都将被引用到LDAP2,例如:
   dn: ou=us,o=grommets,dc=example,dc=com
4. 在LDAP 2上,对于任何在DN中具有uk作为RDN的任何数据的请求都将被引用到LDAP3,例如:
   dn: cn=cheri,ou=uk,o=grommets,dc=example,dc=com
5. 如果LDAP服务器被配置为链结(如备选虚线所示跟随引用),那么一个单一的数据响应将被提供给LDAP客户端。链结由LDAP服务器配置和搜索请求中的值控制。有关链结的信息。
6. 图示明确地使用referral对象类进行了链结,OpenLDAP服务器可以被配置为在搜索DN的后缀在服务器维护的任何DIT中不存在时返回一个通用引用。

3.LDAP 复制

复制功能允许LDAP DIT更新被复制到一个或多个LDAP系统,以备份和/或性能的原因。在这方面,值得强调的是,复制操作在DIT级别运行,而不是LDAP服务器级别。因此,在运行多个DIT的单个服务器中,每个DIT可以复制到不同的服务器。复制定期在本指南所说的“复制周期时间”内发生。OpenLDAP 2.3版本引入了一个强大的新复制功能(通称为syncrepl),2.4版本对此进行了进一步增强,以提供多主功能。有两种可能的复制配置和每种配置类型的多个变体。
注意: 2.4版本之前的OpenLDAP提供了一个使用独立守护进程slurpd的复制功能。该功能现在只有历史意义,其描述仅为仍在支持遗留的(2.3之前)OpenLDAP系统的人而保留。否则不再提及slurpd。

1. 主-从: 在主-从配置中,一个单独的(主)DIT能够更新,这些更新被复制或复制到一个或多个指定的运行从DIT的服务器。从服务器运行主DIT的只读副本。只读用户可以访问包含从DIT的服务器,但需要更新目录的用户只能通过访问包含主DIT的服务器来执行更新。为了进一步困惑其可怜的用户,OpenLDAP在syncrepl复制功能中引入了“提供者”和“使用者”这些术语。提供者可以看作是复制服务的源(提供者)(普通人称之为主),使用者是复制服务的目标(普通人称之为从)。主-从(或提供者-使用者)配置有两个明显的缺点:
   多个位置：如果所有或大多数客户端都需要更新DIT,那么它们要么必须访问一个服务器(运行从DIT)进行正常读访问,并访问另一个服务器(运行主DIT)进行更新。或者,客户端始终可以访问运行主DIT的服务器。在后一种情况下,复制仅提供备份功能。
   弹性：由于只有一个包含主DIT的服务器,它代表着单点故障。
2. 多主: 在多主配置中,一个或多个运行主DIT的服务器可以更新,所产生的更新被传播到对等主服务器。
   从历史上看,OpenLDAP不支持多主操作,但在2.4版本中引入了多主功能。在这种情况下,可能值得指出OpenLDAP确定的所有多主配置的两个特定变体中的通用“更新争用”问题:
   a. 值争用 如果两个属性更新是同时执行的(在复制周期内),且使用不同的值,则根据属性类型(SINGLE或MULTI-VALUED),所得到的条目可能处于不正确或不可用状态。
   b. 删除争用 如果一个用户在另一个用户删除原始(父)条目的同时(在复制周期内)添加了一个子条目,那么被删除的条目将重新出现。

图1.1-2显示了几种可能的复制配置。

图1.1-2 - 复制配置

注释:

1. RO = 只读,RW = 读写
2. LDAP1 面向客户端的系统是一个从属的,只读。客户端必须向主发出写入。
3. LDAP2 面向客户端的系统是一个主,它被复制到两个从属。
4. LDAP3是一个多主,客户端可以向任一系统发出读取(搜索)和/或写入(修改)。每个主在这个配置中,又可以有一个或多个从属DIT。

4.OpenLDAP 复制

从OpenLDAP 2.4版本开始,只有一种复制方法,通常称为syncrepl,它是根据消费者(也称为从属)属性(OLC = olcSyncrepl)或指令(slapd.conf = syncrepl)调用复制的。旧版本的OpenLDAP(2.4版本之前)提供了slurpd样式的复制,现在已经完全废弃。

4.1 OpenLDAP syncrepl方式复制(从2.3版本开始)

OpenLDAP 2.3版本引入了对新的LDAP内容同步协议的支持,从2.4版本开始,这已成为唯一支持的复制功能。LDAP内容同步协议由RFC 4533定义,通常以消费者用于启动复制的功能olcSyncrepl/syncrepl的名称泛指。Syncrepl功能提供了经典的主从复制,并且从2.4版本开始允许多主复制。该协议使用“提供者”(而不是主)一词来定义复制更新的来源,使用“消费者”(而不是从)一词来定义更新的目标。
在syncrepl样式复制中,消费者始终启动更新过程。消费者可以配置为定期从提供者那里“拉取”更新(refreshOnly),或者它可以请求提供者“推送”更新(refreshAndPersist)。在所有复制情况下,为了明确引用条目,服务器必须为DIT中的每个条目维护一个通用唯一编号(entryUUID)。同步过程如图4.1-1(refreshOnly)和4.1-2(refreshAndPersist)所示：

1. 在从服务器上配置 syncrepl,定义主服务器的位置(LDAP URI)。
2. 从服务器主动连接主服务器,请求进行同步。
3. 主服务器收到请求后,首先检查从服务器发送来的上次同步时的 syncCookie,以确定本次同步的起始点。
4. 主服务器进入 present 阶段,发送当前存在的条目数据给从服务器。
   • 对于已改变的条目,发送完整数据用于从服务器更新
   • 对于未改变的条目,发送空数据表示其存在
5. 主服务器进入 delete 阶段,发送已删除的条目数据给从服务器。
6. 从服务器根据收到的 present 和 delete 数据更新自己的数据副本。
7. 同步结束后,主服务器生成新的 syncCookie,包含本次同步的最后更改点,发送给从服务器。
8. 从服务器保存该 syncCookie。在下次同步循环时,将该 syncCookie 发送给主服务器,以此作为同步的起点。
9. 主服务器不需要维护每个从服务器的状态,通过 syncCookie 来定位每个从服务器的同步进度。

4.2 Replication refreshAndPersist (provider Push)

原服务器(1)想要复制一个目录信息树(DIT)(4)(提供者)到从属副本(5)(消费者),需要使用olcSyncrepl(olc)或syncrepl(slapd.conf)(7)进行配置。olcSyncrepl/syncrepl定义了包含DIT(4)主副本的原服务器(3)(提供者)的位置(LDAP URI)。提供者需要使用同步重叠(syncprov overlay)进行配置。

在“刷新并持久化”类型的复制中,消费者(1)会启动一个与提供者(3)的连接(2) - DIT的同步会立即发生,并在这个过程结束时保持连接(使其“持久化”)。之后对提供者(3)的更改(E)会立即传播给消费者(1)。

更多详情:消费者(1)会与提供者(3)打开一个会话(2),并请求“刷新并持久化”同步。任意数量的消费者都可以联系提供者并请求同步服务 - 提供者不需要配置任何关于它的消费者的信息 - 只要任意消费者满足提供者的安全要求,它的同步请求就会被执行。同步请求本质上是一个扩展的LDAP搜索操作,它使用正常的LDAP搜索参数(base DN、搜索范围、搜索过滤器和属性)来定义复制范围 - 因此可以根据搜索条件来复制提供者的全部或部分DIT。

提供者(3)不需要针对每个消费者维护状态信息。相反,提供者会定期发送一个同步cookie(SyncCookie - D) - 这个cookie包含一个更改序列号(contextCSN)- 本质上是一个时间戳,表示发送给该消费者的最后一个更改,可以看作是一个更改或同步检查点。当一个“刷新并持久化”的消费者(1)与提供者(3)打开一个会话(2)时,它们首先必须同步各自的DIT(或DIT片段)的状态。 根据消费者的初始配置,当它首次与提供者(3)打开一个会话(2)时,它可能没有SyncCookie,因此更改的范围是整个DIT(或DIT片段)。 这个过程的一个好处是允许消费者从一个空的复制DIT开始。 当一个消费者(1)后续连接(2)到提供者(3)时,它将具有一个SyncCookie(D)。 对于“刷新并持久化”类型的复制,在提供者、消费者或网络发生故障导致连接终止的情况下,会发生重新连接,否则连接会被永久维护。

在初始同步过程中,DIT的提供者(3)会以两种阶段之一或全部响应。第一种是“present”阶段(B),表示仍在DIT(或DIT片段)中的条目,包括:

1. 对于每个发生了更改的条目(自上次同步后)- 发送完整的条目,包括其DN和UUID(entryUUID)。消费者可以用这个数据可靠地更新其条目。
2. 对于每个未发生更改的条目(自上次同步后)- 发送一个空白条目及其UUID(entryUUID)。
3. 不发送已删除的条目的消息。理论上,在前两个过程结束后,消费者可以删除未被引用的条目。

在删除阶段（ C）:
提供者返回自上次同步后删除的每个条目的DN和UUID(entryUUID)。消费者可以可靠地删除这些条目。
是否需要两个阶段取决于一些额外的技术。
在同步阶段(D)结束时,提供者通常会发送一个SyncCookie(当前的contextCSN)并保持会话。之后对提供者DIT(4)的更新(E)(可能是更改、添加或删除)会被提供者(3)立即发送(E)给消费者

4.3 OpenLDAP syncrepl (N-Way) 多主复制

OpenLDAP 2.4引入了N-Way多主支持。在N-Way多主配置中,任意数量的主服务器可以相互同步。之前已经描述过刷新只读和刷新并持久两种复制功能,这里不再重复。以下注释和配置示例是N-Way多主独有的。
注意:在运行N-Way多主时,必须确保所有的主服务器(提供者)的时钟同步到同一个时间源,例如,它们应该都运行NTP(网络时间协议)。
在N-Way多主中,每个同步服务的提供者也是一个同步服务的消费者,如图所示。

上图显示了一个3路多主(1,2,3)配置。每个主服务器都配置了(5,6,7)作为提供者(使用syncprov叠加层),并作为其他所有主服务器的消费者(使用olcSyncrepl/syncrepl)。每个提供者必须使用olcServerID/ServerID唯一标识。如上所述,每个提供者应该同步到一个共同的时钟源。因此,包含DIT(4)的提供者(1)包含一个配置的syncprov叠加层(提供者叠加层)和两个refreshAndPersist类型的olcSyncrepl/syncrepl定义,针对每个其他提供者(2,3),如蓝色通信链路所示。类似地,其他每个提供者都有一个等效配置 - 单个提供者能力和针对其他两个主服务器(提供者)的refreshAndPersist olcSyncrepl/syncrepl定义。

在这个配置中,假设使用了refreshAndPersist类型的同步(不明白为什么要考虑使用refreshOnly,但这是可能的),那么对任意主服务器的写操作(修改)将会立即传播到所有其他的主服务器(提供者)中,这些主服务器以它们的从属(消费者)角色运行。

2.4版本的N路多主复制目前不支持delta同步。