通过

了解容量规划中的多个服务器角色配置

  • 项目

 

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

上一次修改主题： 2016-11-28

服务器硬件中的几种趋势适用于 Microsoft Exchange Server 2010 时间段。一种趋势是显著提高处理器性能，并增加物理处理器支持的处理器核心数。这意味着在具有多核心处理器的标准普通服务器上部署单个 Exchange 服务器角色可能不会充分利用大部分可用 CPU。部分客户期望通过服务器虚拟化来更有效地利用服务器 CPU 资源。其他客户希望在同一个物理服务器上组合 Exchange 服务器角色。这两种都是有效的解决方案。

另一种趋势是具有多核心处理器和 10 到 16 个内部磁盘的服务器模型的可用性。如果考虑通过 10 到 16 个磁盘提供的每秒输入/输出事务数 (IOPS) 可以支持的邮箱数量，则邮箱服务器角色自身通常不会利用一半以上的可用 CPU 资源。将客户端访问服务器角色和集线器传输服务器角色添加到此服务器则会更有效地利用服务器容量。

可以使用本主题中的信息，作为何时部署多角色服务器配置以及如何正确计划多角色服务器配置的指导。示例说明了多角色服务器的服务器大小调整过程。

目录

建议使用多角色配置的原因

建议使用多角色配置的情况

不建议使用多角色配置的情况

对多角色服务器的硬件建议

在 DAG 中部署多角色服务器

Exchange 2010 多角色方案的大小调整示例

建议使用多角色配置的原因

首先也是最重要的，与我们的基线处理器配置相比，当前能购买到的硬件的处理器速度已经极快，能产生 5,000-6,000 兆周数。该配置采用了 2 x 4 内核 Intel Xeon x5470 3.33 GHz 处理器。（有关我们的基线处理器配置的详细信息，请参阅邮箱服务器处理器容量规划中的“邮箱服务器容量规划的示例”一节。）如果您要将环境中的处理器体系结构更换为当前市场上的处理器，同时保持其他所有环境因素不变，将会看到处理器利用率明显下降。

若要有效地降低所购买的服务器的总体拥有成本，应确保高效地利用系统，即系统必须在峰值负荷时的最坏故障模式下保持近 80% 的 CPU 利用率。通过以下四种方式，可以高效地利用当前的可用处理器：

  • 通过增加每个服务器部署的活动邮箱数，增加工作负荷。

  • 引入一个虚拟化层，并将邮箱角色部署为来宾计算机，与其他来宾计算机并列。

  • 将其他 Exchange 服务器角色部署到系统上。

  • 使用以上方法的组合找出最佳配置，尽可能提高硬件的利用效率。

部署具有多角色体系结构的 Exchange 2010 有多种优势：

  • 多角色体系结构将成为基于构建块的体系结构。利用多角色体系结构，Exchange 环境（不包括“统一消息”和“边缘传输”）中的所有服务器都将完全相同 — 相同的硬件、相同的配置，等等。这种统一性可简化硬件的订购以及服务器的维护和管理。  

    • 从成本的角度来看，整体目标是确保体系结构在 CPU 和硬盘两个方面都达到平衡。在单独的计算机上部署服务器角色可能造成长期的成本劣势，因为可能要购买的 CPU、磁盘和内存资源会多于实际使用的资源。例如，一台服务器仅承载了客户端访问服务器角色的情况。如果有多台服务器，就可以通过非常经济的方式增加指定数量的磁盘 — 在部署该数量的磁盘时，更重要的是在使用这些磁盘时，成本基本上为零。如果部署的服务器角色所使用的磁盘远少于指定数量的磁盘，就要为利用不足或根据未用的磁盘控制器支付成本。

  • 在许多情况下，通过使用多角色体系结构，可以减少环境中的物理 Exchange 服务器数量。减少物理服务器意味降低各种原因导致的成本：

    • 运营成本几乎总是高于资本性支出。在服务器的生命周期内，其管理成本高于其购买成本。

    • 您可以减少 Exchange 服务器许可证的购买数量。多角色服务器仅需要为一台 Exchange 服务器和一个操作系统购买许可证，而分散角色需要多个 Exchange 服务器许可证，并且还可能需要多个操作系统许可证。有关详细信息，请参阅关于许可：对虚拟环境的许可（英文）。

    • 减少服务器部署会在基础结构的其余部分产生扩散效应。例如，减少物理服务器部署可以减少 Exchange 基础结构所需的机架和占地面积，进而减少供电和散热成本。

  • 与部署单角色服务器相比，多核心体系结构最终会将负荷分布在更多服务器上，因为所有邮箱服务器最终还会成为集线器传输服务器和客户端访问服务器。这种体系结构有两个优势：

    • 从可伸缩性角度看，负荷将分布在更多的物理计算机上。在发生故障时，其余服务器上增加的负荷是逐渐增加的，这可以确保不会对服务器正在执行的其他功能产生负面影响。

    • 从弹性机制的角度看，该解决方案可以承受更多的集线器传输和客户端访问角色（或服务）故障，仍然提供服务。

