Luxorの主な機能

ホットスタンバイ冗長構成

Ver.1.3.4より、ホットスタンバイ冗長構成機能に対応しています。
ホットスタンバイ冗長構成を設定すると、プライマリサーバに障害が発生した場合、セカンダリサーバへ自動的に処理を引き継ぐことにより稼働状態を維持します。プライマリサーバが復旧すると、自動的に本来の稼働サーバ・待機サーバの構成へ戻ります。Luxorにおけるホットスタンバイ冗長構成は複数のLuxorサーバが相互に排他ロックの獲得を行い、ロックの獲得に成功したサーバが稼働サーバとなり、インデックスの作成やインデックスの検索を行うことにより実現しています。

INSUITEやSm@rtDBからLuxorへのリクエストはロードバランサ等の上位のネットワーク機器にて死活監視を行い、切り替えを行う必要があります。

なお、ホットスタンバイ冗長構成は負荷分散が目的ではありません。現状Luxorは複数サーバによる負荷分散には対応しておりません。詳しくは、下記の「図 Luxorサーバ冗長構成の設定例」を参照してください。

※インデックスの更新処理は、プライマリ/セカンダリのどちらでも実行可能です。並行稼働ではなく、どちらか一方のみの稼働となります。
※セカンダリサーバを複数構築することは可能ですが、起動可能なセカンダリサーバは一台のみです。

図 Luxorサーバ冗長構成の設定例

Luxorサーバ冗長構成の設定例

冗長構成の設定流れ

ホットスタンバイ冗長構成の詳細設定を説明します。次にまとめた流れを参照し、必要となる手順を確認してください。

1	各サーバの準備
2	各サーバのサービス停止 Luxor、INSUITE®、Sm@rtDBサービスを停止する
3	Luxorの設定 luxor.xml、setup.conf設定ファイルの指定
4	Luxor LB経由の設定冗長化構成の必須設定。死活監視用
5	INSUITE®の設定
6	Sm@rtDBの設定
7	サーバの再起動・その他の注意事項

各サーバの準備

「Luxorサーバ冗長構成の設定例」内のサーバをそれぞれ用意しておきます。その中のNFSサーバに関しては、次の説明を参照してください。

ロックディレクトリをNFSへ共有：

冗長構成の場合に、必ず各Luxorサーバにてロックディレクトリ/var/solr/failoverをNFSで共有されている状態にしていただく必要となります。インデックス作成するためのLuxorサーバ間の排他ロックはファイルで実現します。デフォルトのロックディレクトリは/var/solr/failoverです。

インデックス領域をNFSへ共有：

Luxorサーバを複数台準備する際、NFSサーバ上にインデックス領域を用意し、各サーバのインデックス領域/var/solrをNFSで共有しておくことが一般的な運用となります。NFSへの保存方法については、「Luxorインストール作業の流れ」より参照可能です。

Luxorの設定

Luxorの設定において、luxor.xmlは、setup.confの設定を反映するファイルとなりますので、setup.confの設定値に準じます。冗長化設定以外の設定値は手動変更しないでください。ここでは、主に冗長化設定について説明します。

設定ファイル：var/solr/luxor.xml
親要素：config

要素名称	初期値	説明
failover.servers	無し	設定値：＜servername\|IPAddr＞＜PRIMARY\|SECONDARY\|OFF＞・＜servername\|IPAddr＞は、LuxorサーバのIPを指定。 ※PRIMARYにて1つのみ設定可。 ※SECONDARYとOFFの場合、複数設定可。IP間はカンマ区切り。・＜PRIMARY\|SECONDARY\|OFF＞ホットスタンバイ冗長構成における本サーバの役割を指定。 PRIMARY: 正常時に処理を行うプライマリサーバ。全Luxorサーバで一台のみ設定可。 SECONDARY: プライマリサーバに異常が発生した場合に処理を行うセカンダリサーバ。複数設定可。※SECONDARYモードではインデックスのOptimizeは行われない。 OFF: セカンダリサーバの一種、インデックス作成は行わない。複数設定可。 ※フェイルオーバーのサーバとして使用するのは相応しくないサーバ。Luxorクライアントの検索とインデックス作成リクエストは受け付けるが、インデックス更新は行わない。 ※サーバ名、またはIPアドレスの記述が間違った時、自動的にOFFモードに切り替える。ログメッセージにはこのサーバの名とIPアドレスをWARNレベルで出力する。
failover.lock-dir	/var/solr/failover	サーバ間での排他制御に使用するロックディレクトリのフルパス。ホットスタンバイ冗長構成にするには、このロックディレクトリを各サーバで共有必須。
failover.idle-interval	30（秒）	キューが空の状態において、キューをチェックする時間間隔。
ailover.busy-interval-mills	10（ミリ秒）	キューが空でない状態において、PRIMARYに指定されたサーバがキューをチェックする時間間隔。インデックスの検索と作成の間に、CPU、IOなどのリソース配分の優先順位を調整するためのパラメータ。このパラメータはPRIMARYに指定されたサーバにのみ適用される。
failover.secondary-busy-interval-mills	500（ミリ秒）	キューが空でない状態において、SECONDARYに指定されたサーバがキューをチェックする時間間隔。フェイルバックする際の大事な遅延間隔となる。NFS上に置いてある排他ロック取得には時間がかかる予想だが、500以上に設定することを推奨。500ミリ秒以下に設定する場合、フェイルバックに失敗する可能性が高くなるため500以上を指定してください。

