ibm tivoli_解决Tivoli Directory Server同步问题的方法

ibm tivoli

IBM®Tivoli®Directory Server（TDS）是功能强大且权威的企业目录基础结构，是企业安全性的关键推动因素。 它在为诸如身份管理，门户和Web服务之类的应用程序构建企业身份数据基础结构中发挥关键作用。

TDS充当数据存储库，使用户或应用程序能够查找具有特定任务所需特征的资源。 例如，产品可以利用TDS进行身份验证操作，以验证用户的身份。

因此，TDS成为关键的IT基础架构组件，并实现为高可用性和高性能的集群。 实施中的任何错误都会对现场生产环境产生非常严重的影响。 各种错误可能导致目录服务器群集成员之间的数据不一致。 这可能导致目录条目在TDS群集成员之间同步。

同步问题的一个示例症状是，用户会遇到不一致的身份验证行为，因为用户的登录凭据在不同的TDS群集成员之间是不同的。 本文将重点介绍一些可用于处理目录同步问题的策略。

Tivoli Directory Server环境可实现高可用性

高可用性环境将至少具有两个服务器：主服务器和辅助服务器。 如果主服务器发生任何事情，则辅助服务器将接管并无缝执行操作，而无需任何外部干预。

出于高可用性和性能的原因，Tivoli Directory Server被实现为各种复制拓扑中的集群。 下面概述了两种典型方案

复制方案1：对等复制拓扑（主-主）
Tivoli Directory Server集群是使用对等复制拓扑实现的。 通常将负载平衡器配置为在目录服务器实例之间为读取和写入请求进行负载平衡。 可以有几台服务器充当目录信息的主服务器。 对等主服务器将所有客户端更新复制到其他对等主服务器，但不复制从其他主服务器收到的更新。 对等复制可以提高性能，可用性和可靠性。 通过提供本地服务器来处理分布广泛的网络中的更新，可以提高性能。 通过提供一个备用主服务器，在主主服务器出现故障时可以立即接管工作，从而提高了可用性和可靠性。

负载平衡器（例如IBMWebSphere®Edge Server）具有虚拟主机名，应用程序在将更新发送到目录时使用该虚拟主机名。 负载平衡器配置为将这些更新发送到任一服务器。

当单个服务器的读写频率都太高时，此拓扑主要用于执行负载平衡。

图1. Peer-Peer复制拓扑。

复制方案2：主副本复制拓扑
当写请求的数量很少并且写操作的高可用性不是主要问题时，TDS服务器将使用主副本拓扑实现。 负载平衡器将写请求发送到主服务器，将读请求发送到任何服务器。

主服务器可以包含目录或目录的子树。 主服务器是可写的，这意味着它可以从客户端接收给定子树的更新。 副本服务器包含主服务器目录的副本或部分目录的副本。 副本是只读的。 客户端无法直接更新。 而是将客户端请求引向主服务器，主服务器执行更新，然后将其复制到副本服务器。 主服务器可以具有多个副本。

图2.主副本拓扑。

将环境配置为仅将写入更新路由到一个服务器，将读取请求路由到这两个服务器是一个好习惯。 如果第一台服务器不可用，则写请求应发送到副本服务器。 当主服务器再次可用时，写请求应路由回主服务器

常见的复制问题

复制是目录服务器用来提高性能，可用性和可靠性的一种技术。 复制过程使多个目录服务器中的数据保持同步。

目录服务器中的数据不一致主要是由于复制问题引起的。 使目录服务器保持同步需要一种勤奋的方法，包括监视和维护。 目录管理中的任何疏忽都可能导致整个集群中目录数据的显着差异。

在TDS的集群环境中，集群成员之间的数据需要保持一致。 对主服务器所做的任何更改都需要通过复制技术传播到对等服务器或副本服务器。

由于各种原因，有时对一台服务器所做的更改可能不会复制到其他服务器。 这导致它们之间的数据不一致。

在以下情况下，可能会发生TDS群集成员之间的数据不一致：

1）一台服务器包含另一个TDS群集成员上不存在的条目。

