Cluster Linkを有効にすると、分散キャッシュが自動的に有効になります。キャッシュは、同時に実行されている複数のLiferay DXPノードに分散されます。Cluster LinkはEhcacheの複製を行います。Ehcacheのグローバル設定はportal.propertiesファイルにあります。
デフォルトでは、Liferayはノード間でキャッシュされたエンティティをコピーしません。たとえば、１つのノード上でエンティティが削除または変更された場合、Cluster Link は他のノードに削除メッセージを送信して、ローカルキャッシュ内のこのエンティティを無効にします。別のノードでそのエンティティを要求すると、キャッシュミスが発生します。その後、エンティティはデータベースから取得され、ローカルキャッシュに置かれます。あるノードのローカルキャッシュに追加されたエンティティは、他のノードのローカルキャッシュにはコピーされません。 そのエンティティがキャッシュされていないノードで新しいエンティティを取得しようとすると、キャッシュミスが発生します。ミスにより、ノードはデータベースからエンティティを取得し、それをローカルキャッシュに格納します。
Cluster Linkを有効にするには、以下のプロパティをportal-ext.propertiesに追加します:
cluster.link.enabled=true
Cluster Linkは JGroupsに依存し、APIに通信するノードを提供します。Cluster Linkは、
-
クラスタ内の全てのノードにメッセージ通信できます。
-
特定のノードへメッセージ通信できます。
-
メソッドを呼び出し、全て、一部または特定のノードから値を所得します。
-
新しいノードを検知しノードの参加・離脱通知をします。
クラスタで@ portal @を起動すると、ログファイルのメッセージにクラスタの名前が表示されます（例:cluster=liferay-channel-control）
-------------------------------------------------------------------
GMS: address=oz-52865, cluster=liferay-channel-control, physical address=192.168.1.10:50643
-------------------------------------------------------------------
Cluster Linkはノード間で1対多タイプの通信を提供をする拡張アルゴリズムが含まれています。JGroupsUDP マルチキャストではCluster Linkがデフォルトで実装されていますが、ユニキャストとTCPも利用可能です。
UDPによるマルチキャスト
Cluster Linkを有効にすると、Liferay DXPのデフォルトのクラスタリング設定が有効になります。この設定はUDPを介したIPマルチキャストを定義します。Liferay DXPはこれを行うのに２つのグループのJGroupsチャンネルを使用します。一つはコントロールグループ、二つ目はトランスポートグループです。
チャンネルプロパティーをカスタマイズしたい場合は、portal-ext.properties内で設定します。
cluster.link.channel.name.control=[your control channel name]
cluster.link.channel.properties.control=[your control channel properties]
チャンネルプロパティーについてはJGroupsの資料を参照ください。デフォルト設定は上記で説明したプロパティーを設定します。
マルチキャストはネットワーク上のすべてのデバイスにブロードキャストします。同じネットワーク上のクラスタ環境は、デフォルトで互いに通信します。それらの間で送信されたメッセージおよび情報（例えば、スケジュールされたタスク）は、意図しない結果につながる可能性があります。ネットワーク上で論理的または物理的に分離するか、マルチキャストグループアドレスとポート値の異なるセットを使用するように各クラスタのportal-ext.propertiesを構成することによって、そのようなクラスタ環境を分離します。
JGroupはバインドアドレスを自動で設定します。マニュアルアドレスを設定する場合は、下記を設定します。デフォルト値はlocalhostと設定されています:
cluster.link.bind.addr["cluster-link-control"]=localhost
cluster.link.bind.addr["cluster-link-udp"]=localhost
一部の設定にはlocalhostがホストの実際のアドレスではなく、内部ループバックネットワーク（127.0.0.1または::1)が使用されている場合もあります。何らかの理由でこれらの設定が必要な場合は、以下のプロパティでLiferay DXPに自動で検知させることも可能です。
cluster.link.autodetect.address=www.google.com:80
サーバーから接続可能な他のホストに接続するように設定します。デフォルトではGoogleを指していますが、お使いのサーバーがファイアーウォールの内側にある場合は、この方法が利用できない可能があります。上記のプロパティーでアドレスを設定した場合は、自動検知アドレスを設定する必要はありません。
お使いのネットワークによって、マルチキャストTCPの使用が妨げられる可能性がありますので、下記の設定を使い、クラスターが通信できるようにします。これらの方法は全てJGroups から提供されていますのでご注意ください。
チェックポイント
-
localhost使用せずにIPアドレスをバインドする場合は、これらのプロパティを使用して正しいIPアドレスが宣言されていることを確認してください。`cluster.link.bind.addr["cluster-link-control"]=localhost` `cluster.link.bind.addr["cluster-link-udp"]=localhost` -
負荷テストを実施して、必要に応じて設定を最適化します。
TCPを利用したUNICAST
ネットワーク設定、もしくはノード間の物理距離といった理由から、UDP マルチキャストクラスタ構成を使用できない場合は、TCP ユニキャストが利用できます。ファイアーウォールでノードが分離されている構成や、ノードが地理的に異なる場所に配置されているケースなど特に、TCPユニキャストが必要です。
-
アプリケーションサーバーのJVMにパラメータを追加します。
-Djgroups.bind_addr=[node_address]ノードのIPアドレスを使用します。
-
ノード間で相互に発見できるよう、ディスカバリー・プロトコルを決定します。4つの選択肢があります:
- TCPPing - JDBCPing - S3_Ping - Rackspace_Pingどれを使用すればよいか定かでない時は
TCPPingを使用します。ここで紹介する手順ではTCPPingを使っています。その他の設定は後半で説明しています。 -
LiferayのNexusリポジトリから最新の
com.liferay.portal.cluster.multiple-[version].jarファイルをダウンロードしてください。 このJARのlibフォルダにはjgroups-[version].Final.jarというファイルがあります。 それを開いてtcp.xml見つけてください。このファイルをLiferay DXPにアクセス可能な場所に解凍します。このファイルをすべてのノードで使用してください。 -
垂直クラスタ（例：複数のLiferay DXPサーバーが一つの物理または仮想システムで稼働している）を使用している場合は、TCPポートの衝突を防ぐためにディスカバリポートが最初のノード以外の全ノードに通信するポートを変更してください。この設定は、TCPタグ
bind_portパラメータを調整します:<TCP bind_port="[some unused port]" ... />デフォルトポートが
7800なので、未使用のポートをいくつか用意します。 -
同じタグにパラメータ
singleton_name="liferay_cluster"を追加します。このパラメータはトランスポートを統合し、チャンネルの制御しスレッドプールの数を減らします。詳しくは、 JGroups資料を参照ください。通常、上記以外のJGroups設定は必要ありません。しかし、極めて特殊なケースでクラスターノードが複数ネットワーク上に導入されている場合、ファイアーウォールの外部（公共IP）アドレスにパラメータ
external_addrを各ホストに設定する必要があります。この種の設定は、ノードが物理的に離れている場合に必要です。これを設定することで、個別のネットワークに（ファイアーウォールで分離された）配備されたクラスタのノードが通信できるようになります。このような設定は、システムのセキュリティ監査でフラグされます。詳しくは、JGroups資料を参照ください。 -
ファイルを保存します。そのノードの
portal-ext.propertiesが以下を指すように調節します:cluster.link.channel.properties.control=[CONFIG_FILE_PATH]/tcp.xml cluster.link.channel.properties.transport.0=[CONFIG_FILE_PATH]/tcp.xml
TCPを使ったユニキャストの設定ができました。上記の手順で、他のノードも設定します。
JDBC Ping
TCP Pingを使ってクラスタのメンバーを発見する以外の方法は、セントラルデータベースを全ノードからアクセス可能にし、各ノードを発見させることも可能です。クラスタメンバーは自分自身を書き込み、このデータベースから他のメンバーのアドレスを読み取ります。クラスタ内のノードはこのデータベースに各自アドレスを書き込み、他ノードのアドレスを読み込みます。この設定を有効にするには、TCPPINGタグを、対応するJDBCPINGタグに置き換えます:
<JDBC_PING
connection_url="jdbc:mysql://[DATABASE_IP]/[DATABASE_NAME]?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false"
connection_username="[DATABASE_USER]"
connection_password="[DATABASE_PASSWORD]"
connection_driver="com.mysql.jdbc.Driver"/>
上記の例ではMySQLをデータベースとして使用しています。JDBC Pingの詳細はJGroups資料を参照してください。
S3 Ping
Amazon S3 Pingは、Amazon EC2 クラウドサービス上でサーバーを稼働させている場合に利用できます。 各ノードはS3 バケットに小規模のファイルをアップロードし、他のノードはこのバケットを読み込み他のノードを発見します。ノードが消えると、ファイルが削除されます。
S3 Pingを設定するにはTCPPINGタグを、対応するS3_PINGタグに書き換えます:
<S3_PING
secret_access_key="[SECRETKEY]"
access_key="[ACCESSKEY]"
location="ControlBucket"/>
上記のパラメータの値としてAmazonキーを指定します。 S3 Pingの詳細設定は、JGroups資料を参照してください。
その他のPING
JGroups は、この他にもRackspace Ping、BPing、File Ping等クラスターの発見方法を提供しています。これらのディスカバリーの利用方法の詳細はJGroupsの資料を参照してください。
モジュールを使用したキャッシュ構成の変更
実運用でシステムが処理する必要があるトラフィックの種類の負荷を、最も再現する負荷テストを実施してください。たとえば掲示板上に多くのメッセージが作成されることが予想される場合、負荷テスト用のスクリプトはそれｃを反映するよう作成します。Webコンテンツを主に多く利用する場合は、同じく負荷テストスクリプトにそれが反映されている必要があります。
負荷テストの結果、デフォルトの分散キャッシュ設定がサイトに最適化されていないと分かることもあります。この場合は、設定を自分で調整する必要があります。Liferay DXPのインストールを直接変更することも、各ノードにモジュールをインストールし、クラスタを停止せずに設定を変更することもできます。
プロジェクトを作成することによってこれをできるだけ簡単にしました。プロジェクトをダウンロードして、ワークスペースのしmodulesフォルダにあるLiferay Workspaceに解凍します。キャッシュ設定を上書きするには、Ehcache設定ファイルを1つだけ変更する必要があります。これは、以下のフォルダ構造にあります。
srcmainjavaresourcesehcacheoverride-liferay-multi-vm-clustered.xml
サンプルプロジェクトでは、このファイルにはGroupImplサイトを処理するオブジェクトの設定が含まれています。他のオブジェクトをキャッシュに追加したいと思うかもしれません。実際、デフォルトファイルは他の多くのオブジェクトをキャッシュします。たとえば、活気のあるコミュニティがある場合は、前述のように、トラフィックの大部分がメッセージボードポートレットに向けられることがあります。メッセージボードにスレッドをキャッシュするには、次のMBMessageImplクラスでブロックを設定します。
<cache
eternal="false"
maxElementsInMemory="10000"
name="com.liferay.portlet.messageboards.model.impl.MBMessageImpl"
overflowToDisk="false"
timeToIdleSeconds="600"
>
</cache>
Liferayのクラスタ設定ファイルを抽出して、モジュールプロジェクトに入れることで、デフォルト設定を自分でカスタマイズしながら保持することができます。[Liferay Home]/osgi/portalフォルダ内のcom.liferay.portal.cache.ehcache.impl.jarファイルにあります。 必要なファイルはliferay-multi-vm-clustered.xmlで、com.liferay.portal.cache.ehcache.impl.jarファイル内の/ehcacheフォルダにあります。ファイルを入手したら、上記のファイルの内容をoverride-liferay-multi-vm-clustered.xmlファイルの内容で置き換えます。これで、このデフォルト設定を起点として使用します。
キャッシュに変更を加えたら、ファイルを保存し、モジュールを構築してデプロイすると、カスタマイズした設定でデフォルト設定を上書きします。このように、お客様のサイトで生成されるトラフィックの種類に最適なキャッシュ設定を微調整することができます。キャッシュ設定を変更するためにサーバーを再起動する必要はありません。これは大きな利点ですが、注意が必要です：Ehcacheはキャッシュが生きている間はキャッシュ設定の変更を許可しないので、サーバーの実行中にキャッシュを再設定するとキャッシュがフラッシュされます。