通过

Active Directory 域服务容量计划

本文为 Active Directory 域服务 (AD DS) 的容量规划提供了建议。

容量计划目标

容量规划与排查性能事件不同。 容量计划目标为：

  • 正确实施和操作环境。
  • 尽量减少排查性能问题所花费的时间。

在容量规划中，一个组织可能会在高峰时段将处理器利用率定为 40% 的基线目标，以满足客户端性能要求，并留出足够的时间来升级数据中心的硬件。 同时，该组织将性能问题的监控警报阈值设置为每五分钟 90%。

如果持续超过容量管理阈值，则添加更多或更快的处理器来增加容量或跨多个服务器缩放服务将是一种解决方案。 当性能问题对客户端体验产生负面影响时，性能警报阈值会让你知道何时需要立即采取措施。 相比之下，故障排除解决方案更关心的是处理一次性事件。

容量管理就像你为避免车祸而采取的预防措施，如防御性驾驶、确保刹车正常工作等。 性能故障排除更像是警察、消防部门和紧急医疗专业人员对事故的反应。

在过去的几年里，扩大系统的容量计划指南发生了巨大变化。 系统体系结构中的以下更改对有关设计和扩展服务的基本假设提出了挑战：

  • 64 位服务器平台
  • 虚拟化
  • 对功率消耗的关注度提高
  • SSD 存储
  • 云方案

容量规划的方法也正在从基于服务器的规划练习转向基于服务的规划练习。 Active Directory 域服务 (AD DS) 是一种成熟的分布式服务，许多 Microsoft 和第三方产品都将其用作后端，现在它是确保其他应用程序具有运行所需容量的最关键产品之一。

在开始规划之前需要考虑的重要信息

为了最大限度地利用本文，你应该做以下事情：

  • 请确保你已阅读并理解《Windows Server 2012 R2 的性能优化准则》。
  • 请了解，Windows Server 平台是基于 x64 的体系结构。 此外，你必须了解，即使你的 Active Directory 环境安装在 Windows Server 2003 x86 上（现在已超过支持生命周期的结束），并且具有小于 1.5 GB 的目录信息树 (DIT)，并且可以轻松存储在内存中，本文的指导原则仍然适用。
  • 了解容量规划是一个持续的过程，因此你应该定期审查构建的环境是否符合期望。
  • 要明白，随着硬件成本的变化，优化会在多个硬件生命周期中发生。 例如，如果内存变得更便宜，则每个内核的成本会降低，或者不同存储选项的价格会发生变化。
  • 为每天的高峰时段做好计划。 建议你根据 30 分钟或一小时的间隔制定计划。 当服务实际达到峰值容量时，大于 1 小时的间隔可能会隐藏起来，而小于 30 分钟的间隔可能提供不准确的信息，使短暂的增加看起来比实际更重要。
  • 为企业硬件生命周期内的增长做计划。 这种规划可以包括以交错方式升级或添加硬件的策略，或者每三到五年进行一次全面更新。 每个增长计划都要求你估计 Active Directory 上的负载增长了多少。 历史数据可以帮助你做出更准确的评估。
  • 针对容错的重试。 得出估计值 N 后，就要为包括 N - 1、N - 2 和 N - x 的方案做好计划。

    • 根据增长计划，根据组织需要添加额外的服务器，以确保丢失一个或多个服务器不会使系统超过最大峰值容量估计。

    • 还要记住，必须集成增长和容错计划。 例如，如果你知道部署当前需要一个域控制器 (DC) 来支持负载，但你的估计表明，明年的负载将翻一番，需要两个 DC 携带，那么你的系统没有足够的容量来支持容错。 为了防止这种容量不足，应该计划从三个 DC 开始。 如果预算不允许三个 DC，也可以从两个 DC 开始，然后计划在三到六个月后增加第三个 DC。

      注意

      无论负载来自应用程序服务器还是客户端，添加 Active Directory 感知应用程序均可能会对 DC 负载产生明显影响。

三部分容量规划周期

在开始规划周期之前，需要决定组织需要什么样的服务质量。 本文中的所有建议和指导都针对最佳性能环境。 但是，在不需要优化的情况下，你可以选择性地放松它们。 例如，如果你的组织需要更高级别的并发性和更一致的用户体验，则应考虑设置数据中心。 数据中心使你更加关注冗余，并最大程度地减少系统和基础结构瓶颈。 相比之下，如果你计划部署一个只有少数用户的卫星办公室，你就不需要太担心硬件和基础结构的优化，这让你可以选择成本较低的选项。

接下来，应决定是使用虚拟机还是物理计算机。 从容量规划的角度来看，没有正确或错误的答案。 但是，你确实需要记住，每个方案都提供了一组不同的变量来处理。

虚拟化方案为你提供了两种选择：

  • 直接映射，其中每个主机只有一个来宾。
  • 共享主机方案，其中每个主机有多个来宾。

可以将直接映射方案与物理主机同等对待。 如果选择共享主机方案，则会引入其他变量，你应该在后面的部分中考虑这些变量。 共享主机还与 Active Directory 域服务 (AD DS) 竞争资源，这可能会影响系统性能和用户体验。

现在我们已经回答了这些问题，让我们了解一下容量规划周期本身。 每个容量规划周期都涉及三个步骤：

  1. 测量现有环境，确定当前系统瓶颈的位置，并获取规划部署所需容量所需的环境基础知识。
  2. 根据你的容量要求确定你需要什么硬件。
  3. 监控并验证你设置的基础结构是否在规范范围内运行。 在此步骤中收集的数据将成为下一个容量规划周期的基线。

应用过程

要优化性能，请确保正确选择以下主要组件并针对应用程序负载进行调整：

  • 内存
  • 网络
  • 存储
  • 处理器
  • Netlogon

AD DS 的基本存储要求和兼容客户端软件的一般行为允许具有多达 10,000 到 20,000 个用户的环境忽略物理硬件的容量规划，因为大多数现代服务器级系统已经可以处理如此大小的负载。 但是，数据收集摘要表中的表说明了如何评估现有环境以选择合适的硬件。 之后的部分将更详细地介绍硬件的基线建议和特定于环境的原则，以帮助 AD DS 管理员评估其基础结构。

规划时应记住的其他信息：

  • 基于当前数据的任何大小调整仅适用于当前环境。
  • 在进行估计时，预计需求会在硬件的生命周期内增长。
  • 通过确定是应该扩大当前的环境，还是在整个生命周期中逐渐增加容量来适应未来的增长。
  • 应用于物理部署的所有容量规划原则和方法也适用于虚拟化部署。 但是，在规划虚拟化环境时，需要记住将虚拟化开销添加到任何与域相关的规划或估计中。
  • 容量规划是一种预测，不是一个完全正确的值，所以不要指望它是完全准确的。 始终记住根据需要调整容量，并不断验证你的环境是否按预期工作。

数据收集摘要表

下表列出并解释了确定硬件估算的标准。

工作环境

组件 估算
存储/数据库大小 每个用户 40 KB 到 60 KB
RAM 数据库大小
基本操作系统建议
第三方应用程序
网络 1GB
CPU 每个核心 1000 个并发用户

高级评估条件

组件 评估条件 规划注意事项
存储/数据库大小 脱机碎片整理
存储/数据库性能
  • .- .
  • 存储有两个需要解决的问题
    • 对于大多数 AD 环境而言，可用空间与当前基于主轴和基于 SSD 的存储大小无关。
    • 输入/输出 (I/O) 操作可用。 在许多环境中，管理员通常忽略 I/O 操作可用性。 但是，请务必仅评估没有足够的 RAM 将整个 NTDS 数据库加载到内存中的环境。
  • 存储是一个复杂的主题，应该涉及硬件供应商的专业知识，以确定适当的大小，特别是对于 SAN、NAS 和 iSCSI 等更复杂的方案。 但是，每 GB 存储的成本通常与每 I/O 的成本直接相反：
    • RAID 5 的每 GB 成本低于 RAID 1，但 RAID 1 的每 I/O 成本更低
    • 基于主轴的硬盘驱动器的每 GB 成本较低，但 SSD 的每 I/O 成本较低
  • 重新启动计算机或 AD DS 服务后，可扩展存储引擎 (ESE) 缓存为空，并且缓存预热时性能受限于磁盘。
  • 在大多数环境中，AD 是磁盘读取密集型 I/O 的随机模式，这抵消了缓存和读取优化策略的大部分优势。 AD 在内存中的缓存也比大多数存储系统缓存更大。
RAM
  • 数据库大小
  • 基本操作系统建议
  • 第三方应用程序
  • 存储是计算机中速度最慢的组件。 可以占用 RAM 的存储越多，对磁盘的需求就越少。
  • 确保分配足够的 RAM 来存储操作系统、代理（防病毒、备份、监视）、NTDS 数据库以及随时间推移的增长。
  • 对于最大化 RAM 量不划算（如卫星位置）或不可行（DIT 太大）的环境，请参考存储部分以确保存储大小正确。
网络
  • “Network Interface(*)\Bytes Received/sec”
  • “Network Interface(*)\Bytes Sent/sec”
  • 通常，从 DC 发送的流量远远超出发送到 DC 的流量。
  • 由于交换的以太网连接是全双工的，因此需要单独调整入站和出站网络流量的大小。
  • 整合 DC 的数量会增加用于将响应发送回每个 DC 的客户端请求的带宽量，但对于整个站点来说，带宽足够接近线性。
  • 如果删除卫星位置 DC，请不要忘记将卫星 DC 的带宽添加到集线器 DC 中，并使用该带宽来评估有多少 WAN 流量。
CPU
  • Logical Disk(<NTDS Database Drive\>)\Avg Disk sec/Read
  • “Process(lsass)\% Processor Time”
  • 消除存储瓶颈后，解决所需的计算能力问题。
  • 虽然不是完全线性的，特定范围（如站点）内所有服务器使用的处理器核心数可用于测量支持客户端总负载所需的处理器数。 添加在范围内所有系统之间维护当前服务级别所需的最低数量。
  • 处理器速度的变化（包括与电源管理相关的变化）会影响从当前环境派生的数字。 一般来说，不可能精确评估从 2.5 GHz 处理器到 3 GHz 处理器如何减少所需的 CPU 数量。
NetLogon
  • “Netlogon()\Semaphore Acquires”
  • “Netlogon()\Semaphore Timeouts”
  • “Netlogon(*)\Average Semaphore Hold Time”
  • Net Logon Secure Channel/MaxConcurrentAPI 仅影响具有 NTLM 身份验证和/或 PAC 验证的环境。 PAC 验证在 Windows Server 2008 之前的操作系统版本中默认处于打开状态。 此设置是一个客户端设置，因此它会影响 DC，直到你在所有客户端系统上禁用它。
  • 在具有重大跨信任身份验证的环境（包括林内信任）中，如果未正确调整大小，则风险较高。
  • 服务器合并将提高跨信任身份验证的并发。
  • 当用户集体重新验证新的群集节点时，需要容纳激增，例如群集故障转移。
  • 单个客户端系统（例如群集）可能也需要优化。

规划

很长一段时间以来，对于 AD DS 大小的通常建议是放入与数据库大小相同的 RAM。 现在，使用它们的 AD DS 环境和生态系统已经变得更大了，事情已经发生了变化。 尽管计算能力的提高和从 x86 体系结构到 x64 体系结构的切换使得性能大小的微妙方面与在物理机器上运行 AD DS 的客户无关，但虚拟化使优化成为一个更大的问题。

为了解决这些问题，以下部分介绍了如何确定和规划 Active Directory 即服务的需求。 无论环境是物理环境、虚拟化环境还是混合环境，都可以将这些准则应用于任何环境。 为了最大限度地提高性能，你的目标应该是让 AD DS 环境尽可能接近处理器极限。

RAM

RAM 中可以缓存的存储越多，对磁盘的需求就越少。 为了最大限度地提高服务器的可扩展性，你使用的最小 RAM 量应等于当前数据库大小、总系统值大小、操作系统的建议量以及供应商对代理（防病毒程序、监控、备份等）的建议量的总和。 还应该包括额外的 RAM，以适应服务器生命周期内的未来增长。 这一估计将根据数据库增长和环境变化而变化。

