SharePoint 2010 Search 架构 - 已完工-白红宇

SharePoint 2010 Search 架构 - 已完工

阅读量：5944 次

发布时间：2019-06-19

本文共 12810 字，大约阅读时间需要 42 分钟。

基本知识

===============

Search 再也不是依赖于SSP了. 默认情况下, Search功能现在由Search Service Application, Search Application Proxy, Web services, Search Service Instance, 还有一下的SQL数据库组成:

Search Service Application DB

Search Service Application Crawl Store DB

Search Service Application Property Store DB

创建Search Service Application和Proxy有三种方法.

通过管理中心站点的Manage Service Applications页面

通过管理中心的Farm Configuration Wizard

通过PowerShell命令

Search利用了SharePoint Foundation提供的共享服务的框架(framework). 定义一下组成search的各种组件现在是比较有必要的.

这些组件每一种都扮演了一份重要的角色.

Crawl

==================

爬网组件和爬网数据库

爬网组件即crawler component, 也叫indexer. Indexer就是一个寄宿着一个或多个crawl component的物理服务器. 在SharePoint 2010的search中的一个巨大改变就是indexer上不再存放一份index文件了. Item在被index的同时就会被发送(stream或propagated)到Query server上. 由于Indexer不再存放索引文件的物理拷贝, 它也就不再是一个失败之处了. 默认情况下, 当你通过管理中心provision一个search service application之后, 一个crawler component和crawl database就为你创建出来了.

Crawl component的工作就是将爬数据, 并把content制作成index. Crawl component在MSSearch.exe进程中运行, MSSearch.exe进程是一个叫做"SharePoint Server Search 14”的windows 服务.

为单个search service application创建多个crawl database和crawler component是可以做到的. 这么做的原因有很多, 有些会在这篇文章里介绍一下. 当创建一个crawl component的时候, 它需要与一个SQL 中的crawl database建立映射关系. crawl DB和crawl component都可以即通过管理中心站点创建, 也可以通过PowerShell来创建. 为了简化起见, 我这里只覆盖用管理中心创建的部分. 为了修改Search的拓扑逻辑, 你必须访问Search Administration页面:

Central Administrator\Application Management\Manage Service Applications\Select Search Service Application and select Manage from Ribbon

[具体创建过程就不赘述了, 步骤和截图可以查看].

容错与性能

物理索引文件不存在于indexer上并不意味着你就用一个indexer就够了. 比如说, 如果仅创建了一个crawler component, 并且寄存这个component的index server挂了, 那么search的一个主要组成部分就坏掉了, 因为再也不会有新的爬网发生了. 在第二台机器上创建一个secondary的crawl component可以提供容错机制. 一个crawl component仅可以对应一个SQL crawl database. 多个crawl component可以map到同一个crawl database. 通过多个crawl component映射到同一个crawl database, 容错机制就达成了. 如果寄存crawl component 1的服务器崩溃了, 那么crawl component 2可以从crawl component 1停下的地方继续. 这样我们达到了对indexer的容错, 那crawl DB咋办? 我们完全支持SQL mirror, crawl DB可以在SQL层次来创建mirror来完成对容错机制的支持.

在这种配置下, 性能会有提高, 因为你现在有两个indexers在爬数据而不是一个. 如果你对爬网时间不满意, 很简单地添加一个额外的crawl component并映射到同一个crawl DB上就可以了. 工作量会被同时分配到两台index servers上.

问: 如果我制定了两个indexer来爬相同的content, 并且两个crawl component映射到相同的crawl DB上, 那么这些indexers是否能同时去试图爬新发现的item呢?

答: 不, 不会有重叠的. Items是成批的被两台indexer"捡起"并处理的. 如果Indexer 1选择了第一批, 那么indexer2会处理第二批.

Crawl 任务分配

Crawl任务分配可以通过下面的拓扑配置来获得:

Crawl Component 1 --> Crawl DB 1

Crawl Component2 --> Crawl DB 2

