はじめに

IBM® WebSphere® Portal は、コンテンツ・ソースの索引作成とコンテンツの検索を可能にする検索サービスを提供します。ポータル検索を使用すると、システム管理者は、HTTP プロトコルを用いて Web サイトやコンテンツ・リポジトリーをクロールして索引付けするコンテンツ・ソース・クローラーを定義できます。これにより、ポータル・ユーザーは WebSphere Portal によって提供される検索ポートレットを使用して、これらの Web サイトを検索できます。また、ポータル・コンテンツ・ソースを使用して、WebSphere Portal にインストールされている別のポートレットをクロールして索引付けすることもできます。

この記事は WebSphere Portal InfoCenter に代わるものではありません。ここで触れるインストールとメンテナンスの各作業では、InfoCenter を参照しなければなりません。InfoCenter に書かれている手順の背後にある理由を説明しますので、手順をより簡単にマスターしたり、エラーを避けるために役立ちます。

この記事は、WebSphere Portal クラスタリングの基本を理解し (「リソース」参照)、ポータル検索の経験がある方を対象にしています。

次のセクションでは、ポータル検索のアーキテクチャーの概要について解説します。

上に戻る

ポータル検索とは

ポータル検索のアーキテクチャーを理解すると、クラスター環境で正しいトポロジーを構築するために役立ちます。ポータル検索は、3 つのポートレットと 1 つのコア検索サービスによって構成されています。

• 検索管理ポートレットは、ポータル管理者のために、コア検索サービスと通信し、検索コレクション (検索可能な文書のコレクションで、検索索引とも呼ばれます) の作成、コンテンツ・ソース・クローラー (HTTP クローラー) の管理、および分類法の管理を行います。 WebSphere Portal V5.1 InfoCenter および WebSphere Portal インターフェースでは、メインの管理ポートレットは「検索コレクションの管理 (Manage Search Collections)」と呼ばれています。他の 2 つのポートレットは、管理者を対象にしています。「検索とブラウズの管理 (Manage Search and Browse)」はコレクション内の文書の管理を支援し、「保留検索コレクション項目 (Pending Search Collection Items)」は保留文書の管理を支援します。
• 検索とブラウズポートレットは、ポータル・ユーザーがコレクションを照会したり、対応する分類法を参照することを可能にします。
• 汎用の検索センターポートレットは、ポータル検索および文書マネージャ (PDM) の両方を照会する共通のユーザー・インターフェースを提供します。これは、検索とブラウズポートレットと同様に、ポータル検索の検索をコア検索サービスに委任します。

コア検索サービスには、Web とポータル・サイトのクロールに使用されるコンテンツ・ソース・クローラーのセット、コンテンツ・ソース・クローラーが文書の処理に使用する文書処理パイプライン、および全文検索の索引が含まれています。コア検索サービスはスケジューラーを使用して、クローラーの実行や全文索引のメンテナンスなどの定期的なイベントを開始します。パイプラインは、全文索引で索引付けされる前に文書を処理します。また、文書の要約、形式変換、およびカテゴリ化を自動的に行う各サービスも提供します (図 1 参照)。

上に戻る

永続データの場所

クラスター環境でのポータル検索のデプロイメントを理解するには、どの永続データをどこで管理するのかを理解する必要があります。この情報は全体のアーキテクチャーを左右するからです。次のセクションで示すように、コア検索サービスをデプロイするにはいくつかの方法があります。このため、管理ポートレットと照会ポートレットのどちらも、コア検索サービスの場所を指定しなければなりません。

1. 検索管理ポートレットは、自分自身の設定を次の 2 つの場所に保存します。
   • portlet パラメーターは、ポートレットがどのコア検索サービスを管理するのかを定義します。
   • 検索管理ポートレットは WebSphere Portal データベースにアクセスし、このサービスで利用できるコレクションの名前と場所を取得および保存します。
