可用性描述

现在基于 Web 的应用程序通常都依赖于多个服务器、或许成百上千台客户端工作站、内部和外部网络通信、数据库服务、操作进程以及大量其他基础结构服务，所有这些都必须协调一致地工作。商业理想追求的是连续的信息流，中断将会导致公司在金钱上的损失，在这种情况下，创建高可用性应用程序便成为重要的商业策略。

对于那些日益依赖于基于 Web 的分布式应用程序进行重要业务活动的公司而言，它们需要一系列可用性工程处理选项，从而以一种低耗高效的方式满足服务级别要求。实际上，并非所有应用程序都需要每周 7 天、每天 24 小时正常运行，而且具有即时响应能力。一些应用程序可以不用达到这个标准，而且不会有任何影响。其他应用程序能够容忍意外停机，但可能要求改变恢复策略，而还有一些应用程序则必须使用待机复制策略来提供非常高的可用性，以保证在实际上感觉不到停机的情况下进行即时、透明的恢复。

自分布式应用程序首次安装后，随着分布式应用程序的复杂性和访问量的增加，在原始设计、支持服务或维护和增强功能方面也越来越有可能暴露出一些缺陷。不幸的是，停机导致的问题和远期损失所播及的范围会大大超出本地计算环境（如引起客户不满和导致供应渠道中断）。

如在有关可靠性的主题中描述的那样，应用程序失败的原因有很多：

• 不充分的测试。
• 更改管理问题。
• 缺少进行中的监视和分析。
• 操作错误。
• 弱编码。
• 缺少优质的软件工程处理进程。
• 与外部服务或应用程序的交互。
• 不同的操作条件（使用级别更改、峰值重载）。
• 异常事件（安全性失败、广播风暴）。
• 硬件故障（硬盘、控制器、网络设备、服务器、电源、内存和 CPU）。
• 环境问题（电源、冷却、火、洪水、灰尘、自然灾害）。

约有 40% 的应用程序停机时间是由于测试不充分、更改管理以及缺少进行中的失败监视而发生的。另外 40% 的应用程序停机时间是由因缺乏严格的操作规程而导致的操作错误和备份/还原错误造成的。近几年来硬件的可靠性有了很大的提高，因此由于硬件问题导致的停机时间通常不到总停机时间的 10%。剩余的 10% 的停机时间是由于环境和其他各种问题造成的。

一般来讲，可用性是衡量应用程序多长时间可使用一次的方法。更具体地说，即可用性是一个百分比值，它是基于与计划的总可用运行时间相比时，应用程序实际可以多长时间处理一次服务请求而计算的。可用性的正规计算包括修复时间，因为正在修复中的应用程序无法使用。

可用性公式如下所示：

可用性 = (MTBF / (MTBF + MTTR)) X 100

例如，假设某个应用程序可以无休止地运行。如果假定连续 1000 个小时作为一个检查点，则在此期间两次 1 小时的失败将使可用性为：((1000/2) / ((1000/2) + 1)) X 100 = (500 / 501) X 100 = .998 X 100 = 99.8%。

规划可用性级别

在确定适合于应用程序的可用性级别时，需要回答以下几个问题：

• 客户是谁以及他们的期望是什么？
• 可接受的停机时间是多长？
• 公司内部过程是否依赖于该服务？
• 日程和预算情况如何？

注意：这些可用性计算中使用的是每年 365.25 X 24 = 8,766 小时。

设计可用性

可用性工程处理是指：尽最大努力创建可靠的应用程序组件和基础结构，接受您的应用程序可能至少有一些失败的事实，以及用快速恢复技术设计以最小化（或者甚至消除）停机时间。换一种说法是，可靠性关注的是“它是否工作？”这一问题，而可用性工程处理关注的是“修复它需要多久？”这一问题。

设计可用性是指在硬件或软件故障导致服务错误、事件错误或数据损坏之前，预测、检测和自动排除这些故障，从而使停机时间缩短到最小。解决方案的技术部分要求多个到应用程序服务和数据的通路。解决方案的操作部分在应用程序的整个生命周期中，只使用经测试而且证实过的过程（不论自动的还是基于人员的过程）支持该应用程序。

虽然可用性工程处理主要是指减少非计划停机时间，但减少计划停机时间也很重要。这样的计划停机时间可包括维护更改、操作系统升级、备份或任何其他暂时将应用程序从服务中移除的活动。

• 避免使用较旧的、传统的方法来提高可用性
  • 提供高可用性应用程序的一种传统方法是使用多个 CPU。对称的多处理器 (SMP) 系统使几个处理器共享 I/O 子系统和内存。此方法会引起问题，因为磁盘 I/O 和内存速度通常会约束服务器的吞吐量。
• 利用群集减少非计划停机时间
• 使用网络负载平衡
• 使用 RAID 进行数据存储
• 减少计划停机时间
• 隔离关键任务的应用程序
• 使用队列
• 使用分布式文件系统 (DFS)

