test

Sun Java Enterprise System 5 安装规划指南

第 3 章 制定安装规划

制定实现规范（按第 2 章，制定实现规范所述）之后，您拥有了制定安装规划所需的信息。安装规划列出了安装和配置 Java ES 解决方案所需的所有步骤。您的安装规划将列出实现特定 Java ES 解决方案所需的所有步骤。

本章说明如何制定安装规划。先着手于部署体系结构和实现规范中的信息，它们描述您的 Java ES 解决方案的已部署状态。您要对这些文档中的信息进行分析，确定如何使用 Java ES 安装程序和配置向导来实现规范文档中所描述的解决方案。

本章将分节介绍制定安装规划的方法：

安装规划问题

安装和配置过程的目标是实现部署体系结构中所述的分布式系统。分布式系统由多个组件实例组成，这些组件实例运行在多个计算机上，且彼此之间能够交互操作。要获得一个能够正常运行的分布式系统，必须将组件实例安装到多个计算机上并执行基本配置，以在各组件实例之间建立互操作性。

安装和配置的过程根据 Java ES 安装程序的行为及各个组件的要求来决定。为确保得到一个能够正常运行的分布式系统，您所制定的安装规划必须恰当地使用安装程序并要考虑到解决方案中使用的组件的要求。您的规划必须描述安装每个组件实例及执行基本配置的正确顺序，还要必须指定用以将组件实例配置为交互操作的配置值。

本节介绍在制定安装规划时所必须考虑的主要问题。

分布式安装

Java ES 生产解决方案的服务质量要求需要采用将组件实例分布在多个计算机上的体系结构。例如，为实现可靠的 portal 服务，体系结构可能需要两台不同计算机上的两个 Portal Server 实例，并使用负载平衡在这两个实例之间建立故障转移关系。

但 Java ES 安装程序一次只能在一台计算机上运行。因此，在安装分布式解决方案时，必须在解决方案中使用的每一台计算机上都运行该安装程序。

多数情况下，必须先在一台计算机上安装一个或多个组件，然后运行配置向导执行基本配置。通常，在一台计算机上完成安装和配置之后才能继续在其他计算机上安装和配置另外一组组件。要安装和配置分布式组件实例，可能要执行类似于图 3–1 中所示的一系列任务。

图 3–1 分布式安装过程示例

在计算机 01 上，安装 Messaging Server 和 Calendar Server，配置 Messaging Server，再配置 Calendar Server。在计算机 02 上重复此过程。

组件依赖性

有些 Java ES 组件只有在安装并配置其他组件之后才能进行安装和配置。发生依赖性的原因有以下几点：

注意，在这些依赖性中，有些是解决方案范围的，有些则是本地的。在制定安装规划时，要对解决方案范围的依存关系和本地依存关系做不同的考虑。以下示例介绍了它们之间的不同：

Access Manager 对 Directory Server 的依存关系是解决方案范围的依存关系。安装 Access Manager 时，需要给出由 Directory Server 的一个或多个实例所提供的目录服务的 URL。安装并配置 Directory Server 后，它即会提供可供解决方案中所有组件使用的目录服务。这种依存关系决定了解决方案范围的组件实例安装和配置顺序 — 您必须在安装和配置 Access Manager 之前先安装和配置 Directory Server。在安装规划中，解决方案范围的依赖性决定整个安装和配置步骤的顺序。可以计划先安装 Directory Server，然后再添加依赖目录服务的组件（如 Access Manager）。

Access Manager 对 Web 容器的依赖性是本地依赖性。要满足这一依赖性，必须在运行 Access Manager 的计算机上安装 Web 容器。但此 Web 容器并不为整个解决方案提供 Web 容器服务。如果您的分布式体系结构指定在与 Access Manager 所在计算机不同的计算机上安装 Portal Server，则您必须计划在这两台计算机上都安装一个 Web 容器。每个 Web 容器都在本地支持一个不同的组件。因此，在分布式解决方案中，不存在可供 Web 容器为整个解决方案提供服务的单一位置，您必须计划在整个安装顺序中安装 Web 容器若干次。

