Active Directory 域服务容量计划

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

容量计划目标

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

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

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

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

容量管理是主动的：设计、调整规模和监视环境，使利用率趋势保持在定义的阈值内，并在用户影响之前执行缩放作。 性能故障排除是被动的：解决已经降级用户操作的紧急问题。

纵向扩展系统的容量规划是确保硬件和服务能够处理预期的负载。 在这两种情况下，目标是确保系统可以处理预期的负载，同时仍提供良好的用户体验。 以下体系结构选择可以帮助你实现该目标：

• Virtualization
• 高速存储，如固态硬盘（SSD）和 NVMe（非易失性存储器接口）
• 云场景

Active Directory 域服务（AD DS）是一种成熟的分布式服务，许多Microsoft和第三方产品用作后端。 它是确保其他应用程序具有所需的容量的最关键组件之一。

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

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

• 请确保已阅读并了解 适用于 Windows Server 的性能优化准则。
• Windows Server 平台是基于 x64 的体系结构，与 x86 系统相比，该体系结构提供更大的内存地址空间。 无论 Windows Server 版本如何，本文的指南都适用于 Active Directory 环境。 对于当前版本，扩展的 x64 内存功能允许在内存中缓存更大的数据库，但容量规划原则保持不变。 如果环境具有完全适合可用系统内存的目录信息树（DIT），则这些准则也适用。
• 了解容量规划是一个持续的过程，因此你应该定期审查构建的环境是否符合期望。
• 要明白，随着硬件成本的变化，优化会在多个硬件生命周期中发生。 例如，如果内存变得更便宜，则每个内核的成本会降低，或者不同存储选项的价格会发生变化。
• 规划每日高峰繁忙时段。 建议你根据 30 分钟或一小时的间隔制定计划。 选择间隔时，请考虑以下信息：
  • 间隔大于 1 小时可能会妨碍识别服务何时达到峰值容量。
  • 小于 30 分钟的间隔会使暂时性增加看起来比实际更重要。
• 为企业硬件生命周期内的增长做计划。 此增长计划可能包括以惊人的方式升级或添加硬件的策略，或每三到五年进行一次完整的刷新。 每个增长计划都要求你估计 Active Directory 上的负载增长了多少。 历史数据可以帮助你做出更准确的评估。
• 容错是某些组件发生故障时系统能够继续正常运行。 确定所需的容量（称为 n）后，应计划容错。 请考虑 n + 1、n + 2 或甚至 n + x 的情况。 例如，如果需要两个域控制器（DC），请规划三个域控制器，以便可以处理一个 DC 故障。

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

  • 请记得集成增长和容错计划。 例如，一个域控制器（DC）处理今天的负载。 预测显示一年内负载翻倍，将需要两个 DC 来满足需求。 这不会留下额外的容量用于容错。 为了防止这种容量不足，应该计划从三个 DC 开始。 如果预算不允许三个 DC，也可以从两个 DC 开始，然后计划在三到六个月后增加第三个 DC。

    Note

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

三部分容量规划周期

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

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

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

• 直接映射，其中每个主机只有一个客户机。
• 共享主机 场景，其中每个主机上有多个来宾。

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

回答这些早期的规划问题后，让我们看看容量规划周期本身。 每个容量规划周期都涉及三个步骤：

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

应用过程

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

• Memory
• Network
• 存储
• Processor
• Netlogon

AD DS 的基本存储要求和兼容的客户端软件的一般行为意味着现代服务器级硬件可以轻松满足多达 10,000 到 20,000 个用户的环境的容量规划需求。 尽管容量规划对于所有部署都很重要，但较小的环境通常在其硬件选择方面具有更大的灵活性，因为大多数最新的服务器系统可以处理这些负载，而无需进行专用优化。

数据收集摘要表中的表说明如何评估现有环境以选择正确的硬件。 之后的部分将更详细地介绍硬件的基线建议和特定于环境的原则，以帮助 AD DS 管理员评估其基础结构。

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

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

数据收集摘要表

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

工作环境

高级评估条件

Planning

很长一段时间，AD DS 大小调整的典型建议是放入与数据库大小一样多的 RAM。 尽管计算能力的增强和从 x86 体系结构切换到 x64 让物理机器上托管的 AD DS 性能尺寸化的细微方面变得不再那么重要，虚拟化却突出了性能调优的重要性。

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

