Sun ONE Directory Server 5.2 安装和调整指南 |
本章介绍从 Netscape Directory Server 4.x 和 iPlanet Directory Server 5.x 升级到 Sun ONE Directory Server 5.2。
注意 本章不说明如何从 Innosoft Distributed Directory Server 4.5.1 升级。
本章主要讨论如何将目录数据从旧服务器移植到新服务器上。有关从旧服务器移植到新服务器上的配置属性的详细信息,请参阅 Sun ONE Directory Server 参考手册。
升级之前
升级前,请熟悉 Sun ONE Directory Server 5.2 提供的新功能,在“建议的读物” 下面的文档中进行了描述。并请检查在实施现有目录服务期间制定的设计决策。
升级单个服务器实例
升级服务器实例包括在现有服务器旁安装新服务器(在不同的 ServerRoot 中使用不同的 serverID,以及不同的 Administration Server 和 Directory Server 端口号)、停用旧服务器、移植配置和目录数据,然后使客户机向新服务器发出请求。
注意 确保运行现有服务器的主机上有足够的磁盘空间。升级过程不仅至少需要有足够的本地磁盘空间来存放旧服务器和新服务器的二进制数据和数据库,而且还需要有足够的额外空间来存放包含所有现有后缀中条目的 LDIF 文件。估计所需的本地磁盘空间可能要稍微大于:
2 *(现有服务器所需的空间)+(LDIF 文件所需的空间)
必须对同一主机上的两个服务器同时执行升级过程,因为不能通过联网的驱动器执行数据移植。
Sun ONE Directory Server 5.2 提供的脚本可帮助您移植服务器实例的数据。移植脚本按顺序执行下列任务:
- 停用现有服务器,同时备份当前配置。
- 检查架构配置文件,通知您标准架构配置文件和现有服务器使用的架构配置文件之间的差异。
(仅用于 4.x 到 5.2)如果现有的 4.x 服务器使用未安装在默认位置的自定义架构,位于 ServerRoot/slapd-serverID/config,那么您必须在移植目录数据之前手动调整配置。
- 为存储在旧服务器中的每个后缀创建数据库。
(仅用于 4.x 到 5.2)4.x 服务器支持每个数据库存在多个后缀。移植脚本为新服务器上的每个后缀都创建数据库。
- 移植服务器和数据库配置参数。
4.x 服务器将此类参数存储在 slapd.conf 中。5.x 服务器将此类参数作为条目存储在 dse.ldif 中。
注意 该脚本不移植 o=NetscapeRoot 下的数据。
部署服务器(例如依赖此后辍中数据的 Sun ONE Messaging Server)时,请手动移植 o=NetscapeRoot 中的数据,或使用此服务器提供的工具进行移植。
(仅用于 4.x 到 5.2)移植脚本不移植所有的 4.x 服务器参数。在某些情况下,必须手动移植 4.x 属性值。详细信息,请参阅 Sun ONE Directory Server 参考手册 的当前版本。
- 移植用户定义的架构对象。
- 移植索引。
- 移植标准服务器插件。
必须手动移植自定义的插件。至少,必须重新编译所有自定义插件。有关插件 API 变更的详细列表,请参阅 Sun ONE Directory Server Plug-In API 编程指南。
- (仅用于 5.x 到 5.2)移植复制协议。
注意 从 5.2 Directory Server 复制到 5.1 服务器之前,请将 cn=config 时的 nsslapd-schema-repl-useronly 设置为 on。否则,5.2 架构就加入 5.1 服务器,以防止 5.1 服务器由于存在重复对象而重新启动。
- 移植证书数据库和 SSL 参数。
- (仅用于 5.x 到 5.2)移植数据库链接。
- (仅用于 5.x 到 5.2)移植复制条目。
- 移植 SNMP 配置。
完成移植脚本后,客户机可以向新服务器发送请求。
升级多个已复制的服务器
升级多个服务器意味着单独升级每个服务器,这不足为奇。但是,升级服务器的顺序取决于现有服务器的软件版本和复制拓扑。
对于 5.x 到 5.2 的升级,标准过程是自下而上。首先移植使用者服务器。接着升级集线器。最后升级主服务器。有关在特定实例中如何执行此操作的信息,请参阅“5.x 升级方案示例”。
对于 4.x 到 5.2 升级,由升级 4.x 主服务器开始,然后处理从主服务器复制的使用者服务器的每个分支,从最靠近主服务器的使用者服务器开始复制。有关在特定实例中如何执行此操作的信息,请参阅“4.x 升级方案示例”。
如果现有环境包括多个已复制服务器,则请在升级前仔细阅读本章中所有相关的节。您必须制定详尽的计划,以避免产生不必要的停机时间。
获取升级帮助
Sun 专业服务可以帮助您升级关键的目录服务。
联系信息,请参阅 http://www.sun.com/service/sunps/sunone/。
升级单个服务器
本节介绍从单个现有服务器到单个 5.2 服务器的升级过程。
注意 如果现有的 4.x 服务器使用自定义架构,那么请确保在移植任何数据前,移植脚本可以找到自定义架构。详细信息,请参阅“(用于 4.x 到 5.2)处理自定义架构”。
如果移植脚本不识别自定义架构,则它不移植此架构;而是在将数据移植到新服务器后,应用标准架构文件。将标准架构应用到符合自定义架构的条目可能导致无法对其进行修改,从而使已升级的目录为只读。
安装新服务器
按照第 1 章“安装 Sun ONE Directory Server”中的说明,在与现有服务器所在的同一主机上安装新服务器。
注意 安装新服务器之前,请确保拥有现有服务器的当前备份。
新服务器驻留的 ServerRoot 位置必须与现有服务器的位置不同。新服务器还必须由不同的 serverID 标识。
尽管可以选择重新使用为原始安装提供的大多数配置信息,但请不要重新使用现有的端口号。相反,在移植现有数据后可以更改新服务器的端口号。
(用于 4.x 到 5.2)处理自定义架构
提供的用于移植数据的脚本只能识别放置在标准 slapd.user_oc.conf 和 slapd.user_at.conf 文件中的自定义架构,或放置在其他文件中并使用 useroc 和 userat 指令包括在 slapd.conf 中的自定义架构。例如,如果自定义架构直接包含在 slapd.at.conf 或 slapd.oc.conf 中,则移植脚本不识别这些架构。
升级前请执行下列步骤。
- 将 slapd.at.conf 或 slapd.oc.conf 与新服务器的 ServerRoot/bin/slapd/install/version4/ 下提供的标准文件进行比较,将自定义架构元素转录到 slapd.user_oc.conf 和 slapd.user_at.conf 文件中。
如果自定义对象类有继承关系,那么请确保上一级对象类优先于架构配置文件中的其他对象类。
- 如果自定义属性已添加到 slapd.oc.conf 中的标准对象类,则创建包含 slapd.user_oc.conf 中属性的新对象类,并将新对象类添加到现有目录中使用自定义属性的各个条目中。
- 使用 useroc 和 userat 指令,将新指令放置在其他文件的 include 语句附近,将 slapd.user_oc.conf 和 slapd.user_at.conf 文件包含在现有服务器的 slapd.conf 文件中。
此时,现有服务器使用的所有自定义架构都应驻留在 slapd.user_oc.conf 或 slapd.user_at.conf 中,且应使用 useroc 和 userat 指令使 slapd.conf 包含这些文件。
移植现有数据
处理自定义架构后,执行下列步骤将现有数据移植到新服务器上。
- 如果计划要在新的 Directory Server 上采用脱机方式从文件初始化复制,则在处理前要获得这些文件。
有关导出 Directory Server 数据的说明,请参阅 Sun ONE Directory Server 管理指南。
- 确保新的 Directory Server 正在运行。
- 作为用户有权在旧服务器和新服务器上启动、停止和运行数据库导出和导入。
例如,成为超级用户或以 Administrator 身份登录。
- 设置如表 2-1 所示的环境变量。
表 2-1    移植时使用的环境变量
变量
值
PATH
(UNIX) ServerRoot/bin/slapd/admin/bin:$PATH
(Windows) ServerRoot/bin/slapd/admin/bin;%PATH%
PERL5LIB
ServerRoot/bin/slapd/admin/bin
- 在新服务器实例下运行移植脚本:
# cd ServerRoot/bin/slapd/admin/bin
# perl migrateInstance5 -p port52 -D "cn=directory manager" -w password -o oldServ -n newServ
其中,oldServ 代表到旧服务器实例的完整路径(如 /usr/iplanet/servers/slapd-ldap 或 /usr/iplanet/ds5/slapd-ldap),newServ 代表到新服务器实例的完整路径(如 /var/ds/v5.2/slapd-dirserv)。
脚本在运行时产生输出。可以选择将此输出重定向到文件中,以便在移植完成后进行检查。
仅在将现有数据移植到新服务器后停用旧服务器。
(用于 4.x 到 5.2)创建复制协议
如果现有的 4.x 服务器包含在复制范围内,则在移植数据后,升级需要重新创建复制协议。在执行升级过程之前,请参阅“(用于 4.x 到 5.2)升级已复制的服务器”。
有关为 5.2 服务器配置复制的说明,请参阅 Sun ONE Directory Server 管理指南。
(可选)重新使用现有端口号
将数据从旧服务器移植到新服务器后,可以选择停用旧服务器,并使新服务器使用旧服务器所使用的相同端口进行监听。使用同一端口可使客户机应用程序继续运行,而无需更改其配置。
有关更改服务器端口的说明,请参阅 Sun ONE Directory Server 管理指南。在新服务器开始使用旧端口进行监听之前,要确保停止旧服务器。
(用于 4.x 到 5.2)升级已复制的服务器
升级已复制的 4.x 服务器时,从复制到新的主服务器开始,然后通过复制拓扑逐个处理分支。此方法限制了服务器同步流量的大小。
注意 有关复制配置和初始化的详细说明,请参阅 Sun ONE Directory Server 管理指南。
准备新的主服务器
升级期间,5.2 服务器配置为主服务器,但在 4.x 拓扑中它充当遗留使用者服务器。升级后,禁用 4.x 使用者服务器功能,新服务器则用作 5.2 拓扑中的主服务器。
此过程需要手动配置新的主服务器。因此,可以在与现有主服务器所在的不同主机上安装新的主服务器。
- 按照第 1 章“安装 Sun ONE Directory Server”中的说明安装新服务器。
- 在新服务器上手动重新生成 4.x 主服务器的配置。
- 将新服务器用作主服务器(用于 5.2 拓扑)。
有关说明,请参阅 Sun ONE Directory Server 管理指南。
- 将新服务器用作 4.x 主服务器的遗留使用者服务器(用于 4.x 拓扑)。
有关说明,请再次参考 Sun ONE Directory Server 管理指南。
- 对从 4.x 主服务器到新服务器的复制进行初始化。
此过程在 Netscape Directory Server 管理指南 的第 13 章“管理复制”中进行描述。请参阅标题为“手动初始化使用者服务器”一节。
现在可以升级使用者服务器。
升级使用者服务器
本过程列出一些方法。详细信息,请参阅后续步骤。
- 升级 4.x 拓扑中的所有分支。
- 根据需要,向 5.2 拓扑添加其他服务器。
- 在新的主服务器上禁用遗留使用者服务器协议以切断新拓扑与旧拓扑之间的联系。
此过程完成后,即完成了更新过程。
升级分支
将现有 4.x 复制拓扑视作一个树,主服务器作为根元素。这里,分支表示此树中一组已复制的服务器,复制流从根节点供应商服务器开始,通过树中的使用者服务器,最终达到叶节点使用者服务器。
升级分支包括自上而下使用新服务器替换分支中的所有旧服务器。
注意 升级服务器时,复制流停止流向此分支中的所有下游服务器。在升级期间,应考虑将客户机请求重定向到另一个分支。
- 按照“升级单个服务器”中的说明,升级分支中的顶端服务器。
此操作切断流向分支的复制流,暂时停止分支中的下游服务器上的复制更新。
- 配置 5.2 分支中新服务器上的复制协议,以便接收复制拓扑中与新的主服务器较近的 5.2 服务器的更新。
例如,在新分支中配置顶端服务器来接收 5.2 主服务器中的更新。
- 对从 5.2 供应商服务器到新的 5.2 服务器的复制进行初始化。
脱机初始化可能要快于联机初始化,这取决于网络性能和目录数据容量与更新比较的结果。
- 沿着分支采用递归方式应用第 1 步、第 2 步和第 3 步,直到对所有叶使用者服务器完成这些步骤为止。
有关配置复制协议和初始化复制的说明,请参阅 Sun ONE Directory Server 管理指南。
到此为止,完成了对分支的更新过程。对其余的 4.x 分支重复此过程。
添加其他服务器
完成从 4.x 拓扑到 5.2 拓扑的升级后,可以根据需要为新拓扑添加其他主服务器、集线器和使用者服务器。
针对每个其他服务器执行下列步骤。
- 按照第 1 章“安装 Sun ONE Directory Server” 中的说明安装新服务器。
- 调整新服务器上的复制协议以符合已规划的拓扑。
有关说明,请参阅 Sun ONE Directory Server 管理指南。
- 在新服务器上初始化复制。
有关说明,请再次参阅 Sun ONE Directory Server 管理指南。
4.x 升级方案示例
请考虑某一 4.x 主服务器的升级,这个主服务器复制到两个分支,一个分支是单个使用者服务器,另一个分支是提供有两个使用者服务器的集线器。本节介绍升级到新的多主服务器拓扑所执行的步骤。
图 2-1 显示升级前的 4.x 拓扑。
图 2-1    现有 4.x 拓扑示例
图 2-2 显示添加 5.2 主服务器的过程,此主服务器还充当 4.x 主服务器的遗留使用者服务器。
图 2-2    带有其他新服务器的 4.x 拓扑的示例
图 2-3 显示复制 4.x 分支的第一步。
注意,在升级期间整个分支都停止接收复制更新。此中断在停止上游 4.x 使用者服务器以进行升级时开始,在重新启动 4.x 使用者服务器时结束。
如说明中所述,如果客户机需要最新的可用更新,则可以选择将客户机请求导向另一个分支上的使用者服务器。
图 2-3    升级过程中 4.x 分支示例 - 第 1 步
图 2-4 显示替换 4.x 分支的下一个步骤。
图 2-4    升级过程中 4.x 分支示例 - 第 2 步
图 2-5 显示替换 4.x 分支的下一个步骤。
图 2-5    升级过程中 4.x 分支示例 - 第 3 步
图 2-6 显示替换另一 4.x 分支。
图 2-6    升级过程中 4.x 分支示例 - 下一个分支
图 2-7 显示两个并列的拓扑。
图 2-7    升级过程中 4.x 和 5.2 拓扑示例
图 2-8 显示向新拓扑中添加主服务器、集线器和其他复制协议。
图 2-8    向 5.2 拓扑中添加服务器
完成升级过程后还可以添加其他服务器。
图 2-9 显示复制协议从旧 4.x 主服务器移至 5.2 主服务器。
图 2-9    删除复制协议
在重新定向客户机请求并删除复制协议后,可以禁用 4.x 服务器。
图 2-10 显示生成的 5.2 拓扑。
图 2-10    生成的 5.2 拓扑
现在客户机请求定向到 5.2 拓扑。
(用于 5.x 到 5.2)升级已复制的服务器
升级已复制的 5.x 服务器时,通常从升级使用者服务器开始,然后升级集线器,最后升级主服务器。该自下而上的方法每次只中断一个服务器,而不是中断复制拓扑的一个完整分支。该方法还可帮助您避免主服务器和使用者服务器之间可能的自定义架构同步问题。
注意 这里描述的过程应用标准方法升级 5.x 拓扑。
但是,如果自下而上的方法未能满足特定要求,则请采用其他方法。
升级 5.x 服务器
- 对于现有拓扑中的每个使用者服务器,请按照“升级单个服务器”中的说明升级使用者服务器。
- 对于现有拓扑中的每个集线器,请按照相同的说明更新集线器。
- 对于现有拓扑中的每个主服务器,请按照相同说明更新主服务器。
添加其他服务器
完成从 5.x 拓扑到 5.2 拓扑的升级后,可以根据需要为新拓扑添加其他主服务器、集线器和使用者服务器。
针对每个其他服务器执行下列步骤。
- 按照第 1 章“安装 Sun ONE Directory Server” 中的说明安装新服务器。
- 调整新服务器上的复制协议以符合已规划的拓扑。
- 在新服务器上初始化复制。
有关配置复制协议和初始化复制的说明,请参阅 Sun ONE Directory Server 管理指南。
此过程完成后,即完成了更新过程。客户机可以开始使用已升级复制拓扑中的服务器。
5.x 升级方案示例
请考虑对复制到两个集线器(提供两个使用者服务器)的 5.x 双主服务器进行升级。本节介绍升级此拓扑以使用 5.2 服务器所执行的步骤。
图 2-11 显示升级前的 5.x 拓扑。
图 2-11    现有 5.x 拓扑示例
第一步涉及升级使用者服务器。图 2-12 显示生成的拓扑。
图 2-12    5.x 使用者服务器升级步骤示例
下一步涉及升级集线器。图 2-13 显示了升级后的结果。
图 2-13    5.x 集线器升级步骤示例
下一步涉及升级主服务器。图 2-14 显示升级后的结果。
图 2-14    5.x 主服务器升级示例 - 第 3 步
图 2-15 显示升级后的 5.2 拓扑。此时,可以停用旧拓扑中的服务器,新服务器已添加到 5.2 拓扑中。
图 2-15    升级后的 5.2 拓扑示例
现在客户机请求定向到 5.2 拓扑。