SharePoint 2013中规划企业搜索体系结构

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

SharePoint 2013中规划企业搜索体系结构

摘要:了解如何规划小型、中型或大型企业搜索体系结构。

设置企业搜索体系结构之前,需要仔细规划很多事项。我们将逐步帮助您规划小型、中型或大型企业搜索体系结构。

您是否熟悉 SharePoint 2013 中搜索系统的组件,及如何交互?您在开始进行之前阅读 SharePoint Server 2013 中的搜索概述 SharePoint Server 2013 搜索体系结构,以便熟悉搜索体系结构、搜索组件、搜索数据库和搜索拓扑。规划搜索体系结构时,以下是有关注意事项的一些建议:

第 1 步:我有多少内容?

第 2 步:多大搜索体系结构适合多少内容?

第 3 步:我应了解哪些硬件要求?

  • 选择以物理方式还是虚拟方式运行服务器
  • 选择主机服务器的硬件资源
  • 规划存储性能
  • 选择您的搜索体系结构支持高可用性的方式

第 4 步:如何检查我的搜索体系结构是否运行良好?

  • 测试存储 I/O 子系统
  • 测试搜索性能

第 1 步:我有多少内容?

您的搜索索引拥有的内容量影响您需要托管服务器场的资源。算出您规划为可搜索的大约项目数。以下是一些项目示例:文档、网页、SharePoint 列表项和图像。请记住,SharePoint 列表中的每个条目都可列为一项。

当您确立好一个数字后,乘以您认为该内容在未来 12 个月内的预期增长。

例如,如果您启动 12000 个索引项目,并希望该内容量在未来 12 个月内增加三倍,您应规划 36000 个可搜索项。

第 2 步:多大搜索体系结构适合多少内容?

评估搜索体系结构的构建是大是小并不容易。搜索体系结构的大小取决于您的内容量、爬网率、查询吞吐量和您所需的高可用性级别。此处有一些 Microsoft 测试过的搜索体系结构示例,我们建议您将这些示例用作您规划自己服务器场的基础。您所选择的示例搜索体系结构取决于需要搜索的内容量:

尽管这些示例搜索体系结构使用虚拟机,您仍可以根据您搜索体系结构的整体 SharePoint 2013 解决方案策略同时使用物理服务器和虚拟机。

小型搜索服务器场

如果您最多拥有 1000 万个项目,小型搜索服务器场可能是最适合您的服务器场。Microsoft 测试了此搜索服务器场,并测量出它每秒可以爬网 50 个文档,且每秒服务 10 个查询。对于每秒 50 个文档的爬网率,首次完全爬网中,需要搜索 55 个小时来爬网 1000 万个项目。

中型搜索服务器场

如果您具有 1000 万个和 4000 万个之间的项目,中型搜索服务器场可能是最适合您的服务器场。Microsoft 测试了此搜索服务器场,并测量出它每秒可以爬网 100 个文档,且每秒服务 10 个查询。对于每秒 100 个文档的爬网率,首次完全爬网中,需要搜索 110 个小时来爬网 4000 万个项目。

大型搜索服务器场

如果您具有 4000 万个和 1 亿个之间的项目,大型搜索服务器场可能是最适合您的服务器场。Microsoft 测试了此搜索服务器场,并测量出它每秒可以爬网 200 个文档,且每秒服务 10 个查询。对于每秒 200 个文档的爬网率,首次完全爬网中,需要搜索 140 个小时来爬网 1 亿个项目。

第 3 步:我应了解哪些硬件要求?

现在,您已确定了您的内容量并选择了示例搜索体系结构,下一步是规划您所需的硬件,如本节中所述:

  • 选择以物理方式还是虚拟方式运行服务器
  • 选择主机服务器的硬件资源
    • 规划主机服务器的一般存储
    • 小型搜索服务器场的最低硬件资源
    • 中型搜索服务器场的最低硬件资源
    • 大型搜索服务器场的最低硬件资源
  • 规划存储性能
    • 选择存储空间
      • 搜索组件 IOPS 要求
      • 搜索数据库 IOPS 要求
  • 选择您的搜索体系结构支持高可用性的方式

选择以物理方式还是虚拟方式运行服务器