設定例：

<config> <failover> <servers> luxor1server PRIMARY, luxor2server SECONDARY, luxor3server SECONDARY, luxor4server OFF </servers> </failover> </config>
注意事項：

ホットスダンバイ冗長構成時、setup.confの設定で下記設定が必要となります。
- lockType=native
- jmx=off（設定必須）
※Luxorのインストール、バージョンアップ時に、setup.confにて上記のパラメータ設定にしてください。JMXのデフォルト値はOFFとなっていますが、運用中ONに設定される可能性があります。JMXをOFFにしないと冗長構成時の切り替えが正常に動作しませんので、Luxor Ver1.3.4以降のバージョンにて利用する際、必ず「jmx=off」へ書き換えてください。setup.confの詳細については、「Luxorのサーバ」の記載より参照してください。

Luxor LB経由の設定

冗長化構成にする場合、ロードバランサ側で死活監視を行う必要があるため、各サーバともロードバランサ経由にすることが必須です。ApacheをLBサーバにする際の設定例を説明します。

プライマリサーバ 10.0.6.A

セカンダリサーバ 10.0.6.B

Luxor LBサーバ 10.0.6.C

上記構成の場合を前提とする場合、Luxor LBサーバ10.0.6.Cにアクセスし、設定ファイル/opt/apache2/conf/httpd.confを開き、次の内容を追記します。

  設定例（Apache2.2）：<br>
  LoadModule proxy_module modules/mod_proxy.so <br>
  LoadModule proxy_balancer_module modules/mod_proxy_balancer.so <br>
  LoadModule proxy_http_module modules/mod_proxy_http.so<br>
  …　…<br>
  …　…<br>
  ProxyPass /solr/ balancer://hotstandby/<br>
  <Proxy balancer://hotstandby/><br>
     BalancerMember http://10.0.6.A:10080/solr/<br>
     # The below is the hot standby<br>
     BalancerMember http://10.0.6.B:10080/solr/ status=+H <br>
  </Proxy><br>

    ※status=+Hは、ホットスダンバイのサーバの指定となります。

INSUITE®の設定

luxor_domain (LuxorサーバIPではなく、Luxor LBサーバのIPを指定。)

luxor_allow_ip (LuxorサーバIP。複数台の場合、すべてのLuxorサーバIPを指定。)

※Luxorサーバ指定の場合はカンマ区切り。詳細の設定については、domain.datの説明を参照してください。

Sm@rtDBの設定

下記のLuxorサーバへの認証情報にて、APサーバではなく、Luxor LBサーバのIPアドレス或いはドメイン名を指定してください。

親要素: default-values.system.fullTextSearch.luxor.server
要素名称: contextUrl
指定値: Luxor LBのIPアドレス或いはドメイン名
注意事項:

[注意事項1]ホットスダンバイ冗長構成時、Tomcatの起動・停止順

PRIMARY、SECONDARYを指定した場合、フェイルオーバー、フェイルバックが実行される事を防止するため、サーバのTomcat起動・停止順は、以下のようにすることを推奨します。

サーバの起動：PRIMARY → SECONDARY
サーバの停止：SECONDARY → PRIMARY

[注意事項2]インデックス作成実行しているサーバの突然停止

インデックス作成を実行しているサーバが電源断等により突然停止すると、Luxorの内部で使用しているロックファイルwrite.lockが残ることがあり、これが原因でそれ以降のインデックス作成・更新処理が実行されずキューに貯まりつづける事があります。この現象が発生すると、インデックス作成・更新処理が停止した以降のデータが検索結果に反映しません。
 現象の監視方法：Luxorのログファイル/var/log/solr/solr.logに以下のようなエラーが出力されます。

  YYYY-MM-dd HH:mm:ss,xxx ERROR common.SolrException (SolrException.java:151) 
  org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: 
  SimpleFSLock@/var/solr/smartdb/document_item/data/index/write.lock

 "org.apache.lucene.store.LockObtainFailedException" 及び "write.lock" を監視することでこの現象の発生を検出する事ができます。

 現象の解消方法：以下の例のような手順でwrite.lockファイルを削除します。

  # touch /var/solr/failover/option.lock
  # find /var/solr -name write.lock              ※ファイルの存在をチェック
  # find /var/solr -name write.lock | xargs rm   ※対象ファイルを削除
  # rm -f /var/solr/failover/option.lock

