6.2. 常见复制场景
您可以使用以下常见场景来构建最适合您的需要的复制拓扑：
6.2.1. 单层复制
在单层次复制场景中，供应商服务器维护目录数据的主副本（读写副本），并将此数据的更新发送到一个或多个消费者服务器。所有目录修改都会在供应商服务器上的读写副本中进行，消费者服务器包含数据的只读副本。
供应商服务器维护一个 changelog，记录对供应商副本所做的任何更改。
下图显示了单层复制场景：
图 6.1. 单层复制
单一供应商服务器可以管理的使用者服务器总数取决于网络的速度以及每天修改的条目总数。
6.2.2. multi-supplier 复制
在多层次复制环境中，同一信息的主要副本可以存在于多个服务器上，并且可以在不同的位置同时更新目录数据。每台服务器上发生的更改复制到其他服务器上，这意味着每个服务器作为供应商和消费者的功能。
当在多个服务器上修改同一数据时，会发生复制冲突。使用冲突解析过程，目录服务器使用最新的更改作为有效的更改。
在多层次环境中，每个供应商都需要具有指向消费者和其他供应商的复制协议。例如，您使用两个供应商配置复制，供应商 A 和 Vendor B，以及两个消费者，Consumer C 和 Consumer D。另外，您决定一个供应商只更新一个消费者。在 Vendor A 上，您可以创建一个指向 供应商 B 和 Consumer C 的复制协议。在 Vendor B 上，您可以创建一个指向 供应商 A 和 Consumer D 的复制协议。下图演示了复制协议：
图 6.2. 使用两个供应商进行多层次复制
Red Hat Directory Server 在任何复制环境中支持最多 20 个供应商服务器，以及无限数量的 hub 和消费者服务器。
使用许多供应商需要创建一系列复制协议。此外，每个供应商都可以在不同的拓扑中配置，这意味着您的目录服务器环境可以有 20 个不同的目录树甚至模式差异。许多其他变量可能会对拓扑选择进行直接影响。
供应商可以将更新发送到所有其他供应商，或向供应商的一些子集发送更新。当更新发送到所有供应商时，更改会更快地传播，整个场景具有更好的容错能力。但是，它增加了供应商配置的复杂性，并带来高网络和高服务器需求。向供应商子集发送更新要更简单地配置和减少网络和服务器负载，但在出现多个服务器故障时会增加数据丢失的风险。
完全连接的网格拓扑
下图显示了一个完全连接的网格拓扑，其中四个供应商服务器将数据复制到所有其他供应商服务器。总之，在四个供应商服务器之间存在 Telve 复制协议，因为一个复制协议只描述了一个供应商和一个消费者之间的关系。
如果您有 20 个供应商，则需要在总计创建 380 个复制协议（每个有 19 个协议的 20 个供应商）。
如果两个或更多个服务器同时失败的可能性比较小或连接，请考虑使用部分连接的拓扑。
部分连接的拓扑
下图显示了每个供应商服务器将数据复制到两个供应商服务器的拓扑。与上例拓扑相比，只有 8 个复制协议存在于四个供应商服务器之间。
6.2.3. 级联复制
在级联复制场景中，hub 服务器从供应商服务器接收更新，并将这些更新发送到消费者服务器。hub 服务器是一个混合的，因为它包含只读副本，如典型的消费者服务器，它也像典型的供应商服务器一样维护一个更改日志。
Hub 服务器将供应商数据转发到消费者，并引用从目录客户端更新到供应商的请求。
下图显示了级联复制场景：
图 6.3. 级联复制场景
下图显示了如何在每台服务器上配置副本（读写或只读），以及哪些服务器维护更改日志。
图 6.4. 在级联复制中复制流量和更改日志
在以下情况下级联复制很有用：
- 平衡繁重流量负载。由于复制拓扑中的供应商管理所有更新流量，因此可能会使它们负载过重，从而支持用户复制流量。您可以将复制流量重定向到可服务复制到大量消费者的 hub。
- 通过在地理位置分散的环境中使用本地 hub 供应商来减少连接成本。
- 以提高目录服务的性能。如果您将所有读取操作定向到消费者，并将所有更新操作都定向到供应商，您可以从 hub 服务器中删除所有索引（系统索引除外）。这将显著提高供应商和 hub 服务器之间的复制速度。
6.2.4. 混合场景
可以合并任何复制场景，以满足网络和目录环境的需求。一个常见的组合是使用带有级联配置的多层次配置。
下图显示了混合场景的示例拓扑：
图 6.5. 合并多层次和级联复制
