搜索
支持控制台（Console）开发人员开始试用联系人

7.3. 定义复制策略

download PDF
复制策略由必须提供的服务决定。要确定复制策略，首先对网络、用户、应用程序及其如何使用目录服务的调查开始。
在规划复制策略后，可以部署目录服务。最好将目录服务部署到阶段，因为这可让管理员根据企业在目录服务上的负载来调整目录服务。除非负载分析基于已在运行的目录，准备更改目录服务，因为目录的现实需求变得很明显。

7.3.1. 执行复制调查

在站点问卷调查中收集有关网络质量和使用情况的信息，以帮助定义复制策略：
  • LAN 和 WAN 的质量可以连接不同的构建或远程站点以及可用带宽的数量。
  • 用户的物理位置、每个站点中的用户数量及其使用模式；这就是他们打算如何使用目录服务。
  • 访问目录服务的应用程序数量以及读取、搜索的相对百分比，以及比较操作与写入操作。
  • 如果消息传递服务器使用 目录，请找出它处理的每个电子邮件消息所执行的操作数量。依赖于目录服务的其他产品通常是身份验证应用程序或子目录应用程序等产品。对于每个，确定目录服务中执行的操作的类型和频率。
  • 存储在目录服务中的条目的数量和大小。
管理人类资源数据库或财务信息的站点可能比那些只用于电话目的的工程人员在目录服务上重取负载。

7.3.2. 使用 Fractional Replication 复制复制所选属性

部分复制允许管理员选择从供应商传输到消费者（或其他供应商）的一系列属性。因此，管理员可以在不复制包含的所有信息的情况下复制数据库。
每个复制协议都启用和配置部分复制。属性排除所有条目同样同样地应用。至于消费者服务器方面，排除的属性始终没有值。因此，客户端对消费者服务器执行搜索永远不会看到排除的属性。类似地，应当执行搜索指定其过滤器中的这些属性，不会匹配条目。
在以下情况下，部分复制特别有用：
  • 如果消费者服务器使用较慢的网络进行连接，但不经常更改的属性或更大属性，如 jpegPhoto 会导致网络流量减少。
  • 如果使用者服务器放置在不受信任的网络中，例如公共互联网，不包括敏感属性，如电话数字，即使服务器的访问控制措施被破坏或机器被攻击者破坏，也不再提供任何级别的保护。
在第 8 章" 管理指南 "中的复制协议和供应商配置小节中介绍了配置部分复制。

7.3.3. 复制资源要求

使用复制需要更多资源。在定义复制策略时请考虑以下资源要求：
  • 磁盘用量 - 在供应商服务器中，更改日志在每个更新操作后写入。接收许多更新操作的供应商服务器可能会遇到更多磁盘用量。
    注意
    每个供应商服务器都使用单一的 changelog。如果供应商包含多个复制的数据库，则更改日志会更频繁使用，磁盘使用量越高。
  • 服务器线程 - 每个复制协议使用一个服务器线程。因此，客户端应用程序可用的线程数量会减少，可能会影响客户端应用程序的服务器性能。
  • 文件描述符 - 服务器可用的文件描述符数量会减少更改日志（一个文件描述符）和每个复制协议（每个协议一个文件描述符）。

7.3.4. 管理多容量复制所需的磁盘空间

multi-supplier 副本维护额外的日志，包括目录编辑的更改日志、更新条目的状态信息以及删除条目的 tombstone 条目。执行多层次复制需要此信息。由于这些日志文件会变得非常大，因此需要定期清理这些文件，以便防止浪费磁盘空间。
有四个属性可以为 multi-supplier 副本配置 changelog maintenance。两个位于 cn=changelog5 下，直接与修剪更改日志相关：
  • nsslapd-changelogmaxage 设置更改日志中条目可以达到的最长期限；一旦一个条目比这个限制旧，它会被删除。这样会使更改日志无限期地增大。
  • nsslapd-changelogmaxentries 设置 changelog 中允许的最大条目数。与 nsslapd-changelogmaxage 一样，这也会修剪更改日志，但要小心设置。这必须足够大，以允许一组完整的目录信息或多层次复制可能无法正常工作。