要为解决方案制定安装规划，需要对描述解决方案的部署体系结构进行分析，然后确定组件之间的依存关系。您的规划必须以满足所有依赖性的顺序来安装和配置组件。总之，先根据解决方案范围的依赖性来制定整个安装顺序。然后考虑各个计算机上可能存在的本地依赖性。

组件依赖性列在表 3–1 中。有关处理这些依存关系的更多信息，参见制定安装规划中对各个组件的描述。

表 3–1 Java ES 组件依赖性

产品组件

依赖性 

依赖性实质 

是否必须为本地？ 

Access Manager

Directory Server 

存储配置数据；存储用户数据并启用对用户数据的查找 

否 
 

J2EE Web 容器，以下产品之一： 

-Application Server； 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

必须将 Access Manager 部署到这些 Web 容器之一 

是 

Access Manager SDK

Access Manager 

提供底层 Access Manager 服务 

否 
 

J2EE Web 容器，以下产品之一： 

-Application Server； 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

必须将 Access Manager SDK 部署到这些 Web 容器之一 

是 

Access Manager Distributed Authentication 

Access Manager 

提供底层 Access Manager 服务 

否 

J2EE Web 容器，以下产品之一： 

-Application Server； 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

必须将 Access Manager SDK 部署到这些 Web 容器之一 

是 

Access Manager Session Failover 

Access Manager 

提供底层 Access Manager 服务 

否 

Message Queue 

提供可靠的异步消息传送 

否 

Application Server

Message Queue

提供可靠的异步消息传送 

是 
 

Web Server（可选）

在各 Application Server 实例间提供负载平衡 

是 
 

High Availability Session Store（可选）

存储会话状态，它支持 Application Server 实例之间的故障转移 

是 

Directory Proxy Server

Directory Server 

提供底层 LDAP 目录服务 

否 

Directory Server

无 

   

High Availability Session Store 

无 

   

Java DB 

无 

   

Message Queue 

Directory Server（可选） 

存储受管对象和持久性消息 

否 
 

J2EE Web 容器，下面两项之一（可选）：

-Application Server； 

-Web Server 

支持客户机与 Message Broker 之间的 HTTP 传输 

否 
 

Sun Cluster（可选） 

支持在高可用性解决方案中使用 Message Queue 

否 

Portal Server

J2EE Web 容器，以下产品之一：

-Application Server； 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

必须将 Portal Server 部署到这些 Web 容器之一 

是 
 

Directory Server 

存储用于验证和授权的用户数据 

否 
 

Access Manager 或 Access Manager SDK 

提供 Access Manager 服务；本地 Access Manager SDK 提供对远程 Access Manager 的访问 

是 
 

Service Registry Client 

提供进行编译所需的库 

否 

Portal Server Secure Remote Access

Portal Server 

提供底层门户服务。 

否 
 

Access Manager 或 Access Manager SDK 

提供 Access Manager 服务；本地 Access Manager SDK 提供对远程 Access Manager 的访问 

是 

Rewriter Proxy 

Portal Server 

提供底层门户服务。 

否 

Netlet Proxy 

Portal Server 

提供底层门户服务。 

否 

Service Registry 

Application Server 

提供必要的容器服务。 

是 

Service Registry Client 

提供必要的客户机接口 

是 

Service Registry Client 

无 

   

Sun Cluster 软件 

无 

   

Sun Cluster 代理

Sun Cluster 

提供底层群集服务。 

是 

Sun Cluster Geographic Edition 

Sun Cluster 

提供底层群集服务。 

是 

Web Proxy Server

Web Server 

提供对 Web Server 上运行的 Web 应用程序的远程访问 

是 

Directory Server（可选） 

存储用于验证和授权的用户数据 

否 

Web Server 

Directory Server（可选） 

存储用于验证和授权的用户数据 

否 

配置为交互操作

