了解高可用性因素

适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题： 2015-03-09

在规划高可用邮箱服务器和数据库体系结构时，必须考虑设计决策，如：

• 是否将部署多个数据库副本？

• 将部署多少个数据库副本？

• 是否具有提供站点恢复能力的体系结构？

• 将部署哪种类型的邮箱服务器恢复模型？

• 将部署多少个邮箱服务器？

• 将如何分布数据库副本？

• 将使用哪种备份模型？

• 将使用哪种存储体系结构？

Microsoft Exchange Server 2010 使您可以使用独立邮箱服务器或为实现邮箱恢复进行配置的邮箱服务器来部署邮箱服务器基础结构。为实现邮箱恢复进行配置的邮箱服务器采用数据库可用性组 (DAG)，在整个 DAG 中高效分布多个数据库副本。通过部署多个数据库副本，您可以执行以下操作：

• 设计一种解决方案来减少使用备份的最常见原因的出现。数据库副本提供针对硬件、软件和数据中心故障的保护。

• 将数据库大小最多增加至 2 TB，因为恢复机制是对数据库的又一次复制而不是备份的还原。

• 如果您要部署三个或更多数据库副本，可考虑传统 RAID 配置的备用存储体系结构（如只是一批磁盘 (JBOD)）。结合使用 JBOD 和较为便宜的磁盘可以为组织节省成本。

您可以在参与 DAG 的所有服务器内分布活动数据库，来使硬件效率最大化。

有关详细信息，请参阅规划高可用性和站点恢复和了解备份、还原和灾难恢复。

目录

规划要部署的数据库副本数

数据库副本类型

站点恢复

规划邮箱服务器恢复模型

规划要部署的邮箱服务器数

规划数据库副本布局

规划备份模型体系结构

规划存储模型体系结构

要查找与高可用性相关的管理任务吗？请参阅管理高可用性和站点恢复。

规划要部署的数据库副本数

如了解邮箱数据库副本中所讨论的那样，DAG 成员可以托管每个邮箱数据库的一个副本，在企业版产品中每个服务器最多可包含 100 个数据库（此限制同时包含主动和被动副本计数）。这意味着一个 16 成员 DAG 支持的数据库限制为 1,600（100 个数据库副本/服务器 × 16 个服务器/DAG ÷ 1 个副本/数据库 = 1,600 个数据库/DAG）。

在高可用性配置中，部署数据库的单一副本没有任何价值，因为这无法提供数据冗余。可使用一个公式来确定特定 DAG 可以支持的数据库数。例如，如果您选择 D 为要部署的数据库数，C 为每个数据库的副本数，而 S 为服务器数，则可应用以下公式：

• D × C = DAG 中的数据库副本总数

• (D × C) ÷ S = 每个服务器的数据库副本数

注意：
得到的每个服务器的数据库数在使用企业版时不得超过 100 个，在使用标准版时不得超过 5 个。

例如，假设您的一个 DAG 包含 6 个服务器和 84 个邮箱数据库，其中每个数据库有 3 个副本。（请注意，6 个服务器是 3 个副本的整数倍。）可应用以下公式：

• 84 个数据库 × 3 个副本 = 总共 252 个数据库

• 252 数据库 ÷ 6 个服务器 = 每个服务器 42 个数据库副本

在另一个示例中，您的 DAG 包含 4 个服务器和 136 个邮箱数据库，其中每个数据库有 3 个副本。可应用以下公式：

• 136 个数据库 × 3 个副本 = 总共 408 个数据库

• 408 数据库 ÷ 4 个服务器 = 每个服务器 102 个数据库副本

因为 102 大于 100，所以建议的方案不是有效的 DAG 设计。

返回顶部

数据库副本类型

有两种类型的数据库副本：

• 高可用数据库副本

• 滞后数据库副本

高可用数据库副本是重播延迟时间配置为零的副本。顾名思义，高可用数据库副本由系统保持为最新状态，可以由系统自动激活，并用于为邮箱服务和数据提供高可用性。