RAM

RAM 中可以缓存的存储越多，对磁盘的需求就越少。

若要最大程度地提高服务器可伸缩性，请通过对以下组件求和计算最低 RAM 要求：

• 当前数据库大小
• 推荐的操作系统容量
• 针对代理的供应商建议，例如：
  • 防病毒程序
  • 监视软件
  • 备份应用程序

还应该包括额外的 RAM，以适应服务器生命周期内的未来增长。 根据数据库增长和环境变化，此估算更改。

在最大化 RAM 不经济高效或不可行的环境中，请参阅 “存储” 部分以正确配置存储。 这些方案包括：

• 预算约束的卫星位置
• 目录信息树（DIT）太大而无法容纳内存的部署

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

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

• 现有系统不总是准确反映 RAM 需求，因为本地安全机构子系统服务（LSASS）由于内存压力缩减 RAM，导致人为地降低需求。
• 单个 DC 只需缓存其客户端感兴趣的数据。 这意味着在不同环境中缓存的数据会根据它包含的客户端类型而更改。 例如，Exchange Server 环境中的 DC 收集的数据不同于仅对用户进行身份验证的 DC。
• 根据具体情况评估每个 DC 的 RAM 所需的工作量通常过大，并且会随着环境的变化而变化。

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

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

RAM 虚拟化注意事项

优化 RAM 的目标是最大程度地减少进入磁盘所需的时间。 避免在主机上过度提交内存（向来宾分配比物理计算机更多的 RAM）。 单独过度提交并不是问题，但如果来宾总使用量超过主机 RAM，则主机页面。 分页会导致性能受限于磁盘，当 DC 转向 NTDS.dit 或页面文件，或当主机对 RAM 进行分页时。 此行为会大幅降低性能和用户体验。

计算摘要示例

建议：16GB

随着时间的推移，更多的数据被添加到数据库中，服务器的平均寿命约为三到五年。 根据 33%的增长估计，18GB 是一个合理的 RAM 量，用于放入物理服务器。

Network

本节将评估部署需要多少总带宽和网络容量，包括客户端查询、组策略设置等。 可以使用 Network Interface(*)\Bytes Received/sec 和 Network Interface(*)\Bytes Sent/sec 性能计数器收集数据以进行估计。 网络接口计数器的采样间隔应为 15、30 或 60 分钟。 对良好的测量来说，任何不足的都会显得太不稳定，而任何过大的都会过度平滑每日的峰值。

带宽需求

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

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

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

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

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

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

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

   Note

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

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

   Note

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

查看数据后，可以从网络利用率示例中提取哪些结论？

• 当前环境满足 60% 目标利用率的 n + 1 容错级别。 使一个系统脱机将每台服务器的带宽从大约 5.5MBps （44%） 转移到约 7MBps （56%）。
• 根据先前所述的合并到一台服务器的目标，此合并更改超过了最大目标利用率和 100 MB 连接可能利用率。
• 使用 1GB 连接时，此每个服务器带宽值表示总容量的 22%。
• 在 n + 1 方案中的正常作条件下，客户端负载相对分布为每台服务器约 14MBps，总容量为 11%。
• 为了确保在 DC 不可用时有足够的容量，每个服务器的正常作目标大约为 30% 网络利用率或每个服务器 38MBps。 故障转移的目标是实现60%的网络利用率或每台服务器达到72 MB/秒。

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

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

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

对于支持超过 5,000 名用户的物理服务器，典型的建议是配备 1GB 适配器。 多个来宾开始共享基础虚拟交换机基础结构后，确认主机有足够的聚合网络带宽来支持所有来宾。 在这两种情况下都要考虑带宽：当 DC 作为 VM 在主机上通过虚拟交换机运行时，以及当它直接连接至物理交换机时。 虚拟交换机需要仔细规划带宽。 上行必须支持通过它传递的聚合数据。 链接到交换机的物理主机网络适配器必须支持 DC 负载以及共享虚拟交换机并通过物理适配器进行连接的其他所有来宾。

网络计算摘要示例

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

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

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

存储

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

• 容量或存储大小
• Performance

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

