test

Sun Java System Application Server 9.1 部署规划指南

第 1 章 产品概念

Sun Java System Application Server 为 J2EE 应用程序开发、部署和管理提供了一个强健的平台。其主要功能包括可伸缩的事务管理、容器管理的持久性运行时、Web 服务性能、群集、高可用性会话状态、安全性和集成功能。

本节包含以下主题：

J2EE 平台概述

Application Server 实现了 Java 2 Enterprise Edition (J2EE) 1.4 技术。J2EE 平台是一组标准规范，它们描述了应用服务器的应用程序组件、API 以及运行时容器和服务。

J2EE 应用程序

J2EE 应用程序由一些组件组成，例如 JavaServer Pages (JSP)、Java Servlet 和 Enterprise JavaBeans (EJB) 模块。软件开发者可以通过这些组件来构建大型分布式应用程序。开发者将 J2EE 应用程序打包在 Java 归档 (Java Archive, JAR) 文件（类似于 zip 文件）中，这些文件可以分发到生产站点。管理员通过将 J2EE JAR 文件部署到一个或多个 Application Server 实例（或实例群集）中，在该服务器上安装 J2EE 应用程序。

下图展示了在以下各节中介绍的 J2EE 平台组件。

抱歉：图形当前不可用。

容器

每个服务器实例包含两个容器：Web 和 EJB。容器是一种运行时环境，它为 J2EE 组件提供服务（如安全性和事务管理）。Web 组件（如 Java Server Pages 和 Servlet）在 Web 容器内运行。Enterprise JavaBeans 在 EJB 容器内运行。

J2EE 服务

J2EE 平台为应用程序提供了一些服务，其中包括：

Web 服务

除了通过 HTTP、RMI/IIOP 和 JMS 访问 J2EE 1.4 应用程序外，客户机还可以将其作为远程 Web 服务进行访问。Web 服务是使用 Java API for XML-based RPC (JAX-RPC) 实现的。J2EE 应用程序还可以作为 Web 服务的客户机，这在网络应用程序中是很常见的。

Web 服务描述语言 (Web Services Description Language, WSDL) 是一种描述 Web 服务接口的 XML 格式。Web 服务使用者可以动态地解析 WSDL 文档以确定 Web 服务提供的操作以及如何执行这些操作。Application Server 使用注册表分发 Web 服务接口描述，其他应用程序可通过 Java API for XML Registries (JAXR) 访问该注册表。

客户机访问

客户机可使用多种方法来访问 J2EE 应用程序。浏览器客户机使用超文本传输协议 (Hypertext Transfer Protocol, HTTP) 访问 Web 应用程序。对于安全通信，浏览器使用的是采用安全套接字层 (Secure Sockets Layer, SSL) 的 HTTP 安全 (HTTPS) 协议。

应用程序客户机容器中运行的丰富客户机应用程序可以使用对象请求代理 (Object Request Broker, ORB)、远程方法调用 (Remote Method Invocation, RMI) 和 Internet 对象请求代理间协议 (Internet Inter-ORB Protocol, IIOP) 或 IIOP/SSL（安全 IIOP）直接查找和访问 Enterprise JavaBeans；使用 HTTP/HTTPS、JMS 和 JAX-RPC 访问应用程序和 Web 服务；以及使用 JMS 向应用程序和消息驱动 Bean 发送消息并从中接收消息。

符合 Web 服务互操作性 (Web Services-Interoperability, WS-I) 基本配置文件的客户机可以访问 J2EE Web 服务。WS-I 是 J2EE 标准不可或缺的组成部分，它定义了可互操作的 Web 服务。用任何支持语言编写的客户机都可通过它访问 Application Server 上部署的 Web 服务。

最佳的访问机制取决于特定应用程序和预期通信量。Application Server 支持可为 HTTP、HTTPS、JMS、IIOP 和 IIOP/SSL 单独配置的侦听器。您可以为每种协议设置多个侦听器，以便提高可伸缩性和可靠性。

J2EE 应用程序还可以用作 J2EE 组件（如其他服务器上部署的 Enterprise JavaBeans 模块）的客户机，并且可以使用其中的任何访问机制。

外部系统和资源

在 J2EE 平台上，外部系统称为资源。例如，数据库管理系统就是一种 JDBC 资源。每种资源是按其 Java Naming and Directory Interface (JNDI) 名称进行唯一标识的。应用程序通过以下 API 和组件来访问外部系统：