安装和配置过程的目标是实现一个交互操作组件实例系统。由于您每次在一台计算机上安装组件并执行基本配置，因此必须预先确定能够实现与其他计算机上的组件成功进行交互操作的配置值。

实现交互操作的配置值包括一个组件实例用来与另一个组件实例进行通信的值，如 URL 或端口号。例如，如果您的解决方案使用 Access Manager，则必须首先安装并配置一个 LDAP 系统信息库，如 Directory Server 实例。然后，在安装和配置 Access Manager 实例时，您必须提供将 Access Manager 配置为与已安装并配置的 LDAP 目录进行交互操作的值。

Java ES 安装程序不知道解决方案中使用的其他计算机上安装了哪些组件。例如，在安装 Access Manager 时，安装程序并不知道相应 LDAP 目录的位置。为确保安装和配置过程能够成功，您必须预先确定哪些安装和配置值能够实现 Access Manager 实例与 Directory Server 实例之间成功地进行交互操作。将这些值包括在您的安装规划中。然后，在安装和配置组件时，键入规划中的值，即可成功地将您的组件配置为可以相互进行交互操作。

您可能要执行类似于图 3–2 中所示的一系列安装和配置任务。

图 3–2 将组件配置为交互操作

计算机 01：Directory Server。计算机 02：安装 Access Manager 并将其配置为能够与计算机 01 上的 Directory Server 实例交互操作。

无论您的解决方案的体系结构如何，所制定的安装规划必须包括配置各个组件所需的所有配置值，并最终形成一个交互操作的分布式解决方案。

冗余策略

大多数为生产方面所使用的解决方案都包括某一类型的冗余。冗余策略将使用一个组件的多个实例来提供单一服务。使用冗余的目的是满足服务质量要求。例如，使用冗余来增加吞吐量从而满足性能要求，或者使用冗余来避免出现单一故障点从而满足可靠性要求。

在使用 Java ES 组件的冗余实例时提供了三种策略：负载平衡、通过 Sun Cluster 软件建立群集及 Directory Server 复制。以下几段简要概述了针对每一种策略所建议的安装和配置过程：

如果您的部署体系结构使用上述任何一个冗余策略，则安装规划必须包括用于安装一个组件的多个实例并将这些实例配置成作为单一服务运行的过程。

LDAP 模式和 LDAP 目录树结构

大多数 Java ES 解决方案都包括 Directory Server。在安装和配置包括 Directory Server 的解决方案时，您需要输入用于建立目录模式和目录树结构的值。您的安装规划中必须列出能够生成正确的 LDAP 模式和目录树结构的输入值。

您要在开始安装规划之前指定 LDAP 模式和目录树结构。您的安装规划包括运行安装程序创建指定的模式和目录树结构时键入的值。有关模式和目录树规范的示例，参见制定用户管理规范。

LDAP 模式通过以下安装和配置过程来建立：

  1. 安装 Directory Server 时会自动建立模式 1 的目录。选择该模式无需任何输入。

  2. 安装 Access Manager 时会自动修改该目录，将其转换为模式 2。选择该模式无需任何输入。

  3. 在包括 Communications Suite 组件的解决方案中，运行 Directory Preparation Tool 会扩展模式，以与 Messaging Server、Calendar Server 和 Communications Express 配合使用。Directory Preparation Tool 可扩展模式 1 目录和模式 2 目录二者。Directory Preparation Tool 的输入值列在您的安装规划中。

  4. 在包括 Communications Suite 组件的解决方案中，运行 Delegated Administrator 可通过用于对用户进行授权和验证以使用特定服务的对象类和属性来扩展模式。输入值取决于解决方案要提供的服务。在您的安装规划中列出输入值。

