级别： 中级 David Konopnicki (Davidko@il.ibm.com), 搜索技术负责人, IBM
2006 年 4 月 03 日 在集群 WebSphere Portal 环境中安装 Portal Search 是一项重要的任务。可以使用几种有较大区别的配置。本文描述了如何在集群环境中使用 Portal Search、几种可能的拓扑结构以及与各个拓扑结构有关的权衡。文中讨论了安装过程和配置，以及 Portal Search 的基础体系结构原则。
引言
IBM® WebSphere® Portal 提供了搜索服务，通过使用该服务，可以建立内容源的索引并搜索内容。使用 Portal Search，管理员可以定义内容源爬网程序，爬网程序使用 HTTP 协议来抓取 Web 站点或内容存储库并为其建立索引。然后，门户用户可以使用搜索 Portlet 来搜索这些 Web 站点，搜索 Portlet 也是由 WebSphere Portal 提供的。另外，可以使用门户内容源来抓取安装在 WebSphere Portal 上的不同 Portlet 并建立相关索引。
本文的目标不是要取代 WebSphere Portal InfoCenter，这里讨论的任何安装或维护任务都应该参考它。相反，本文为 InfoCenter 中描述的过程提供了背景信息，这样就能够更容易地掌握它们，并有望避免错误。
读者应该基本了解 WebSphere Portal 集群（请参阅“参考资料”），并有一定的 Portal Search 使用经验。
下面几部分描述了 Portal Search 的高级体系结构。
了解 Portal Search
为了在集群环境中构建合理的拓扑结构，了解 Portal Search 的体系结构是很有帮助的。Portal Search 由三个 Portlet 和一个核心搜索服务组成。
核心搜索服务包括一组用于抓取 Web 站点和门户站点的爬网程序，以及文档处理管道（内容源爬网程序通过该管道传送文档和全文搜索索引）。它使用一个调度程序来发起周期性的事件，比如爬网程序执行和全文索引维护。在全文索引中建立文档的索引之前，管道将对文档进行处理，并且提供了自动化的摘要、文档格式转换和分类服务（请参见图 1）。
图 1：核心搜索服务
定位持久性数据
要了解集群环境中 Portal Search 的部署，需要知道所管理的是什么持久性数据以及其位于何处，因为该信息驱动着整个体系结构。正如下面的部分所演示的，有几种核心搜索服务部署方式。因此，管理和查询 Portlet 都需要指定核心搜索服务的位置：
- 搜索管理 Portlet 将其配置信息保存到两个不同的地方：
- Portlet 参数标识了该 Portlet 所管理的核心搜索服务。
- 搜索管理 Portlet 访问 WebSphere Portal 数据库，以存储和检索该服务中可用的集合的名称和位置。
- 搜索和浏览 Portlet 使用 Portlet 参数来保存核心搜索服务的位置以及要查询的集合的名称。
- Search Center 使用 WebSphere Portal 数据库来存储与核心搜索服务的参数一同显示的制表符的配置。
- 核心搜索服务把全文索引和集合配置保存在一起，包括文件系统中的内容源和分类。
这表示在集群环境的部署上有极大的约束。因为数据保存在文件系统中，所以两个不同的 Java JVM 很难在不损坏数据的前提下对其进行并发访问。这就是为什么会存在两种核心搜索服务：本地和远程服务。
本地和远程服务的比较
在安装了 WebSphere Portal 后即可以安装本地核心搜索服务，而且本地核心搜索服务将与门户在相同的 JVM 中运行。在集群环境中，几个 JVM 运行不同的 WebSphere Portal 实例以形成一个集群。所有这些实例共享相同的数据库数据。因此，如果将这些 JVM 的核心搜索服务用于访问磁盘上相同的数据，则该数据可能会被损坏。
对这个问题的一个解决方案是使用远程核心搜索服务。可以将核心搜索服务部署到 WebSphere Application Server，并配置管理员和搜索 Portlet，使其可以访问该远程服务。因此，集群节点访问这个公共 JVM，而该 JVM 提供了搜索功能并处理从门户集群中的不同节点传入的请求。由这个唯一的 JVM 来访问磁盘上的搜索数据结构，从而防止数据损坏（请参见图 2）。
图 2：使用远程搜索服务器
考虑 WebSphere Portal 集群拓扑结构
在将 WebSphere Portal 组织成一个集群时，有许多种可能的拓扑结构。尽管集群超出了本文的讨论范围，但区分垂直集群和水平集群是很重要的。
- 垂直集群的成员位于单个节点。这种集群用来提高功能强大的服务器的计算能力的使用率。
- 水平集群的成员位于不同的节点。这种集群提高了出现软件或硬件故障时的可用性。
在这两种类型的集群中，负载均衡都提高了服务器的可伸缩性。也可以将垂直和水平集群结合在一起.
对于搜索来说，重要的区别在于，在垂直集群中，不同节点共享公共的磁盘；而在水平集群中，每个服务器有自己的磁盘。这个区别将在本文其余部分中提到。
使用专用远程搜索服务器
对于集群环境，推荐的解决方案是使用专用搜索服务器。安装一个不属于集群的一部分的 WebSphere Application Server 实例，并将两个远程搜索服务器应用程序中的一个进行如下部署：作为基于 SOAP 的 Web 服务或作为 EJB。
可以在参与到集群中的某个节点上安装远程搜索服务器应用程序（使用另一个 WebSphere Application Server 进程，比如 server1）；然而，门户节点和搜索服务器将争用资源。因此考虑到负载均衡和稳定性方面的原因，最好将其安装到一个单独的 WebSphere Application Server 节点。
对于两个服务应用程序的安全考虑
这两个应用程序在搜索能力上是相当的，但区别在于客户机和服务器之间所使用的通信协议不同。SOAP 服务使用 HTTP，而 EJB 应用程序使用 IIOP。对于大多数用户，这并没有什么区别。然而出于安全方面的原因，一些客户禁止在其内部网中使用 SOAP（概述如下）。
这两种应用程序之间的重要差别是它们所支持的安全特性。在 WebSphere Portal V5.1 中，Portal Search 服务支持两种级别的安全性：
- 集合级安全性用来关联集合与授权用户组。只有授权用户才能在集合中进行搜索。
- 当门户内容源用来实现 Portlet 的可搜索能力时，它使用文档级安全性。这种机制确保在向用户显示搜索结果前，他们必须对页面和 Portlet 具有正确的授权。
这两种级别的安全性实施于 EJB 和 SOAP 应用程序。然而在使用 SOAP 时，无法防止敌对方连接到远程搜索服务器（到 SOAP 端口）并请求未经筛选的结果。（筛选任务是在 WebSphere Portal 服务器中完成的，因为远程 Application Server 不能访问所需的安全信息）。发起此类攻击并不简单，但在理论上却是可行的。
另一方面，如果使用 EJB 应用程序，可以对 WebSphere Portal 和远程搜索服务器之间的通信进行保护，以使远程搜索服务器只接受来自 WebSphere Portal 的连接。
使用远程搜索服务器的限制
远程搜索不能出现在集群中。因此：
可以采取如下方式来防止这种情况：
- 使用监视工具。
- 在不同的节点上配置两个相同的远程搜索服务器，让搜索管理 Portlet 指向它们，并配置一个用来在两者间均衡请求的负载均衡器。然后配置搜索 Portlet 以与负载均衡器进行通信。这种解决方案提高了可伸缩性和可用性。
安装两种远程服务器应用程序之一
要安装和部署 SOAP 服务或 EJB 应用程序，可以执行下列操作：
- 在 WebSphere Application Server 上部署其中一种应用程序。
- 启动应用程序或服务。
- 按照上面所描述的，配置搜索管理 Portlet、搜索和浏览 Portlet 以指向远程搜索服务器。
有关详细信息，请参阅 WebSphere Portal V5.1 InfoCenter 中的主题 Portal Search => Using remote search service。
启用 EJB 应用程序的安全性
要保护 WebSphere Portal 和远程 EJB 搜索服务器之间的通信，请完成下列步骤。有关详细信息，请参阅 WebSphere Portal V5.1 InfoCenter 中的 Portal Search => Preparing security for remote search service。
- 在门户和远程搜索服务器上启用 J2EE 安全性，并确保这两个服务器共享相同的 LDAP 服务器来管理用户。
- 确保集群中所有的服务器共享相同的 Single Sign On (SSO) 域。
- 在将 EJB 搜索应用程序部署到 WebSphere Application Server 时，请将 searchUser 角色映射到 LDAP 中 WebSphere Portal 的管理员用户。
这些操作确保了只有 WebSphere Portal 服务器可以与远程搜索服务器通信，以使它能获取经过安全筛选的结果。
解决服务器重启问题
如果选择使用 EJB 搜索应用程序，在重启远程搜索服务器的同时，还必须重启 WebSphere Portal 服务器。这是由于 APAR PQ83679 中所描述的问题：JAAS 身份验证在 WAS 重启后失效。
要解决这个问题，对 WebSphere Application Server 使用修复后的安全性和 CORBA 端口：
- 首先，关闭 WebSphere_Portal。
- 在远程搜索服务器管理控制台，转到 Application Servers => <Your remote server name> => End Points，并单击 New 按钮。
- 在下拉列表中选择 ORB_LISTENER_ADDRESS，设置服务器地址并设置空闲端口；然后单击 OK。
- 单击 SAS_SSL_SERVERAUTH_LISTENER_ADDRESS，设置服务器地址并设置空闲端口；然后单击 OK。
- 单击 CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS，设置服务器地址并设置空闲端口；然后单击 OK。
- 单击 CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS，设置服务器地址并设置空闲端口。
- 单击 OK => Save。
- 重启 server1。
- 启动 WebSphere_Portal。
从现在开始，应该可以重启远程搜索服务器而不再需要重启 WebSphere Portal。当重启远程搜索服务器时，在访问搜索管理 Portlet 前，需要注销并重新登录。
启动调度程序
如前所述，Portal Search 包括用来启动爬网程序和索引维护处理的调度程序，其中索引维护处理可以删除过时的文档和断开的链接。维护处理是不可配置的，它每隔 24 小时在午夜启动。
当使用本地 Portal Search 时，调度程序作为 WebSphere Portal 启动过程中的一部分启动。当使用远程 Portal Search 时，下面两个过程会启动调度程序：
- 当 WebSphere Portal 服务器启动时，它连接到远程搜索服务器并初始化调度程序。
- 如果在 WebSphere Portal 启动时远程搜索服务器没有运行，或者如果远程搜索服务器已被重启，则不会启动调度程序。因此，已定义的爬网程序和维护处理可能不会运行。为了启动调度程序，管理员只需进入 Manage Search Collections Portlet。然后，WebSphere Portal 将连接到远程搜索服务器并初始化调度程序以实现启动。
安装文档转换服务
如果要索引非文本型的文档，比如 Microsoft® Word 或 Adobe PDF 文档，文档转换服务可以将这些文档转换为适合于解析和索引的格式。Portal Search 文档处理管道假设该服务在本地是可用的。因此，如果使用远程搜索服务器，还需要在远程服务器上安装远程转换服务。不需要将所有的转换任务从 WebSphere Portal 委托给该远程实例。有关安装远程文档转换服务的信息，请参阅 WebSphere Portal InfoCenter 中的 Portal Search => Preparing for remote search service。
使用本地搜索服务
在前面的部分中，我们描述了如何安装并运行远程搜索服务器，它是在集群 WebSphere Portal 环境中推荐的工作方式。然而，对于每一个作为集群的一部分的 WebSphere Portal 服务器，本地搜索服务仍然是可用的。本部分内容解释了能够在水平集群中使用这种本地搜索服务的原因（每一个服务器需要它自己的文件系统）——作为另一种选择——以及这种配置的优点。
其思想是对每一个本地 Portal Search 进行相同的配置，以便任何搜索请求可以由集群中的任何服务器来处理。这种技术的主要缺点是：
- 每一个服务器必须独立地进行配置。
- 每一个服务器上都运行爬网程序和建立维护操作的索引，这将增加系统资源的消耗。
- 在爬网程序运行时，不同搜索源的内容可能会稍微失去同步。
然而从积极的方面来讲，当搜索索引不是频繁进行更新时，使用本地门户搜索服务具有将搜索负载分布到集群节点的优点。同时，如果其中的一个 WebSphere Portal 节点失效（及其 Portal Search），那么剩余节点的搜索服务仍然是可用的。最后，不需要管理其他的搜索服务器。
再次说明，如果每一个 WebSphere Portal 服务器实例都具有自己的非共享的文件系统，那么只能使用这种解决方案，并且每个 WebSphere Portal 节点都可以由管理员通过专门的方式访问。现在让我们看看如何为本地搜索服务器创建集合。
创建集合
要创建一个集合，请执行下列操作：
- 登录到其中一个集群服务器。我们将该服务器称为主服务器。
- 在搜索管理 Portlet 中，创建集合，并配置爬网程序和分类。然后为爬网程序配置调度程序。
- 关闭主服务器。这确保了关闭文件系统中的搜索文件，并且这些文件不会被后续的操作损坏。
- 而对于集群中的每个服务器：
- 关闭服务器。
- 将为搜索集合定义的目录从主服务器复制到该服务器，并使用完全相同的文件系统路径。
- 启动该服务器。
- 启动主服务器。
此时，所有的服务器都具有完全相同的配置。在每个服务器上，调度程序将启动爬网程序，并且将对集合进行更新以使其具有相同的内容。
- 在所有的服务器完成更新后，可以部署搜索和浏览 Portlet 以使其指向该搜索集合。
更新和删除集合
可以通过登录并分别管理每个服务器节点来更新集合。在删除一个集合前，请删除指向将要删除的集合的搜索和浏览 Portlet。
结束语
本文总结了关于在集群中安装 Portal Search 引擎最具挑战性的问题。希望本文可以帮助您更多地了解 Portal Search，并有助于完成管理任务。
致谢
作者要感谢 Andreas Prokoph 提供的有益意见。
参考资料
关于作者  | 
| | David Konopnicki 在位于 Israel Haifa 的 IBM Haifa Lab 工作。他是 Workplace、Portal 和 Collaboration (WPLC) 产品部门中的 Search 团队的技术负责人。 |
对本文的评价
| 