对于最大化 RAM 既不划算也不可行的环境（例如，卫星位置或目录信息树 (DIT) 太大时），请跳到存储，以确保你的存储配置正确。

调整内存大小的另一个重要因素是页面文件大小。 在磁盘大小方面，就像其他与内存相关的事情一样，目标是最大限度地减少磁盘使用。 具体而言，需要多少 RAM 来最大程度地减少分页？ 接下来的几节将为你提供回答此问题所需的信息。 其他不一定影响 AD DS 性能的页面大小考虑因素包括操作系统 (OS) 建议和为内存转储配置系统。

由于许多复杂的因素，确定域控制器 (DC) 需要多少 RAM 可能很困难：

  • 现有系统并不总是 RAM 需求的可靠指标，因为本地安全机构子系统服务 (LSSAS) 在内存压力条件下削减了 RAM，人为地降低了需求。
  • 单个 DC 只需缓存其客户端感兴趣的数据。 这意味着缓存在不同环境中的数据将根据它包含的客户端类型而变化。 例如，在具有 Exchange Server 的环境中，DC 将收集与仅对用户进行身份验证的 DC 不同的数据。
  • 根据具体情况评估每个 DC 的 RAM 所需的工作量通常过大，并且会随着环境的变化而变化。

建议背后的标准可以帮助你做出更明智的决策：

  • RAM 中的缓存越多，对磁盘的需求就越少。
  • 存储是计算机最慢的部件。 基于主轴和 SSD 存储媒体的数据访问速度比 RAM 中的数据访问慢一百万倍。

RAM 虚拟化注意事项

优化 RAM 的目标是尽量减少在磁盘上花费的时间。 还应该避免主机上的内存超额提交。 在虚拟化方案中，内存超额提交是指系统为来宾分配的 RAM 比物理机器本身上存在的 RAM 多。 虽然超额提交本身不是问题，但当所有来宾使用的总内存超过主机 RAM 的容量时，会导致主机分页。 在 DC 访问 NTDS.nit 或页面文件以获取数据，或者主机访问磁盘以尝试访问 RAM 数据的情况下，分页会使性能磁盘受限。 因此，这一过程极大地降低了性能和整体用户体验。

计算摘要示例

组件 估计内存（示例）
基本操作系统推荐的 RAM （Windows Server 2008） 2 GB
LSASS 内部任务 200 MB
监视代理 100 MB
防病毒 100 MB
数据库（全局编录） 8.5 GB
用于执行备份的缓冲，以便管理员登录而不会受到影响 1GB
总计 12 GB

建议：16 GB

随着时间的推移，更多的数据被添加到数据库中，服务器的平均寿命约为三到五年。 根据 333% 的增长估计，16 GB 是放置在物理服务器中的合理 RAM 容量。

网络

本节将评估部署需要多少总带宽和网络容量，包括客户端查询、组策略设置等。 可以使用 Network Interface(*)\Bytes Received/sec 和 Network Interface(*)\Bytes Sent/sec 性能计数器收集数据以进行估计。 网络接口计数器的采样间隔应为 15、30 或 60 分钟。 低于这一数值的波动太大，无法进行良好的测量；而高于这一数值则会使每日峰值变得过于平滑。

注意

通常，DC 上的大多数网络流量都是在 DC 响应客户端查询时的出站流量。 因此，本节主要侧重于出站流量。 但是，我们还建议你对入站流量的每个环境进行评估。 也可以使用本文中的指南来评估入站网络流量要求。 更多详细信息，请参阅 929851：TCP/IP 的默认动态端口范围在 Windows Vista 和 Windows Server 2008 中已更改。

带宽需求

网络可伸缩性计划包括两个不同的类别：流量和来自网络流量的 CPU 负载。

在规划流量支持的容量时，你需要考虑两件事。 首先，需要知道 DC 之间有多少 Active Directory 复制流量。 其次，必须评估站点内客户端到服务器的流量。 相对于发送回客户端的大量数据，站点内流量主要接收来自客户端的小型请求。 对于每台服务器最多 5,000 个用户的环境，100 MB 通常就足够了。 对于超过 5,000 个用户的环境，建议改用 1 GB 网络适配器和接收端缩放 (RSS) 支持。

若要评估站点内流量容量，特别是在服务器整合方案中，应查看站点中所有 DC 的 Network Interface(*)\Bytes/sec 性能计数器，将它们加在一起，然后将总和除以 DC 的目标数。 计算此数字的一种简单方法是打开 Windows 可靠性和性能监视器，并查看堆积面积图视图。 确保所有计数器的比例相同。

让我们看一个更复杂的方法示例，以验证此一般规则是否适用于特定环境。 在本示例中，我们做出了以下假设：

  • 目标是尽可能减少服务器占用空间。 理想情况下，一台服务器承载负载，然后部署另一台服务器以实现冗余（n + 1 方案）。
  • 在此方案中，当前网络适配器仅支持 100 MB，并且处于交换环境中。
  • 在 n 方案（丢失 DC）中，目标网络带宽的最大利用率为 60%。
  • 每个服务器大约连接到 10,000 个客户端。

现在，让我们看看 Network Interface(*)\Bytes Sent/sec 计数器中的图表对这个示例方案的描述：

  1. 工作日从早上 5:30 左右开始，到晚上 7:00 结束。
  2. 最繁忙的时段是从上午 8:00 到上午 8:15，在最繁忙的 DC 上每秒发送的字节数超过 25 字节。

    注意

    所有性能数据都是历史数据，因此上午 8:15 的峰值数据点表示上午 8:00 至 8:15 的负载。

  3. 凌晨 4:00 之前会出现峰值，在最繁忙的 DC 上每秒发送超过 20 个字节，这可能表明来自不同时区的负载或后台基础结构活动，如备份。 由于上午 8:00 的峰值超过了这一活动，因此不相关。
  4. 站点中有五个 DC。
  5. 最大负载约为每 DC 5.5 MBps，占 100 MB 连接的 44%。 使用这些数据，我们可以估计上午 8:00 到 8:15 之间所需的总带宽为 28 MBps。

    注意

    网络接口发送/接收计数器以字节为单位，但以位为单位测量网络带宽。 因此，若要计算总带宽，需要执行 100 MB ÷ 8 = 12.5 MB，1 GB ÷ 8 = 128 MB。

现在我们已经回顾了数据，我们可以从中得出哪些结论？

  • 当前环境在 60% 的目标利用率下满足 n + 1 级容错能力。 使一个系统脱机将使每台服务器的带宽从约 5.5 MBps (44%) 转移到约 7 MBps (56%)。
  • 基于之前所述的整合到一台服务器的目标，此更改超过了最大目标利用率和 100 MB 连接的可能利用率。
  • 对于 1 GB 的连接，此值占总容量的 22%。
  • 在 n + 1 方案的正常操作条件下，客户端负载相对均匀地分布，每台服务器约为 14 Mbps，占总容量的 11%。
  • 为了确保在DC不可用时有足够的容量，每台服务器的正常操作目标约为 30% 的网络利用率或每台服务器 38 MBps。 故障转移目标是 60% 的网络利用率或每台服务器 72 Mbps。

最终的系统部署必须具有 1 GB 网络适配器，并连接到将支持所述负载的网络基础结构。 由于网络流量很大，来自网络通信的 CPU 负载可能会限制 AD DS 的最大可伸缩性。 你可以使用相同的过程来估计到 DC 的入站通信。 但是，在大多数情况下，不需要计算入站流量，因为它小于出站流量。

请务必确保硬件在每台服务器超过 5,000 个用户的环境中支持 RSS。 对于高网络流量方案，均衡中断负载可能是一个瓶颈。 可以通过检查 Processor(*)\% Interrupt Time 计数器来检测潜在的瓶颈，以确定中断时间是否在 CPU 之间分布不均。 支持 RSS 的网络接口控制器 (NIC) 可以减轻这些限制并提高可伸缩性。

注意

可以采用类似的方法来估计在整合数据中心或停用卫星位置的 DC 时是否需要更多容量。 若要估计所需的容量，只需查看客户端的出站和入站流量数据。 其结果是广域网 (WAN) 链路中存在大量流量。

在某些情况下，由于流量较慢（例如证书检查无法满足 WAN 上的激进超时），因此可能会导致比预期更多的流量。 出于此原因，WAN 大小调整和利用率应该是一个迭代的持续过程。

网络带宽的虚拟化注意事项

对于支持超过 5,000 个用户的服务器，物理服务器的典型建议是 1 GB。 一旦多个来宾开始共享基础虚拟交换机基础架构，你应该格外注意主机是否有足够的网络带宽来支持系统中的所有来宾。 无论网络中是否包含作为 VM 在主机上运行的 DC，网络流量是通过虚拟交换机还是直接连接到物理交换机，都需要考虑带宽。 虚拟交换机是上行链路必须支持连接传输的数据量的组件，这意味着链接到交换机的物理主机网络适配器应该能够支持 DC 负载以及共享连接到物理网络适配器的虚拟交换机的所有其他来宾。

网络计算摘要示例

下表包含我们可以用来计算网络容量的示例方案中的值：

系统 峰值带宽
DC 1 6.5 MBps
DC 2 6.25 MBps
DC 3 6.25 MBps
DC 4 5.75 MBps
DC 5 4.75 MBps
总计 28.5 MBps

根据此表，建议的带宽为 72 MBps (28.5 MBps ÷ 40%)。

目标系统计数 总带宽（从上方）
2 28.5 MBps
由此产生的常规行为 28.5 ÷ 2 = 14.25 MBps

与往常一样，你应该假设客户端负载会随着时间的推移而增加，因此你应该尽早为这种增长做好计划。 建议你计划至少 50% 的估计网络流量增长。

存储

在规划存储容量时，你应该考虑两件事：

  • 容量或存储大小
  • 性能

虽然容量很重要，但一定不要忽视性能。 以目前的硬件成本来看，大多数环境都不够大，这两个因素都不是主要问题。 因此，通常的建议是只放入与数据库大小相同的 RAM。 然而，对于更大环境中的卫星位置来说，这一建议可能有些过头了。

大小调整

评估存储

与 Active Directory 首次出现时相比，当时 4 GB 和 9 GB 驱动器是最常见的驱动器大小，现在除了最大的环境外，Active Directory 的大小甚至不是所有环境的考虑因素。 使用 180 GB 范围内的最小可用硬盘驱动器大小，整个操作系统、SYSVOL 和 NTDS.dit 可以轻松地安装在单个驱动器上。 因此，我们建议你避免在这方面投入过多资金。

我们唯一的建议是，你应确保 NTS.dit 大小的 110% 可用，以便对存储进行碎片整理。 除此之外，在适应未来的增长时，你应该采取通常的考虑因素。

如果要评估存储，则首先必须评估 NTDS.dit 和 SYSVOL 需要多大。 这些测量值将帮助你确定固定磁盘和 RAM 分配的大小。 因为这些组件的成本相对较低，所以在计算时不需要非常精确。 有关存储评估的详细信息，请参阅 Active Directory 用户和组织单位的存储限制和增长估计。

注意

上一段中链接的文章基于在 Windows 2000 中发布 Active Directory 期间进行的数据大小估计。 在进行自己的估计时，请使用反映环境中对象实际大小的对象大小。

当你查看具有多个域的现有环境时，你可能会注意到数据库大小的变化。 发现这些变体时，请使用最小的全局目录 (GC) 和非 GC 大小。

数据库大小可能因 OS 版本而异。 运行早期操作系统版本的 DC（如 Windows Server 2003）的数据库大小比运行更高版本（如 Windows Server 2008 R2）的 DC 要小。 启用了 Active Directory 回收站或凭据漫游等功能的 DC 也会影响数据库大小。

注意

  • 对于新环境，请记住，同一域中的 100,000 名用户占用大约 450 MB 的空间。 填充的属性会对占用的总空间量产生巨大影响。 属性由来自第三方和 Microsoft 产品（包括 Microsoft Exchange Server 和 Lync）的许多对象填充。 因此，建议根据环境的产品组合进行评估。 但是，还应该记住，除了最大的环境外，为所有环境进行精确估计的数学和测试可能不值得花费大量时间或精力。
  • 确保可用空间为 NTDS.dit 大小的 110%，以启用脱机碎片整理。 此可用空间还允许你在服务器三到五年的硬件使用寿命期间规划增长。 如果你有足够的存储空间，那么分配足够的可用空间以相当于 DIT 的 300% 用于存储是适应增长和碎片整理的安全方法。

