了解可用性、可靠性和可伸缩性

上一次修改主题： 2005-05-20

尽管本指南重点讨论获得可用性，但是了解对于规划和实现高可用性 Exchange 2003 邮件系统，可靠性和可伸缩性如何也是关键的组成部分，这一点也很重要的。

定义可用性

在 IT 社区中，用于度量系统可用性的衡量标准是系统能够提供预期功能的时间百分比。由于与邮件系统相关，因此可用性是邮件服务已启动并正在运行的时间百分比。以下公式用于计算可用性级别：

Percentage of availability = (total elapsed time - sum of downtime)/total elapsed time

可用性通常以“九”进行度量。例如，可用性级别为“三个九”的解决方案能够在 99.9% 的时间内支持其预期功能，相当于在 24x7x365（每天 24 小时/每周七天/一年 365 天）的基础上，每年 8.76 小时的年停机时间。下表列出了许多组织试图获得的常见可用性级别。

可用性百分比和年停机时间

遗憾的是，度量可用性并不像选择上表中列出的一个可用性百分比那么简单。首先，必须确定用于量化停机时间的衡量标准。例如，某个组织可能认为当一个数据库没有装入时即出现停机时间。另一组织可能认为仅当超过半数的用户受到中断影响时，才出现停机时间。

此外，确定可用性要求时，必须考虑服务及使用此服务的组织的具体情况。例如，存放非关键公用文件夹数据的服务器的可用性要求，其设置可以低于包含关键任务邮箱数据库的服务器的可用性要求。

有关用于衡量可用性的衡量标准的信息，以及有关基于服务上下文和组织要求来确定可用性要求的信息，请参阅设置可用性目标。

定义可靠性

可靠性度量标准通常用于计算单个解决方案组件的故障概率。用于定义组件或系统可靠性的一个度量标准是平均故障间隔时间 (MTBF)。MTBF 是平均间隔时间，通常以千小时或万小时（有时称为“开机时间”或 POH）进行表示，即经过此间隔时间后组件出现故障并需要修复。MTBF 使用以下公式进行计算：

MTBF = (total elapsed time - sum of downtime)/number of failures

一个相关的度量标准是平均修复时间 (MTTR)。MTTR 是修复故障组件所花费的平均间隔时间（通常以小时表示）。所有解决方案组件（例如服务器硬件、操作系统、应用程序软件和网络情况）的可靠性都可以影响该解决方案的可用性。

如果系统具有容错能力则会更可靠。容错是指：当系统的一部分出现故障时，系统可以继续运行。通过高度硬件冗余来设计系统，可以获得容错。如果任何单个组件发生故障，则冗余组件将取代它，而不会察觉到停机时间。有关容错组件的详细信息，请参阅实现 Exchange 2003 组织容错。

定义可伸缩性

在 Exchange 部署中，可伸缩性用于度量某个服务或应用程序为满足日益增长的性能要求而能够进行扩展的程度。用于 Exchange 群集时，可伸缩性是指，当群集的总负载超过群集能够提供足够性能的能力时，以递增方式向现有群集添加计算机的能力。为了满足邮件基础结构日益增长的性能要求，可以实现两种可伸缩性策略：向上扩展或横向扩展。

向上扩展

向上扩展包括增加现有硬件的系统资源（如处理器、内存、磁盘和网络适配器），或者用更好的系统资源替换现有硬件。当要提升客户端响应时间时（例如在 Exchange 前端服务器网络负载平衡 (NLB) 配置中），向上扩展很适合。例如，如果当前硬件不能为用户提供足够的性能，则可以考虑向 NLB 群集中的服务器添加 RAM 或中央处理器 (CPU)，以满足需求。

Windows Server 2003 支持符合对称多处理 (SMP) 标准的单个或多个 CPU。通过使用 SMP，操作系统能够在任何可用的处理器上运行线程，这使得在需要其他处理资源以增加系统的功能时，应用程序可以使用多个处理器。

横向扩展

横向扩展包括添加服务器以满足需求。在后端服务器群集中，这意味着向群集添加节点。在前端 NLB 方案中，它意味着向 Exchange 2003 前端协议服务器集中添加计算机。当希望改进服务器的客户端响应时间时，横向扩展也同样适用。

有关服务器群集解决方案的可伸缩性的信息，请参阅规划群集时的考虑因素中的“性能和可伸缩性的注意事项”。

有关选择硬件和优化 Exchange 2003 以改善性能及可伸缩性的详细信息，请参阅 Exchange Server 2003 Performance and Scalability Guide（英文）。