安装和配置过程还会建立基本的目录树结构：

  1. 安装 Directory Server 将创建基本后缀（或目录树的根）。在 Java ES 安装程序安装 Directory Server 时，基本后缀是一个必需的输入值。在您的安装规划中，将基本后缀列为安装过程的输入值之一。

  2. 安装和配置 Messaging Server 将使目录树分支并创建一个 LDAP 组织。此组织代表受 Messaging Server 实例管理的电子邮件域。组织的名称是 Messaging Server 配置向导所要求的一个输入项。在您的安装规划中，将组织 DN 列为 Messaging Server 配置过程的输入值之一。

  3. 安装和配置 Calendar Server、Communications Express、Delegated Administrator 和 Instant Messaging 时指定这些组件应在目录中的什么位置查找用户数据。LDAP DN 是每个组件配置向导都要求的输入项，因此在您的安装规划中，应将该 DN 列为每个配置向导的一个输入值。如果解决方案使用 Access Manager 单点登录，必须配置所有这些组件都使用同一位置查找用户数据，即 Messaging Server 配置向导创建的组织。在所有这些配置向导中将输入相同的 LDAP DN。在您的安装规划中，将组织 DN 列为所有配置向导的输入值之一。

从用户管理规范获取 LDAP 基本后缀和电子邮件域组织的名称，并将它们添加到安装规划中。有关用户管理规范的更多信息，参见制定用户管理规范。

Java ES 安装程序行为

本节介绍 Java ES 安装程序的一些会影响安装规划的行为。

安装程序是本地的

Java ES 安装程序每次在一台计算机上安装组件软件。大部分解决方案是分布式的，因此您必须多次运行安装程序。您的安装规划中必须包括每次运行安装程序的过程。本节介绍如何对部署体系结构进行分析以及如何确定必须运行多少次安装程序才能实现体系结构。

有几种解决方案仅安装在一台计算机上，这些解决方案的安装规划提供了仅运行一次安装程序的过程。以下解决方案仅需运行安装程序一次：

大多数解决方案需要分布在若干计算机上。在这些解决方案的安装规划中必须说明：需要运行安装程序多次才能安装和配置完整的解决方案。要分析这些解决方案，请遵守以下指导原则：

本节的目的在于引入一个概念，即在安装规划中有时必须说明是在一台计算机上运行安装程序和配置向导，还是在一台计算机上运行安装程序多次。有关不同组件组合实际安装过程的更多信息，参见制定安装规划。

安装程序操作模式

安装程序在两种不同的模式下运行，这两种模式称为“现在配置”和“以后再配置”。这两个模式有以下区别：

所选择的配置选项将应用于整个安装会话。如果要以“现在配置”模式在计算机上安装某些组件，并以“以后再配置”模式安装其他一些组件，必须多次运行安装程序。

安装程序的兼容性检查

Java ES 安装程序会执行一些依存关系和兼容性检查，但它只能检查本地计算机。例如，如果安装的是分布式解决方案中的 Access Manager，安装程序无法检查远程 Directory Server 是否与所安装的 Access Manager 兼容。

如果要安装和配置全新的解决方案，由于所有组件均来自同一 Java ES 发行版本，因此不太可能存在兼容性问题。如果是在已建立的解决方案中添加新组件，或围绕现有组件构建 Java ES 解决方案，兼容性可能会成为问题。例如，如果您已在使用 Directory Server，并且正在使用 Access Manager 和 Portal Server 围绕现有 Directory Server 建立解决方案，这些组件之间的兼容性便会成为问题。开始安装和配置新组件之前，需要确认这些组件是兼容的。

其他安装问题

本节列出了在一些解决方案中出现的许多具体问题，同时还提供了有关详细信息的参考。

表 3–2 需要考虑的安装问题

解决方案要求 

指导或说明 

使用 Solaris 10 区域 

如果要安装到 Solaris 10 区域中，参阅附录 A，Java ES 和 Solaris 10 区域。

使用 Directory Server 加密 

在 Directory Server 实例上配置 LDAPS（SSL over LDAP，基于 LDAP 的 SSL） 。 

对 Access Manager 使用第三方 Web 容器

第三方 Web 容器（BEA WebLogic Server 或 IBM WebSphere Application Server）可以和 Portal Server 及 Access Manager 配合使用。必须首先安装和运行这些容器，然后才能安装任何依赖于这些容器的 Java ES 组件。

