使用 Tivoli Directory Server 代理实现 LDAP 的高可伸缩性和高可用性.docVIP

　　使用 Tivoli Directory Server 代理实现 LDAP 的高可伸缩性和高可用性 　　简介 　　在任何分布式环境中，为了提供普遍的访问，都需要一致的身份验证和授权服务。大量这种部署使用 IBM Tivoli Directory Server (TDS) 提供集中的安全管理。 　　把身份验证和密码服务集中在一起不仅会提高安全性，还会减少相关联的管理成本。对于这个问题，一种出色的解决方案是让一个服务器处理环境中的所有请求。但是，这需要使用高可用的服务器。在任何用户身份验证解决方案中都希望实现高可用性，因为如果身份验证服务器关闭，就可能造成整个企业停止运作。在使用 LDAP 时，有两种解决方法。可以使用 IBM Tivoli Directory Server 提供的复制特性把服务器配置成主-主模式或主-副本模式。在主-主配置中，没有主要服务器，对任何服务器所做的修改都会传播到其他主服务器。在主-副本设置中，在主服务器上执行所有修改，更新传播到一个或多个副本服务器。可以按调度计划执行复制，也可以在主服务器上完成修改之后立即复制。 　　为了展示一种可伸缩的解决方案，本文在 secldapclntd 配置中引入一个 TDS 代理。在单一 LDAP 服务器中定义大量用户信息会导致响应时间增加，整个系统可能会变慢。为了提高系统的可伸缩性，本文提供一个使用分布式目录的解决方案。在分布式目录环境中，数据跨多个目录服务器分散存储。 　　代理服务器是一种特殊的 IBM Tivoli Directory Server，它们能够从客户机接收请求并根据需要执行路由。除了对请求进行路由之外，代理服务器还能够执行负载平衡、故障转移和分布式身份验证。环境中的客户机只知道前端的代理服务器，代理服务器背后的服务器集群对于客户机是隐藏的，客户机会看到统一的目录视图。 　　TDS 代理服务器简介 　　LDAP 用于存储任何与目录相似的信息，这种信息需要快速查询，更新不太频繁。企业范围的 LDAP 服务器常常存储数百万条目。要支持如此大量的条目和相应的请求，同时又要保证性能不会下降，这就需要高可伸缩硬件。为了解决这些问题，可以使用分布式目录。 　　引入分布式目录是为了解决性能和可伸缩性问题。分布式目录有助于把大量数据分散在多个服务器上。由于数据是分散存储的，每个服务器要处理的请求数量自然就减少了，这可以简化管理。 　　通过在分布式目录前面添加代理服务器，可以非常有效地抽象它。客户机只知道代理，代理服务器上配置了后端分布式数据的详细信息。代理服务器还配置了分割数据的方法。这让代理能够从后端获取数据并传输给客户机。代理服务器和后端目录服务器之间的交互对于客户机是完全透明的。代理服务器还可以作为负载平衡器或故障转移管理器。 　　Tivoli Directory 代理服务器的关键特性包括： 　　可伸缩性：可伸缩性是目录服务器的一项重要需求。分布式目录可以有效地扩展任何目录设置。 　　设置分布式目录有不同的方法。当前可以使用的机制包括： 　　基于 RDN 散列 的分割：使用目录服务器条目计算一个惟一的散列值。散列值是根据条目的 RDN 计算出来的。在分布目录时，这个散列值映射到特定后端目录服务器中的特定条目。 　　基于子树 的分割：按照这种分割机制，每个子树驻留在一个单独的后端目录服务器上。 　　抽象：代理服务器作为一组目录服务器的抽象层。客户机看到一个统一的目录，并不知道后端的数据分布情况。另外，代理服务器和后端目录服务器之间的交互对于客户机是透明的。 　　用 TDS 代理设置 secldapclntd 　　对于使用 secldapclntd 和 IBM Tivoli Directory Server 的任何典型设置，可以使用 mksecldap 命令设置客户机和服务器。粗略来说，mksecldap 命令在配置服务器时执行以下步骤： 　　创建一个默认的 IBM Tivoli Directory Server 实例 ldapdb2。 　　配置其下将存储的 AIX 用户和组的后缀。 　　使用本地主机的安全数据库文件中的用户和组信息装载 LDAP 数据库。 　　配置 LDAP 服务器管理员 DN 和密码。 　　安装用于 LDAP 服务器的 AIX 审计插件。 　　启动 LDAP 服务器。 　　把默认的密码加密机制改为 crypt。 　　在 /etc/inittab 中添加 LDAP 服务器条目 (slapd)，以便在重新引导之后自动地重新启动。 　　本文并不使用 mksecldap 命令设置 LDAP 服务器。不使用 mksecldap 是因为，我们的最终目标是