2. 検索とブラウズポートレットはポートレットのパラメーターを使用して、コア検索サービスの場所と照会するコレクションの名前を示します。
3. 検索センターは WebSphere Portal データベースを使用して、コア検索サービスのパラメーターと共に表示するタブの設定を保存します。
4. コア検索サービスは、コレクションの設定と共に全文索引を保存します。これには、コンテンツ・ソースとファイル・システム内の分類法も含まれます。 このことは、クラスター環境のデプロイメントでの最大の制約を表しています。データはファイル・システムに保存されているため、異なる 2 つの JavaTM JVM が同時に 1 つのデータにアクセスすると、破損するおそれがあります。この理由から、コア検索サービスは、ローカル・サービスとリモート・サービスという 2 つの形で提供されています。

上に戻る

ローカル・サービスとリモート・サービスの比較

ローカルのコア検索サービスは、WebSphere Portal のインストール時に自動的にインストールされ、ポータルと同じ JVM で実行されます。クラスター環境では、いくつかの JVM が WebSphere Portal のインスタンスを実行し、これらが 1 つのクラスターを形成しています。これらのすべてのインスタンスは、同じデータベース・データを共有しています。このため、複数の JVM のコア検索サービスがディスク上の同じデータにアクセスすると、データが破損するおそれがあります。

この問題を解決する 1 つの方法は、リモートのコア検索サービスを使用することです。コア検索サービスを WebSphere Application Server にデプロイし、このリモート・サービスにアクセスするよう管理ポートレットと検索ポートレットを設定できます。これにより、クラスターの各ノードはこの共通 JVM にアクセスします。この JVM は検索機能を提供し、ポータル・クラスター内のさまざまなノードから受信した要求を処理します。この JVM だけがディスク上の検索データ構造にアクセスするので、データの破損が避けられます (図 2 参照)。

上に戻る

WebSphere Portal クラスタリングのトポロジーの考察

WebSphere Portal サーバー群をクラスターに組み込む際に、多くのトポロジーが考えられます。クラスタリングについてはこの記事の範囲ではありませんが、垂直クラスターと水平クラスターを区別することが重要です。

• 垂直クラスターでは、そのメンバーは 1 つのノードに存在します。このようなクラスターは、強力なサーバーがあり、その能力を効率よく利用したいときに使用されます。
• 水平クラスターでは、そのメンバーは異なるノードに存在します。このようなクラスターは、ソフトウェアまたはハードウェア障害時の可用性を高めます。

どちらのタイプのクラスターでも、ロード・バランシングによってサーバーのスケーラビリティーが改善されます。垂直クラスターと水平クラスターの組み合わせも可能です。

検索に関しては、垂直クラスターでは異なるノードが共通のディスクを共有するのに対し、水平クラスターでは、通常、各サーバーが専用のディスクを使用する点が大きな違いです。以降の内容では、この違いについて取り上げます。

上に戻る

専用リモート検索サーバーの使用

クラスター環境で推奨されるソリューションは、専用の検索サーバーを使用することです。まず、WebSphere Application Server の 1 つのインスタンスをインストールします。これは、クラスターの一部ではありません。次に、リモート検索サーバー・アプリケーションを SOAP 上の Web サービスとしてデプロイするか、EJB としてデプロイします。

リモート検索サーバー・アプリケーションをクラスター内のノードの 1 つにインストールすることもできますが (server1 などの別の WebSphere Application Server プロセスを使用する)、ポータル・ノードと検索サーバーがリソースを奪い合う可能性があります。このため、負荷分散と安定性の理由により、専用の WebSphere Application Server ノードにインストールすることを推奨します。

上に戻る

2 つのサービス・アプリケーションでのセキュリティーの考察

2 つのアプリケーションは、検索能力はまったく同じですが、クライアントとサーバー間で使用される通信プロトコルが異なります。SOAP サービスは HTTP を使用し、EJB アプリケーションは IIOP を使用します。このことは、ほとんどのユーザーにとって大きな違いはありません。しかし、企業によっては、セキュリティー上の理由から、社内イントラネットで SOAP の使用を禁止している場合もあります (後述)。

2 つのアプリケーションの大きな違いは、それぞれがサポートするセキュリティー機能にあります。WebSphere Portal V5.1 では、ポータル検索サービスは次に示す 2 つのレベルのセキュリティーをサポートします。

