7.2. 常见复制场景

在最基本的复制配置中，供应商服务器会将副本直接复制到一个或多个消费者服务器。在这个配置中，所有目录修改都会在供应商服务器上的读写副本中进行，消费者服务器会包含数据的只读副本。

供应商服务器必须对存储在消费者服务器上的读写副本执行所有修改。下面展示了这一点。

供应商服务器可以将读写副本复制到多个消费者服务器。单一供应商服务器可以管理的使用者服务器总数取决于网络的速度以及每天修改的条目总数。然而，供应商服务器能够维护多个消费者服务器。

在 多层次复制 环境中，同一信息的主副本可以存在于多个服务器上。这意味着可在不同的位置同时更新数据。每台服务器上发生的更改将复制到其他服务器上。这意味着每个服务器作为供应商和消费者的功能。

当在多个服务器上修改相同数据时，会有一个冲突解析程序来确定要保留哪些更改。目录服务器将有效的更改视为最新的更改。

多个服务器可以有相同数据的主副本，但在单个复制协议范围内，只有一个供应商服务器和一个消费者。因此，要在两个供应商服务器间创建一个用于同一数据负责的多层环境，请创建多个复制协议。

在 图 7.2 “简化多层次复制配置” 中，供应商 A 和 provider B 各自包含同一数据的读写副本。

图 7.3 “在简单多Supplier 环境中复制流量” 演示了复制流量，其中包含两个供应商（图示中的读写副本）和两个消费者（图示中只读副本）。消费者可由两个供应商更新。供应商服务器可确保更改不会冲突。

目录服务器中的复制可以支持 20 个供应商，它们共享对相同数据的责任。使用许多供应商需要创建一系列复制协议。（也请记住，在多层次复制中，每个供应商都可以在不同拓扑中进行配置 - 即有 20 个不同的目录树甚至模式差异。有很多变量对拓扑选择直接影响。）

在多层次复制中，供应商可以将更新发送到所有其他供应商，或向其他供应商的一些子集发送更新。向所有其他供应商发送更新意味着更快地对更改进行请求，整个方案的整体方案具有更好的故障容错性。然而，它还增加了配置供应商的复杂性，并带来高网络需求和高服务器需求。向供应商子集发送更新要更简单地配置和减少网络和服务器负载，但数据在存在多个服务器故障时可能会丢失。

图 7.4 “多层复制配置 A” 演示了一个完全连接的网格拓扑，其中四个供应商服务器向其他三个供应商服务器提供数据（也作为消费者运作）。四家供应商服务器之间都存在一系列调整复制协议。

图 7.5 “配置 B” 演示了一个拓扑，即每个供应商服务器将数据发送到另外两个供应商服务器（也可以作为消费者使用）。与 图 7.4 “多层复制配置 A” 中的拓扑所示，只有 8 个复制协议存在于四个供应商服务器间，与 中拓扑显示的有十二协议。此拓扑很有用，有可能同时出现两个或更多个服务器失败。

这两示例就是简化的多层次方案。由于红帽目录服务器可以在单个多层次环境中拥有 20 多个供应商和数量无限数量的 hub 供应商，因此复制拓扑可能会变得更为复杂。例如： 图 7.4 “多层复制配置 A” 有 12 个复制协议（我们的供应商各自有三个协议）。如果有 20 个供应商，则有 380 个复制协议（每个有 19 个协议的 20 个服务器）。

在规划多supplier 复制时，请考虑：

在级联复制方案中，hub 供应商 从供应商服务器接收更新并在消费者服务器上回放这些更新。hub 供应商是一个混合的；它包含了只读副本，如典型的消费者服务器，它也像典型的供应商服务器一样维护一个更改日志。

当供应商从原始供应商接收供应商数据时，中心供应商会转发供应商数据。同样，当 hub 供应商从目录客户端收到更新请求时，它会引用供应商服务器的客户端。

如果组织内不同位置之间的某些网络连接比其他位置相比，级联复制非常有用。例如，Example Corp. 将其目录数据的主副本保存在 Minneapolis 中，以及 New York 和 Chicago 中的消费者服务器。Minneapolis 和 New York 之间的网络连接非常好，但 Minneapolis 和 Chicago 之间的连接不佳。由于 New York 和 Chicago 之间的网络是公平的，示例管理员使用 cascading replication 将目录数据从 Minneapolis 移到 New York to Chicago。

图 7.7 “复制流量和更改日志” 从不同的视角演示了相同的场景，它显示了如何在每台服务器上配置副本（读写或只读），以及哪些服务器维护更改日志。

可以合并任何复制场景，以满足网络和目录环境的需求。种常见组合是使用具有级联配置的多层次配置。