Sun Java System Application Server 9.1 高可用性管理指南

第 1 章 Application Server 中的高可用性

本章介绍了 Sun Java System Application Server 中随群集配置文件和企业配置文件提供的高可用性功能。

注 –

HADB 软件随 Sun Java System Application Server 的 Application Server 独立分发提供。有关 Sun Java System Application Server 的可用分发的信息，请参见《Sun Java System Application Server 9.1 Installation Guide》中的“Distribution Types and Their Components”。HADB 功能仅在企业配置文件中可用。有关配置文件的信息，请参见《Sun Java System Application Server 9.1 管理指南》中的“用法配置文件”。

本章包含以下主题。

高可用性概述

无论硬件和软件故障，高可用性应用程序和服务均可持续提供其正常功能。这些应用程序有时被称为提供五个九可靠性的应用程序，因为它们 99.999% 的时间都可用。

Application Server 提供以下高可用性功能：

高可用性会话持久性
高可用性 Java 消息服务
RMI-IIOP 负载平衡和故障转移

高可用性会话持久性

Application Server 提供了 HTTP 请求和会话数据（HTTP 会话数据和有状态会话 Bean 数据）的高可用性。

Java EE 应用程序通常具有大量会话状态数据。Web 购物车是会话状态的一个典型示例。此外，应用程序可以高速缓存会话对象中需要频繁使用的数据。事实上，几乎带有重要用户交互的所有应用程序都需要维护会话状态。HTTP 会话和有状态会话 Bean (stateful session bean, SFSB) 都具有会话状态数据。

保留故障服务器之间的会话状态对最终用户非常重要。为了实现高可用性，Application Server 为会话状态数据提供了以下类型的存储：

群集中其他服务器上的内存中复制
高可用性数据库 (High-availability database, HADB)

如果托管用户会话的 Application Server 实例出现故障，则可以恢复会话状态，并且会话可以继续进行而不会丢失信息。

有关如何设置高可用性会话持久性的详细说明，请参见第 9 章，配置高可用性会话持久性和故障转移。

高可用性 Java 消息服务

Java 消息服务 (Java Message Service, JMS) API 是一种通讯标准，使 Java EE 应用程序和组件可以创建、发送、接收和读取消息。并启用了松散耦合的可靠异步分布式通信。Sun Java System Message Queue (MQ)（实现了 JMS）与 Application Server 紧密集成，使您可以创建诸如消息驱动 bean (message-driven bean, MDB) 之类的依赖 JMS 的组件。

通过连接池、故障转移和 MQ 群集，JMS 实现了高可用性。有关更多信息，请参见第 10 章，Java 消息服务的负载平衡和故障转移。

连接池和故障转移

Application Server 支持 JMS 连接池和故障转移。Application Server 将自动实现 JMS 连接池。默认情况下，Application Server 从指定的主机列表中随机选择其主 MQ 代理。发生故障转移时，MQ 会将负载透明地转移到另一个代理，并维持 JMS 语义。

有关 JMS 连接池和故障转移的更多信息，请参见连接池和故障转移。

MQ 群集

MQ 企业版支持多个互连代理实例（称为代理群集）。使用代理群集的情况下，客户机连接将分布在群集的所有代理中。群集可以提供水平可伸缩性并提高可用性。

有关 MQ 群集的更多信息，请参见结合使用 Application Server 与 MQ 群集。

RMI-IIOP 负载平衡和故障转移

通过 RMI-IIOP 负载平衡，IIOP 客户机请求被分发到不同的服务器实例或名称服务器上，这样就会将负载平均地分布在群集中，从而提供了可伸缩性。与 EJB 群集和可用性结合的 IIOP 负载平衡还可提供 EJB 故障转移。

客户机执行对象的 JNDI 查找时，命名服务实际上会将请求绑定到特定的服务器实例。此后，所有从该客户机发出的查找请求都被发送到同一服务器实例，因此将在同一目标服务器上托管所有 EJBHome 对象。此后获得的所有 Bean 引用也创建在相同的目标主机上。这样就有效提供了负载平衡，因为所有客户机在执行 JNDI 查找时会随机使用目标服务器的列表。如果目标服务器实例发生故障，查找或 EJB 方法调用会将故障转移到另一个服务器实例。

