『Red Hat Data Grid Server Guide』

Red Hat Data Grid 7.3

Red Hat Data Grid 7.3 向け

概要

本ガイドでは、Red Hat Data Grid 7.3 の管理と設定について説明します。

第1章 Red Hat Data Grid Server について

Red Hat Data Grid Server は、HotRod、Memcached、および REST など、さまざまなプロトコルで任意の数のキャッシュをクライアントに公開します。サーバー自体は、WildFly が提供する堅牢な基盤上に構築されるため、管理、設定、データソース、トランザクション、ロギング、セキュリティーなどのサービスを各サブシステムに委譲します。Red Hat Data Grid Server は Red Hat Data Grid と JGroups の最新リリースと密接に関連しているため、これらのコンポーネントを制御するサブシステムが異なるため、新機能が導入され、既存の機能(クロスサイトレプリケーションなど)が変更されます。このため、これらのサブシステムの設定は Red Hat Data Grid Server 固有のスキーマを使用する必要がありますが、ほとんどの場合、設定は交換可能です。詳細は、「設定」のセクションを参照してください。

第2章 はじめに

サーバーの使用を開始するには、Red Hat Data Grid Server ディストリビューションをダウンロードし、これをローカルディレクトリーに展開し、プラットフォームに応じて bin/standalone.sh または bin/standalone.bat スクリプトを使用して起動します。これにより、standalone/configuration/standalone.xml 設定ファイルを使用して単一ノードサーバーが起動し、4 つのエンドポイントがサポートされている各プロトコルに 1 つずつ起動します。これらのエンドポイントにより、Red Hat Data Grid サブシステムで設定されたすべてのキャッシュにアクセスできます(プロトコルの設計により、単一のキャッシュへのアクセスのみを許可する Memcached エンドポイントを除く)。

第3章 操作モード

WildFly のような Red Hat Data Grid Server は、スタンドアロンモードとドメインという 2 つの異なるモードで起動できます。

3.1. スタンドアロンモード

単純な設定の場合、スタンドアロンモードは簡単に始まります。ローカル設定とクラスター化された両方の設定を許可しますが、複数のノードの構成、管理、調整はユーザーの責任から行われるため、単一ノードの実行にのみ推奨されます。たとえば、スタンドアロンサーバーのクラスターにキャッシュを追加する場合、ユーザーは全ノードに個別に設定する必要があります。デフォルトの standalone.xml 設定は JGroups サブシステムを提供しないため、クラスター化モードでは機能しません。代替の設定ファイルを使用してスタンドアロンモードを起動するには、以下のように -c コマンドラインスイッチを使用します。

bin/standalone.sh -c clustered.xml

複数のホストでクラスターモードでサーバーを起動した場合は、UDP マルチキャストを使用して相互に自動的に検出し、クラスターを形成する必要があります。単一ホストで複数のノードを起動するには、以下のように jboss.socket.binding.port-offset プロパティーを使用してポートオフセットを指定し、以下のように各ノードを起動します。

bin/standalone.sh -Djboss.socket.binding.port-offset=100 -Djboss.node.name=nodeA

何らかの理由で UDP マルチキャストを使用できない場合は、TCP 検出を使用できます。TCP ディスカバリーの 設定方法は、以下の JGroups サブシステム 設定セクションを参照してください。

3.2. ドメインモード

サーバークラスターを実行するのに推奨されるドメインモードがあります。これは、すべてが単一の制御ポイントから集中管理できるためです。以下の図は、2 つの物理ホスト(A、B)で実行されている 4 つのサーバーノード(A1、A2、B1、B2)があるドメイン設定の例のトポロジーについて説明しています。

図3.1 domain-mode

3.2.1. ホスト

上図の各「ホスト」ボックスは、物理ホストまたは仮想ホストを表します。物理ホストには、ゼロ、1 つまたは複数のサーバーインスタンスを含めることができます。

3.2.1.1. ホストコントローラー

domain.sh または domain.bat スクリプトがホストで実行されると、ホストコントローラーとして知られるプロセスが起動します。ホストコントローラーはサーバー管理のみに関連しており、Red Hat Data Grid サーバーのワークロードを処理するわけではありません。ホストコントローラーは、ホスト上で実行される個々の Red Hat Data Grid サーバープロセスを開始および停止し、ドメインコントローラーと対話してそれらを管理できるようにします。

デフォルトでは、各ホストコントローラーは、ホストのファイルシステム上の Red Hat Data Grid Server インストールにある domain/configuration/host.xml ファイルから設定を読み取ります。host.xml ファイルには、特定のホストに固有の設定情報が含まれます。主な変更点:

  • このインストールから実行する予定の実際の Red Hat Data Grid Server インスタンスの名前の一覧です。
  • ホストコントローラーがドメインコントローラーと通信し、それ自体を登録してドメイン設定にアクセスする方法の設定。これは、リモートドメインコントローラーを検索して問い合わせする方法の設定、またはホストコントローラー自体がドメインコントローラーとして動作するよう指示する設定のいずれかです。
  • ローカルの物理インストールに固有の項目の設定。たとえば、domain.xml で宣言された名前付きインターフェース定義(以下を参照)は、host.xml の実際のマシン固有の IP アドレスにマップできます。domain.xml の抽象パス名を host.xml の実際のファイルシステムパスにマッピングできます。

3.2.2. ドメインコントローラー

1 つのホストコントローラーインスタンスが、ドメイン全体の集中管理ポイントとして機能するように構成されます(例: ドメインコントローラー)。ドメインコントローラーの主な役割は、ドメインの集中管理ポリシーを維持することです。これにより、すべてのホストコントローラーが現在の内容を認識できるようにし、ホストコントローラーが Red Hat Data Grid サーバーインスタンスをこのポリシーに従って実行できるように支援します。この集中管理ポリシーは、ドメインコントローラーのホストファイルシステム上の Red Hat Data Grid サーバーインストールの domain/configuration/domain.xml ファイルにデフォルトで保存されます。

domain.xml ファイルは、ドメインコントローラーを実行するためのインストールの domain/configuration ディレクトリーに置く必要があります。ドメインコントローラーの実行が意図されていないインストール(例: リモートのドメインコントローラーに接続するように設定されたホストコントローラー)には、インストールを行う必要はありません。このようなサーバーに domain.xml ファイルが存在すると、問題はありません。

domain.xml ファイルには、ドメインの Red Hat Data Grid Server インスタンスが実行するように設定できるさまざまな「profiles」の設定が含まれます。プロファイル設定には、そのプロファイルを構成するさまざまなサブシステムの詳細な設定(キャッシュコンテナーやキャッシュ、エンドポイント、セキュリティーレルム、データソースなど)が含まれます。ドメイン設定には、これらのサブシステムが開くことができるソケットのグループの定義も含まれます。ドメイン設定には、「サーバーグループ」の定義も含まれます。

3.2.3. サーバーグループ

サーバーグループは、単一のサーバーインスタンスとして管理および設定されるサーバーインスタンスのセットです。管理対象ドメインでは、各アプリケーションサーバーインスタンスはサーバーグループのメンバーになります。グループに単一のサーバーしかない場合でも、サーバーはグループのメンバーになります。サーバーグループのすべてのサーバーが一貫した設定になるように、ドメインコントローラーとホストコントローラーが責任を負います。これらはすべて同じプロファイルで設定され、同じデプロイメントコンテンツがデプロイされる必要があります。簡単にするために、Red Hat Data Grid クラスターに属するすべてのノードが 1 つのサーバーグループのサーバーとして設定されていることを確認してください。

