多くの企業環境では、スケーラビリティと可用性の両方の観点からクラスタリングが活用されています。 この記事では、既存のクラスタ環境に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 以上でのみ利用可能です。
解像度
完全なクラスタ環境を構築する場合：
- クラスタ活性化キーは各ノードに配備する必要があります。
- すべてのノードが同じLiferayデータベースまたはデータベースクラスタを指しています。
- Documents and Media repositoriesは、クラスタの全ノードからアクセス可能です。
- 検索インデックスは、レプリケーションのために構成されるか、別の検索サーバーを使用します。
- キャッシュを配布しています。
- サーバーファームを使用しない場合は、各ノードにホットデプロイフォルダが設定されます。
クラスター起動キー
Liferay Portalを正常に動作させるためには、クラスタ内の各ノードにクラスタアクティベーションキーを配備する必要があります。 Cluster Activation Keyの入手方法については、以下のリンクをクリックしてください。
さらに、クラスタアクティベーションキーが動作するためには、クラスタリンクが有効である必要があります。 そのためには、 portal-ext.propertiesで以下を設定します : cluster.link.enabled=true
データベース
すべてのノードが同じLiferayデータベースを指していることを確認します。 portal-ext.properties から、または直接アプリケーションサーバー上でJDBCを設定します。
テストに：
- 両方のTomcats（ノード1、2）をスタートさせる 順次. 理由は、Quartz Schedulerがマスターノードを選出できるようにするためです！
- ログインして、Node 1にポートレット（例：Hello Velocity）を追加します。
- Node 2で、ページをリフレッシュします。
追加されたものはNode 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を参照する際に、互いに同じプロパティを反映させる必要があります。 そうでない場合、各ノードが別々のDocument Libraryリポジトリを参照している場合、データの破損やインデックスの問題が発生する可能性があります。
テストに：
- Node 1で、ドキュメント・ライブラリにドキュメントをアップロードします。
- Node 2で、ドキュメントをダウンロードする。
成功すると、ドキュメントがダウンロードされるはずです。 ノードを逆にして繰り返します。
注1） Advanced File System Storeは、高可用性環境において利用可能なオプションです。 Advanced File System Storeの他にも、ドキュメントとメディアライブラリの共有オプションがあります。 異なるタイプのファイルストアは互いに通信できないため、一方から他方に変更すると、ポータルが以前にアップロードしたファイルを読めなくなることに留意してください。 ストアの種類を変更し、以前にアップロードしたファイルを保持する必要がある場合は、ファイルストア移行を実行します。
注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で、 コントロールパネル -> ユーザー にアクセスし、新しいユーザーを作成します。
- ノード 2 で、 コントロールパネル -> ユーザーにアクセスします。 新しいユーザーが作成されたことを確認する
成功すれば、インデックスを再作成する必要なく、新しいユーザーがもう一方のノードに表示されます。 ノードを逆にして、同じテストを行う。
注1） Solrは、インデックスが企業専用の検索エンジンとサーバーに配置されることになるため、インデックス共有のオプションとなります。 この場合、 lucene.replicate.write=true プロパティは使用しない方が良いでしょう。
注2） デフォルトで Liferay はインデックスエンジンとして Lucene を使用します。 portal-ext.properties ## Lucene Search セクションでは、多くの高度な設定を行うことができます。 最適なオプションを選択してください。 高度な設定については、 Lucene's Performance documentationを参照してください。
分散型キャッシング
分散キャッシングにより、LiferayクラスタはEhcacheを介して複数のクラスタノード間でキャッシュコンテンツを共有することができます。
デフォルトのLiferayクラスタリンク機構を有効にするには、以下のポータルプロパティを有効にし、Ehcache Cluster Web Plugin（ Liferay Marketplaceで入手可能）をデプロイすることで実現します。
ehcache.cluster.link.replication.enabled=true
Liferay には Managing Liferay Portal's Distributed Cacheという特定の記事があります。
ユニキャストクラスタリングの利用を検討されている場合は、以下の点にご注意ください：Liferay Portal は、Liferay Portal 6.1 EE GA3 SP1 以上の jgroups.jar バージョン 3.2.10 を使用します。 その前のLiferay Portalのバージョン 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 の知識ベース記事をご覧ください。
ホットデプロイフォルダ
デフォルトでは、すべてのデプロイ可能なプラグインは、すべてのノードに別々にデプロイする必要があることに留意してください。
しかし、どのアプリケーションサーバーも「サーバーファーム」を構成する方法があり、ある場所にデプロイするとすべてのノードにデプロイされるようになっています。 手順については、各アプリケーションサーバーのドキュメントを参照してください。
その他、確認すべき事項
一部のOSでは、IPv4とIPv6のアドレスが混在しているため、クラスタリングは機能しません。 これを解決するには、次のJVM起動パラメータを追加します。 -Djava.net.preferIPv4Stack=true.
PropertySettingJobFactory の WARN メッセージがログにいくつか表示されることがあります。 Liferayはデフォルトで、QuartzSchedulerEngineクラス内のJobDataMapに情報を保存します。 しかし、 org.quartz.simpl.PropertySettingJobFactory内では、フィールドのみが期待されています。 警告メッセージを解決するには、クラスのロギングレベルをERRORレベルに設定する必要があります。