IIOP 负载平衡和故障转移将透明地发生。在应用程序部署过程中无需特殊的步骤。如果在其上部署应用程序客户机的 Application Server 实例参与群集，则 Application Server 将自动查找群集中当前处于活动状态的所有 IIOP 端点。但是，客户机应该至少已指定两个端点以用于引导目的，以防其中一个端点出现故障。

有关 RMI-IIOP 负载平衡和故障转移的更多信息，请参见第 11 章，RMI-IIOP 负载平衡和故障转移。

Application Server 如何提供高可用性

Application Server 通过以下子组件和功能提供高可用性：

负载平衡器插件

负载平衡器插件接受 HTTP/HTTPS 请求，然后将请求转发至群集中的应用程序服务器实例。如果实例出现故障，变得不可用（由于网络故障）或无法响应，负载平衡器会将请求重定向至现有的可用计算机。负载平衡器还可识别故障实例何时恢复并相应地重新分布负载。Application Server 提供了用于 Sun Java System Web Server 和 Apache Web Server 以及 Microsoft Internet Information Server 的负载平衡器插件。

负载平衡器通过在多台物理计算机中分布工作量来提高系统的整体吞吐量。它还可通过对 HTTP 请求的故障转移提供更高的可用性。对于要保留的 HTTP 会话信息，必须配置 HTTP 会话持久性。

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

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

有关配置负载平衡和故障转移的信息，请参见第 5 章，配置 HTTP 负载平衡。

会话状态数据的存储

通过存储会话状态数据，可以在群集中的服务器实例故障转移后恢复会话状态。恢复会话状态可使会话继续进行而不会丢失信息。Application Server 为 HTTP 会话和有状态会话 Bean 数据提供了以下类型的高可用性存储：

群集中其他服务器上的内存中复制
高可用性数据库

群集中其他服务器上的内存中复制

其他服务器上的内存中复制提供会话状态数据的轻量存储，而无需获取单独的数据库（如 HADB）。此类型的复制可使用其他服务器上的内存来实现 HTTP 会话和有状态会话 Bean 数据的高可用性存储。群集服务器实例在环形拓扑中复制会话状态。每个备份实例均在内存中存储复制数据。通过在其他服务器上的内存中复制会话状态数据，可以分布会话。

使用内存中复制要求启用组管理服务 (Group Management Service, GMS)。有关 GMS 的更多信息，请参见组管理服务。

如果群集中的服务器实例位于不同的计算机上，请确保满足以下先决条件：

要确保 GMS 和内存中复制正常工作，这些计算机必须在同一子网上。
要确保内存中复制正常工作，必须同步群集中所有计算机上的系统时钟使其尽可能接近。

高可用性数据库

注 –

Application Server 提供了高可用性数据库 (High Availability Database, HADB)，以实现 HTTP 会话和有状态会话 Bean 数据的高可用性存储。HADB 旨在通过负载平衡、故障转移和状态恢复等功能支持高达 99.999% 的服务和数据可用性。通常，您必须独立于 Application Server 来配置和管理 HADB。

不让 Application Server 承担状态管理职责会具有很多好处。Application Server 实例在它们的周期中作为可伸缩高性能应用程序容器执行，将状态复制委托给外部高可用性状态服务。由于采用这种松散耦合的体系结构，因此可以很轻松地向群集中添加 Application Server 实例或从群集中删除 Application Server 实例。HADB 状态复制服务可以单独伸缩，以获得最佳的可用性和性能。如果 Application Server 实例同时还执行复制任务，Java EE 应用程序的性能将会降低，并会受到较长的垃圾收集暂停的限制。

有关规划和设置应用服务器安装（包括确定硬件配置、调整大小和拓扑）以通过 HADB 实现高可用性的信息，请参见《Sun Java System Application Server 9.1 部署规划指南》中的“Planning for Availability”和《Sun Java System Application Server 9.1 部署规划指南》中的第 3 章 “选择拓扑”。

高可用性群集