要对 Access Manager SDK 使用第三方 Web 容器，必须在安装后手动配置 Access Manager SDK。参见《适用于 UNIX 的 Sun Java Enterprise System 5 安装指南》中的“具有容器配置的 Access Manager SDK 示例”

注：Portal Server 只能在 Solaris OS 上使用第三方 Web 容器。 

注：Access Manager 和 Portal Server 应使用相同的 Web 容器。 

将 Apache Web Server 用于负载平衡插件

Apache Web Server 可与 Application Server 负载平衡插件配合使用。在这种情况下，必须首先安装和配置 Apache Web Server，然后才能安装任何依赖于它的 Java ES 组件。 

使用模式 1 LDAP

对于模式 1 部署，不能使用 Access Manager。 

配置单个用户条目和单点登录

对于单点登录，Access Manager 是必需的。 

使用 HADB 配置高可用性 

有关设置 HADB 以实现高可用性的过程概述，参见《适用于 UNIX 的 Sun Java Enterprise System 5 安装指南》中的“Web 和应用程序服务示例”。

Application Server 负载平衡 

有关使用 Application Server 负载平衡插件的过程概述，参见《适用于 UNIX 的 Sun Java Enterprise System 5 安装指南》中的“Web 和应用程序服务示例”。

非超级用户所有权 

如果 Application Server 或 Web Server 需要非超级用户所有权，参阅《适用于 UNIX 的 Sun Java Enterprise System 5 安装指南》中的“非超级用户示例”

制定安装规划

您的部署体系结构和实现规范应描述解决方案的最终状态。部署体系结构说明安装的组件实例数目、组件实例安装在哪些计算机系统上以及组件实例交互操作的方式。要达到部署体系结构中描述的状态，必须在您的解决方案中安装并配置这些组件实例，每次安装一个计算机系统，直到完成安装和配置整个解决方案为止。 您的安装规划必须以正确顺序提供解决方案中每个组件实例的安装和配置过程。

要制定安装和配置规划，必须在 Java ES 部署体系结构与实现规范中考虑您所了解的组件依赖性及其他安装问题。必须确定安装和配置解决方案中各组件实例的正确顺序，以及正确的安装和配置输入值，这些值用于实现组件实例的交互操作。

本节将指导您分析部署体系结构和实现规范，进而制定安装规划。概括地说，您可按如下步骤开始：

  1. 打开一个文本文件，准备一张白纸或其他介质以记录您的规划。

  2. 在您的部署体系结构中，检查每个计算机系统上的组件并确定存在哪些组件依赖性。

  3. 确定那些不依赖于其他组件的组件实例。这些通常是 Directory Server 实例。您的安装规划首先应说明如何在指定计算机系统上安装这些实例。通过记录这些计算机系统和在这些系统上安装的组件实例，开始您的安装规划。

  4. 为解决方案中这些特定计算机系统上的这些组件实例确定正确的安装/配置值。将这些配置值添加到您的安装规划中。

  5. 确定余下的组件中有哪些组件仅依赖于 Directory Server。它们通常是具有 Access Manager 的计算机系统。接下来在您的安装规划中列出这些计算机系统。

  6. 按照组件依赖性的顺序，继续分析您的规范。确定必需的配置值，并在您的规划中记录这些组件实例。

例如，如果您使用此过程分析图 2–1 中所示的部署体系结构，则需要制定与表 3–3 相似的安装规划。

表 3–3 说明了安装规划的前八个步骤。为了使此规划的体系结构显得有条理，没有列出各个配置值。在本规划中，请注意下列事项：

表 3–3 样例部署体系结构的概要安装规划

计算机 

安装和配置任务 

DS1

  1. 在此计算机上运行 Java ES 安装程序。使用在用户管理规范中指定的配置值，安装并配置 Directory Server 实例。

  2. 启动和检验 Directory Server 实例。