其他两个属性位于 cn=replica, cn=suffixDN, cn=mapping tree, cn=config 中的复制协议条目下。这两个属性与在 changelog 中保留的维护信息相关，即 tombstone 和 state 信息，而不是目录编辑信息。
  • nsDS5ReplicaPurgeDelay 设置 tombstone （删除）条目和状态信息的最大期限。一旦 tombstone 或 state information 条目早于这个年龄，就可以删除它。这与 nsslapd-changelogmaxage 属性不同，其中 nsDS5ReplicaPurgeDelay 值仅适用于 tombstone 和状态信息条目； nsslapd-changelogmaxage 适用于 changelog 中的每个条目，包括目录修改。
  • nsDS5ReplicaTombstonePurgeInterval 设置服务器运行清除操作的频率。在这个间隔里，Directory 服务器会运行内部操作来清理 changelog 中的 tombstone 和 state 条目。确保最长期限超过复制更新调度的最长期限，或者多层次复制可能无法正确更新副本。
管理复制和更改日志的参数在第 2 章"核心配置属性"中所述，如 配置、命令和文件参考 中所述。

7.3.5. 跨 Wide-Area 网络复制

广域网通常具有较高的延迟、更高的带宽延迟产品，速度低于局域网。当供应商和消费者使用广域网连接时，目录服务器支持有效的复制功能。
在以前的目录服务器版本中，用于传输供应商和用户之间的条目和更新非常敏感，因为供应商仅发送一个更新操作，然后等待消费者的响应。这会导致减少延迟较高的吞吐量。
供应商在不等待响应的情况下向消费者发送多个更新和条目。因此，在延迟高的网络中，许多复制操作可以在网络上传输，而复制吞吐量则类似于在本地区域网络中实现的。
注意
如果供应商连接到运行比 7.1 之前的版本的 Red Hat Directory Server 版本的另一个供应商，它会回退到旧的复制机制来实现兼容性。因此，需要在供应商和消费者服务器上运行至少版本 7.1，才能实现对延迟的复制。
对于目录服务器和网络连接效率，同时存在性能和安全问题：
  • 如果跨公共网络（如互联网）执行复制，则强烈建议使用 TLS。这种保护措施可防止停止复制流量。
  • 对网络使用 T-1 或更快互联网连接。
  • 在创建用于跨域网络复制的协议时，请避免在服务器间持续同步。复制流量可能会消耗大量带宽，并减慢整个网络和互联网连接的速度。
  • 初始化消费者时，不会立即初始化消费者；相反，使用文件系统副本初始化速度要快于在线初始化或从文件初始化。有关使用文件系统副本初始化的信息，请参阅 红帽目录服务器管理指南。

7.3.6. 使用复制进行高可用性

使用复制以防止丢失单一服务器导致目录服务不可用。至少将本地目录树复制到至少一个备份服务器。
某些目录架构师认为每个物理位置应复制三次，以获得最大数据可靠性。将复制用于容错的程度取决于环境和个人首选项，但根据目录服务使用的硬件和网络的质量，以此作为这一决定。不可靠硬件需要更多备份服务器。
注意
不要使用复制作为常规数据备份策略的替代。有关备份目录数据的详情，请查看 红帽目录服务器管理指南。
要保证所有目录客户端的写入故障切换，请使用多层次复制场景。如果 read-failover 足够了，请使用单层复制。
LDAP 客户端应用程序通常只能配置为只搜索一个 LDAP 服务器。除非有自定义客户端应用程序通过位于不同 DNS 主机名的 LDAP 服务器轮转，否则 LDAP 客户端应用程序只能配置为查找目录服务器的单一 DNS 主机名。因此，可能需要使用 DNS 轮循或网络排序来向备份目录服务器提供故障转移。有关设置和使用 DNS 循环或网络排序的详情，请参考 DNS 文档。