ドメインには複数のサーバーグループ(例: 複数の Red Hat Data Grid クラスター)を指定できます。異なるサーバーグループを異なるプロファイルやデプロイメントで設定できます。たとえば、異なる Red Hat Data Grid Server クラスターを使用するドメインでは、異なるサービスが提供されます。異なるサーバーグループが同じプロファイルを実行し、同じデプロイメントを持つこともできます。

サーバーグループ定義の例は次のとおりです。

<server-group name="main-server-group" profile="clustered">
    <socket-binding-group ref="standard-sockets"/>
</server-group>

server-group 設定には、以下の必須属性が含まれます。

  • namecachettl-ListenerExternalthe name of the server group
  • profile aadClient- groups should run the servers should run the profile that the profile(グループのサーバーが実行すべきプロファイルの名前)

さらに、以下のオプションの要素も使用できます。

  • socket-binding-groupListenerExternal-ipmilan は、グループのサーバーで使用するデフォルトのソケットバインディンググループの名前を指定します。host.xml でサーバーごとに上書きできます。server-group 要素に指定がない場合は、host.xml の各サーバーに提供する必要があります。
  • デプロイメントコンテンツは、グループのサーバーにデプロイする必要があるデプロイメントコンテンツです。
  • グループ内のすべてのサーバーに設定する必要がある system-properties aadClientsystem プロパティー
  • group 内の全サーバーに対する jvm settings jvm 設定ホストコントローラーはこれらの設定を host.xml で提供された設定にマージして、サーバーの JVM を起動するために使用する設定を取得します。詳細は、「JVM 設定」を参照してください。

3.2.4. サーバー

上図の各「サーバー」は、実際の Red Hat Data Grid サーバーノードを表します。サーバーは、ホストコントローラーとは別の JVM プロセスで実行されます。ホストコントローラーはそのプロセスを起動します。管理対象ドメインでは、エンドユーザーはコマンドラインからサーバープロセスを直接起動できません。

ホストコントローラーは、ドメイン全体の設定(domain.xml から)およびホスト固有の設定(host.xml から)の要素を組み合わせて、サーバーの設定を行います。

第4章 設定例

サーバーディストリビューションは、さまざまな設定やユースケースを示す docs/examples/configs(主にスタンドアロンモードを使用)に設定ファイルのサンプルのセットも提供します。これらを使用するには、standalone/configuration ディレクトリーにコピーし、以下の構文を使用してサーバーを起動します。

bin/standalone.sh -c configuration_file_name.xml

起動スクリプトでサポートされるパラメーターの詳細は、WildFly ドキュメントの「 Command line parameters 」を参照してください。

第5章 管理

5.1. CLI

CLI を使用して、スタンドアロンノードまたはドメインコントローラーで管理操作を実行することができます。

$ bin/cli.sh
[disconnected /] connect
[standalone@localhost:9990 /] cd subsystem=datagrid-infinispan
[standalone@localhost:9990 subsystem=datagrid-infinispan] cd cache-container=local
[standalone@localhost:9990 cache-container=local] cd local-cache=default
[standalone@localhost:9990 local-cache=default]

CLI は非常に強力で、管理リソースツリーを移動したり、単一のリソースまたはサブツリー全体を調べるのに便利な機能を多数サポートしています。複数のコマンドを一括して 1 回の操作として適用することも可能です。

5.2. Console

Web コンソールを使用して、スタンドアロンモードまたはドメインモードのいずれかで実行しているサーバーで管理操作を実行できます。コンソールは、CLI が提供する操作のサブセットのみをサポートしますが、以下のアクションを実行できます。

  • キャッシュコンテナー設定の表示/編集
  • コンテナー間でのタスクの実行
  • キャッシュ設定の表示/編集
  • キャッシュインスタンスの作成/削除
  • クラスター/サーバー/キャッシュ統計の表示
  • イベントログの表示
  • 起動/停止サーバー/クラスター(ドメインモードのみ)

コンソールにアクセスするには、必要なモードでサーバーを起動するには、http://localhost:9990 に移動し、ユーザーの認証情報を入力します。コンソールの開発に貢献する場合は、ソースコードは で参照 でき ます。

注記

Web コンソールを使用する前に、. /bin/add-user.sh スクリプトを使用して少なくとも 1 つのユーザーアカウントを設定する必要があります。ユーザーアカウントを作成する前にコンソールにアクセスしようとすると、このプロセスの詳細な手順がブラウザーに表示されます。

5.3. JMX

JMX を介して Red Hat Data Grid Server を監視する方法は 2 つあります。

  • 同じユーザーとしてローカルに実行している JConsole または VisualVM を使用します。これにより、ローカルの jvmstat 接続が使用され、追加の設定は必要ありません。
  • JMX リモーティング(JSR-160)を使用して、任意のホストから接続します。これには、サーバーのセキュリティー設定に関して特別なプロトコルを使用して管理ポート(通常は 9990)経由で接続する必要があります。

JMX リモーティングのクライアントを設定するには、$RHDG_HOME/bin/client/jboss-cli-client.jar をクライアントのクラスパスに追加し、以下のサービス URL のいずれかを使用します。

  • service:jmx:remote+http://hostname:9990 (管理インターフェース経由のプレーン接続の場合)
  • service:jmx:remote+https://hostname:9993 (ただし、これには適切なキーが利用可能である必要があります)。

JMX サブシステムは、公開された Remoting コネクターで JMX へのリモートアクセスを取得できるように Remoting エンドポイントにサービスを登録します。これは、スタンドアロンモードでデフォルトでオンに切り替え、ポート 9990 でアクセスできますが、ドメインモードではオフにされるため、有効にする必要があります。ドメインモードでは、ポートは、サーバーインスタンスを監視するための Remoting コネクターのポートになります。

<subsystem xmlns="urn:jboss:domain:jmx:1.3">
    <expose-resolved-model/>
    <expose-expression-model/>
    <remoting-connector use-management-endpoint="false"/>
</subsystem>

5.4. JMX Bean の Prometheus への公開

  • 以下のように Red Hat Data Grid サーバーを起動します。

    $ ./standalone.sh -c cloud.xml --jmx 8180:my-config.yaml

5.5. アクセスログ

hot Rod および REST エンドポイントは、すべての受信クライアントリクエストを、以下のカテゴリーのログエントリーとして記録できます。

  • Hot Rod エンドポイントの org.infinispan.PLUGINSROD_ACCESS_LOG ロギングカテゴリー。
  • REST エンドポイントの org.infinispan.REST_ACCESS_LOG ロギングカテゴリー。

5.5.1. アクセスログの有効化

Hot Rod および REST エンドポイントのアクセスログはデフォルトで無効になっています。いずれかのロギングカテゴリーを有効にするには、以下の例のように、サーバー設定ファイルでレベルを TRACE に設定します。

<logger category="org.infinispan.HOTROD_ACCESS_LOG" use-parent-handlers="false">
    <level name="TRACE"/>
    <handlers>
       <handler name="HR-ACCESS-FILE"/>
    </handlers>
</logger>

5.5.2. アクセスログのプロパティー

アクセスログのデフォルト形式は以下のとおりです。

%x{address} %X{user} [%d{dd/MMM/yyyy:HH:mm:ss z}] "%X{method} %m %X{protocol}" %X{status} %X{requestSize} %X{responseSize} %X{duration}%n