存储虚拟化注意事项

在将多个虚拟硬盘 (VHD) 文件分配给单个卷的情况下，应使用至少为 DIT 大小 210% 的固定状态磁盘（DIT 的 100% + 110% 可用空间），以确保有足够的空间来满足需求。

存储计算摘要示例

下表列出了用于估计假设存储方案的空间需求的值。

从评估阶段收集的数据 大小
NTDS.dit 大小 35 GB
允许脱机碎片整理的修饰符 2.1 GB
所需的总存储空间 73.5 GB

注意

存储估算还应包括 SYSVOL、OS、页面文件、临时文件、本地缓存数据（如安装程序文件和应用程序）所需的存储量。

存储性能

存储是计算机中速度最慢的组件，对客户端体验的负面影响最大。 对于足够大的环境，本文中的 RAM 大小建议不可行，忽视存储容量规划的后果可能会对系统性能造成毁灭性的影响。 可用存储技术的复杂性和多样性进一步增加了风险，因为将 OS、日志和数据库放在单独的物理磁盘上的典型建议并不适用于所有方案。

有关磁盘的旧建议假定磁盘是允许隔离 I/O 的专用主轴。 由于引入了以下存储类型，这一假设不再成立：

  • RAID
  • 新的存储类型以及虚拟化和共享存储方案
  • 存储区域网络（SAN）上的共享主轴
  • SAN 或网络连接存储上的 VHD 文件
  • 固态硬盘 (SSDs)
  • 分层存储体系结构，例如 SSD 存储层缓存更大的基于主轴的存储

共享存储（如 RAID、SAN、NAS、JBOD、存储空间 和 VHD）可能会被放置在后端存储上的其他工作负载过载。 这些类型的存储也带来了额外的挑战：物理磁盘和 AD 应用程序之间的 SAN、网络或驱动程序问题可能会导致限制和延迟。 需要澄清的是，这些配置并不糟糕，但它们更复杂，这意味着你需要额外注意确保每个组件都按预期工作。 有关更详细的说明，请参阅本文后面的附录 C 和附录 D。 此外，虽然 SSD 不受一次只能处理一个 I/O 的硬盘驱动器的限制，但它们仍然有可能重载的 I/O 限制。

总之，无论存储体系结构如何，所有存储性能规划的目标是确保所需数量的 I/O 始终可用，并在可接受的时间范围内发生。 有关本地附加存储的方案，请参阅附录 C，了解有关设计和规划的详细信息。 可以将附录中的原则应用于更复杂的存储方案，以及与支持后端存储解决方案的供应商进行对话。

由于目前可用的存储选项很多，我们建议你在规划时咨询硬件支持团队或供应商，以确保解决方案满足 AD DS 部署的需求。 在这些对话中，你可能会发现以下性能计数器很有用，特别是当数据库对于 RAM 来说太大时：

  • LogicalDisk(*)\Avg Disk sec/Read（例如，如果 NTDS.dit 存储在驱动器 D 上，则完整路径为 LogicalDisk(D:)\Avg Disk sec/Read）
  • LogicalDisk(*)\Avg Disk sec/Write
  • LogicalDisk(*)\Avg Disk sec/Transfer
  • LogicalDisk(*)\Reads/sec
  • LogicalDisk(*)\Writes/sec
  • LogicalDisk(*)\Transfers/sec

当你提供数据时，你应该确保以 15、30 或 60 分钟的间隔对其进行采样，以尽可能准确地反映你当前的环境。

评估结果

本节重点介绍从数据库读取数据，因为数据库通常是要求最高的组件。 通过替换 <NTDS Log>)\Avg Disk sec/Write 和 LogicalDisk(<NTDS Log>)\Writes/sec)，可以将相同的逻辑应用于对日志文件的写入。

LogicalDisk(<NTDS>)\Avg Disk sec/Read 计数器显示当前存储的大小是否足够大。 如果该值大致等于磁盘类型的预期磁盘访问时间，则 LogicalDisk(<NTDS>)\Reads/sec 计数器是一个有效的度量值。 如果结果大致等于磁盘类型的磁盘访问时间，则 LogicalDisk(<NTDS>)\Reads/sec 计数器是一个有效的度量值。 虽然这可能会因后端存储的制造商规格而异，但适合 LogicalDisk(<NTDS>)\Avg Disk sec/Read 的范围大致如下：

  • 7200 RPM：9 到 12.5 毫秒 (ms)
  • 10,000 RPM：6 到 10 ms
  • 15,000 RPM：4 到 6 ms
  • SSD – 1 至 3 ms

你可能会从其他源中听到存储性能在 15 ms 到 20 ms 时降级。 这些值与前一列表中的值之间的区别在于，列表值显示了正常工作范围。 其他值用于故障排除目的，帮助你识别客户端体验何时下降到明显程度。 有关详细信息，请参阅附录 C。

  • LogicalDisk(<NTDS>)\Reads/sec 是系统当前正在执行的 I/O 量。
    • 如果 LogicalDisk(<NTDS>)\Avg Disk sec/Read 处于后端存储的最佳范围内，则可以直接使用 LogicalDisk(<NTDS>)\Reads/sec 来调整存储大小。
    • 如果 LogicalDisk(<NTDS>)\Avg Disk sec/Read 不在后端存储的最佳范围内，则需要根据以下公式进行额外 I/O：LogicalDisk(<NTDS>)\Avg Disk sec/Read ÷ 物理媒体磁盘访问时间 × LogicalDisk(<NTDS>)\Avg Disk sec/Read

当进行这些计算时，应该考虑以下几点：

  • 如果服务器的 RAM 量不理想，则结果值将过高，并且不够准确，无法用于规划。 但是，你仍然可以使用它们来预测最坏的情况。
  • 如果添加或优化 RAM，则还会减少读取 I/O LogicalDisk(<NTDS>)\Reads/Sec 的数量。 这种减少可能会导致存储解决方案不如原始计算所猜测的那样稳健。 遗憾的是，我们无法提供有关此语句含义的更多细节，因为计算因具体环境而异，特别是客户端负载。 但是，我们建议在优化 RAM 后调整存储大小。

性能虚拟化注意事项

与前面的部分一样，我们的目标是确保共享基础结构能够支持所有使用者的总负载。 规划以下方案时，需要牢记这一目标：

  • 在 SAN、NAS 或 iSCSI 基础结构上与其他服务器或应用程序共享相同媒体的物理 CD。
  • 使用对共享媒体的 SAN、NAS 或 iSCSI 基础结构的直通访问权限的用户。
  • 在本地共享媒体或 SAN、NAS 或 iSCSI 基础结构上使用 VHD 文件的用户。

从来宾用户的角度来看，必须通过主机访问任何存储都会影响性能，因为用户必须经过额外的代码路径才能获得访问权。 性能测试表明，虚拟化会根据主机系统使用多少处理器来影响吞吐量。 处理器利用率还受到来宾用户对主机的资源需求量的影响。 这一需求有助于你在处理虚拟化方案中的处理需求时处理的虚拟化考虑因素。 有关详细信息，请参阅附录 A。

使问题进一步复杂化的是，当前有多少存储选项可用，每种存储选项对性能的影响都大不相同。 这些选项包括直通存储、SCSI 适配器和 IDE。 从物理环境迁移到虚拟环境时，应使用 1.10 的倍数来调整虚拟化来宾用户的不同存储选项。 但是，在不同存储方案之间传输时，无需考虑调整，因为存储是本地、SAN、NAS 还是 iSCSI 更重要。

虚拟化计算示例

确定正常运行条件下正常系统所需的 I/O 量：

  • LogicalDisk(<NTDS Database Drive>) ÷ 高峰时段 15 分钟内每秒的传输数
  • 确定超出基础存储容量的存储所需的 I/O 量：

    所需的 IOPS = (LogicalDisk(<NTDS Database Drive>)) ÷ Avg Disk Read/sec ÷ <Target Avg Disk Read/sec>) × LogicalDisk(<NTDS Database Drive>)\Read/sec

计数器 值
实际 LogicalDisk(<NTDS Database Drive>)\平均值磁盘秒数/传输 0.02 秒（20 毫秒）
目标 LogicalDisk(<NTDS Database Drive>)\平均值磁盘秒数/传输 0.01 秒
可用 I/O 更改的乘数 0.02 ÷ 0.01 = 2
值名称 值
LogicalDisk(<NTDS Database Drive>)\传输次数/秒 400
可用 I/O 更改的乘数 2
高峰期所需的总 IOPS 800

若要确定缓存的预热速率，请执行以下操作：

  • 确定缓存预热可接受的最长时间。 在典型方案中，可接受的时间量是从磁盘加载整个数据库所需的时间。 在 RAM 无法加载整个数据库的情况下，请使用填充整个 RAM 所需的时间。
  • 确定数据库的大小，不包括你不打算使用的空间。 有关详细信息，请参阅评估存储。
  • 将数据库大小除以 8 KB，得到加载数据库所需的 I/O 总数。
  • 将总 I/O 除以定义时间范围内的秒数。

你计算的数字基本准确，但可能不准确，因为你没有将（可扩展存储引擎）ESE 配置为具有固定的缓存大小，然后 AD DS 将逐出以前加载的页面，因为它默认使用可变缓存大小。

要收集的数据点 值
可接受最长预热时间 10 分钟（600 秒）
数据库大小 2 GB
计算步骤 公式 结果
计算页中数据库的大小 (2 GB × 1024 × 1024) = 数据库大小（以 KB 为单位） 2,097,152 KB
计算数据库中的页数 2,097,152 KB ÷ 8 KB = 页数 262,144 页
计算完全预热缓存所需的 IOPS 262,144 页 ÷ 600 秒 = 所需 IOPS 437 IOPS

Processing

评估 Active Directory 处理器使用情况

对于大多数环境，管理处理能力是最值得关注的组件。 在评估部署所需的 CPU 容量时，你应该考虑以下两件事：

  • 根据跟踪昂贵且效率低下的搜索中概述的标准，你环境中的应用程序在共享服务基础结构中是否按预期运行？ 在较大的环境中，编码不佳的应用程序会使 CPU 负载变得不稳定，以牺牲其他应用程序为代价，占用过多的 CPU 时间，增加容量需求，并在 DC 上不均匀地分配负载。
  • AD DS 是一个分布式环境，有许多潜在的客户端，其处理需求差异很大。 每个客户端的估计成本可能因使用模式和使用 AD DS 的应用程序数量而异。 与网络中的情况非常相似，你应该将估算视为对环境中所需总容量的评估，而不是一次查看每个客户端。

你应该在完成存储估计后才进行此估计，因为没有关于处理器负载的有效数据，你将无法做出准确的猜测。 在对处理器进行故障排除之前，确保任何瓶颈都不是由存储引起的，这一点也很重要。 当你删除处理器等待状态时，CPU 利用率会增加，因为它不再需要等待数据。 因此，最应该关注的性能计数器是 Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read 和 Process(lsass)\ Processor Time。 如果 Logical Disk(<NTDS Database Drive>)\Avg Disk sec/Read 计数器超过 10 或 15 毫秒，则 Process(lsass)\ Processor Time 中的数据人为偏低，问题与存储性能有关。 建议将采样间隔设置为 15、30 或 60 分钟，以获得尽可能准确的数据。

处理概览

要计划域控制器的容量计划，最需要关注和理解的是处理能力。 在调整系统大小以确保最佳性能时，总有一个组件是瓶颈，而在适当大小的域控制器中，这个组件就是处理器。

与按站点审查环境需求的网络部分类似，必须为所需的计算容量执行相同的操作。 与网络部分不同，其中可用的网络技术远远超过正常需求，请更加注意调整 CPU 容量的大小。 与任何中型环境一样；超过几千个并发用户的任何内容都可能会给 CPU 带来巨大的负载。

