6.3. 定义复制策略
您可以根据您要提供的服务来确定复制策略。以下是您可以实现的常见复制策略：
如果高可用性是主要关注的，请在单一站点上创建一个包含多个目录服务器的数据中心。单层复制提供读取故障切换，而多层次复制则提供 write-failover。
如需了解更多详细信息，请参阅使用复制来实现高可用性。
如果本地可用性是主要关注，请使用复制将数据分布到位于全球本地办事处的目录服务器。您可以在单一位置（如公司总部）维护所有信息的主要副本，或者每个本地站点可以管理与它们相关的部分。
如需了解更多详细信息，请参阅使用复制进行本地可用性。
要平衡目录服务器管理和避免网络拥塞的请求负载，请使用复制配置进行负载平衡。
如需了解更多详细信息，请参阅使用复制进行负载平衡。
如果您将多个用户用于公司的不同位置或部分，或者某些服务器不安全，则使用 部分复制来排除 敏感或很少修改的信息，以在不损害敏感信息的情况下维护数据完整性。
如需了解更多详细信息，请参阅 Fraction al 复制。
如果网络在多个站点和由多层次复制连接的本地数据供应商中扩展了多个目录服务器，请将复制配置用于广域网。
如需了解更多详细信息，请参阅 跨各种网络复制。
要确定复制策略，首先对网络、用户、应用程序及其如何使用目录服务的调查开始。
6.3.1. 执行复制问卷调查
收集网络质量和使用信息，以帮助定义复制策略：
- 连接不同构建或远程站点以及可用带宽的 LAN 和 WAN 的质量。
用户的物理位置、每个站点有多少个用户，以及他们打算如何使用目录服务的使用模式。
管理人工资源数据库或财务信息的网站通常会在目录上造成大量负载，而不是包含将目录用于电话的工程人员。
访问目录的应用程序数量以及 读、搜索 的相对百分比，并将 操作与 写入操作 进行比较。
如果消息传递服务器使用 目录，请找出它处理的每个电子邮件消息所执行的操作数量。使用该目录的其他产品通常是身份验证应用程序或元目录应用程序等产品。对于每个应用程序，确定目录中执行的操作的类型和频率。
- 目录中存储条目的数量和大小。
6.3.2. 复制资源要求
复制需要资源。在定义复制策略时请考虑以下资源要求：
- 磁盘用量
- 在供应商服务器上，目录服务器在每个更新操作后写入更改日志。因此，接收许多更新操作的供应商服务器具有更高的磁盘用量。
- 服务器线程
- 每个复制协议都会创建一个专用的线程，CPU 负载取决于复制吞吐量。
- 文件描述符
- 服务器将一个文件描述符用于更改日志，以及每个复制协议的一个文件描述符。
6.3.3. 管理多层次复制所需的磁盘空间
在多层次拓扑中，供应商维护复制所需的额外日志，包括目录编辑的 changelog、更新条目的状态信息以及已删除条目的 tombstone 条目。由于这些日志文件可能会变得非常大，所以您必须定期清理这些文件，以避免不必要的磁盘空间使用。
在每个服务器上，您可以使用以下属性在复制环境中配置复制日志维护：
-
nsslapd-changelogmaxage属性设置 changelog 中条目的最长期限。当条目早于最长期限值后，Directory 服务器会删除该条目。设置条目的最长期限可防止更改日志无限期增长。 -
nsslapd-changelogmaxentries属性设置 changelog 可以包含的最大条目数。请注意，nsslapd-changelogmaxentries值必须足够大，以包含一组完整的目录信息。否则，多层次复制可能会出现问题。 -
nsDS5ReplicaPurgeDelay设置更改日志中 tombstone (deleted)条目和状态信息的最长期限。当 tombstone 或 state 信息条目早于该年龄后，Directory 服务器会删除该条目。nsDS5ReplicaPurgeDelay值只适用于 tombstone 和状态信息条目，而nsslapd-changelogmaxage适用于 changelog 中的每个条目，包括目录修改。 -
nsDS5ReplicaTombstonePurgeInterval属性设置服务器运行清除操作的频率，以清理更改日志的 tombstone 和 state 条目。确保最长期限超过复制更新调度的最长期限。否则，在更新副本时可能会出现多层次复制问题。
6.3.4. 使用复制来实现高可用性
在单一服务器出现故障时，使用复制来防止目录不可用。至少，将本地目录树复制到至少一个备份服务器。您为容错复制的频率取决于您的要求。但是，根据目录所使用的硬件和网络的质量将此决策为基础。不可靠的硬件需要更多备份服务器。
不要将复制用作常规数据备份策略的替代，因为复制和备份具有不同的目的。有关备份目录数据的详情，请参考 备份和恢复红帽目录服务器。
您可以选择以下策略来防止目录不可用：
- 要保证所有目录客户端的写入故障转移，请使用 多层次复制。
- 要保证 read-failover，请使用 single-supplier 复制。
LDAP 客户端应用程序通常配置为仅搜索一个 LDAP 服务器。如果您没有自定义客户端应用程序通过位于不同 DNS 主机名的 LDAP 服务器轮转，则您只能配置 LDAP 客户端应用程序以查看目录服务器的单一 DNS 主机名。因此，您可能需要使用 DNS 循环或网络排序来为备份目录服务器提供故障切换。
6.3.5. 使用复制进行本地可用性
根据网络的质量以及您的数据是关键任务，您可能需要将复制用于本地可用性。
将复制用于本地可用性，理由如下：
您需要一个本地的数据主副本。
大型的跨国企业可能需要仅维护某个国家/地区的员工感兴趣的目录信息。此外，拥有本地数据主副本对于任何企业而言对于在部门或组织级别上控制数据的任何企业非常重要。
您有不可靠或间歇性可用的网络连接。
国际网络具有不可靠的 WAN，导致网络连接不稳定。
您有定期的、会影响目录服务器性能的网络负载。
具有老化网络的企业可能会在正常工作时间内遇到大量网络负载。
您要减少供应商上的网络负载和工作负载。
即使网络可靠且可用，您可能想降低网络成本。
6.3.6. 使用复制进行负载均衡
复制目录数据的一个主要原因是平衡网络的工作负载，并提高目录性能。
因为目录条目的大小通常是 1 KB，每个目录搜索都会在您的网络负载中添加大约 1 KB。如果您的目录用户每天执行十个目录搜索，则每个目录用户大约需要 10 KB 的网络负载。如果您有一个缓慢、大量加载或不可靠的 WAN，您可能需要将目录树复制到本地服务器。
但是，确定本地可用数据是否值得复制导致的网络负载增加的成本。如果您将整个目录树复制到远程站点，您可能会在网络上增加更大的负载，与用户搜索中产生的流量进行比较。如果您的目录更改频繁，但当远程站点只有几个用户每天执行一些目录搜索时，这尤其如此。
下表将复制目录的负载影响与 100万个条目（每天 100,000 个条目）进行了比较，以及每天执行 10 个员工的小远程站点的负载影响。
| 加载类型 | access/day | 平均条目大小 | Load |
|---|---|---|---|
| 复制 | 100,000 | 1KB | 100MB/day |
| 远程搜索 | 1,000 | 1KB | 1MB/day |
在不过载网络的情况下将数据提供给本地站点之间有妥协，就是使用调度复制。有关数据一致性和复制计划的更多信息，请参阅 数据一致性。
6.3.6.1. 网络负载均衡示例
这个示例描述了在 New York (NY)和 Los Angeles (LA)和 Los Angeles (LA)设有办事处的企业，每个办公室管理单独的子树。
下图显示了企业如何管理子树：
图 6.6. 企业 NY 和 LA 子树
每个办公室都包含一个高速网络，但两个城市之间的连接是不可靠的。要平衡网络负载，请使用以下策略：
为每个办公室选择一个服务器作为本地管理数据的供应商服务器。
将本地管理的数据从该供应商复制到远程办公室中的相应供应商服务器。当您在每个位置中有主要数据副本时，用户不会在不可靠的连接上执行更新和搜索操作。因此，性能会被优化。
- 将每个供应商服务器上的目录树（包括从远程办公室提供的数据）复制到至少一个本地目录服务器，以确保目录数据的可用性。
在每个位置配置级联复制，并增加用于搜索本地数据的消费者数量，以提供进一步的负载平衡。
NY 办公室生成比 LA 特定搜索更具体的搜索。该示例显示了带有三个 NY 数据消费者和一个 LA 消费者的 NY 办事处。LA LA 办事处有 3 个 LA 数据消费者和一个 NY 数据消费者。
图 6.7. 企业负载平衡示例
6.3.6.2. 提高性能的负载平衡示例
这个示例描述了具有以下特征的企业：
- 该目录包括支持 1,000,000 个用户的 1,500,000 个条目。
- 每个用户每天都执行 10 个目录搜索。
- 消息传递服务器每天处理 25,000,000 个邮件，并且执行五个目录搜索每个邮件。
- 用户分布到四个时区。
这相当于总计每天的 135,000,000 个目录搜索：
1,000,000 个用户 x 10 搜索 = 每天 10,000,000 名用户搜索
25,000,000 邮件 x 5 搜索 = 每天 125,000,000 邮件搜索
10,000,000 + 125,000,000 = 135,000,000 个每天搜索
随着营业日的 8 小时工作日和用户分布到四个时区，在四个时区内，峰值使用量延长至 12 小时。因此，目录服务器必须在 12 小时内支持 135,000,000 目录搜索。此等于为 3,125 搜索每秒搜索(135,000,000 /(60*60*12))。
如果运行 Directory 服务器的硬件支持每秒读取 500 个，则必须使用至少 6 个或 7 个目录服务器来支持这个负载。对于具有一百万目录用户的企业，为本地可用性添加更多目录服务器。
在这种情况下，您可以使用以下复制策略：
将两个目录服务器放在多层次配置中，以一个城市处理所有写入流量。
此配置假设您想对所有目录数据进行单点控制。
使用供应商服务器复制到一个或多个 hub。
点消费者的 读取、搜索 和比较 请求，使供应商只能处理 写入请求。有关 hub 的更多信息，请参阅 Cascading-replication。
使用 hub 复制到整个企业的本地站点。
复制到本地站点有助于平衡服务器和网络上的负载，并确保目录数据的高可用性。
在每个站点，至少复制一次以确保高可用性，至少用于 读取操作。
使用 DNS sort 以确保本地用户始终找到他们可以用于目录搜索的本地目录服务器。
6.3.6.3. 小站点的复制策略示例
示例企业具有以下特征：
- 整个企业包含在单一构建中。
- 构建速度非常快（每秒100 Mb 每秒）和轻量级使用网络。
- 网络非常稳定，服务器硬件和操作系统平台是可靠的。
- 单个服务器可以轻松处理负载。
在这种情况下，您需要至少复制一次，以便在关闭主服务器进行维护或硬件升级时来确保可用性。另外，设置一个 DNS 循环，以便在其中一个目录服务器不可用时提高 LDAP 连接性能。
6.3.6.4. 大型站点的复制策略示例
从 Example 复制策略为小型站点 的示例企业已增长到更大的位置，现在具有以下特征：
- 公司包含在两个单独的构建中，构建 A 和构建 B。
- 在正常工作时间内，构建之间的连接速度缓慢且非常繁忙。
- 每个构建都有一个非常快（每秒100 Mb 每秒）和轻量级使用的网络。
- 每个构建中的网络非常稳定，服务器硬件和操作系统平台是可靠的。
- 单个服务器可在一个构建中轻松处理负载。
对于这样的条件，您的复制策略包含以下步骤：
在两个构建中选择一个服务器，以包含目录数据的主副本。
将服务器置于构建中，其中包含负责目录数据主副本的最大人数，例如构建 A。
在构建 A 内至少复制一次，以获得目录数据的高可用性。
使用 multi-supplier 复制 配置来确保写入故障切换。
- 在第二个构建 B 中创建两个副本。
- 如果您在供应商和消费者服务器之间不需要密切一致性，请仅在非高峰期内调度复制。
6.3.7. 部分复制
使用部分复制，您可以选择一组目录服务器不会从供应商复制到消费者或其他供应商的属性。因此，可以在不复制数据库包含的所有信息的情况下复制数据库。
每个复制协议启用并配置部分复制。目录服务器对所有条目同样应用属性排除。排除的属性始终对消费者没有值。因此，对消费者服务器执行搜索的客户端永远不会看到排除的属性，即使搜索过滤器明确指定这些属性。
在以下情况下使用部分复制：
-
消费者服务器使用较慢的网络进行连接。很少更改的属性或较大的属性（如
jpegPhoto）会减少网络流量。 - 消费者服务器放置在不受信任的网络中，如公共互联网。排除敏感属性（如电话号码）提供了额外的保护级别，以确保即使服务器访问控制措施被攻击者禁止访问敏感属性，也不会访问敏感属性。
6.3.8. 在广域网络间复制
广域网络(WAN)通常具有更高的延迟、更高的带宽延迟产品，速度低于局域网。当供应商和消费者使用广泛网络连接时，目录服务器支持有效的复制。
在以前的版本中，目录服务器使用的复制协议非常敏感，因为供应商只发送一个更新操作，然后等待消费者的响应。这会导致缩短延迟更高的吞吐量。
目前，供应商在不等待响应的情况下向消费者发送多个更新和条目，复制吞吐量与局域网的吞吐量类似。
在使用 WAN 时，请考虑以下性能和安全问题：
- 使用传输层安全(TLS)协议保护在公共网络（如互联网）中执行的复制。
- 对网络使用 T1 或更快的互联网连接。
- 避免在为通过 WAN 进行复制创建协议时在服务器之间持续同步。复制流量可能会消耗大量带宽，并减慢整个网络和互联网连接的速度。
其他资源
