Data Grid Server ガイド


Red Hat Data Grid 8.0

Data Grid のドキュメント

概要

Data Grid Server を設定、実行、監視し、リモートクライアントアプリケーションからデータにアクセスします。

第1章 Red Hat Data Grid

Data Grid は、高性能の分散型インメモリーデータストアです。

スキーマレスデータ構造
さまざまなオブジェクトをキーと値のペアとして格納する柔軟性があります。
グリッドベースのデータストレージ
クラスター間でデータを分散および複製するように設計されています。
エラスティックスケーリング
サービスを中断することなく、ノードの数を動的に調整して要件を満たします。
データの相互運用性
さまざまなエンドポイントからグリッド内のデータを保存、取得、およびクエリーします。

1.1. Data Grid のドキュメント

Data Grid のドキュメントは、Red Hat カスタマーポータルで入手できます。

1.2. Data Grid のダウンロード

Red Hat カスタマーポータルで Data Grid Software Downloads にアクセスします。

注記

Data Grid ソフトウェアにアクセスしてダウンロードするには、Red Hat アカウントが必要です。

第2章 Getting Started with Data Grid Server

Data Grid Server を素早く設定し、基本情報を確認します。

2.1. Data Grid Server の要件

Data Grid サーバーのホストシステム要件を確認してください。

Red Hat Data Grid でサポートされている設定 を参照してください。

2.2. サーバー分布のダウンロード

Data Grid サーバーディストリビューションは、Java ライブラリー (JAR ファイル)、設定ファイル、および data ディレクトリーのアーカイブです。

手順

  1. Red Hat カスタマーポータルにアクセスします。
  2. ソフトウェアダウンロードセクション から Red Hat Data Grid 8.0 サーバーをダウンロードします。

検証

チェックサムを使用して、ダウンロードの整合性を検証します。

  1. 以下のように、サーバーダウンロードアーカイブを引数として、md5sum または sha256sum を実行します。

    $ sha256sum jboss-datagrid-${version}-server.zip
  2. Data Grid Software Details ページで MD5 または SHA-256 チェックサムの値と比較します。

参照資料

Data Grid Server README には、サーバーディストリビューションの内容が記載されています。

2.3. Data Grid Server のインストール

Data Grid サーバーのアーカイブを、ホストの任意のディレクトリーに展開します。

手順

以下のように、サーバーアーカイブで抽出ツールを使用します。

$ unzip infinispan-server-${version}.zip

作成されたディレクトリーは $RHDG_HOME です。

2.4. Data Grid サーバーの実行

クラスターを自動的に形成する Data Grid サーバーインスタンスをスピンアップします。データを保管するためのキャッシュ定義の作成方法を説明します。

2.4.1. Data Grid Server の起動

起動スクリプトで Data Grid サーバーを起動します。

手順

  1. $RHDG_HOME でターミナルを開きます。
  2. server スクリプトを実行します。

    Linux
    $ bin/server.sh
    Microsoft Windows
    bin\server.bat

    サーバーログには以下のメッセージが表示されます。

    ISPN080004: Protocol SINGLE_PORT listening on 127.0.0.1:11222
    
    ISPN080001: Data Grid Server <$version> started in <mm>ms

Hello Data Grid!

  • ブラウザーで 127.0.0.1:11222 を開き、Data Grid コンソールにアクセスします。

参照資料

Data Grid Server README では、server スクリプトのコマンドライン引数を説明します。

2.4.2. Data Grid クラスター検出の確認

デフォルトでは、同じネットワークで実行している Data Grid サーバーは、MPING プロトコルを使用して相互に検出します。

この手順では、同じホストで 2 つの Data Grid サーバーを起動し、クラスタービューを検証する方法を説明します。

前提条件

ホストで Data Grid サーバーインスタンスを開始します。

手順

  1. 新しい Data Grid サーバーインスタンスをインストールして実行します。

    1. $RHDG_HOME でターミナルを開きます。
    2. root ディレクトリーを server2 にコピーします。

      $ cp -r server server2
  2. ポートオフセットと server2 ルートディレクトリーの場所を指定します。

    $ bin/server.sh -o 100 -s server2

検証

サーバーログで以下のメッセージを確認します。

INFO  [org.infinispan.CLUSTER] (jgroups-11,<server_hostname>)
ISPN000094: Received new cluster view for channel cluster:
[<server_hostname>|3] (2) [<server_hostname>, <server2_hostname>]

INFO  [org.infinispan.CLUSTER] (jgroups-11,<server_hostname>)
ISPN100000: Node <server2_hostname> joined the cluster

2.5. Data Grid CLI を使用した操作の実行

Data Grid コマンドラインインターフェイス (CLI) を使用してサーバーに接続し、データにアクセスして管理機能を実行します。

2.5.1. Data Grid CLI の起動

以下のように Data Grid CLI を起動します。

  1. $ISPN_HOME でターミナルを開きます。
  2. CLI を実行します。

    $ bin/cli.sh
    [disconnected]>

2.5.2. Data Grid Server への接続