Sizing

评估存储

与 Active Directory 刚推出时 4GB 和 9GB 驱动器最常见的情况相比，现在调整 Active Directory 的尺寸几乎不用去考虑，除非是在最大型的环境中。 在可用硬盘驱动器最小容量为 180GB 的情况下，整个操作系统、SYSVOL 和 NTDS.dit 可以轻松装在一个驱动器上。 因此，我们建议避免在存储大小调整方面投入太多资金。

建议确保 NTDS.dit 的可用空间为 110%，以便可以对存储进行碎片整理。

除了此建议之外，还应考虑适应未来增长的一般注意事项。

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

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

数据库大小可能因 OS 版本而异。 运行早期 OS 版本的 DC 的数据库大小比运行更高版本的数据库大小要小。 启用了 Active Directory 回收站或凭据漫游等功能的 DC 也会影响数据库大小。

存储虚拟化注意事项

在将多个虚拟硬盘（VHD）文件分配给单个卷的情况下，应使用固定状态磁盘。 磁盘应至少为 210% DIT 的大小，以确保有足够的空间供你使用。 此固定 VHD 大小包括 100% 的 DIT 大小加上 110% 的可用空间。

存储计算摘要示例

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

存储估算还应包括数据库以外的更多存储组件。 这些组件包括：

• SYSVOL
• 操作系统文件
• 页面文件
• 临时文件
• 本地缓存数据，如安装程序文件
• Applications

存储性能

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

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

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

在后端存储上放置的其他工作负荷可以重载共享存储，例如 RAID、SAN、NAS、JBOD、存储空间和 VHD。 这些类型的存储设备可以提供额外的考虑。 例如，物理磁盘与 AD 应用程序之间的 SAN、网络或驱动程序问题可能会导致限制和延迟。 为了澄清，这些类型的存储体系结构不是一个坏选择，但它们更为复杂，这意味着你需要特别注意确保每个组件按预期工作。 有关更详细的说明，请参阅本文后面的 附录 C 和 附录 D 。

这种固态存储技术（NVMe 和 SSD）与传统硬盘驱动器没有相同的机械限制。 但是，它们仍存在 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 的良好范围是：

• 7,200 rpm：9 毫秒到 12.5 毫秒（ms）
• 10,000 rpm：6 毫秒到 10 毫秒
• 15,000 rpm：4 毫秒到 6 毫秒
• SSD – 1 毫秒到 3 毫秒

你可能会从其他源中听到存储性能在 15 毫秒到 20 毫秒时降级。 这些值与前一列表中的值之间的区别在于，列表值显示了正常工作范围。 其他值用于故障排除目的，帮助你识别客户端体验何时下降到明显程度。 有关详细信息，请参阅 附录 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>)) ÷ 磁盘平均读取/秒 ÷ <Target Avg Disk Read/sec>) × LogicalDisk(<NTDS Database Drive>)\读取/秒

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

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

计算的数字是近似值。 不完全准确是因为可扩展存储引擎（ESE）缓存大小未固定。 默认情况下，缓存会增大和收缩，因此 AD DS 可能会逐出之前加载的页面。 固定的缓存大小将使估计更精确。

Processing

评估 Active Directory 处理器使用情况

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

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

在开始估算处理器使用情况之前，请先完成 存储 估算。 如果没有有关处理器负载的有效数据，则无法进行准确的猜测。 在对处理器进行故障排除之前，请务必确保存储不会创建任何瓶颈。 当你删除处理器等待状态时，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。
• 在工作时间，总目标 CPU 使用率在正常操作条件下（N + 1）为 40%，在其他条件下（N

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

• 负载被均匀分配，这就是我们预期的结果，当客户端使用 DC 定位器和精心编写的搜索时。

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

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

  在非高峰时段，管理良好的系统上的短暂峰值通常是由以下因素引起的：

  • 备份作业
  • 完整的防病毒扫描
  • 硬件库存扫描
  • 软件库存扫描
  • 软件分发或修补程序部署

  这些任务之外的峰值可能表示异常负载并需要调查。 因为这些峰值发生在营业时间之外，所以它们不计入超出容量规划目标。