• コレクション・レベルのセキュリティーは、コレクションと権限を持つユーザーを関連付けるために使用されます。権限を持つユーザーだけが、コレクション内を検索できます。
• ポータルのコンテンツ・ソースを使用してポートレットを検索可能にするときに、文書レベルのセキュリティーが使用されます。このメカニズムにより、検索結果をユーザーに提供する前に、ページとポートレットに対する適切な権限がユーザーに与えられます。

この 2 つのセキュリティーのレベルは、EJB アプリケーションと SOAP アプリケーションの両方に適用されます。しかし、SOAP を使用している場合は、悪意のあるユーザーがリモート検索サーバーに接続し (SOAP ポートへの接続)、フィルタリングされていない結果の要求を防げません (リモート Application Server は必要なセキュリティー情報へのアクセス権を持たないので、フィルタリングは WebSphere Portal サーバーで行われます)。このような攻撃は簡単ではありませんが、理論的には可能です。

一方、EJB アプリケーションを使用している場合は、WebSphere Portal とリモート検索サーバー間の通信をセキュアにできるので、リモート検索サーバーは WebSphere Portal からの接続だけを受け入れます。

上に戻る

リモート検索サーバーの使用制限

リモート検索サーバーは、クラスター内に配置できません。このため、次のようなことが生じます。

• リモート検索サーバーは、WebSphere Portal クラスターによるスケーラビリティーの改善による利点を得られません。新しいノードをクラスターに追加しても、検索のキャパシティーは向上しません。
  
  一方、検索用の専用サーバーを使用すると、WebSphere Portal のスケーラビリティーが向上します。専用サーバーによって、ポータルはクローラーの実行と全文索引の更新という作業から解放されます。この 2 つのプロセスは、ネットワークの帯域幅およびディスク I/O の観点では、大きな負荷となります。
• リモート検索サーバーは Single Point of Failure (システム全体の障害につながる単一箇所の障害) になります。ソフトウェアまたはハードウェアの障害によって検索サーバーがダウンすると、ポータル全体で検索機能が使用できません。

1. モニター・ツールを使用します。
2. 2 つの同じリモート検索を異なるノードで設定し、検索管理ポートレットがそれぞれを指すようにします。また、双方への要求を均衡化させるために、ロード・バランサーを設定します。次に、ロード・バランサーと通信するよう検索ポートレットを設定します。このソリューションによって、スケーラビリティーと可用性の両方が改善されます。

上に戻る

いずれかのリモート・サーバー・アプリケーションのインストール

SOAP サービスまたは EJB アプリケーションのいずれかをインストールしデプロイするには、次のように操作します。

• いずれかのアプリケーションを WebSphere Application Server にデプロイします。
• アプリケーションまたはサービスを起動します。
• 前述のように、リモート検索サーバーを指すように検索管理ポートレットと検索とブラウズポートレットを設定します。

詳細については、WebSphere Portal V5.1 InfoCenter のトピック「ポータル検索 => リモート検索サービスの使用」を参照してください。

上に戻る

EJB アプリケーションのセキュリティーの有効化

WebSphere Portal とリモート EJB 検索サーバー間の通信をセキュアにするには、次の手順で操作します。詳細については、WebSphere Portal V5.1 InfoCenter のトピック「ポータル検索 => リモート検索サービスのセキュリティーの準備」を参照してください。

• ポータル・サーバーとリモート検索サーバーで J2EE セキュリティーを有効にし、ユーザーを管理するために両方のサーバーが同じ LDAP サーバーを共有していることを確認します。
• クラスター内のすべてのサーバーが同じシングル・サインオン (SSO) ドメインを共有していることを確認します。
• EJB 検索アプリケーションを WebSphere Application Server にデプロイするときは、LDAP で WebSphere Portal の管理者ユーザーに searchUser 役割を割り当てます。

これらの操作によって WebSphere Portal サーバーだけがリモート検索サーバーと通信できるようになるので、セキュリティーによってフィルタリングされた結果が得られます。

上に戻る

サーバー再起動の問題の解決