前述のフォーマットは、以下のようなログエントリーを作成します。

127.0.0.1 - [30/Oct/2018:12:41:50 CET] "PUT /rest/default/key HTTP/1.1" 404 5 77 10

ロギングプロパティーは %X{name} 表記を使用し、アクセスログの形式を変更可能にします。以下は、デフォルトのロギングプロパティーです。

プロパティー説明

address

X-Forwarded-For ヘッダーまたはクライアント IP アドレスのいずれか。

user

認証を使用する場合のプリンシパル名。

method

使用されるメソッド。PUTGET など。

protocol

使用されるプロトコルHTTP/1.1HTTP/2HOTROD/2.9 など。

status

REST エンドポイントの HTTP ステータスコード。OK または Hot Rod エンドポイントの例外。

requestSize

リクエストのサイズ (バイト単位)。

responseSize

応答のサイズ (バイト単位)。

duration

サーバーによる要求の処理にかかった時間 (ミリ秒数)。

ヒント

h: で始まるヘッダー名を使用して、リクエストに含まれるヘッダーをログに記録します (例: %X{h:User-Agent})。

第6章 設定

サーバーは WildFly コードベースをベースとしているため、JGroups、Red Hat Data Grid、および Endpoint サブスキーム以外の WildFly ドキュメントを参照してください。

6.1. JGroups サブシステムの設定

JGroups サブシステムはネットワークトランスポートを設定し、複数の Red Hat Data Grid Server ノードをクラスター化する場合にのみ必要です。

サブシステム宣言は、以下の XML 要素に囲まれています。

<subsystem xmlns="urn:infinispan:server:jgroups:9.4">
  <channels default="cluster">
    <channel name="cluster"/>
  </channels>
  <stacks default="${jboss.default.jgroups.stack:udp}">
    ...
  </stacks>
</subsystem>

サブシステム内で使用するスタックを宣言し、命名する必要があります。サブシステム宣言の default-stack 属性は、宣言されたスタックのいずれかを参照する必要があります。jboss.default.jgroups.stack プロパティーを使用して、コマンドラインからスタックを切り替えることができます。

bin/standalone.sh -c clustered.xml -Djboss.default.jgroups.stack=tcp

スタック宣言は、トランスポート、UDP または TCP、その後にプロトコルのリストで構成されます。以下の形式でプロパティーを子要素として追加することで、プロトコルをチューニングできます。

<property name="prop_name">prop_value</property>

Red Hat Data Grid のデフォルトのスタックは以下のとおりです。

<stack name="udp">
  <transport type="UDP" socket-binding="jgroups-udp"/>
  <protocol type="PING"/>
  <protocol type="MERGE3"/>
  <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
  <protocol type="FD_ALL"/>
  <protocol type="VERIFY_SUSPECT"/>
  <protocol type="pbcast.NAKACK2"/>
  <protocol type="UNICAST3"/>
  <protocol type="pbcast.STABLE"/>
  <protocol type="pbcast.GMS"/>
  <protocol type="UFC"/>
  <protocol type="MFC"/>
  <protocol type="FRAG3"/>
</stack>
<stack name="tcp">
  <transport type="TCP" socket-binding="jgroups-tcp"/>
  <protocol type="MPING" socket-binding="jgroups-mping"/>
  <protocol type="MERGE3"/>
  <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
  <protocol type="FD_ALL"/>
  <protocol type="VERIFY_SUSPECT"/>
  <protocol type="pbcast.NAKACK2">
    <property name="use_mcast_xmit">false</property>
  </protocol>
  <protocol type="UNICAST3"/>
  <protocol type="pbcast.STABLE"/>
  <protocol type="pbcast.GMS"/>
  <protocol type="MFC"/>
  <protocol type="FRAG3"/>
</stack>
注記

一部のプロパティーでは、Red Hat Data Grid は JGroups のデフォルト以外の値を使用します。以下のファイルを確認して、Red Hat Data Grid の JGroups 設定を確認する必要があります。

  • リモートクライアント/サーバーモード:

    • jgroups-defaults.xml
    • infinispan-jgroups.xml
  • ライブラリーモード:

    • default-jgroups-tcp.xml
    • default-jgroups-udp.xml

これらの JGroups ファイルは、Red Hat カスタマーポータルから Red Hat Data Grid ソースディストリビューションで利用できます。

利用可能なプロパティーおよびデフォルト値に関する詳細は、JGroups プロトコル のドキュメントを参照してください。

デフォルトの TCP スタックは、UDP マルチキャストを使用する検出に MPING プロトコルを使用します。別のプロトコルを使用する必要がある場合は、JGroups Discovery Protocols を参照してください。以下のスタックの例では、TCPPING 検索プロトコルを 2 つの初期ホストで設定します。

<stack name="tcp">
  <transport type="TCP" socket-binding="jgroups-tcp"/>
  <protocol type="TCPPING">
    <property name="initial_hosts">HostA[7800],HostB[7800]</property>
  </protocol>
  <protocol type="MERGE3"/>
  <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
  <protocol type="FD_ALL"/>
  <protocol type="VERIFY_SUSPECT"/>
  <protocol type="pbcast.NAKACK2">
    <property name="use_mcast_xmit">false</property>
  </protocol>
  <protocol type="UNICAST3"/>
  <protocol type="pbcast.STABLE"/>
  <protocol type="pbcast.GMS"/>
  <protocol type="UFC"/>
  <protocol type="MFC"/>
  <protocol type="FRAG3"/>
</stack>

デフォルト設定には、さまざまな環境用に事前設定されたさまざまなスタックが含まれます。たとえば、tcpgossip スタックは Gossip 検出を使用します。

<protocol type="TCPGOSSIP">
  <property name="initial_hosts">${jgroups.gossip.initial_hosts:}</property>
</protocol>

Amazon AWS で実行する場合は、s3 スタックを使用します。

<protocol type="org.jgroups.aws.s3.NATIVE_S3_PING" module="org.jgroups.aws.s3:{infinispanslot}">
  <property name="region_name">${jgroups.s3.region:}</property>
  <property name="bucket_name">${jgroups.s3.bucket_name:}</property>
  <property name="bucket_prefix">${jgroups.s3.bucket_prefix:}</property>
</protocol>

同様に、Google の Cloud Platform を使用する場合は、google スタックを使用します。

<protocol type="GOOGLE_PING">
  <property name="location">${jgroups.google.bucket:}</property>
  <property name="access_key">${jgroups.google.access_key:}</property>
  <property name="secret_access_key">${jgroups.google.secret_access_key:}</property>
</protocol>

dns-ping スタックを使用して、OKD や OpenShift などの Kubernetes 環境で Red Hat Data Grid を実行します。

<protocol type="dns.DNS_PING">
    <property name="dns_query">${jgroups.dns_ping.dns_query}</property>
</protocol>

dns_query プロパティーの値は、クラスターメンバーを返す DNS クエリーです。Kubernetes DNS の命名に関する詳細は、「サービスおよび Pod の DNS」を参照してください。

6.2. Red Hat Data Grid サブシステムの設定

Red Hat Data Grid サブシステムは、キャッシュコンテナーおよびキャッシュを設定します。

サブシステム宣言は、以下の XML 要素に囲まれています。

<subsystem xmlns="urn:infinispan:server:core:9.4" default-cache-container="clustered">
  ...
