确定可用性策略

开发可用性要求策略时，应研究组件交互和用量分析，以确定要考虑的可用性解决方案。对组件进行逐个分析，以确定最适合可用性和故障转移要求的解决方案。

下列项目是为帮助确定可用性策略而需收集的信息类型的示例：

• 指定的可用性中有多少个九？

• 故障转移情况下的性能要求（例如，故障转移期间至少保持 50% 的性能）是什么？

• 用量分析是否区分高峰和非高峰使用时间？

• 地域考虑因素有哪些？

所选的可用性策略还必须考虑设计最佳资源使用方案中阐述的可维护性要求。避免需要太多管理和维护的复杂解决方案。

可用性策略

Java Enterprise System 部署的可用性策略包括以下各项：

• 负载平衡。使用冗余硬件和软件组件来分流处理负载。负载平衡器把对某个服务的任意请求引导至该服务的多个对称服务实例之一。如果任一实例发生故障，其他实例可以承担更大的负载。

• 故障转移。涉及对冗余硬件和软件的管理，在任何组件发生故障时提供对服务的不间断访问并保证关键数据的安全。

  Sun Cluster 软件为后端组件管理的关键数据提供了故障转移解决方案，比如 Messaging Server 的消息存储和 Calendar Server 日历数据。

• 复制服务。复制服务为对同一数据的访问提供多个源。Directory Server 为 LDAP 目录访问提供多个复制和同步策略。

后续各节给出一些提供不同级别的负载平衡、故障转移和复制服务的可用性解决方案示例。

单服务器系统

将服务的所有计算资源置于单个服务器上。如果服务器发生故障，整个服务便终止运行。

图 5–2 单服务器系统

Sun 提供具有下列优点的高端服务器：

• 系统运行中更换和重新配置硬件组件

• 可在服务器的故障隔离域中运行多个应用程序

• 不必重新引导系统即可升级容量、执行速度及 I/O 配置

一台高端服务器的价格通常高于具有可比性的多服务器系统。不过，单个服务器可节省对数据中心多台服务器的管理、监视和驻扎成本。多服务器系统在负载平衡、故障转移和解除单个故障点方面的灵活性更强。

水平冗余系统

利用可提供负载平衡和故障转移两种功能的平行冗余服务器提高可用性的方法有若干种。下图显示的是组成一个 N+1 故障转移系统的两台复制服务器。其中一台服务器发生故障时，N+1 系统通过一个额外服务器继续提供 100% 容量。

图 5–3 具有两台服务器的 N+1 故障转移系统

上面水平冗余系统中每台服务器的计算能力都完全相同。一台服务器即可满足性能要求，另一台服务器作为备份服务器调入服务时，也可提供 100% 的性能。

N+1 故障转移设计的优点是，故障转移情况下仍可达到 100% 的性能。缺点是增加了硬件成本，而总体性能却未得到相应提升（因为一个服务器只在发生故障转移的情况下使用，平时备用）。

下图所显示的是这样一种系统：通过在两台服务器间分配性能负载来实现负载平衡和故障转移。

图 5–4 两台服务器间的负载平衡和故障转移

在上面水平冗余系统中所示的系统内，如果一台服务器发生故障，所有服务仍然可用，只不过性能只能达到完全性能的某一百分比。另一台服务器提供 6 CPU 计算能力，为要求的 10 CPU 的 60%。

这种设计的一个优点是，两台服务器均可用时有 2 个 CPU 的额外潜潜在容量。

下图显示的是，在多台服务器间分配负载来满足性能和负载平衡要求。

图 5–5 在 n 台服务器间分配负载

由于水平冗余系统所示的设计中有五台服务器，如果一台服务器发生故障，其余服务器可继续提供总计 8 个 CPU 的计算能力，达到 10 个 CPU 性能要求的 80%。如果在设计中增加一个具有 2 CPU 计算能力的服务器，实际得到的便是 N+1 设计。如果一台服务器发生故障，其余服务器可满足 100% 的性能要求。

这种设计具有下列优点：

• 单台服务器发生故障时的性能得到提升

• 即使不止一台服务器停机，仍然具有可用性

• 可轮换将服务器停机，以进行维护和升级

• 多台低端服务器的价格通常低于单台高端服务器

不过，增加服务器数量会使管理和维护成本大幅增加，还应考虑在数据中心驻扎服务器的成本。达到某一数量后，再增加服务器所得到的性能提升会越来越少。

Sun Cluster 软件

对于要求高可用性（如四或五个九）的情况，可以考虑将 Sun Cluster 软件纳入可用性设计。群集系统是冗余服务器、存储器及其他网络资源相结合的产物。群集中的服务器彼此间不间断地通信，如果其中一台服务器脱机，群集中的其余设备会将该服务器隔离，并将故障节点上的任何应用程序或数据故障转移到另一节点。这一故障转移过程所需时间较短，几乎不用中断为系统用户提供的服务。