遗憾的是，由于利用 AD 的客户端应用程序存在巨大差异，因此对每个 CPU 的用户进行一般估计无法适用于所有环境。 具体而言，计算需求受用户行为和应用程序配置文件的约束。 因此，每个环境都需要单独调整大小。

目标网站行为配置文件

当你为整个网站进行容量规划时，你的目标应该是 N + 1 容量设计。 在这种设计中，即使一个系统在高峰期发生故障，服务仍然可以在可接受的质量水平上继续。 在 N 方案中，在高峰时段，所有框的负载应小于 80%-100%。

此外，该站点的应用程序和客户端使用推荐的 DsGetDcName 函数方法来定位 DC，它们应该已经均匀分布，只有轻微的暂时性峰值。

现在，我们将了解两个符合目标和偏离目标的环境示例。 首先，我们将看一个按预期工作且不超过容量规划目标的环境示例。

对于第一个示例，我们将做出以下假设：

  • 站点中的五个 DC 中的每一个都有四个 CPU。
  • 在正常操作条件 (N + 1) 下，工作时间的总目标 CPU 利用率为 40%，否则为 60% (N)。 在非工作时间，目标 CPU 使用率为 80%，因为我们预计备份软件和其他维护过程会消耗所有可用资源。

现在，让我们了解每个 DC 的 (Processor Information(_Total)\% Processor Utility) 图表，如下图所示。

每个域控制器的 CPU 使用率图表的屏幕截图。

  • 负载分布相对均匀，这是我们在客户端使用 DC 定位器和编写良好的搜索时所期望的。

  • 在几个五分钟的时间间隔内，会出现 10% 的峰值，有时甚至是 20%。 但是，除非这些高峰导致 CPU 使用率超过容量计划目标，否则你不需要对其进行调查。

  • 所有系统的高峰时段在上午 8:00 至 9:15 之间。 平均工作日从早上 5:00 持续到下午 5:00。 因此，在下午 5:00 到凌晨 4:00 之间发生的任何随机 CPU 使用高峰都是在工作时间之外，因此你不需要将其纳入容量规划问题中。

    注意

    在管理良好的系统中，非高峰时段发生的峰值通常是由备份软件、全系统防病毒扫描、硬件或软件清单、软件或补丁部署等引起的。 因为这些峰值发生在营业时间之外，所以它们不计入超出容量规划目标。

  • 由于每个系统大约占 40%，而且它们都有相同数量的 CPU，因此如果其中一个系统脱机，其余系统的运行率估计为 53%。 系统 D 具有 40% 的负载，该负载被平均分配并添加到系统 A 和 C 现有的 40% 负载中。 这种线性假设并不完全准确，但提供了足够的准确性来衡量。

接下来，让我们来看一个 CPU 使用率不高且超出容量规划目标的环境示例。

在本例中，我们有两个 DC 以 40% 的速度运行。 一个域控制器脱机，导致剩余 DC 上的估计 CPU 使用率达到 80%。 这种 CPU 使用水平远远超过了容量计划的阈值，并开始限制负载配置文件的 10% 到 20% 的剩余空间。 因此，在 N 方案中，每个峰值都可能将 DC 驱动到 90% 甚至 100%，从而降低其响应能力。

计算 CPU 需求

Process\% Processor Time 性能计数器跟踪所有应用程序线程在 CPU 上花费的总时间，然后将该总和除以经过的系统总时间。 多 CPU 系统上的多线程应用程序可能会超过 100% 的 CPU 时间，并且你对其数据的解释与 Processor Information\% Processor Utility 计数器非常不同。 在实践中，Process(lsass)\% Processor Time 计数器跟踪系统需要多少 CPU 以 100% 的速度运行以支持进程的需求。 例如，如果计数器的值为 200%，则意味着系统需要两个以 100% 运行的 CPU 来支持完整的 AD DS 负载。 尽管在功耗和能耗方面，以 100% 容量运行的 CPU 是最具成本效益的；但出于附录 A 中概述的原因，当多线程系统的系统不是 100% 运行时，它的响应速度更快。

为了适应客户端负载的瞬时峰值，我们建议你将峰值时段 CPU 的目标设置在系统容量的 40% 到 60% 之间。 例如，在目标站点行为配置文件的第一个示例中，需要 3.33 个 CPU（60% 目标）和 5 个 CPU（40% 目标）来支持 AD DS 负载。 应根据操作系统和任何其他所需代理（如防病毒、备份、监控等）的需求添加额外容量。 虽然应在每个环境的基础上评估代理对 CPU 代理的影响，但通常可以在单个 CPU 上为代理进程分配 5% 到 10% 的空间。 再来看看我们的示例，我们需要 3.43（60% 目标）和 5.1（40% 目标）CPU 来支持高峰期间的负载。

现在，让我们来看一个计算特定流程的示例。 在本例中，我们将了解 LSASS 进程。

计算 LSASS 进程的 CPU 使用率

在此示例中，系统是一个 N + 1 方案，其中一台服务器承载 AD DS 负载，而另一台服务器则用于冗余。

下图显示了此示例方案中 LSASS 进程在所有处理器上的处理器时间。 此数据是从 Process(lsass)\% Processor Time 性能计数器收集的。

进程 LSASS 处理器时间性能计数器跨所有处理器的时间图表的屏幕截图。

下面是这个图表告诉我们关于方案环境的内容：

  • 站点中有三个域控制器。
  • 工作日在上午 7:00 左右开始上升，然后在下午 5:00 下降。
  • 一天中最繁忙的时段是上午 9:30 至上午 11:00。

    注意

    所有性能数据都是历史数据。 上午 9:15 的峰值数据点表示上午 9:00 至 9:15 的负载。

  • 上午 7:00 之前的峰值可能表明来自不同时区或后台基础结构活动（如备份）的额外负载。 然而，由于这一峰值低于上午 9:30 的峰值活动，因此无需担心。

在最大负载下，lsass 进程以 100% 的速度消耗大约 4.85 个 CPU，在单个 CPU 上消耗 485%。 这些结果表明，方案站点需要大约 12/25 个 CPU 来处理 AD DS。 为后台进程引入建议的 5% 到 10% 的额外容量时，服务器需要 12.30 到 12.25 个 CPU 来支持其当前负载。 对未来增长的预测使这一数字更高。

何时优化 LDAP 权重

在某些情况下，应考虑优化 LdapSrvWeight。 在容量规划的上下文中，当你的应用程序、用户负载或基础系统功能不均衡时，需要对其进行调优。

以下部分介绍了两个示例方案，应在其中优化轻量级目录访问协议 (LDAP) 权重。

示例 1：PDC 模拟器环境

如果使用主域控制器 (PDC) 模拟器，则分布不均匀的用户或应用程序行为可能会同时影响多个环境。 PDC 模拟器上的 CPU 资源通常比部署中的其他地方要求更高，因为有多个工具和操作以它为目标，例如组策略管理工具、二次身份验证尝试、信任建立等。

  • 仅当 CPU 使用率存在明显差异时，才应优化 PDC 模拟器。 优化应减少 PDC 模拟器上的负载，并增加其他 DC 上的负载，从而实现更均匀的负载分布。
  • 在这些情况下，将 PDC 模拟器的 LDAPSrvWeight 值设置为 50 到 75 之间。
系统 使用默认值的 CPU 利用率 New LdapSrvWeight 估计的新 CPU 利用率
DC 1（PDC 仿真器） 53% 57 40%
DC 2 33% 100 40%
DC 3 33% 100 40%

问题是，如果 PDC 模拟器角色被转移或占用，特别是转移到站点中的另一个域控制器，则新 PDC 模拟器上的 CPU 利用率会急剧增加。

在此示例方案中，我们根据 目标站点行为配置文件，假设此站点中的所有三个域控制器都有四个 CPU。 在正常情况下，如果其中一个 DC 有八个 CPU，会发生什么情况？ 将有两个 DC，利用率为 40%，一个 DC 利用率为 20%。 虽然这种配置不一定很糟糕，但你有机会使用 LDAP 权重优化来更好地平衡负载。

示例 2：具有不同 CPU 计数的环境

当同一站点中的服务器具有不同的 CPU 数量和速度时，你需要确保它们均匀分布。 例如，如果你的站点有两个八核服务器和一个四核服务器，那么四核服务器的处理能力只有其他两个服务器的一半。 如果客户端负载均匀分布，这意味着四核服务器需要比两个八核服务器努力两倍来管理其 CPU 负载。 最重要的是，如果八个核心服务器中的一个脱机，四个核心服务器就会过载。

系统 Processor Information\ % Processor Utility(_Total)
使用默认值的 CPU 利用率		 New LdapSrvWeight 估计的新 CPU 利用率
4-CPU DC 1 40 100 30%
4-CPU DC 2 40 100 30%
8-CPU DC 3 20 200 30%

对“N + 1”方案进行规划至关重要。 必须针对每个方案计算一个 DC 脱机的影响。 在负载分布均匀的前一个场景中，为了确保在“N”方案中有 60% 的负载，并且负载在所有服务器上均匀平衡，由于比率保持一致，分布很好。 当你查看 PDC 模拟器优化方案，或用户或应用程序负载不平衡的任何一般方案时，效果非常不同：

系统 优化利用率 New LdapSrvWeight 估计的新利用率
DC 1（PDC 仿真器） 40% 85 47%
DC 2 40% 100 53%
DC 3 40% 100 53%

处理虚拟化注意事项

当为虚拟化环境进行容量规划时，需要考虑两个级别：主机级别和来宾级别。 在主机级别，必须确定业务周期的高峰期。 由于为虚拟机在 CPU 上计划客户线程类似于为物理机在 CPU 上计划 AD DS 线程，因此我们仍然建议使用基础主机的 40% 到 60%。 在来宾级别，由于基础线程计划原则保持不变，我们仍然建议将 CPU 使用率保持在 40% 到 60% 范围内。

在每个主机有一个来宾的直接映射方案中，必须引入在前面的部分中完成的所有容量规划估算，才能进行估算。 对于共享主机方案，对基础处理器的效率有大约 10% 的影响，这意味着如果一个站点需要 10 个 CPU，目标为 40%，那么建议在所有 N 来宾上分配的虚拟 CPU 数量为 11 个。 在物理服务器和虚拟服务器混合分布的站点中，此修饰符仅适用于虚拟机 (VM)。 例如，在 N + 1 方案中，一个具有 10 个 CPU 的物理服务器或直接映射服务器几乎等于一个主机上具有 11 个 CPU 的来宾，主机上为 DC 预留了 11 个 CPU。

在分析和计算支持 AD DS 负载所需的 CPU 数量时，请记住，如果你计划购买物理硬件，市场上在售的硬件类型可能与你的估计不完全一致。 但是，在使用虚拟化时就不会有这个问题。 使用 VM 可以减少向站点添加计算能力所需的工作量，因为你可以根据需要为 VM 添加任意数量的 CPU。 然而，虚拟化并不能免除你准确评估需要多少计算能力来保证基础硬件在来宾需要更多 CPU 时可用的责任。 和往常一样，请记住提前规划增长。

虚拟化计算摘要示例

系统 峰值 CPU
DC 1 120%
DC 2 147%
DC 3 218%
CPU 总使用率 485%
目标系统计数 总带宽（从上方）
目标为 40% 时所需的 CPU 4.85 ÷ .4 = 12.25

在此方案中提前规划增长时，如果假设在未来三年内需求将增长 50%，则需要确保到那时它有 18.375 个 CPU (12.25 × 1.5)。 或者，你可以在第一年后审查需求，然后根据结果增加额外容量。

NTLM 跨信任客户端身份验证负载

评估跨信任客户端身份验证负载

许多环境可能有一个或多个域通过信任进行连接。 对不使用 Kerberos 的其他域中的标识的身份验证请求需要使用两个域控制器之间的安全通道遍历信任。 用户试图在站点中访问的域控制器连接到另一个域控制器，该域控制器位于目标域中或通往目标域的路径上的某个位置。 DC 可以对受信任域中的其他 DC 进行多少次调用由 *MaxConcurrentAPI 设置控制。 为了确保安全通道能够处理 DC 相互通信所需的负载量，可以优化 MaxConcurrentAPI；或者如果位于林中，可以创建快捷方式信任。 请参阅如何使用 MaxConcurrentApi 设置对 NTLM 身份验证进行性能优化，了解有关如何确定跨信任的流量的详细信息。