Application Server 组件

本节介绍了 Sun Java System Application Server 中的组件：

下图展示了这些 Application Server 组件如何使用提供高可用性的简单示例拓扑进行交互。在此示例拓扑中，一个管理员管理两台组成群集的计算机。HADB 和 Application Server 进程位于同一台计算机上。域管理服务器本身可能位于单独的计算机上，也可能位于承载应用服务器实例的任一计算机上。图表中的线表示通信或控制。

管理工具（如基于浏览器的管理控制台）与域管理服务器 (Domain Administration Server, DAS) 进行通信，后者又与节点代理和服务器实例进行通信。

服务器实例

服务器实例是在单个 Java 虚拟机 (Java Virtual Machine, JVM) 进程中运行的 Application Server。Application Server 已通过 Java 2 Standard Edition (J2SE) 5.0 和 1.4 认证。Application Server 安装中包含建议的 J2SE 分发包。

通常，在计算机上创建单个服务器实例就足够了，因为 Application Server 和附带的 JVM 均可扩展到多个处理器。但是，如果在一台计算机上创建多个实例，则将非常有益于进行应用程序隔离和滚动升级。在某些情况下，可以在多个管理域中使用具有多个实例的大型服务器。管理工具可简化在多台计算机中创建、删除和管理服务器实例的过程。

管理域

管理域（或简称域）是一组统一管理的服务器实例。服务器实例属于单个管理域。域中的实例可以在不同的物理主机上运行。

您可以从某个 Application Server 安装中创建多个域。通过将服务器实例分组到域中，不同的组织和管理员可以共享单个 Application Server 安装。每个域都有自己的独立于其他域的配置、日志文件和应用程序部署区域。更改某个域的配置不会影响其他域的配置。同样，在某个域上部署应用程序不会将其部署到任何其他域，或在任何其他域中显示该应用程序。在任何给定时间，管理员只能通过一个域的验证，因而只能在该域中执行管理操作。

域管理服务器 (Domain Administration Server, DAS)

每个域都具有一个域管理服务器 (Domain Administration Server, DAS)，这一特别指定的应用服务器实例用于承载管理应用程序。DAS 会对管理员进行验证，接受来自管理工具的请求，并与域中的服务器实例进行通信以执行请求。

管理工具是指 asadmin 命令行工具，即基于浏览器的管理控制台。Application Server 还提供了基于 JMX 的 API 以进行服务器管理。管理员每次只能查看和管理单个域，从而强制进行安全分离。

DAS 有时也称为管理服务器或默认服务器。之所以称为默认服务器是因为，它是某些管理操作的默认目标。

由于 DAS 是一个应用服务器实例，因此，它也可以承载用于测试的 J2EE 应用程序。但是，不要使用它来承载生产应用程序。例如，如果尚未创建用于承载生产应用程序的群集和实例，您可能希望将应用程序部署到 DAS 中。

DAS 保存一个系统信息库，其中包含其域和部署的所有应用程序的配置。如果 DAS 处于不活动状态或出现故障，则将不会影响活动服务器实例的性能或可用性，但无法进行管理更改。在某些情况下，为了安全起见，有意地停止 DAS 进程可能是非常有用的；例如，停止 DAS 进程以冻结生产配置。

系统提供了一些管理命令，用于备份和恢复域配置和应用程序。通过使用标准的备份和恢复步骤，您可以快速恢复工作配置。如果 DAS 主机出现故障，您必须创建新的 DAS 安装才能恢复以前的域配置。有关说明，请参见《Sun Java System Application Server 9.1 管理指南》中的“重新创建域管理服务器”。

Sun Cluster 数据服务通过转移 DAS 主机 IP 地址故障和使用全局文件系统来提供高可用性的 DAS。这种解决方案提供了几乎持续可用的 DAS 和系统信息库，从而避免出现多种类型的故障。Sun Cluster Data Services 随 Sun Java Enterprise System 附带提供，也可以与 Sun Cluster 一起另行购买。有关更多信息，请参见 Sun Cluster Data Services 文档。

群集

群集是命名的服务器实例集合，这些实例共享相同的应用程序、资源以及配置信息。您可以将不同计算机上的服务器实例分组到一个逻辑群集中并将其作为一个单元来管理。您可以使用 DAS 轻松控制多机群集的生命周期。