群集是作为一个逻辑实体一起工作的 Application Server 实例的集合。群集为一个或多个 Java EE 应用程序提供了运行时环境。高可用性群集将状态复制服务与群集和负载平衡器集成在一起。

使用群集具有以下优点：

高可用性（通过允许为群集中的服务器实例提供故障转移保护来实现）。如果一个服务器实例出现故障，其他服务器实例将接管该服务器实例正在服务的请求。
可伸缩性（通过允许向群集中添加服务器实例从而增加系统的容量来实现）。负载平衡器插件会将请求分布到群集中的可用服务器实例。当管理员向群集中添加更多服务器实例时，无需中断服务。

群集中的所有实例具有以下特性：

引用相同的配置。
具有相同的一组已部署应用程序（例如，Java EE 应用程序 EAR 文件、Web 模块 WAR 文件或 EJB JAR 文件）。
具有相同的一组资源，因此具有相同的 JNDI 名称空间。

域中的每一个群集都具有唯一的名称；此外，该名称在所有节点代理名称、服务器实例名称、群集名称和配置名称中也必须是唯一的。此名称不能为 domain。您在群集上执行的操作与在非群集服务器实例上执行的操作相同（例如，部署应用程序和创建资源）。

群集和配置

群集的设置源自该群集可能与其他群集共享的命名配置。其配置不能被其他服务器实例或群集所共享的群集可视为具有独立配置。默认情况下，此配置的名称为 cluster_name-config，其中 cluster_name 表示群集的名称。

能与其他群集或实例共享其配置的群集可视为具有共享配置。

群集、实例、会话和负载平衡

群集、服务器实例、负载平衡器和会话的相互关系如下：

服务器实例不需要属于群集。但是，不属于群集的实例无法通过将会话状态从一个实例转移到其他实例来利用高可用性。
群集中的服务器实例可以由一台或多台计算机托管。您可以将不同计算机上的服务器实例组织为一个群集。
特定负载平衡器可以向多个群集中的服务器实例转发请求。您可以使用负载平衡器的此功能来执行联机升级，而不使服务受到损失。有关更多信息，请参见“配置群集”一章中的“使用多个群集进行联机升级而不使服务受到损失”。
一个群集可以从多个负载平衡器接收请求。如果群集由多个负载平衡器提供服务，则必须以完全相同的方式在每个负载平衡器上配置群集。
每个会话都依赖于特定的群集。因此，尽管您可以在多个群集上部署一个应用程序，但是会话故障转移将只能在单个群集中实现。

因此，对于群集中的服务器实例，群集充当的是会话故障转移的安全边界。在 Application Server 中，您可以使用负载平衡器和升级组件，而不使服务受到任何损失。

从故障中恢复

使用 Sun Cluster

Sun Cluster 提供域管理服务器、节点代理、Application Server 实例、Message Queue 和 HADB 的自动故障转移。有关更多信息，请参见《Sun Cluster Data Service for Sun Java System Application Server Guide for Solaris OS》。

使用标准以太网互联和 Sun Cluster 产品的子集。该功能包含在 Java ES 中。

手动恢复

您可以使用多种技术来手动恢复各个子组件：

恢复域管理服务器

丢失域管理服务器 (Domain Administration Server, DAS) 只会影响管理。即使 DAS 不可访问，Application Server 群集和应用程序也将继续像以前那样运行。

可使用以下任一方法恢复 DAS：

定期运行 asadmin 备份命令，以便获得定期快照。发生硬件故障后，在具有相同网络标识的新计算机上安装 App Server，然后运行 asadmin 从以前创建的备份中恢复。有关更多信息，请参见重新创建域管理服务器。
将域安装和配置放置在共享的强健文件系统（例如 NFS）上。如果主 DAS 计算机发生故障，则会初启具有相同 IP 地址的第二台计算机，并通过手动介入或用户提供的自动控制功能让该台计算机进行接管。Sun Cluster 使用类似的方法来实现 DAS 容错。
压缩 Application Server 安装和域根目录。在新计算机上恢复它，为其指定相同的网络标识。如果您使用的是基于文件的安装，这可能是最简单的方法。
从 DAS 备份中恢复。请参见 AS8.1 UR2 修补程序 4 的说明。