与前面的方案一样，必须在一天中的高峰时段收集数据，才能使其有用。

注意

林内和林间方案可能会导致身份验证遍历多个信任，这意味着你需要在流程的每个阶段进行优化。

虚拟化规划

在为虚拟化进行容量规划时，应记住以下几点：

  • 许多应用程序默认或在某些配置中使用网络级别信任管理器 (NTLM) 身份验证。
  • 随着活动客户端数量的增加，对应用服务器容量的需求也在增加。
  • 客户端有时会在有限的时间内保持会话打开状态，而不是定期重新连接，以实现电子邮件拉取同步等服务。
  • 需要身份验证才能访问 Internet 的 Web 代理服务器可能会导致 NTLM 负载过高。

这些应用程序可能会给 NTLM 身份验证带来很大的负载，这会给 DC 带来很大的压力，尤其是在用户和资源位于不同域的情况下。

可以采取许多方法来管理跨信任负载，这些方法通常可以而且应该同时使用：

  • 通过在用户所在的域中查找用户使用的服务来减少跨信任客户端身份验证。
  • 增加可用的安全渠道数目。 这些通道称为快捷方式信任，与林内和跨林流量相关。
  • 优化 MaxConcurrentAPI 的默认设置。

要在现有服务器上优化 MaxConcurrentAPI，请使用以下公式：

New_MaxConcurrentApi_setting ≥ (semaphore_acquires + semaphore_time-outs) × average_semaphore_hold_time ÷ time_collection_length

有关详细信息，请参阅知识库文章 2688798：如何使用 MaxConcurrentApi 设置对 NTLM 身份验证执行性能调整。

虚拟化注意事项

无需考虑任何特殊事项，因为虚拟化是一种操作系统优化设置。

虚拟化优化计算示例

Data type 值
信号灯获取（最小值） 6,161
信号灯获取（最大值） 6,762
信号量超时 0
平均信号灯保持时间 0.012
收集持续时间（秒） 1:11 分钟（71 秒）
公式（来自知识库 2688798） ((6762 - 6161) + 0) × 0.012 /
MaxConcurrentAPI 的最小值 ((6762 - 6161) + 0) × 0.012 ÷ 71 = 0.101

对于此时间段的此系统，默认值是可接受的。

监视容量计划目标的合规性

在本文中，我们讨论了如何规划和扩展以实现利用率目标。 下表汇总了为确保系统按预期运行而必须监视的推荐阈值。 请记住，这些不是性能阈值，只是容量规划阈值。 运行超过这些阈值的服务器仍然可以工作；但随着用户需求的增加，在开始看到性能问题之前，你需要验证应用程序是否按预期工作。 如果应用程序正常，则应开始评估硬件升级或其他配置更改。

类别 性能计数器 间隔/采样 目标 警告
处理器 Processor Information(_Total)\% Processor Utility 60 分钟 40% 60%
RAM（Windows Server 2008 R2 或更低版本） 内存\可用 MB < 100 MB 不可用 < 100 MB
RAM（Windows Server 2012） 内存\长期平均待机缓存生存期（秒） 30 分钟 必须测试 必须测试
网络 Network Interface(*)\Bytes Sent/sec

Network Interface(*)\Bytes Received/sec

 30 分钟 40% 60%
存储 LogicalDisk((<NTDS Database Drive>))\Avg Disk sec/Read

LogicalDisk((<NTDS Database Drive>))\Avg Disk sec/Write

 60 分钟 10 毫秒 15 毫秒
AD 服务 Netlogon(*)\Average Semaphore Hold Time 60 分钟 0 1 秒

附录 A：CPU 大小调整条件

本附录介绍了可以帮助你估计环境 CPU 调整大小需求的有用术语和概念。

定义：CPU 调整大小

  • 处理器（微处理器）是读取和执行程序指令的组件。

  • 多核处理器在同一个集成电路上具有多个 CPU。

  • 多 CPU 系统具有不在同一集成电路上的多个 CPU。

  • 从操作系统的角度来看，逻辑处理器是一种只有一个逻辑计算引擎的处理器。

这些定义包括超线程、多核处理器上的单核或单核处理器。

由于当今的服务器系统具有多个处理器、多个多核处理器和超线程，因此这些定义被概括为涵盖这两种情况。 我们使用术语“逻辑处理器”，因为它代表了可用计算引擎的 OS 和应用程序视角。

线程级并行度

每个线程都是独立的任务，因为每个线程都有自己的堆栈和指令。 AD DS 是多线程的，你可以按照如何使用 Ntdsutil.exe 在 Active Directory 中查看和设置 LDAP 策略中的说明优化可用线程数，它可以跨多个逻辑处理器很好地扩展。

数据级并行度

数据级并行是指服务在同一进程的多个线程之间共享数据，并在多个进程之间共享多个线程。 AD DS 进程本身将被视为在单个进程的多个线程之间共享数据的服务。 对数据的任何更改都会反映在缓存所有级别的所有运行线程、每个核心以及共享内存的任何更新中。 在写入操作期间，性能可能会下降，因为在指令处理继续之前，所有内存位置都会根据变化进行调整。

CPU 速度与多核注意事项

通常，更快的逻辑处理器可以减少处理一系列指令所需的时间。 更多的逻辑处理器意味着可以同时运行更多任务。 但是，这些规则不适用于更复杂的方案，例如从共享内存提取数据、等待数据级并行性以及同时管理多个线程的开销。 因此，多核系统中的可伸缩性不是线性的。

要理解为什么会发生这种变化，不妨将这些方案想象成高速公路，会有所帮助。 每个线程都是一辆车，每条车道都是一个核心，速度限制就是时钟速度。

如果高速公路上只有一辆车，那么有两车道还是 12 车道都无所谓。 那辆车只在速度限制允许的范围内行驶。

如果线程需要的数据不是立即可用的，那么线程在从内存中获取相关数据之前就无法处理指令。 这就像高速公路的一段被关闭。 即使高速公路上只有一辆车，限速也不会影响它的行驶能力，因为在道路重新开放之前，它哪儿也去不了。

随着汽车数量的增加，高速公路管理汽车数量所需的开销也会增加。 在交通高峰期开车时，司机需要更加集中注意力，而不是在深夜，路上几乎没有人。 此外，在双车道高速公路上驾驶时，你只需要担心另一条车道；而在六车道高速公路上行驶时，你需要注意其他五条车道。

总之，关于是否应该添加更多或更快的处理器的问题变得非常主观，应该逐案考虑。 特别是对于 AD DS，其处理需求取决于环境因素，并且在单个环境中可能因服务器而异。 因此，本文前面的部分没有在进行超精确计算方面投入大量精力。 当你做出预算驱动的购买决策时，我们建议你首先将处理器使用率优化为 40% 或你的特定环境所需的任何数字。 如果你的系统没有优化，那么你就不会从购买额外的处理器中受益。

注意

此概念与阿姆达尔定律和古斯塔夫松定律有关。

响应时间以及系统活动级别如何影响性能

排队理论是对排队或队列的数学研究。 在计算的排队理论中，利用率定律由 t 方程表示：

U k = B ÷ T

其中 U k 是利用率百分比，B 是繁忙时间，T 是观察系统的总时间。 在 Microsoft 上下文中，这意味着处于运行状态的100 纳秒 (ns) 间隔线程的数量除以给定时间间隔内可用的 100 ns 间隔的数量。 这是与计算处理器对象和 PERF_100NSEC_TIMER_INV 中显示的处理器利用率百分比的公式相同。

排队论还提供了以下公式：N = U k ÷ (1 - U k)，用于根据利用率估计等待项目的数量，其中 N 是队列的长度。 在所有利用率间隔上绘制此方程的图表，可以得出以下估计值，即在任何给定的 CPU 负载下，队列在处理器上的停留时间。

一个折线图，显示了随着 CPU 负载的增加，队列进入处理器需要多长时间。队列长度随着 CPU 利用率的增加而变长。

基于这一估计，我们可以观察到，在 50% 的 CPU 负载后，平均等待时间通常会在队列中包含另一个项目，并迅速增加到 70% 的 CPU 利用率。

为了理解排队理论如何应用于 AD DS 部署，让我们回到在 CPU 速度与多核考虑因素中使用的高速公路隐喻。

下午较繁忙时段将达到 40% 至 70% 的运力范围。 有足够的交通流量，你选择车道行驶的能力不会受到严重限制。 虽然其他司机挡住你的路的可能性很高，但这并不需要你像在高峰时段那样努力在车道上的其他车辆之间找到一个安全的空隙。

随着高峰时间的临近，道路系统的运力接近 100%。 在高峰时段变道变得非常具有挑战性，因为车辆靠得太近，你在变道时没有太多的回旋余地。

这就是为什么将容量的长期平均值估计为 40% 可以为异常负载峰值留出更多空间，无论这些峰值是暂时的（例如，编码不佳的查询需要一段时间才能运行），还是一般负载的异常突增（例如，假日周末后第二天早上的活动尖峰）。

前面的陈述认为处理器时间计算的百分比与利用率定律方程相同。 这个简化版本旨在向新用户介绍这一概念。 但是，对于更高级的数学，可以使用以下参考作为指南：

  • 转换 PERF_100NSEC_TIMER_INV
    • B = 空闲线程在逻辑处理器上花费的 100 ns 间隔数。 PERF_100NSEC_TIMER_INV 更改计算中的 X 变量
    • T = 给定时间范围内 100 ns 间隔的总数。 PERF_100NSEC_TIMER_INV 更改计算中的 Y 变量。
    • U k = 逻辑处理器的利用率百分比（按“空闲线程”或空闲时间百分比）。
  • 数学计算：
    • U k = 1 – %Processor Time
    • %Processor Time = 1 – U k
    • %Processor Time = 1 – B / T
    • %Processor Time = 1 – X1 – X0 / Y1 – Y0

将这些概念应用于容量规划

上一节中的数学可能会使确定系统中需要多少逻辑处理器看起来非常复杂。 因此，调整系统大小的方法应侧重于根据当前负载确定最大目标利用率，然后计算需要达到该目标的逻辑处理器数。 此外，你的估计不需要完全准确。 虽然逻辑处理器速度确实对同步产生了重大影响，但性能也可能受到其他方面的影响：

  • 缓存效率
  • 内存一致性要求
  • 线程计划和同步
  • 客户端负载不完全均衡

由于计算能力相对低成本，因此不值得花费太多时间来计算所需 CPU 的精确数量。

同样重要的是要记住，在这种情况下，40% 的建议不是强制性要求。 我们将其作为进行计算的合理起点。 不同类型的 AD 用户需要不同的响应级别。 甚至可能存在这样的情况，即环境可以以 80% 甚至 90% 的利用率持续平均运行，而处理器访问等待时间的增加不会显著影响客户端性能。

系统中还有其他区域比逻辑处理器慢得多，你也应该优化这些区域，包括 RAM 访问、磁盘访问和通过网络传输响应。 例如：

  • 如果在磁盘占用率为 90% 的系统中添加处理器，可能不会显著提高性能。 如果更仔细地观察系统，会发现有很多线程甚至没有进入处理器，因为它们正在等待 I/O 操作完成。

  • 解决磁盘绑定问题可能意味着先前处于等待状态的线程不再被卡住，从而对 CPU 时间产生更多的争用。 因此，90% 的利用率将达到 100%。 需要优化这两个组件，以便将利用率降至可管理的水平。

    注意

    对于具有 Turbo 模式的系统，Processor Information(*)\% Processor Utility 计数器可能超过 100%。 Turbo 模式允许 CPU 在短时间内超过额定处理器速度。 如果需要更多信息，请查看 CPU 制造商的文档和计数器说明。