鉴于以上原因，在大多数情况下，我们推荐的 Exchange 2010 部署策略是多角色服务器配置。

建议使用多角色配置的情况

鉴于以下原因，大多数情况下建议使用多角色配置：

  • 简单的比例单位   预计邮箱数量定期增长的组织应考虑部署多角色服务器。因为每个多角色服务器表示一个构建块，所以此模型允许方便地添加构建块以满足不断增加容量的需要。

  • 需要利用当前处理器的大规模部署   根据在 Exchange 2010 正式发布版本 (RTM) 之前进行的可伸缩性测试，多角色服务器可以在单台服务器上有效地利用 6 核（或更多核心）的处理器。与往常将各种服务器角色分别部署到带有较少处理器核心的服务器上的做法不同，此项功能帮助大型组织将邮箱、集线器传输以及客户端访问这三种服务器角色进行合并，从而减少服务器数量。此方法利用前面提到的构建块模型为大规模部署提供构建块平台，同时也减少了所需服务器的整体数量。应该首先使用实验室测试对大型核心计数系统中的多角色配置的可伸缩性进行验证，其次进行生产部署。

  • 采用内部存储的服务器部署   现今的许多服务器都有两个物理多核心处理器以及 10 到 16 个内部磁盘。Exchange 2010 的多项改可降低 I/O 要求，从而使这些服务器成为高成本效益的解决方案。根据用户配置文件和磁盘类型，这些服务器通常可最多支持 4,000 个邮箱。建议将客户端访问和集线器传输服务器角色添加到这些服务器，以利用额外 CPU，并使这些服务器自包含构建块。

  • 风险缓解方案限制了驻留在邮箱服务器上的邮箱数量   对于某些部署，风险管理策略限制了可在邮箱服务器上部署的邮箱数量，因此可使用多角色服务器作为解决方案。例如，具有 10,000 个邮箱的组织包含一个策略，即单个服务器中断不能影响环境中超过 25% 的邮箱。此要求会将每个邮箱服务器的邮箱数量限制为 2,500 个。通过将客户端访问和集线器传输服务器角色添加到该服务器，可以利用其上的额外容量。

  • 小型组织和分支机构部分   除了下面提到的使用 Windows 网络负载平衡的情况外，对于以尽量减少物理服务器、操作系统实例和要管理的 Exchange 服务器数量为主要目标的部署，建议使用多角色部署解决方案。如果最低要求为拥有两个或三个物理服务器，则在同一物理服务器上运行客户端访问、集线器传输和邮箱服务器角色就可提供所需的角色冗余。

建议使用多角色配置的原因

不建议使用多角色配置的情况

