クラスタ環境へのLiferayポータルのインストール

多くの企業環境では、スケーラビリティと可用性の両方のためにクラスタリングを利用しています。 この記事では、既存のクラスター化された環境にLiferay Portalの基本構成をインストールするための具体的な手順を説明します。

よくある誤解は、Liferay Portalを設定することで、高可用性/クラスタ化された環境が自動的に作成されるというものです。 しかし、定義上、クラスター化された環境には、ロードバランサ、クラスター化されたアプリケーションサーバ、およびデータベースが含まれます。 クラスタ化された環境を設定すると、Liferay Portalをその環境にインストールすることができます。 この記事では、 ユーザーガイド のLiferay Clusteringセクションを拡張し、さらなる指示を与えています。

また、ユーザーはクラスタがマルチキャスト設定を使用しているかユニキャスト設定を使用しているかを判断することができます。 デフォルトでは、Liferay Portal はマルチキャスト・クラスタリングを使用します。 portal-ext.propertiesで、ユーザーはマルチキャストポート番号を変更して、他のインスタンスを実行しているインスタンスと競合しないようにすることができます。 ユーザーがユニキャスト・クラスタを使用することを決定した場合、ユーザーはLiferayがサポートするいくつかのオプションを利用できます。TCP、Amazon S3、File Ping、JDBC Pingです。 最後のオプション-JDBC Ping-は、Liferay Portal 6.2.x EE 以降でのみ利用可能です。

決議

完全にクラスタ化された環境を設定するには

  1. クラスタ起動キーは各ノードに配置する必要があります。
  2. すべてのノードが同じLiferayデータベースまたはデータベースクラスタを指しています。
  3. ドキュメントとメディアのリポジトリは、クラスタのすべてのノードからアクセス可能です。
  4. 検索インデックスはレプリケーション用に設定するか、別の検索サーバーを使用します。
  5. キャッシュが分散されています。
  6. サーバーファームを使用していない場合は、各ノードにホットデプロイフォルダを設定します。

クラスター活性化キー

クラスタ内の各ノードには、Liferay Portal を適切に実行するためのクラスタ・アクティベーション・キーが配備されている必要があります。 クラスタ活性化キーの取得については、以下のリンクをクリックしてください。

さらに、クラスタ起動キーが動作するためには、クラスタリンクが有効になっている必要があります。 これを行うには、 portal-ext.properties: cluster.link.enabled=trueで以下のように設定します。

データベース

すべてのノードが同じLiferayデータベースを指していることを確認します。 portal-ext.properties から、またはアプリケーションサーバ上で直接JDBCを設定します。

テストするために。

  1. 両方のトムキャット(ノード1と2)を起動する 順次. 理由は、Quartz Schedulerがマスターノードを選択できるようにするためです!
  2. ログインして、ポートレット(Hello Velocityなど)をNode 1に追加します。
  3. ノード2では、ページを更新します。

ノード2に追加が表示されるはずです。 他のノードをテストするために、ノードを逆にして繰り返します。

ドキュメント・メディアライブラリの共有

以下のプロパティは、特に AdvancedFileSystemStoreで使用するためのものであることに注意してください。

portal-ext.propertiesに以下のように設定します。

6.0.xの場合

dl.hook.file.system.root.dir=

dl.hook.impl=com.liferay.documentlibrary.util.AdvancedFileSystemHook

6.1.x と 6.2.x の場合

dl.store.file.system.root.dir=

dl.store.impl=com.liferay.portlet.documentlibrary.store.AdvancedFileSystemStore

クラスタ内のノードは、ドキュメント・ライブラリを参照する際に、互いに同じプロパティを反映させる必要があります。 そうしないと、各ノードが別々の Document Library リポジトリを参照している場合、データの破損やインデックスの問題が発生する可能性があります。

テストするために。

  1. ノード1で、ドキュメントライブラリにドキュメントをアップロードします。
  2. ノード2では、ドキュメントをダウンロードします。

成功すれば、ドキュメントがダウンロードされるはずです。 ノードを逆にして繰り返します。

注1: Advanced File System Storeは、高可用性環境で利用可能なオプションです。 高度なファイルシステムストア以外にも、ドキュメントとメディアライブラリを共有するオプションがあります。 ファイルストアの種類が違うとお互いに通信できないので、1つから他のものに変更すると、ポータルが以前にアップロードされたファイルを読むことができなくなることを覚えておいてください。 ユーザーがストアの種類を変更し、以前にアップロードしたファイルを保存する必要がある場合は、ファイルストアの移行を実行します。

注2: ドキュメントをファイルシステムに保存することができない場合は、6.1.x以降では、以下のポータルプロパティを使用してDBStoreの保存方法が利用できます。 dl.store.impl=com.liferay.portlet.documentlibrary.store.DBStore