群集可以实现水平可伸缩性、负载平衡和故障转移保护。根据定义，群集中的所有实例都具有相同的资源和应用程序配置。当群集中的服务器实例或计算机出现故障时，负载平衡器检测到该故障，会将通信从出现故障的实例重定向至群集中的其他实例，并恢复用户会话状态。由于群集中所有实例上的应用程序和资源都相同，因此一个实例可以故障转移至群集中的任何其他实例。

群集、域和实例是相关的，如下所示：

节点代理

节点代理是一个轻量级进程，它在每台承载服务器实例的计算机上运行，其中包括承载 DAS 的计算机。节点代理：

每个物理主机对其所属的每个域都必须至少具有一个节点代理。如果物理主机包含来自多个域的实例，则每个域需要有一个节点代理。虽然允许在主机上为每个域设置多个节点代理，但这样做并没有什么好处。

因为节点代理用于启动和停止服务器实例，所以它必须始终保持运行。因此，在操作系统引导时，将启动该代理。在 Solaris 和其他 Unix 平台上，可通过 inetd 进程来启动节点代理。在 Windows 上，可以将节点代理指定为 Windows 服务。

有关节点代理的更多信息，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 8  章 “配置节点代理”。

命名配置

命名配置是一个抽象概念，用于封装 Application Server 属性设置。群集和独立服务器实例引用命名配置以获取其属性设置。通过使用命名配置，J2EE 容器的配置独立于其所在的物理计算机，但特定细节除外，例如 IP 地址、端口号以及堆内存量。使用命名配置可以为 Application Server 管理提供强大的功能和较高的灵活性。

要应用配置更改，只需更改命名配置的属性设置，这样引用它的所有群集和独立实例便可获取更改。仅当删除了对命名配置的所有引用后，才能删除该命名配置。每个域可以包含多个命名配置。

Application Server 附带提供一个名为 default-config 的默认配置。该默认配置已进行了优化，以便在 Application Server Platform Edition 中提高开发者的生产效率以及在 Application Server Enterprise Edition 中提供较高的安全性和可用性。

您可以根据该默认配置创建自己的命名配置，并根据自身需要对其进行自定义。请使用管理控制台和 asadmin 命令行实用程序来创建和管理命名配置。

HTTP 负载平衡器插件

负载平衡器可以在多个物理计算机中分配工作负载，从而提高系统的整体吞吐量。Application Server Enterprise Edition 包含用于 Sun Java System Web Server、Apache Web Server 以及 Microsoft Internet Information Server 的负载平衡器插件。

负载平衡器插件接受 HTTP 和 HTTPS 请求，然后将请求转发到群集中的某个应用服务器实例。如果某个实例出现故障、变得不可用（由于网络故障）或无法响应，则会将请求重定向到现有的可用计算机。负载平衡器还可识别故障实例何时恢复并相应地重新分配负载。

对于简单的无状态应用程序，一个负载平衡群集可能就足够了。但是，对于具有会话状态的重点应用程序，请将负载平衡群集与 HADB 一起使用。

要为系统设置负载平衡，除了 Application Server 以外，还必须安装 Web 服务器和负载平衡器插件。然后，您必须：

参与负载平衡的服务器实例和群集必须具有同构环境。通常，这意味着服务器实例均引用相同的服务器配置、可以访问相同的物理资源，以及具有部署到其上的相同的应用程序。同构环境确保了在出现故障前后，负载平衡器可以始终在群集中的活动实例之间平均分配负载。

可以使用 asadmin 命令行工具来创建负载平衡器配置，将对群集和服务器实例的引用添加到该配置中，启用负载平衡器对群集的引用，为应用程序启用负载平衡，选择创建运行状况检查器，生成负载平衡器配置文件，最后将负载平衡器配置文件复制到 Web 服务器的 config 目录中。管理员可以创建脚本以自动完成整个过程。

有关更多详细信息以及完整的配置说明，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 5  章 “配置 HTTP 负载平衡”。

会话持久性

J2EE 应用程序通常具有大量会话状态数据。Web 购物车是会话状态的一个典型示例。此外，应用程序可以高速缓存会话对象中需要频繁使用的数据。事实上，几乎所有包含大量用户交互的应用程序都需要保留会话状态。HTTP 会话和有状态会话 Bean (Stateful Session Bean, SFSB) 均包含会话状态数据。