滞后数据库副本是配置为将事务日志重播延迟一段时间的副本。滞后数据库副本旨在提供时间点保护，该保护可以用于从存储逻辑损坏、管理错误（例如，删除或清除断开连接的邮箱）和自动化错误（例如，批量清除断开连接的邮箱）恢复。

通常，滞后数据库副本不会由活动管理器最佳副本选择算法所激活。因为部署滞后数据库副本是为了降低运行风险，所以不应激活这些副本。如果被激活并且如果发出了装入请求，则日志重播会开始，重播所有所需日志文件以使数据库成为最新并处于干净关闭状态，从而失去时间点功能。

有关如何在邮箱服务器级别阻止激活或挂起针对一个或多个数据库副本的激活以防止数据库副本（如滞后数据库副本）自动激活的详细信息，请参阅 Set-MailboxServer 和 Suspend-MailboxDatabaseCopy。

返回顶部

站点恢复

您的环境可能包含多个数据中心。在 Exchange 2010 设计过程中，确定是在单个数据中心中部署 Exchange 基础结构，还是跨两个或更多数据中心进行分布。您所在组织的恢复服务级别协议 (SLA) 应定义在出现主数据中心故障之后所需的服务级别。

如果 Exchange 部署将跨多个数据中心进行以实现站点恢复目标，请考虑应用哪种用户分布模型。基于邮箱相对于数据中心的位置，有两种类型的用户分布模型：

• 主动/被动用户分布模型

• 主动/主动用户分布模型

如果用户邮箱主要位于单个数据中心内（或如果用户通过单个数据中心访问数据），并且 SLA 要求用户在正常操作过程中继续通过主数据中心访问数据，则体系结构为主动/被动用户分布模型。

如果用户邮箱分散在各数据中心内，并且 SLA 要求用户在正常操作过程中继续通过主数据中心访问数据，则体系结构为主动/主动用户分布模型。

在主动/被动用户分布模型中，可以如下图所示部署体系结构，其中活动邮箱由主数据中心托管，但是数据库副本部署在辅助数据中心内。

具有两个数据中心的主动/被动用户分布模型

下图中显示的体系结构可能用于主动/主动用户分布模型。

具有两个数据中心的主动/主动用户分布模型

但是，上图中显示的体系结构存在一个风险。广域网 (WAN) 是 DAG 的单一故障点。丢失 WAN 将导致辅助数据中心中的 DAG 成员丢失仲裁。在此示例中，Windows 故障转移群集总共具有五个投票（四个 DAG 成员加见证服务器），要求始终有三个投票可用，才能使故障转移群集保持正常运行。其中三个投票位于雷蒙德数据中心内，而两个投票位于波特兰数据中心内。丢失 WAN 连接会导致波特兰数据中心仅托管两个投票，这不足以维持仲裁。雷蒙德数据中心具有三个投票，因而可以维持仲裁并继续为活动邮箱提供服务（只要这三个投票正常运行）。

若要为主动/主动用户分布模型降低此风险，建议部署两个 DAG，如下图所示。

有两个 DAG 用于主动/主动用户分布模型

DAG1 托管雷蒙德数据中心的活动邮箱，并作为主动/被动用户分布模型实现，其中被动数据库副本部署在波特兰数据中心内。DAG2 托管波特兰数据中心的活动邮箱，并作为主动/被动用户分布模型实现，其中被动数据库副本部署在雷蒙德数据中心内。

此体系结构可以承受 WAN 的丢失：

• 在雷蒙德数据中心中，DAG2 的邮箱服务器成员会由于丢失仲裁而进入故障状态，但是 DAG1 的活动邮箱服务器成员仍可正常运行，为用户提供服务。

• 在波特兰数据中心中，DAG1 的邮箱服务器成员会由于丢失仲裁而进入故障状态，但是 DAG2 的活动邮箱服务器成员仍可正常运行，为用户提供服务。