7.3.7. 使用 Replication 进行本地可用性

复制本地可用性的需求由网络的质量以及站点的活动决定。另外，请仔细考虑目录服务中包含的数据的性质，如果数据暂时不可用，则会给企业带来后果。对数据进行更关键任务，对系统的容错程度越低，导致网络连接不佳。
将复制用于本地可用性，理由如下：
  • 保留数据的本地主副本。
    对于大型的跨国企业来说，这是一个重要的策略，需要仅维护特定国家或地区员工感兴趣的目录信息。拥有本地主副本对于任何企业来说也很重要，因为任何位于部门或机构级别控制数据的任何企业来说也很重要。
  • 缓解不可靠或间歇性可用的网络连接。
    如果出现不可靠的 WAN，则可能会出现间歇性网络连接，如国际网络中发生。
  • 要偏移定期，极高的网络负载可能会导致目录服务的性能被严重降低。
    在具有陈旧网络的企业中，性能可能也会受到影响，在正常的工作时间内可能会遇到这些状况。

7.3.8. 使用 Replication 进行负载均衡

复制可以通过多种方式平衡目录服务器上的负载：
  • 通过将用户的搜索活动分散在多个服务器中。
  • 将服务器指定给只读活动（只在供应商服务器上发生）。
  • 通过将特殊服务器专用于特定的任务，如支持邮件服务器活动。
平衡网络的工作负载是由目录数据复制执行的重要功能。尽可能地将数据移动到可以使用合理快速、可靠的网络连接访问的服务器。最重要的注意事项是服务器与目录用户之间的网络连接速度和可靠性。
目录条目通常平均大约为 1 kilobyte(KB)。因此，每个目录查找都会在网络负载中添加一个 KB。如果目录用户每天执行十个目录查找，那么对于每个目录用户来说，每个目录用户都会增加网络负载，每天大约有 10KB 的网络负载。如果站点有一个缓慢、大量加载或不可靠的 WAN，那么请考虑将目录树复制到本地服务器。
另外，请考虑，本地可用数据的好处是可能需要因为复制导致的网络负载增加而造成的。如果整个目录树复制到远程站点，例如，这可能会给网络增加大量压力，这与用户的目录查找造成的流量进行比较。当目录树经常改变时，这尤其如此，但在远程站点中只有一些用户每天执行一些目录查找。
表 7.1 “网络上的复制和远程查找的影响” 比较复制目录 100万条目的成本（即每天更改这些条目 10% 的数据），同时需要花费少量远程站点，每天执行 10 个查找。每个情况下，目录条目的平均大小被认为是 1KB。
表 7.1. 网络上的复制和远程查找的影响
加载类型 对象（object）[a] access/Day[b] avg.条目大小 Load
复制 100万次 100,000 1KB 100Mb/day
远程查找 100 1,000 1KB 1Mb/day
[a] 对于复制，对象 指的是数据库中的条目数量。对于远程查找，它指的是访问数据库的用户数量。
[b] 对于复制，Accesses/Day 基于 10% 对需要复制的数据库的变化率。对于远程查找，它基于每日的远程用户的查询。
由于复制与普通目录使用情况导致的加载差异不同，因此使用复制进行网络负载平衡需要。另一方面，本地可用目录数据的好处可能远超过网络负载的注意事项。
在为本地站点和网络过载和使用调度复制时，最好发生数据。有关数据一致性和复制计划的更多信息，请参阅 第 7.1.2 节 “数据一致性”。

7.3.8.1. 网络负载均衡示例

在本示例中，企业在纽约和 Los Ans Angeles 处设有办事处，每个办事处都有其管理的特定子树。

图 7.9. 在远程办公室管理企业子树