虽然会话状态没有存储在数据库中的事务状态那样重要，但对于最终用户来说，在出现服务器故障时保留会话状态是非常有必要的。Application Server 提供了在系统信息库中保存或保留此会话状态的功能。如果承载用户会话的应用服务器实例出现故障，则可以恢复会话状态。会话可以继续进行，而不会丢失信息。

Application Server 支持以下类型的会话持久性存储：

利用内存持久性，状态可始终保存在内存中，但会在出现故障时丢失。利用 HA 持久性，Application Server 可将 HADB 用作 HTTP 和 SFSB 会话的持久性存储。利用文件持久性，Application Server 可序列化会话对象，并将其存储到由会话管理器属性指定的文件系统位置。对于 SFSB，如果未指定 HA，则 Application Server 会将状态信息存储在此位置的 session-store 子目录中。

对需要保存的 SFSB 状态更改进行检查称为检查点操作。如果启用检查点操作，则通常会在完成任何涉及 SFSB 的事务之后（即使该事务回滚）执行该操作。有关开发有状态会话 Bean 的更多信息，请参见《Sun Java System Application Server 9.1 Developer’s Guide》中的“Using Session Beans”。有关启用 SFSB 故障转移的更多信息，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的“有状态会话 Bean 故障转移”。

除了 Application Server 正在处理的请求数以外，会话持久性配置设置还会影响 HADB 每分钟收到的请求数以及每个请求中的会话信息。

有关配置会话持久性的更多信息，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 9  章 “配置高可用性会话持久性和故障转移”。

群集中的 IIOP 负载平衡

利用 IIOP 负载平衡，可以将 IIOP 客户机请求分配到不同的服务器实例或名称服务器。目标是将负载平均分布在群集中，从而提供可伸缩性。通过结合使用 IIOP 负载平衡以及 Sun Java System Application Server 中的 EJB 群集和可用性功能，不仅可以提供负载平衡，而且还可以提供 EJB 故障转移。

当客户机对某个对象执行 JNDI 查找时，命名服务会创建一个与特定服务器实例关联的 InitialContext (IC) 对象。从此时起，使用该 IC 对象进行的所有查找请求都会发送给相同的服务器实例。使用该 InitialContext 查找的所有 EJBHome 对象都托管在相同的目标服务器上。此后获得的所有 Bean 引用也创建在相同的目标主机上。这就有效地提供了负载平衡，原因是所有客户机都在创建 InitialContext 对象时随机使用动态目标服务器的列表。如果目标服务器实例发生故障，查找或 EJB 方法调用会将故障转移到另一个服务器实例。

例如，图中显示的 ic1、ic2 和 ic3 是在 Client2 的代码中创建的三个不同 InitialContext 实例。它们将被分配到群集的三个服务器实例中。因而，此客户机创建的 Enterprise JavaBeans 便会随之分布到这三个实例中。Client1 仅创建一个 InitialContext 对象，并且来自此客户机的 Bean 引用仅位于服务器实例 1 上。如果服务器实例 2 出现故障，ic2 上的查找请求会将故障转移到另一个服务器实例（不一定是服务器实例 3）。对于服务器实例 2 上以前承载的 Bean，还会自动将对其进行的任何 Bean 方法调用重定向到另一个实例（如果此操作安全）。虽然查找故障转移是自动完成的，但 Enterprise JavaBeans 模块将仅在安全时才重试方法调用。

IIOP 负载平衡和故障转移将透明地发生。在应用程序部署过程中无需特殊的步骤。在群集中添加或删除新实例将不会更新该群集的现有客户机视图。您必须在客户端手动更新端点列表。

消息队列和 JMS 资源

Sun Java System Message Queue (MQ) 为分布式应用程序提供了可靠的异步消息传送功能。MQ 是一个企业消息传送系统，它实现了 Java 消息服务 (Java Message Service, JMS) 标准。MQ 为 J2EE 应用程序组件提供了消息传送功能，例如，消息驱动 Bean (Message-Driven Bean, MDB)。

Application Server 通过集成 Sun Java System Message Queue 来实现 Java 消息服务 (Java Message Service, JMS) API。Application Server Enterprise Edition 包含 MQ 企业版，该版本具有故障转移、群集和负载平衡功能。