</subsystem>

6.2.1. コンテナー

Red Hat Data Grid サブシステムは複数のコンテナーを宣言できます。コンテナーは以下のように宣言されます。

<cache-container name="clustered" default-cache="default">
  ...
</cache-container>

サーバーモードでは暗黙的なデフォルトキャッシュはないものの、名前付きキャッシュをデフォルトとして指定できることに注意してください。

クラスター化されたキャッシュ(分散、レプリケート、無効化)を宣言する必要がある場合、既存の JGroups トランスポートを参照する <transport/> 要素も指定する必要があります。ローカルキャッシュのみがある場合にのみ、これは必要ありません。

<transport executor="infinispan-transport" lock-timeout="60000" stack="udp" cluster="my-cluster-name"/>

6.2.2. キャッシュ

これでキャッシュを宣言できるようになりました。設定で宣言されたキャッシュのみがエンドポイントで利用可能であり、未定義のキャッシュにアクセスしようとすると不正な操作であることに注意してください。これとは対照的に、未定義キャッシュを取得するデフォルトの Red Hat Data Grid ライブラリーの動作と暗黙的に、デフォルト設定を使用してこれを作成します。以下は、利用可能な 4 つのタイプのキャッシュの宣言例です。

<local-cache name="default" start="EAGER">
  ...
</local-cache>

<replicated-cache name="replcache" mode="SYNC" remote-timeout="30000" start="EAGER">
  ...
</replicated-cache>

<invalidation-cache name="invcache" mode="SYNC" remote-timeout="30000" start="EAGER">
  ...
</invalidation-cache>

<distributed-cache name="distcache" mode="SYNC" segments="20" owners="2" remote-timeout="30000" start="EAGER">
  ...
</distributed-cache>

6.2.3. expiration

キャッシュにエントリーのデフォルト有効期限を定義するには、以下のように <expiration/> 要素を追加します。

<expiration lifespan="2000" max-idle="1000"/>

expiration 要素に使用できる属性は次のとおりです。

  • キャッシュエントリーのライフスパンが最大で、その後にエントリー全体が期限切れになります(ミリ秒単位)。-1 は、エントリーが失効しないことを意味します。
  • キャッシュエントリー キャッシュで維持される最大アイドル時間(ミリ秒単位)。アイドル時間を超えると、エントリーはクラスター全体に期限切れになります。-1 はエントリーが失効しないことを意味します。
  • メモリーとキャッシュストアから期限切れのエントリーをパージする後続の実行の 間隔 (ミリ秒単位)。定期的なエビクションプロセスを完全に無効にする場合は、interval を -1 に設定します。

6.2.4. エビクション

キャッシュのエビクションストラテジーを定義するには、<memory> 要素を <*-cache /> に追加します。

エビクションストラテジーの設定に関する詳細は、『 Red Hat Data Grid User Guide 』の「 Eviction and Data Container 」を参照してください。

6.2.5. ロック

キャッシュのロック設定を定義するには、以下のように <locking/> 要素を追加します。

<locking isolation="REPEATABLE_READ" acquire-timeout="30000" concurrency-level="1000" striping="false"/>

locking 要素に設定可能な属性は以下のとおりです。

  • 分離 は、キャッシュロックの分離レベルを設定します。NONE、READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READ、SERIALIZABLE のいずれかを使用できます。デフォルトは REPEATABLE_READ です。
  • true の場合、ロックする必要があるすべてのエントリーで共有ロックのプールが維持されます。それ以外の場合は、キャッシュのエントリーごとにロックが作成されます。ロックストライピングは、メモリーフットプリントの制御に役立ちますが、システムの同時実行性を軽減する可能性があります。
  • acquire-timeout: 特定のロック取得を試行するための最大時間。
  • ロックコンテナーの同時実行 レベル。この値は、Red Hat Data Grid と対話する同時スレッドの数に応じて調整します。
  • 非トランザクションキャッシュの 同時 更新のみ: true(デフォルト値)に設定すると、並列更新の場合はキャッシュがデータの一貫性を維持します。クラスター化されたキャッシュの場合、これは追加の RPC のコストであるため、アプリケーションがデータを同時に書き込みすることが期待されない場合には、このフラグを無効にするとパフォーマンスが向上します。

6.2.6. Hot Rod によるトランザクション操作

hot Rod クライアントは、キャッシュ操作を実行するときにトランザクション機能を利用できます。Red Hat Data Grid がサポートするプロトコルは、トランザクション機能を提供します。

6.2.7. ローダーとストア

ローダーとストアは、埋め込みモードとほぼ同様にサーバーモードで定義できます。

ただし、サーバーモードでは、<persistence>…​</persistence> タグ。代わりに、ストアの属性が store type 要素で定義されたようになりました。たとえば、ドメインモードで分散キャッシュを持つ H2 データベースを設定するには、domain.xml 設定で次のように「デフォルト」キャッシュを定義します。

<subsystem xmlns="urn:infinispan:server:core:9.4">
  <cache-container name="clustered" default-cache="default" statistics="true">
    <transport lock-timeout="60000"/>
    <global-state/>
    <distributed-cache name="default">
      <string-keyed-jdbc-store datasource="java:jboss/datasources/ExampleDS" fetch-state="true" shared="true">
        <string-keyed-table prefix="ISPN">
          <id-column name="id" type="VARCHAR"/>
          <data-column name="datum" type="BINARY"/>
          <timestamp-column name="version" type="BIGINT"/>
        </string-keyed-table>
        <write-behind modification-queue-size="20"/>
      </string-keyed-jdbc-store>
    </distributed-cache>
  </cache-container>
</subsystem>

この例で注意すべきもう 1 つの重要なことは、次のように domain.xml 設定の datasources サブシステムで定義される「ExampleDS」データソースを使用することです。

<subsystem xmlns="urn:jboss:domain:datasources:4.0">
  <datasources>
    <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
      <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
      <driver>h2</driver>
      <security>
        <user-name>sa</user-name>
        <password>sa</password>
      </security>
    </datasource>
  </datasources>
</subsystem>
注記

ストア設定の他の例については、サーバーディストリビューション(./domain /configuration/domain.xml)で提供されるデフォルトの「domain.xml」ファイルで設定テンプレートを確認してください。

6.2.8. 状態遷移

分散またはレプリケートされたキャッシュの状態遷移設定を定義するには、以下のように <state-transfer/> 要素を追加します。

<state-transfer enabled="true" timeout="240000" chunk-size="512" await-initial-transfer="true" />

state-transfer 要素に可能な属性は次のとおりです。

  • true を 有効化 すると、起動時にキャッシュに状態を求めるプロンプトが出されます。そのため、キャッシュは起動時間に影響を及ぼしますが、キャッシュは「warm」を開始します。デフォルトは true です。
  • 例外をスローして起動を中止するまでに、近接しているキャッシュからの状態を待つ最大時間(ミリ秒)を タイムアウト します。デフォルトは 240000(4 分)です。
  • chunk-size は、各転送でバッチ処理するキャッシュエントリーの数です。デフォルトは 512 に設定されます。
  • true 場合、キャッシュは最初の状態遷移が完了するまで待機し、リクエストに応答します。デフォルトは true です。

6.3. エンドポイントサブシステムの設定

endpoint サブシステムは、特定のコネクタープロトコルでコンテナー全体(または Memcached の場合は単一のキャッシュ)を公開します。異なるインターフェース/ポートにバインドする場合は、必要なだけコネクターを定義できます。

