Active Directory 域服务容量计划
本主题最初由 Microsoft 项目经理 Ken Brumfield 编写，并为 Active Directory 域服务（AD DS）容量计划提供建议。
容量计划目标
容量计划不同于性能事件故障排除。 它们密切相关，但大不相同。 容量计划目标为：
- 正确实施和操作环境
- 最大程度地减少故障排除性能问题所花费的时间。
在容量计划中，组织的基线目标可能为在高峰期的处理器利用率达到 40%，从而满足客户端性能要求，并适应升级数据中心硬件所需的时间。 但是，若要收到异常性能事件通知，监视警报阈值可能会设置为 90%，间隔为 5 分钟。
区别在于，当持续超出容量管理阈值（不考虑一次性事件）时，解决方案将为添加容量（即添加更多或更快的处理器）或者跨多个服务器扩展服务。 性能警报阈值指示客户端体验当前正在遭受困扰，需要立即采取措施来解决问题。
类比来说：容量管理是为了防止车祸（防御性驾驶、确保刹车正常工作等），而性能故障排除是警察、消防部门和急救医疗专业人员在事故发生后所做的工作。 Active Directory 的风格正如“防御性驾驶”。
在过去的几年里，扩大系统的容量计划指南发生了巨大变化。 系统体系结构中的以下更改挑战了有关设计和缩放服务的基本假设：
- 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 分钟或一小时间隔查看此情况。 任何较大的值都可能隐藏实际峰值，而任何较小的值都可能因“暂时性峰值”而扭曲。
- 为企业硬件生命周期内的增长做计划。 其中可能包括以交错方式升级或添加硬件的策略，或每三到五年进行一次完全刷新。 每一项都需要“猜测”Active Directory 上的负载将增加多少。 如果收集了历史数据，将有助于此评估。
- 针对容错的重试。 得出估计值 N 后，请计划包括 N – 1、N – 2、N – x 的方案。
根据组织需要添加其他服务器，以确保单个或多个服务器的损失不会超过最大峰值容量估计值。
同时还需要考虑集成增长计划和容错计划。 例如，如果需要一个 DC 来支持负载，但估计下一年负载将翻倍并且总共需要两个 DC，则没有足够的容量来支持容错。 解决方案为使用三个 DC。 如果预算紧张，还可以计划在 3 或 6 个月后增加第三个 DC。
注意
无论负载来自应用程序服务器还是客户端，添加 Active Directory 感知应用程序均可能会对 DC 负载产生明显影响。
容量计划周期的三步过程
在容量计划中，首先确定所需的服务质量。 例如，核心数据中心支持更高级别的并发，并且需要为用户和使用应用程序提供更一致的体验，这需要更加关注冗余并最大程度地减少系统和基础结构瓶颈。 相比之下，具有少量用户的附属位置不需要相同级别的并发或容错。 因此，附属办公室可能不需要大量精力来优化基础硬件和基础结构，这可能会节省成本。 此处的所有建议和指南都是为了获得最佳性能，对于要求不高的方案，可以有选择地放宽。
下一个问题是：虚拟的还是物理的？ 从容量计划的角度来看，没有正确或错误的答案：只有一组不同的变量要处理。 虚拟化方案将从以下两个选项中选出一个：
- 每个主机一个来宾的“直接映射”（其中虚拟化仅用于从服务器中抽象物理硬件）
- “共享主机”
测试和生产方案表明，“直接映射”方案可以像物理主机一样对待。 但是，“共享主机”引发了一些注意事项，稍后会详细介绍。 “共享主机”方案意味着 AD DS 也在争用资源，这样需要惩罚和优化注意事项。
考虑到这些注意事项，容量计划周期是一个迭代的三步过程：
- 度量现有环境，确定当前系统瓶颈的位置，并获取计划所需容量所需的环境基础知识。
- 根据步骤 1 中概述的条件确定所需的硬件。
- 监视并验证实施的基础结构是否在规范范围内运行。 此步骤中收集的某些数据将成为下一个容量计划周期的基线。
应用过程
若要优化性能，请确保正确选择这些主要组件并优化到应用程序负载：
- 内存
- 网络
- 存储
- 处理器
- Net Logon
对于具有多达 10,000 到 20,000 名用户的环境，AD DS 拥有基本存储要求及编写出色的客户端软件的一般性能，可使其无需在涉及物理硬件的容量计划上进行大量投资，因为几乎任何现代服务器级系统都会处理这些负载。 下表总结了如何评估现有环境以选择正确的硬件。 以下各节会详细分析每个组件，以帮助 AD DS 管理员使用基线建议和特定于环境的主体评估其基础结构。
一般而言：
- 基于当前数据的任何大小调整都仅适用于当前环境。
- 根据任何估计，整个硬件生命周期中的需求都会增加。
- 确定是立即扩大规模并扩展到更大的环境，还是增加整个生命周期的容量。
- 容量计划原则和方法同样适用于虚拟化，但虚拟化开销需要添加到任何与域相关的内容中。
- 与任何尝试预测的事物一样，容量计划并不是一门准确的科学。 不要期望计算完美且准确率达到 100%。 此处的指南是最精简的建议：增加容量以增加安全性，并持续验证环境是否与目标保持一致。
数据收集摘要表
新环境
| 组件 | 估算 |
|---|---|
| 存储/数据库大小 | 每个用户 40 KB 到 60 KB |
| RAM | 数据库大小 基本操作系统建议 第三方应用程序 |
| 网络 | 1GB |
| CPU | 每个核心 1000 个并发用户 |
高级评估条件
| 组件 | 评估条件 | 规划注意事项 |
|---|---|---|
| 存储/数据库大小 | 存储限制中标题为“激活通过碎片整理释放的磁盘空间的日志记录”的一节 | |
| 存储/数据库性能 |
|
|
| RAM |
|
|
| 网络 |
|
|
| CPU |
|
|
| NetLogon |
|
|
规划
长期以来，社区对调整 AD DS 大小的建议一直是“根据数据库大小添加 RAM”。 在大多数情况下，该建议是大多数环境需要关注的。 但自 1999 年推出以来，使用 AD DS 的生态系统和 AD DS 环境本身都变大了。 尽管计算能力提高并且从 x86 体系结构转换到 x64 体系结构，性能大小调整的细微方面对于在物理硬件上运行 AD DS 的许多客户来说已变得无关紧要，但虚拟化的增长为比以前更多的受众重新带来了优化问题。
因此，以下指南介绍如何确定和计划 Active Directory 即服务的需求，无论它是部署在物理、虚拟/物理组合还是纯虚拟化方案中。 因此，我们将评估分为四个主要组件：存储、内存、网络和处理器。 简言之，为了最大限度地提高 AD DS 的性能，目标是尽可能接近处理器限制。
RAM
简而言之，RAM 中可以缓存的内容越多，需要移动到磁盘的就越少。 若要最大化服务器的可伸缩性，最小 RAM 量应为当前数据库大小、总 SYSVOL 大小、操作系统建议量、以及供应商对代理（防病毒、监视、备份等）的建议量之和。 应添加额外的容量，以适应服务器生存期内的增长。 根据环境变化对数据库增长的估计，这将会受到环境的影响。
对于最大化 RAM 量不具有成本效益（例如在附属位置）或不可行（DIT 太大）的环境，请参阅“存储”一节以确保存储设计正确。
调整内存大小的常见结果是调整页面文件大小。 在与内存相关的其他所有背景相同的情况下，目标是尽量减少移到速度较慢的磁盘。 因此，问题应该从“我应该如何设置页面文件的大小？”开始，然后 到“需要多少 RAM 才能最小化分页？” 后一个问题的答案将在本节的其余部分概述。 因此，有关调整页面文件大小的大部分讨论就保留在常规操作系统建议的领域，以及需要为系统配置内存转储（与 AD DS 性能无关）。
正在评估
域控制器（DC）所需的 RAM 量实际上很复杂，原因如下：
- 尝试使用现有系统来测量所需的 RAM 量时，出错的可能性很大，因为 LSASS 会在内存压力条件下进行修整，从而不自然地减少需求。
- 主观事实是，单个 DC 只需缓存其客户端“感兴趣”的内容。 这意味着，需要在只有 Exchange 服务器的站点中的 DC 上缓存的数据与需要在仅对用户进行身份验证的 DC 上缓存的数据大相径庭。
- 无法逐个评估每个 DC 的 RAM，并且会随着环境的变化而变化。
- 建议背后的条件将有助于做出明智的决策：
- RAM 中可以缓存的内容越多，需要移动到磁盘的就越少。
- 存储是迄今为止计算机中最慢的组件。 访问基于主轴和 SSD 存储介质的数据的速度比访问 RAM 中的数据慢 1,000,000 倍。
因此，若要最大化服务器的可伸缩性，最小 RAM 量为当前数据库大小、总 SYSVOL 大小、操作系统建议量、以及针对代理（防病毒、监视、备份等）的供应商建议量之和。 添加额外的容量，以适应服务器生存期内的增长。 这会受到基于数据库增长估计的环境影响。 但是，对于拥有少量最终用户的附属位置，要求可以放宽，因为这些站点不需要缓存太多即可为大多数请求提供服务。
对于最大化 RAM 量不具有成本效益（例如在附属位置）或不可行（DIT 太大）的环境，请参阅“存储”一节以确保存储大小正确。
注意
调整内存大小的必然结果是调整页面文件的大小。 由于目标是尽量减少移到速度较慢的磁盘，因此问题应该从“我应该如何设置页面文件的大小？”开始，然后 到“需要多少 RAM 才能最小化分页？” 后一个问题的答案将在本节的其余部分概述。 因此，有关调整页面文件大小的大部分讨论就保留在常规操作系统建议的领域，以及需要为系统配置内存转储（与 AD DS 性能无关）。
RAM 虚拟化注意事项
避免过度使用主机内存。 优化 RAM 量背后的基本目标是最大程度地减少移动到磁盘的时间。 在虚拟化方案中，当分配给来宾的 RAM 多于物理计算机上存在的 RAM 时，存在过度使用内存的概念。 这本身不是问题。 当所有来宾主动使用的内存总量超过主机的 RAM 容量并且基础主机开始分页时，这将成为一个问题。 如果域控制器要访问 NTDS.dit 获取数据，或者域控制器要访问页面文件来获取数据，或者主机要访问磁盘以获取来宾认为位于 RAM 中的数据，性能将受磁盘限制。
计算摘要示例
| 组件 | 估计内存（示例） |
|---|---|
| 基本操作系统推荐的 RAM （Windows Server 2008） | 2 GB |
| LSASS 内部任务 | 200 MB |
| 监视代理 | 100 MB |
| 防病毒 | 100 MB |
| 数据库（全局编录） | 8.5 GB |
| 用于执行备份的缓冲，以便管理员登录而不会受到影响 | 1GB |
| 总计 | 12 GB |
建议：16 GB
随着时间的推移，可以设想，会向数据库添加更多数据，并且服务器可能会投入生产 3 到 5 年。 根据 33% 的增长估计，16 GB 是放入物理服务器的合理 RAM 量。 在虚拟机中，鉴于可以方便地修改设置和将 RAM 添加到 VM，因此从 12 GB 开始并计划在将来进行监视和升级是较为合理的。
网络
正在评估
本节不重点评估对遍历 WAN 的复制通信的请求（对此将在Active Directory 复制流量中完整介绍），而是评估所需的总带宽和网络容量，包括客户端查询、组策略应用程序等。 对于现有环境，可以使用性能计数器“Network Interface(*)\Bytes Received/sec”和“Network Interface(*)\Bytes Sent/sec”收集。 网络接口计数器的采样间隔为 15、30 或 60 分钟。 如果采样间隔较小，则通常太不稳定而无法进行适当的度量；如果间隔较大，则每日峰值将过于平滑。
注意
通常，DC 上的大多数网络流量都是在 DC 响应客户端查询时的出站流量。 这是关注出站流量的原因，但建议也评估每个环境的入站流量。 可以使用相同的方法来解决和查看入站网络流量要求。 有关详细信息，请参阅知识库文章 929851：TCP/IP 的默认动态端口范围在 Windows Vista 和 Windows Server 2008 中已更改。
带宽需求
网络可伸缩性计划包括两个不同的类别：流量和来自网络流量的 CPU 负载。 与本文的其他主题相比，每个方案都很简单。
对于评估必须支持的流量大小，AD DS 在网络流量方面有两项独特的容量计划类别。 第一个是在域控制器之间遍历的复制流量，这在参考文章 Active Directory 复制流量中有全面介绍，但也与 AD DS 的当前版本相关。 第二个是站点内的客户端到服务器流量。 一种更简单的计划方案是，站点内流量主要接收来自客户端的小型请求，相对于发送回客户端的大量数据。 对于站点中每个服务器最多 5,000 个用户的环境，100 MB 通常就足够了。 超过 5,000 个用户，建议使用 1 GB 网络适配器和接收方缩放 (RSS) 支持。 若要验证此方案（尤其是在服务器合并方案中），请查看站点中所有 DC 的 Network Interface(*)\Bytes/sec，将它们相加，并除以域控制器的目标数量，以确保有足够的容量。 执行此操作的最简单方法是，使用 Windows 可靠性和性能监视器（前称 Perfmon）中的“堆积面积图”视图，确保所有计数器的缩放方式相同。
请考虑以下示例（也称为验证一般规则是否适用于特定环境的非常复杂的方法）。 做出以下假设：
- 目标是尽可能减少服务器占用空间。 理想情况下，一台服务器将处理负载并部署额外的服务器以实现冗余（N + 1 方案）。
- 在此方案中，当前网络适配器仅支持 100 MB，并且位于交换环境中。 在 N 方案（丢失 DC）中，目标网络带宽的最大利用率为 60%。
- 每个服务器大约连接到 10,000 个客户端。
从图表中的数据获得的知识 (Network Interface(*)\Bytes Sent/sec)：
- 工作日从 5:30 左右开始增加，在晚上 7:00 开始减少。
- 高峰时段为上午 8:00 至上午 8:15，最繁忙的 DC 每秒发送超过 25 字节。
注意
所有性能数据都是历史数据。 因此，8:15 的峰值数据点显示从 8:00 至 8:15 的负载。
- 凌晨 4:00 之前会出现峰值，最繁忙的 DC 每秒发送超过 20 个字节，这可能表示来自不同时区的负载或后台基础结构活动（例如备份）。 由于上午 8:00 的峰值超过了此活动，因此不相关。
- 站点中有五个域控制器。
- 每个 DC 的最大负载约为 5.5 MB/s，占 100 MB 连接的 44%。 使用此数据，估计上午 8:00 至上午 8:15 之间所需的总带宽为 28 MB/s。
注意
请注意，网络接口发送/接收计数器以字节为单位，网络带宽以位为单位。 100 MB ÷ 8 = 12.5 MB、1 GB ÷ 8 = 128 MB。
结论：
- 此当前环境在 60% 的目标利用率下满足 N + 1 级别容错。 使一个系统脱机，将使每个服务器的带宽从大约 5.5 MB/s (44%) 变为大约 7 MB/s (56%)。
- 基于上述整合到单个服务器的目标，这超过了最大目标利用率和 100 MB 连接的理论可能利用率。
- 使用 1 GB 连接时，这将占总容量的 22%。
- 在 N + 1 方案中的正常运行条件下，客户端负载将相对均匀地分布在每个服务器大约 14 MB/s 或总容量的 11%。
- 为了确保在 DC 不可用期间容量充足，每个服务器的正常运行目标大约为 30% 的网络利用率或 38 MB/s。 故障转移目标是 60% 的网络利用率或每个服务器 72 MB/s。
简言之，系统的最终部署必须具有 1 GB 网络适配器，并连接到支持所述负载的网络基础结构。 另请注意，鉴于生成的网络流量，网络通信的 CPU 负载可能会产生重大影响，并限制 AD DS 的最大可伸缩性。 此过程可用于估计到 DC 的入站通信量。 但是，鉴于出站流量比入站流量多得多，对于大多数环境而言，这是一种学术实践。 在每个服务器超过 5,000 个用户的环境中，确保 RSS 的硬件支持非常重要。 对于网络流量较高的方案，均衡中断负载可能是一个瓶颈。 这可以通过 Processor(*)% Interrupt Time 在 CPU 之间的分布不均匀来检测。 已启用 RSS 的 NIC 可以缓解此限制并提高可伸缩性。
注意
类似的方法可用于估计合并数据中心或停用附属位置中的域控制器时所需的额外容量。 只需收集到客户端的出站和入站流量，即 WAN 链接上现在存在的流量。
在某些情况下，由于流量较慢（例如证书检查无法满足 WAN 上的激进超时），因此可能会导致比预期更多的流量。 出于此原因，WAN 大小调整和利用率应该是一个迭代的持续过程。
网络带宽的虚拟化注意事项
为物理服务器提供建议很容易：对于支持超过 5000 个用户的服务器，为 1 GB。 一旦多个来宾开始共享基础虚拟交换机基础结构后，需要额外注意以确保主机有足够的网络带宽来支持系统上的所有来宾，因此需要额外的严格措施。 这不过是确保网络基础结构进入主机的扩展。 无论网络是否包含作为虚拟机来宾运行的域控制器在通过虚拟交换机的网络流量的主机上运行，或者是否直接连接到物理交换机。 虚拟交换机只是上行链路需要支持传输的数据量的一个组件。 因此，链接到交换机的物理主机物理网络适配器应能够支持 DC 负载以及共享连接到物理网络适配器的虚拟交换机的所有其他来宾。
计算摘要示例
| 系统 | 峰值带宽 |
|---|---|
| DC 1 | 6.5 MB/s |
| DC 2 | 6.25 MB/s |
| DC 3 | 6.25 MB/s |
| DC 4 | 5.75 MB/s |
| DC 5 | 4.75 MB/s |
| 总计 | 28.5 MB/s |
建议：72 MB/s（28.5 MB/s 除以 40%）
| 目标系统计数 | 总带宽（从上方） |
|---|---|
| 2 | 28.5 MB/s |
| 由此产生的常规行为 | 28.5 ÷ 2 = 14.25 MB/s |
与往常一样，可以假设随着时间的推移客户端负载将增加，应尽可能为增长而计划。 建议的计划容量要考虑网络流量估计增加 50%。
存储
存储计划由两个部分组成：
- 容量或存储大小
- 性能
在计划容量上花费了大量时间和文档，而性能经常被完全忽视。 在当前的硬件成本下，大多数环境都不足够大，以至于其中任何一个实际上都是问题，而“根据数据库大小添加 RAM”的建议通常会涵盖其余部分，尽管对于较大环境中的附属位置来说可能有些滥用。
大小调整
评估存储
在 13 年前推出 Active Directory 时，4 GB 和 9 GB 是最常见的驱动器大小，与那个时代相比，除了最大的环境之外，Active Directory 的大小甚至不是所有环境的考虑因素。 使用 180 GB 范围内的最小可用硬盘驱动器大小，整个操作系统、SYSVOL 和 NTDS.dit 可以轻松地安装在单个驱动器上。 因此，建议放弃在此领域的大量投资。
唯一要考虑的建议是确保 110% 的 NTDS.dit 大小可用，以便启用碎片整理。 此外，还应该适应硬件生命周期的增长。
第一个也是最重要的考虑因素是评估 NTDS.dit 和 SYSVOL 的大小。 这些度量值将导致调整固定磁盘和 RAM 分配的大小。 由于这些组件（相对）便宜，因此计算不必精确或准确。 有关如何针对现有环境和新环境评估此内容的内容，请参阅数据存储系列文章。 具体而言，请参阅下列文章：
对于现有环境 – 文章存储限制中标题为“激活通过碎片整理释放的磁盘空间的日志记录”的一节。
对于新环境 - 标题为 Active Directory 用户和组织单位增长估计一文。
注意
这些文章基于在 Windows 2000 中发布 Active Directory 时进行的数据大小估计。 使用反映环境中对象实际大小的对象大小。
查看具有多个域的现有环境时，数据库大小可能会有所不同。 如果是这种情况，请使用最小的全局编录（GC）和非 GC 大小。
数据库大小可能因操作系统版本而异。 运行早期操作系统（如 Windows Server 2003）的 DC 的数据库大小比运行更高版本的操作系统（如 Windows Server 2008 R2）的 DC 更小，尤其是在启用了 Active Directory 回收站或凭据漫游等功能时。
注意
- 对于新环境，请注意 Active Directory 用户和组织单位的增长估计中的估计值表明，100,000 个用户（在同一域中）占用大约 450 MB 的空间。 请注意，填充的属性可能会对总量产生巨大影响。 属性由第三方和 Microsoft 产品（包括 Microsoft Exchange Server 和 Lync）在多个对象上填充。 最好根据环境中的产品组合进行评估，但除最大环境之外，对环境进行详细计算和测试准确估计可能并不值得花费大量时间和精力。
- 确保 110% 的 NTDS.dit 大小可用作可用空间，以便启用脱机碎片整理，并计划在 3 至 5 年的硬件生命周期内进行扩展。 鉴于存储成本较低，估计存储大小为 DIT 大小的 300% 作为存储分配足以满足扩展和脱机碎片整理的潜在需求。
存储虚拟化注意事项
在单个卷上分配多个虚拟硬盘（VHD）文件时，请使用至少为 DIT 大小的 210%（DIT 的 100% + 110% 可用空间）的固定大小磁盘，以确保保留足够的空间。
计算摘要示例
| 从评估阶段收集的数据 | 大小 |
|---|---|
| NTDS.dit 大小 | 35 GB |
| 允许脱机碎片整理的修饰符 | 2.1 GB |
| 所需的总存储空间 | 73.5 GB |
注意
此存储是除 Sysvol 操作系统页面文件临时文件本地缓存数据（如安装程序文件）和应用程序所需的存储之外的存储。
存储性能
评估存储性能
存储是计算机中速度最慢的组件，对客户端体验的负面影响最大。 对于 RAM 大小建议不可行的大型环境，在存储计划中忽视性能的后果可能是灾难性的。 此外，存储技术的复杂性和多样性限制了“将操作系统、日志和数据库放在单独的物理磁盘上”的长期最佳做法在有用方案中的适用性，从而增加了失败的风险。 这是因为长期存在的最佳做法基于以下假设：“磁盘”是专用主轴，这允许隔离 I/O。 使这一点成为现实的假设不再与引入以下项相关：
- RAID
- 新的存储类型以及虚拟化和共享存储方案
- 存储区域网络（SAN）上的共享主轴
- SAN 或网络连接存储上的 VHD 文件
- 固态硬盘
- 分层存储体系结构（即 SSD 存储层缓存更大的基于主轴的存储）
具体而言，共享存储（RAID、SAN、NAS、JBOD（即存储空间）、VHD）都能够被放置在后端存储上的其他工作负荷超额订阅/重载。 这些还增加了一个挑战，即 SAN/网络/驱动程序问题（物理磁盘和 AD 应用程序之间的一切）可能导致限制和/或延迟。 需要明确的是，这些并不是“糟糕的”配置，而是更复杂的配置，需要所有组件在整个过程中正常工作，因此需要额外注意以确保性能是可接受的。 有关更详细的说明，请参阅本文档后面的附录 C 小节“SAN 简介”和附录 D。 此外，虽然固态硬盘没有旋转磁盘（硬盘驱动器）一次只允许处理一个 IO 的限制，但它们仍存在 IO 限制，并且 SSD 可能会重载/超额订阅。 简言之，无论基础存储体系结构和设计如何，所有存储性能工作的最终目标是确保所需的每秒输入/输出操作数（IOPS）可用，并确保这些 IOPS 在可接受的时间范围内发生（如本文档其他部分所述）。 对于本地附加存储的方案，请参阅附录 C，了解如何设计传统的本地存储方案的基础知识。 这些原则通常适用于更复杂的存储层，也有助于与支持后端存储解决方案的供应商进行对话。
- 鉴于可用的存储选项范围广泛，建议利用硬件支持团队或供应商的专业知识，以确保特定解决方案满足 AD DS 的需求。 以下数字将作为提供给存储专家的信息。
对于数据库太大而无法保存在 RAM 中的环境，使用性能计数器来确定需要支持的 I/O 量：
- LogicalDisk(*)\Avg Disk sec/Read（例如，如果 NTDS.dit 存储在 D:/ drive，完整路径则为 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 分钟的间隔采样，以对当前环境的需求进行基准测试。
评估结果
注意
重点是从数据库中读取，因为通常这是要求最苛刻的组件，可以通过替换 LogicalDisk(<NTDS Log>)\Avg Disk sec/Write 和 LogicalDisk(<NTDS Log>)\Writes/sec)，将相同的逻辑应用于写入日志文件：
- LogicalDisk(<NTDS>)\Avg Disk sec/Read 指示当前存储的大小是否足够。 如果结果大致等于磁盘类型的“磁盘访问时间”，则 LogicalDisk(<NTDS>)\Reads/sec 是有效的度量值。 检查后端存储的制造商规格，但 LogicalDisk(<NTDS>)\Avg Disk sec/Read 的合适范围大致为：
- 7200 – 9 到 12.5 毫秒 (ms)
- 10,000 – 6 到 10 ms
- 15,000 – 4 至 6 ms
- SSD – 1 至 3 ms
-
注意
建议指出存储性能下降 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) ÷ (Physical Media Disk Access Time) × (LogicalDisk(<NTDS>)\Avg Disk sec/Read)
注意事项：
- 请注意，如果为服务器配置了欠佳的 RAM 量，则这些值在计划中将不准确。 值将错误地偏高，仍然可以用作最坏的情况。
- 专门添加/优化 RAM 将减少读取 I/O (LogicalDisk(<NTDS>)\Reads/Sec 的数量。这意味着存储解决方案可能不必像最初计算的那样可靠。 遗憾的是，比此一般声明更具体的任何内容都依赖于客户端负载的环境，无法提供一般指南。 最佳选择是在优化 RAM 后调整存储大小。
性能虚拟化注意事项
与上述所有虚拟化讨论类似，此处的关键是确保基础共享基础结构可以使用基础共享媒体和通往它的所有路径支持 DC 负载以及其他资源。 无论物理域控制器与 SAN、NAS 或 iSCSI 基础结构上的其他服务器或应用程序共享相同的基础媒体，无论来宾是使用对 SAN、NAS 或 iSCSI 基础结构的直通访问还是使用本地共享媒体或是驻留在 SAN、NAS 或 iSCSI 基础结构上的 VHD 文件，都是如此。 计划活动旨在确保基础媒体能够支持所有使用者的总负载。
此外，从来宾的角度来看，由于必须遍历其他代码路径，因此必须通过主机访问任何存储会影响性能。 当然，存储性能测试表明，虚拟化对吞吐量的影响取决于主机系统的处理器利用率（请参阅附录 A：CPU 大小调整条件），这显然受来宾请求的主机资源的影响。 这与虚拟化方案中有关处理需求的虚拟化注意事项有关（请参阅虚拟化处理注意事项）。
更加复杂的是，存在各种不同的存储选项，它们都对性能产生不同的影响。 作为从物理迁移到虚拟的安全估计，使用乘数 1.10 来调整 Hyper-V 上虚拟化来宾的不同存储选项，例如直通存储、SCSI 适配器或 IDE。 在不同存储方案之间传输时必须进行的调整，与存储是本地存储、SAN、NAS 存储还是 iSCSI 无关联。
计算摘要示例
确定正常运行条件下正常系统所需的 I/O 量：
- 在高峰期 15 分钟期间，LogicalDisk(<NTDS Database Drive>)\Transfers/sec
- 确定超出基础存储容量的存储所需的 I/O 量：
所需的 IOPS = (LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Read ÷ <Target Avg Disk sec/Read>) × LogicalDisk(<NTDS Database Drive>)\Read/sec
| 计数器 | 值 |
|---|---|
| 实际 LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Transfer | 0.02 秒（20 毫秒） |
| 目标 LogicalDisk(<NTDS Database Drive>)\Avg Disk sec/Transfer | 0.01 秒 |
| 可用 IO 变化的乘数 | 0.02 ÷ 0.01 = 2 |
| 值名称 | 值 |
|---|---|
| LogicalDisk(<NTDS Database Drive>)\Transfers/sec | 400 |
| 可用 IO 变化的乘数 | 2 |
| 高峰期所需的总 IOPS | 800 |
若要确定缓存所需的预热速率，请执行以下命令：
- 确定预热缓存的可接受最长时间。 指从磁盘加载整个数据库所花费的时间，或者对于不能在 RAM 中加载整个数据库的情况，指填充 RAM 的最长时间。
- 确定数据库的大小，不包括空格。 有关详细信息，请参阅评估存储。
- 将数据库大小除以 8 KB 将是加载数据库所需的总 IO 数。
- 将总 IO 数除以定义的时间范围内秒数。
请注意，计算的速率虽然准确，但如果 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 处理器使用情况
对于大多数环境，在按照“计划”一节所述正确优化存储、RAM 和网络后，管理处理容量将是最值得关注的组件。 评估所需的 CPU 容量时，存在两个挑战：
环境中的应用程序是否在共享服务基础结构中表现良好，并在《创建更高效的 Microsoft Active Directory 应用程序》一文中标题为“跟踪昂贵且低效的搜索”一节中进行了讨论，或从下层 SAM 调用迁移到 LDAP 调用。
在大型环境中，这一点很重要，因为编码不当的应用程序可能会导致 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”中的数据会人为降低，这是 Microsoft 支持用于故障排除与存储相关的性能问题的常规阈值。 与以前一样，建议采样间隔为 15 分钟、30 分钟或 60 分钟。 如果采样间隔较小，则通常太不稳定而无法进行适当的度量；如果间隔较大，则每日峰值将过于平滑。
介绍
要计划域控制器的容量计划，最需要关注和理解的是处理能力。 调整系统大小以确保最佳性能时，始终有一个组件是瓶颈，在适当大小的域控制器中，该组件将是处理器。
与按站点审查环境需求的网络部分类似，必须为所需的计算容量执行相同的操作。 与网络部分不同，其中可用的网络技术远远超过正常需求，请更加注意调整 CPU 容量的大小。 与任何中型环境一样；超过几千个并发用户的任何内容都可能会给 CPU 带来巨大的负载。
遗憾的是，由于利用 AD 的客户端应用程序存在巨大差异，因此对每个 CPU 的用户进行一般估计无法适用于所有环境。 具体而言，计算需求受用户行为和应用程序配置文件的约束。 因此，每个环境都需要单独调整大小。
目标网站行为配置文件
如前所述，在计划整个站点的容量时，目标是采用 N + 1 容量设计，这样，系统在高峰期发生故障时，它可以继续以合理的质量水平提供服务。 这意味着，在“N”方案中，高峰期所有箱子的负载应低于 100%（最好小于 80%）。
此外，如果站点中的应用程序和客户端使用最佳做法来查找域控制器 (即使用 dsGetDcName 函数)，则由于多种因素，客户端应相对均匀地分布，且出现轻微的暂时性峰值。
在下一个示例中，将做出以下假设：
- 站点中五个 DC 中的每一个都有四个 CPU。
- 在正常操作条件（“N + 1”）下，工作时间的总目标 CPU 利用率为 40%，否则为 60%（“N”）。 在非工作时间，目标 CPU 利用率为 80%，因为备份软件和其他维护预期会消耗所有可用资源。
分析图表 (Processor Information(_Total)\% Processor Utility) 中每个 DC 的数据：
在大多数情况下，负载相对均匀地分布，客户端使用 DC 定位符并且搜索写得很好的话，这是可以预料的。
在 10% 时有一些 5 分钟的峰值，有些高达 20%。 通常，除非它们导致超出容量计划目标，否则不值得研究。
所有系统的高峰期大约在上午 8:00 至上午 9:15 之间。 从凌晨 5:00 左右平稳过渡至下午 5:00 左右，这通常表明业务周期。 在下午 5:00 至凌晨 4:00 之间，每个盒子方案的 CPU 利用率的随机峰值超出了容量计划考虑范围。
注意
在管理良好的系统上，上述峰值可能是正在运行的备份软件、完整的系统防病毒扫描、硬件或软件清单、软件或修补程序部署等。 由于它们在用户业务周期的高峰期之外，因此不会超出目标。
由于每个系统大约占用 40%，并且所有系统的 CPU 数量相同，因此如果一个系统发生故障或脱机，其余系统将以估计的 53% 运行（系统 D 40% 负载将平分并添加到系统 A 和系统 C 上的现有 40% 负载中）。 由于多种原因，此线性假设并不完全准确，但提供足够的测量准确度。
备用方案 – 两个域控制器以 40% 运行：一个域控制器发生故障，估计另一个域控制器的 CPU 为 80%。 这远远超出了上面概述的容量计划阈值，并且开始严重限制上述负载配置文件中 10% 到 20% 的净空量，这意味着在“N”方案中，峰值将推动 DC 达到 90% 到 100%，并且肯定会降低响应能力。
计算 CPU 需求
“Process\% Processor Time”性能对象计数器将应用程序的所有线程在 CPU 上花费的总时间相加，并除以已用总系统时间量。 这样做的效果是，多 CPU 系统上的多线程应用程序可能超过 100% 的 CPU 时间，其解释方式与“Processor Information\% Processor Utility”非常不同。 实际上，“Process(lsass)\% Processor Time”可视为支持进程需求所需的 100% 运行的 CPU 数。 值为 200% 表示需要 2 个 CPU，每个为 100%，才能支持完整的 AD DS 负载。 尽管从 CPU、电源和能耗方面花费的资金来看，以 100% 容量运行的 CPU 是最经济高效的，但出于附录 A 中详述的一些原因，当系统未以 100% 运行时，多线程系统的响应能力会更好。
为了适应客户端负载的暂时性峰值，建议将高峰期 CPU 设定为系统容量的 40% 到 60%。 使用上面的示例，意味着需要 3.33（60% 目标）到 5（40% 目标）CPU 用于 AD DS（lsass 进程）负载。 应根据基本操作系统和所需的其他代理（如防病毒、备份、监视等）的需求添加额外的容量。 尽管需要根据每个环境评估代理的影响，但可以估计为单个 CPU 的 5% 到 10%。 在当前示例中，这表示高峰期需要 3.43（60% 目标）和 5.1（40% 目标）CPU。
执行此操作的最简单方法是，使用 Windows 可靠性和性能监视器（Perfmon）中的“堆积面积图”视图，确保所有计数器的缩放方式相同。
假设：
- 目标是尽可能减少服务器占用空间。 理想情况下，一台服务器将处理负载并添加额外的服务器以实现冗余（N + 1 方案）。
从图表中的数据获得的知识 (Process(lsass)\% Processor Time)：
- 工作日从 7:00 左右开始增加，在下午 5:00 开始减少。
- 最繁忙的时段是上午 9:30 至上午 11:00。
注意
所有性能数据都是历史数据。 9:15 的峰值数据点显示从 9:00 至 9:15 的负载。
- 上午 7:00 之前会出现峰值，这可能表示来自不同时区的负载或后台基础结构活动（例如备份）。 由于上午 9:30 的峰值超过了此活动，因此不相关。
- 站点中有三个域控制器。
在最大负载下，lsass 消耗一个 CPU 的大约 485%，或者说 4.85 个 CPU 以 100% 的速度运行。 根据前面的计算，这意味着站点需要大约 12.25 个 CPU 用于 AD DS。 加上上述后台进程 5% 到 10% 的建议，这意味着更换现在的服务器将需要大约 12.30 到 12.35 个 CPU 才能支持相同的负载。 现在需要考虑对增长的环境估计。
何时优化 LDAP 权重
在几种情况下，应考虑优化 LdapSrvWeight。 在容量计划环境中，当应用程序或用户负载不均匀时，或者基础系统容量不均匀时，将执行此操作。 超出容量计划的原因不在本文讨论范围内。
优化 LDAP 权重有两个常见原因：
- PDC 仿真器是影响用户或应用程序加载行为未均匀分布的每个环境的示例。 由于某些工具和操作针对 PDC 仿真器（如组策略管理工具），因此身份验证失败或信任建立等的第二次尝试可能会比站点中的其他位置更频繁地请求 PDC 仿真器的 CPU 资源。
- 仅当 CPU 利用率存在明显差异时，才能进行此优化，以便减少 PDC 仿真器上的负载，并增加其他域控制器上的负载，从而更均匀地分配负载。
- 在这种情况下，将 PDC 仿真器的 LDAPSrvWeight 设置为 50 到 75 之间。
- 站点中具有不同 CPU 计数（和速度）的服务器。 例如，假设有两个八核服务器和一个四核服务器。 最后一个服务器的处理器是其他两个服务器的一半。 这意味着，当客户端负载分布良好时，四核机箱上的平均 CPU 负载增加至八核机箱的大约两倍。
- 例如，两个八核机箱的运行率为 40%，四核机箱的运行率为 80%。
- 此外，请考虑在这种情况下丢失一个八核机箱的影响，特别是四核盒现在超载的事实。
示例 1 - PDC
| 系统 | 使用默认值的利用率 | New LdapSrvWeight | 估计的新利用率 |
|---|---|---|---|
| DC 1（PDC 仿真器） | 53% | 57 | 40% |
| DC 2 | 33% | 100 | 40% |
| DC 3 | 33% | 100 | 40% |
此处的问题是，如果 PDC 仿真器角色被站点中的另一个域控制器移动或占用时，则新的 PDC 仿真器将急剧增加。
使用目标站点行为配置文件部分中的示例，假设站点中的所有三个域控制器都有四个 CPU。 在正常情况下，如果其中一个域控制器有八个 CPU，会发生什么情况？ 两个域控制器的利用率为 40%，一个域控制器的利用率为 20%。 虽然还不错，但可以更好地平衡负载。 利用 LDAP 权重来实现此目的。 一个示例方案是：
示例 2 - 不同的 CPU 计数
| 系统 | Processor Information\ % Processor Utility(_Total) 使用默认值的利用率 |
New LdapSrvWeight | 估计的新利用率 |
|---|---|---|---|
| 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% 的相同目标。 在下一层（来宾层），由于线程计划的原则没有更改，因此来宾内部的目标保持在 40% 到 60% 的范围内。
在直接映射方案中，每个主机有一个来宾，为此完成的所有容量计划都需要添加到基础主机操作系统的要求（RAM、磁盘、网络）。 在共享主机方案中，测试表明，对基础处理器的效率有 10% 的影响。 这意味着，如果站点在 40% 的目标下需要 10 个 CPU，则建议在所有“N”来宾之间分配的虚拟 CPU 量为 11。 在物理服务器和虚拟服务器混合分布的站点中，修饰符仅适用于 VM。 例如，如果站点具有“N + 1”方案，则具有 10 个 CPU 的物理或直接映射服务器大约相当于主机上具有 11 个 CPU 的一个来宾，并为域控制器保留 11 个 CPU。
在对支持 AD DS 负载所需的 CPU 数量的分析和计算过程中，映射到物理硬件可购买的 CPU 数量不一定映射清晰。 虚拟化无需四舍五入。 虚拟化减少了向站点添加计算容量所需的工作量，因为可以方便地将 CPU 添加到 VM。 它不会消除准确评估所需计算能力的需求，以便在需要向来宾添加更多 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 身份验证的标识的身份验证请求，需要使用域控制器的安全通道将信任遍历到目标域中的另一个域控制器或目标域路径中的下一个域。 域控制器可以使用安全通道对受信任域中的域控制器进行的并发调用数由称为 MaxConcurrentAPI 的设置控制。 对于域控制器，请使用以下两种方法之一来确保安全通道能够处理负载：优化 MaxConcurrentAPI 或在林中创建快捷方式信任。 若要测量单个信任之间的流量，请参阅 如何使用 MaxConcurrentApi 设置对 NTLM 身份验证执行性能调整。
在数据收集期间，与所有其他方案一样，必须在一天的高峰繁忙时段收集才能使数据有用。
注意
林内和林间方案可能导致身份验证遍历多个信任，每个阶段都需要优化。
规划
默认情况下或在特定配置方案中，有几个应用程序使用 NTLM 身份验证。 应用程序服务器的容量不断增长，并为越来越多的活动客户端提供服务。 还有一种趋势是，客户端在有限的时间内保持会话打开状态并定期重新连接（例如邮件拉取同步）。 高 NTLM 负载的另一个常见示例是，需要对 Internet 访问进行身份验证的 Web 代理服务器。
这些应用程序可能会导致 NTLM 身份验证出现重大负载，从而给 DC 带来巨大压力，尤其是在用户和资源位于不同域中时。
有多种方法来管理跨信任负载，实际上，这些方法被结合使用，而不是在独占的一个方案中使用。 可能的选项包括：
- 通过在用户驻留的同一域中查找其使用的服务，减少跨信任客户端身份验证。
- 增加可用的安全渠道数目。 这与林内和林间流量相关，称为快捷方式信任。
- 优化 MaxConcurrentAPI 的默认设置。
若要优化现有服务器上的 MaxConcurrentAPI，公式为：
New_MaxConcurrentApi_setting ≥ (semaphore_acquires + semaphore_time-outs) × average_semaphore_hold_time ÷ time_collection_length
有关详细信息，请参阅知识库文章 2688798：如何使用 MaxConcurrentApi 设置对 NTLM 身份验证执行性能调整。
虚拟化注意事项
无，这是操作系统优化设置。
计算摘要示例
| 数据类型 | 值 |
|---|---|
| 信号灯获取（最小值） | 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，不在同一集成电路上
逻辑处理器 - 从操作系统的角度来看，一个逻辑计算引擎
这包括超线程、多核处理器上的一个核心或单核处理器。
由于当今的服务器系统具有多个处理器、多个多核处理器和超线程，因此此信息已经过概括以涵盖这两种方案。 因此，将使用术语逻辑处理器，因为它表示可用计算引擎的操作系统和应用程序透视图。
线程级并行度
每个线程都是独立的任务，因为每个线程都有自己的堆栈和指令。 由于 AD DS 是多线程的，并且可以使用 Ntdsutil.exe 在 Active Directory 中查看和设置 LDAP 策略来优化可用线程数，因此它可以跨多个逻辑处理器较好地进行缩放。
数据级并行度
这涉及到在单个进程内的多个线程之间共享数据（仅适用于 AD DS 进程）以及（通常）在多个进程中的多个线程之间共享数据。 由于担心过度简化此情况，这意味着对数据的任何更改都会反映在运行上述线程的所有内核的不同缓存级别（L1、L2、L3）的所有正在运行的线程中，以及共享内存更新。 在写入操作期间，性能可能会降低，而在指令处理可以继续之前，所有不同的内存位置都保持一致。
CPU 速度与多核注意事项
一般经验法则是，更快的逻辑处理器缩短了处理系列指令所需的时间，而更多的逻辑处理器意味着可以同时运行更多的任务。 这些经验法则随着方案本身变得更加复杂而分崩离析，需要考虑从共享内存获取数据、等待数据级并行度以及管理多个线程的开销。 这也是多核系统不是线性可伸缩性的原因。
对于这些注意事项，请思考以下类比：假设一条高速公路，每辆汽车是一个线程，每条车道是一个核心，速度限制是时钟速度。
- 如果高速公路上只有一辆车，有两个车道还是 12 个车道并不重要。 汽车将在限速允许的情况下尽可能快地行驶。
- 假设线程所需的数据无法立即可用。 打个比方，一段路段被关闭。 如果高速公路上只有一辆车，那么在重新打开车道（从内存中获取数据）之前，限速是多少并不重要。
- 随着汽车数量的增加，管理汽车数量的开销也随之增加。 比较驾驶体验和道路几乎空无一人（例如深夜）和交通繁忙（例如下午三时左右，但不是高峰时段）时所需的注意程度。 此外，请考虑在双车道高速公路上行驶时（在这种情况下，只有另一条车道关心驾驶员在做什么）和六车道高速公路（在这种情况下，必须关心许多司机在做什么）上行驶时需要注意的量。
注意
下一节扩展了有关高峰时段场景的类比：响应时间/系统繁忙如何影响性能。
因此，有关更多或更快的处理器的具体信息非常容易受到应用程序行为影响，对于 AD DS 而言，这特定于环境，甚至会因环境中的服务器而异。 这就是为什么本文前面的参考内容不会在过于精确方面投入大量精力，并且计算中包含了安全边际。 在做出预算驱动的购买决策时，建议先将处理器利用率优化 40%（或环境所需的任何数目），然后再考虑购买更快的处理器。 在更多处理器之间增加同步，会抵消线性进展中多处理器的真正好处（2 倍处理器数量无法提供 2 倍的可用额外计算能力）。
注意
此概念与阿姆达尔定律和古斯塔夫松定律有关。
响应时间/系统繁忙如何影响性能
排队理论是对排队（队列）的数学研究。 在队列理论中，“利用法则”由以下等式表示：
U k = B ÷ T
其中 U k 是利用率百分比，B 是繁忙时间，T 是观察系统的总时间。 转换为 Windows 上下文时，这意味着处于“正在运行”状态的 100 纳秒 (ns) 间隔线程数除以给定时间间隔内可用的 100 ns 间隔数。 这是用于计算处理器效用百分比的公式（请参阅处理器对象和 PERF_100NSEC_TIMER_INV）。
队列理论还提供了公式：N = U k ÷ (1 – U k)，用于根据利用率估计等待项的数量，（N 是队列的长度）。 根据所有利用率间隔绘制的图表，可估计在给定 CPU 负载下队列到达处理器所需的时间。
据观察，在 CPU 负载为 50% 后，平均而言，队列中始终有一个其他项处于等待，在 CPU 利用率约为 70% 后，会明显快速增加。
回到本节前面使用的驾驶类比：
- 假设，“下午三时”的繁忙时间将下降到 40% 至 70% 的范围。 交通量足够大，因此选择车道的能力不受重大限制，且很有可能其他司机也在路上，但不需要努力“找到”与道路上其他汽车的安全距离。
- 人们会注意到，随着交通接近高峰时间，道路系统将要接近 100% 的容量。 改变车道可能会变得非常具有挑战性，因为汽车离得太近了，这样做必须更加谨慎。
这就是为什么保守估计容量的长期平均值为40%，以便为负载的异常峰值留出余量，无论上述峰值是暂时性的（例如运行几分钟的编码不佳的查询）或是典型负载下的异常突发（长周末后的第一天早晨）。
上述认为 % Processor Time 计算与利用法则相同，是一种简化，方便一般读者使用。 对于数学上严格的情况：
- 转换 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 数量，与其说是提供商业价值，不如说是一种学术练习。
百分之四十不是严格要求，而是一个合理的开始。 Active Directory 的使用者都需要不同级别的响应能力。 在某些情况下，环境会以 80% 或 90% 的利用率作为持续平均值运行，因为访问处理器的等待时间增加不会明显影响客户端性能。 需要重申的是，系统中的许多区域比系统中的逻辑处理器慢得多，包括访问 RAM、访问磁盘以及通过网络传输响应。 所有项都需要同时进行优化。 示例：
- 添加更多处理器到运行 90% 的磁盘限制的系统中，可能不会显著提高性能。 对系统进行更深入的分析，可能会发现，有许多线程甚至没有进入处理器，因为它们正在等待 I/O 完成。
- 解决磁盘限制问题可以防止以前在等待状态中花费大量时间的线程等待 I/O，从而增加对 CPU 时间的争用，这意味着上一示例中的 90% 利用率将变为 100%（因为不能更高）。 这两个组件需要同时进行优化。
注意
对于具有“Turbo”模式的系统，Processor Information(*)\% Processor Utility 可能超过 100%。 在这种情况下，CPU 会短暂超过额定处理器速度。 有关更详细的见解，请参阅 CPU 制造商的文档和计数器说明。
讨论整个系统利用率注意事项，还会涉及到将会话域控制器作为虚拟化来宾。 响应时间/系统繁忙如何影响性能，适用于虚拟化方案中的主机和来宾。 这就是为什么在只有一个来宾的主机中，域控制器（通常是任何系统）的性能与在物理硬件上的性能大致相同。 如前所述，向主机添加其他来宾会增加基础主机的利用率，从而增加访问处理器的等待时间。 简言之，需要在主机和来宾级别管理逻辑处理器利用率。
扩展前面的类比，高速公路仍然为物理硬件，来宾 VM 是公共汽车（将乘客直接带到他们想要的目的地的特快巴士）。 设想以下四种场景：
- 在非高峰时间，一名乘客登上了一辆几乎空载的公共汽车，并且公共汽车在几乎空无一人的道路上行驶。 没有任何交通状况，乘客可以像自驾一样快速到达目的地，十分轻松。 乘客的乘车时间仍受限速限制。
- 非高峰时间，所以公共汽车几乎空载，但路上的大部分车道都关闭了，所以高速公路仍然拥堵。 在繁忙的道路上，乘客乘坐的公共汽车几乎空无一人。 虽然乘客在公共汽车上没有遇到竞争，但总行程时间仍然由外面的交通决定。
- 在高峰时间，高速公路和公共汽车上都很拥挤。 不仅行程需要更长的时间，而且上下车也是一场噩梦，因为人挤人，而高速公路的状况也不是很好。 增加更多公共汽车（为来宾添加逻辑处理器）不会使运行变得更顺畅或花费更少的时间。
- 最后一个场景，也许类比有点夸张，公共汽车满载，但道路并不繁忙。 虽然乘客仍然难以上下车，但公共汽车上路后，行程就会变得更有效率。 这是增加更多公共汽车（为来宾添加逻辑处理器）能够提高来宾性能的唯一场景。
由此可以相对容易推断出，道路利用率在 0% 到 100% 之间和公交汽车利用率在 0% 到 100% 之间存在影响程度各异的不同场景。
出于与上述排队数量相同的原因，将上述 40% CPU 的主体作为主机和来宾的合理目标是一个合理的开始。
附录 B：不同处理器速度的注意事项，以及处理器电源管理对处理器速度的影响
在处理器选择一节中，假设处理器在收集数据的整个过程中以 100% 的时钟速度运行，并且更换系统将具有相同的速度处理器。 尽管这两个假设实际上都是错误的，尤其是自 Windows Server 2008 R2 及更高版本以来，默认电源计划为“平衡”，但这种方法仍然有效，因为它是一种保守的方法。 虽然潜在的错误率可能会增加，但安全边际会随着处理器速度的增加而增加。
- 例如，在需要 11.25 个 CPU 的情况下，如果处理器在收集数据时以半速运行，则更准确的估计可能是 5.125 ÷ 2。
- 将时钟速度加倍不能保证给定时间段内发生的处理量增加一倍。 这是因为处理器等待 RAM 或其他系统组件所花费的时间可能保持不变。 最终效果是，更快的处理器在等待获取数据时可能有更高的空闲时间百分比。 同样，建议坚持使用分母的最小公倍数，保持保守，并避免尝试通过假设处理器速度之间的线性比较来计算潜在的错误准确度级别。
或者，如果替换硬件的处理器速度低于当前硬件，则可以安全地按比例增加对所需处理器的估计量。 例如，计算出需要 10 个处理器来维持站点负载，当前处理器以 3.3 Ghz 运行，而替换处理器将以 2.6 Ghz 运行，则速度降低 21%。 在这种情况下，建议使用的数量为 12 个处理器。
也就是说，这种差异不会更改容量管理处理器利用率目标。 由于处理器时钟速度将根据所需的负载动态调整，因此，在较高负载下运行系统将产生 CPU 在更高的时钟速度状态下花费更多时间的情况，最终目标是在峰值时以 100% 时钟速度状态达到 40% 的利用率。 如果低于此情况，则会节省电量，因为 CPU 速度将在非高峰方案受到限制。
注意
一种选择是，在收集数据时关闭处理器的电源管理（将电源计划设置为“高性能”）。 这样可以更准确地表示目标服务器上的 CPU 消耗量。
为了调整不同处理器的估计值，排除上面概述的其他系统瓶颈，过去可以安全地假设处理器速度加倍会使可以执行的处理量增加一倍。 如今，处理器的内部体系结构在处理器之间差异很大，因此测量使用不同处理器的效果的更安全方式是利用标准性能评估公司的 SPECint_rate2006 基准。
查找正在使用和计划使用的处理器的 SPECint_rate2006 分数。
- 在标准性能评估公司的网站上，选择“Results”，突出显示“CPU2006”，然后选择“Search all SPECint_rate2006 results”。
- 在“Simple Request”下，输入目标处理器的搜索条件，例如“Processor Matches E5-2630 (baselinetarget)”和“Processor Matches E5-2650 (baseline)”。
- 查找要使用的服务器和处理器配置（如果没有完全匹配项，则查找接近的配置），并记下“Result”和“# Cores”列中的值。
若要确定修饰符，请使用以下公式：
（（“每个核心得分值的目标平台”）×（“每个核心 MHz 的基线平台”））÷（（“每个核心得分值的基线”）×（“每个核心 MHz 的目标平台”））
请使用上面的示例：
(35.83 × 2000) ÷ (33.75 × 2300) = 0.92
将估计的处理器数乘以修饰符。 在上述情况下，从 E5-2650 处理器到 E5-2630 处理器乘以计算的 11.25 CPU × 0.92 = 需要 10.35 个处理器。
附录 C：与存储交互的操作系统的基础知识
响应时间/系统繁忙如何影响性能中概述的队列理论概念也适用于存储。 若要应用这些概念，必须熟悉操作系统处理 I/O 的方式。 在 Microsoft Windows 操作系统中，为每个物理磁盘创建一个用于保存 I/O 请求的队列。 但是，需要对物理磁盘进行说明。 阵列控制器和 SAN 将主轴集合作为单个物理磁盘呈现给操作系统。 此外，阵列控制器和 SAN 可以将多个磁盘聚合为一个阵列集，然后将此阵列集拆分为多个“分区”，作为多个物理磁盘提供给操作系统（见图）。
在此图中，两个主轴被镜像并拆分为数据存储的逻辑区域（Data 1 和 Data 2）。 操作系统将这些逻辑区域视为单独的物理磁盘。
尽管这非常令人困惑，但本附录中使用以下术语来标识不同的实体：
- 主轴 – 物理安装在服务器中的设备。
- 阵列 - 由控制器聚合的主轴集合。
- 阵列分区 - 聚合阵列的分区
- LUN - 引用 SAN 时使用的阵列
- 磁盘 – 操作系统将其视为单个物理磁盘。
- 分区 – 操作系统识别为物理磁盘的逻辑分区。
操作系统体系结构注意事项
操作系统为观察的每个磁盘创建一个先进/先出（FIFO）I/O 队列；此磁盘可能表示一个主轴、一个阵列或一个阵列分区。 从操作系统的角度来看，在处理 I/O 时，活动队列越多越好。 由于 FIFO 队列是序列化的，这意味着颁发给存储子系统的所有 I/O 都必须按照请求到达的顺序进行处理。 通过将操作系统观察到的每个磁盘与主轴/阵列相关联，操作系统现在为每个唯一的磁盘集维护一个 I/O 队列，从而消除了磁盘之间对稀缺 I/O 资源的争用，并将 I/O 请求隔离到单个磁盘。 例外情况是 Windows Server 2008 引入了 I/O 优先顺序的概念，设计为使用“低”优先级的应用程序会脱离此正常顺序，并被置于次要地位。 未专门编码以利用“低”优先级的应用程序默认为“正常”。
简单存储子系统简介
从一个简单的示例（计算机中的单个硬盘驱动器）开始，逐个组件进行分析。 将其分解为主要存储子系统组件后，系统包括：
- 1 – 10,000 RPM Ultra Fast SCSI HD（超快 SCSI 传输速度为 20 MB/s）
- 1 – SCSI 总线（电缆）
- 1 – Ultra Fast SCSI 适配器
- 1 – 32 位 33 MHz PCI 总线
识别组件后，可以计算可以传输系统的数据量或可以处理多少 I/O。 请注意，I/O 量和可传输系统的数据量是相关的，但并不相同。 此相关性取决于磁盘 I/O 是随机的还是顺序的，以及块大小。 （所有数据都以块的形式写入磁盘，但不同的应用程序使用不同的块大小。）逐个组件：
硬盘驱动器 – 平均 10,000 RPM 硬盘驱动器的寻道时间为 7 毫秒 (ms)，访问时间为 3 ms。 寻道时间是读/写磁头移动到盘片上某个位置所需的平均时间。 访问时间是磁头位于正确位置后读取数据或将数据写入磁盘所需的平均时间。 因此，在 10,000 RPM HD 上读取唯一数据块的平均时间构成了每个数据块大约 10 毫秒（0.010 秒）的总寻道和访问时间。
如果每次磁盘访问都需要磁头移动到磁盘上的新位置，则读/写操作称为“随机”。 因此，如果所有 I/O 都是随机的，则 10,000 RPM HD 每秒可以处理大约 100 个 I/O（IOPS）（公式为每秒 1000 毫秒除以每个 I/O 10 毫秒，或 1000/10 = 100 IOPS）。
或者，如果所有 I/O 都来自 HD 上的相邻扇区，这称为顺序 I/O。 顺序 I/O 没有寻道时间，因为一旦第一个 I/O 完成，读/写磁头位于 HD 上存储下一个数据块的开始位置。 因此，一个 10,000 RPM HD 每秒可以处理大约 333 个 I/O（每秒 1000 毫秒除以每个 I/O 3 毫秒）。
注意
此示例不反映磁盘缓存，其中通常保留一个柱面的数据。 在这种情况下，第一个 I/O 需要 10 毫秒，磁盘读取整个柱面。 所有其他顺序 I/O 从缓存中填充。 因此，磁盘内缓存可以提高顺序 I/O 性能。
到目前为止，硬盘驱动器的传输速率无关紧要。 无论硬盘驱动器是 20 MB/s Ultra Wide 还是 Ultra3 160 MB/s，10,000 RPM HD 可以处理的实际 IOPS 量都是大约 100 个随机或约 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 毫秒寻道、4 毫秒访问 10,000 RPM 7 毫秒寻道、3 毫秒访问 15,000 RPM 4 毫秒寻道、2 毫秒访问 随机 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 底板（总线） – 理解“底板（总线）”（在此方案中为带状电缆）对存储子系统的吞吐量的影响，其取决于对块大小的了解。 实质上的问题是，如果 I/O 在 8 KB 块中，总线可以处理多少 I/O？ 在此方案中，SCSI 总线为 20 MB/s 或 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 MB/秒 10,000 2,500 40 MB/秒 20,000 5,000 128 MB/s 65,536 16,384 320 MB/s 160,000 40,000 从此图表中可以确定，在演示的方案中，无论使用什么，总线都不会成为瓶颈，因为最大主轴为 100 I/O，远低于上述任何阈值。
注意
这假定 SCSI 总线效率为 100%。
SCSI 适配器 – 若要确定其可以处理的 I/O 量，需要检查制造商的规格。 将 I/O 请求定向到适当的设备需要某种类型的处理，因此可以处理的 I/O 量取决于 SCSI 适配器（或阵列控制器）处理器。
在此示例中，假设可以处理 1,000 个 I/O。
PCI 总线 – 这是一个经常被忽视的组件。 在此示例中，这不会是瓶颈；但是，随着系统纵向扩展，它可能会成为瓶颈。 作为参考，在 33Mhz 下运行的 32 位 PCI 总线理论上可以传输 133 MB/s 的数据。 下面是公式：
32 位÷ 8 位/字节× 33 MHz = 133 MB/s。
请注意，这是理论限制；实际情况中，只能达到最大值的约 50%，但在某些突发场景中，可以在短时间内实现 75% 的效率。
66-MHz 64 位 PCI 总线可以支持理论最大值（64 位 ÷ 8 位每字节 × 66 Mhz）= 528 MB/秒。此外，其他设备（如网络适配器和第二个 SCSI 控制器等）将减少可用带宽，因为共享带宽且设备争用有限的资源。
在分析此存储子系统的组件后，主轴是可以请求的 I/O 量（即可以通过系统传递的数据量）的限制因素。 具体而言，在 AD DS 方案中每秒 100 个随机 I/O（以 8 KB 为增量），访问 Jet 数据库时每秒总共 800 KB。 或者，专门分配给日志文件的主轴的最大吞吐量将受到以下限制：每秒 300 个顺序 I/O（以 8 KB 为增量），总共为每秒 2400 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 MB/s。 | 添加 7 个磁盘（总计 = 8） I/O 是随机的 32 KB 块大小 10,000 RPM HD |
总共 800 个 I/O。 25,600 KB/s (25 MB/s) 可以读/写到磁盘。 总线仅支持 20 MB/s |
|||
| 升级总线并添加更多磁盘后，磁盘仍然是瓶颈。 | 添加 13 个磁盘（总计 = 14） 添加具有 14 个磁盘的第二个 SCSI 适配器 I/O 是随机的 4 KB 块大小 10,000 RPM HD 升级到 320 MB/s 的 SCSI 总线 |
2800 个 I/O 11,200 KB/s (10.9 MB/s) |
|||
| 将 I/O 更改为顺序后，磁盘仍然是瓶颈。 | 添加 13 个磁盘（总计 = 14） 添加具有 14 个磁盘的第二个 SCSI 适配器 I/O 是顺序的 4 KB 块大小 10,000 RPM HD 升级到 320 MB/s 的 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 MB/s 的 SCSI 总线 |
14,000 个 I/O 56,000 KB/s (54.7 MB/s) |
|||
| 将块大小增加到 32 KB 后，PCI 总线将成为瓶颈。 | 添加 13 个磁盘（总计 = 14） 添加具有 14 个磁盘的第二个 SCSI 适配器 I/O 是顺序的 32 KB 块大小 15,000 RPM HD 升级到 320 MB/s 的 SCSI 总线 |
14,000 个 I/O 448,000 KB/s (437 MB/s) 是主轴的读/写限制。 PCI 总线理论上支持最高 133 MB/s（效率最高为 75%）。 |
RAID 简介
引入阵列控制器时，存储子系统的性质不会发生显著变化；它只是替换计算中的 SCSI 适配器。 更改的是使用各种阵列级别（如 RAID 0、RAID 1 或 RAID 5）时，将数据读取和写入磁盘的成本。
在 RAID 0 中，数据在 RAID 磁盘阵列中的所有磁盘上条带化。 这意味着，在读取或写入操作期间，会从每个磁盘拉取或推送部分数据，从而增加在同一时间段内传输系统的数据量。 因此，每个主轴（假设 10,000 RPM 驱动器）每秒可以执行 100 个 I/O 操作。 可支持的 I/O 总量是 N 个主轴乘以每个主轴每秒 100 IOPS（每秒产生 100*N 个 I/O）。
在 RAID 1 中，数据在一对主轴上进行镜像（复制）以实现冗余。 因此，在执行读取 I/O 操作时，可以从集合中的两个主轴读取数据。 这使两个磁盘的 I/O 容量在读取操作期间有效可用。 需要注意的是，写入操作无法获得 RAID 1 的性能优势。 这是因为，需要将相同的数据写入这两个驱动器以实现冗余。 虽然这不会花费更多时间，因为数据同时写入两个主轴，但由于两个主轴都被数据复制占用，一个写入 I/O 操作本质上会阻止两个读取操作。 因此，每次写入 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+ 0，在读取和写入成本方面与 RAID 1 完全相同。 但是，I/O 现在在每个镜像集上条带化。 如果
每个主轴的最大 IOPS × 2 主轴 × [(%Reads + %Writes) ÷ (%Reads + 2 × %Writes)] = 总 I/O
在 RAID 1 集中，当 RAID 1 集的多重性（N）条带化时，每个 RAID 1 集可处理的 I/O 总数变为 N × I/O：
N × {每个主轴的最大 IOPS × 2 主轴 × [(%Reads + %Writes) ÷ (%Reads + 2 × %Writes)] } = 总 IOPS
在 RAID 5（有时称为 N + 1 RAID）中，数据跨 N 个主轴条带化，奇偶校验信息写入“+ 1”主轴。 但是，在 RAID 5 中执行写 I/O 比 RAID 1 或 1 + 0 昂贵得多。 每次向阵列提交写入 I/O 时，RAID 5 将执行以下操作：
- 读取旧数据
- 读取旧的奇偶校验
- 写入新数据
- 写入新的奇偶校验
由于操作系统提交给阵列控制器的每个写入 I/O 请求都需要完成四个 I/O 操作，因此提交的写入请求完成时间是单个读取 I/O 的四倍。 从操作系统的角度推导出将 I/O 请求转换为发生在主轴上的 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 容量来获得系统可用的总 I/O 吞吐量。 这是因为，如果一个控制器发生故障，则其余控制器必须处理所有连接的系统请求的整个 I/O 负载。 由于所有容量计划均针对高峰使用期，因此不应将冗余组件纳入可用资源，并且计划的峰值利用率不应超过系统的 80% 饱和度（以便适应突发或异常系统行为）。 同样，冗余 SAN 交换机、存储单元和主轴不应纳入 I/O 计算。
分析 SCSI 或光纤通道硬盘驱动器的行为时，分析行为的方法与先前描述的没有改变。 尽管每个协议都有一定的优缺点，但每个磁盘的限制因素都是硬盘驱动器的机械限制。
分析存储单元上的通道与计算 SCSI 总线上可用的资源或带宽（如 20 MB/s）除以块大小（如 8 KB）完全相同。 这与前面的简单示例的区别在于多个通道的聚合。 例如，如果有 6 个通道，每个通道支持 20 MB/s 的最大传输速率，则可用的 I/O 和数据传输总量为 100 MB/s（这是正确的，而不是 120 MB/s）。 同样，容错是此计算的重要部分，如果一整个通道丢失，系统只剩下 5 个正常运行的通道。 因此，为了确保在发生故障时继续满足性能预期，所有存储通道的总吞吐量不应超过 100 MB/s（这假定负载和容错均匀分布在所有通道）。 将其转换为 I/O 配置文件取决于应用程序的行为。 对于 Active Directory Jet I/O，这相当于每秒 12,500 IOPS（100 MB/s ÷每个 I/O 8 KB）。
接下来，需要获取控制器模块的制造商规格，以便理解每个模块可以支持的吞吐量。 在此示例中，SAN 有两个控制器模块，每个模块支持 7,500 个 I/O。 如果不需要冗余，系统的总吞吐量可能为 15,000 IOPS。 在计算发生故障时的最大吞吐量时，限制为一个控制器的吞吐量，即 7,500 IOPS。 此阈值远低于所有存储通道可以支持的最大 12,500 IOPS（假设 4 KB 块大小），因此它目前是分析中的瓶颈。 出于计划目的，计划的所需最大 I/O 将为 10,400 I/O。
当数据离开控制器模块时，它会通过速率为 1 GB/s（或每秒 1 吉比特）的光纤通道连接。 要将此与其他指标相关联，将 1 GB/s 转换为 128 MB/s（1 GB/s ÷ 8 位/字节）。 由于这超过了存储单元中所有通道的总带宽（100 MB/s），因此这不会给系统造成瓶颈。 此外，由于这只是两个通道中的一个（用于冗余的附加 1 GB/s 光纤通道连接），如果一个连接失败，则剩余的连接仍有足够的容量来处理所需的所有数据传输。
在路由到服务器时，数据几乎总是通过 SAN 交换机。 由于 SAN 交换机必须处理传入的 I/O 请求并将其转发到相应的端口，因此该交换机将限制可处理的 I/O 量，但需要制造商规范来确定该限制。 例如，如果有两个交换机，并且每个交换机可以处理 10,000 IOPS，则总吞吐量将为 20,000 IOPS。 同样，容错是一个问题，如果一个交换机发生故障，系统的总吞吐量将为 10,000 IOPS。 由于正常操作的利用率不应超过 80%，因此应以使用不超过 8000 个 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 长时间饱和时，缓存最终会填满。 若要清空缓存，需要分配足够的突发间隔时间或额外的主轴，以提供足够的 I/O 来缓存刷新。
较大的缓存只能缓冲更多数据。 这意味着其可以适应较长的饱和期。
在正常运行的存储子系统中，操作系统写入性能将提高，因为只需将数据写入缓存。 一旦基础媒体的 I/O 饱和，缓存将填满，写入性能将恢复到磁盘速度。
缓存读取 I/O 时，缓存最有利的方案是将数据按顺序存储在磁盘上，并且缓存可以预先读取（假设下一个扇区包含下一个请求的数据）。
如果读取 I/O 是随机的，则驱动器控制器上的缓存不太可能提升可从磁盘读取的数据量。 如果基于操作系统或应用程序的缓存大小大于基于硬件的缓存大小，则不存在提升。
对于 Active Directory，缓存仅受 RAM 量的限制。
SSD 注意事项
SSD 与基于主轴的硬盘完全不同。 然而，两个关键条件仍然存在：“它可以处理多少 IOPS？” 和“这些 IOPS 的延迟是多少？” 与基于主轴的硬盘相比，SSD 可以处理更高的 I/O 量，并且延迟更低。 在撰写本文时，总体而言，SSD 在每 GB 的成本方面仍然很昂贵，但在每 I/O 的成本方面却非常便宜，从存储性能的角度来看是值得考虑的。
注意事项：
- IOPS 和延迟都高度受制造商设计的影响，并且在某些情况下已观察到其性能比基于主轴的技术差。 简言之，更重要的是查看和验证每个驱动器的制造商规格，并且不要假设一般性。
- IOPS 类型可能是非常不同的数字，具体取决于它是读取还是写入。 通常，AD DS 服务主要基于读取，与其他一些应用程序方案相比，其影响较小。
- “写入耐用性”—这个概念指 SSD 单元最终会磨损。各家制造商以不同的方式应对这一挑战。 至少对于数据库驱动器而言，主要读取 I/O 配置文件且数据不是高度易失性的数据库驱动器而言，允许淡化此问题的重要性。
总结
考虑存储的一种方法是想象家庭管道。 想象存储数据媒体的 IOPS 是家中的主排水管。 如果堵塞（例如管道底部）或受限（如果被损毁或太小），或者如果使用太多的水（客人太多），水会流回家中的每个水槽。 这与共享环境非常相似，其中一个或多个系统利用具有相同基础媒体的 SAN/NAS/iSCSI 上的共享存储。 可以采用不同的方法来解决不同的方案：
- 损毁或过小的排水管需要完全更换和修复。 这类似于在整个基础结构中添加新硬件或使用共享存储重新分发系统。
- “堵塞”的管道通常意味着识别并消除一个或多个违规问题。 在存储方案中，可能是存储或系统级备份、跨所有服务器同步的防病毒扫描，以及高峰期运行同步碎片整理软件。
在任何管道设计中，多个排水管流入主排水管。 如果这些排水管或连接点中的任何一个堵塞，则只有该连接点后面的东西会停止。 在存储方案中，可能是交换机过载（SAN/NAS/iSCSI 方案）、驱动程序兼容性问题（错误的驱动程序/HBA 固件/storport.sys 组合）或备份/防病毒/碎片整理。 若要确定存储“管道”是否足够大，需要度量 IOPS 和 I/O 大小。 在每个连接处将它们加在一起，以确保足够的“管道直径”。
附录 D - 关于存储故障排除的讨论 - 根据数据库大小添加 RAM 的环境不是可行的选项
理解为何存在这些建议，有助于适应存储技术的变化。 存在这些建议，有两个原因。 第一个是 IO 隔离，以便操作系统主轴上的性能问题（即分页）不会影响数据库和 I/O 配置文件的性能。 第二种情况是，AD DS（和大多数数据库）的日志文件本质上是顺序的，基于主轴的硬盘驱动器和缓存在与顺序 I/O 一起使用时，会导致操作系统的 I/O 更加随机，这是因为它提供了重要的与 AD DS 数据库驱动器的模式和几乎完全随机的 I/O 模式相比的性能优势。 通过将顺序 I/O 隔离到单独的物理驱动器，可以增加吞吐量。 当今存储选项面临的挑战是，这些建议背后的基本假设不再正确。 在许多虚拟化存储方案（如 iSCSI、SAN、NAS 和虚拟磁盘映像文件）中，基础存储媒体在多个主机之间共享，从而完全否定了“IO 隔离”和“顺序 I/O 优化”两个方面。 事实上，这些方案增加了额外的复杂性，因为访问共享媒体的其他主机可能会降低对域控制器的响应能力。
在计划存储性能时，需要考虑三个类别：冷缓存状态、预热缓存状态和备份/还原。 当域控制器最初重新启动或 Active Directory 服务重启且 RAM 中没有 Active Directory 数据时，会出现冷缓存状态。 热缓存状态是域控制器处于稳定状态且数据库被缓存的状态。 请务必注意，因为它们将驱动截然不同的性能配置文件，并且，当缓存为冷时，以足够的 RAM 来缓存整个数据库对于性能无济于事。 可以通过以下类比来考虑这两种方案的性能设计，预热冷缓存是一次“冲刺”，而运行具有热缓存的服务器是一场“马拉松”。
对于冷缓存和热缓存方案，问题变为存储将数据从磁盘移动到内存的速度。 预热缓存的情况是，随着时间的推移，随着更多查询重用数据、缓存命中率增加以及需要转到磁盘的频率降低，性能会提高。 因此，减少了移动到磁盘对性能的负面影响。 在等待缓存预热并增长到系统最大允许大小时，任何性能降级都是暂时的。 对话可以简化为从磁盘中获取数据的速度，并且是 Active Directory 可用 IOPS 的简单度量，其受基础存储可用的 IOPS 的影响。 从计划的角度来看，由于预热缓存和备份/还原方案发生异常，通常发生在非工作时间，并且受 DC 负载的影响，因此除了将这些活动安排在非高峰时段外，不存在一般建议。
在大多数情况下，AD DS 主要是读取 IO，比例通常为 90% 读取/10% 写入。 读取 I/O 通常是用户体验的瓶颈，而写入 IO 会导致写入性能下降。 由于 NTDS.dit 的 I/O 主要是随机的，缓存往往为读取 IO 提供最小的好处，因此为读取 I/O 配置文件正确配置存储更为重要。
对于正常运行情况，存储计划目标是最小化从磁盘返回 AD DS 请求的等待时间。 这实质上意味着未完成和挂起的 I/O 数小于或等于磁盘的路径数。 可通过多种方式进行度量。 在性能监视方案中，一般建议是 LogicalDisk (<NTDS 数据库驱动器>) \Avg Disk sec/Read 小于 20 毫秒。 所需的操作阈值必须低得多，最好尽可能接近存储速度，范围为 2 - 6 毫秒（0.002 - 0.006 秒），具体取决于存储的类型。
示例：
分析图表：
- 左侧绿色椭圆 – 在 10 毫秒时，延迟保持一致。 负载从 800 IOPS 增加到 2400 IOPS。 这是基础存储处理 I/O 请求的速度的绝对限值。 这受存储解决方案细节的约束。
- 右侧的紫红色椭圆 - 虽然延迟继续增加，但从绿色圆圈的末尾到数据收集的末尾，吞吐量保持不变。 这表明，当请求量超过基础存储的物理限制时，请求在队列中等待发送到存储子系统的时间就越长。
应用以下知识：
- 对查询大型组成员身份的用户的影响 - 假设这需要从磁盘读取 1 MB 的数据，可按如下所示进行 I/O 量和所需时间评估：
- Active Directory 数据库页的大小为 8 KB。
- 至少需要从磁盘中读取 128 页。
- 假设没有缓存任何内容，则下限（10 毫秒）至少需要 1.28 秒才能从磁盘读取数据以将数据返回到客户端。 在 20 毫秒时，存储吞吐量早已达到最大值，也是建议的最大值，从磁盘检索数据以将数据返回给最终用户需要 2.5 秒。
- 缓存的预热速率 – 假设客户端负载将最大化此存储示例中的吞吐量，缓存将以 2400 IOPS × 每个 IO 8 KB 的速率预热。 或者，以大约 20 MB/s 的速度，大约每 53 秒将 1 GB 的数据库加载到 RAM 中。
注意
当组件主动读取或写入磁盘时（例如备份系统或 AD DS 运行垃圾回收时），在短时间内观察到延迟增加是正常的。 在计算的基础上，应提供额外的余量，以适应这些定期事件。 目标是提供足够的吞吐量来适应这些方案，而不会影响正常功能。
可以看到，根据存储设计，缓存的预热速度存在物理限制。 预热缓存的是传入的客户端请求，其速率最高可达基础存储可以提供的速率。 运行脚本以在高峰时段“预热”缓存，将会对实际客户端请求驱动的负载产生竞争。 这会对交付客户端首先需要的数据产生不利影响，因为根据设计，这会对稀缺磁盘资源产生竞争，因为人为尝试预热缓存将加载与 DC 进行联系的客户端不相关的数据。