次のいずれかを行います。

  • connect コマンドを実行して、デフォルトのポート 11222 の Data Grid サーバーに接続します。

    [disconnected]> connect
    [hostname1@cluster//containers/default]>
  • Data Grid サーバーの場所を指定します。たとえば、ポートオフセットが 100 のローカルサーバーに接続します。

    [disconnected]> connect 127.0.0.1:11322
    [hostname2@cluster//containers/default]>
ヒント

Tab キーを押して、使用可能なコマンドとオプションを表示します。-h オプションを使用して、ヘルプテキストを表示します。

2.5.3. テンプレートからのキャッシュの作成

Data Grid キャッシュテンプレートを使用して、推奨されるデフォルト設定でキャッシュを追加します。

手順

  1. テンプレートからの分散同期キャッシュを作成し、mycache という名前を付けます。

    [//containers/default]> create cache --template=org.infinispan.DIST_SYNC mycache
    ヒント

    --template= 引数の後に Tab キーを押して、利用可能なキャッシュテンプレートを一覧表示します。

  2. キャッシュ設定を取得します。

    [//containers/default]> describe caches/mycache
    {
      "distributed-cache" : {
        "mode" : "SYNC",
        "remote-timeout" : 17500,
        "state-transfer" : {
          "timeout" : 60000
        },
        "transaction" : {
          "mode" : "NONE"
        },
        "locking" : {
          "concurrency-level" : 1000,
          "acquire-timeout" : 15000,
          "striping" : false
        },
        "statistics" : true
      }
    }

2.5.4. キャッシュエントリーの追加

Data Grid CLI でキャッシュにデータを追加します。

前提条件

  • mycache という名前のキャッシュを作成し、そのキャッシュに cd を作成します。

    [//containers/default]> cd caches/mycache

手順

  1. エントリーを "mycache" に追加します。

    [//containers/default/caches/mycache]> put hello world
    ヒント

    キャッシュのコンテキストにない場合は、--cache= パラメーターを使用します。以下に例を示します。

    [//containers/default]> put --cache=mycache hello world
  2. エントリーを取得して確認します。

    [//containers/default/caches/mycache]> get hello
    world

2.5.5. Data Grid サーバーのシャットダウン

CLI を使用して、実行中のサーバーを正常にシャットダウンします。これにより、Data Grid はすべてのエントリーをディスクに渡し、その状態を維持します。

  • shutdown server コマンドを使用して、個々のサーバーを停止します。

    [//containers/default]> shutdown server $hostname
  • shutdown cluster コマンドを使用して、クラスターに参加しているサーバーをすべて停止します。

    [//containers/default]> shutdown cluster

検証

サーバーログで以下のメッセージを確認します。

ISPN080002: Data Grid Server stopping
ISPN000080: Disconnecting JGroups channel cluster
ISPN000390: Persisted state, version=<$version> timestamp=YYYY-MM-DDTHH:MM:SS
ISPN080003: Data Grid Server stopped

第3章 Data Grid サーバーネットワークの設定

Data Grid サーバーを使用すると、ネットワーク全体でエンドポイントを使用できるようにインターフェイスとポートを設定できます。

デフォルトでは、Data Grid サーバーは単一の TCP/IP ポートへの多重エンドポイントを多重化し、受信クライアント要求のプロトコルを自動的に検出します。

3.1. サーバーインターフェイス

Data Grid サーバーは、異なるストラテジーを使用して IP アドレスにバインドできます。

3.1.1. アドレスストラテジー

単一 public インターフェイスを IPv4 ループバックアドレス (127.0.0.1) にマップする inet-address 戦略を使用します。

<interfaces>
  <interface name="public">
    <inet-address value="${infinispan.bind.address:127.0.0.1}"/>
  </interface>
</interfaces>
ヒント

CLI -b 引数または infinispan.bind.address プロパティーを使用して、コマンドラインから特定のアドレスを選択できます。デフォルトバインドアドレスの変更 を参照してください。

3.1.2. ループバックストラテジー

ループバックアドレスを選択します。

  • IPv4 アドレスブロック 127.0.0.0/8 はループバックアドレス用に予約されています。
  • IPv6 アドレスブロック ::1 はループバックアドレスのみになります。
<interfaces>
    <interface name="public">
        <loopback/>
    </interface>
</interfaces>

3.1.3. 非 Loopback ストラテジー

非ループバックアドレスを選択します。

<interfaces>
    <interface name="public">
        <non-loopback/>
    </interface>
</interfaces>

3.1.4. ネットワークアドレスストラテジー

IP アドレスに基づいてネットワークを選択します。

<interfaces>
    <interface name="public">
        <inet-address value="10.1.2.3"/>
    </interface>
</interfaces>

3.1.5. 任意のアドレスストラテジー

INADDR_ANY ワイルドカードアドレスを選択します。その結果、Data Grid サーバーはすべてのインターフェイスでリッスンします。

<interfaces>
    <interface name="public">
        <any-address/>
    </interface>
</interfaces>

3.1.7. サイトのローカルストラテジー

サイトローカル (プライベート) の IP アドレスを選択します。

  • IPv4 アドレスブロック 10.0.0.0/8172.16.0.0/12、および 192.168.0.0/16 はサイトローカルアドレス指定用に予約されています。
  • IPv6 アドレスブロック fc00::/7 はサイトローカルユニキャストアドレス用に予約されます。
<interfaces>
    <interface name="public">
        <inet-address value="10.1.2.3"/>
    </interface>
</interfaces>

3.1.8. ホストストラテジーの一致

ホスト名を解決し、任意のネットワークインターフェイスに割り当てられている IP アドレスの 1 つを選択します。

Data Grid サーバーは、使用可能なすべてのオペレーティングシステムインターフェイスを列挙して、設定内のホスト名から解決された IP アドレスを見つけます。

<interfaces>
    <interface name="public">
        <match-host value="my_host_name"/>
    </interface>
</interfaces>

3.1.9. マッチインターフェイス戦略

正規表現に一致するネットワークインターフェイスに割り当てられた IP アドレスを選択します。

Data Grid サーバーは、使用可能なすべてのオペレーティングシステムインターフェイスを列挙して、設定内のインターフェイス名を見つけます。

ヒント

柔軟性を高めるために、この戦略では正規表現を使用してください。

<interfaces>
    <interface name="public">
        <match-interface value="eth0"/>
    </interface>
</interfaces>

3.1.10. マッチアドレスストラテジー

inet-address と同様ですが、正規表現を使用して IP アドレスを選択します。

Data Grid サーバーは、使用可能なすべてのオペレーティングシステムインターフェイスを列挙して、設定内の IP アドレスを特定します。

ヒント

柔軟性を高めるために、この戦略では正規表現を使用してください。

<interfaces>
    <interface name="public">
        <match-address value="132\..*"/>
    </interface>
</interfaces>

3.1.11. フォールバックストラテジー

インターフェイス設定には、複数の戦略を含めることができます。Data Grid サーバーは、宣言された順序で各ストラテジーを試みます。

たとえば、次の設定では、Data Grid サーバーは最初にホストの照合を試み、次に IP アドレスを照合し、次に INADDR_ANY ワイルドカードアドレスにフォールバックします。

<interfaces>
    <interface name="public">
        <match-host value="my_host_name"/>
        <match-address value="132\..*"/>
        <any-address/>
    </interface>
</interfaces>

3.1.12. Data Grid Server のデフォルトのバインドアドレスの変更

サーバー -b スイッチまたは infinispan.bind.address システムプロパティーを使用して、別のアドレスにバインドできます。

たとえば、以下のように public インターフェイスを 127.0.0.2 にバインドします。

Linux
$ bin/server.sh -b 127.0.0.2
Windows
bin\server.bat -b 127.0.0.2

3.2. ソケットバインディング

ソケットバインディングは、エンドポイントコネクターをサーバーインターフェイスおよびポートにマッピングします。

デフォルトでは、Data Grid サーバーは以下のソケットバインディングを提供します。

<socket-bindings default-interface="public" port-offset="${infinispan.socket.binding.port-offset:0}">
    <socket-binding name="default" port="${infinispan.bind.port:11222}"/>
    <socket-binding name="memcached" port="11221"/>
</socket-bindings>
  • socket-bindings は、デフォルトのインターフェイスとポートオフセットを宣言します。
  • default は、hotrod と rest コネクターをデフォルトのポート 11222 にバインドします。
  • memcached は、memcached コネクターをポート 11221 にバインドします。

    注記

    memcached エンドポイントはデフォルトで無効にされます。

socket-binding 宣言のデフォルトインターフェイスをオーバーライドするには、interface 属性を指定します。

たとえば、"private" という名前の interface 宣言を追加します。

<interfaces>
  ...
  <interface name="private">
    <inet-address value="10.1.2.3"/>
  </interface>
</interfaces>

続いて、以下のように、socket-binding 宣言で interface="private" を指定して、プライベート IP アドレスにバインドすることができます。

<socket-bindings default-interface="public" port-offset="${infinispan.socket.binding.port-offset:0}">
  ...
  <socket-binding name="private_binding" interface="private" port="1234"/>
</socket-bindings>

3.2.1. ポートオフセットの指定

同じホストで複数のインスタンスを実行する場合は、Data Grid サーバーでポートオフセットを設定します。デフォルトのポートオフセットは 0 です。

Data Grid CLI または infinispan.socket.binding.port-offset システムプロパティーで -o スイッチを使用して、ポートオフセットを設定します。

たとえば、以下のようにオフセットが 100 のサーバーインスタンスを起動します。デフォルトの設定では、これにより、Data Grid Server がポート 11322 でリッスンします。

Linux
$ bin/server.sh -o 100
Windows
bin\server.bat -o 100

3.3. Data Grid プロトコルの処理

Data Grid サーバーはルーターコネクターを使用して、同じ TCP ポート 11222 で複数のプロトコルを公開します。複数のプロトコルに単一のポートを使用すると、設定と管理が簡素化され、権限のないユーザーの攻撃対象領域が減少するため、セキュリティーが向上します。

Data Grid サーバーは、ポート 11222 を介して HTTP/1.1、HTTP/2、および Hot Rod プロトコル要求を次のように処理します。

HTTP/1.1 アップグレードヘッダー
クライアントリクエストには HTTP/1.1 アップグレード ヘッダーフィールドが含まれ、Data Grid サーバーとの HTTP/1.1 接続を開始できます。次に、クライアントアプリケーションは Upgrade: protocol ヘッダーフィールドを送信できます。protocol は Data Grid サーバーエンドポイントです。
Application-Layer Protocol Negotiation (ALPN)/Transport Layer Security (TLS)
クライアントアプリケーションは、Data Grid サーバーエンドポイントのサーバー名表示 (SNI) マッピングを指定して、安全な方法でプロトコルをネゴシエートします。
Hot Rod の自動検出
シングルポートルーター設定に Hot Rod が含まれている場合、Hot Rod ヘッダーを含むクライアント要求は自動的に Hot Rod エンドポイントにルーティングされます。

3.3.1. ALPN 用クライアントの設定

Data Grid サーバーと TLS ハンドシェイク時に、プロトコルネゴシエーションの ALPN メッセージを提供するようにクライアントを設定します。

前提条件

  • 暗号化で Data Grid サーバーエンドポイントを有効にします。

手順

  1. Data Grid サーバーとの ALPN/TLS エクスチェンジを処理する適切なライブラリーをクライアントアプリケーションに提供します。

    注記

    Data Grid は、Java に Wildfly OpenSSL バインディングを使用します。

  2. トラストストアでクライアントを適宜設定します。

プログラムで

ConfigurationBuilder builder = new ConfigurationBuilder()
      .addServers("127.0.0.1:11222");

builder.security().ssl().enable()
      .trustStoreFileName("truststore.pkcs12")
      .trustStorePassword(DEFAULT_TRUSTSTORE_PASSWORD.toCharArray());

RemoteCacheManager remoteCacheManager = new RemoteCacheManager(builder.build());
RemoteCache<String, String> cache = remoteCacheManager.getCache("default"");

Hot Rod クライアントプロパティー

infinispan.client.hotrod.server_list = 127.0.0.1:11222
infinispan.client.hotrod.use_ssl = true
infinispan.client.hotrod.trust_store_file_name = truststore.pkcs12
infinispan.client.hotrod.trust_store_password = trust_store_password

参照資料

第4章 Data Grid Server エンドポイントの設定

Data Grid サーバーは、リモートクライアントアプリケーションからのリクエストを処理するリスナーエンドポイントを提供します。

4.1. Data Grid のエンドポイント

Data Grid エンドポイントは、異なるコネクタープロトコルで CacheManager インターフェイスを公開し、データをリモートでアクセスし、Data Grid クラスターを管理および維持するための操作を実行することができます。

異なるソケットバインディングで複数のエンドポイントコネクターを定義できます。

4.1.1. Hot Rod

Hot Rod は、テキストベースのプロトコルと比較して、データへのアクセス時間を短縮し、パフォーマンスを向上するために設計されたバイナリー TCP クライアントサーバープロトコルです。

Data Grid は、Java、C++、C#、Node.js、およびその他のプログラミング言語で Hot Rod クライアントライブラリーを提供します。

トポロジーの状態遷移

Data Grid はトポロジーキャッシュを使用して、クライアントにクラスタービューを提供します。トポロジーキャッシュには、内部 JGroups トランスポートアドレスを公開された Hot Rod エンドポイントにマッピングするエントリーが含まれます。

クライアントが要求を送信すると、Data Grid サーバーは、要求ヘッダーのトポロジー ID をキャッシュからのトポロジー ID と比較します。クライアントに古いトポロジー ID がある場合は、Data Grid サーバーは新しいトポロジービューを送信します。

クラスタートポロジービューを使用すると、Hot Rod クライアントは、ノードがいつ参加および離脱するかを即座に検出できるため、動的な負荷分散とフェイルオーバーが可能になります。

分散キャッシュモードでは、一貫性のあるハッシュアルゴリズムにより、Hot Rod クライアント要求をプライマリー所有者に直接ルーティングすることもできます。

4.1.2. REST

参照資料

Data Grid は、HTTP クライアントがデータにアクセスし、クラスターを監視および保守し、管理操作を実行できるようにする RESTful インターフェイスを公開します。

標準の HTTP ロードバランサーを使用して、クライアントに負荷分散およびフェイルオーバー機能を提供できます。ただし、HTTP ロードバランサーは静的クラスタービューを維持し、クラスタートポロジーの変更が発生したときに手動で更新する必要があります。

4.1.3. プロトコルの比較

表4.1 参照資料
 Hot RodHTTP / REST

トポロジー対応

Y

N

ハッシュ対応

Y

N

暗号化

Y

Y

認証

Y

Y

条件付き操作

Y

Y

バルク操作

Y

N

トランザクション

Y

N

リスナー

Y

N

クエリー

Y

Y

実行

Y

N

クロスサイトフェイルオーバー

Y

N

4.2. エンドポイントコネクター

ソケットバインディング、認証メカニズム、および暗号化設定を指定するコネクター宣言で、Data Grid サーバーエンドポイントを設定します。

デフォルトのエンドポイントコネクター設定は以下のとおりです。

<endpoints socket-binding="default">
   <hotrod-connector name="hotrod"/>
   <rest-connector name="rest"/>
   <memcached-connector socket-binding="memcached"/>
</endpoints>
  • endpoints には、エンドポイントコネクター宣言が含まれ、デフォルトのソケットバインディング、セキュリティーレルム、クライアントが有効な TLS 証明書を表示する必要があるかどうかなどのエンドポイントのグローバル設定を定義します。
  • <hotrod-connector name="hotrod"/> は、Hot Rod コネクターを宣言します。
  • <rest-connector name="rest"/> は、Hot Rod コネクターを宣言します。
  • <memcached-connector socket-binding="memcached"/> は memcached ソケットバインディングを使用する Memcached コネクターを宣言します。

参照資料

urn:infinispan:server スキーマは利用可能なすべてのエンドポイント設定を提供します。

4.2.1. Hot Rod コネクター

Hot Rod コネクター宣言は Hot Rod サーバーを有効にします。

<hotrod-connector name="hotrod">
  <topology-state-transfer />
  <authentication>
    ...
  </authentication>
  <encryption>
    ...
  </encryption>
</hotrod-connector>
  • name="hotrod" は、Hot Rod コネクターに論理的に名前を付けます。
  • topology-state-transfer は、Hot Rod クライアントにクラスタートポロジーを提供する状態遷移操作を調整します。
  • authentication は SASL 認証メカニズムを設定します。
  • encryption は、クライアント接続の TLS 設定を設定します。

参照資料

urn:infinispan:server スキーマは、使用可能なすべての Hot Rod コネクター設定を提供します。

4.2.2. REST コネクター

REST コネクター宣言は REST サーバーを有効にします。

<rest-connector name="rest">
  <authentication>
    ...
  </authentication>
  <cors-rules>
    ...
  </cors-rules>
  <encryption>
    ...
  </encryption>
</rest-connector>
  • name="rest" は、REST コネクターに論理的に名前を付けます。
  • authentication は認証メカニズムを設定します。
  • cors-rules は、クロスドメイン要求の CORS (Cross Origin Resource Sharing) ルールを指定します。
  • encryption は、クライアント接続の TLS 設定を設定します。

参照資料

urn:infinispan:server スキーマは利用可能なすべての REST コネクター設定を提供します。

第5章 Data Grid サーバーの監視

5.1. Working with Data Grid Server Logs

Data Grid は Apache Log4j 2 を使用して、トラブルシューティング目的および根本原因分析のための環境およびレコードキャッシュ操作の詳細を取得する設定可能なロギングメカニズムを提供します。

5.1.1. Data Grid のログファイル

Data Grid は、ログメッセージを次のディレクトリーに書き込みます。
$RHDG_HOME/${infinispan.server.root}/log

server.log
サーバーの起動に関連する起動ログなど、人間が判読できる形式のメッセージ。
Data Grid は、サーバーの起動時にデフォルトでこのファイルを作成します。
server.log.json
Data Grid ログを解析および分析できる JSON 形式のメッセージ。
JSON-FILE アペンダーを有効にすると、Data Grid はこのファイルを作成します。

5.1.2. データグリッドログプロパティーの設定

Log4j2 の マニュアル で説明されている log4j2.xml を使用して Data Grid ログを設定します。

手順

  1. 任意のテキストエディターで $RHDG_HOME/${infinispan.server.root}/conf/log4j2.xml を開きます。
  2. 必要に応じてロギング設定を変更します。
  3. log4j2.xml を保存し、閉じます。
5.1.2.1. ログレベル

ログレベルは、メッセージの性質と重大度を示します。

ログレベル説明

TRACE

粒度の細かいデバッグメッセージ。アプリケーションを介して個々のリクエストのフローをキャプチャーします。

DEBUG

個々のリクエストと関連性のない、一般的なデバッグのメッセージ。

INFO

ライフサイクルイベントを含む、アプリケーションの全体的な進捗状況に関するメッセージ。

WARN

エラーやパフォーマンスの低下につながる可能性のあるイベント。

ERROR

操作またはアクティビティーの正常な実行を妨げる可能性がありますが、アプリケーションの実行は妨げないエラー状態。

FATAL

重大なサービス障害やアプリケーションのシャットダウンを引き起こす可能性のあるイベント。

上記の個々のメッセージのレベルに加えて、この設定では、ALL (すべてのメッセージを含む) と OFF (すべてのメッセージを除外) のさらに 2 つの値を可能にします。

5.1.2.2. Data Grid ログカテゴリー

Data Grid は、機能領域ごとにログを整理する INFOWARNERRORFATAL のレベルのメッセージのカテゴリーを提供します。

org.infinispan.CLUSTER
状態遷移操作、イベントのリバランス、パーティション設定などが含まれる Data Grid クラスターリング固有のメッセージ。
org.infinispan.CONFIG
Data Grid 設定固有のメッセージ
org.infinispan.CONTAINER
有効期限とエビクション操作、キャッシュリスナーの通知、トランザクションなどを含むデータコンテナーに固有のメッセージ。
org.infinispan.PERSISTENCE
キャッシュローダーとストアに固有のメッセージ。
org.infinispan.SECURITY
Data Grid のセキュリティーに固有のメッセージ。
org.infinispan.SERVER
Data Grid Server に固有のメッセージ。
org.infinispan.XSITE
クロスサイトレプリケーション操作に固有のメッセージ。
5.1.2.3. ログアペンダー

ログアペンダーは、Data Grid によるログメッセージの記録方法を定義します。

CONSOLE
ログメッセージをホストの標準出力 (stdout) または標準エラー (stderr) ストリームに書き込みます。
デフォルトで org.apache.logging.log4j.core.appender.ConsoleAppender クラスを使用します。
FILE
ファイルにログメッセージを書き込みます。
デフォルトで org.apache.logging.log4j.core.appender.RollingFileAppender クラスを使用します。
JSON-FILE
ログメッセージを JSON 形式でファイルに書き込みます。
デフォルトで org.apache.logging.log4j.core.appender.RollingFileAppender クラスを使用します。
5.1.2.4. ログパターン

CONSOLE および FILE アペンダーは、PatternLayout を使用して、pattern に従ってログメッセージをフォーマットします。


%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p (%t) [%c{1}] %m%throwable%n は、FILE アペンダーのデフォルトのパターンの例になります。

  • %d{yyyy-MM-dd HH:mm:ss,SSS} は現在の日時を追加します。
  • %-5p は、ログレベルを右揃えで指定します。
  • %t は、現在のスレッドの名前を追加します。
  • %c{1} はロギングカテゴリーの短縮名を追加します。
  • %m はログメッセージを追加します。
  • %throwable は例外スタックトレースを追加します。
  • %n は改行を追加します。

パターンについては、 PatternLayout ドキュメント で詳細に説明されています。

5.1.2.5. JSON ログハンドラーの有効化および設定

Data Grid は、JSON 形式でメッセージを書き込む JSON ログハンドラーを提供します。

前提条件

Data Grid が実行されていないことを確認します。ログハンドラーは動的に有効にすることはできません。

手順

  1. 任意のテキストエディターで $RHDG_HOME/${infinispan.server.root}/conf/log4j2.xml を開きます。
  2. JSON-FILE アペンダーのコメントを解除して、FILE アペンダーをコメントアウトします。

          <!--<AppenderRef ref="FILE"/>-->
          <AppenderRef ref="JSON-FILE"/>
  3. オプションで、JSON アペンダーレイアウト を設定します。
  4. logging.properties を保存して閉じます。

Data Grid を起動すると、各ログメッセージが JSON マップとして以下のファイルに書き込みます。
$RHDG_HOME/${infinispan.server.root}/log/server.log.json

5.1.3. アクセスログ

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

  • Hotgitops エンドポイントの org.infinispan.HOTROD_ACCESS_LOG ロギングカテゴリー。
  • REST エンドポイントの org.infinispan.REST_ACCESS_LOG ロギングカテゴリー。
5.1.3.1. アクセスログの有効化

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

<Logger name="org.infinispan.HOTROD_ACCESS_LOG" additivity="false" level="INFO">
   <AppenderRef ref="HR-ACCESS-FILE"/>
</Logger>
5.1.3.2. アクセスログのプロパティー

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

`%X{address} %X{user} [%d{dd/MMM/yyyy:HH:mm:ss Z}] &quot;%X{method} %m %X{protocol}&quot; %X{status} %X{requestSize} %X{responseSize} %X{duration}%n`

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

127.0.0.1 - [DD/MM/YYYY:HH:MM:SS +0000] "PUT /rest/v2/caches/default/key HTTP/1.1" 404 5 77 10

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

プロパティー説明

address

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

user

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

メソッド

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

protocol

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

status

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

requestSize

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

responseSize

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

duration

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

ヒント

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

5.2. 統計、メトリクス、および JMX の設定

DataGrid が MicroProfileMetrics エンドポイントまたは Data Grid を介してエクスポートする統計を有効にします。JMX MBean を登録することで、管理操作を実施することもできます。

5.2.1. Data Grid 統計の有効化

Data Grid を使用すると、キャッシュマネージャーと特定のキャッシュインスタンスの統計を有効にできます。

注記

Data Grid サーバーは、キャッシュマネージャーの統計を有効にするデフォルト の infinispan.xml 設定ファイルを提供します。デフォルトの Data Grid サーバー設定を使用する場合は、キャッシュを設定する場合にのみ統計を有効にする必要があります。

手順

  • 統計を宣言的またはプログラムで有効にします。

宣言的に

<cache-container statistics="true"> 1
  <local-cache name="mycache" statistics="true"/> 2
</cache-container>

1
Cache Manager の統計を収集します。
2
名前付きキャッシュに関する統計を収集します。

プログラムで

GlobalConfiguration globalConfig = new GlobalConfigurationBuilder()
  .cacheContainer().statistics(true) 1
  .build();

 ...

Configuration config = new ConfigurationBuilder()
  .statistics().enable() 2
  .build();

1
Cache Manager の統計を収集します。
2
名前付きキャッシュに関する統計を収集します。
注記

キャッシュマネージャーの統計を有効にしても、キャッシュの統計はグローバルに有効にはなりません。この設定は、Cache Manager の統計のみを収集します。

5.2.2. Data Grid メトリクスの有効化

Data Grid は Eclipse MicroProfile Metrics API と互換性があり、ゲージおよびヒストグラムメトリクスを生成することができます。

  • Data Grid メトリクスは、vendor スコープで提供されます。JVM に関連するメトリクスは、Data Grid サーバーの base スコープで提供されます。
  • ゲージは、書き込み操作または JVM アップタイムの平均数 (ナノ秒) などの値を指定します。ゲージはデフォルトで有効になっています。統計を有効にすると、Data Grid はゲージを自動的に生成します。
  • ヒストグラムは、読み取り、書き込み、削除の時間などの操作実行時間の詳細を提供します。Data Grid では追加の計算が必要になるため、デフォルトではヒストグラムは有効になりません。

手順

  • メトリクスを宣言的またはプログラム的に設定する。

宣言的に

<cache-container statistics="true"> 1
  <metrics gauges="true" histograms="true" /> 2
</cache-container>

プログラムで

GlobalConfiguration globalConfig = new GlobalConfigurationBuilder()
  .statistics().enable() 1
  .metrics().gauges(true).histograms(true) 2
  .build();

1 1
Cache Manager の統計を計算し、収集します。
2 2
統計をゲージおよびヒストグラムメトリクスとして収集します。

5.2.3. Data Grid メトリクスの収集

Prometheus などのモニターリングツールを使用して、Data Grid メトリクスを収集します。

前提条件

  • 統計を有効にします。統計を有効にしないと、Data Grid はメトリクスに 0-1 の値を指定します。
  • 必要に応じて、ヒストグラムを有効にします。デフォルトでは、Data Grid はゲージを生成しますが、ヒストグラムは生成しません。

手順

  • Prometheus (OpenMetrics) 形式でメトリクスを取得します。

    $ curl -v http://localhost:11222/metrics
  • MicroProfile JSON 形式でメトリクスを取得します。

    $ curl --header "Accept: application/json" http://localhost:11222/metrics

次のステップ

Data Grid メトリクスを収集するようにモニターリングアプリケーションを設定します。たとえば、以下を prometheus.yml に追加します。

static_configs:
    - targets: ['localhost:11222']

5.2.4. JMX の有効化および設定

Data Grid サーバーとともに JMX を有効にして、統計を収集し、管理操作を実施することができます。

注記

管理操作のみを使用する場合は、統計を有効にしなくても JMX を有効にできます。この場合、Data Grid はすべての統計に対して 0 値を提供します。

手順

  • JMX を宣言的またはプログラム的に有効にします。

宣言的に

<cache-container>
  <jmx enabled="true" /> 1
</cache-container>

プログラムで

GlobalConfiguration globalConfig = new GlobalConfigurationBuilder()
  .jmx().enable() 1
  .build();

1 1
Data Grid JMX MBean を登録します。
5.2.4.1. 複数のキャッシュマネージャーの命名

同じ JVM 上で複数の Data Grid Cache Manager が実行する場合は、競合を防ぐために各 Cache Manager を一意に特定する必要があります。

手順

  • 環境内の各キャッシュマネージャーを一意に識別します。

たとえば、以下の例では、キャッシュマネージャー名として Hibernate2LC を指定します。これにより、org.infinispan:type=CacheManager,name="Hibernate2LC" という名前の JMX MBean が作成されます。

宣言的に

<cache-container name="Hibernate2LC">
  <jmx enabled="true" />
  ...
</cache-container>

プログラムで

GlobalConfiguration globalConfig = new GlobalConfigurationBuilder()
  .cacheManagerName("Hibernate2LC")
  .jmx().enable()
  .build();

5.2.4.2. カスタム MBean サーバーでの MBean の登録

Data Grid には、カスタム MBeanServer インスタンスに MBean を登録するのに使用できる MBeanServerLookup インターフェイスが含まれています。

手順

  1. getMBeanServer() メソッドがカスタム MBeanServer インスタンスを返すように MBeanServerLookup の実装を作成します。
  2. 以下の例のように、クラスの完全修飾名で Data Grid を設定します。

宣言的に

<cache-container>
   <jmx enabled="true" mbean-server-lookup="com.acme.MyMBeanServerLookup" />
</cache-container>

プログラムで

GlobalConfiguration globalConfig = new GlobalConfigurationBuilder()
  .jmx().enable().mBeanServerLookup(new com.acme.MyMBeanServerLookup())
  .build();

5.2.4.3. Data Grid MBean

Data Grid は、管理可能なリソースを表す JMX MBean を公開します。

org.infinispan:type=Cache
キャッシュインスタンスに使用できる属性および操作。
org.infinispan:type=CacheManager
Data Grid キャッシュやクラスターのヘルス統計など、Cache Manager で使用できる属性および操作。

使用できる JMX MBean の詳細な一覧および説明、ならびに使用可能な操作および属性については、Data Grid JMX Components のドキュメントを参照してください。

5.3. サーバーの正常性統計の取得

以下の方法で Data Grid クラスターの正常性を監視します。

  • embeddedCacheManager.getHealth() メソッド呼び出しでプログラマティックに監視
  • JMX MBean
  • Data Grid REST Server

5.3.1. JMX 経由での Health API へのアクセス

JMX 経由で Data Grid クラスターの正常性統計を取得します。

手順

  1. JConsole などの JMX 対応ツールを使用して Data Grid Server に接続し、以下のオブジェクトに移動します。

    org.infinispan:type=CacheManager,name="default",component=CacheContainerHealth
  2. 利用可能な MBean を選択し、クラスターの正常性の統計を取得します。

5.3.2. REST 経由での Health API へのアクセス

REST API 経由で Data Grid クラスターの正常性を取得します。

手順

  • GET 要求を呼び出して、クラスターの正常性を取得します。

    GET /rest/v2/cache-managers/{cacheManagerName}/health

Data Grid は、以下のような JSON ドキュメントで応答します。

{
    "cluster_health":{
        "cluster_name":"ISPN",
        "health_status":"HEALTHY",
        "number_of_nodes":2,
        "node_names":[
            "NodeA-36229",
            "NodeB-28703"
        ]
    },
    "cache_health":[
        {
            "status":"HEALTHY",
            "cache_name":"___protobuf_metadata"
        },
        {
            "status":"HEALTHY",
            "cache_name":"cache2"
        },
        {
            "status":"HEALTHY",
            "cache_name":"mycache"
        },
        {
            "status":"HEALTHY",
            "cache_name":"cache1"
        }
    ]

}
ヒント

以下のように Cache Manager のステータスを取得します。

GET /rest/v2/cache-managers/{cacheManagerName}/health/status

参照資料

詳細は、REST v2 (version 2) API ドキュメントを参照してください。

第6章 Data Grid サーバーのセキュア化

Data Grid サーバーをネットワーク攻撃と不正アクセスから保護します。

6.1. キャッシュの承認

Data Grid は、リクエストにキャッシュ操作の実行を許可することにより、データへのアクセスを制限できます。

Data Grid は、ID、またはタイプ java.security.Principal のプリンシパルを、設定内のセキュリティーロールにマップします。たとえば、reader という名前のプリンシパルは reader という名前のセキュリティーロールにマップされます。

Data Grid を使用すると、さまざまなロールにアクセス許可を割り当てて、キャッシュ操作を許可できます。たとえば、Cache.get() には読み取り権限が必要ですが、Cache.put() には書き込み権限が必要です。

この場合、reader ロールを持つユーザークライアントがエントリーの記述を試みると、Data Grid はリクエストを拒否し、セキュリティー例外を出力します。ただし、writer ロールを持つユーザーのクライアントが書き込みリクエストを送信すると、Data Grid は承認を検証し、後続の操作のためにトークンでクライアントを発行します。

6.1.1. キャッシュ認証設定

キャッシュ承認用の Data Grid 設定は以下のとおりです。

<infinispan>
   <cache-container default-cache="secured" name="secured">
      <security>
         <authorization> 1
            <identity-role-mapper /> 2
            <role name="admin" permissions="ALL" /> 3
            <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" /> 4
         </security>
      </local-cache>
   </cache-container>

</infinispan>
1
キャッシュコンテナーのキャッシュ承認を設定します。
2
プリンシパル名をロールに変換する PrincipalRoleMapper の実装を指定します。
3
ロールに名前を付け、データへのアクセスを制御する権限を割り当てます。
4
キャッシュの許可されたロールを定義します。

6.2. Data Grid サーバーのセキュリティーレルムの定義

セキュリティーレルムは、ID、暗号化、認証、および承認情報を Data Grid サーバーエンドポイントに提供します。

6.2.1. プロパティーレルム

プロパティーレルムはプロパティーファイルを使用して、ユーザーおよびグループを定義します。

users.properties は、ユーザー名をプレーンテキスト形式でパスワードにマッピングします。DIGEST-MD5 SASL メカニズムまたは Digest HTTP メカニズムを使用する場合は、パスワードを事前にダイジェストすることもできます。

myuser=a_password
user2=another_password

groups.properties はユーザーをロールにマッピングします。

supervisor=myuser,user2
reader=myuser
writer=myuser

プロパティーレルム設定

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <properties-realm groups-attribute="Roles"> 1
            <user-properties path="users.properties" 2
                             relative-to="infinispan.server.config.path" 3
                             plain-text="true"/> 4
            <group-properties path="groups.properties" 5
                              relative-to="infinispan.server.config.path"/>
         </properties-realm>
      </security-realm>
   </security-realms>
</security>

1
グループを Data Grid サーバー認証のロールとして定義します。
2
users.properties ファイルを指定します。
3
ファイルが $ISPN_HOME/server/conf ディレクトリーに相対されることを指定します。
4
users.properties のパスワードがプレーンテキスト形式であることを指定します。
5
groups.properties ファイルを指定します。

サポート対象の認証メカニズム

プロパティーレルムは、以下の認証メカニズムをサポートします。

  • SASL: PLAINDIGEST-*、および SCRAM-*
  • HTTP(REST): Basic および Digest
6.2.1.1. プロパティーレルムへのユーザーの追加

Data Grid サーバーは、プロパティーファイルに新しいユーザー/ロールマッピングを簡単に追加できる user-tool スクリプトを提供します。

手順

  1. $ISPN_HOME ディレクトリーに移動します。
  2. bin ディレクトリーで user-tool スクリプトを実行します。

たとえば、supervisor、reader、および writer グループに属するパスワード qwer1234! というパスワードを持つ myuser という名前の新規ユーザーを作成します。

Linux
$ bin/user-tool.sh -u myuser -p "qwer1234!" -g supervisor,reader,writer
Microsoft Windows
$ bin\user-tool.bat -u myuser -p "qwer1234!" -g supervisor,reader,writer

6.2.2. LDAP レルム

LDAP レルムは、OpenLDAP、Red Hat Directory Server、Apache Directory Server、Microsoft Active Directory などの LDAP サーバーに接続して、ユーザーを認証し、メンバーシップ情報を取得します。

注記

LDAP サーバーは、サーバーのタイプとデプロイメントに応じて、異なるエントリーレイアウトを持つことができます。このため、LDAP レルム設定は複雑です。すべてのポジションの設定の例を提供するために、本書では扱いません。

LDAP レルム設定

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
        <ldap-realm name="ldap" 1
                    url="ldap://my-ldap-server:10389" 2
                    principal="uid=admin,ou=People,dc=infinispan,dc=org" 3
                    credential="strongPassword"
                    connection-timeout="3000" read-timeout="30000" 4
                    connection-pooling="true" referral-mode="ignore"
                    page-size="30"
                    direct-verification="true"> 5
            <identity-mapping rdn-identifier="uid" 6
                              search-dn="ou=People,dc=infinispan,dc=org"> 7
               <attribute-mapping> 8
                  <attribute from="cn"
                             to="Roles"
                             filter="(&amp;(objectClass=groupOfNames)(member={1}))"
                             filter-dn="ou=Roles,dc=infinispan,dc=org"/>
               </attribute-mapping>
            </identity-mapping>
         </ldap-realm>
      </security-realm>
   </security-realms>
</security>

1
LDAP レルムに名前を付けます。
2
LDAP サーバー接続 URL を指定します。
3
LDAP サーバーに接続するためのプリンシパルおよび認証情報を指定します。
重要

LDAP 接続のプリンシパルには、LDAP クエリーを実行し、特定の属性にアクセスするために必要な権限が必要です。

4
必要に応じて、接続タイムアウトなどを指定して LDAP サーバー接続を調整します。
5
ユーザーの認証情報を検証します。Data Grid は設定済みの認証情報を使用して LDAP サーバーへの接続を試みます。または、パスワードを指定する user-password-mapper 要素を使用することもできます。
6
LDAP エントリーをアイデンティティーにマッピングします。rdn-identifier は、指定された識別子 (通常はユーザー名) をもとにユーザーエントリーを検索する LDAP 属性を指定します (例: uid または sAMAccountName 属性)。
7
ユーザーエントリーを含む LDAP サブツリーへの検索を制限する開始コンテキストを定義します。
8
ユーザーがメンバーとなっている全グループを取得します。通常、メンバーシップ情報を保存する方法は 2 つあります。
  • 通常、member 属性にクラス groupOfNames を持つグループエントリーの下。この場合は、前述の設定例にあるように、属性フィルターを使用できます。このフィルターは、提供されたフィルターに一致するエントリーを検索します。フィルターは、ユーザーの DN と等しい member 属性を持つグループを検索します。次に、フィルターは、from で指定されたグループエントリーの CN を抽出し、それをユーザーの Roles に追加します。
  • memberOf 属性のユーザーエントリー。この場合、以下のような属性参照を使用する必要があります。

    <attribute-reference reference="memberOf" from="cn" to="Roles" />

    この参照は、ユーザーエントリーからすべての memberOf 属性を取得し、from で指定された CN を抽出し、それらをユーザーの Roles に追加します。

サポート対象の認証メカニズム

LDAP レルムは、以下の認証メカニズムを直接サポートします。

  • SASL: PLAINDIGEST-*、および SCRAM-*
  • HTTP(REST): Basic および Digest
6.2.2.1. LDAP レルムプリンシパルの書き換え

GSSAPIGS2-KRB5Negotiate などの一部の SASL 認証メカニズムでは、LDAP サーバーの検索に使用する前に クリーンアップ する必要のあるユーザー名を提供します。

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <ldap-realm name="ldap"
                     url="ldap://${org.infinispan.test.host.address}:10389"
                     principal="uid=admin,ou=People,dc=infinispan,dc=org"
                     credential="strongPassword">
            <name-rewriter> 1
               <regex-principal-transformer name="domain-remover"
                                            pattern="(.*)@INFINISPAN\.ORG"
                                            replacement="$1"/>
            </name-rewriter>
            <identity-mapping rdn-identifier="uid"
                              search-dn="ou=People,dc=infinispan,dc=org">
               <attribute-mapping>
                  <attribute from="cn" to="Roles"
                             filter="(&amp;(objectClass=groupOfNames)(member={1}))"
                             filter-dn="ou=Roles,dc=infinispan,dc=org" />
               </attribute-mapping>
               <user-password-mapper from="userPassword" />
            </identity-mapping>
         </ldap-realm>
      </security-realm>
   </security-realms>
</security>
1
正規表現を使用してプリンシパルからユーザー名を抽出するリライトを定義します。

6.2.3. トラストストアレルム

トラストストアレルムは、Data Grid サーバーへの接続が許可されるすべてのクライアントのパブリック証明書が含まれるキーストアを使用します。

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities>
            <ssl>
               <keystore path="server.p12" 1
                         relative-to="infinispan.server.config.path" 2
                         keystore-password="secret" 3
                         alias="server"/> 4
            </ssl>
         </server-identities>
         <truststore-realm path="trust.p12" 5
                           relative-to="infinispan.server.config.path"
                           keystore-password="secret"/>
      </security-realm>
   </security-realms>
</security>
1
サーバー証明書が含まれるキーストアを使用して SSL サーバーアイデンティティーを提供します。
2
ファイルが $ISPN_HOME/server/conf ディレクトリーに相対されることを指定します。
3
キーストアパスワードを指定します。
4
キーストアエイリアスを指定します。
5
すべてのクライアントのパブリック証明書が含まれるキーストアを提供します。

サポート対象の認証メカニズム

トラストストアレルムは、クライアント証明書の認証メカニズムと連携します。

  • SASL: EXTERNAL
  • HTTP (REST): CLIENT_CERT

6.2.4. トークンレルム

トークンレルムは外部サービスを使用してトークンを検証し、Red Hat SSO などの RFC-7662 (OAuth2 トークンイントロスペクション) と互換性のあるプロバイダーを必要とします。

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <token-realm name="token"
                      auth-server-url="https://oauth-server/auth/"> 1
            <oauth2-introspection
                    introspection-url="https://oauth-server/auth/realms/infinispan/protocol/openid-connect/token/introspect" 2
                    client-id="infinispan-server" 3
                    client-secret="1fdca4ec-c416-47e0-867a-3d471af7050f"/> 4
         </token-realm>
      </security-realm>
   </security-realms>
</security>
1
認証サーバーの URL を指定します。
2
トークンイントロスペクションエンドポイントの URL を指定します。
3
Data Grid サーバーのクライアント識別子に名前を付けます。
4
Data Grid サーバーのクライアントシークレットを指定します。

サポート対象の認証メカニズム

トークンレルムは、以下の認証メカニズムをサポートします。

  • SASL: OAUTHBEARER
  • HTTP (REST): Bearer

6.3. Data Grid サーバーのアイデンティティーの作成

サーバーアイデンティティーはセキュリティーレルムで定義され、Data Grid サーバーがアイデンティティーをクライアントに証明できるようにします。

6.3.1. SSL アイデンティティーの設定

SSL ID は、証明書または証明書のチェーンのいずれかが含まれるキーストアを使用します。

注記

セキュリティーレルムに SSL アイデンティティーが含まれる場合、Data Grid サーバーはこれらのセキュリティーレルムを使用するエンドポイントの暗号化を自動的に有効にします。

手順

  1. Data Grid サーバーのキーストアを作成します。

    重要

    Data Grid サーバーは JKS、JCEKS、PKCS12、BKS、BCFKS、および UBER のキーストア形式をサポートします。

    実稼働環境では、サーバー証明書は Root または Intermediate CA のいずれかの信頼される認証局によって署名される必要があります。

  2. キーストアを $ISPN_HOME/server/conf ディレクトリーに追加します。
  3. server-identities 定義を Data Grid サーバーのセキュリティーレルムに追加します。
  4. パスワードおよびエイリアスとともにキーストアの名前を指定します。
6.3.1.1. SSL Identity 設定

以下の例では、Data Grid サーバーの SSL アイデンティティーを設定します。

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities> 1
            <ssl> 2
               <keystore path="server.p12" 3
                         relative-to="infinispan.server.config.path" 4
                         keystore-password="secret" 5
                         alias="server"/> 6
            </ssl>
         </server-identities>
      </security-realm>
   </security-realms>
</security>
1
Data Grid サーバーの ID を定義します。
2
Data Grid サーバーの SSL アイデンティティーを設定します。
3
Data Grid サーバーの SSL 証明書が含まれるキーストアに名前を付けます。
4
キーストアが $ISPN_HOMEserver/conf ディレクトリーに相対されることを指定します。
5
キーストアパスワードを指定します。
6
キーストアエイリアスを指定します。
6.3.1.2. キーストアの自動生成

Data Grid サーバーを設定し、起動時にキーストアを自動的に生成します。

重要

自動生成されたキーストア:

  • 実稼働環境では使用しないでください。
  • 必要に応じて生成されます。たとえば、クライアントから最初の接続を取得する際などに生成されます。
  • Hot Rod クライアントで直接使用可能な証明書が含まれます。

手順

  1. サーバー設定に keystore 要素の generate-self-signed-certificate-host 属性を含めます。
  2. サーバー証明書のホスト名を値として指定します。

生成されたキーストアを持つ SSL サーバーアイデンティティー

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities>
            <ssl>
               <keystore path="server.p12"
                         relative-to="infinispan.server.config.path"
                         keystore-password="secret"
                         alias="server"
                         generate-self-signed-certificate-host="localhost"/> 1
            </ssl>
         </server-identities>
      </security-realm>
   </security-realms>
</security>

1
localhost を使用してキーストアを生成します。
6.3.1.3. SSL プロトコルおよび暗号スイートの調整

特定のプロトコルと暗号を使用するように、Data Grid サーバーの SSL アイデンティティー経由で SSL エンジンを設定できます。

重要

使用するプロトコル機能に正しい暗号を設定していることを確認する必要があります。たとえば、HTTP/2ALPN です。

手順

  1. engine 要素を Data Grid サーバーの SSL アイデンティティーに追加します。
  2. enabled-protocols および enabled-ciphersuites 属性を使用して SSL エンジンを設定します。

SSL エンジンの設定

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1
          https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities>
            <ssl>
               <keystore path="server.p12"
                         relative-to="infinispan.server.config.path"
                         keystore-password="secret" alias="server"/>
               <engine enabled-protocols="TLSv1.2 TLSv1.1" 1
                       enabled-ciphersuites="SSL_RSA_WITH_AES_128_GCM_SHA256 2
                       SSL_RSA_WITH_AES_128_CBC_SHA256"/>
            </ssl>
         </server-identities>
      </security-realm>
   </security-realms>
</security>

1
TLS v1 プロトコルおよび v2 プロトコルを使用するように SSL エンジンを設定します。
2
指定された暗号スイートを使用するように SSL エンジンを設定します。

6.3.2. Kerberos アイデンティティーの設定

Kerberos アイデンティティーは、Kerberos パスワードから派生するサービスプリンシパル名と暗号化鍵が含まれる キータブ ファイルを使用します。

注記

キータブ ファイルには、ユーザーとサービスのアカウントプリンシパルの両方を含めることができます。ただし、Data Grid サーバーは、サービスアカウントのプリンシパルのみを使用します。その結果、Data Grid サーバーはクライアントに ID を提供でき、これによりクライアントが Kerberos サーバーで認証できるようになります。

ほとんどの場合、Hot Rod および REST コネクターに一意のプリンシパルを作成します。たとえば、INFINISPAN.ORG ドメインに datagrid サーバーがあるとします。この場合、以下のサービスプリンシパルを作成する必要があります。

  • hotrod/datagrid@INFINISPAN.ORG は Hot Rod サービスを特定します。
  • HTTP/datagrid@INFINISPAN.ORG は REST サービスを識別します。

手順

  1. Hot Rod および REST サービスのキータブファイルを作成します。

    Linux
    $ ktutil
    ktutil:  addent -password -p datagrid@INFINISPAN.ORG -k 1 -e aes256-cts
    Password for datagrid@INFINISPAN.ORG: [enter your password]
    ktutil:  wkt http.keytab
    ktutil:  quit
    Microsoft Windows
    $ ktpass -princ HTTP/datagrid@INFINISPAN.ORG -pass * -mapuser INFINISPAN\USER_NAME
    $ ktab -k http.keytab -a HTTP/datagrid@INFINISPAN.ORG
  2. キータブファイルを $ISPN_HOME/server/conf ディレクトリーにコピーします。
  3. server-identities 定義を Data Grid サーバーのセキュリティーレルムに追加します。
  4. Hot Rod および REST コネクターにサービスプリンシパルを提供するキータブファイルの場所を指定します。
  5. Kerberos サービスプリンシパルに名前を付けます。
6.3.2.1. Kerberos ID 設定

以下の例では、Data Grid サーバーの Kerberos ID を設定します。

<security xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
          xmlns="urn:infinispan:server:10.1">
   <security-realms>
      <security-realm name="default">
         <server-identities> 1
            <kerberos keytab-path="hotrod.keytab" 2
                      principal="hotrod/datagrid@INFINISPAN.ORG" 3
                      required="true"/> 4
            <kerberos keytab-path="http.keytab" 5
                      principal="HTTP/localhost@INFINISPAN.ORG" 6
                      required="true"/>
         </server-identities>
      </security-realm>
   </security-realms>
</security>
1
Data Grid サーバーの ID を定義します。
2
Hotgitops コネクターの Kerberos アイデンティティーを提供する keytab ファイルを指定します。
3
Hotgitops コネクターの Kerberos サービスプリンシパルに名前を付けます。
4
Data Grid サーバーの起動時にキータブファイルが存在する必要があることを指定します。
5
REST コネクターの Kerberos アイデンティティーを提供する keytab ファイルを指定します。
6
REST コネクターの Kerberos サービスプリンシパルに名前を付けます。

6.4. エンドポイント認証メカニズムの設定

クライアントとの認証を行うように、SASL 認証メカニズムで Hotfaillock および REST コネクターを設定します。

6.4.1. Hotot 認証の設定

特定の SASL 認証メカニズムを使用して、クライアントとの認証を Data Grid サーバーセキュリティーレルムに対して認証するように設定します。

手順

  1. Hot Rod コネクター設定に authentication 定義を追加します。
  2. Hot Rod コネクターが認証に使用する Data Grid セキュリティーレルムを指定します。
  3. 使用する Hot Rod エンドポイントの SASL 認証メカニズムを指定します。
  4. 必要に応じて SASL 認証プロパティーを設定します。
6.4.1.1. Hot Rod 認証設定

SCRAM、DIGEST、および PLAIN 認証を使用した Hot Rod コネクター

<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:infinispan:server:10.1
           https://infinispan.org/schemas/infinispan-server-10.1.xsd"
           xmlns="urn:infinispan:server:10.1"
           socket-binding="default" security-realm="default"> 1
   <hotrod-connector name="hotrod">
      <authentication>
         <sasl mechanisms="SCRAM-SHA-512 SCRAM-SHA-384 SCRAM-SHA-256 2
                           SCRAM-SHA-1 DIGEST-SHA-512 DIGEST-SHA-384
                           DIGEST-SHA-256 DIGEST-SHA DIGEST-MD5 PLAIN"
               server-name="infinispan" 3
               qop="auth"/> 4
      </authentication>
   </hotrod-connector>
</endpoints>

1
default という名前のセキュリティーレルムに対する認証を有効にします。
2
認証に使用する SASL メカニズムを指定します。
3
Data Grid サーバーがクライアントに宣言する名前を定義します。サーバー名は、クライアント設定と一致する必要があります。
4
認証 QoP を有効にします。

Kerberos 認証を使用した Hot Rod コネクター

<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
           xmlns="urn:infinispan:server:10.1"
           socket-binding="default" security-realm="default">
   <hotrod-connector name="hotrod">
      <authentication>
         <sasl mechanisms="GSSAPI GS2-KRB5" 1
               server-name="datagrid" 2
               server-principal="hotrod/datagrid@INFINISPAN.ORG"/> 3
      </authentication>
   </hotrod-connector>
</endpoints>

1
Kerberos 認証に GSSAPI および GS2-KRB5 メカニズムを有効にします。
2
Data Grid サーバー名を定義します。これは Kerberos サービス名と同じです。
3
サーバーの Kerberos アイデンティティーを指定します。
6.4.1.2. Hot Rod エンドポイント認証メカニズム

Data Grid は、Hot Rod コネクターを使用して以下の SASL 認証メカニズムをサポートします。

認証メカニズム説明関連する詳細

PLAIN

プレーンテキスト形式の認証情報を使用します。PLAIN 認証は、暗号化された接続でのみ使用する必要があります。

Basic HTTP メカニズムに似ています。

DIGEST-*

ハッシュアルゴリズムとナンス値を使用します。ホットロッドコネクターは、強度の順に、DIGEST-MD5DIGEST-SHADIGEST-SHA-256DIGEST-SHA-384、および DIGEST-SHA-512 ハッシュアルゴリズムをサポートします。

Digest HTTP メカニズムに似ています。

SCRAM-*

ハッシュアルゴリズムとナンス値に加えてソルト値を使用します。ホットロッドコネクターは、SCRAM-SHASCRAM-SHA-256SCRAM-SHA-384、および SCRAM-SHA-512 ハッシュアルゴリズムを強度順にサポートします。

Digest HTTP メカニズムに似ています。

GSSAPI

Kerberos チケットを使用し、Kerberos ドメインコントローラーが必要です。対応する Kerberos サーバー ID をレルム設定に追加する必要があります。ほとんどの場合、ユーザーメンバーシップ情報を提供するために ldap-realm も指定します。

SPNEGO HTTP メカニズムに似ています。

GS2-KRB5

Kerberos チケットを使用し、Kerberos ドメインコントローラーが必要です。対応する Kerberos サーバー ID をレルム設定に追加する必要があります。ほとんどの場合、ユーザーメンバーシップ情報を提供するために ldap-realm も指定します。

SPNEGO HTTP メカニズムに似ています。

EXTERNAL

クライアント証明書を使用します。

CLIENT_CERTHTTP メカニズムに似ています。

OAUTHBEARER

OAuth トークンを使用し、token-realm 設定が必要です。

BEARER_TOKEN HTTP メカニズムに似ています。

6.4.1.3. SASL Quality of Protection (QoP)

SASL メカニズムが整合性とプライバシー保護設定に対応している場合は、qop 属性を使用して Hot Rod コネクター設定に追加することができます。

QoP 設定説明

auth

認証のみ。

auth-int

整合性保護による認証。

auth-conf

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

6.4.1.4. SASL ポリシー

SASL ポリシーを使用すると、Hot Rod コネクターが使用できる認証メカニズムを制御できます。

ポリシー説明デフォルト値

forward-secrecy

セッション間の forward secrecy をサポートする SASL メカニズムのみを使用します。これは、1 つのセッションに分割しても、将来のセッションに分割するための情報が自動的に提供されないことを意味します。

false

pass-credentials

クライアント認証情報が必要な SASL メカニズムのみを使用してください。

false

no-plain-text

単純な受動的攻撃の影響を受けやすい SASL メカニズムは使用しないでください。

false

no-active

アクティブな非辞書攻撃の影響を受けやすい SASL メカニズムは使用しないでください。

false

no-dictionary

受動的な辞書攻撃の影響を受けやすい SASL メカニズムは使用しないでください。

false

no-anonymous

匿名ログインを許可する SASL メカニズムは使用しないでください。

true

ヒント

Data Grid のキャッシュ承認では、ロールおよびパーミッションに基づいてキャッシュへのアクセスを制限します。キャッシュ承認を設定する場合は、<no-anonymous value=false /> を設定して匿名ログインを許可し、アクセスロジックをキャッシュ承認に委任できます。

SASL ポリシー設定の Hot Rod コネクター

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

1
Hotgitops コネクターの複数の SASL 認証メカニズムを指定します。
2
SASL メカニズムのポリシーを定義します。

前述の設定により、Hot Rod コネクターは GSSAPI メカニズムを使用します。これは、すべてのポリシーに準拠する唯一のメカニズムであるためです。

6.4.2. REST 認証の設定

特定の SASL 認証メカニズムを使用して、クライアントとの認証を Data Grid サーバーセキュリティーレルムに対して認証するように設定します。

手順

  1. REST コネクター設定に authentication 定義を追加します。
  2. REST コネクターが認証に使用する Data Grid セキュリティーレルムを指定します。
  3. REST エンドポイントが使用する SASL 認証メカニズムを指定します。
  4. 必要に応じて SASL 認証プロパティーを設定します。
6.4.2.1. REST 認証設定

BASIC および DIGEST 認証による REST コネクター

<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
           xmlns="urn:infinispan:server:10.1"
           socket-binding="default" security-realm="default"> 1
   <rest-connector name="rest">
      <authentication mechanisms="DIGEST BASIC"/> 2
   </rest-connector>
</endpoints>

1
default という名前のセキュリティーレルムに対する認証を有効にします。
2
認証に使用する SASL メカニズムを指定します。

Kerberos 認証による REST コネクター

<endpoints xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
           xmlns="urn:infinispan:server:10.1"
           socket-binding="default" security-realm="default">
   <rest-connector name="rest">
      <authentication mechanisms="SPNEGO" 1
                      server-principal="HTTP/localhost@INFINISPAN.ORG"/> 2
   </rest-connector>
</endpoints>

1
Kerberos 認証の SPENGO メカニズムを有効にします。
2
サーバーの Kerberos アイデンティティーを指定します。
6.4.2.2. REST エンドポイント認証メカニズム

Data Grid は、REST コネクターを使用して以下の認証メカニズムをサポートします。

認証メカニズム説明関連する詳細

BASIC

プレーンテキスト形式の認証情報を使用します。暗号化された接続でのみ BASIC 認証を使用する必要があります。

HTTP Basic HTTP 認証方式に対応し、PLAIN SASL メカニズムと同様です。

DIGEST

ハッシュアルゴリズムとナンス値を使用します。REST コネクターは、SHA-512SHA-256、および MD5 ハッシュアルゴリズムをサポートします。

Digest HTTP 認証スキームに対応し、DIGEST-* SASL メカニズムに似ています。

SPNEGO

Kerberos チケットを使用し、Kerberos ドメインコントローラーが必要です。対応する Kerberos サーバー ID をレルム設定に追加する必要があります。ほとんどの場合、ユーザーメンバーシップ情報を提供するために ldap-realm も指定します。

Negotiate HTTP 認証スキームに対応し、GSSAPI および GS2-KRB5SASL メカニズムに類似しています。

BEARER_TOKEN

OAuth トークンを使用し、token-realm 設定が必要です。

Bearer HTTP 認証スキームに対応し、OAUTHBEARERSASL メカニズムに似ています。

CLIENT_CERT

クライアント証明書を使用します。

EXTERNAL SASL メカニズムに似ています。

第7章 サーバー側のタスクをリモートで実行

Data Grid コマンドラインインターフェイス、REST API、または Hot Rod クライアントから呼び出すことができる Data Grid サーバーにタスクを定義して追加します。

カスタム Java クラスとしてタスクを実装するか、JavaScript などの言語でスクリプトを定義することができます。

7.1. サーバータスクの作成

カスタムタスクの実装を作成し、それらを Data Grid サーバーに追加します。

7.1.1. サーバータスク

Data Grid サーバータスクは、org.infinispan.tasks.ServerTask インターフェイスを拡張するクラスであり、一般的に以下のメソッド呼び出しが含まれます。

setTaskContext()
タスクパラメーター、タスクが実行されるキャッシュ参照などを含む実行コンテキスト情報へのアクセスを許可します。ほとんどの場合、実装はこの情報をローカルに保存し、タスクが実際に実行したときに使用します。
getName()
タスクの一意の名前を返します。クライアントはこれらの名前でタスクを呼び出します。
getExecutionMode()

タスクの実行モードを返します。

  • TaskExecutionMode.ONE_NODE は、要求を処理するノードのみがスクリプトを実行します。ただし、スクリプトはクラスター化された操作を引き続き呼び出すことができます。
  • TaskExecutionMode.ALL_NODES Data Grid は、クラスター化されたエグゼキューターを使用してノード間でスクリプトを実行します。たとえば、ストリーム処理はすべてのノードに分散されるため、ストリーム処理を呼び出したサーバータスクを 1 つのノードで実行する必要があります。
call()
結果を計算します。このメソッドは java.util.concurrent.Callable インターフェイス内で定義され、サーバータスクにより呼び出されます。
重要

サーバータスクの実装は、サービ出力ダーパターンの要件に準拠する必要があります。たとえば、実装にはゼロ引数のコンストラクターが必要です。

以下の HelloTask クラス実装は、1 つのパラメーターを持つタスクの例を提供します。

package example;

import org.infinispan.tasks.ServerTask;
import org.infinispan.tasks.TaskContext;

public class HelloTask implements ServerTask<String> {

   private TaskContext ctx;

   @Override
   public void setTaskContext(TaskContext ctx) {
      this.ctx = ctx;
   }

   @Override
   public String call() throws Exception {
      String name = (String) ctx.getParameters().get().get("name");
      return "Hello " + name;
   }

   @Override
   public String getName() {
      return "hello-task";
   }

}

7.1.2. サーバータスクの Data Grid サーバーへのデプロイメント

カスタムサーバーのタスククラスを Data Grid サーバーに追加します。

前提条件

実行中の Data Grid サーバーを停止します。Data Grid は、カスタムクラスのランタイムデプロイメントをサポートしません。

手順

  1. JAR ファイルでサーバータスクの実装をパッケージ化します。
  2. 以下のように、サーバーのタスクの完全修飾名が含まれる META-INF/services/org.infinispan.tasks.ServerTask ファイルを追加します。

    example.HelloTask
  3. JAR ファイルを Data Grid サーバーの $RHDG_HOME/server/lib ディレクトリーにコピーします。
  4. クラスを Data Grid 設定のデシリアライズホワイトリストに追加します。または、システムプロパティーを使用してホワイトリストを設定します。

7.2. サーバースクリプトの作成

カスタムスクリプトを作成して、Data Grid サーバーに追加します。

7.2.1. サーバースクリプト

Data Grid サーバーのスクリプトは javax.script API をベースとしており、JVM ベースの ScriptEngine 実装と互換性があります。

Hello World スクリプトの例

以下は、1 つの Data Grid サーバーで実行され、1 つのパラメーターを持ち、JavaScript を使用する簡単な例です。

// mode=local,language=javascript,parameters=[greetee]
"Hello " + greetee

上記のスクリプトを実行するときに、greetee パラメーターの値を渡すと、Data Grid は "Hello ${value}" を返します。

7.2.1.1. スクリプトメタデータ

メタデータは、スクリプトの実行中に Data Grid サーバーが使用するスクリプトに関する追加の情報を提供します。

スクリプトメタデータは、スクリプトの最初の行でコメントを追加する property=value ペアです。以下に例を示します。

// name=test, language=javascript
// mode=local, parameters=[a,b,c]
  • スクリプト言語 (//, ;;, #) に一致するコメントスタイルを使用してください。
  • コンマで区切られた property=value ペア
  • 値は一重引用符 (') または二重引用符 (") で区切ります。
表7.1 メタデータプロパティー
プロパティー説明

mode

実行モードを定義し、次の値を持ちます。

local は、リクエストを処理するノードのみがスクリプトを実行します。ただし、スクリプトはクラスター化された操作を引き続き呼び出すことができます。

distributed Data Grid は、クラスター化されたエグゼキューターを使用してノード間でスクリプトを実行します。

言語

スクリプトを実行する ScriptEngine を指定します。

extension

ScriptEngine を設定する代替方法としてファイル名の拡張子を指定します。

role

ユーザーがスクリプトを実行する必要があるロールを指定します。

parameters

このスクリプトの有効なパラメーター名の配列を指定します。このリストに含まれていないパラメーターを指定する呼び出しによって例外が生じます。

datatype

オプションで、データおよびパラメーターおよび戻り値を保存する MediaType(MIME タイプ) を設定します。このプロパティーは、特定のデータフォーマットのみをサポートするリモートクライアントに便利です。

現在、データに String UTF-8 形式を使用するように、text/plain; charset=utf-8 のみを設定できます。

7.2.1.2. スクリプトバインディング

Data Grid は、内部オブジェクトをスクリプト実行のバインディングとして公開します。

バインディング説明

cache

スクリプトが実行されるキャッシュを指定します。

marshaller

データをキャッシュにシリアル化するために使用するマーシャラーを指定します。

cacheManager

キャッシュの cacheManager を指定します。

scriptingManager

スクリプトを実行するスクリプトマネージャーのインスタンスを指定します。このバインディングを使用して、スクリプトから他のスクリプトを実行することができます。

7.2.1.3. スクリプトパラメーター

Data Grid を使用すると、スクリプトを実行するためのバインディングとして名前付きパラメーターを渡すことができます。

パラメーターは name,value のペアで、name は文字列、value はマーシャラーが解釈できる任意の値になります。

以下のスクリプトの例では、multiplicandmultiplier の 2 つのパラメーターがあります。このスクリプトは multiplicand の値を取り、その値を multiplier の値で乗算します。

// mode=local,language=javascript
multiplicand * multiplier

上記のスクリプトを実行すると、Data Grid は式の評価の結果で応答します。

7.2.2. Data Grid Server へのスクリプトの追加

コマンドラインインターフェイスを使用して、Data Grid サーバーにスクリプトを追加します。

前提条件

Data Grid サーバーは、スクリプトを ___script_cache キャッシュに保存します。キャッシュ認証を有効にする場合、ユーザーは ___script_cache にアクセスするために ___script_manager ロールを持っている必要があります。

手順

  1. 必要に応じてスクリプトを定義します。

    たとえば、単一の Data Grid サーバーで実行し、2 つのパラメーターを持ち、JavaScript を使用して指定の値を掛ける multiplication.js という名前のファイルを作成します。

    // mode=local,language=javascript
    multiplicand * multiplier
  2. 次の例のように、Data Grid への CLI 接続を開き、task コマンドを使用してスクリプトをアップロードします。

    [//containers/default]> task upload --file=multiplication.js multiplication
  3. スクリプトが利用可能であることを確認します。

    [//containers/default]> ls tasks
    multiplication

7.2.3. プログラムでのスクリプトの作成

以下の例のように、Hot Rod RemoteCache インターフェイスを使用してスクリプトを追加します。

RemoteCache<String, String> scriptCache = cacheManager.getCache("___script_cache");
scriptCache.put("multiplication.js",
  "// mode=local,language=javascript\n" +
  "multiplicand * multiplier\n");

7.3. サーバー側のタスクとスクリプトの実行

Data Grid サーバーで、タスクとカスタムスクリプトを実行します。

7.3.1. タスクおよびスクリプトの実行

コマンドラインインターフェイスを使用して、Data Grid サーバーでタスクとスクリプトを実行します。

前提条件

  • Data Grid への CLI 接続を開きます。

手順

次の例のように、task コマンドを使用して、Data Grid サーバーでタスクとスクリプトを実行します。

  • multipler.js という名前のスクリプトを実行して、2 つのパラメーターを指定します。

    [//containers/default]> task exec multipler.js -Pmultiplicand=10 -Pmultiplier=20
    200.0
  • @@cache@names という名前のタスクを実行して、利用可能なすべてのキャッシュの一覧を取得します。

    //containers/default]> task exec @@cache@names
    ["___protobuf_metadata","mycache","___script_cache"]

7.3.2. プログラムでのスクリプトの実行

以下の例のように、execute() を呼び出して、Hot Rod RemoteCache インターフェイスを使用してスクリプトを実行します。

RemoteCache<String, Integer> cache = cacheManager.getCache();
// Create parameters for script execution.
Map<String, Object> params = new HashMap<>();
params.put("multiplicand", 10);
params.put("multiplier", 20);
// Run the script with the parameters.
Object result = cache.execute("multiplication.js", params);

7.3.3. プログラムでのタスクの実行

以下の例のように、execute() を呼び出して、Hot Rod RemoteCache インターフェイスを使用してタスクを実行します。

// Add configuration for a locally running server.
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.addServer().host("127.0.0.1").port(11222);

// Connect to the server.
RemoteCacheManager cacheManager = new RemoteCacheManager(builder.build());

// Retrieve the remote cache.
RemoteCache<String, String> cache = cacheManager.getCache();

// Create task parameters.
Map<String, String> parameters = new HashMap<>();
parameters.put("name", "developer");

// Run the server task.
String greet = cache.execute("hello-task", parameters);
System.out.println(greet);

第8章 Data Grid サーバーのローリングアップグレードの実行

Data Grid クラスターのローリングアップグレードを実行して、ダウンタイムやデータの損失なしにバージョン間で変更します。ローリングアップグレードは、Hot Rod 経由で Data Grid サーバーおよびデータの両方をターゲットバージョンに移行します。

8.1. ターゲットクラスターの設定

ターゲット Data Grid バージョンを実行し、リモートキャッシュストアを使用してソースクラスターからデータを読み込むクラスターを作成します。

前提条件

  • ターゲットアップグレードバージョンとともに Data Grid クラスターをインストールします。
重要

ターゲットクラスターのネットワークプロパティーはソースクラスターのネットワークプロパティーが重複していないことを確認します。JGroups トランスポート設定でターゲットおよびソースクラスターの一意の名前を指定する必要があります。環境に応じて、異なるネットワークインターフェイスを使用し、ターゲットクラスターとソースクラスターを分離するためにポートオフセットを指定することもできます。

手順

  1. ソースクラスターから移行する各キャッシュについて、ターゲットクラスターに aRemoteCacheStore を追加します。

    リモートキャッシュストアは Hot Rod プロトコルを使用して、リモート Data Grid クラスターからデータを取得します。リモートキャッシュストアをターゲットクラスターに追加する場合は、ソースクラスターからデータをレイジーに読み込み、クライアント要求を処理します。

  2. すべての要求の処理を開始するために、クライアントをターゲットクラスターに切り替えます。

    1. クライアント設定をターゲットクラスターの場所で更新します。
    2. クライアントを再起動します。

8.1.1. ローリングアップグレードのリモートキャッシュストア

以下のようにローリングアップグレードを実行するには、特定のリモートキャッシュストア設定を使用する必要があります。

<persistence passivation="false"> 1
   <remote-store xmlns="urn:infinispan:config:store:remote:10.1"
                 cache="myDistCache" 2
                 protocol-version="2.5" 3
                 hotrod-wrapping="true" 4
                 raw-values="true"> 5
      <remote-server host="127.0.0.1" port="11222"/> 6
   </remote-store>
</persistence>
1
パッシベーションを無効にします。ローリングアップグレードのリモートキャッシュストアは、パッシベーションを無効にする必要があります。
2
ソースクラスター内のキャッシュの名前と一致します。ターゲットクラスターは、リモートキャッシュストアを使用してこのキャッシュからデータを読み込みます。
3
ソースクラスターの Hot Rod プロトコルバージョンと一致します。2.5 は最小バージョンであり、アップグレードパスに適しています。別の Hot Rod でバージョンを設定する必要はありません。
4
エントリーが Hot Rod プロトコルに適した形式でラップされるようにします。
5
データを raw 形式でリモートキャッシュストアに保存します。これにより、クライアントはリモートキャッシュストアから直接データを使用できるようになります。
6
ソースクラスターの場所を参照します。

8.2. ターゲットクラスターへのデータの同期

ターゲットクラスターがリモートキャッシュストアを使用してクライアント要求を実行し、オンデマンドでデータを読み込む場合は、ソースクラスターからターゲットクラスターにデータを同期できます。

この操作はソースクラスターからデータを読み取り、ターゲットクラスターに書き込みます。データは、ターゲットクラスターのすべてのノードに並行して移行され、各ノードはデータのサブセットを受け取ります。Data Grid 設定で、各キャッシュの同期を実行する必要があります。

手順

  1. ターゲットクラスターに移行する Data Grid 設定の各キャッシュの同期操作を開始します。

    Data Grid REST API を使用し、?action=sync- data パラメーターで GET リクエストを呼び出します。たとえば、myCache という名前のキャッシュ内のデータをソースクラスターからターゲットクラスターに同期するには、以下を実行します。

    GET /v2/caches/myCache?action=sync-data

    操作が完了すると、Data Grid はターゲットクラスターにコピーされたエントリーの合計数で応答します。

    または、RollingUpgradeManager MBean で synchronizeData(migratorName=hotrod) を呼び出すことで JMX を使用できます。

  2. ターゲットクラスター内の各ノードをソースクラスターから切断します。

    たとえば、ソースクラスターから myCache キャッシュを切断するには、以下の POST 要求を呼び出します。

    GET /v2/caches/myCache?action=disconnect-source

    JMX を使用するには、RollingUpgradeManager MBean で disconnectSource(migratorName=hotrod) を呼び出します。

次のステップ

ソースクラスターからすべてのデータを同期した後、ローリングアップグレードプロセスが完了しました。ソースクラスターの使用を停止できるようになりました。

第9章 Data Grid Server リファレンス

9.1. Data Grid Server

Data Grid サーバーは、データへの高速で信頼性の高い安全なアクセスを提供します。このリリースのサーバーは、以前のバージョンとオファーを改善しています。

  • 既存の機能 (設定など) の重複を最小限に抑えた小さなコードベース。
  • 埋め込み可能: サーバーは、単一設定とクラスター設定の両方で簡単にテストできるようにする必要があります。
  • RESTful な管理機能。
  • ApacheLog4j2 を使用したロギング。
  • WildFlyElytronSPI によるセキュリティー。

9.1.1. ディレクトリー構造

サーバーディストリビューションのディレクトリー構造は次のとおりです。

  • /bin: サーバーを起動してユーザーを作成/変更するためのスクリプト。
  • /boot: サーバーを起動するための JAR ファイル。
  • /docs: 例とコンポーネントライセンス。
  • /lib: サーバー JAR ファイル。
  • /server: デフォルトのサーバーインスタンスフォルダー。

    • /server/conf: 設定ファイル
    • /server/data: コンテナー名別に編成されるデータファイル。
    • /server/lib: カスタムフィルター、リスナーなどの拡張 JAR ファイル。
    • /server/log: サーバーのログファイル。

9.1.2. Server Paths

サーバーは、以下の パス を使用します。

  • Infinispan.server.home はデフォルトで、サーバーのディストリビューションが含まれるディレクトリーに設定されます。
  • infinispan.server.root には、Data Grid サーバーの設定とデータが含まれ、デフォルトでは infinispan.server.home の下の server ディレクトリーになります。
    複数のルートが同じディレクトリーまたは異なるディレクトリーに存在させることができます。複数のサーバーインスタンスを起動するには、コマンドライン引数を使用して infinispan.server.root へのパスを指定します。

    注記

    サーバーが起動すると、infinispan.server.root がロックされ、複数のサーバーインスタンスによる同時使用を回避します。

  • infinispan.server.configuration の デフォルトは infinispan.xml で、これは infinispan.server.root の下の conf フォルダーにあります。

9.1.3. コマンド引数

server.sh|bat 起動スクリプトには、情報の取得、サーバーランタイム環境の設定に使用できる引数が含まれます。

利用可能なコマンド引数を表示するには、以下のように --help または -h オプションを追加します。

$ bin/server.sh -h

9.1.4. ロギング設定

server/conf ディレクトリーの log4j2.xml を使用してロギングを設定します。

9.1.5. 設定

サーバーの設定は、標準の Data Grid 設定を以下のサーバー固有の要素で拡張します。

  • security はエンドポイントで利用可能なセキュリティーレルムを設定します。
  • cache-container 複数のコンテナーを設定し、名前で区別することができます。
  • endpoints には、有効なエンドポイントコネクター (hotrod、rest など) が一覧表示されます。
  • socket-bindings はソケットバインディングを一覧表示します。

以下は、サーバー設定の例です。

<infinispan
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:infinispan:config:10.1 https://infinispan.org/schemas/infinispan-config-10.1.xsd
                            urn:infinispan:server:10.1 https://infinispan.org/schemas/infinispan-server-10.1.xsd"
        xmlns="urn:infinispan:config:10.1"
        xmlns:server="urn:infinispan:server:10.1">

   <cache-container default-cache="default" statistics="false">
      <transport cluster="${infinispan.cluster.name}" stack="udp"/>
      <global-state/>
      <distributed-cache name="default"/>
   </cache-container>

   <server xmlns="urn:infinispan:server:10.1">
      <interfaces>
         <interface name="public">
            <loopback/>
         </interface>
         <interface name="admin">
            <loopback/>
         </interface>
      </interfaces>

      <socket-bindings default-interface="public" port-offset="${infinispan.socket.binding.port-offset:0}">
         <socket-binding name="hotrod" port="11222"/>
         <socket-binding name="rest" port="8080"/>
         <socket-binding name="memcached" port="11221"/>
         <socket-binding name="admin" port="9990" interface="admin"/>
      </socket-bindings>

      <security>
         <security-realms>
            <security-realm name="ManagementRealm">
               <properties-realm groups-attribute="Roles">
                  <user-properties path="mgmt-users.properties" relative-to="infinispan.server.config.dir" plain-text="true"/>
                  <group-properties path="mgmt-groups.properties" relative-to="infinispan.server.config.dir" />
               </properties-realm>
            </security-realm>
            <security-realm name="PublicRealm">
               <properties-realm groups-attribute="Roles">
                  <user-properties path="public-users.properties" relative-to="infinispan.server.config.dir" plain-text="true"/>
                  <group-properties path="public-groups.properties" relative-to="infinispan.server.config.dir" />
               </properties-realm>
               <server-identities>
                  <ssl>
                     <keystore path="application.keystore" relative-to="infinispan.server.config.dir"
                               keystore-password="password" alias="server" key-password="password"
                               generate-self-signed-certificate-host="localhost"/>
                  </ssl>
               </server-identities>
            </security-realm>
         </security-realms>
      </security>

      <endpoints>
         <hotrod-connector socket-binding="hotrod"/>
         <memcached-connector socket-binding="memcached"/>
         <rest-connector socket-binding="rest"/>
      </endpoints>
   </server>
</infinispan>

9.1.6. 詳細

以下は、特定の順序でサーバーに関する追加情報の一覧です。

  • 同じサーバーによって処理されるすべてのコンテナーは同じスレッドプールとトランスポートを共有します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.