在远程办公室管理企业子树
每个办公室包含一个高速网络，但两个城市之间的连接不可靠。平衡网络负载：
  1. 为每个办公室选择一个服务器作为本地管理数据的供应商服务器。
  2. 将本地管理的数据从该服务器复制到远程办公室中对应的供应商服务器。
  3. 将每个供应商服务器上的目录树（包括从远程办公室提供的数据）复制到至少一个本地目录服务器，以确保目录数据的可用性。对本地管理的后缀使用多supplier 复制，为接收远程服务器数据的主副本的后缀进行级联复制。

7.3.8.2. 用于提高性能的负载平衡示例

假设企业有以下特征：
  • 使用一个目录服务器，其中包含支持 100 万用户的 150 万个条目
  • 每个用户每天执行十个目录查找
  • 使用一个消息传递服务器，每天处理 2,500万邮件
  • 消息传递服务器针对它处理的每个邮件执行五个目录查找
这相当于每天进行 1 千万次的用户查找，每天 1.25 亿次的电子邮件查找，总计每天 1.35 次的目录查找。
随着营业日的 8 小时工作日和用户分布到四个时区，例如，在四个时间段内的工作日（或峰值使用）将延长至 12 小时。因此，该服务必须在 12 小时时间内支持 1.35億目录查找。此等于为每秒 3,125 查找（135,000,000 /(60*60*12)）。
表 7.2. 计算目录服务器负载
访问类型 类型数 每日访问 总访问数
用户查找 100万次 10 1,000 万
电子邮件查找 2,500 万 5 125 million
组合访问 135 million
总计 1.35億(3,125/second)
如果运行 Directory 服务器的硬件支持每秒读取 500 个，则必须使用至少 6 个或 7 个目录服务器来支持此负载。对于拥有一百万目录用户的企业，为本地可用性添加更多目录服务器。
复制方法有几种：
  • 在一个城市中配置两个目录服务器以处理所有写入流量。
    此配置假定应该对所有目录数据有单一的控制点。
  • 使用这些供应商服务器复制到一个或多个 hub 供应商。
    目录服务服务的读取、搜索和比较应针对于消费者服务器的请求，从而释放供应商服务器来处理写入请求。
  • 使用 hub 供应商将复制到整个企业的本地站点。
    复制到本地站点有助于平衡服务器的工作负载和 WAN，以及确保目录数据的高可用性。
  • 在每个站点，至少复制一次以确保高可用性，至少用于读取操作。
  • 使用 DNS sort 以确保本地用户始终找到他们可以用于目录查找的本地目录服务器。

7.3.8.3. Small 站点的 Replication 策略示例

example Corp. 具有以下特征：
  • 整个企业都包含在一个构建中。
  • 构建速度很高（每秒100 Mb/秒）和轻量使用的网络。
  • 网络非常稳定，服务器硬件和操作系统平台是可靠的。
  • 单一服务器可轻松处理站点的负载。
在这种情况下，Example Corp. 决定在主服务器关机以进行维护或硬件升级时，至少复制一次，以确保主服务器关机。另外，设置一个 DNS 轮循，以便在其中一个目录服务器不可用时提高 LDAP 连接性能。

7.3.8.4. 大型站点的复制策略示例

随着 example Corp. 的增长，它保留了以前的特征（如 第 7.3.8.3 节 “Small 站点的 Replication 策略示例”中），它有一些变化：
  • 企业包含在两种独立构建中。
  • 构建之间有较慢的连接，这些连接在正常工作时间内非常忙。
随着对网络需要的改变，那么 Corp. 的管理员需要调整其复制策略：
  • 在两个构建中选择一个服务器，以包含目录数据的主副本。
    此服务器应放在构建中，其中包含负责目录数据的主副本的最大人员数量。我们应该将这一构建视为构建 A。
  • 在构建 A 中至少复制一次以实现高可用性目录数据。
    使用多supplier 复制配置来确保写入失败。
  • 在第二个构建(Building B)中创建两个副本。
  • 如果供应商和消费者服务器之间不需要关闭一致性，请调度复制，使其仅在非高峰期时间进行。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.