有关详细信息，请参阅规划高可用性和站点恢复。

返回顶部

规划邮箱服务器恢复模型

Exchange 2010 邮箱服务器容量规划的一个重要方面是在为邮箱恢复配置数据库副本时，确定计划在每个服务器上要激活的数据库副本数。可能的设计有很多种，但是建议使用两种模型，如以下各节所述。

针对所有已激活数据库副本的设计

可以将服务器体系结构设计为可处理 100% 所有正成为主动副本的托管数据库副本。例如，如果您的服务器托管 35 个数据库副本，则将处理器和内存设计为在用户活动的峰值时段存储所有的 35 个数据库。此解决方案通常成对部署。例如，如果部署四个服务器，则一对为服务器 1 和 2，第二对为服务器 3 和 4。此外，当针对此方案进行设计时，应调整每个服务器的大小，使正常运行时操作占用的可用资源不超过 40%。

在本主题讨论的两种模型中，此模型具有更高的服务器计数。

定向故障方案的设计

可以将服务器体系结构设计为在计划适应最糟糕的故障情况时处理活动邮箱负载。在此模型中需要考虑许多因素，包括站点恢复、RAID 存储与 JBOD、DAG 大小和数据库副本计数。此容量规划模型实现了资金成本、可用性和客户端性能特征之间的平衡。

假设随机且均匀地分布数据库副本：

• 针对两成员或三成员 DAG 配置（其中每个邮箱数据库具有两个高可用数据库副本）中的自动单成员服务器故障的设计。

• 针对三成员 DAG 配置（其中每个邮箱数据库具有三个高可用数据库副本）中的双成员服务器故障的设计（出现第二个故障后手动激活）。

• DAG 具有四个或更多成员且每个邮箱数据库具有三个或更多高可用数据库副本时，针对这种情况下的自动双成员服务器故障的设计。

如果选择此容量规划模型，则强烈建议您限制每个服务器可以激活的数据库数，以使单个服务器不会过载，从而避免提供不佳的客户端体验。

您可以通过配置最大主动数据库设置来限制数据库的数目。您可以通过运行 Set-MailboxServer -MaximumActiveDatabases 在 Exchange 命令行管理程序中配置此限制。在 DAG 中的每个服务器上配置此限制以匹配部署支持的活动数据库的最大数目。

有关详细信息，请参阅数据库可用性组设计示例。

返回顶部

规划要部署的邮箱服务器数

在确定要部署的邮箱服务器数时，可使用要部署的数据库副本数的倍数。例如，如果您计划部署三个数据库副本，则可采用 3、6、9、12 或 15 个服务器开始设计。

在为 DAG 中的服务器数确定起点后，可基于邮箱数、故障设计模型以及可能会增加或减少所需邮箱服务器数的其他设计约束来适当地调整 DAG 成员数。

许多组织都会遇到的一个设计约束是可以在一个服务器上放置的最大邮箱数。例如，如果某个组织具有 20,000 个邮箱，并且在故障事件期间只能影响 25% 的邮箱，可以在单个服务器上部署的最大邮箱数为 5,000。这需要至少部署四个邮箱服务器。

选择的服务器硬件和存储模型也可能会导致对每个服务器上部署的邮箱数或数据库副本数进行调整，从而可能影响邮箱服务器的总数。

多角色服务器与独立角色服务器

在 Exchange Server 2007 中，客户端访问和集线器传输服务器角色需要处于与群集邮箱服务器独立的服务器上。在 Exchange 2010 中，不再存在群集邮箱服务器，因此此限制也不再适用。客户端访问和集线器传输服务器角色可以在 DAG 成员上托管，从而提供改进的部署选项。

在部署多角色服务器（邮箱、客户端访问和集线器传输服务器角色处于同一个服务器上）时，可简化大多数体系结构。除了边缘传输和统一消息服务器，其他所有 Exchange 2010 服务器都可以相同。这些服务器可以具有相同的硬件、软件安装过程和配置选项。服务器间的一致性可以简化 Exchange 实现的管理。