讨论整个系统的利用率考虑因素还涉及作为虚拟化来宾的域控制器。 响应时间以及系统活动级别如何影响性能适用于虚拟化方案中的主机和来宾。 在只有一个来宾的主机中，DC 或系统的性能几乎与物理硬件上的性能相同。 向主机添加更多来宾会提高基础主机的利用率，也会增加访问处理器的等待时间。 因此，必须在主机和来宾级别管理逻辑处理器利用率。

让我们回顾前几节中的高速公路隐喻，只是这次我们将来宾 VM 想象成一辆快车。 与公共交通或校车不同，快车直接到达乘客的目的地，中途不停靠。

现在，假设有四种方案：

  • 一个系统的非高峰时段就像深夜乘坐快车。 当乘客上车时，几乎没有其他乘客，道路几乎空无一人。 因为没有交通拥堵的公共汽车，所以乘坐起来很容易，速度也和乘客自己开车一样快。 然而，乘客的行程时间也受到当地速度限制的限制。
  • 当系统 CPU 使用率过高时，非高峰时段就像在高速公路上的大多数车道关闭时深夜乘坐。 尽管公共汽车本身大部分是空的，但由于车道限制，道路仍然拥挤不堪。 虽然乘客可以自由坐在任何他们想坐的地方，但他们的实际行程时间取决于巴士外的交通状况。
  • 高峰时段 CPU 利用率高的系统就像高峰时段拥挤的公交车。 不仅旅行时间更长，而且上下车也更难，因为公交车上挤满了其他乘客。 向来宾系统添加更多的逻辑处理器，以尝试加快等待时间，就像尝试通过增加更多公交车来解决交通问题一样。 问题不在于公交车的数量，而在于行程需要多长时间。
  • 一个在非高峰时段 CPU 利用率高的系统就像一辆拥挤的公交车在晚上几乎空无一人的道路上行驶。 虽然乘客可能很难找到座位或上下车，但一旦公交车搭载了所有乘客，旅程就相当顺利了。 此方案是唯一一种通过添加更多总线来提高性能的情况。

根据前面的示例，可以看到，在 0% 到 100% 的利用率之间有许多方案对性能有不同程度的影响。 此外，在非常特定的方案之外，添加更多的逻辑处理器并不一定能提高性能。 将这些原则应用于主机和来宾的建议 40% CPU 利用率目标应该相当简单。

附录 B：有关不同处理器速度的注意事项

在处理中，我们假设处理器在收集数据时以 100% 的时钟速度运行，并且任何替换系统都具有相同的处理速度。 尽管这些假设并不准确，特别是对于默认电源计划为平衡的 Windows Server 2008 R2 及更高版本，但这些假设仍然适用于保守估计。 虽然潜在的错误可能会增加，但随着处理器速度的提高，它只会增加安全裕度。

  • 例如，在需要 11.25 个 CPU 的方案中，如果在收集数据时处理器以半速运行，则对其需求的更准确估计将是 5.125 ÷ 2。
  • 无法保证时钟速度加倍会使记录时间段内发生的处理量加倍。 处理器在 RAM 或其他组件上等待的时间大致保持不变。 因此，更快的处理器在等待系统获取数据时可能会花费更多的空闲时间。 我们建议你坚持使用最低公分母，保持保守的估计，并避免假设处理器速度之间的线性比较，这可能会使你的结果不准确。

如果替换硬件中的处理器速度低于当前硬件，则应按比例增加所需处理器的估计数量。 例如，让我们看看一个场景，即计算需要 10 个处理器来维持站点的负载。 当前的处理器运行频率为 3.3 GHz，而你计划替换的处理器运行频率为 2.6 GHz。 如果只更换 10 个原始处理器，速度就会下降 21%。 为了提高速度，需要至少 12 个处理器，而不是 10 个。

然而，这种可变性不会改变容量管理处理器利用率目标。 处理器时钟速度根据负载需求动态调整，因此在较高负载下运行系统会导致 CPU 在更高时钟速度状态下花费更多时间。 最终目标是使 CPU 在高峰营业时间以 100% 的时钟速度状态达到 40% 的利用率。 在非高峰情况下，通过限制 CPU 速度，可以节省电力。

注意

通过将电源计划设置为高性能，可以在数据收集期间关闭处理器的电源管理。 关闭电源管理可以让你更准确地读取目标服务器中的 CPU 消耗量。

为了调整不同处理器的估计值，建议使用 Standard Performance Evaluation Corporation 的 SPECint_rate2006 基准。 若要使用此基准，请执行以下操作：

  1. 转到 Standard Performance Evaluation Corporation (SPEC) 网站。

  2. 选择结果。

  3. 输入 CPU2006，并选择搜索。

  4. 在可用配置的下拉菜单中，选择所有 SPEC CPU2006。

  5. 在搜索表单请求字段中，选择简单，然后选择开始！。

  6. 在简单请求下，输入目标处理器的搜索条件。 例如，如果要查找 ES-2630 处理器，请在下拉菜单中选择处理器，然后在搜索字段中输入处理器名称。 完成后，选择执行简单提取。

  7. 在搜索结果中查找服务器和处理器配置。 如果搜索引擎未返回完全匹配项，请查找最接近的匹配项。

  8. 记录结果和内核数列中的值。

  9. 使用以下公式确定修饰符：

    （（“每个核心得分值的目标平台”）×（“每个核心 MHz 的基线平台”））÷（（“每个核心得分值的基线”）×（“每个核心 MHz 的目标平台”））

    例如，下面介绍了如何查找 ES-2630 处理器的修饰符：

    (35.83 × 2000) ÷ (33.75 × 2300) = 0.92

  10. 将你估计需要的处理器数量乘以此修饰符。

    以 ES-2630 处理器为例，0.92 × 10.3 = 10.35 个处理器。

附录 C：操作系统如何与存储交互

我们在响应时间以及系统活动级别如何影响性能中讨论的排队概念也适用于存储。 为了有效地应用这些概念，你需要熟悉 OS 如何处理 I/O。 在 Windows OS 中，OS 会创建一个队列，其中包含每个物理磁盘的 I/O 请求。 但是，物理磁盘不一定是单个磁盘。 OS 还可以将阵列控制器或 SAN 上的主轴聚合注册为物理磁盘。 阵列控制器和 SAN 还可以将多个磁盘聚合为单个阵列集，将其拆分为多个分区，然后将每个分区用作物理磁盘，如下图所示。

显示两个块轴被一个分区分隔的示意图。每个块内部都有两个矩形，分别标记为 Data 1 和 Data 2，表示它存储的数据。

在此图中，两个主轴被镜像并拆分为用于数据存储的逻辑区域，标记为 Data 1 和 Data 2。 OS 将每个逻辑区域注册为单独的物理磁盘。

现在，我们已经阐明了物理磁盘的定义，你还应该熟悉以下术语，以帮助你更好地理解本附录中的信息。

  • 主轴是物理安装在服务器中的设备。
  • 阵列是由控制器聚合的主轴集合。
  • 阵列分区是聚合阵列的分区。
  • 逻辑单元号 (LUN) 是连接到计算机的 SCSI 设备阵列。 本文在讨论 SAN 时使用这些术语。
  • 磁盘包括 OS 注册为单个物理磁盘的任何主轴或分区。
  • 分区是 OS 注册为物理磁盘的逻辑分区。

操作系统体系结构注意事项

OS 为其注册的每个磁盘创建一个先进先出 (FIFO) I/O 队列。 这些磁盘可以是主轴、阵列或阵列分区。 当涉及到 OS 如何处理 I/O 时，活动队列越多越好。 当 OS 对 FIFO 队列进行序列化时，它必须按到达顺序处理向存储子系统发出的所有 FIFO I/O 请求。 当 OS 将每个磁盘与主轴或阵列相关联时，它为每个唯一的磁盘集维护一个 I/O 队列，从而消除了磁盘之间对稀缺 I/O 资源的争用，并将 I/O 需求隔离到单个磁盘。 但是，Windows Server 2008 引入了一个例外，即 I/O 优先级。 无论 OS 何时收到，设计为使用低优先级 I/O 的应用程序都会被移动到队列的后面。 未专门编码为使用低优先级设置的应用程序默认为正常优先级。

简单存储子系统简介

在本节中，我们将讨论简单的存储子系统。 让我们从一个示例开始：计算机内的单个硬盘驱动器。 如果我们将此系统分解为其主要存储子系统组件，我们会得到以下结果：

  • 一个 10,000 RPM 超高速 SCSI 硬盘（超高速 SCSI 的传输速率为 20 MBps）
  • 1 条 SCSI 总线（电缆）
  • 一个超高速 SCSI 适配器
  • 1 个 32 位 33 MHz PCI 总线

注意

此示例没有反映磁盘缓存，系统通常在磁盘缓存中保存一个柱面的数据。 在这种情况下，第一个 I/O 需要 10 ms，磁盘读取整个柱面。 所有其他顺序 I/O 都由缓存满足。 因此，磁盘内缓存可以提高顺序 I/O 性能。

一旦确定了组件，就可以开始了解系统可以传输多少数据以及可以处理多少 I/O。 I/O 的数量和系统可以传输的数据量是相互关联的，但不是相同的值。 这种相关性取决于块大小以及磁盘 I/O 是随机的还是顺序的。 系统将所有数据以块的形式写入磁盘，但不同的应用程序可以使用不同的块大小。

接下来，让我们逐个组件分析这些项。

硬盘驱动器访问时间

平均 10,000-RPM 硬盘驱动器的寻道时间为 7 ms，访问时间为 3 ms。 寻道时间是指读写头移动到盘片上某个位置所需的平均时间。 访问时间是指磁头在正确位置读取或写入数据到磁盘所需的平均时间。 因此，在 10,000-RPM HD 中读取唯一数据块的平均时间包括每个数据块总共约 10 ms 或 0.010 秒的寻道和访问时间。

当每次磁盘访问都需要磁头移动到磁盘上的新位置时，读取或写入行为称为随机。 当所有 I/O 都是随机的时，10,000-RPM HD 每秒可以处理大约 100 个 I/O (IOPS)。

当所有 I/O 都发生在硬盘驱动器上的相邻扇区时，我们称之为顺序 I/O。 顺序 I/O 没有寻道时间，因为在第一个 I/O 完成后，读取或写入头位于硬盘驱动器存储下一个数据块的起始位置。 例如，根据以下方程式，10,000-RPM HD 每秒能够处理大约 333 个 I/O：

每秒 1000 毫秒 ÷ 每个 I/O 3 毫秒

到目前为止，硬盘的传输速率与我们的示例无关。 无论硬盘大小如何，10,000-RPM HD 可以处理的实际 IOPS 量始终约为 100 个随机 I/O 或 300 个顺序 I/O。 由于块大小根据写入驱动器的应用程序而变化，因此每个 I/O 提取的数据量也会发生变化。 例如，如果块大小为 8 KB，则 100 次 I/O 操作将从硬盘读取或写入总共 800 KB。 但是，如果数据块大小为 32 KB，则 100 I/O 将向硬盘驱动器读取或写入 3,200 KB (3.2 MB)。 如果 SCSI 传输速率超过传输的数据总量，那么获得更快的传输速率不会改变任何事情。 有关详细信息，请参阅以下表：

说明 7200 RPM 9 ms 寻道，4 ms 访问 10,000 RPM 7 ms 寻道，3 ms 访问 15,000 RPM 4 ms 寻道，2 ms 访问
随机 I/O 80 100 150
顺序 I/O 250 300 500
10,000 RPM 驱动器 8 KB 块大小 (Active Directory Jet)
随机 I/O 800 KB/s
顺序 I/O 2400 KB/s

SCSI 底板

SCSI 底板（在此示例方案中为带状电缆）如何影响存储子系统的吞吐量取决于块大小。 如果 I/O 以 8 KB 块为单位，总线可以处理多少 I/O？ 在此方案中，SCSI 总线为 20 MBps，即 20480 KB/s。 20480 KB/s 除以 8 KB 块，SCSI 总线支持的最大 IOPS 约为 2500。

注意

下表中的数字表示一个示例方案。 大多数连接的存储设备目前使用 PCI Express，这提供了更高的吞吐量。

SCSI 总线支持的每个块大小的 I/O 2 KB 块大小 8 KB 块大小 (AD Jet) (SQL Server 7.0/SQL Server 2000)
20 MBps 10,000 2,500
40 MBps 20,000 5,000
128 MBps 65,536 16,384
320 MBps 160,000 40,000