サブシステム宣言は、以下の XML 要素に囲まれています。

 <subsystem xmlns="urn:infinispan:server:endpoint:9.4">
  ...
 </subsystem>

6.3.1. Hot Rod

以下のコネクター宣言は、hotrod ソケットバインディング( <socket-binding-group /> 要素内に宣言)を使用して HotRod サーバーを有効にし、他のすべての設定にデフォルトを使用して、ローカル コンテナーで宣言されたキャッシュを公開します。

<hotrod-connector socket-binding="hotrod" cache-container="local" />

コネクターは、デフォルト設定でサポートするトポロジーキャッシュを作成します。これらの設定を調整する場合は、以下のように <topology-state-transfer /> 子要素をコネクターに追加します。

<hotrod-connector socket-binding="hotrod" cache-container="local">
   <topology-state-transfer lazy-retrieval="false" lock-timeout="1000" replication-timeout="5000" />
</hotrod-connector>

Hot Rod コネクターは、同時実行やバッファーなどの追加設定でさらに調整できます。詳細は、プロトコルコネクター設定段落を参照してください。

さらに、SSL を使用して HotRod コネクターをセキュアにすることができます。最初に、設定ファイルの management セクションで、セキュリティーレルム内で SSL サーバーアイデンティティーを宣言する必要があります。SSL サーバーアイデンティティーは、キーストアとそのシークレットへのパスを指定する必要があります。詳細は AS の ドキュメント を参照してください。次に、以下のように <security /> 要素を HotRod コネクターに追加します。

<hotrod-connector socket-binding="hotrod" cache-container="local">
    <security ssl="true" security-realm="ApplicationRealm" require-ssl-client-auth="false" />
</hotrod-connector>

6.3.2. Memcached

以下のコネクター宣言は、memcached ソケットバインディング( <socket-binding-group /> 要素内で宣言)を使用して Memcached サーバーを有効にし、他のすべての設定のデフォルトを使用して ローカル コンテナーで宣言された memcachedCache キャッシュを公開します。Memcached プロトコルの制限により、コネクターによって 1 つのキャッシュのみを表示できます。複数のキャッシュを公開する場合は、追加の memcached-connectors を別の socket-bindings に宣言します。

<memcached-connector socket-binding="memcached" cache-container="local"/>

6.3.3. REST

<rest-connector socket-binding="rest" cache-container="local" security-domain="other" auth-method="BASIC"/>

6.3.4. Common Protocol Connector の設定

HotRod および Memcached プロトコルコネクターは、宣言で多数のチューニング属性をサポートします。

  • worker-threads はワーカースレッドの数を設定します。デフォルトは 160 です。
  • idle-timeout は、クライアントからの接続がアクティビティーなしに開いたままになる最大時間を秒単位で指定します。デフォルトは -1 です(コネクションはタイムアウトしません)
  • tcp-nodelay は TCP スタック上の TCP NODELAY に影響を与えます。デフォルトでは有効に設定されています。
  • send-buffer-size は送信バッファーのサイズを設定します。
  • receive-buffer-size は受信バッファーのサイズを設定します。

6.3.5. Red Hat Data Grid エンドポイントの開始および停止

コマンドラインインターフェース(CLI)を使用して Red Hat Data Grid エンドポイントコネクターを起動および停止します。

エンドポイントコネクターを起動および停止するコマンド:

  • 個々のエンドポイントに適用します。すべてのエンドポイントコネクターを停止または起動するには、各エンドポイントコネクターでコマンドを実行する必要があります。
  • 単一ノードのみに(クラスター全体ではなく)有効にしてください。

手順

  1. CLI を起動して、Red Hat Data Grid に接続します。
  2. 以下のように、datagrid-infinispan-endpoint サブシステムのエンドポイントコネクターを一覧表示します。

    [standalone@localhost:9990 /] ls subsystem=datagrid-infinispan-endpoint
    hotrod-connector     memcached-connector  rest-connector       router-connector
  3. 開始または停止するエンドポイントコネクターに移動します。以下に例を示します。

    [standalone@localhost:9990 /] cd subsystem=datagrid-infinispan-endpoint
    
    [standalone@localhost:9990 subsystem=datagrid-infinispan-endpoint] cd rest-connector=rest-connector
  4. :stop-connector コマンドおよび :start-connector コマンドを適宜使用します。

    [standalone@localhost:9990 rest-connector=rest-connector] :stop-connector
    {"outcome" => "success"}
    
    [standalone@localhost:9990 rest-connector=rest-connector] :start-connector
    {"outcome" => "success"}

6.3.6. プロトコルの相互運用性

クライアントは、REST、Hot Rod などのエンドポイントを介して Red Hat Data Grid でデータを交換します。

各エンドポイントは異なるプロトコルを使用するため、クライアントは適切な形式でデータを読み書きできます。Red Hat Data Grid は複数のクライアントと同時に相互運用できるため、クライアント形式とストレージ形式との間でデータを変換する必要があります。

詳細は、『User Guide』の「 Protocol Interoperability 」のトピックを参照してください。

6.3.7. カスタムのマーシャリングブリッジ

Red Hat Data Grid は、Kryo ライブラリーおよび Protostuff ライブラリーを使用して、クライアント/サーバーリクエストをマーシャリングするためのマーシャリングブリッジを 2 つ提供します。これらのマーシャラーのいずれかを使用するには、必要なマーシャラーの依存関係をクライアントの pom に配置するだけです。オブジェクトマーシャリングのカスタムスキーマは、クライアント上でライブラリーの api を使用して選択したライブラリーに登録するか、または指定のマーシャラーブリッジの RegistryService を実装する必要があります。両方のライブラリーでこれを実現する方法の例を以下に示します。

6.3.7.1. Protostuff

protostuff マーシャラーの依存関係を pom に追加します。

<dependency>
  <groupId>org.infinispan</groupId>
  <artifactId>infinispan-marshaller-protostuff</artifactId>
  <version>${version.infinispan}</version>
</dependency>

${version.infinispan} を Red Hat Data Grid の適切なバージョンに置き換えます。

独自のコードにカスタム Protostuff スキーマを登録するには、マーシャリングを開始する前に、カスタムスキーマを Protostuff に登録する必要があります。これは、単に呼び出しを行うことで実現できます。

RuntimeSchema.register(ExampleObject.class, new ExampleObjectSchema());

または、SchemaRegistryService.java インターフェースのサービスプロバイダーを実装し、register () メソッドにすべてのスキーマ登録を配置することもできます。このインターフェースの実装は Java の ServiceLoader API を介してロードされるため、実装されたクラスの完全パスはデプロイメント jar 内の META-INF/services/org/infinispan/marshaller/protostuff/SchemaRegistryService ファイルで指定する必要があります。

6.3.7.2. ケリー

kryo marshaller 依存関係を pom に追加します。

<dependency>
  <groupId>org.infinispan</groupId>
  <artifactId>infinispan-marshaller-kryo</artifactId>
  <version>${version.infinispan}</version>
</dependency>

${version.infinispan} を Red Hat Data Grid の適切なバージョンに置き換えます。