注3: データベース上のJCRStoreも選択肢の一つです。 Jackrabbitは独自のテーブルにインデックスを作成しないため、時間が経つとこれがパフォーマンスのペナルティになる可能性があります。 ユーザーは、すべてのJackrabbitテーブルの主キー列のインデックスを手動で変更する必要があります。 他にも注意すべき設定として、データベースへの接続量の制限があります。

注4: データベースへの接続数も要因の一つです。 アプリケーションサーバーへのデータベース接続数を増やすことを検討してください。

注5: 各タイプのファイルストアの詳細な説明については、『 管理者ガイド for Liferay Portal 6.0.x』(354ページ)を参照してください。 Liferay Portal 6.2.x Clustering ドキュメントや Guide for Document and Media Library の記事も参照してください。

検索とインデックス共有

portal-ext.propertiesで以下のように設定します。

lucene.replicate.write=true

各ノードは、クラスタ内の他のノードと同期する必要のあるローカルインデックスを保持します。 上記2つのプロパティは、すべてのノードに設定する必要があります。

テストするために。

  1. ノード1で、 コントロールパネル-> ユーザー に移動し、新しいユーザーを作成します。
  2. ノード 2 で、 コントロールパネル -> ユーザーに移動します。 新しいユーザーが作成されたことを確認します。

成功した場合、新しいユーザーは再インデックス化する必要なく他のノードに表示されます。 ノードを逆にして同じテストを行います。

注1: Solrは、インデックスをエンタープライズ専用の検索エンジンとサーバーに置くことになるので、インデックス共有のオプションです。 この場合、 lucene.replicate.write=true プロパティは使用すべきではありません。

注2: デフォルトではLiferayはインデックスエンジンとしてLuceneを使用しています。 portal-ext.properties ## Lucene Search セクションでは多くの高度な設定が可能です。 最適なオプションを選択してください。 高度な設定については、 Lucene のパフォーマンスに関するドキュメントを参照してください。

分散キャッシング

分散キャッシュにより、LiferayクラスタはEhcacheを介して複数のクラスタノード間でキャッシュコンテンツを共有することができます。

デフォルトのLiferayクラスタリンクメカニズムを有効にするには、次のポータルプロパティを有効にし、EhcacheクラスタWebプラグインを配置します( Liferay Marketplaceで利用可能)。

ehcache.cluster.link.replication.enabled=true

Liferayには、 Liferay Portalの分散キャッシュの管理に関する具体的な記事があります。

ユニキャストクラスタリングの使用を検討している場合は、以下の点に注意してください。Liferay Portalは、Liferay Portal 6.1 EE GA3 SP1以上のjgroups.jarバージョン3.2.10を使用しています。 その前のLiferayポータルのバージョンは jgroups.jar のバージョンは2.8.1です。 2つのバージョンには違いがあるので、チャンネルを設定する際には、適切なバージョンの tcp.xml がベースとして使用されていることを確認してください。

6.0 EE SP2、6.1 EE GA1、6.1 EE GA2などの以前のバージョンのLiferay Portalのユーザーの場合、Ehcacheのデフォルトのキャッシュレプリケーション技術よりもパフォーマンスが向上するため、本番環境でhibernate-cluster.xmlとliferay-multi-vm-clustered.xmlファイルを設定することを強くお勧めします。

注1: Ehcacheには、特定のオブジェクトをキャッシュするためのさまざまな変更があります。 ユーザーは、必要に応じてこれらの設定を調整する必要があります。 キャッシングの設定については、ユーザーガイドの「分散キャッシング」のセクションを参照してください。 高度な最適化と設定については、 の Ehcache ドキュメントを参照してください。

注意 2: Ehcache のデフォルトのキャッシュレプリケーション技術の詳細や、チューニングキャッシュをポータルに展開する方法については、ナレッジベースの記事 Advanced Ehcache Configuration を参照してください。

ホットデプロイフォルダ

デフォルトでは、すべてのデプロイ可能なプラグインはすべてのノードに別々にデプロイされなければならないことに注意してください。

しかし、すべてのアプリケーションサーバは、1 つの場所にデプロイするとすべてのノードへのデプロイが発生するように、「サーバファーム」を設定する方法を持っています。 操作方法は各アプリケーションサーバーの説明書をご覧ください。

その他チェックすべき銘柄

一部のオペレーティングシステムでは、IPv4 と IPv6 アドレスが混在しているため、クラスタリングが機能しません。 これを解決するには、以下のJVM起動パラメータを追加します。 -Djava.net.preferIPv4Stack=true.

いくつかのPropertySettingJobFactoryのWARNメッセージがログに表示されることがあります。 Liferayは、デフォルトではQuartzSchedulerEngineクラス内のJobDataMapに情報を保存します。 ただし、 org.quartz.simpl.PropertySettingJobFactory内のフィールドのみが期待されます。 警告メッセージを解決するには、クラスのロギングレベルを有効にしてERRORレベルに設定する必要があります。

追加情報

この記事は役に立ちましたか?
0人中0人がこの記事が役に立ったと言っています