EJB 検索アプリケーションの使用を選択し、リモート検索サーバーを再起動するときは、WebSphere Portal サーバーも再起動する必要があります。これは、「APAR PQ83679: JAAS authentication fails after WAS restart」に記載された問題によるものです。

この問題を解決するには、WebSphere Application Server に修正済みのセキュリティーと CORBA ポートを使用します。

1. まず、WebSphere_Portal をシャットダウンします。
2. リモート検索サーバーの管理コンソールで、[Application Servers] - [使用しているリモート・サーバー名] - [End Points] に移動し、[New] ボタンをクリックします。
3. ドロップダウンリストで [ORB_LISTENER_ADDRESS] を選択し、使用するサーバーのアドレスと空きポートを設定します。[OK] をクリックします。
4. [SAS_SSL_SERVERAUTH_LISTENER_ADDRESS] をクリックし、使用するサーバーのアドレスと空きポートを設定します。[OK] をクリックします。
5. [CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS] をクリックし、使用するサーバーのアドレスと空きポートを設定します。[OK] をクリックします。
6. [CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS] をクリックし、使用するサーバーのアドレスと空きポートを設定します。
7. [OK] をクリックし、[Save] をクリックします。
8. server1 を再起動します。
9. WebSphere_Portal を起動します。

これ以降は、WebSphere Portal を再起動せずに、リモート検索サーバーを再起動できます。リモート検索サーバーを再起動するときは、検索管理ポートレットにアクセスする前に、いったんログアウトしてからログインし直してください。

上に戻る

スケジューラーの開始

前述のように、ポータル検索には、クローラーと、古くなった文書および壊れたリンクを削除する索引のメンテナンス・プロセスを開始するスケジューラーが含まれています。メンテナンス・プロセスは設定を変更できず、毎日午前 0 時に実行されます。

ローカルのポータル検索を使用するとき、スケジューラーは WebSphere Portal の起動の一部として開始されます。リモートのポータル検索を使用するときは、次の 2 つの手順によってスケジューラーが開始されます。

• WebSphere Portal サーバーは起動時にリモート検索サーバーに接続し、スケジューラーを初期化します。
• WebSphere Portal の起動時にリモート検索サーバーが実行されていない場合、またはリモート検索サーバーが再起動されている場合、スケジューラーは開始されません。これにより、定義済みのクローラーおよびメンテナンス・プロセスが実行されないことがあります。スケジューラーを開始するには、システム管理者は単に Manage Search Collections ポートレットを入力するだけでかまいません。これにより、WebSphere Portal はリモート検索サーバーに接続し、スケジューラーを初期化して開始します。

上に戻る

Document Conversion Services のセットアップ

Microsoft® Word または Adobe PDF 文書など、テキスト以外の文書を索引付けするときは、Document Conversion Services がこれらの文書を解析および索引作成に適した形式に変換します。ポータル検索の文書処理パイプラインは、このサービスがローカルで利用可能であることを前提としています。このため、リモート検索サーバーを使用するときは、リモートの Document Conversion Services をリモート・サーバーにインストールする必要があります。WebSphere Portal からのすべての変換タスクをこのリモート・インスタンスに委任する必要はありません。リモートの Document Conversion Services をインストールする方法については、WebSphere Portal InfoCenter の「ポータル検索 => リモート検索サービスのセキュリティーの準備」を参照してください。

上に戻る

ローカル検索サービスの使用

前のセクションでは、リモート検索サーバーの設定と実行方法について解説しました。クラスター化された WebSphere Portal 環境では、この方法を使用することが推奨されています。しかし、クラスターを構成する各 WebSphere Portal サーバーでローカル検索サーバーを使用することも、従来どおり可能です。このセクションでは、別の方法として、水平クラスターでこのローカル検索サービスを使用する方法 (各サーバーが固有のファイル・システムを持つことが必要) と、その利点について解説します。

この方法では、クラスター内の任意のサーバーで任意の検索要求を処理できるよう、ローカルの各ポータル検索に同じ設定を行います。この方法の主な短所は次のとおりです。