如果您使用的是我们已为您测试过的小型、中型或大型体系结构中的一个,您将在虚拟机上运行搜索体系结构。另请注意,尽管虚拟环境更容易管理,但其性能级别有时可能会稍低于物理环境。物理服务器在同一服务器上可托管的搜索组件比虚拟服务器要多。您可在 SharePoint 2013 中的服务器场虚拟化和体系结构概述中找到有用的指导。您也可以在物理服务器上运行搜索体系结构。在示例服务器场体系结构中,只需将搜索组件从虚拟机移到主机服务器并移除虚拟机即可。每个物理服务器最多可托管四个索引组件,但其他搜索组件每种仅托管一个。例如,如果您将中型示例搜索体系结构更改为使用物理服务器,您将发现您在主机 E 上有两个内容处理组件。解决方案是退出其中一个内容处理组件。这样是可行的,因为内容的处理依赖于可用的资源数量,而不是内容处理组件的数量。

选择主机服务器的硬件资源

每个搜索组件和搜索数据库需要主机服务器的最少量的硬件资源即可运行良好。但是,您拥有的硬件资源越多,您的搜索体系结构的性能越好。因此,硬件资源数量最好多于硬件资源的最低数量。每个搜索组件需要的资源取决于工作负荷,这主要由爬网速率、查询速率和索引项目数决定。

例如,在 Windows Server 2008 R2 Service Pack 1 (SP1) 中托管虚拟机时,每个虚拟机使用的 CPU 内核不能超过四个。在 Windows Server 2012 或更高版本中,您在每个虚拟机上使用八个或更多 CPU 内核。然后您可以为每个虚拟机向外扩展更多 CPU 内核,而无需向上扩展更多虚拟机。设置使用相同硬件资源托管相同搜索组件的服务器或虚拟机。现在我们以索引组件为例。当您在虚拟机上托管索引分区时,性能最差的虚拟机决定了整个搜索体系结构的性能。

分析报告数据库所需的最低存储量可能各不相同。这是因为存储量取决于用户与 SharePoint 2013 的交互方式。当用户交互频率较高时,通常要存储更多事件。检查当前搜索体系结构用于分析数据库的存储量,并至少为您重新设计的拓扑分配此存储量。

一般存储

确保每台主机服务器具有足够的磁盘空间进行 Windows Server 操作系统和 SharePoint 2013 程序文件的基本安装。主机服务器还需要有可用的硬盘空间进行日志记录、调试、创建内存转储等诊断、日常操作和页面归档。一般情况下,80 GB 的磁盘空间足以供 Windows Server 操作系统和 SharePoint 2013 程序文件使用。

增加每个数据库服务器的 SQL 日志空间的存储。如果您没有将数据库服务器设置为经常备份数据库,SQL 日志空间将使用大量存储,有关如何规划 SQL 数据库的详细信息,请参阅存储和 SQL Server 容量规划与配置 (SharePoint Server 2013)

小型搜索服务器场的最低硬件资源

下表显示了每个应用程序服务器或数据库服务器需要的最低硬件资源量。

中型搜索服务器场的最低硬件资源

下表显示了每个应用程序服务器或数据库服务器需要的最低硬件资源量。

大型搜索服务器场的最低硬件资源

下表显示了每个应用程序服务器或数据库服务器需要的最低硬件资源量。

规划存储性能

存储速度影响搜索性能。请确保您的存储速度足够快,从而能够处理来自搜索组件和数据库的流量。磁盘速度以每秒的 I/O 操作数 (IOPS) 进行测量。

对于在存储空间内分布来自搜索组件和操作系统的数据,您所决定的方式会影响搜索性能。比较好的做法是:

  • 在具有普通性能的三个单独存储卷或分区之间拆分 Windows Server 操作系统文件、SharePoint 2013 程序文件和诊断日志。
  • 存储高性能的独立存储卷或分区上的搜索组件数据。

注意:

当您在主机上安装 SharePoint 2013 时,您可以为搜索组件数据设置一个自定义位置。需要存储数据的主机上的任何搜索组件将数据存储在此位置。稍后要更改此位置,必须在该主机上重新安装 SharePoint 2013。

选择存储空间