ホットスタンバイ冗長構成に関する既知問題

オプティマイズ処理中にTomcatが停止された場合の制限事項
プライマリサーバで定期的に実行されるオプティマイズ処理中にプライマリサーバのTomcatが停止された場合、以下の制限事項があります。

[1]プライマリサーバのログファイル/var/log/solr/solr.logに以下のようなエラーが出力され、オプティマイズ処理が中断した状態になる可能性があります。
　※必ず再現するわけではありませんが、発生した場合はTomcat再起動で復旧します。

YYYY-MM-dd HH:mm:ss,xxx ERROR common.SolrException (SolrException.java:151) org.apache.lucene.util.ThreadInterruptedException: java.lang.InterruptedException

[2]冗長構成では 1.の現象が発生した後セカンダリサーバへフェイルオーバーしますが、フェイルオーバー後にセカンダリサーバへ検索リクエストが送信されると、セカンダリサーバでの検索結果が空で返され、かつセカンダリサーバのログファイル（/var/log/solr/solr.log）に以下のようなエラーが出力される可能性があります。 ※必ず再現するわけではありませんが、このエラーが発生した場合はその直後にセカンダリサーバのリロードが自動実行され、次の検索時には正常に検索結果を返します。

YYYY-MM-dd HH:mm:ss,xxx ERROR common.SolrException (SolrException.java:151) java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code

アクティブではないセカンダリサーバにリクエストが送信された場合の制限事項
ロードバランサの動作により、プライマリサーバがアクティブな状態のままセカンダリサーバへリクエストが送信された場合、以下の制限事項があります。

[1] 冗長構成であっても、アクティブ（処理が実行される）になるサーバは１台のみで、複数台が同時にアクティブになることはありません。インデックス作成・更新リクエストをセカンダリサーバへ送信しても、インデックス処理自体はプライマリで実行されます。

[2] 検索リクエストにとっても同様に、検索対象が、セカンダリサーバのTomcatが前回再起動した時点のデータとなり、再起動以降のデータは含まれません。検索結果の差分に関しては、プライマリサーバのLuxorポートが応答しなくなった時点で、リクエストの振り先をセカンダリサーバへ切り替える必要があります。

精度向上

従来のインデックス作成では、アルファベットと文字・数字を組み合わせたキーワードでは検索してもヒットしません。Luxor Ver1.3.6にて検索機能向上の対応として、従来のインデックスを補強する新たなスキーマを追加することで、INSUITE®とSm@rtDBのデータに対する検索精度の高いインデックスの作成方法を実現しています。
新スキーマを使用した場合、下記のキーワードの組み合わせが検索可能となります。

アルファベットと文字の組み合わせ
アルファベットと数字の組み合わせ

精度向上の設定

アルファベットと文字・数字の組み合わせがヒットしない現状を改善するため、Lucene/Solrを構成するもののひとつであるトークナイザーの改良を実施し、新たなスキーマとして追加しています。INSUITE®、Sm@rtDBとも新スキーマの利用が可能です。

Luxor.1.3.6以降のバージョンを新規インストールする場合、新スキーマがデフォルトとなりますので、そのまま精度向上機能が利用可能です。
Luxor.1.3.6以降のバージョンへバージョンアップする場合、データのインデックスが従来のままとなりますので、アルファベットと文字・数字の組み合わせはヒットしません。バージョンアップ後、インデックスの再作成が必要です。
従来のスキーマを利用し続ける場合、setup.shを実行する前にsetup.confのスキーマを変更する必要があります。

設定ファイル：setup.conf
ファイルパス：/root/luxor.1.3.8/setup.conf

※Ver.1.3.8の場合のパスを例にしています。各リビジョンに合わせ、読み替えてください。

パラメータ名	初期値	説明
schemaISEVer	v2	INSUITE®のインデックス作成にて新スキーマを利用するかの設定。 v1:新スキーマを利用しない。インデックス作成規則は従来のまま。 v2:新スキーマを利用する。
schemaSDBVer	v2	Sm@rtDBのインデックス作成にて新スキーマを利用するかの設定。 v1:新スキーマを利用しない。インデックス作成規則は従来のまま。 v2:新スキーマを利用する。

※ 精度向上機能についてINSUITE®とSm@rtDBで設定を揃える必要はありませんが、設定が異なる場合、検索結果に違いが出る可能性があります。

精度向上検索キーワード例

[1]検索キーワード：「Oracleユーザでログインする」

検索精度向上オプションを使用しない場合（V1）：

Oracle ユーーザザででロロググイインンすする

検索精度向上オプションを使用場合（V2）：