通过使用将两个crawl component分别映射到不同的crawl database上的方式, 爬网时每一个host都被赋予了一个crawl DB. 这里的Host就是content source中所定义的一个地址. 所以, 如果我使用host header为Sales.Contoso.Com 和TPSReports.Contoso.Com创建了两个web applications, 那么这两个的任何一个都是一个单独的host. 我可以使用下面的配置来创建一个新的search service app:

Index Server 1 “Crawl Component 1” <--> Crawl DB 1

Index Server 2 “Crawl Component2” <--> Crawl DB 2

当我开始爬网的时候, 例子中的每一个host会最终按照下面的结果进行分配:

Sales.Contoso.Com --> Index Server 1 “Crawl Component 1” <--> Crawl DB 1

TPSReports.Contoso.Com --> Index Server 2 “Crawl Component2” <--> Crawl DB 2

跟crawl database关联的寄宿有crawl component的服务器会爬那个host. 当多个crawl database存在的时候, SharePoint会去尝试平均地分配爬网的工作量. 在这个例子中, 我仅有两个host. 如果我之后再添加第三个host, 那么crawler如何确定哪个crawl db会负责哪个host呢? 这个决定的结果基于已经存在于crawl DB中的item或doc的数量.

在上面的例子里, Sales.Contoso.Com 有30万个item, 并且被赋给了Crawl DB 1; TPSReports.Contoso.Com 有200个item, 并且被assign给了Crawl DB 2. 然后呢, 下面的两个host被添加到了content source中:

HR.Contoso.Com 有2,000 items

Facilities.Contoso.Com 有8,000 items

爬网被初始化的时候, 这两个host都会被赋给Crawl DB 2, 因为Crawl DB 2相对于Crawl DB 1 而言包含较少的doc id. Host的分配并不是只凭host的数量来确定的, 事实上是靠每个crawl db中的item的数量决定的. 默认情况下, 有更少doc id的crawl db总是会被分配新的host. 如果想要影响这种分配机制的话, 我们可以使用host distribution rule来进行干预.

注意: 仅多创建crawl database而不创建crawl component是没有意义的, 因为这是对SQL server的磁盘和资源的一种浪费.

问: 一个crawl component或crawl database存在, 并且已经爬网过了场中的所有的host. 基于很多原因我们后来决定添加额外的crawl component和crawl database. SharePoint管理员想要把已经存在于原来的crawl db中的一半的host剪切到新的crawl db中, 这可以么? 如何做到呢?

答: 一旦crawl component和crawl database被创建了, 那么有两种方法来移动一半的host.

第一: 重置索引, 之后完全爬网.

第二: 为那一半的host添加host distribution rule. 完全爬网, 爬网结束后, 就可以移除host distribution rule了.

控制Host Address Distribution

在某些情况下, SharePoint管理员会需要对哪个crawl db/indexer被赋予那个host上有更强的控制. 这可以通过对host distribution rule的使用来达成. 这个功能可以在search admin page中访问到.

当我们添加了一个host并且应用的时候, 如果这个host已经被分配到了一个crawl store中, 那么crawler会被暂停, 同时内容会被物理地移动到你所指定的crawl DB中. 这是一个非常耗费资源的动作.

还需要更多控制么?

你还可以控制是否需要某个crawl DB仅仅服务于host distribution rule. 当创建新的crawl component的时候, 最后的一个选项如下:

通过创建只服务于Host Distribution Rules中的host的crawl database, indexer会意识到修改的存在, 并且会自动地不会去在crawl的时候在这个crawl database中自动分配新发现的host. 仅在host address属于Host Distribution Rule里定义的映射属性集合的时候, 才会被分配到相应的crawl db中.

当一个SharePoint 管理员想要利用这个功能, 一个比较适合的情况是那个新添加的host包括几百万个item. 如果Host Distribution Rule在爬网之前就创建好了的话, 这样的配置会为那个host提供一个专门的crawl database. 因为这个database是dedicate于那个host的, 所以这个database就不会再被添加新的host.

问: 我如何可以通过使用"在host distribution rules中定义host的方法"和"拥有dedicated的crawl database的host的方法"来达到即能容错, 又能有较短的crawl 时间的效果呢?