恢复节点代理和服务器实例

可采用两种方法来恢复节点代理和服务器实例。

保存备份 zip 文件。没有用于备份节点代理和服务器实例的显式命令。只需创建一个包含节点代理目录的内容的 zip 文件。发生故障后，将保存的备份解压至具有相同主机名和 IP 地址的新计算机上。请使用相同的安装目录位置、OS 等。该计算机上必须有基于文件的安装、基于软件包的安装或恢复的备份映像。

手动恢复。使用的新计算机必须具有相同的 IP 地址。

在该计算机上安装 Application Server 节点代理位。
请参见 AS8.1 UR2 修补程序 4 安装说明。
重新创建节点代理。您无需创建任何服务器实例。
同步过程将从 DAS 复制配置和数据，并进行更新。

恢复负载平衡器和 Web 服务器

没有专门用于备份 Web 服务器配置的显式命令。只需压缩 Web 服务器安装目录。发生故障后，将保存的备份解压至具有相同网络标识的新计算机上。如果新计算机具有不同的 IP 地址，则更新 DNS 服务器或路由器。

注 –

这里假定首先重新安装了 Web 服务器或从映像恢复了 Web 服务器。

负载平衡器插件（插件目录）和配置位于 Web 服务器安装目录（通常为 /opt/SUNWwbsvr）。web-install/web-instance/config 目录包含 loadbalancer.xml 文件。

恢复 Message Queue

Message Queue (MQ) 配置和资源存储在 DAS 中，可以将其与实例同步。任何其他数据和配置信息都位于 MQ 目录中，通常位于 /var/imq 下，所以可以根据需要备份和修复这些目录。新的计算机必须已经包含 MQ 安装。恢复计算机时，确保像以前一样启动 MQ 代理。

恢复 HADB

注 –

如果您具有两个活动 HADB 节点，则可以配置两个备用节点（在单独的计算机上），如果发生故障，它们可以接管。这是一种比较干净利落的方法，因为备份和恢复 HADB 可能会导致恢复过时的会话。

有关创建具有备用节点的数据库的信息，请参见创建数据库。有关将备用节点添加到数据库的信息，请参见添加节点。如果恢复和自我修复失败，则备用节点将自动接管。

使用 Netbackup

注 –

此过程尚未经 Sun QA 测试。

使用 Veritas Netbackup 可以保存每台计算机的映像。对于 BPIP，备份四台具有 Web 服务器和 Application Server 的计算机。

对于已经恢复的每台计算机，使用与原始计算机相同的配置，例如，相同的主机名、IP 地址等。

对于基于文件的产品（如 Application Server），仅备份和恢复相关的目录。但是，对于基于软件包的安装（如 Web 服务器映像），必须备份和恢复整个计算机。软件包安装到 Solaris 软件包数据库中。因此，如果仅备份目录，随后将其恢复至新系统中，将会造成“已部署”的 Web 服务器无法识别软件包数据库。这可能会给将来的修补和升级带来问题。

请勿手动复制和恢复 Solaris 软件包数据库，其他替代方法是在安装组件（例如，Web 服务器）后备份计算机的映像，这称为基准 tar 文件。对 Web 服务器进行更改时，备份这些目录（例如，在 /opt/SUNWwbsvr 下）。恢复时，先恢复基准 tar 文件，然后覆盖已修改的 Web 服务器目录。同样，可以对 MQ（BPIP 的基于软件包的安装）使用该过程。如果您升级或修补原始计算机，请确保创建一个新的基准 tar 文件。

如果具有 DAS 的计算机发生故障，则在恢复之前将无法使用 DAS。

DAS 是中心系统信息库。恢复服务器实例并重新启动它们时，这些实例只会与 DAS 中的信息同步。因此，必须通过 asadmin 或管理控制台进行所有更改。

每天备份 HADB 的映像可能并不可行，因为映像可能包含旧的应用程序会话状态。

重新创建域管理服务器