配置、管理和维护 Sun Cluster 软件需要额外的专用硬件和专门技能。

可用性设计示例

本节包含两个可用性策略示例，基于员工数为 1,000 至 5,000 人的中型企业基于身份的通信解决方案，如先前在基于身份的通信示例一节中所述。第一个可用性策略说明了用于 Messaging Server 的负载平衡。第二个说明了使用 Sun Cluster 软件实现故障转移的解决方案。

Messaging Server 的负载平衡示例

下表中列出了逻辑体系结构中每个逻辑 Messaging Server 组件的 CPU 能力估计。此表重复了在更新 CPU 数量估计一节中计算出的最终估计数量。

表 5–6 支持组件的 CPU 数量估计调整

组件	CPU	内存
Messaging Server（MTA，入站）	2	4 GB
Messaging Server（MTA，出站）	2	4 GB
Messaging Server (MMP)	2	4 GB
Messaging Server (Message Store)	2	4 GB

对于本例，假设在技术要求阶段指定了下列服务质量要求：

• 可用性。总体系统可用性应为 99.99%（不包括计划停机）。单个计算机系统故障不会导致服务故障。

• 可伸缩性。日常峰值负载情况下，任何服务器的使用量都不应超过 80%，而且系统必须能够适应每年 10% 的长期增长速度。

为满足可用性要求，应为每个 Messaging Server 组件提供两个实例，每一个都位于不同的硬件服务器上。如果一个组件的服务器发生故障，另一个组件可提供服务。下图显示了此可用性策略的网络示意图。

上图中，CPU 数量为原估计数量的两倍。CPU 数量加倍的原因如下：

• 在一台服务器发生故障的情况下，另一台服务器提供处理负载的 CPU 能力。

• 对于任何服务器在峰值负载下利用程度不超过 80% 的可伸缩性要求，添加的 CPU 能力可提供此保险余量。

• 对于适应年增长 10% 负载的可伸缩性要求，添加的 CPU 能力增加了潜在容量，在需要另外扩大规模之前可用于处理增长的负载。

使用 Sun Cluster 软件的故障转移示例

下图显示了一个对 Calendar Server 后端和 Messaging Server 消息存储实施故障转移策略的示例。Calendar Server 后端和消息存储都在单独的硬件服务器上复制，并且使用 Sun Cluster 软件配置了故障转移。Sun Cluster 中每台服务器上的 CPU 数量和相应内存都被复制。

图 5–6 使用 Sun Cluster 软件的故障转移设计

目录服务复制示例

可对目录服务进行复制，以便在不同服务器间分配事务，从而提供高可用性。Directory Server 提供各种复制服务策略，其中包括：

• 多数据库。在不同数据库中存储目录树的不同部分。

• 链锁和引用。将分布数据链接到单个目录树。

• 单主复制。为主数据库提供一个中心源，然后将该中心源分配到使用者副本中。

• 多主复制。在多个服务器间分配主数据库。然后，这些主中的每一个都在使用者副本中分配其各自的数据库。

Directory Server 的可用性策略是个复杂的问题，不在本指南的讨论范围之内。以下两节，单主复制和多主复制提供了对基本复制策略的概括说明。有关详细信息，参见《Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide》的第 12 章 "Designing a Highly Available Deployment"。

单主复制

下图显示了一个说明基本复制概念的单主复制策略。

图 5–7 单主复制示例

在单主复制中，一个 Directory Server 实例管理主目录数据库，并记录所有变化。主数据库被复制为任意数量的使用者数据库。Directory Server 的使用者实例按读取和搜索操作进行了优化。使用者接收的任何写操作都被引用回主数据库。主数据库定期更新使用方数据库。

单主复制的优点包括：

• 为数据库读取和写入操作优化了单个 Directory Server

• 为读取和搜索操作优化了任意数量的 Directory Server 使用者实例

• Directory Server 使用者实例的水平可伸缩性

多主复制

下图显示了一个可用于全局分配目录访问的多主复制策略。

在多主复制中，一个或多个 Directory Server 实例管理主目录数据库。每个主数据库都有一个指定同步主数据库的过程的复制协议。每个主数据库都被复制为任意数量的使用者数据库。与单主复制相同，Directory Server 的使用者实例都按读取和搜索访问进行了优化。使用者接收的任何写操作都被引用回主数据库。主数据库定期更新使用方数据库。

图 5–8 多主复制示例

多主复制策略除具有单主复制的所有优点之外，还提供了一个在更新主数据库时提供负载平衡的可用性策略。还可以实现一个对目录操作提供本地控制的可用性策略，这对于在全球分布数据中心的企业是一个很重要的考虑事项。