对于基本 JMS 管理任务，请使用 Application Server 管理控制台和 asadmin 命令行实用程序。

对于高级任务（包括管理 Message Queue 群集），请使用 install_dir/imq/bin 目录中提供的工具。有关管理 Message Queue 的详细信息，请参见 Sun Java System Message Queue 管理指南。

有关部署 JMS 应用程序和 MQ 群集以进行消息故障转移的信息，请参见Message Queue 代理部署规划。

高可用性数据库

本节包括以下主题：

概述

前面的会话持久性中介绍了 J2EE 应用程序的会话持久性需求。Application Server 将高可用性数据库 (High-Availability Database, HADB) 用作高可用性的会话存储。HADB 包含在 Application Server Enterprise Edition 中，但部署后，可以在单独的主机上运行。HADB 为 HTTP 会话和有状态会话 Bean 数据提供了高可用性的数据存储。

这种分离的体系结构具有以下优点：

注 –

HADB 进行了优化以便 Application Server 使用，但不能作为通用数据库供应用程序使用。

有关 HADB 硬件和网络系统要求，请参见《Sun Java System Application Server 9.1 发行说明》中的“硬件和软件要求”。有关 HADB 所需的其他系统配置步骤，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 2  章 “安装和设置高可用性数据库”。

系统要求

HADB 主机的系统要求如下：

有关网络配置要求，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 2  章 “安装和设置高可用性数据库”。有关高可用性的其他要求，请参见减小双故障风险。

HADB 体系结构

HADB 是由节点对组成的分布式系统。节点将划分到两个数据冗余单元 (Data Redundancy Unit, DRU) 中，每个 DRU 包含每对节点中的一个节点，如数据冗余单元中所述。

每个节点包含：

一组 HADB 节点可以承载一个或多个会话数据库。每个会话数据库与一个特定的应用服务器群集相关联。在删除群集时，还会删除与其关联的会话数据库。

有关 HADB 硬件要求，请参见《Sun Java System Application Server 9.1 发行说明》中的“硬件和软件要求”。

节点和节点进程

共有两种类型的 HADB 节点：

每个节点包含一个父进程和几个子进程。父进程称为节点监控 (NSUP)，由管理代理启动。它负责创建子进程并使它们保持运行。

子进程可以是：

数据冗余单元

如前面所述，HADB 实例包含一对 DRU。每对中的两个 DRU 具有相同的活动节点数和备用节点数。一个 DRU 中的每个活动节点在另一个 DRU 中具有镜像节点。由于进行了镜像，每个 DRU 都包含完整的数据库副本。

下图显示了一个包含 6 个节点的示例 HADB 体系结构：四个活动节点和两个备用节点。节点 0 和 1 是一个镜像对，节点 2 和 3 也是一个镜像对。在此示例中，每个主机有一个节点。通常，如果主机具备足够的系统资源（请参见系统要求），则它可以有多个节点。

注 –

必须成对添加承载 HADB 节点的计算机，每个 DRU 中各有一台计算机。

HADB 可通过复制数据和服务来获得高可用性。可以将镜像节点上的数据副本指定为主副本和热备用副本。主副本执行插入、删除、更新以及读取等操作。热备用副本接收主副本操作的日志记录，并在事务生命周期内重复执行这些操作。读取操作仅由主节点执行，因而不会记录这些操作。每个节点同时包含主副本和热备用副本，并担当这两种角色。数据库将进行分段并分配到 DRU 的活动节点中。镜像对中的每个节点包含一组相同的数据分段。复制镜像节点上的数据称为复制。HADB 可通过复制来提供高可用性：当某个节点出现故障时，其镜像节点几乎立即接管该节点的功能（在几秒钟内）。复制可确保高可用性，并且屏蔽节点故障或 DRU 故障，而不会丢失数据或服务。

当镜像节点接管出现故障的节点的功能时，它必须完成双倍的任务量：其自己的任务和出现故障的节点的任务。如果镜像节点不具备足够的资源，过多的负载会降低其性能，并增大出现故障的可能性。当节点出现故障时，HADB 会尝试重新启动它。如果无法重新启动出现故障的节点（例如，由于硬件故障），则系统将继续运行，但会降低可用性。