2）条目存在于两个服务器上，但是它们的属性不同。

目录服务器同步问题的原因和解决方法

在多主复制环境中，同一条目可以由多台服务器修改。 例如，如果一台服务器收到修改请求，而另一台服务器收到针对同一条目的重命名请求，则可能发生潜在的竞争情况。

由多个服务器对同一条目进行的更新可能会导致目录数据不一致，因为冲突解决是基于条目的时间戳进行的。 条目可能在一个服务器上获得更新，而在另一台服务器上获得更新。 当更新到达副本时，它的时间戳可能比复制的条目晚。 为了解决复制冲突，具有较晚时间戳记的常规数据库条目不会被具有较早时间戳记的复制条目代替，并且复制失败。 复制队列将被阻止，其他复制请求将不被处理。 队列不断增加，导致数据不一致。

要基于时间戳在服务器上禁用冲突解决，可以定义IBMSLAPD_REPL_NO_CONFLICT_RESOLUTION环境变量。 如果在启动服务器之前定义了变量，则服务器将在无复制冲突解决模式下运行。 在这种模式下，服务器不会尝试比较复制条目的条目时间戳，以尝试解决条目之间的冲突。 在服务器启动期间会检查此环境变量，因此，在服务器运行时对其进行更改不会对服务器产生任何影响。


图3.在ibmslapd.conf中设置参数

当检测到复制冲突时，替换的条目将存储在丢失和找到的日志中，以用于恢复。 在这种情况下，必须进行手动干预才能使数据保持一致状态。 系统管理员需要定期检查丢失和找到的日志，如果存在任何条目，则必须在服务器上手动进行更新。丢失和找到的日志可以在日志默认目录中找到。

设置负载均衡器是解决数据冲突的一种方法。 负载平衡器配置为仅将这些更新发送到一台服务器。 如果该服务器因网络故障而关闭或不可用，则负载平衡器会将更新发送到下一个可用的对等服务器，直到第一个服务器恢复联机并可用。


如果复制队列卡住，则可以通过Web管理员删除阻止条目。 工具。
Web管理工具。


图4.跳过阻止条目

有时，复制队列可能会变得太大，并且包含太多阻止条目。 手动删除每个阻止条目变得非常繁琐。 在这种情况下，可以使用复制错误表。
通过任一Web管理员配置ibm-slapdReplMaxErrors参数的值。 工具或目录服务器配置文件中。

只要任何条目在复制队列中被阻塞，它将被登录到ibmslapd.log文件中，并且将从队列中跳过以让其他条目继续进行。 它将一直跳过阻塞条目，直到达到ibm-slapdReplMaxErrors定义的值。
重新启动服务器以使配置更改生效。
分析日志文件中的阻止条目。

图5：通过Web admin设置ibm-slapdReplMaxErrors参数 工具。

idsldapsearch -h hostname -p port -b "o=ibm,c=us" -s "sub" \
      "objectclass=ibm-replicationAgreement" ibm-replicationState

在某些情况下，将数据从一个TDS加载到另一TDS服务器时，Bulkload或idsldif2db可能无法成功完成。 运行idsbulkload时，请仔细检查输出消息。 如果执行期间发生错误，则目录可能未完整填充。 您可能需要删除所有LDAP表，或删除数据库（重新创建一个空数据库），然后重新开始。 如果发生这种情况，则不会将任何数据添加到目录，并且必须再次尝试idsbulkload。

尽量减少人为错误，并避免在不确认预期结果的情况下进行与配置和复制相关的任何更改。 首先测试质量检查中的任何更改，然后在生产中复制这些更改。

复制工具

为了同步TDS群集成员并使它们恢复一致状态，采用了以下方法。

1）使用idsdb2ldif从一台TDS服务器导入数据，并使用idsldif2db或bulkload将数据导出到另一台服务器。

2）使用idsldapdiff实用程序。

3）在更新方式下，在具有ldap连接器的目录服务器之间使用Tivoli Directory Integrator。
参考

有关更多信息，请访问TDI产品文档 。