• 由于每个系统大约占 40%，而且它们都有相同数量的 CPU，因此如果其中一个系统脱机，其余系统的运行率估计为 53%。 然后，将系统 D 的 40% 负载在其余系统之间均匀拆分，并将其添加到其现有负载的 40% 中。 这种线性再分配假设并不完全准确，但它为估计提供了足够的准确性。

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

在此示例中，两个 DC 以 40% 运行。 一个数据中心脱机，其余数据中心的利用率跃升到估计 80%。 在故障转移期间，此负载超过了容量计划阈值，并将应对突增负载的预留空间缩小至10%–20%。 每个峰值现在都可以将 DC 驱动到 90% 甚至 100%，从而减少响应能力。

计算 CPU 需求

Process\% Processor Time 性能计数器跟踪所有应用程序线程在 CPU 上花费的总时间，然后将该总和除以经过的系统总时间。 在多核 CPU 系统上，多线程应用程序的 CPU 使用时间可以超过 100%，而其数据解释方式则不同于计数器 Processor Information\% Processor Utility 的数据。 在实践中，Process(lsass)\% Processor Time 计数器跟踪系统需要多少 CPU 以 100% 的速度运行以支持进程的需求。 例如，如果计数器的值为 200%，则意味着系统需要两个以 100% 运行的 CPU 来支持完整的 AD DS 负载。 尽管以 100% 容量运行的 CPU 在电源和能耗方面是最经济高效的，但多线程系统在系统未满负荷运行时响应更迅速。 本效率的原因在 附录 A 中概述。

为了适应客户端负载的瞬时峰值，我们建议你将峰值时段 CPU 的目标设置在系统容量的 40% 到 60% 之间。 例如，在目标站点行为配置文件的第一个示例中，需要 3.33 个 CPU（60% 目标）和 5 个 CPU（40% 目标）来支持 AD DS 负载。 应根据操作系统和任何其他所需代理（如防病毒、备份、监控等）的需求添加额外容量。 计划为基础结构代理（防病毒、备份、监视）保留一个 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。

  Note

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

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

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

何时优化 LDAP 权重

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

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

示例 1：PDC 模拟器环境

如果使用主域控制器 (PDC) 模拟器，则分布不均匀的用户或应用程序行为可能会同时影响多个环境。 PDC 模拟器的 CPU 负载通常比其他域控制器高。 许多操作对此偏好或始终联系，例如：

• 组策略管理工具（创建、编辑、链接、GPMC 刷新）
• 密码更改验证/第二次身份验证尝试（回退密码检查）
• 信任创建和维护操作
• 时间服务层次结构（域/森林中的权威时间源）
• 帐户锁定处理
• 仍然将目标设定为 PDC 模拟器的旧应用程序或配置错误的应用程序

如果这些活动很常见，请单独监视其 CPU 并规划额外的余量。

仅当 CPU 使用率存在明显差异时，才应优化 PDC 模拟器。 优化应减少 PDC 模拟器上的负载，并增加其他 DC 上的负载，从而实现更均匀的负载分布。

在这些情况下，将 PDC 模拟器的 LDAPSrvWeight 值设置为 50 到 75 之间。

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

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

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

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

规划 N + 1 方案至关重要。 必须针对每个方案计算一个 DC 脱机的影响。 在前面的示例中，负载在所有服务器上均匀共享。 在 N 情况下（一台服务器丢失），每个剩余的服务器维持在约 60%。 当前分布是可接受的，因为比率保持一致。 查看 PDC 模拟器优化方案或用户或应用程序负载不平衡的任何常规方案时，效果不同：

处理虚拟化注意事项

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

对于直接映射配置（每个主机一个来宾），请再次使用之前收集的容量规划数字。 将它们直接应用于调整此部署的大小。

在共享主机方案中，假设虚拟化会产生大约 10% CPU 效率开销。 如果站点在物理硬件上需要 10 个 CPU，以达到 40% 的目标利用率，那么为了开销需要再添加一个 CPU。 跨 N 个客户域控制器分配总共 11 个虚拟 CPU（vCPU）。

在物理服务器和虚拟服务器混合分发的站点中，此虚拟化开销仅适用于虚拟机（VM）。 在 N + 1 设计中，10 CPU 物理（或直接映射）服务器大致相当于具有 11 个 vCPU 的虚拟 DC。 主机还需要为该 VM 保留另外 11 个 CPU。

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