カスタム Kryo シリアライザーを独自のコードに登録するには、マーシャリングを開始する前に、カスタムシリアライザーを Kryo で登録する必要があります。これは、SerializerRegistryService.java インターフェースのサービスプロバイダーを実装し、すべてのシリアライザー登録を register(Kryo) メソッドに配置します。ここで、シリアライザーは、Kryo api を使用して指定の Kryo オブジェクトで登録される必要があります。たとえば、kryo. register(ExampleObject.class、新しい ExampleObjectSerializer ())を使用します。このインターフェースの実装は Java の ServiceLoader API を介して読み込まれるため、実装されたクラスの完全パスは、デプロイメント jar 内の META-INF/services/org/infinispan/marshaller/kryo/SerializerRegistryService ファイルで提供される必要があります。

6.3.7.3. サーバー互換モード

Protostuff/Kryo ブリッジを互換モードで使用する場合は、すべてのカスタムオブジェクトのクラスファイルをサーバーのクラスパスに配置する必要があります。これを行うには、Protocol Interoperability セクションで概説されている手順に従って、サーバーのクラスパスにすべてのカスタムクラスが含まれる jar を配置する必要があります。

互換性モードでカスタムマーシャラーを利用する場合は、マーシャラーと、サーバーのクラスパス上のランタイム依存関係も必要です。この手順を支援するために、ブリッジと基盤のライブラリーに必要なすべてのランタイムクラスファイルが含まれるブリッジ実装ごとに「バンドル」 jar を作成しました。したがって、サーバーのクラスパスにこの jar を 1 つだけ含める必要があります。

Bundle jar ダウンロード:

注記

マーシャラーバンドルを modules/system/layers/base/org/infinispan/main/modules.xml に登録する場合は、カスタムクラスが含まれる JAR ファイルをカスタムマーシャラーバンドルと同じマーシャラーバンドルに配置する必要があります。

6.3.7.3.1. カスタムスキーマ/シリアルコンソールの登録

Kryo/Protostuff マーシャラーのカスタムシリアライザー/スキーマは、適切なサービスインターフェースを介して互換性モードで登録する必要があります。これを行うには、サービスプロバイダーを含む JAR をマーシャラーバンドルとカスタムクラスと同じディレクトリーまたはモジュールに登録する必要があります。

注記

サービスプロバイダーの実装をユーザーのカスタムクラスと同じ JAR に提供する必要はありません。ただし、プロバイダーが含まれる JAR はマーシャラーとカスタムクラス JAR ファイルと同じディレクトリー/モジュールに存在する必要があります。

第7章 セキュリティー

7.1. 一般的な概念

7.1.1. 承認

埋め込みモードと同様に、サーバーは同じ設定を使用したキャッシュ承認をサポートします。以下に例を示します。

   <cache-container default-cache="secured" name="secured">
      <security>
         <authorization>
	    <identity-role-mapper/>
            <role name="admin" permissions="ALL" />
            <role name="reader" permissions="READ" />
            <role name="writer" permissions="WRITE" />
            <role name="supervisor" permissions="READ WRITE EXEC"/>
         </authorization>
      </security>
      <local-cache name="secured">
         <security>
            <authorization roles="admin reader writer supervisor" />
         </security>
      </local-cache>
   </cache-container>

7.1.2. サーバーレルム

Red Hat Data Grid Server のセキュリティーは、基盤となるサーバーレルムおよびセキュリティードメインによって提供される機能を中心に構築されます。セキュリティーレルムは、管理インターフェースとアプリケーションインターフェースの両方の認証および承認情報を提供するためにサーバーによって使用されます。

セキュリティーレルムの設定

<server xmlns="urn:jboss:domain:2.1">
   ...
   <management>
        ...
        <security-realm name="ApplicationRealm">
           <authentication>
              <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
           </authentication>
           <authorization>
              <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
           </authorization>
        </security-realm>
        ...
    </management>
    ...
</server>

Red Hat Data Grid Server には add-user.sh スクリプト(Windows の場合は add-user.bat)が同梱されています。これは、上記のプロパティーファイルに新しいユーザー/ロールマッピングを追加するプロセスを容易にします。ロールの初期セットでユーザーを ApplicationRealm に追加する呼び出し例:

./bin/add-user.sh -a -u myuser -p "qwer1234!" -ro supervisor,reader,writer

LDAP、JAAS などの代替ソースに対する認証/認可を行うこともできます。セキュリティーレルムの設定方法については、WildFly セキュリティーレルムガイド を参照してください。プロトコルに選択する認証メカニズムを選択すると、認証ソースのタイプが制限されることに注意してください。これは、認証情報はアルゴリズム自体でサポートされている形式でなければなりません(ダイジェストアルゴリズムの事前提供されたパスワードなど)。

7.2. Hot Rod 認証

Hot Rod プロトコルは、SASL メカニズムを利用して認証をサポートします。サポートされる SASL メカニズム(通常はメッチとして省略)は以下のとおりです。

  • PLAIN - 認証情報はプレーンテキスト形式でネットワーク上で送信されるため、最も安全ではないメッセージです。暗号化(TLS など)と組み合わせて、安全に使用できます。
  • DIGEST-MD5 - ネットワーク上で送信する前に認証情報をハッシュ化するので、PLAIN より安全になります。
  • GSSAPI - このメッチは Kerberos チケットを使用するため、適切に設定された Kerberos ドメインコントローラー(Microsoft Active Directory など)が必要です。
  • EXTERNAL - このメッチは、基礎となるトランスポート(X.509 クライアント証明書などから)から認証情報を取得するため、client-certificates を使用した暗号化を有効にする必要があります。

以下の設定は、DIGEST-MD5 SASL メカニズムを使用した ApplicationRealm に対する認証を有効にし、認証 QoP のみを有効にします( SASL Protection の Protection を参照してください)。

hot Rod コネクター設定

<hotrod-connector socket-binding="hotrod" cache-container="default">
   <authentication security-realm="ApplicationRealm">
      <sasl server-name="myhotrodserver" mechanisms="DIGEST-MD5" qop="auth" />
   </authentication>
</hotrod-connector>

server-name 属性に注目してください。これは、サーバーが受信クライアントに対して宣言する名前であるため、クライアント設定が一致する必要があります。GSSAPI は Kerberos サービス名と同等であるため、特に重要です。複数のメカニズムを指定でき、順番に試行されます。

7.2.1. SASL 保護品質

SASL の主な目的は認証を提供することですが、整合性およびプライバシー保護もサポートしています(保護品質(または qop)とも呼ばれます)。認証ネゴシエーション時に、暗号はクライアントとサーバー間で交換され、その後のすべてのトラフィックにチェックサムと暗号化を追加するのに使用できます。qop の必須レベルは、以下のように調整できます。

QOP説明

auth

認証のみ

auth-int

整合性保護による認証

auth-conf

整合性とプライバシー保護による認証

7.2.2. SASL ポリシー

メカニズムの選択方法は、SASL ポリシーを調整して詳細に調整できます。これには、希望のポリシーに一致するかどうかに基づいてメカニズム/除外メカニズムを効果的に含まれます。

Policy説明

forward-secrecy

選択した SASL メカニズムがセッション間の転送セキュリティーをサポートする必要があることを指定します。つまり、1 つのセッションに分割しても、今後のセッションに侵入するための情報が自動的に提供されないことを意味します。

pass-credentials

選択した SASL メカニズムにクライアントクレデンシャルが必要であることを指定します。

no-plain-text

選択した SASL メカニズムが単純な平文パッシブ攻撃の影響を受けないように指定します。

no-active