当条目存在于一台服务器上但副本服务器上不存在时，可以使用db2ldif和ldif2db工具来同步目录条目。

idsldapdiff实用程序和Tivoli Directory Integrator可以用于同步两个服务器上都存在但具有不同属性的条目。 如果条目存在于一个TDS群集成员而不是副本客户成员上，它们还可以同步数据。

Ldapdiff实用程序

idsldapdiff命令行实用程序旨在比较两个不同目录服务器上的两个目录子树，以确定它们的内容是否匹配。 它可识别副本服务器及其主服务器中的差异，并可用于同步副本。

该工具遍历供应商服务器上目录子树中的每个条目，并将其内容与使用者服务器上的相应条目进行比较。 由于需要读取有关每个条目的信息，因此运行该实用程序可能会花费很长时间，并且可能会向供应商和消费者服务器生成大量读取请求。 根据找到的差异数量以及是否指定了修复操作，该实用程序还可以向用户服务器生成相等数量的写请求。

Idsldapdiff执行两次传递以使服务器同步。 在第一遍中，idsldapdiff遍历供应商服务器并执行以下操作：将供应商和消费者上的所有额外条目添加。 比较并修复两个服务器上都存在的条目。 在第二遍中，idsldapdiff遍历消费者以检查消费者上是否有任何其他条目

运行该实用程序的要求

没有对任何目录服务器进行更新时，请运行该实用程序。 管理员需要将所有更新活动暂停到要比较的两个子树上。 必须在调用比较工具之前手动完成此操作。 如果在进行更新时运行该工具，则不能保证准确地报告或修复了所有差异。

如果请求修复操作，请将该工具与服务器管理控件一起使用（一个标志）。 服务器管理控件允许该工具写入只读副本，还允许它修改操作属性，例如ibm-entryUuid。

在开始复制之前，可以使用idsldapdiff实用程序使主服务器和副本服务器同步。 该工具要求两个服务器上都存在要比较的基本DN。 如果两个服务器中的任何一个都不存在基本DN，则该实用程序将给出错误并退出。

理想情况下，最初设置复制时，该工具仅在服务器之间使用一次。 例如，如果拓扑有两个对等主服务器和两个副本服务器，则可能要在对等1和对等2之间运行idsldapdiff。然后，如果复制被暂停，请在对等1和副本1之间以及对等2和副本2之间同时运行idsldapdiff。 。
如果复制设置正确，则对主服务器上目录的每次更改都会传播到副本。 但是，如果出现问题，则可以运行该工具来识别和纠正复制问题。

该实用程序是一种诊断和纠正工具，不能作为常规维护运行。 根据日志文件中发现的与复制相关的错误，管理员可能会决定运行该实用程序。

命令

idsldapdiff -sh hostname sp 389 -sD cn=root -sw password -ch consumerhostname -cp 389 \
-cD cn=root -cw password -b o=ibm,c=us  -a -F


-sh Specifies the host name.
  
-sp Specify an alternate TCP port other than default where the LDAP server is listening.
  
-sD Use dn to bind to the LDAP directory. dn is a string-represented DN
  
-sw supplier password
  
-ch Specifies the host name.
  
-cp Ldapport
  
-cD Use dn to bind to the LDAP directory. dn is a string-represented DN
  
-cw consumer password
  
-b  Use searchbase as the starting point for the search.
  
-a Specifies inclusion of server administration control for writing to a
         
 read-only replica
  
-F This is the fix option. If specified, content on the consumer replica is modified
  
   to match the content of the supplier server.
  
   This cannot be used if the -S is also specified.
  
-L filename.  If the -F option is not specified, use this option to generate an
  
   LDIF file for output.
  
-C countnumber Counts the number of non-matching entries.
  
-S Specifies to compare the schema on both of the servers
  
-O Displays DNs only for non-matching entries

结论

本文介绍了在解决与数据同步有关的问题时可以采用的各种解决方案。 当TDS服务器投入生产并且数据同步问题开始累积时，可以使用它。

---

翻译自: https://www.ibm.com/developerworks/tivoli/library/t-tdssync/index.html

ibm tivoli