可用性的最佳措施

使用群集

即使采用最好的软件工程处理，所有应用程序最终都会失败。尽管失败仍要提供应用程序服务是可用性工程处理的核心内容。群集是高可用性的关键技术，因为它在出现失败时提供即时故障转移应用程序服务。

使用网络负载平衡

“网络负载平衡”(NLB) 通过检测服务器失败和自动将通信量重新分发给仍然运行的服务器，增强基于 Web 的关键应用程序的可用性。利用 NLB 可获取两个设计好处：带有最低操作支持的高可用性和具有易于添加的容量的增量可缩放性。

使用服务级别协议

投资某个应用程序并开始编制设计规范后，一项重要工作是创建一份书面协议，定义期望的服务级别。这样的服务级别协议应包括这样的细节：“该应用程序应每周 7 天、每天 24 小时运行，年可用性为 99.9%”。

如同可靠性要求一样，可用性要求也包含不确定性。经常很难在仍能使客户满意的情况下实现业务需要与预算之间的平衡。随着时间的推移，业务要求和应用程序用途可能更改，影响原始的可用性假定。

提供时刻警惕的监视

一些公司不保存应用程序失败或资源损耗数据。虽然有一些关于网络中断期或操作系统失败的统计信息，但通常缺乏足够的信息来隔离问题和分析趋势。连续监视操作工作负荷和失败数据对于发现趋势和改善服务至关重要。

建立帮助台以减少停机时间

帮助台负责收集问题信息、确定问题历史以及启动即时问题解析。通常，帮助台为组织内的用户提供应用程序支持。帮助台也应在每个失败恢复方案中作为重点涉及的内容，处理应用程序失败问题的一级支持。

每个帮助台应有一个问题升级计划，定义负责解决各种类型的问题的人员。明确定义的升级过程可避免在危机过程中出现混乱。问题升级计划应包括：

• 在问题恶化的情况下求救的层次结构。
• 为每个应用程序和每种类型的操作失败所指定的联系人。
• 重要联系人的呼机和移动电话。
• 形成文档的问题的历史记录，其中包括解决方案的描述性细节。

测试恢复计划

一定要多次测试恢复计划。一个编写得很好的计划在经过严格的测试条件证实之前，只不过是一张纸而已。使用预先安排的和“令人吃惊的”中断实践恢复过程。拔掉插头、切断电源、断开网络电缆。应用程序是否仍然运行？抢救小组是否迅速行动，使该应用程序重新开始运行？他们在快速安装、配置和启动进程方面是否训练有素？如果不是，请从头做起。

恢复计划应定期安排真实的中断期恢复测试，并明确定义如何满足下列要求：

• 所有灾难性恢复过程的详细说明。
• 需要的所有操作的核对表，这些操作使每个前端和后端服务器可以运转。
• 必须的现场备件清单。
• 恢复手册的硬拷贝。请记住：如果环境出现问题，您将无法访问电子文本。

选择良好的基础结构

• 硬件
• 标准化的硬件是达到高可用性的基本要求。标准硬件具有以下优点：
• 简化硬件认证的测试。
• 替换部件始终与生产部件匹配。
• 缩减部件清单。
• 降低对支持人员的培训要求。
• 对于所有硬件目标，克隆工具、磁盘映像以及安装进程完全相同。

同步所有时钟

在不同服务器上运行的操作系统和应用程序必须在时间上同步。如果违反了这个简单的前提，对于自动和手动的重建进程，进程和文件创建时间戳将不一致并且混乱。请确保在每个服务器上维护同步的日期和时间信息。

使用数据备份

每个数据中心必须预计严重的数据损坏或丢失的可能性。数据错误产生的后果影响范围很广，从客户身份验证出现问题到破坏财务帐目和商业团体的可信性等。

维护数据完整性可以象执行完整的数据库备份那样简单。维护数据完整性的一种策略是创建主数据库的完整备份，然后增量测试源计算机是否有数据损坏。

可以通过将备份与应用程序事务日志组合来改进此方法。然后可运行“数据库一致性检查器”(DBCC) 检测并修复损坏。

因为现代 RAID 技术为数据提供了强大的保证，所以实现完整数据库备份取决于您对数据损坏的风险和后果的评估。至少，提供完整备份将有助于从灾难性系统失败中恢复。

检查所有安全计划

安全性是指确保应用程序服务只对有资格的用户可用。安全性还意味着保护应用程序使用的所有分布式组件和资源。对于关键的 Internet 应用程序，安全性实现必须解决在应用程序、匿名用户、已验证用户以及业务伙伴的 Web 站点之间的安全通信问题。

Web 应用程序的安全性有几项主要的职责：

• 保护前端服务器不受未经授权的访问。
• 保护后端服务器上的数据的保密性和完整性。

• 防止入侵（如拒绝服务攻击）。

• 以上内容引用自：可用性概述
• 设计目标