有关存储体系结构和磁盘类型的概述,请参阅存储和 SQL Server 容量规划和配置 (SharePoint Server 2010)。托管索引、分析处理的服务器和搜索管理组件或搜索数据库需要能够保持低延迟的存储,同时每秒还能够提供充足的 I/O 操作数 (IOPS)。下表显示了每一个这些搜索组件和数据库要求的 IOPS 数。

如果您部署诸如 SAN/NAS 的共享存储,一个搜索组件的高峰磁盘负载通常与另一个搜索组件的高峰磁盘负载一致。若要获取共享存储的 IOPS 搜索要求量,您需要将每一个这些组件的 IOPS 要求量加起来。

所示组件 IOPS 要求

搜索数据库 IOPS 要求

选择您的搜索体系结构如何支持高可用性

如果您不熟悉高可用性策略,以下是可让您开始的文章:为 SharePoint 2013 创建具有高可用性的体系结构和策略。当您托管独立容错域上的冗余搜索组件和数据库时,您的搜索体系结构支持高可用性。所有的示例搜索体系结构都托管独立服务器上的冗余搜索组件。

对于搜索体系结构中的每一个冗余主机服务器,您应计划安装:

  1. 冗余网络
  2. 通过独立布线或不间断电源 (UPS) 提供的冗余电源。

第 4 步:如何检查我的搜索体系结构是否运行良好?

在您将搜索体系结构部署到生产环境之前,需要检查该搜索体系结构是否运行良好。以下是操作步骤清单:

  1. 对使用拥有充足 IOPS 的存储 I/O 子系统的索引组件进行测试。请参阅测试存储 I/O 子系统
  2. 将搜索体系结构到试验环境。确保该试验环境代表了生产环境。
  3. 测试试验环境的搜索性能。请参阅测试搜索性能

有关 SharePoint 2013 中一般测试的概述,请参阅SharePoint Server 2013 的性能测试

测试存储 I/O 子系统

若要测试存储 I/O 子系统,请运行最重要的磁盘操作并测量 IOPS。您可以使用 SQLIO 工具运行这些测试。请参阅 SQLIO 磁盘子系统基准工具

设置测试环境

您无需设置整个搜索体系结构,或者安装 SharePoint 2013。只需设置可以产生存储 I/O 子系统理想工作负载的测试环境即可。

我们来设想一下本地存储的案例。例如,如果中等搜索服务器场中的主机 A 使用本地磁盘,您需要安装两台虚拟机并同时运行两台虚拟机上的磁盘操作测试。

您需要另外设置一个共享存储。例如,如果中等搜索服务器场中所有索引组件的工作负载及其他不相关的工作负载都共享同一个存储,那么您需要:

  1. 安装主机 A、B、C 和 D 中的八台虚拟机,并设置不相关工作负载的源。
  2. 确保您在主机 A、B、C 和 D 中所有虚拟机上运行同步磁盘操作测试的同时,不相关工作负载应用到共享的存储。

创建测试文件

  1. 使用命令 sqlio.exe -t32 -s1 -b256 1g 创建 1 GB 测试文件。此命令创建名为“1g”的文件。
  2. 保存您希望测试的存储设备上的测试文件。例如:中等服务器场中主机 A 的硬盘上。
  3. 将此测试文件连接到一个足够大的测试文件。例如:256 GB,使用命令 copy 1g+1g+1g+...+1g testfile
  4. 重新启动服务器。这将确保缓存不会导致测试结果出现偏差。

运行测试

最好测量以下内容:

  • 中等大小的随机访问性能(请参阅以下测试一和测试二)。
  • 大型传输的读取和写入吞吐量(请参阅以下测试三和测试四)。

下表显示您应用于运行每次测试的 SQLIO 命令。所有命令都假设当前目录中存在“测试文件”。每次测试运行 300 秒。

本地磁盘存储的示例结果

下表中的示例结果显示了在添加测试文件之前已至少使用 50 % 磁盘子系统能力的部署。

磁盘控制器和磁盘心轴强烈影响这些结果。