虚拟化计算摘要示例

如果预计在三年内需求增长 50%，那就计划到那时需要 18.375 个 CPU（12.25 × 1.5）。 或者，你可以在第一年后审查需求，然后根据结果增加额外容量。

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

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

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

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

虚拟化规划

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

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

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

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

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

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

New_MaxConcurrentApi_setting≥（semaphore_acquires + semaphore_time）×average_semaphore_hold_time÷time_collection_length

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

虚拟化注意事项

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

虚拟化优化计算示例

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

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

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

附录 A：CPU 大小调整条件

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

定义：CPU 调整大小

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

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

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

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

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

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

线程级并行度

每个线程都是独立的任务，因为每个线程都有自己的堆栈和指令。 AD DS 可以在多个逻辑处理器之间很好地缩放，因为它是多线程的，并且可以优化可用线程数。 若要了解有关优化可用线程的详细信息，请按照 如何使用 Ntdsutil.exe在 Active Directory 中查看和设置 LDAP 策略 的说明进行作。

数据级并行度

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

CPU 速度与多核注意事项

更快的逻辑处理器缩短了单个线程完成其工作所需的时间。 添加更多逻辑处理器可增加可并行运行的线程数。 但是，由于内存延迟、共享资源争用、同步/锁定、串行代码路径和计划开销，缩放是非线性的。 因此，多核系统中的可伸缩性不是线性的。

利用率以非线性方式缩放，因为多个约束进行交互：

• 单个可运行线程在更快的核心上更快完成。如果没有可运行的并行工作，增加更多空闲核心没有意义。
• 当线程在缓存中停滞或需要主内存中的数据时，在数据返回之前，它无法向前推进。 更快的核心不会消除内存延迟;相对于周期率，它们可能会等待更长的时间。
• 随着并发（可运行线程）的增加，同步、缓存一致性流量、锁竞争和调度器开销消耗了较大百分比的总周期数。
• 更广泛的系统（更多的套接字/核心）放大了需要全局排序的操作的延迟影响（例如，修改共享数据、TLB 失效、处理器间中断）。
• 某些代码路径是串行的（Amdahl 的法律）。 并行区域饱和后，额外的核心会导致回报减少。

因此，仅当工作负载具有足够的可执行和可并行的任务，并且不主要受限于内存、存储或处理器锁争用时，增加处理器核心或其频率才能有效提高 AD DS 的吞吐量。

总之，关于是否应该添加更多或更快的处理器的问题变得非常主观，应该逐案考虑。 特别是对于 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 负载下，队列在处理器上的停留时间。

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

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

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

随着高峰时间的临近，道路系统的运力接近 100%。 在高峰时段变道变得非常具有挑战性，因为车辆靠得太近，你在变道时没有太多的回旋余地。 队列行为解释了 40% 长期平均容量目标。 保持平均利用率接近 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 – %处理器时间
  • % 处理器时间 = 1 – U k
  • % 处理器时间 = 1 – B / T
  • %Processor 时间 = 1 – X1 – X0 / Y1 – Y0

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

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

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

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

同样重要的是要记住，在这种情况下，40% 的建议不是强制性要求。 我们将其作为进行计算的合理起点。 不同类型的 AD 用户需要不同的响应级别。 某些环境在 CPU 使用率平均达到 80%–90% 时，只要队列等待时间没有明显增加，仍然能满足用户期望。 将其视为例外，使用延迟数据进行验证，并密切监控潜在的争用问题。

系统的其他部分比 CPU 慢。 也对它们进行调整。 专注于 RAM 访问、磁盘访问和网络响应时间。 例如：

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

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

  Note

  对于具有 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 速度来实现省电。

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

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

2. 选择 “结果”。

3. 输入 CPU2006 并选择“ 搜索”。

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

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

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

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

8. 记录 Result 和 # Cores 列中的值。

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

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

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

   （35.83 × 2000） ÷ （33.75 × 2300） = 0.92

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

    对于 E5-2630 处理器示例，0.92 × 10.3 = 10.35 处理器。

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

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

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

