在 SharePoint Server 中规划企业搜索体系结构
适用于：
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
设置企业搜索体系结构之前，需要仔细规划很多事项。 我们将逐步帮助你规划小型、中型、大型或超大型企业搜索体系结构。
你是否熟悉 SharePoint Server 中搜索系统的组件及其交互方式？ 在开始之前，请阅读 SharePoint Server 中的搜索体系结构概述和 SharePoint Server 2016 搜索体系结构（或 SharePoint Server 2013 搜索体系结构），以便熟悉搜索体系结构、搜索组件、搜索数据库和搜索拓扑。 规划搜索体系结构时，以下是有关注意事项的一些建议：
第 1 步：我有多少内容？
您的搜索索引拥有的内容量影响您需要托管服务器场的资源。 算出您规划为可搜索的大约项目数。 以下是一些项目示例：文档、网页、SharePoint 列表项和图像。 请记住，SharePoint 列表中的每个条目都可列为一项。
当您确立好一个数字后，乘以您认为该内容在未来 12 个月内的预期增长。
例如，如果你从 12，000 个索引项开始，并且预计该内容的数量在未来 12 个月内会翻倍。 应计划 36，000 个可搜索项。
步骤 2：内容量的大小搜索体系结构是多少？
评估搜索体系结构的构建是大是小并不容易。 搜索体系结构的大小取决于您的内容量、爬网率、查询吞吐量和您所需的高可用性级别。 建议使用示例搜索体系结构作为计划自己的服务器场的基础。 您所选择的示例搜索体系结构取决于需要搜索的内容量：
| SharePoint 2016) (内容量 | 示例搜索体系结构 | SharePoint 2013) (内容量 |
|---|---|---|
| 0-2000 万个项 | 小型搜索服务器场 | 0 - 1000 万个项 |
| 0-8000 万个项 | 中型搜索服务器场 | 0 - 4000 万个项 |
| 0-2 亿个项 | 大型搜索服务器场 | 0 - 1 亿个项 |
| 0-5 亿个项 | 特大型搜索服务器场 | 不支持 |
尽管这些示例搜索体系结构使用虚拟机，但可以根据搜索体系结构的整体 SharePoint Server 解决方案的策略同时使用物理服务器和虚拟机。
小型搜索服务器场
我们已预计此搜索体系结构每秒可以爬网 50 个文档，且每秒服务大约 10 个查询。 如果 SharePoint Server 2016 场中最多有 2000 万个项目，则小型搜索场可能是最适合你的服务器场。 对于每秒 50 个文档的爬网率，首次完全爬网中，需要搜索 110 个小时来爬网 2000 万个项目。
中型搜索服务器场
我们已预计此搜索体系结构每秒可以爬网 100 个文档，且每秒服务大约 10 个查询。 如果 SharePoint Server 2016 场中有 2000 万到 8000 万个项目，中等搜索场可能是最适合你的服务器场。 对于每秒 200 个文档的爬网率，首次完全爬网中，需要搜索 280 个小时来爬网 8000 万个项目。
大型搜索服务器场
我们已预计此搜索体系结构每秒可以爬网 200 个文档，且每秒服务大约 10 个查询。 如果 SharePoint Server 2016 场中有 8000 万到 2 亿个项目，则大型搜索场可能是最适合你的服务器场。 对于每秒 200 个文档的爬网率，首次完全爬网中，需要搜索 280 个小时来爬网 2 亿 万个项目。
特大型搜索服务器场
Microsoft 测试了此搜索体系结构并测试了其每秒可以爬网 300-500 个文档，且每秒服务大约 10 个查询。 只有 SharePoint Server 2016 支持此大小的搜索体系结构。 如果拥有多达 5 亿个项目，则适合从类似于特大型搜索服务器场的服务器场开始。 对于每秒 500 个文档的爬网率，首次完全爬网中，需要搜索大约 300 个小时来爬网 5 亿个项目。
创建这种大小的搜索服务器场需要仔细规划和调整服务器场才能获得所需的性能。 你会发现寻求专家指导会有所帮助。 规划如何备份和还原此大小的搜索场，以及如何在数据中心发生重大中断时恢复服务器场也很重要。 建议对备份、还原和恢复进行练习。
第 3 步：我应了解哪些硬件要求？
现在，您已确定了您的内容量并选择了示例搜索体系结构，下一步是规划您所需的硬件，如本节中所述：
选择以物理方式还是虚拟方式运行服务器
如果使用我们估计的某个体系结构，则会在虚拟机上运行搜索体系结构。 另请注意，尽管虚拟环境更容易管理，但其性能级别有时可能会稍低于物理环境。 物理服务器在同一服务器上可托管的搜索组件比虚拟服务器要多。 您可以在 Overview of farm virtualization and architectures for SharePoint 2013中找到有用指导。
还可以在物理服务器上运行搜索体系结构。 在示例服务器场体系结构中，只需将搜索组件从虚拟机移动到主机服务器，并取走虚拟机。 每个物理服务器最多可以托管四个索引组件，但每种类型的其他搜索组件中只有一个。 例如，如果将中等示例搜索体系结构更改为使用物理服务器，则会发现主机 E 上有两个内容处理组件。解决方案是取走其中一个内容处理组件。 这之所以有效，是因为爬网、内容处理和分析处理取决于可用的资源量，而不是内容处理组件的数量。
选择主机服务器的硬件资源
每个搜索组件和搜索数据库需要主机服务器的最少量的硬件资源即可运行良好。 但是，您拥有的硬件资源越多，您的搜索体系结构的性能越好。 因此，硬件资源数量最好多于硬件资源的最低数量。 每个搜索组件需要的资源取决于工作负荷，这主要由爬网速率、查询速率和索引项目数决定。
例如，在 Windows Server 2008 R2 Service Pack 1 (SP1) 中托管虚拟机时，每个虚拟机使用的 CPU 内核不能超过四个。 在 Windows Server 2012 或更高版本中，您在每个虚拟机上使用八个或更多 CPU 内核。 然后您可以为每个虚拟机向外扩展更多 CPU 内核，而无需向上扩展更多虚拟机。 设置使用相同硬件资源托管相同搜索组件的服务器或虚拟机。 现在我们以索引组件为例。 当您在虚拟机上托管索引分区时，性能最差的虚拟机决定了整个搜索体系结构的性能。
一般存储
确保每个主机服务器有足够的磁盘空间用于 Windows Server 操作系统的基本安装和 SharePoint Server 程序文件。 主机服务器还需要有可用的硬盘空间进行日志记录、调试、创建内存转储等诊断、日常操作和页面归档。 通常，80 GB 的磁盘空间足以用于 Windows Server 操作系统和 SharePoint Server 程序文件。
增加每个数据库服务器的 SQL 日志存储空间。 如果没有将数据库服务器设置为经常备份数据库，SQL 日志则会占用大量存储空间。 有关如何规划 SQL 数据库的详细信息，请参阅存储和SQL Server容量规划和配置 (SharePoint Server) 。
分析报告数据库所需的最低存储量可能各不相同。 这是因为存储量取决于用户与 SharePoint Server 的交互方式。 当用户交互频率较高时，通常要存储更多事件。 检查当前搜索体系结构用于分析数据库的存储量，并至少为您重新设计的拓扑分配此存储量。
小型搜索服务器场的最低硬件资源
下表显示了每个应用程序服务器或数据库服务器需要的最低硬件资源量。
| 服务器 | 位于主机 | 存储器 | RAM | 处理器1 | 网络带宽 |
|---|---|---|---|---|---|
| 带有查询处理和索引组件的应用程序服务器。 | A、B | 500 GB2，3 | 32 GB2，3 | 1.8 GHz 8x CPU 核心2，3 | 1 Gbps |
| 带有爬网、搜索管理、分析和内容处理组件的应用程序服务器。 | A、B | 200 GB | 8 GB | 1.8 GHz 4x CPU 内核 | 1 GB |
| 带有所有搜索数据库的数据库服务器。 | C、D | 100 GB | 16 GB | 1.8 GHz 4x CPU 内核 | 1 Gbps |
1此处特指 CPU 内核数，而不是 CPU 线程数。
2使用 SharePoint Server 2013 时，所需的最小资源量为 500 GB 存储、16 GB RAM 和 4 个 CPU 核心。
3使用 SharePoint Server 2016，还可以使用 250 GB 存储、16 GB RAM 和 4 个 CPU 核心，但每个索引组件只能包含 1000 万个项目，并且搜索场仅支持与 SharePoint Server 2013 搜索场相同的内容量。
中型搜索服务器场的最低硬件资源
下表显示了每个应用程序服务器或数据库服务器需要的最低硬件资源量。
| 服务器 | 位于主机 | 存储器 | RAM | 处理器1 | 网络带宽 |
|---|---|---|---|---|---|
| 带有查询处理和索引组件的应用程序服务器。 | A、B、C、D | 500 GB2，3 | 32 GB2，3 | 1.8 GHz 8x CPU 核心2，3 | 1 Gbps |
| 带有索引组件的应用程序服务器。 | A、B、C、D | 500 GB2，3 | 32 GB2，3 | 1.8 GHz 8x CPU 核心2，3 | 1 Gbps |
| 带有分析和内容处理组件的应用程序服务器。 | E、 F | 300 GB | 8 GB | 1.8 GHz 4x CPU 内核 | 1 GB |
| 带有爬网、搜索管理和内容处理组件的应用程序服务器。 | E、 F | 100 GB | 8 GB | 1.8 GHz 4x CPU 内核 | 1 GB |
| 带有所有搜索数据库的数据库服务器。 | G、H | 400 GB | 16 GB | 1.8 GHz 4x CPU 内核 | 1 Gbps |
1此处特指 CPU 内核数，而不是 CPU 线程数。
2使用 SharePoint Server 2013 时，所需的最小资源量为 500 GB 存储、16 GB RAM 和 4 个 CPU 核心。
3使用 SharePoint Server 2016，还可以使用 250 GB 存储、16 GB RAM 和 4 个 CPU 核心，但每个索引组件只能包含 1000 万个项目，并且搜索场仅支持与 SharePoint Server 2013 搜索场相同的内容量。
大型搜索服务器场的最低硬件资源
下表显示了每个应用程序服务器或数据库服务器需要的最低硬件资源量。
| 服务器 | 位于主机 | 存储器 | RAM | 处理器1 | 网络带宽 |
|---|---|---|---|---|---|
| 带有查询处理和索引组件的应用程序服务器。 | A、B、C、D、E、G、H | 500 GB2、3 | 32 GB2、3 | 1.8 GHz 8x CPU 核心2、3 | 1 Gbps |
| 带有索引组件的应用程序服务器。 | A, B, C, D, E, F, G, H, I, J | 500 GB2、3 | 32 GB2、3 | 1.8 GHz 8x CPU 核心2、3 | 1 Gbps |
| 带有分析和内容处理组件的应用程序服务器。 | K, L, M, N | 300 GB | 8 GB | 1.8 GHz 4x CPU 内核 | 1 GB |
| 带有爬网和搜索管理组件的应用程序服务器 | K, L | 100 GB | 8 GB | 1.8 GHz 4x CPU 内核 | 1 GB |
| 带有搜索数据库的数据库服务器 | O, P, Q, R | 500 GB | 16 GB | 1.8 GHz 4x CPU 内核 | 1 Gbps |
1此处特指 CPU 内核数，而不是 CPU 线程数。
2使用 SharePoint Server 2013 时，所需的最小资源量为 500 GB 存储、16 GB RAM 和 4 个 CPU 核心。
3使用 SharePoint Server 2016，还可以使用 250 GB 存储、16 GB RAM 和 4 个 CPU 核心，但每个索引组件只能包含 1000 万个项目，并且搜索场仅支持与 SharePoint Server 2013 搜索场相同的内容量。
特大型搜索服务器场的最低硬件资源
下表显示了每个应用程序服务器或数据库服务器需要的最低硬件资源量。 只能使用 SharePoint Server 2016 生成此示例场。
| 服务器 | 位于主机 | 存储器 | RAM | 处理器1 | 网络带宽 |
|---|---|---|---|---|---|
| 带有索引组件的应用程序服务器 | A-X | 500 GB | 32 GB | 1.8 GHz 8x CPU 内核 | 1 GB |
| 带有查询处理和索引组件的应用程序服务器。 | Y、Z | 500 GB | 32 GB | 1.8 GHz 8x CPU 内核 | 1 GB |
| 带有爬网、搜索管理或内容处理组件的应用程序服务器 | AA-AF | 100 GB | 8 GB | 1.8 GHz 4x CPU 内核 | 1 GB |
| 带有分析处理组件的应用程序服务器 | AG、AH | 800 GB | 8 GB | 1.8 GHz 4x CPU 内核 | 1 GB |
| 带有搜索数据库的数据库服务器 | AI-AL | 500 GB | 16 GB | 1.8 GHz 4x CPU 内核 | 1 Gbps |
1此处特指 CPU 内核数，而不是 CPU 线程数。
规划存储性能
存储速度影响搜索性能。 请确保您的存储速度足够快，从而能够处理来自搜索组件和数据库的流量。 磁盘速度以每秒的 I/O 操作数 (IOPS) 进行测量。
对于在存储空间内分布来自搜索组件和操作系统的数据，您所决定的方式会影响搜索性能。 比较好的做法是：
在具有标准性能的三个单独存储卷或分区之间拆分 Windows Server 操作系统文件、SharePoint Server 程序文件和诊断日志。
在具有高性能的独立存储卷或分区上存储搜索组件数据。
注意
在主机上安装 SharePoint Server 时，可以为搜索组件数据设置自定义位置。 需要存储数据的主机上的任何搜索组件将数据存储在此位置。 若要稍后更改此位置，必须在该主机上重新安装 SharePoint Server。
选择存储空间
有关存储体系结构和磁盘类型的概述，请参阅存储和SQL Server容量规划和配置 (SharePoint Server) 。 托管索引或分析处理组件或搜索数据库的服务器需要能够保持低延迟的存储，同时每秒提供足够的 I/O 操作 (IOPS) 。 下表展示了每个搜索组件和数据库要求的 IOPS 数。
如果您部署诸如 SAN/NAS 的共享存储，一个搜索组件的高峰磁盘负载通常与另一个搜索组件的高峰磁盘负载一致。 若要获取共享存储的 IOPS 搜索要求量，您需要将每一个这些组件的 IOPS 要求量加起来。
所示组件 IOPS 要求
| 组件名称 | 组件详细信息 | IOPS 要求 | 独立存储卷/分区的使用 |
|---|---|---|---|
| 索引组件 | 合并索引时和处理并响应查询时使用存储。 | 64 KB 随机读取时要求 300 IOPS。 256 KB 随机写入时要求 100 IOPS。 顺序读取时要求每秒 200 MB。 顺序写入时要求每秒 200 MB。 |
是 |
| 分析组件 | 以批量处理的形式本地分析数据。 | 否 | 是 |
| 爬网组件 | 在将下载的内容发送到内容处理组件之间本地存储该内容。 存储受内容带宽的限制。 | 否 | 是 |
搜索数据库 IOPS 要求
| 数据库名称 | IOPS 要求 | I/O 子系统上的典型负载。 |
|---|---|---|
| 爬网数据库 | 中等到高 IOPS | 每秒 1 个文档 (DPS) 爬网率要求 10 IOPS。 |
| 链接数据库 | 中等 IOPS | 搜索索引中每 100 万项目要求 10 IOPS。 |
| 搜索管理数据库 | 低 IOPS | 不适用。 |
| 分析报告数据库 | 中等 IOPS | 不适用。 |
选择您的搜索体系结构如何支持高可用性
如果您对高可用性策略不熟悉，下面这篇文章将能帮助您实现入门：为 SharePoint Server 创建具有高可用性的体系结构和策略。 当您托管独立容错域上的冗余搜索组件和数据库时，您的搜索体系结构支持高可用性。 所有的示例搜索体系结构都托管独立服务器上的冗余搜索组件。
对于搜索体系结构中的每一个冗余主机服务器，您应计划安装：
冗余网络
通过独立布线或不间断电源 (UPS) 提供的冗余电源。
第 4 步：如何检查我的搜索体系结构是否运行良好？
在您将搜索体系结构部署到生产环境之前，需要检查该搜索体系结构是否运行良好。 以下是操作步骤清单：
对使用拥有充足 IOPS 的存储 I/O 子系统的索引组件进行测试。 请参阅测试存储 I/O 子系统。
将搜索体系结构到试验环境。 确保该试验环境代表了生产环境。
测试试验环境的搜索性能。 请参阅测试搜索性能
有关 SharePoint 中一般测试的概述，请参阅 SharePoint Server 2013 的性能测试。
测试存储 I/O 子系统
若要测试存储 I/O 子系统，请运行最重要的磁盘操作，然后衡量 IOPS。 可以使用 DiskSpd 工具来运行这些测试。 请参阅 DiskSpd：可靠的存储性能工具。
设置测试环境
无需设置整个搜索体系结构或安装 SharePoint Server。 只需设置可以产生存储 I/O 子系统理想工作负载的测试环境即可。
我们来设想一下本地存储的案例。 例如，如果中等搜索服务器场中的主机 A 使用本地磁盘，您需要安装两台虚拟机并同时运行两台虚拟机上的磁盘操作测试。
您需要另外设置一个共享存储。 例如，如果中等搜索服务器场中所有索引组件的工作负载及其他不相关的工作负载都共享同一个存储，那么您需要：
安装主机 A、B、C 和 D 中的八台虚拟机，并设置不相关工作负载的源。
确保您在主机 A、B、C 和 D 中所有虚拟机上运行同步磁盘操作测试的同时，不相关工作负载应用到共享的存储。
创建测试文件
使用 命令
diskspd -c256G testfile创建 256 GiBytes 测试文件。 此命令创建名为“testfile”的 256 GiBytes 大小文件。 还可以按照语法创建具有其他大小的文件：diskspd -c<size>[K|M|G|b] <filename>保存您希望测试的存储设备上的测试文件。 例如：中等服务器场中主机 A 的硬盘上。
重新启动服务器。 这将确保缓存不会导致测试结果出现偏差。
运行测试
最好测量以下内容：
中等大小的随机访问性能（请参阅以下测试一和测试二）。
大型传输的读取和写入吞吐量（请参阅以下测试三和测试四）。
下表显示了运行每个测试时应使用的 DiskSpd 命令。 所有命令都假设当前目录中存在"测试文件"。 每次测试运行 300 秒。
| 测试编号 | 范围 | 命令 |
|---|---|---|
| 1 | 64 KB 读取 [IOPS] | diskspd -t4 -b64K -o25 -r -d300 testfile |
| 2 | 256 KB 写入 [IOPS] | diskspd -t4 -b256K -o25 -r -w100 -d300 testfile |
| 3 | 100 MB 读取 [MB/秒] | diskspd -t1 -o1 -b100M -r -d300 testfile |
| 4 | 100 MB 写入 [MB/秒] | diskspd -t1 -o1 -b100M -r -w100 -d300 testfile |
本地磁盘存储的示例结果
下表中的示例结果显示了在添加测试文件之前已至少使用 50 % 磁盘子系统能力的部署。
磁盘控制器和磁盘心轴强烈影响这些结果。
如果您测试空磁盘，您将获得提升的结果，因为测试文件将处于跨所有心轴的最佳轨迹（短行程）。 这可以提高多达二倍或三倍的性能。 如果您测试优化了对未初始化存储空间或包含所有零的存储（例如，动态 VHD/VHDX 文件）的访问的硬盘，您将获得偏高的结果。 在这种情况下，请使用包含真实数据的非常大的测试文件，而不是使用 DiskSpd 命令生成综合测试文件。
| 磁盘布局 | 测试 1 | 测试 2 | 测试 3 | 测试 4 | |
| 日常操作过程中推荐的最低 IOPS | 300 | 100 | 200 | 200 | |
| Dell H710 RAID 控制器上 RAID5 中的 4x 1 TB 7200 RPM NLSAS（64kB 带区大小、64kB 块大小） | 1181 | 206 | 284 | 296 | |
| Dell H710 RAID 控制器上 RAID5 中的 8x 1TB 7200 RPM NLSAS（64kB 带区大小、64kB 块大小） | 2082 | 337 | 610 | 645 | |
| Dell H710 RAID 控制器上 RAID5 中的 16x 1TB 7200 RPM NLSAS（64kB 带区大小、64kB 块大小） | 3763 | 595 | 1173 | 1181 | |
| Dell H710 RAID 控制器上 RAID50 (2x8) 中的 16x 1TB 7200 RPM NLSAS（64kB 带区大小、64kB 块大小） | 3613 | 545 | 1139 | 1164 | |
| Dell H710 RAID 控制器上 RAID10 中的 16x 1TB 7200 RPM NLSAS（256kB 带区大小、64kB 块大小） | 4030 | 1146 | 970 | 775 | |
| Dell H710 RAID 控制器上 RAID5 中的 4x SmartStorage Optimus 800GB SSD（64kB 带区大小、64kB 块大小） | 32385 | 3781 | 1714 | 1319 | |
| Dell H710 RAID 控制器上 RAID0 中的 4x SmartStorage Optimus 800GB SSD（256kB 带区大小、64kB 块大小） | 31747 | 7149 | 1643 | 1798 |
测试搜索性能
以下是测试您搜索体系结构的操作步骤清单：
选择要运行测试的内容
选择最代表您生产内容的内容。 如果您选择仅用于测试的内容，请确保您已获得不同类型的项目，而不是您已复制多次的一个项目。 原因是因为查询处理器将花时间检测复制的项目，这将影响搜索性能，而且您的结果无法代表生产环境。
设置可爬网内容的一个或多个内容源。 请验证您具有所需的用户帐号和网络访问。
选择要测试查询性能的术语和短语
您所获取的查询结果的数量称为查全率。
若要测试查询性能，您首先需要创建一组用作查询的术语和短语。 或者，从现有安装中收集查询。 请确保该组包含具有低查全率和高查全率的术语和短语，且该术语和短语与您的环境相关。
示例
如果您搜索产品目录中的产品编号，很可能一个产品只有一个编号。 因此您可以快速地获得搜索结果。 这是低查全率。
如果您在公司 Intranet 上查询类似于"演示文稿"的常用术语，很可能会获得许多结果，而且花费更长的时间。 这是高查全率。
例如，如果您的内容与人力资源相关，则使用与此领域相关的搜索术语。
测量搜索性能
SharePoint Server 收集爬网运行状况报告和查询运行状况报告中的搜索性能度量值。 您可以在"搜索管理"下的管理中心找到这些报告。
较好的方法是首先使用综合负载测量搜索性能，然后使用一小组活动用户和活动内容进行测量。 当您使用活动用户和活动内容时，可以观察到搜索体系结构执行的方法。 如果您的内容比预期的增长更快，可能值得考虑使用下一大小的搜索体系结构。 或者，如果用户比预期更活跃，我们建议增加分析数据库的存储空间量。