通过多角色服务器（处于大规模环境中）可更加高效地使用核心数较多的服务器，从而可提供高兆周功能。每个角色在单独部署时，建议的最大已占用处理器插槽数为 2。在合并角色时，建议的最大处理器插槽数为 4。服务器可以具有更大的工作负载，这可减少组织中的服务器总数。部署较少的服务器可降低管理这些服务器的成本，因为多角色服务器可将成本从定期发生的运营费用变为一次性资本费用。减少服务器数可以显著减少能源、冷却和数据中心空间的消耗，从而进一步减少定期发生的运营费用。

虽然多角色概念十分高效，但是独立服务器角色仍然有用武之地。例如，独立角色部署可适用于某些虚拟化环境或利用了某些硬件体系结构（例如，不能适当隔离硬件的刀片服务器基础结构）的情况。

在部署多角色服务器时，必须适当地设计处理器和内存体系结构。就处理器而言，您应确保邮箱服务器角色在故障模式期间不占用 40% 以上的可用兆周，为集线器传输和客户端访问服务器角色保留 40% 的兆周。若要确保所有服务器角色都有足够内存可用，请遵循了解邮箱数据库缓存中定义的内存指导。

有关详细信息，请参阅了解容量规划中的多个服务器角色配置。

返回顶部

规划数据库副本布局

在高可用性设计过程中，需要设计平衡的数据库副本布局。在规划数据库副本布局时应遵循以下设计原则：

• 通过隔离每个副本，来确保最大程度减少特定邮箱数据库的多数据库副本故障。例如，在同一个服务器机架或同一个存储阵列中，放置的特定邮箱数据库的数据库副本不要超过一个。否则，机架或阵列故障会导致同一个数据库的多个副本出现故障，这会影响该数据库的可用性。

• 按照一致的分布式方式对数据库副本进行布局，以确保在出现故障后均匀地分布活动邮箱数据库。任何特定服务器上的每个数据库副本的激活首选项总和必须相等或近似相等，因为这可在出现故障后形成近似均匀的分布（假设副本正常且处于最新状态）。

有关详细信息，请参阅数据库副本布局设计。

返回顶部

规划备份模型体系结构

Exchange 2010 包括几个功能和体系结构的更改，在正确部署和配置后，这些更改可提供本机数据保护，从而无需进行传统的数据备份。使用下表可确定是否需要继续利用传统备份模型或是否可以实现 Exchange 2010 中的本机数据保护功能。

逻辑损坏情况通常需要时间点备份。但是对于 Exchange 2010，提供了几个可以减少时间点备份需求的选项：

• 对于单个项目恢复，如果用户更改了任何邮箱文件夹中某个项目的某些属性，则在修改写入数据库之前，该项目的副本会保存在“可恢复的项目”文件夹中。如果邮件的修改导致副本损坏，则可以还原原始项目。

• 日历修复助理可针对该邮箱服务器上的邮箱检测并更正单次和定期会议项目的不一致性，以免收件人错过会议通知或获得不可靠的会议信息。

• 在邮箱移动过程中，Microsoft Exchange 邮箱复制服务会检测损坏的项目，不会将这些项目移动到目标邮箱数据库。

• Exchange 2010 Service Pack 1 (SP1) 引入了 New-MailboxRepairRequest cmdlet，该 cmdlet 可以修复搜索文件夹、项目计数、文件夹视图以及父/子文件夹方面的损坏。

时间点备份可以是传统备份或滞后数据库副本，这两者可提供相同功能。选择哪种取决于您的恢复 SLA。恢复 SLA 定义恢复点目标（如果发生灾难，数据必须在特定时间范围内还原），以及必须将备份保留多长时间。如果恢复 SLA 为 14 天或更短时间，则可以利用滞后数据库副本。如果恢复 SLA 大于 14 天，则必须使用传统备份。对于未授权管理员以及公司或监管合规方案，时间点备份的维护通常独立于消息传递基础结构和消息传递 IT 人员，这表示传统备份解决方案。