HADB 容许整个 DRU、一个或多个节点出现故障，但不容许出现“双故障”，即节点及其镜像均出现故障。有关如何减小出现双故障的可能性的信息，请参见减小双故障风险。

备用节点

当某个节点出现故障时，其镜像节点将接管该节点的功能。如果出现故障的节点没有备用节点，则此时它将没有镜像。备用节点自动接替出现故障的节点的镜像。通过设置备用节点，可以缩短系统在没有镜像节点的情况下运行的时间。

备用节点通常不包含数据，但会持续监视 DRU 中活动节点的故障情况。如果某个节点出现故障并且在指定的超时期限内未能恢复，备用节点将从镜像节点中复制数据并与其进行同步。所花的时间取决于复制的数据量以及系统和网络能力。在进行同步后，备用节点将自动接替镜像节点，而无需手动介入，从而减轻了镜像节点的过载压力并平衡了镜像上的负载。这称为故障恢复或自我修复。

在修复出现故障的主机（通过更换硬件或升级软件）并重新启动后，该主机中运行的一个或多个节点将作为备用节点加入到系统中，因为原始备用节点现在是活动节点。

备用节点并不是必需的，但系统可以通过这些节点保持其整体服务级别，即使在某台计算机出现故障的情况下也是如此。备用节点还可以简化在承载活动节点的计算机上执行计划维护的过程。请为每个 DRU 分配一台计算机以作为备用计算机，以便在某台计算机出现故障时，HADB 系统可继续运行，而不会对性能和可用性造成负面影响。

注 –

通常，应使用具有足够多 Application Server 实例和 HADB 节点的备用计算机接替变为不可用的任何计算机。

示例备用节点配置

以下示例说明了如何在 HADB 部署中使用备用节点。共有两种可能的部署拓扑：同位（HADB 和 Application Server 位于相同的主机上）和分层（它们位于不同的主机上）。有关部署拓扑的更多信息，请参见第 3 章，选择拓扑。

示例：同位配置

作为一个备用节点配置示例，假定四个 Sun FireTM V480 服务器采用的是同位拓扑，每个服务器具有一个 Application Server 实例和两个 HADB 数据节点。

对于备用节点，额外分配两个服务器（每个 DRU 一台计算机）。每台备用计算机运行一个应用服务器实例和两个备用 HADB 节点。

示例：分层配置

假定使用以下分层拓扑：HADB 层具有两个 Sun FireTM 280R 服务器，每个服务器运行两个 HADB 数据节点。为保持此系统的完整能力（即使一台计算机变为不可用），对 Application Server 实例层以及 HADB 层各配置一台备用计算机。

Application Server 实例层的备用计算机所具有的实例数必须与该层中的其他计算机相同。同样，HADB 层的备用计算机所具有的 HADB 节点数也必须与该层中的其他计算机相同。

减小双故障风险

HADB 的内置数据复制功能使其容许单个节点或整个 DRU 出现故障。默认情况下，在出现双故障时，即镜像节点对或两个 DRU 均出现故障时，HADB 将无法继续运行。在这种情况下，HADB 会变为不可用。

除了使用上一节中介绍的备用节点外，还可以采取以下措施来最大限度地减小出现双故障的可能性：

这些措施是可选的，但会提高 HADB 实例的整体可用性。

HADB 管理系统

HADB 管理系统提供了内置安全功能并简化了多平台管理。如下图所示，HADB 管理体系结构包含以下组件：

如图所示，在运行 HADB 服务的每台计算机上都运行了一个 HADB 管理代理。每台计算机通常承载一个或多个 HADB 节点。与 Application Server 域类似，HADB 管理域中包含多台计算机。要容许数据库出现故障，域中必须至少有两台计算机；通常计算机的个数必须为偶数以组成 DRU 对。因此，每个域中包含多个管理代理。

如图所示，每个域可以包含一个或多个数据库实例。每台计算机可以包含一个或多个节点，这些节点属于一个或多个数据库实例。

管理客户机

HADB 管理客户机是命令行实用程序 hadbm，用于管理 HADB 域及其数据库实例。HADB 服务可以连续运行（即使已停止关联的 Application Server 群集），但如果要删除这些服务，则必须小心将其关闭。有关使用 hadbm 的更多信息，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 3  章 “管理高可用性数据库”。