以下情况不建议使用多角色配置：

  • 需要使用 Windows 网络负载平衡 (NLB) 的小型组织或分支机构部署   对于要将两个或三个多角色服务器部署为数据库可用性组 (DAG) 成员的小型部署，多角色服务器可能不适用。有关 DAG 的详细信息，请参见管理数据库可用性组。添加到邮箱服务器（DAG 成员）的群集组件会阻止在服务器上安装 NLB 的操作。有关负载平衡建议的详细信息，请参阅了解 Exchange 2010 中的负载平衡。但是，仍需要将平衡入站通信加载到客户端访问服务器。在这种情况下主要有两种选择：

    • 购买硬件负载平衡设备。尽管有一些初级 NLB 设备，但此选择成本很高，尤其对于较小型的环境。

    • 虚拟化 Exchange 服务器角色。在有些环境中，限制服务器数量会导致需要在与 Exchange 2010 服务器相同的物理硬件上部署域控制器、文件和打印服务器以及其他应用程序。建议实施作为主机服务器的物理服务器并隔离虚拟环境内的应用程序。通过此隔离，您可以对在虚拟机上运行的客户端访问服务器运行 NLB。

  • 虚拟化   可以结合考虑邮件配置文件与在多核心配置下运行的情况，减少虚拟机可以承载的最大活动邮箱数量。如果邮件用户的使用量不大，在虚拟机中共存服务器角色可能会有意义。但是，如果邮件用户的使用量很大，则对虚拟机中资源的使用可能会受限，从而可能需要减少每个邮箱虚拟机的邮箱数量，或者将角色分散到单独的虚拟机中。在这些情况下，更有效的方法可能是在每个虚拟机中部署单个 Exchange 服务器角色，或者为每个邮箱服务器角色虚拟机部署一个客户端访问和集线器传输组合虚拟机。

    注释注意：
    不能在管理程序主机服务器上安装 Exchange 服务器角色。主机服务器中仅可部署管理软件（例如，防病毒软件、备份软件或虚拟机管理软件）。主机服务器上不应安装其他基于服务器的应用程序（例如，Exchange、Microsoft SQL Server 或 Active Directory）。主机服务器应专门用来运行来宾虚拟机。

有关详细信息，请参阅了解客户端访问和容量规划中的集线器传输组合角色配置。

建议使用多角色配置的原因

对多角色服务器的硬件建议

通常，应调整多角色服务器的大小，将一半的可用处理器核心用于邮箱服务器角色，剩余的一半用于客户端访问和集线器传输服务器角色。Microsoft 没有为多角色服务器指定最大推荐处理器核心数量，而是提供了最大占用处理器插槽数量。这是指连接多核心处理器的主机上的处理器插槽数理。有关详细信息，请参阅了解处理器配置和 Exchange 性能。

除了确定处理器体系结构的规模外，还必须为多角色配置部署确定正确的内存大小。有关详细信息，请参阅了解内存配置和 Exchange 性能。

在 DAG 中部署多角色服务器

在 DAG 中部署单角色邮箱服务器时，请考虑与邮箱服务器负载有关的单个和多个服务器故障的容量规划。如果 DAG 中有四个邮箱服务器，则将邮箱服务器大小调整为 50% 容量，以便在两个邮箱服务器同时发生故障时，可以容纳双倍的活动用户数。因为集线器传输和客户端访问服务器位于不同的物理服务器上，所以丢失一个或两个邮箱服务器对这些服务器的负载影响很小。

在 DAG 中部署多角色服务器时，请考虑客户端访问、集线器传输和邮箱服务器负载的容量规划。如果 DAG 中有四个多角色服务器，请确保有足够的容量来容纳可能增倍的集线器传输和客户端访问服务器负载。因为多角色配置与服务器角色的建议处理器核心比率一致，所以如果正确调整邮箱服务器角色的最大活动数据库大小，则集线器传输和客户端访问服务器应该符合此方案的性能目标。

建议使用多角色配置的原因

Exchange 2010 多角色方案的大小调整示例

以下示例说明了多角色服务器的服务器大小调整过程。此示例包括下列设计假设：

  • 邮箱总数   24,000

  • 邮箱配置文件   每天 100 封邮件（例如发送 20 封，接收 80 封）

  • 每个邮箱的数据库缓存   6 MB（基于每天 100 封邮件的配置文件）

  • 可用性要求   单个站点内的邮箱恢复；防止三个数据库副本和两个服务器同时发生故障

  • 数据库要求   DAG 中有 120 个数据库，每个数据库有 200 个邮箱

  • 服务器平台   基于 2 x 6 核心 2.26 GHz 处理器 (X5650) 的服务器（12 个核心）