答: 当然可以, 这就和定义另一个crawl component并映射到一个dedicated的crawl database一样简单. 记住, 多个crawl component可以映射到相同的crawl DB上, 这样可以高效地达成"容错"+"更短爬网时间的性能提升"的效果.

问: 等等! 我对于一个crawl component对应一个crawl database很满意. 我不想要"server hosting crawl component"这个indexer了, 我想要个崭新的server做我的indexer, 我需要创建一个新的crawl component么?

答: 不需要. 没必要为了迁移到一个新的index server而创建额外的crawl components. 就简单的通过页面Search Admin Page\Search Application topology 编辑当前的crawl component, 指定新server就可以了.

观察是第一步, 行动是第二步

在武断地provision新的crawler components和crawl DBs之前, 应该先观察一下当前的环境和爬网的健康状况, 收集一些证据来支持你所要做的重要决定会比较好. 追求容错机制和减少爬网时间的原因前面已经介绍过了, 我这里就不会进一步的讨论了. 观察系统或硬件的瓶颈是考虑增加更多crawl component或crawl db的一个好的先行步骤.

监测Index Server

观察: Index server在爬网时几乎CPU用到顶, 或者物理内存用到顶, 导致爬网时间变长.

行动: 在一个新server上Provision一个新的crawl component, 然后映射到相同的crawl DB上.

监测SQL Server

观察: crawl database的IO在极限附近(I/O bound), 并且磁盘延迟(disk latency)异常高.