選択した SASL メカニズムが、アクティブな(ディクショナリー以外)攻撃を受けない必要があることを指定します。このメカニズムでは、アクティブな攻撃を防ぐために相互認証が必要になる場合があります。

no-dictionary

選択した SASL メカニズムが受動的な辞書攻撃の影響を受けないように指定します。

no-anonymous

選択した SASL メカニズムが匿名ログインを許可しないことを指定します。

各ポリシーの値は「true」または「false」のいずれかになります。ポリシーが存在しない場合は、選択したメカニズムにその特性(ポリシーを「false」に設定する場合と同じ)は必要ありません。例外の 1 つが no-anonymous ポリシーで、存在しない場合はデフォルトで true に設定され、匿名接続が阻止されます。

注記

エンドポイントへの匿名および認証された接続を混在させ、認証設定をキャッシュするために実際のアクセスロジックを委譲することができます。これを行うには、no-anonymous ポリシーを false に設定し、キャッシュ承認を有効にします。

以下の設定は、利用可能なすべてのメカニズムを選択しますが、選択したポリシーに関する唯一のメカニズムであるため、実際には GSSAPI のみを有効にします。

hot Rod コネクターポリシー

<hotrod-connector socket-binding="hotrod" cache-container="default">
   <authentication security-realm="ApplicationRealm">
      <sasl server-name="myhotrodserver" mechanisms="PLAIN DIGEST-MD5 GSSAPI EXTERNAL" qop="auth">
         <policy>
            <no-active value="true" />
            <no-anonymous value="true" />
            <no-plain-text value="true" />
         </policy<>
      </sasl>
   </authentication>
</hotrod-connector>

7.2.3. GSSAPI/Kerberos の使用

GSSAPI/Kerberos を使用する場合は、セットアップと設定が異なります。まず、セキュリティードメインサブシステムを使用して Kerberos ログインモジュールを定義する必要があります。

セキュリティードメインの設定

<system-properties>
    <property name="java.security.krb5.conf" value="/tmp/infinispan/krb5.conf"/>
    <property name="java.security.krb5.debug" value="true"/>
    <property name="jboss.security.disable.secdomain.option" value="true"/>
</system-properties>

<security-domain name="infinispan-server" cache-type="default">
    <authentication>
        <login-module code="Kerberos" flag="required">
            <module-option name="debug" value="true"/>
            <module-option name="storeKey" value="true"/>
            <module-option name="refreshKrb5Config" value="true"/>
            <module-option name="useKeyTab" value="true"/>
            <module-option name="doNotPrompt" value="true"/>
            <module-option name="keyTab" value="/tmp/infinispan/infinispan.keytab"/>
            <module-option name="principal" value="HOTROD/localhost@INFINISPAN.ORG"/>
        </login-module>
    </authentication>
</security-domain>

次に、Hot Rod コネクターを変更する必要があります。

hot Rod コネクター設定

<hotrod-connector socket-binding="hotrod" cache-container="default">
   <authentication security-realm="ApplicationRealm">
      <sasl server-name="infinispan-server" server-context-name="infinispan-server" mechanisms="GSSAPI" qop="auth" />
   </authentication>
</hotrod-connector>

7.3. TLS/SSL(Hot Rod)および REST 暗号化

Hot Rod および REST プロトコルはいずれも、SSL/TLS を使用した暗号化と任意の TLS/SNI サポート(Server Name Indication)をサポートします。これを設定するには、サーバー証明書を保存する JDK の一部である keytool アプリケーションを使用してキーストアを作成する必要があります。次に、<server-identities> 要素をセキュリティーレルムに追加します。

SSL のセキュリティーレルム設定

<security-realm name="ApplicationRealm">
    <server-identities>
        <ssl>
            <keystore path="keystore_server.jks" relative-to="jboss.server.config.dir" keystore-password="secret" />
        </ssl>
    </server-identities>
</security-realm>

注記

SNI サポートを使用する場合は、複数のセキュリティーレルムが設定される可能性があります。

サーバーの起動時に開発証明書を生成することもできます。これを行うには、以下のように keystore 要素に generate-self-signed-certificate-host を指定します。

キーストアの自動生成

<security-realm name="ApplicationRealm">
    <server-identities>
        <ssl>
            <keystore path="keystore_server.jks" relative-to="jboss.server.config.dir" keystore-password="secret" generate-self-signed-certificate-host="localhost"/>
        </ssl>
    </server-identities>
</security-realm>

注記

自動生成されたキーストアを使用する場合は、覚えておく必要のある基本的な原則が 3 つあります。

  • 実稼働環境では使用しないでください。
  • これらは、必要に応じて生成されます(例: クライアントからの最初の接続の取得時など)。
  • これらの証明書も証明書が含まれているので、Hot Rod クライアントで直接使用することもできます。

次に、endpoint サブシステムの <hotrod-connector> または <rest-connector> 要素を変更して暗号化を必要とします。オプションで SNI 設定を追加します。

hot Rod コネクター SSL 設定

<hotrod-connector socket-binding="hotrod" cache-container="local">
    <encryption security-realm="ApplicationRealm" require-ssl-client-auth="false">
        <sni host-name="domain1" security-realm="Domain1ApplicationRealm" />
        <sni host-name="domain2" security-realm="Domain2ApplicationRealm" />
    </encryption>
</hotrod-connector>
<rest-connector socket-binding="rest" cache-container="local">
    <encryption security-realm="ApplicationRealm" require-ssl-client-auth="false">
        <sni host-name="domain1" security-realm="Domain1ApplicationRealm" />
        <sni host-name="domain2" security-realm="Domain2ApplicationRealm" />
    </encryption>
</rest-connector>

注記