• 各サーバーを個別に設定しなければならない。
• クローラーと索引のメンテナンス処理が各サーバーで実行されるので、システム・リソースの消費が増加する。
• クローラーが実行されている間に、異なる検索コレクション間で同期が若干ずれることがある。

しかし、長所に目を向けると、検索索引が頻繁に更新されない環境では、ローカルのポータル検索サービスを使用することにより、クラスター・ノード間での検索の負荷が分散される利点が得られます。また、WebSphere Portal の 1 つのノード (および、そのポータル検索) がダウンした場合でも、残りのノードでは検索サービスを利用できます。さらに、専用の検索サーバーを管理する必要もありません。

繰り返しになりますが、各 WebSphere Portal サーバーのインスタンスがそれぞれ固有の非共有ファイル・システムを保持し、システム管理者が各 WebSphere Portal ノードに個別にアクセス可能な場合にのみ、このソリューションを使用できます。次に、ローカル検索サービス用のコレクションを作成する方法について見ていきましょう。

上に戻る

コレクションの作成

コレクションを作成するには

1. クラスター・サーバーの 1 つにログインします。このサーバーをメイン・サーバーと呼びます。
2. search admin ポートレットで、コレクションを作成し、クローラーと分類法を設定します。次に、すべてのクローラーのスケジュールを設定します。
3. メイン・サーバーをシャットダウンします。これにより、ファイル・システム上の検索ファイルが閉じられ、以降の操作で破損されないことが保証されます。
4. クラスター内の各サーバーで、順番に次のように操作します。
   1. サーバーをシャットダウンします。
   2. 検索コレクション用に定義したディレクトリーをメイン・サーバーからこのサーバーにコピーします。このとき、まったく同じファイル・システム・パスを使用します。
   3. サーバーを起動します。
5. メイン・サーバーを起動します。

   この時点で、すべてのサーバーはまったく同じ設定を持っています。各サーバーでスケジューラーがクローラーを起動し、同じ内容を持つようコレクションが更新されます。

6. すべてのサーバーが更新された後、検索コレクションを指すように検索とブラウズポートレットをデプロイすることができます。

上に戻る

コレクションの更新と削除

各サーバー・ノードに個別にログインして管理することにより、コレクションを更新できます。コレクションを削除する前に、削除したいコレクションを指している検索とブラウズポートレットを削除してください。

上に戻る

まとめ

この記事では、ポータル検索エンジンをクラスターにインストールする際の、最も重要な課題について解説しました。この記事が、ポータル検索の概要の理解と、管理作業のお役に立つことを願っています。

上に戻る

謝辞

的確なコメントをくださった Andreas Prokoph 氏に感謝します。

参考文献

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• developerWorks WebSphere Portal zone (US) には、ポータルおよびポートレットの開発を支援する幅広い技術リソースがあります。
  
  
• 『A step-by-step guide to configuring a WebSphere Portal V5.1.0.1 cluster using WebSphere Application Server V6.0.0.2』(US) では、ポータル・クラスターの作成方法が解説されています。
  
  
• WebSphere Portal 製品のマニュアル (US) には、InfoCenter、リリース情報、WebSphere Portal の各リリース向けの readme など、現在の製品で利用できるすべてのマニュアルが含まれています。
  
  

著者について

David Konopnicki works in the IBM Haifa Lab in Haifa, Israel. He is the technical lead of the Search team in the Workplace, Portal, and Collaboration (WPLC) products division.

この記事を評価する

コメント

上に戻る

目次

• はじめに
• ポータル検索とは
• 永続データの場所
• ローカル・サービスとリモート・サービスの比較
• WebSphere Portal クラスタリングのトポロジーの考察
• 専用リモート検索サーバーの使用
• 2 つのサービス・アプリケーションでのセキュリティーの考察
• リモート検索サーバーの使用制限
• いずれかのリモート・サーバー・アプリケーションのインストール
• EJB アプリケーションのセキュリティーの有効化
• サーバー再起動の問題の解決
• スケジューラーの開始
• Document Conversion Services のセットアップ
• ローカル検索サービスの使用
• コレクションの作成
• コレクションの更新と削除
• まとめ
• 謝辞
• 参考文献
• 著者について
• コメント