如果您测试空磁盘,您将获得提升的结果,因为测试文件将处于跨所有心轴的最佳轨迹(短行程)。这可以提高多达二倍或三倍的性能。如果您测试优化了对未初始化存储空间或包含所有零的存储(例如,动态 VHD/VHDX 文件)的访问的硬盘,您将获得偏高的结果。在此案例中,使用非常大的包含真实数据的测试文件,而不是生成使用 SQLIO 命令的综合测试文件。

测试搜索性能

以下是测试您搜索体系结构的操作步骤清单:

  1. 选择要运行测试的内容
  2. 选择要测试查询性能的术语和短语
  3. 测试搜索性能

选择要运行测试的内容

选择最代表您生产内容的内容。如果您选择仅用于测试的内容,请确保您已获得不同类型的项目,而不是您已复制多次的一个项目。原因是因为查询处理器将花时间检测复制的项目,这将影响搜索性能,而且您的结果无法代表生产环境。

设置可爬网内容的一个或多个内容源。请验证您具有所需的用户帐号和网络访问。

选择要测试查询性能的术语和短语

您所获取的查询结果的数量称为查全率。

若要测试查询性能,您首先需要创建一组用作查询的术语和短语。请确保该组包含具有低查全率和高查全率的术语和短语,且该术语和短语与您的环境相关。

示例

  • 如果您搜索产品目录中的产品编号,很可能一个产品只有一个编号。因此您可以快速地获得搜索结果。这是低查全率。
  • 如果您在公司 Intranet 上查询类似于“演示文稿”的常用术语,很可能会获得许多结果,而且花费更长的时间。这是高查全率。
  • 例如,如果您的内容与人力资源相关,则使用与此领域相关的搜索术语。

测量搜索性能

SharePoint 2013 收集“爬网运行状况报告”和“查询运行状况报告”中的搜索性能测量。您可以在“搜索管理”下的管理中心找到这些报告。

较好的方法是首先使用综合负载测量搜索性能,然后使用一小组活动用户和活动内容进行测量。当您使用活动用户和活动内容时,可以观察到搜索体系结构执行的方法。如果您的内容比预期的增长更快,可能值得考虑使用下一大小的搜索体系结构。或者,如果您的用户比预期使用更多的分析,我们则建议您增加分析数据库的存储空间量。

 本文转自SanMaoSpace博客园博客,原文链接:http://www.cnblogs.com/SanMaoSpace/p/5052343.html,如需转载请自行联系原作者

相关文章
|
存储 固态存储 索引
搜索和推荐统一存储层的新进展和思考
我们在2017年统一了搜索和推荐场景下的HA3、iGraph、RTP和DII四大引擎的存储层(参见统一之战),帮助它们取得了的更迅速的迁移能力、更快速的数据恢复能力和更丰富的数据召回能力。 最近一年来,我们在统一的存储框架上又做了进一步的演进,下面将分别从架构、Build服务以及存储模型角度介绍我们的新进展和思考。   1.架构   在我们的传统架构(参见统一之战)中,
2846 0
|
6月前
CRM软件推荐2024:五款顶级产品解析,助您找到最佳选项!
2024年,随着民营经济发展,CRM软件成为企业增长的关键。本文推荐了五款高好评CRM:1) Zoho CRM,以其易用性和性价比受青睐;2) Zoho Bigin,轻量级选项适合小微企业;3) Salesforce,CRM巨头,但国内售后不足;4) Hubspot,提供免费版,付费版价格较高;5) Pipedrive,专注小型团队。企业在选择时应考虑试用体验和服务质量。
114 6
|
机器学习/深度学习 监控 算法
转:蝶形算法在文档管理软件中的运用包含哪些具体优势
蝶形算法,也称为快速傅里叶变换(FFT),是一种用于计算序列的离散傅里叶变换的数学算法,它在信号处理、图像处理和控制系统中有着广泛的应用。
104 0
如何建立一个内部搜索营销团队
在这个由两部分组成的系列文章的第1部分中,概述了各种内部组织结构,并解释了各自如何帮助建立,发展和维护内部搜索营销团队。 建立,发展和维护内部搜索营销团队对任何组织来说都是一项挑战。 在这个由两部分组成的系列文章的第一部分,“如何建立一个内部搜索营销团队”中,我将解决所有这些问题,并概述不同的组织结构,为内部团队提供最佳机会成功。
1284 0
下一篇
无影云桌面