行动1: 在相同的SQL Server上不同的主轴集上("on a different set of spindles”)Provision一个新的crawl database, 然后使用Host Distribution Rule转移掉一半的host到新的crawl db上.

或者

行动2: 在一个不同的带有更佳的磁盘子系统的SQL Server上Provision一个新的crawl database, 然后使用Host Distribution Rule转移掉一半的host到新的crawl db上.

注意: Provisioning一个crawl db需要provision一个新的crawl component.

观察: 爬网时, SQL Server Memory或CPU几乎到顶, 并且无法维持高负载.

行动: 构建一台新的SQL Server, 在新的SQL Server上provision crawl DB. 使用Host Distribution Rule转移掉一半的host到新的crawl db上.

重要: 这些是非常基本的解决系统瓶颈的方法. 比如说, 大致的对于CPU观察里发现有CPU high的情况, 不能从这就自动地臆断需要创建新的crawl components. 你可能需要更多的分析. 诸如找到下面问题的答案:

CPU是仅在crawl的时候high么?

那个进程的CPU高?

Content source里有新添加的host么?

SharePoint的健康监测和性能计数器有没有揭示一些有用的东西?

等等...

Query

==================

在SharePoint 2010的Query中, 有些东西已经改变了. Query基础架构也已经组件化了, 所以现在, 你仅需要创建你需要的东西. 这篇文章会过一遍query component的定义, 他们如何协同工作的, 如何创建他们.

Query 基础

跟crawl一样, Query也组件化了, 从而达成了下面的目标:

亚秒级的查询延迟.

索引不再是失败点, 索引存储在Query Server上.

Query由在多台服务器上的可以向外扩展的组件们组成, 从而提高了性能.

Query 流程

一个用户执行了一个搜索动作

服务于用户的WFE使用相关联的Search Service Application Proxy来连接到运行着”Query and Site Settings Service”(也通常被叫做Query Processor)的服务器上. 它使用WCF来完成这次通信.

QP会连接到下面的组件上来搜集搜索结果, 合并搜索结果, Security Trim搜索结果, 然后把最终结果返回给WFE.
- Query Component - 存有全部索引文件或部分索引文件
- Property Store DB - 存有metadata或被索引的内容的properties
- Search Admin DB - 存有Security Descriptors和Configuration data

WFE向用户显示搜索结果.

几个Query Component是可以随着索引文件或属性的增加而扩展的. 一个search service application中, 下面的组件都可以有多个:

- - Property Store DB
  - Query Components
  - Query Processors

Query Component 和 Property Store DB

在这篇文章中我会交互使用Query Server和Query Component两个术语. Query Server是一台运行着一个或多个Query Component的服务器. 这些服务器保有一份完整的索引文件或者部分的索引文件. Query Server现在是在文件系统上存放索引文件的唯一角色. 正如前面谈到的, Indexer爬网内容并制作临时索引. Indexer会分块地propagate临时索引到Query Server上. Query Server包含一整份或作为索引分区的一部分索引. Query组件运行在Index Partition的上下文中. Query组件负责为搜索请求提供服务. Query Component运行在MSSearch.exe中. 一个Query Component仅会被映射到一个Property Store DB上. 到目前为止, 你应该注意到了我们拆分了Search用的数据库(例如:Property Store DB和Crawl DB). 通过拆分这些数据库, 我们可以达到下面的目的:

- - 数据库的size变小了.
  - 数据库的性能提高了.

还有, 通过雕琢数据库, Crawl DB的使用高峰并不会影响到Query的性能, 因为Query主要使用的是Property Store DB.

为单独的Search Service Application创建多个Property Store database和Query Component是可以的. 这么做的原因有很多, 这些原因的大多数都会在本文的后面进行介绍. Query Component可以为某个Index Partitiion而创建, 也可以为某个Index Partition的镜像(Mirror)而创建从而达到容错(fault tolerance)的目的. 这种Query组件(Query Partition和Property Store DB)都可以在通过管理中心或者PowerShell来创建. 为了简化, 我仅描述如何在管理中心中进行创建. 为了修改Search Topology, 你需要访问 Search Administration页面.

Central Administrator\Application Management\Manage Service Applications\Select Search Service Application and select Manage from Ribbon

滚动到页面的下方查看或修改搜索拓扑结构.

分三步创建Query组件.

点击Modify按钮.

选择New Property Database 或者 Query Component, 然后添加合适的选项配置.

Apply 拓扑修改.

容错与性能

Query Component的容错

强烈推荐为你的index创建容错机制. 这可以通过为一个Query Component在另一台服务器上创建镜像而做到. 参考下图创建:

结果是为相同的Index Partition创建了第二个Query Component.

注意: Query Processor会在Query Component之间分配Query请求.

问: 我不想让我的Query Component的镜像来提供Query服务, 怎么办?

答: 在添加mirror query component页面, 你可以选择下面的选项:

Set this query component as failover-only.

这并不会消除failover query component收到query请求. Query Processor会优先考虑没被标记为fail over的Query Component来提供query 服务. 如果所有的active query component都down了, 那么query processor会把请求发送给标记为fail over的query component.

Property Store 的容错

我们完全支持后端使用SQL mirroring来达到对Property Store DB的容错.

Query Component 的性能

在SharePoint的前一个版本中, 每一个query server都会存储一整份的index文件. 虽然这个完成了容错的目的, 但是这对性能并没有什么帮助. Index的大小和Query的延迟之间是有只接关系的. Index的大小可以很容易的成为Query 性能的瓶颈.

比如说:

拥有一千万文档的index平均需要2秒来完成单次查询.

拥有两千万文档的index平均需要4秒来完成单次查询.

这个问题在SharePoint 2010 中被解决了. Index partition可以包含一整份的index, 也可以包含一部分的index. 通过创建额外的query component, 一个新的index partition会被创建出来, 并且其会保有一部分的index.

比如:

假设整个index是8GB大小, 包含两千万个文档.

拥有 50%: 4GB 的index\10 million documents: Query Server 1 - Index Partition 1

拥有 50%: 4GB 的index\10 million documents: Query Server 2 - Index Partition 2

通过对巨大索引的分区, 查询时间会被减少, 针对这种瓶颈的解决方案就出现了. 对索引进行分区很简单, 就跟创建query component一样.

举例:

问: 如果一个index被分区到了多个query components上, 那么crawler如何分配被索引了的内容呢?

答: Crawler会通过一个基于DocID的哈希算法来分配爬网过的内容.

Property Store DB 的性能

正如Query component一样, Property Store DB也可以扩展并且在Property Store DB里分担load. 如果property Store DB因为Database的大小, 或者是因为磁盘子系统的IO延迟而成为了系统后端的瓶颈, 那么我们可以创建一个新的property store DB来分担负载. 跟crawl DB一样, Property Store DB如果没有映射到什么东西上的话, 那它就一点儿用都没有. 因此, Property Store DB必须被映射到一个Query Component上. 如果决定了要创建一个额外的property store DB来增强性能, 那么我们就得创建一个非镜像的Query Component然后映射到这个property Store DB上.

下面是一条至理名言:

"创建一个新的property store DB需要Index被分区, 因为不得不创建一个新的非镜像的Query Component."

Query Processor

好极了, 理解Property Store DB和Query Component的扩展已经完成了一半, 还有一半. Query Processor在Search 2010里仍然扮演着重要的角色. Query processor负责处理一个query请求并且它运行在w3wp.exe进程中. 它从Property Store DB和Index components和query components中获取结果. 一旦拿到了结果, 他们就会被打包, security trim后, 回传给query的请求者(WFE). 针对相同的index partition, 如果有多于一个query component或其镜像存在, Query Processor会对到来的请求进行负载均衡. 这项规则的一个例外是: 如果query component被标记为fail over only(更多请具体见上面的描述).

问: 如果我对我的index进行了分区, 同时我又创建了多个query component, 每个query component都各服务于一个index partition呢? Query Processor怎么会知道该连接到哪个partition上才能精确地得到正确的结果呢?

答: 答案是它不会知道的. Query Processor会连接到每一个单独的包含index的partition的非镜像的query component去取结果.

问: 如果我为了提高性能而创建了多个property store database呢? Query Processor怎么会知道究竟该连接到那个property store才能精确地获得正确结果呢?

答: 答案是它不知道. Query Processor会连接到每一个Property Store去取结果的.

在SharePoint 2007中, Query Processor运行在任何一个WFE上. 在SharePoint 2010里, 任何服务器都可以运行Query Processor. 它不再跟Query角色绑定了. 你可以通过下面的步骤在任何一台机器上创建Query Processor.

管理中心站点, System Settings, Services on Server页面.

开启Search Query and site settings服务

注意: Post provision a new web service is created within IIS on that server. 之后, 一个新的web service会在那台服务器上创建出来.

Query Processor的扩展

跟Query Component和Property Store DB一样, Query Processor角色也可以通过多台服务器扩展. 如果Query Processor是瓶颈的话, 比如说不能满足到来的所有的query请求, 又或者是寄存着Query Processor的w3wp.exe有CPU或内存的使用过高问题. 这种情况下, 创建额外的Query Processor就是应该的了. 通过这么做, 请求的负载会在每一台运行着Query Processor的服务器中进行均衡.

同样的, 这还可以达到容错的目的. 通过多台Query Processor的角色, 如果一台挂了, 那么另一台还可以使用. (译者曾经遇到过一个问题, 多台机器运行Query Processor, 其中一台的共QP使用的web service坏掉了, 这种情况下没有负载均衡, 相反情况是搜索会间歇性地失败.)

在父子关系的场中的Query Processor的功能

在Publishing/Consumer服务器场的场景下, Query Processor总是运行在保有Search Service Application的场中. 所以, 如果一个Search Service Application存在于Publishing Farm, 那么Query Processor就仅会在publishing farm中运行. Consumer farm通过相关联的Search Service Application proxy来通过WCF连接到publishing farm里的Query Processor.

观察是第一步, 行动是第二步

在武断地创建新的Query Component或者是Property DB之前, 先观察当前场的环境以及查询的健康状况, 通过收集证据来支持你稍后的重要决定. 很显然, 容错和查询延迟在前面的部分中已经讨论过了, 这里就不再赘述. 不按察系统的软硬件瓶颈是考虑添加Query Components或Property Store DB’s的好开端.

监测Query Server

观察: Query Server总是CPU很高, 同时, 或单独地, 物理内存的使用也很高, 这导致了查询延迟.

行动: 创建一个新的 query component

监控SQL Server

观察: Property Store DB 是SQL的IO重负, 并且磁盘延迟总是很高.

行动: 在相同机器或不同机器上创建一个新的Property Store

重要: 有很多基本的方法来解决系统的瓶颈. 比如说不要从简单的CPU的一次高峰就假设我们需要创建新的Query Component. 我们需要更多的观察分析. 比如说, 寻找下面问题的答案.