可以使用 asadmin 命令行实用程序来创建和删除与高可用性群集关联的 HADB 实例。有关更多信息，请参见《Sun Java System Application Server 9.1 高可用性管理指南》中的第 9  章 “配置高可用性会话持久性和故障转移”。

管理代理

管理代理是一个名为 ma 的服务器进程，它可以访问主机上的资源；例如，它可以创建设备并启动数据库进程。管理代理协调并执行管理客户机命令，如启动或停止数据库实例。

管理客户机通过指定管理代理的地址和端口号来连接到该代理。在连接后，管理客户机通过管理代理向 HADB 发送命令。代理将接收并执行请求。因此，管理代理必须正在主机上运行，才能向该主机发出任何 hadbm 管理命令。可以将管理代理配置为自动启动的系统服务。

确保管理代理的可用性

管理代理进程通过重新启动出现故障的 HADB 节点监控进程来确保其可用性。因此，要进行部署，您必须确保 ma 进程的可用性才能保持 HADB 的整体可用性。在重新启动后，管理代理通过域中的其他代理来恢复域和数据库配置数据。

可以使用主机操作系统 (Operating System, OS) 来确保管理代理的可用性。在 Solaris 或 Linux 上，init.d 可确保 ma 进程在出现故障并重新引导操作系统后的可用性。在 Windows 上，管理代理作为 Windows 服务运行。因此，如果管理代理出现故障或重新引导操作系统，操作系统将重新启动该代理。

管理域

HADB 管理域是一组主机，每个主机在相同的端口号上运行管理代理。域中的主机可以包含一个或多个 HADB 数据库实例。管理域是由代理使用的通用端口号以及在创建域或在其中添加代理时生成的标识符（称为 domainkey）定义的。domainkey 为域提供唯一的标识符，这一点至关重要，因为管理代理使用多址广播进行通信。可以将 HADB 管理域设置为与 Application Server 域相匹配。

在开发环境中，在一个域中包含多个数据库实例会非常有用，因为这样可以使不同的开发者小组使用其自己的数据库实例。在某些情况下，这在生产环境中也可能非常有用。

所有属于某个域的代理将协调其管理操作。在通过 hadbm 命令更改数据库配置时，所有代理将相应地更改配置。除非节点主机上的管理代理正在运行，否则无法停止或重新启动该节点。不过，即使某些代理不可用，您也可以执行 hadbm 命令以读取 HADB 状态或配置变量值。

可以使用以下管理客户机命令来执行与管理域相关的操作：

系统信息库

管理代理将数据库配置存储在系统信息库中。系统信息库具有较高的容错能力，因为将在所有管理代理上复制该系统信息库。通过将配置保存在服务器上，您可以从任何装有管理客户机的计算机中执行管理操作。

要对系统信息库进行任何更改，域中的大多数管理代理必须正在运行。因此，如果域中有 M 个代理，则必须至少有 M/2 + 1 个代理（向下舍入为整数）正在运行才能对系统信息库进行更改。

如果域中的某些主机不可用（例如，由于硬件故障），并且由于未达到法定数目而无法执行某些管理命令，请使用 hadbm disablehost 命令从域中删除出现故障的主机。

设置和配置规划

Procedure为 Application Server 设置并配置高可用性

  1. 确定性能以及 QoS 要求和目标，如第 1 章，产品概念中所述。

  2. 确定系统大小，如第 1 章，产品概念中的设计决策所述。

    • Application Server 实例数

    • HADB 节点和主机数

    • HADB 存储容量

  3. 确定系统拓扑，如第 3 章，选择拓扑中所述。

    这可确定是将 HADB 安装在与 Application Server 相同的主机上，还是安装在不同的主机上。

  4. 安装 Application Server 实例以及相关的子组件，如 HADB 和 Web 服务器。

  5. 创建域和群集。

  6. 配置 Web 服务器软件。

  7. 安装负载平衡器插件。

  8. 设置并配置负载平衡。

  9. 设置并配置 HADB 节点和 DRU。

  10. 为 AS Web 容器和 EJB 容器配置 HA 会话持久性。

  11. 部署应用程序并为其配置高可用性和会话故障转移。

  12. 如果大量使用消息传送功能，则为 JMS 群集配置故障转移。

    有关更多信息，请参见《Sun Java System Message Queue Adminstration Guide》。