clients In order to connect to the server using the Hot Rod protocol(Hot Rod プロトコルを使用してサーバーに接続するには、JRE が信頼する認証局(CA)によって鍵が署名されていない限り、接続する公開鍵が含まれるトラストストアが必要です。

ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder
    .addServer()
        .host("127.0.0.1")
        .port(11222)
     .security()
        .ssl()
           .enabled(true)
           .sniHostName("domain1")
           .trustStoreFileName("truststore_client.jks")
           .trustStorePassword("secret".toCharArray());
remoteCacheManager = new RemoteCacheManager(clientBuilder.build());

さらに、クライアント証明書認証を有効にすることもできます(オプションで EXTERNAL SASL メッチを使用してクライアントの認証および承認も許可します)。これを有効にするには、サーバー上のセキュリティーレルムがトラストストアを追加して受信クライアント証明書を信頼できるようにする必要があります。

<security-realm name="ApplicationRealm">
   <authentication>
      <truststore path="truststore_server.jks" relative-to="jboss.server.config.dir" keystore-password="secret"/>
   </authentication>
   <server-identities>
       <ssl>
           <keystore path="keystore_server.jks" relative-to="jboss.server.config.dir" keystore-password="secret" />
       </ssl>
   </server-identities>
</security-realm>

次に、コネクターにクライアント証明書を必要とするよう指示します。

<hotrod-connector socket-binding="hotrod" cache-container="local">
    <encryption security-realm="ApplicationRealm" require-ssl-client-auth="true" />
</hotrod-connector>

クライアントでは、この時点では、サーバー証明書を信頼する trustStore に証明書が含まれる keyStore を指定する必要があります。

その方法を学ぶためのセクションです。

第8章 ヘルスモニタリング

Red Hat Data Grid サーバーには、クラスターの正常性を監視するための特別なエンドポイントがあります。API は以下を介して公開されます。

8.1. JMX を使用したヘルス API へのアクセス

まず、JMX を使用して Red Hat Data Grid サーバーに接続する必要があります(JConsole またはその他のツールを使用してこれを使用します)。次に、オブジェクト名 jboss.datagrid-infinispan:type=CacheManager,name="clustered",component=CacheContainerHealth に移動します。

8.2. CLI を使用したヘルス API へのアクセス

以下の例のように、コマンドラインインターフェース(CLI)から Health API にアクセスできます。

Standalone
$ bin/cli.sh -c "/subsystem=datagrid-infinispan/cache-container=clustered/health=HEALTH:read-resource(include-runtime=true)"
ドメインモード
$ bin/cli.sh -c "/host=master/server=${servername}/subsystem=datagrid-infinispan/cache-container=clustered/health=HEALTH:read-resource(include-runtime=true)"

${servername} は、Red Hat Data Grid サーバーインスタンスの名前です。

以下は、CLI 呼び出しの結果の例です。

{
    "outcome" => "success",
    "result" => {
        "cache-health" => "HEALTHY",
        "cluster-health" => ["test"],
        "cluster-name" => "clustered",
        "free-memory" => 99958L,
        "log-tail" => [
            "<time_stamp> INFO  [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
            "<time_stamp> INFO  [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
            "<time_stamp> INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
            "<time_stamp> INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
            "<time_stamp> INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
            "<time_stamp> INFO  [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
            "<time_stamp> INFO  [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
            "<time_stamp> INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
            "<time_stamp> INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
            "<time_stamp> INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Red Hat Data Grid Server <build_version> (WildFly Core <build_version>) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
        ],
        "number-of-cpus" => 8,
        "number-of-nodes" => 1,
        "total-memory" => 235520L
    }
}

8.3. REST を使用したヘルス API へのアクセス

REST インターフェースを使用すると、CLI と同じリソースセットにアクセスできます。ただし、HTTP Management API は認証を必要とするため、最初に add-user.sh スクリプトで認証情報を追加する必要があります。

クレデンシャルを設定したら、以下の例のように REST 経由で Health API にアクセスします。

Standalone
curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-container/clustered/health/HEALTH?operation=resource&include-runtime=true&json.pretty=1" --header "Content-Type: application/json" -u username:password
ドメインモード
curl --digest -L -D - "http://localhost:9990/management/host/master/server/${servername}/subsystem/datagrid-infinispan/cache-container/clustered/health/HEALTH?operation=resource&include-runtime=true&json.pretty=1" --header "Content-Type: application/json" -u username:password

${servername} は、Red Hat Data Grid サーバーインスタンスの名前です。

以下は、REST 呼び出しの結果の例です。

HTTP/1.1 200 OK
Connection: keep-alive
Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
Content-Type: application/json; charset=utf-8
Content-Length: 1927
Date: <time_stamp>

{
    "cache-health" : "HEALTHY",
    "cluster-health" : ["test", "HEALTHY"],
    "cluster-name" : "clustered",
    "free-memory" : 96778,
    "log-tail" : [
        "<time_stamp> INFO  [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
        "<time_stamp> INFO  [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
        "<time_stamp> INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
        "<time_stamp> INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
        "<time_stamp> INFO  [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
        "<time_stamp> INFO  [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
        "<time_stamp> INFO  [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
        "<time_stamp> INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
        "<time_stamp> INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
        "<time_stamp> INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Red Hat Data Grid Server <build_version> (WildFly Core <build_version>) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
    ],
    "number-of-cpus" : 8,
    "number-of-nodes" : 1,
    "total-memory" : 235520
}%

REST API の結果は、CLI が取得した結果と全く同じであることに注意してください。

第9章 マルチテナンシー

マルチテナンシーでは、以下のように複数のコンテナーにアクセスできます。

マルチテナンシー

現在、データへのアクセスには、Hot Rod クライアントの使用と REST インターフェースの使用の 2 つのプロトコルがサポートされています。

9.1. REST インターフェースの使用

マルチテナンシールーターは、以下のテンプレートを使用してコンテナーを分離するために URL プレフィックスを使用します: https://<server_ip>:<server_port>/rest/<rest_connector_name>/<cache_name>/<key>;すべての HTTP 操作は、標準の rest-connector の使用と全く同じままです。

デフォルトでは、REST コネクターは HTTP/1.1 プロトコルと HTTP/2 プロトコルの両方をサポートします。HTTP/1.1 から HTTP/2 への切り替え手順では、TLS/ALPN ネゴシエーションまたは HTTP/1.1 アップグレード手順を使用する必要があります。前者の場合は、適切な暗号化を有効にする必要があります。後者は常に有効です。

9.2. Hot Rod クライアントの使用

バイナリープロトコルのマルチテナントルーティングには、SSL/TLS Server Name Indication などの標準のトランスポート層メカニズムを使用する必要があります。このサーバーは暗号化をサポートするように設定する必要があります。また、追加の SNI ルーティングを router-connector に追加する必要があります。

セキュアな Hot Rod サーバーに接続するには、クライアントは以下のような設定を使用する必要があります。

ConfigurationBuilder clientBuilder = new ConfigurationBuilder();
clientBuilder
    .addServer()
        .host("127.0.0.1")
        .port(hotrodServer.getPort())
     .security()
        .ssl()
           .enabled(sslClient)
           .sniHostName("hotrod-1") // SNI Host Name
           .trustStoreFileName("truststore.jks")
           .trustStorePassword("secret".toCharArray());
remoteCacheManager = new RemoteCacheManager(clientBuilder.build());

9.2.1. マルチテナントルーター

Multi-tenant ルーターエンドポイントは、1 つ以上の REST/Hot Rod コネクターのファサードとして機能します。その主な目的は、クライアントリクエストを適切なコンテナーに転送することです。

ルーティングを適切に設定するには、他のコネクターの socket-binding 属性を無効にして、以下のように追加の属性 を使用する必要があります。

<rest-connector name="rest-1" cache-container="local"/>
<rest-connector name="rest-2" cache-container="local"/>
<hotrod-connector name="hotrod-1" cache-container="local" />
<hotrod-connector name="hotrod-2" cache-container="local" />

次の手順では、新しい router-connector エンドポイントを追加し、他のコンテナーにアクセスする方法を設定します。Hot Rod コネクターには、TLS/SNI および REST コネクターを使用する必要があるため、URL で接頭辞を使用する必要があります。

<router-connector hotrod-socket-binding="hotrod" rest-socket-binding="rest" keep-alive="true" tcp-nodelay="false" receive-buffer-size="1024" send-buffer-size="1024">
    <hotrod name="hotrod-1" >
        <sni host-name="hotrod-1" security-realm="SSLRealm1"/>
    </hotrod>
    <hotrod name="hotrod-2" >
        <sni host-name="hotrod-2" security-realm="SSLRealm2"/>
    </hotrod>
    <rest name="rest-1">
        <prefix path="rest-1" />
    </rest>
    <rest name="rest-2">
        <prefix path="rest-2" />
    </rest>
</router-connector>

以下の設定では、SNI Host Name "hotrod-1 " を使用する場合に Hot Rod-1 コネクターにアクセスします。REST クライアントは以下の URL を使用して "rest-1" コネクター( https://<server_ip>:<server_port>/rest/rest-1 )にアクセスする必要があります。