DS2 

  1. 在此计算机上运行 Java ES 安装程序。使用在用户管理规范中指定的配置值，安装并配置 Directory Server 实例。

  2. 启动和检验 Directory Server 实例。

  3. 检验负载平衡器对于这两个 Directory Server 实例是否都能正常起作用。

  4. 关闭 DS2 中的 Directory Server 实例。保持 DS1 中 Directory Server 实例的运行状态。

AM1 

  1. 在此计算机上运行 Java ES 安装程序。安装并配置 Access Manager 实例。配置 Access Manager 实例，使其与通过负载经平衡的 Directory Server 实例创建的逻辑目录服务交互操作。

  2. 启动和检验 Access Manager 实例。

  3. 配置 Access Manager 实例以实现负载平衡。

AM2 

  1. 在此计算机上运行 Java ES 安装程序。安装并配置 Access Manager 实例。配置 Access Manager 实例，使其与通过负载经平衡的 Directory Server 实例创建的逻辑目录服务交互操作。

  2. 启动和检验 Access Manager 实例。

  3. 配置 Access Manager 实例以实现负载平衡。

  4. 使用 Access Manager 控制台修改 Access Manager 的目录条目。

  5. 检验这两个 Access Manager 实例对于负载经平衡的操作是否能正常起作用。

STR1 

  1. 运行 Java ES 安装程序。安装 Sun Cluster Core 组件。

  2. 准备计算机以便进行 Sun Cluster 配置。此步骤包括创建和挂载 Sun Cluster 软件所使用的文件系统。

  3. 运行 Sun Cluster 配置向导。建立和配置群集。

STR2 

  1. 运行 Java ES 安装程序。安装 Sun Cluster Core 组件。

  2. 准备计算机以便进行 Sun Cluster 配置。此步骤包括创建和挂载 Sun Cluster 软件所使用的文件系统。

  3. 运行 Sun Cluster 配置向导。建立和配置群集。

  4. 在 STR1 和 STR2 上完成网络时间协议 (Network Timing Protocol, NTP) 的配置。

  5. 将法定设备添加到群集中（连接到这两台计算机）。

  6. 创建群集文件系统和资源组，设置虚拟主机名和 IP 地址。

  7. 检验群集的故障转移功能。

STR1 

  1. 运行 Java ES 安装程序。安装 Messaging Server 和 Calendar Server。

  2. 在计算机 DS1 上，运行 Directory Server Preparation Tool。

  3. 运行 Messaging Server 配置向导以创建一个 Messaging Server 实例。根据用户管理规范，提供可在 LDAP 目录树中创建分支的配置值。提供可配置 Messaging Server 实例使其与负载经平衡的 Access Manager 实例和负载经平衡的 Directory Server 实例交互操作的配置值。

  4. 配置 Messaging Server 以实现单点登录。

  5. 启动和检验 Messaging Server 实例。

  6. 运行 Calendar Server 配置向导以创建一个 Calendar Server 实例。提供配置该实例的配置值，以便其能够使用由 Messaging Server 配置为用户和组数据创建的 LDAP 分支。提供可配置 Calendar Server 实例使其与负载经平衡的 Access Manager 实例和负载经平衡的 Directory Server 实例交互操作的配置值。

  7. 在计算机 STR2 上，创建 Calendar Server 用户、用户组和目录。

  8. 编辑 Calendar Server 配置文件。设置配置参数，以使用虚拟 IP 地址而不是计算机的 IP 地址。

  9. 配置 Calendar Server 以实现单点登录。

  10. 启动和检验 Calendar Server 实例。

STR1 

  1. 运行 Java ES 安装程序。分别为 Messaging Server 和 Calendar Server 安装 Sun Cluster 代理。

  2. 使用 Messaging Server 代理创建并启用 Messaging Server 资源。

  3. 检验 Messaging Server 资源从 STR1 到 STR2 的故障转移。

  4. 使用 Calendar Server 代理创建并启用 Calendar Server 资源。

  5. 检验 Calendar Server 资源从 STR1 到 STR2 的故障转移。

STR2 

您在 mscs01 上创建的实例被自动识别为共享资源。