Oracle Oracleユユユーーザザででロロググイインンすする

[2]検索キーワード：「よく使う機能TOP10」

検索精度向上オプションを使用しない場合（V1）：

よく　く使　使う　う機　機能　TOP　10

検索精度向上オプションを使用場合（V2）：

よく　く使　使う　う機　機能　能　能TOP　TOP　10

精度向上機能利用時の注意点

INSUITE®とSm@rtDBでは、必ず両方を新スキーマに設定することは必須ではありませんが、片方のみの新スキーマ設定である場合、インデックスが作られる際の分割は違うため、検索結果が異なってくる可能性があります。
Luxor Ver1.3.6以降にバージョンアップし、検索精度向上機能を利用する場合、必ずインデックス再作成を実施してください。

精度向上機能に関連するQ＆A

Q:「検索精度向上オプション」が正常に動作しているかはどう判断すればいいですか？

A:任意機能にてテストデータを登録し、検索結果にて該当データがヒットするかを確認することで判断できます。

確認手順
1.スケジュール機能にて、タイトルが"C非公開"のテストデータを登録しておきます。
2."C非"をキーワードとして検索し、該当のスケジュールがヒットする場合、検索精度向上オプションが利用中であることが判断できます。

Q:Luxor Ver1.3.6以降にバージョンアップ後、デフォルトで検索精度向上オプションが利用になります。インデックスを再作成しなかった場合にどんな問題が発生しますか？

A:Luxorをバージョンアップする場合、旧データのインデックスの作られ方と新スキーマ追加後のインデックス作られ方は異なりますので、インデックス再作成を行わずに利用する場合、既存のインデックスを検索してもヒットしないため検索精度は向上しません。

最適化処理

インデックスの登録/更新や削除の操作を確定して検索結果に反映させるには、コミットが必要です。コミットを繰り返してインデックスが複数のセグメントに分割されると、検索性能が低下してしまいます。そのため、適宜インデックスを最適化する操作が必要となります。

最適化処理の設定

そもそも、最適化処理（オプティマイズ機能）は、Solr側が用意している機能となります。Luxorでは、Solr側の最適化処理に対して、インデックスの更新・削除後、最適化処理を実施するまでの間隔時間を指定することで、最適化処理の自動実施する仕組みを対応しています。
Luxorインデックス最適化処理のデフォルトは、インデックスの更新発生後の30分経過後に自動で実行されます。

設定ファイル：setup.conf
ファイルパス：/root/luxor.1.3.8/setup.conf

※Ver.1.3.8の場合のパスを例にしています。各リビジョンに合わせ、読み替えてください。

パラメータ名	初期値	説明
optimizeInterval	1800（秒）	インデックス更新・削除後、自動オプティマイズを実施するまでの間隔を指定する。・初期値の1800（秒）では、インデックスの更新（削除）発生後、30分経過後に自動で最適化を実施する。・自動最適化の処理を停止する場合、"0"を指定する。・値が大きいと、オプティマイズによるサーバ負荷は軽減できるが、オプティマイズしないままでは検索パフォーマンスは劣化する。

従来solr側の最適化処理

自動最適化処理設定パラメータoptimizeIntervalを"0"に設定することより自動最適化処理を停止する場合、Solr側自身の最適化処理を手動で実施することも可能です。
手動で最適化を行うには、Luxorサーバにて下記コマンドを実行します（定期処理コマンドcronにより、夜間バッチで実行する運用も可能です）。

# curl "http://＜LuxorサーバのIPアドレス＞:10080/solr/＜core名＞/update?optimize=true"

また、Curlコマンドの代わりにブラウザのアドレスバーに下記のURLを指定しても良いです。

http://＜LuxorサーバのIPアドレス＞:10080/solr/＜core名＞/update?optimize=true

※core名とは、INSUITE®やSma@rtDBの機能毎に分かれている設定やインデックスの保持を行う単位のことです。詳しくは、「Luxor管理画面の情報」の記載を参照してください。

最適化処理の注意点

最適化コマンドの実行時、Luxorサーバの物理メモリ使用率は高くなります。また、ディスク容量はインデックスサイズの二倍以上のサイズが必要となります。大量の更新が発生する重い処理であることを事前に把握し、実のタイミングを見計らってください。
長期にわたって最適化処理を行わない場合、検索速度の劣化やOSのファイルディスクリプタ制限への抵触などの問題が発生する恐れがあります。
最適化処理は、ディスク上のインデックスサイズ肥大化を改善することで検索性能向上へとつなげる仕組みとなります。インデックス自身の不整合問題は解決できません。

最適化処理に関連するQ＆A

Q:最適化処理が終了したかどうか確認する方法。

A:Luxor Ver.2.0.3以降のAbout画面にて最適化処理のステータスを確認出来ますが、Luxor Ver.1.X系では、対応していない現状です。