如上表所示，在我们的示例方案中，总线永远不会成为瓶颈，因为主轴最大值为 100 个 I/O，远低于任何列出的阈值。

注意

在此方案中，我们假设 SCSI 总线效率为 100%。

SCSI 适配器

为了确定系统可以处理多少 I/O，必须查阅制造商的规格。 将 I/O 请求定向到适当的设备需要处理能力，因此系统可以处理多少 I/O 取决于 SCSI 适配器或阵列控制器处理器。

在此示例中，我们假设系统可以处理 1,000 个 I/O。

PCI 总线

PCI 总线是一个经常被忽视的组件。 在此示例中，PCI 总线不是瓶颈。 但是，随着系统纵向扩展，它可能在未来成为一个瓶颈。

在我们的示例方案中，我们可以通过使用以下公式看到 PCI 总线可以传输多少数据：

32 位 ÷ 每字节 8 位 × 33 MHz = 133 MBps

因此，我们可以假设以 33 Mhz 运行的 32 位 PCI 总线可以传输 133 MBps 的数据。

注意

该公式的结果代表了传输数据的理论极限。 实际上，大多数系统只能达到最大限制的 50% 左右。 在某些突发情况下，系统可以在短时间内达到极限的 75%。

基于此公式，66 MHz 64 位 PCI 总线可以支持理论上最大 528 MBps：

64 位 ÷ 每字节 8 位 × 66 Mhz = 528 MBps

当你添加任何其他设备（如网络适配器或第二个 SCSI 控制器）时，它会减少系统可用的带宽，因为所有设备都共享带宽，并且可以相互争用，以获取有限的处理资源。

分析存储子系统以发现瓶颈

在此方案中，主轴是可以请求多少 I/O 的限制因素。 因此，这个瓶颈也限制了系统可以传输的数据量。 由于我们的示例是 AD DS 方案，因此可传输的数据量是每秒 100 个随机 I/O，增量为 8 KB，当你访问 Jet 数据库时，总共每秒 800 KB。 相比之下，配置为专门分配给日志文件的主轴的最大吞吐量将限制为每秒 300 个顺序 I/O（以 8 KB 分期计），总计为 2,400 KB 或每秒 2.4 MB。

现在，我们已经分析了示例配置的组件，让我们看一个表，该表展示了在存储子系统中添加和更改组件时可能出现瓶颈的位置。

备注 瓶颈分析 磁盘 总线 适配器 PCI 总线
这是添加第二个磁盘后域控制器的配置。 磁盘配置表示 800 KB/s 的瓶颈。 添加 1 个磁盘（总计 = 2）

I/O 是随机的

4 KB 块大小

10,000 RPM HD

 总共 200 个 I/O
总计 800 KB/s。
添加 7 个磁盘后，磁盘配置仍表示瓶颈，为 3200 KB/s。 添加 7 个磁盘（总计 = 8）

I/O 是随机的

4 KB 块大小

10,000 RPM HD

 总共 800 个 I/O。
总计 3200 KB/s
将 I/O 更改为顺序后，网络适配器成为瓶颈，因为它被限制为 1000 IOPS。 添加 7 个磁盘（总计 = 8）

I/O 是顺序的

4 KB 块大小

10,000 RPM HD

 2400 I/O 秒可读/写到磁盘，控制器限制为 1000 IOPS
将网络适配器替换为支持 10,000 IOPS 的 SCSI 适配器后，瓶颈将返回到磁盘配置。 添加 7 个磁盘（总计 = 8）

I/O 是随机的

4 KB 块大小

10,000 RPM HD

升级 SCSI 适配器（现在支持 10,000 个 I/O）

 总共 800 个 I/O。
总计 3200 KB/s
将块大小增加到 32 KB 后，总线成为瓶颈，因为它仅支持 20 MBps。 添加 7 个磁盘（总计 = 8）

I/O 是随机的

32 KB 块大小

10,000 RPM HD

 总共 800 个 I/O。 25,600 KB/s (25 MBps) 可以读/写到磁盘。

总线仅支持 20 MBps
升级总线并添加更多磁盘后，磁盘仍然是瓶颈。 添加 13 个磁盘（总计 = 14）

添加具有 14 个磁盘的第二个 SCSI 适配器

I/O 是随机的

4 KB 块大小

10,000 RPM HD

升级到 320 MBps SCSI 总线

 2800 个 I/O

11,200 KB/s (10.9 MBps)
将 I/O 更改为顺序后，磁盘仍然是瓶颈。 添加 13 个磁盘（总计 = 14）

添加具有 14 个磁盘的第二个 SCSI 适配器

I/O 是顺序的

4 KB 块大小

10,000 RPM HD

升级到 320 MBps SCSI 总线

 8,400 个 I/O

33,600 KB\s

(32.8 MB\s)
添加更快的硬盘驱动器后，磁盘仍然是瓶颈。 添加 13 个磁盘（总计 = 14）

添加具有 14 个磁盘的第二个 SCSI 适配器

I/O 是顺序的

4 KB 块大小

15,000 RPM HD

升级到 320 MBps SCSI 总线

 14,000 个 I/O

56,000 KB/s

(54.7 MBps)
将块大小增加到 32 KB 后，PCI 总线将成为瓶颈。 添加 13 个磁盘（总计 = 14）

添加具有 14 个磁盘的第二个 SCSI 适配器

I/O 是顺序的

32 KB 块大小

15,000 RPM HD

升级到 320 MBps SCSI 总线

 14,000 个 I/O

448,000 KB/s

(437 MBps) 是主轴的读/写限制。

PCI 总线支持的理论最大值为 133 MBps（最高效率为 75%）。

RAID 简介

当向存储子系统引入阵列控制器时，它不会显著改变其性质。 在计算中，阵列控制器只替换 SCSI 适配器。 但是，使用各种阵列级别时，向磁盘读取和写入数据的成本确实会发生变化。

在 RAID 0 中，写入数据会在 RAID 集中的所有磁盘上进行条带化。 在读取或写入操作期间，系统从每个磁盘提取数据或将数据推送到每个磁盘，从而增加了系统在特定时间段内可以传输的数据量。 因此，在这个使用 10,000 RPM 驱动器的示例中，使用 RAID 0 将允许执行 100 个 I/O 操作。 系统支持的 I/O 总量为 N 个主轴乘以每个主轴每秒 100 个 I/O，或 N 个主轴 × 每个主轴每秒 100 个 I/O。

显示 RAID 0 部署中逻辑 D 驱动器的图表。系统在磁盘之间执行的读取和写入操作由一条蓝色线条表示，蓝线将每个主轴像项链一样连接在一起。

在 RAID 1 中，系统通过一对主轴对数据进行镜像或复制，以实现冗余。 当系统执行读取 I/O 操作时，它可以从集合中的两个主轴读取数据。 此镜像使两个磁盘的 I/O 容量在读取操作期间都可用。 然而，RAID 1 并没有给写入操作带来任何性能优势，因为系统还需要在一对主轴上镜像写入的数据。 尽管镜像不会使写入操作花费更长的时间，但它确实会阻止系统同时执行多个读取操作。 因此，每次写入 I/O 操作都需要两次读取 I/O 操作。

以下公式计算此方案中发生了多少 I/O 操作：

读取 I/O + 2 × 写入 I/O = 消耗的可用磁盘 I/O 总数

当你知道部署中的读取与写入的比例以及部署中的主轴数时，可以使用此公式计算阵列可以支持的 I/O 数量：

每个主轴的最大 IOPS × 2 主轴 × [(% Reads + % Writes) ÷ (% Reads + 2 × % Writes)] = 总 IOPS

使用 RAID 1 和 RAID 0 的方案在读取和写入操作的成本方面与 RAID 1 完全相同。 但是，I/O 现在在每个镜像集上条带化。 这意味着公式将变为：

每个主轴的最大 IOPS × 2 主轴 × [(% Reads + % Writes) ÷ (% Reads + 2 × % Writes)] = 总 I/O

在 RAID 1 集中，当你对 N 个 RAID 1 集进行条带化时，阵列可以处理的总 I/O 将变为 N × I/O 每个 RAID 1 集：

N × {每个主轴的最大 IOPS × 2 主轴 × [(% Reads + % Writes) ÷ (% Reads + 2 × % Writes)]} = 总 IOPS

我们有时称 RAID 5 为 N + 1 RAID，因为系统会在 N 主轴上对数据进行条带化，并将奇偶校验信息写入 + 1 主轴。 但是，RAID 5 在执行写入 I/O 时比 RAID 1 或 RAID 1+0 使用更多的资源。 每次操作系统向阵列提交写入 I/O 时，RAID 5 都会执行以下过程：

  1. 读取旧数据。
  2. 读取旧的奇偶校验。
  3. 写入新数据。
  4. 写入新的奇偶校验。

OS 向阵列控制器发送的每个写入 I/O 请求都需要四个 I/O 操作才能完成。 因此， N + 1 RAID 写入请求的完成时间是读取 I/O 的四倍。 换句话说，要确定来自 OS 的 I/O 请求数量转换为主轴收到的请求数量，你可以使用以下公式：

读取 I/O + 4 × 写入 I/O = 总 I/O

同样，在 RAID 1 集中，你知道读取与写入的比率以及有多少主轴，可以使用此公式来确定阵列可以支持的 I/O 数量：