现在，我们阐明了定义物理磁盘的内容。 以下术语可帮助你更好地了解本附录中的信息。

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

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

OS 为其注册的每个磁盘创建一个先进先出 (FIFO) I/O 队列。 这些磁盘可以是主轴、阵列或阵列分区。 当涉及到 OS 如何处理 I/O 时，活动队列越多越好。 当 OS 对 FIFO 队列进行序列化时，它必须按到达顺序处理向存储子系统发出的所有 FIFO I/O 请求。 通过为每个轴或阵列保留单独的 I/O 队列，OS 会阻止磁盘竞争相同的稀缺 I/O 资源，并使活动仅与所涉及的磁盘隔离。 但是，Windows Server 2008 以 I/O 优先级的形式引入了异常。 无论 OS 何时收到，设计为使用低优先级 I/O 的应用程序都会被移动到队列的后面。 未编码为使用低优先级设置的应用程序默认为普通优先级。

简单存储子系统简介

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

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

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

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

硬盘驱动器访问时间

平均 10,000- RPM 硬盘驱动器有 7 毫秒的搜寻时间和 3 毫秒的访问时间。 寻道时间是指读写头移动到盘片上某个位置所需的平均时间。 访问时间是指磁头在正确位置读取或写入数据到磁盘所需的平均时间。 因此，在 10,000-RPM HD 中读取唯一数据块的平均时间包括总共大约 10 毫秒或 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 提取的数据量也会发生变化。 例如，如果块大小为 8KB，则从硬盘驱动器读取或写入的 100 个 I/O 操作总共处理 800KB。 但是，如果块大小为 32KB，则 100 I/O 会将 3,200KB（3.2MB）读取或写入到硬盘驱动器。 如果 SCSI 传输速率超过传输的数据总量，那么获得更快的传输速率不会改变任何事情。 有关详细信息，请参阅以下表：

SCSI 底板

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

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

SCSI 适配器

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

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

PCI 总线

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

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

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

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

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

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

添加另一台设备（例如网络适配器或第二个 SCSI 控制器）可减少系统可用的带宽。 总线上的所有设备共享该带宽，每个新设备都争用有限的处理资源。

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

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

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

RAID 简介

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

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

在 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 × 每个 RAID 1 集合的 I/O。

N × {每个磁盘的最大 IOPS × 2 个磁盘 × [（% 读取 + + % 写入) ÷ （% 读取 + 2 × % 写入)]} = 总 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 个通道，每个通道支持 20MBps 最大传输速率，则可用 I/O 和数据传输总量为 100MBps。 六个通道每个以 20MBps 效率运行，总理论带宽为 120MBps。 我们将计划吞吐量上限为 100MBps（N+1 设计）。 如果一个通道发生故障，剩余的 5 个 （5 × 20MBps） 仍提供所需的 100MBps。 此示例还假定系统在所有通道之间均匀分配负载和容错。

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

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

当数据离开控制器模块时，它通过 1Gbps（即 128MBps）的光纤通道连接进行传输。 由于此量超过所有存储单元通道的总带宽 100MBps，因此不会瓶颈系统。 正常作期间，两个光纤通道路径中只有一个传输流量：另一个路径是为冗余保留的。 如果活动路径失败，备用路径将接管。 它有足够的容量来处理完整的数据负载。

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

最后，在服务器中安装的 HBA 还会限制它可以处理的 I/O 量。 安装更多 HBA 来实现冗余。 计算容量时，请排除冗余 HBA。 假设一个 HBA 处于脱机状态（N - 1），并评估一个或多个剩余活动 HBA 上的总可用 I/O。

缓存注意事项

缓存是可以显著影响存储系统中任何位置的整体性能的组件之一。 但是，对缓存算法的详细分析超出了本文的范围。 相反，下面是关于磁盘子系统缓存的几个要点总结。

• 缓存改进了持续的顺序写入 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 或轴模型的供应商规格;性能和延迟因设计而异。 不要将所有 SSD 或所有轴视为相等。 比较每个模型的 IOPS、延迟、耐力、队列深度行为和固件功能。
• IOPS 类型可以具有不同的值，具体取决于它们是读取还是写入。 AD DS 服务主要依赖于读取，因此，与其他应用程序场景相比，无论您使用哪种写入技术，影响都较小。
• 写入持久性是假设 SSD 单元的使用寿命有限，并且在大量使用后最终会耗尽。 对于数据库驱动器，以读取 I/O 为主的配置文件将单元的写入持久性扩展到不需要太担心写入持久性的程度。