在托管域管理服务器 (domain administration server, DAS) 的计算机出现故障时，如果以前已备份 DAS，则可以重新创建 DAS。要重新创建 DAS 的工作副本，您必须具有：

一台包含原始 DAS 的计算机 (machine1)。
一台包含群集的计算机 (machine2)，该群集具有运行应用程序并满足客户机需要的服务器实例。该群集是使用第一台计算机上的 DAS 配置的。
一台备份计算机，当第一台计算机崩溃时，需要在该备份计算机上重新创建。

注 –

必须对第一台计算机上的 DAS 进行备份。使用 asadmin backup-domain 来备份当前域。

迁移 DAS

以下步骤用于将域管理服务器从第一台计算机 (machine1) 迁移到第三台计算机 (machine3)。

在第三台计算机上安装应用程序服务器，方法与在第一台计算机上安装相同。

为了可以在第三台计算机上正确地恢复 DAS 并且不会发生路径冲突，您必须执行此操作。
1. 使用命令行（交互式）模式来安装应用程序服务器管理软件包。
  
  要激活交互式命令行模式，请使用 console 选项调用安装程序：
  ./bundle-filename -console
  要使用命令行界面进行安装，您必须具有超级用户权限。
2. 要安装默认域，请取消选择该选项。
  
  只有具有相同体系结构并具有完全相同的安装路径（即都使用相同的 as-install 和 domain-root-dir）的两台计算机才支持备份域的恢复。

将第一台计算机上的备份 ZIP 文件复制到第三台计算机上的 domain-root-dir 中。

也可以通过 FTP（文件传输协议）方式传输文件。

将 ZIP 文件恢复到第三台计算机上。
asadmin restore-domain --filename domain-root-dir/sjsas_backup_v00001.zip --clienthostname machine3 domain1
注 –
通过指定 --clienthostname 选项，就无需在 domain.xml 文件中修改 jmx-connector 元素的 client-hostname 属性。

可以备份任何域。但是，在重新创建域时，域名称应与原始域名称相同。

将第三台计算机上的 domain-root-dir/domain1/generated/tmp 目录的权限更改为与第一台计算机上相同目录的权限相匹配。

该目录的默认权限为：drwx------（或 700）。

例如：
chmod 700 domain-root-dir/domain1/generated/tmp
以上示例假定您备份的是 domain1。如果备份的是其他名称的域，应使用要备份的域的名称替换上面的 domain1。

在第三台计算机上的 domain-root-dir/domain1/config/domain.xml 文件中，更新 jms-service 元素的 host 属性值。

此属性的原始设置如下：
```
<jms-service... host=machine1.../>
```
对此属性的设置进行如下修改：
```
<jms-service... host=machine3.../>
```

在 machine3 上启动已恢复的域：
asadmin start-domain --user admin-user --password admin-password domain1
DAS 与正在运行的所有节点代理联系，并为节点代理提供用于联系 DAS 的信息。节点代理使用此信息与 DAS 通信。

对于重新启动 DAS 时未运行的任何节点代理，请在 machine2 上更改 as-install /nodeagents/nodeagent/agent/config/das.properties 中的 agent.das.host 属性值。

对于重新启动 DAS 时正在运行的节点代理，不需要执行此步骤。

在 machine2 上重新启动节点代理。

注 –
使用 asadmin start-instance 命令启动群集实例，可以使这些实例与已恢复的域同步。

第 1 章 Application Server 中的高可用性

高可用性概述

高可用性会话持久性

高可用性 Java 消息服务

连接池和故障转移

MQ 群集

RMI-IIOP 负载平衡和故障转移

更多信息

调优高可用性服务器和应用程序

Application Server 如何提供高可用性

负载平衡器插件

会话状态数据的存储

群集中其他服务器上的内存中复制

高可用性数据库

高可用性群集

群集和配置

群集、实例、会话和负载平衡

从故障中恢复

使用 Sun Cluster

手动恢复

恢复域管理服务器

恢复节点代理和服务器实例

恢复负载平衡器和 Web 服务器

恢复 Message Queue

恢复 HADB

使用 Netbackup

重新创建域管理服务器

迁移 DAS