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

高可用性数据库

本节包括以下主题：

概述

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

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

高可用性群集中的服务器实例是松散耦合的，并用作高性能 J2EE 容器。
停止和启动服务器实例不会影响其他服务器或其可用性。
HADB 可以在另一组成本较低的计算机（例如，具有一个或两个处理器）上运行。几个群集可以共享这些计算机。根据部署需求，您既可以在与 Application Server 相同的计算机（同位）上运行 HADB，也可以在不同的计算机（分层）上运行 HADB。有关这两个选项的更多信息，请参见同位拓扑。
当状态管理要求发生变化时，可以在 HADB 系统中添加资源，而不会影响现有群集或其应用程序。

注 –

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

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

系统要求

HADB 主机的系统要求如下：

每个 HADB 节点至少有一个 CPU。
每个节点至少有 512 MB 的内存。

有关网络配置要求，请参见《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)，由管理代理启动。它负责创建子进程并使它们保持运行。

子进程可以是：

事务服务器进程 (TRANS)，用于协调分布式节点上的事务以及管理数据存储。
关系代数服务器进程 (RELALG)，用于协调并执行复杂的关系代数查询，如排序和连接。
SQL 共享内存服务器进程 (SQLSHM)，用于维护 SQL 字典高速缓存。
SQL 服务器进程 (SQLC)，用于接收客户机查询，将查询编译为本地 HADB 指令，将这些指令发送到 TRANS，接收结果并将结果传送到客户机。对于每个客户机连接，每个节点包含一个主 SQL 服务器和一个子服务器。
节点管理器服务器进程 (NOMAN)，管理代理使用该进程来执行由 hadbm 管理客户机发出的管理命令。

数据冗余单元

如前面所述，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 Fire^TM V480 服务器采用的是同位拓扑，每个服务器具有一个 Application Server 实例和两个 HADB 数据节点。

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

示例：分层配置

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

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

减小双故障风险

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

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

提供独立电源：为实现最佳的容错能力，支持一个 DRU 的服务器必须使用独立的电源（通过不间断电源）、处理单元和存储器。如果一个 DRU 出现电源故障，另一个 DRU 中的节点可以继续处理请求，直至电源恢复正常。
提供双互连：要容许单个网络出现故障，可复制 DRU 之间的线路和交换机。

这些措施是可选的，但会提高 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 状态或配置变量值。

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

hadbm createdomain：使用指定的主机创建管理域。
hadbm extenddomain：将主机添加到现有管理域中。
hadbm deletedomain：删除管理域。
hadbm reducedomain：从管理域中删除主机。
hadbm listdomain：列出在管理域中定义的所有主机。

系统信息库

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

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

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