如果选择维护时间点备份，则设计的几个方面可能会发生变化：

• 部署滞后数据库副本会影响存储。由于 ReplayLagTime 设置而必须为滞后数据库副本上的事务日志分配额外空间。此外，滞后数据库副本的放置可能会影响存储体系结构。（有关详细信息，请参阅本主题后面的“规划存储模型体系结构”。）

• 部署传统备份解决方案会影响逻辑单元号 (LUN) 布局（具体取决于卷影复制服务 (VSS) 解决方案的类型），因为基于硬件的 VSS 克隆解决方案需要每个数据库体系结构具有两个 LUN。

根据存储体系结构，利用传统备份解决方案可能需要显著减小所需用户邮箱大小以满足备份和还原时间范围 SLA。

在部署 Exchange 本机数据保护时，会对邮箱数据库启用循环日志记录。在启用循环日志记录时，确保系统中内置了足够容量，以便解决方案可以承受阻止日志截断的灾难事件。您至少应确保，最少有三天的事务日志容量（排除滞后副本要求）。有关循环日志记录如何用于连续复制的详细信息，请参阅了解备份、还原和灾难恢复。

有关规划备份的其他信息，请参阅：

• 了解 Exchange 2010 LUN 体系结构

• 了解邮箱数据库和日志容量因素

• 了解日历修复

• 了解可恢复的项目

返回顶部

规划存储模型体系结构

Exchange 2010 在存储设计方面提供了灵活性。Exchange 2010 包括性能、可靠性和高可用性方面的改进，这些改进使组织可以在一系列存储设备上运行 Exchange。以 Exchange 2007 中引入的磁盘输入/输出 (I/O) 改进为基础，最新版本的 Exchange 对存储性能的要求更低，并且对于存储故障具有更强的容错能力。

选择的存储平台应确保在容量要求与 I/O 要求之间实现平衡，同时确保解决方案提供可接受的磁盘延迟和快速响应的用户体验。

RAID 或 JBOD

确定是使用 RAID 技术还是 JBOD 方法（假设存储平台允许使用 JBOD 配置）来实现存储平台。对于 Exchange，JBOD 意味着将数据库及其关联日志同时存储在单个磁盘上。若要在 JBOD 上进行部署，必须至少部署三个高可用数据库副本。利用单个磁盘会成为单一故障点，因为当该磁盘发生故障时，驻留在该磁盘上的数据库副本会丢失。至少拥有三个数据库副本可确保实现容错能力，因为在一个副本（或磁盘）发生故障时还有其他两个副本。但是，三个高可用数据库副本的放置以及滞后数据库副本的使用可能会影响存储设计。下表显示了针对 RAID 或 JBOD 考虑事项的指导。

RAID 或 JBOD 考虑事项

若要对主数据中心服务器在 JBOD 上进行部署，需要在 DAG 中包含三个或更多高可用数据库副本。如果在托管高可用数据库副本的同一个服务器上混合滞后副本（例如，不使用专用滞后数据库副本服务器），则至少需要两个滞后数据库副本。

若要使辅助数据中心服务器使用 JBOD，应在辅助数据中心中至少包含两个高可用数据库副本。辅助数据中心中的一个副本丢失不会导致需要跨 WAN 重新设定种子，也不会导致在激活辅助数据中心时形成单一故障点。如果在托管高可用数据库副本的同一个服务器上混合滞后数据库副本（例如，不使用专用滞后数据库副本服务器），则至少需要两个滞后数据库副本。

对于专用滞后数据库副本服务器，应在数据中心中至少有两个滞后数据库副本使用 JBOD。否则，丢失磁盘会导致丢失滞后数据库副本，以及丢失保护机制。

有关详细信息，请参阅了解存储配置。

返回顶部

 © 2010 Microsoft Corporation。保留所有权利。