Summary

当多个独立工作负荷争用每秒有限的 I/O作（IOPS）和同一基础媒体或互连上的带宽时，会发生共享存储争用。 典型的争用源包括：

• 使用同一 SAN LUN 的多个服务器
• 多个其虚拟磁盘驻留在同一 NAS 卷上的 VM
• 通过共享构造访问常见 iSCSI 目标的主机

当一个工作负荷生成持续较高的 I/O（例如备份、全面防病毒扫描、大型目录枚举或批量导出或导入任务）时，所有使用该共享资源的消费者的读取和写入操作的平均延迟和尾部延迟都会增加。 如果 NTDS.dit 或日志 I/O 必须在设备队列中等待，提升的延迟会直接减少 AD DS 响应能力。

建议的修正工作流：

1. 度量值：收集 LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read、 Avg Disk sec/Write、 Reads/sec、 Writes/sec和存储阵列统计信息（队列深度、控制器利用率），间隔为 15-60 分钟，涵盖峰值和维护时段。

2. 属性：确定哪个工作负荷导致延迟高峰（与备份窗口、防病毒扫描、批处理作业或 VM 邻居活动相关联）。 使用每个 LUN/每个 VM 指标（如果可用）。

3. 对问题类型进行分类：

   • 容量饱和（IOPS 或吞吐量一致接近设备/控制器规格和延迟上升）。
   • 突发干扰（短的高强度任务会增加尾部延迟，但不是平均利用率）。
   • 基础设施瓶颈（超额分配的主机总线适配器、交换机、路径故障转移导致可用通道减少、过时的驱动程序/固件、未对齐的多路径策略）。

4. 动作：

   • 重新平衡或隔离繁重的工作负荷，以分离 LUN/卷/存储层。
   • 为备份、完整的防病毒扫描和磁盘碎片整理错开或重新安排时间，以避开 AD DS 的峰值身份验证/查询周期。
   • 持续使用率较高时添加或升级存储组件。
   • 确保驱动程序/固件和多路径软件是当前且正确配置的。
   • 优化 RAM 的大小，使经常访问的数据保存在内存中，从而减少对存储的读取压力。

5. 验证：确认更改后延迟返回到目标（例如 2-6 毫秒 SSD/NVMe、4-12 毫秒轴），并且峰值队列深度仍保持在可接受的限制范围内。

模拟或加剧存储竞争的潜在瓶颈点包括超量配置的交换机或主机总线适配器共享线路。

在添加更多磁盘或移动到更快的媒体之前，请检查并排除这些磁盘。

始终将延迟数据与队列长度和设备/控制器利用率配对，以确定是优化、重新计划还是横向扩展。

关键成功条件：

• 在高峰 AD DS 负载期间，Avg Disk sec/Read和Avg Disk sec/Write持续保持在目标延迟带内。
• 没有长时间的 IOPS 达到稳定且延迟上升。 如果观察到，这可能表示饱和。
• 在定义的维护时段内执行繁重的维护任务，而不会将生产延迟推送到阈值以上。

如果在计划和配置调整后未满足目标，请转到容量扩展或迁移到高性能存储层。

附录 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 毫秒，选择较低端用于更快的媒体（NVMe/SSD），选择较高端用于较慢的层。

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

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

• 图表左侧用绿色圈出的区域显示，当负载从 800 IOPS 增加到 2,400 IOPS 时，延迟始终保持在 10 ms。 此延迟基线受所使用的存储解决方案类型的影响。
• 图表右侧用褐红色圈出的区域显示了从基线到数据收集结束之间的系统吞吐量。 吞吐量本身不会改变，但延迟会增加。 此区域显示请求卷通过存储系统的物理限制时会发生什么情况。 请求在被磁盘处理之前在队列中等待的时间更长。

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

首先，假设用户查询大型组的成员身份需要系统从磁盘读取 1MB 的数据。 可以评估所需的 I/O 量以及操作所花费的时间：

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

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

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

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

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