每个主轴的 IOPS × (主轴 – 1）× [(% Reads + % Writes) ÷ (% Reads + 4 × % Writes)] = 总 IOPS

注意

上一个公式的结果因奇偶校验而丢失的驱动器。

SAN 简介

当你在环境中引入存储区域网络 (SAN) 时，它不会影响我们在前面部分中所述的规划原则。 但是，你应该考虑到 SAN 可以更改与其连接的所有系统的 I/O 行为。 使用 SAN 的主要优点之一是，它为你提供了比内部或外部连接存储更多的冗余，但这也意味着你的容量规划需要考虑容错需求。 此外，当在系统中引入更多组件时，还需要将这些新部件考虑到计算中。

现在，让我们将 SAN 分解为其组件：

  • SCSI 或光纤通道硬盘驱动器
  • 存储单元通道背板
  • 存储单元本身
  • 存储控制器模块
  • 一个或多个 SAN 交换机
  • 一个或多个主机总线适配器 (HBA)
  • 外围组件互连 (PCI) 总线

设计冗余系统时，必须包含额外的组件，以确保系统在一个或多个原始组件停止工作的危机方案中仍能正常工作。 但是，在进行容量规划时，需要从可用资源中排除冗余组件，以便准确估计系统的基线容量，因为除非发生紧急情况，否则这些组件通常不会联机。 例如，如果 SAN 有两个控制器模块，则在计算总可用 I/O 吞吐量时只需要使用一个，因为除非原始模块停止工作，否则另一个不会打开。 此外，不应将冗余 SAN 交换机、存储单元或主轴引入 I/O 计算。

此外，由于容量规划只考虑高峰使用期，因此不应将冗余组件纳入可用资源。 为了适应突发或其他异常的系统行为，峰值利用率不应超过系统饱和度的 80%。

分析 SCSI 或光纤通道硬盘驱动器的行为时，应根据前面部分中概述的原则对其进行分析。 尽管每种协议都有自己的优点和缺点，但限制每个磁盘性能的主要因素是硬盘驱动器的机械限制。

分析存储单元上的通道时，应采用与计算 SCSI 总线上可用资源数量时相同的方法：将带宽除以块大小。 例如，如果存储单元有 6 个通道，每个通道支持 20 MBps 最大传输速率，则可用 I/O 和数据传输总量为 100 MBps。 总吞吐量为 100 MBps 而不是 120 MBps 的原因是，存储通道总吞吐量不应超过其中一个通道突然关闭时将使用的吞吐量，从而只留下五个正常工作的通道。 当然，此示例还假定系统在所有通道上均匀分布负载和容错。

是否可以将前面的示例转换为 I/O 配置文件取决于应用程序行为。 对于 Active Directory Jet I/O，最大值约为每秒 12,500 I/O，或每个I/O 100 MBps ÷ 8 KB。

为了了解控制器模块支持的吞吐量，还需要了解其制造商规格。 在此示例中，SAN 有两个控制器模块，每个模块支持 7,500 个 I/O。 如果不使用冗余，则系统总吞吐量为 15,000 IOPS。 但是，在需要冗余的情况下，可以仅根据其中一个控制器的限制计算最大吞吐量，即 7,500 IOPS。 假设数据块大小为 4 KB，则此阈值远低于存储通道可以支持的最大值 12500 IOPS，因此是分析中的瓶颈。 但是，出于规划目的，应该计划的最大 I/O 为 10,400 I/O。

当数据离开控制器模块时，它会传输额定值为 1 GBps 或 128 Mbps 的光纤通道连接。 由于这个数量超过了所有存储单元通道上 100 MBps 的总带宽，因此它不会成为系统的瓶颈。 此外，由于冗余，此传输仅在两个光纤通道中的一个上进行；因此如果一个光纤通道连接停止工作，其余连接仍有足够的容量来处理数据传输需求。

然后，数据通过 SAN 交换机传输到服务器。 交换机限制了它可以处理的 I/O 量，因为它需要处理传入的请求，然后将其转发到适当的端口。 但是，只有查看制造商的规格，才能知道交换机限制是什么。 例如，如果系统有两个交换机，每个交换机可以处理 10,000 IOPS，则总吞吐量将为 20,000 IOPS。 根据容错规则，如果一个交换机停止工作，系统总吞吐量将为 10,000 IOPS。 因此，在正常情况下，不应使用超过 80% 的利用率或 8,000 个 I/O。

最后，在服务器中安装的 HBA 还会限制它可以处理的 I/O 量。 通常，需要安装第二个 HBA 来实现冗余；但与 SAN 交换机一样，当计算系统可以处理的 I/O 量时，总吞吐量将为 N - 1 HBA。

缓存注意事项

缓存是可以显著影响存储系统中任何位置的整体性能的组件之一。 但是，对缓存算法的详细分析超出了本文的范围。 相反，我们将为你提供一个关于磁盘子系统缓存的快速列表。

  • 缓存改进了持续的顺序写入 I/O，因为它将许多较小的写入操作缓冲到更大的 I/O 块中。 它还将操作存储在几个大块中，而不是许多小块中。 此优化可减少随机和顺序 I/O 操作总数，使更多资源可用于其他 I/O 操作。
  • 缓存并不能提高存储子系统上的持续写入 I/O 吞吐量，因为它只缓冲写入，直到主轴可用于提交数据。 当来自主轴的所有可用 I/O 长时间被数据饱和时，缓存最终会被填满。 若要清空缓存，必须提供足够的 I/O，以便通过提供额外的主轴或在突发之间留出足够的时间让系统赶上来清理缓存。
  • 更大的缓存允许缓存更多的数据，这意味着缓存可以处理更长时间的饱和。
  • 在典型的存储子系统中，OS 通过缓存提高了写入性能，因为系统只需要将数据写入缓存。 但是，一旦基础媒体被 I/O 操作饱和，缓存就会填满，写入性能将恢复到正常的磁盘速度。
  • 缓存读取 I/O 时，当你将数据顺序存储在桌面上并允许缓存提前读取时，缓存最有用。 预读是指缓存可以立即移动到下一个扇区，就好像下一扇区包含系统接下来将请求的数据一样。
  • 当读取 I/O 是随机的时，驱动器控制器上的缓存不会增加磁盘可以读取的数据量。 如果基于 OS 或应用程序的缓存大小大于基于硬件的缓存大小，那么任何提高磁盘读取速度的尝试都不会改变任何事情。
  • 在 Active Directory 中，缓存仅受系统持有的 RAM 量的限制。

SSD 注意事项

固态硬盘 (SSD) 与基于主轴的硬盘有着根本的不同。 SSD 可以以较低的延迟处理更大的 I/O 量。 虽然 SSD 的每 GB 成本可能很昂贵，但就每 I/O 成本而言，它们非常便宜。 但是，SSD 的容量规划涉及到问你自己同样的问题：它们可以处理多少 IOPS，这些 IOPS 的延迟是多少？

在规划 SSD 时，应考虑以下几点：

  • IOPS 和延迟都取决于制造商的设计。 在某些情况下，某些 SSD 设计的性能可能比基于主轴的技术差。 在决定是使用 SSD 还是主轴时，应逐个驱动器查看和验证制造商的规格，而不是假设所有技术都以某种方式工作。
  • IOPS 类型可以具有不同的值，具体取决于它们是读取还是写入。 与其他应用程序方案相比，AD DS 服务主要是基于读取的，因此受你使用的写入技术的影响较小。
  • 写入持久性是假设 SSD 单元的使用寿命有限，并且在大量使用后最终会耗尽。 对于数据库驱动器，以读取 I/O 为主的配置文件将单元的写入持久性扩展到不需要太担心写入持久性的程度。

总结

想象一下，存储就像房子的室内管道。 存储数据的媒体的 IOPS 就像家里的主要排水管。 当主排水管堵塞或受到尺寸或管道坍塌的限制时，当家庭使用大量水时，排水管就会回流，无法正常工作。 这种情况类似于共享环境中有一个或多个系统在同一 SAN、NAS 或 iSCSI 上使用共享存储，并具有相同的基础媒体。 由于用户需求超过了系统的能力，因此性能受到了影响。

同样，在我们的虚构管道方案中，可以采用不同的方法来解决堵塞和其他性能问题：

  • 若要解决坍塌的排水管或排水管太小的问题，需要用工作正常且尺寸正确的管道替换。 在共享存储方面，这就像在整个基础结构中添加新硬件或重新分配共享系统的使用。
  • 疏通排水管需要找出潜在的问题及其位置，然后用适当的工具将其清除。 例如，厨房水槽排水管中相对简单的堵塞只需要柱塞或排水清洁器即可清除，而涉及被困物体的更复杂的堵塞可能需要排水蛇。 同样，在共享存储系统中，确定性能问题的原因有助于确定是需要创建系统级备份、跨所有服务器同步防病毒扫描，还是同步在高峰时段运行的碎片整理软件。

在大多数管道设计中，多个排水管汇入主排水管。 当排水管堵塞时，水只会被困在堵塞点后面。 如果一个连接点堵塞，那么该连接点后面的所有排水管都会停止排水。 在存储方案中，连接点堵塞就像交换机过载、驱动程序兼容性问题或软件任务不同步。 必须测量 IOPS 和 I/O 大小，以确定存储系统是否可以处理负载，然后根据需要调整系统。

附录 D：在无法选择更多 RAM 的环境中进行存储故障排除

虚拟化存储之前的许多存储建议都用于两个目的：

  • 隔离 I/O，以防止 OS 主轴上的性能问题影响数据库和 I/O 配置文件的性能。
  • 利用基于主轴的硬盘驱动器和缓存在与 AD DS 日志文件的顺序 I/O 一起使用时可以为系统带来的性能提升。 将顺序 I/O 隔离到单独的物理驱动器也可以提高吞吐量。

使用新的存储选项时，早期存储建议背后的许多基本假设不再成立。 虚拟化存储方案（例如 iSCSI、SAN、NAS 和虚拟磁盘映像文件）通常跨多个主机共享基础存储媒体。 这种差异否定了必须隔离 I/O 并优化顺序 I/O 的假设。 现在，访问共享媒体的其他主机可能会降低对域控制器的响应速度。

在规划存储性能的容量时，应考虑以下三项事项：

  • 冷缓存状态
  • 热缓存状态
  • 备份和还原

冷缓存状态是指最初重新启动域控制器或重新启动 Active Directory 服务时，RAM 中没有 Active Directory 数据。 热缓存状态是指域控制器在稳定状态下运行并缓存数据库。 就性能设计而言，预热冷缓存就像短跑，而运行具有完全预热缓存的服务器就像马拉松。 定义这些状态及其驱动的不同性能配置文件非常重要，因为在估计容量时需要同时考虑它们。 例如，仅仅因为你有足够的 RAM 在热缓存状态下缓存整个数据库，并不能帮助你在冷缓存状态下优化性能。

对于这两种缓存方案，最重要的是存储将数据从磁盘移动到内存的速度。 当你预热缓存时，随着查询重用数据，性能会随着时间的推移而提高，缓存命中率会提高，转到磁盘检索数据的频率会降低。 因此，必须转到磁盘的不利性能影响也减少了。 任何性能下降都是暂时的，通常在缓存达到其热状态和系统允许的最大大小时消失。

可以通过测量 Active Directory 中的可用 IOPS 来衡量系统从磁盘获取数据的速度。 可用 IOPS 的数量也取决于基础存储中可用的 IOPS 数量。 从规划的角度来看，由于缓存预热和备份或还原状态是通常在非高峰时段发生的特殊事件，并且受到直流负载的影响，因此我们只能在非高峰时间进入这些状态，而不能给出一般建议。

在大多数情况下，AD DS 主要是读取 I/O，读取率为 90%，写入率为 10%。 读取 I/O 是用户体验的典型瓶颈，而写入 I/O 是降低写入性能的瓶颈。 缓存对读取 I/O 的好处往往很小，因为 NTDS.dit 文件的 I/O 操作主要是随机的。 因此，你的首要任务是确保正确配置读取 I/O 配置文件存储。

在正常操作条件下，存储规划目标是尽量减少系统从 AD DS 向磁盘返回请求的等待时间。 未完成和挂起的 I/O 操作的数量应小于或等于磁盘中的路径数量。 对于性能监视方案，我们通常建议 LogicalDisk((<NTDS Database Drive>))\Avg Disk sec/Read 计数器应小于 20 ms。 应将操作阈值设置得更低，尽可能接近存储速度，在 2 到 6 毫秒的范围内，具体取决于存储类型。

以下折线图显示了存储系统中的磁盘延迟测量值。

显示存储系统内磁盘延迟的折线图。图表右侧的一个区域周围画了一个褐红色的圆圈。

让我们分析一下此折线图：

  • 图表左侧用绿色圈出的区域显示，当负载从 800 IOPS 增加到 2,400 IOPS 时，延迟始终保持在 10 ms。 此区域是基础存储处理 I/O 请求的速度的基准。 但是，此基线受你使用的存储解决方案类型的影响。
  • 图表右侧用褐红色圈出的区域显示了从基线到数据收集结束之间的系统吞吐量。 吞吐量本身不会改变，但延迟会增加。 此区域演示了每当请求量超过基础存储的物理限制时，请求如何花费更长的时间在队列中等待发送到存储子系统。

现在，让我们想想这些数据告诉我们什么。

首先，让我们假设一个用户查询一个大型组的成员资格，要求系统从磁盘读取 1 MB 的数据。 可以使用这些值评估所需的 I/O 量以及操作需要多长时间：

  • 每个 Active Directory 数据库页面的大小为 8 KB。
  • 系统需要读取的最小页数为 128。
  • 因此，在关系图中的基线区域，系统至少需要 1.28 秒才能从磁盘加载数据并将其返回到客户端。 在 20 ms 的标记处，吞吐量远远高于建议的最大吞吐量，此过程需要 2.5 秒。

根据这些数字，可以使用以下公式计算缓存的预热速度：

每个 I/O 2,400 IOPS × 8 KB

运行此计算后，我们可以说此方案中的缓存预热率为 20 MBps。 换句话说，系统每 53 秒将大约 1 GB 的数据库加载到 RAM 中。

注意

当组件积极地读写磁盘时，延迟会在短时间内上升，这是很正常的。 例如，当系统正在备份或 AD DS 运行垃圾回收时，延迟会增加。 除了最初的使用估计之外，你应该为这些周期性事件提供额外的空间。 目标是在不影响整体功能的情况下，提供足够的吞吐量来适应这些峰值。

根据设计存储系统的方式，缓存的预热速度存在物理限制。 唯一可以将缓存预热到基础存储可以容纳的速率的是传入的客户端请求。 在高峰时段运行脚本尝试预热缓存会与真实的客户端请求争用，增加整体负载，加载与客户端请求无关的数据，并降低性能。 建议你避免使用人为措施来预热缓存。