通过

为 SharePoint 中的更多内容和用户重新设计企业搜索拓扑

  • 项目

适用于：yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

大部分搜索环境会随着时间而增长，包括在内容数量和用户数量方面。 有时搜索环境会增长到超出搜索体系结构的容量和性能。 解决方案是扩展搜索体系结构的拓扑：

  1. 重新设计拓扑（本文）

  2. 实现重新设计的拓扑（在 SharePoint Server 中管理搜索拓扑）

你是否熟悉 SharePoint Server 中搜索系统的组件及其交互方式？ 在开始之前，请阅读 SharePoint Server 中的搜索体系结构概述和 SharePoint Server 2016 搜索体系结构（或 SharePoint Server 2013 搜索体系结构），以便熟悉搜索体系结构、搜索组件、搜索数据库和搜索拓扑。

在本文中，我们将分步介绍如何重新设计搜索拓扑。

执行这些步骤后，您将了解：

  • 对于每种搜索组件和搜索数据库，您的拓扑需要多少。

  • 每种搜索组件要部署在哪些应用程序服务器和数据库上。

  • 每个应用程序服务器和数据库服务器需要多少硬件资源。

第 1 步：我有多少内容？

您的搜索索引中的内容量会影响托管服务器场所需的资源。 检查现有搜索环境中有多少可搜索的项目。 您可以在 SharePoint 管理中心网站的 搜索管理 页面上找到此数字。 若要打开搜索管理页，请单击“管理中心中的 服务应用程序 ”，然后单击搜索服务应用程序的名称。

估计预计未来 12 个月可搜索项数会增长多少，并针对该数量设计搜索拓扑。 例如，如果你有 8,000,000 个索引项，并且你预计该内容的数量在未来 12 个月内将增长 50%。 应针对 12,000,000 个可搜索项进行设计。

第 2 步：我应扩展到什么大小的搜索体系结构？

评估搜索体系结构的构建是大是小并不容易。 搜索体系结构的大小取决于您的内容量、爬网率、查询吞吐量和您所需的高可用性级别。 Microsoft 已经测试了一些示例搜索体系结构，我们建议使用这些体系结构作为您自己的服务器场的基础。 将当前搜索体系结构与示例搜索体系结构进行比较，并确定哪个示例更好地体现了您当前的搜索体系结构。 然后考虑要扩展到哪个示例搜索体系结构。 您选择的示例搜索体系结构取决于有多少内容必须为可搜索状态：

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 线程数。

阿拉伯数字使用 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 线程数。

阿拉伯数字使用 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

阿拉伯数字使用 SharePoint Server 2013 时，所需的最小资源量为 500 GB RAM、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 2013)。 托管索引、分析处理和搜索管理组件（或搜索数据库）的服务器要求存储不仅能保持低延迟，还能提供足够的每秒 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 创建具有高可用性的体系结构和策略。 当您在单独的故障域中托管冗余搜索组件和数据库时，服务器场某个部分停机不会使整个服务终止。 但是，搜索性能会下降，因为搜索组件无法再共享负载。 为了降低丢失单个服务器的可能性，最好改进本地冗余。 对于搜索体系结构中的每个主机服务器：

  • 在每个服务器上使用 RAID 存储。

  • 在每个服务器上安装多个冗余网络连接。

  • 安装多个冗余电源，每个服务器均具有独立布线或不间断电源 (UPS)。

所有示例搜索体系结构在独立服务器上托管冗余搜索组件。 在示例搜索体系结构中，每个主机对中最右侧的主机为冗余主机。 下面显示了大型搜索体系结构，其中框出了冗余主机：

指明哪些服务器托管冗余搜索组件的大型企业搜索服务器场的示意图。