下列过程适用：

  1. 计算服务器数   需要一个四节点 DAG 来防止两个服务器同时发生故障。但是，客户已决定部署六台服务器，以便在两台服务器发生故障时能控制最大数量的活动邮箱。因此，设计将从 DAG 中的六个邮箱服务器入手。

  2. 根据激活模型计算每个服务器主动邮箱的最大数目   假设主动数据库平均分布在这些节点上，那么理想情况下，每个服务器应该托管 4,000 (24,000 ÷ 6) 个主动邮箱。要计算此示例在发生双节点故障之后的主动邮箱数，则请使用邮箱数除以剩余节点数 4，即每个节点 6,000 (24,000 ÷ 4) 个主动邮箱。

    在本示例中，Set-MailboxServer cmdlet 中的 MaximumActiveDatabases 参数将配置为 30，以确保单服务器上转为活动状态的数据库比例不超过 40%。

  3. 计算活动邮箱 CPU 要求   根据了解邮箱数据库缓存中的基于邮件活动和邮箱数据库缓存的每个邮箱的估计 IOPS 表，将服务器上活动邮箱的最大数目乘以每个活动邮箱的兆周数（6,000 × 2 个兆周 = 12,000 个兆周）。每多一个附加的数据库副本，就请将此值乘以 10%。

    在此示例中，每个数据库具有一个主动副本和三个被动副本，因此要将 12,000 个兆周增加 30%（12,000 × 1.3 = 15,600 个兆周）。有关详细信息，请参阅了解邮箱数据库缓存中的“数据库缓存指标”。

  4. 计算被动邮箱 CPU 要求   根据了解邮箱数据库缓存中的基于邮件活动和邮箱数据库缓存的每个邮箱的估计 IOPS 表，当服务器托管最大数量的活动邮箱时，将被动邮箱的数量乘以每个被动邮箱的兆周数（10,000 × 0.3 个兆周 = 3,000 个兆周）。有关详细信息，请参阅了解邮箱数据库缓存中的“数据库缓存指标”。

  5. 将主动和被动 CPU 需求相加以得到总 CPU 需求   在本示例中，15,600 个活动邮箱兆周 + 3,000 个被动邮箱兆周 = 18,600 个兆周的总 CPU 需求。

  6. 将邮箱 CPU 需求应用于硬件平台   本示例使用基于 2 x 6 核心 2.26 GHz 处理器的 (x5650) 服务器。根据邮箱服务器处理器容量规划中的指导，这等于 60,083 个兆周。将所需的兆周数除以基于服务器平台可用的兆周数，从而估算发生双节点故障之后峰值时间段的 CPU 使用率（18,600 ÷ 60,083 = 31% 的预测 CPU 使用率）。

    建议将多角色配置的邮箱服务器角色部分设计为在峰值时间段内（例如，两个节点同时发生故障）使用率不超过 40%。此设计将允许在维护峰值时间段内（例如，两个节点同时发生故障）低于 80% 的服务器 CPU 总使用率时，有足够的空间容纳客户端访问和集线器传输服务器角色的 CPU 使用率。

  7. 计算活动邮箱内存要求   将活动邮箱数乘以每个邮箱的所需数据库缓存。在本示例中，由于双服务器故障，因此其余服务器将托管 6,000 个活动邮箱 ((6,000 × 6 MB) ÷ 1,024 = 35.1 GB)。数据库缓存要求基于邮箱配置文件。有关详细信息，请参阅了解邮箱数据库缓存中的“数据库缓存指标”。

  8. 将总内存要求应用于硬件平台   此所需总内存是基于数据库缓存要求和服务器设计（专用或多角色）确定的。有关详细信息，请参阅了解邮箱数据库缓存中的默认邮箱数据库缓存大小表。本示例中多角色服务器的总内存要求是 52.2 GB ((4 GB + 35.1 GB) ÷ 0.75)。因为 52.2 GB 不是标准的内存配置，所以向上舍入为 64 GB 或使用服务器支持的最接近的内存配置。

    建议使用多角色配置的原因

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