Data Grid Server ガイド
Data Grid のドキュメント
概要
第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
ディレクトリーのアーカイブです。
手順
- Red Hat カスタマーポータルにアクセスします。
- ソフトウェアダウンロードセクション から Red Hat Data Grid 8.0 サーバーをダウンロードします。
検証
チェックサムを使用して、ダウンロードの整合性を検証します。
以下のように、サーバーダウンロードアーカイブを引数として、
md5sum
またはsha256sum
を実行します。$ sha256sum jboss-datagrid-${version}-server.zip
-
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 サーバーを起動します。
手順
-
$RHDG_HOME
でターミナルを開きます。 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 サーバーインスタンスを開始します。
手順
新しい Data Grid サーバーインスタンスをインストールして実行します。
-
$RHDG_HOME
でターミナルを開きます。 root ディレクトリーを
server2
にコピーします。$ cp -r server server2
-
ポートオフセットと
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 を起動します。
-
$ISPN_HOME
でターミナルを開きます。 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 キャッシュテンプレートを使用して、推奨されるデフォルト設定でキャッシュを追加します。
手順
テンプレートからの分散同期キャッシュを作成し、mycache という名前を付けます。
[//containers/default]> create cache --template=org.infinispan.DIST_SYNC mycache
ヒント--template=
引数の後に Tab キーを押して、利用可能なキャッシュテンプレートを一覧表示します。キャッシュ設定を取得します。
[//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
手順
エントリーを "mycache" に追加します。
[//containers/default/caches/mycache]> put hello world
ヒントキャッシュのコンテキストにない場合は、
--cache=
パラメーターを使用します。以下に例を示します。[//containers/default]> put --cache=mycache hello world
エントリーを取得して確認します。
[//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.6. ローカルストラテジーのリンク
link-local IP アドレスを選択します。
-
IPv4 アドレスブロック
169.254.0.0/16
(169.254.0.0 – 169.254.255.255
) は、リンクローカルアドレス指定用に予約されています。 -
IPv6 アドレスブロック
fe80::/10
は、リンクローカルユニキャストアドレス用に予約されています。
<interfaces> <interface name="public"> <inet-address value="10.1.2.3"/> </interface> </interfaces>
3.1.7. サイトのローカルストラテジー
サイトローカル (プライベート) の IP アドレスを選択します。
-
IPv4 アドレスブロック
10.0.0.0/8
、172.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 サーバーエンドポイントを有効にします。
手順
Data Grid サーバーとの ALPN/TLS エクスチェンジを処理する適切なライブラリーをクライアントアプリケーションに提供します。
注記Data Grid は、Java に Wildfly OpenSSL バインディングを使用します。
- トラストストアでクライアントを適宜設定します。
プログラムで
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
参照資料
- Data Grid エンドポイントコネクター
- WildFly OpenSSL
- SslConfigurationBuilder
- Hot Rod クライアント設定プロパティー
第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. プロトコルの比較
Hot Rod | HTTP / 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 ログを設定します。
手順
-
任意のテキストエディターで
$RHDG_HOME/${infinispan.server.root}/conf/log4j2.xml
を開きます。 - 必要に応じてロギング設定を変更します。
-
log4j2.xml
を保存し、閉じます。
5.1.2.1. ログレベル
ログレベルは、メッセージの性質と重大度を示します。
ログレベル | 説明 |
---|---|
| 粒度の細かいデバッグメッセージ。アプリケーションを介して個々のリクエストのフローをキャプチャーします。 |
| 個々のリクエストと関連性のない、一般的なデバッグのメッセージ。 |
| ライフサイクルイベントを含む、アプリケーションの全体的な進捗状況に関するメッセージ。 |
| エラーやパフォーマンスの低下につながる可能性のあるイベント。 |
| 操作またはアクティビティーの正常な実行を妨げる可能性がありますが、アプリケーションの実行は妨げないエラー状態。 |
| 重大なサービス障害やアプリケーションのシャットダウンを引き起こす可能性のあるイベント。 |
上記の個々のメッセージのレベルに加えて、この設定では、ALL
(すべてのメッセージを含む) と OFF
(すべてのメッセージを除外) のさらに 2 つの値を可能にします。
5.1.2.2. Data Grid ログカテゴリー
Data Grid は、機能領域ごとにログを整理する INFO
、WARN
、ERROR
、FATAL
のレベルのメッセージのカテゴリーを提供します。
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 が実行されていないことを確認します。ログハンドラーは動的に有効にすることはできません。
手順
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}] "%X{method} %m %X{protocol}" %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}
表記を使用し、アクセスログの形式を変更可能にします。以下は、デフォルトのロギングプロパティーです。
プロパティー | 説明 |
---|---|
|
|
| 認証を使用する場合のプリンシパル名。 |
|
使用されるメソッド。 |
|
使用されるプロトコル |
|
REST エンドポイントの HTTP ステータスコード。 |
| リクエストのサイズ (バイト単位)。 |
| 応答のサイズ (バイト単位)。 |
| サーバーによる要求の処理にかかった時間 (ミリ秒数)。 |
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>
プログラムで
GlobalConfiguration globalConfig = new GlobalConfigurationBuilder() .cacheContainer().statistics(true) 1 .build(); ... Configuration config = new ConfigurationBuilder() .statistics().enable() 2 .build();
キャッシュマネージャーの統計を有効にしても、キャッシュの統計はグローバルに有効にはなりません。この設定は、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();
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();
参照資料
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
インターフェイスが含まれています。
手順
-
getMBeanServer()
メソッドがカスタム MBeanServer インスタンスを返すようにMBeanServerLookup
の実装を作成します。 - 以下の例のように、クラスの完全修飾名で 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 クラスターの正常性統計を取得します。
手順
JConsole などの JMX 対応ツールを使用して Data Grid Server に接続し、以下のオブジェクトに移動します。
org.infinispan:type=CacheManager,name="default",component=CacheContainerHealth
- 利用可能な 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>
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>
サポート対象の認証メカニズム
プロパティーレルムは、以下の認証メカニズムをサポートします。
-
SASL:
PLAIN
、DIGEST-*
、およびSCRAM-*
-
HTTP(REST):
Basic
およびDigest
6.2.1.1. プロパティーレルムへのユーザーの追加
Data Grid サーバーは、プロパティーファイルに新しいユーザー/ロールマッピングを簡単に追加できる user-tool
スクリプトを提供します。
手順
-
$ISPN_HOME
ディレクトリーに移動します。 -
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="(&(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:
PLAIN
、DIGEST-*
、およびSCRAM-*
-
HTTP(REST):
Basic
およびDigest
6.2.2.1. LDAP レルムプリンシパルの書き換え
GSSAPI
、GS2-KRB5
、Negotiate
などの一部の 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="(&(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>
サポート対象の認証メカニズム
トラストストアレルムは、クライアント証明書の認証メカニズムと連携します。
-
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>
サポート対象の認証メカニズム
トークンレルムは、以下の認証メカニズムをサポートします。
-
SASL:
OAUTHBEARER
-
HTTP (REST):
Bearer
6.3. Data Grid サーバーのアイデンティティーの作成
サーバーアイデンティティーはセキュリティーレルムで定義され、Data Grid サーバーがアイデンティティーをクライアントに証明できるようにします。
6.3.1. SSL アイデンティティーの設定
SSL ID は、証明書または証明書のチェーンのいずれかが含まれるキーストアを使用します。
セキュリティーレルムに SSL アイデンティティーが含まれる場合、Data Grid サーバーはこれらのセキュリティーレルムを使用するエンドポイントの暗号化を自動的に有効にします。
手順
Data Grid サーバーのキーストアを作成します。
重要Data Grid サーバーは JKS、JCEKS、PKCS12、BKS、BCFKS、および UBER のキーストア形式をサポートします。
実稼働環境では、サーバー証明書は Root または Intermediate CA のいずれかの信頼される認証局によって署名される必要があります。
-
キーストアを
$ISPN_HOME/server/conf
ディレクトリーに追加します。 -
server-identities
定義を Data Grid サーバーのセキュリティーレルムに追加します。 - パスワードおよびエイリアスとともにキーストアの名前を指定します。
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>
6.3.1.2. キーストアの自動生成
Data Grid サーバーを設定し、起動時にキーストアを自動的に生成します。
自動生成されたキーストア:
- 実稼働環境では使用しないでください。
- 必要に応じて生成されます。たとえば、クライアントから最初の接続を取得する際などに生成されます。
- Hot Rod クライアントで直接使用可能な証明書が含まれます。
手順
-
サーバー設定に
keystore
要素のgenerate-self-signed-certificate-host
属性を含めます。 - サーバー証明書のホスト名を値として指定します。
生成されたキーストアを持つ 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 です。
手順
-
engine
要素を Data Grid サーバーの SSL アイデンティティーに追加します。 -
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>
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 サービスを識別します。
手順
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
-
キータブファイルを
$ISPN_HOME/server/conf
ディレクトリーにコピーします。 -
server-identities
定義を Data Grid サーバーのセキュリティーレルムに追加します。 - Hot Rod および REST コネクターにサービスプリンシパルを提供するキータブファイルの場所を指定します。
- 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>
6.4. エンドポイント認証メカニズムの設定
クライアントとの認証を行うように、SASL 認証メカニズムで Hotfaillock および REST コネクターを設定します。
6.4.1. Hotot 認証の設定
特定の SASL 認証メカニズムを使用して、クライアントとの認証を Data Grid サーバーセキュリティーレルムに対して認証するように設定します。
手順
-
Hot Rod コネクター設定に
authentication
定義を追加します。 - Hot Rod コネクターが認証に使用する Data Grid セキュリティーレルムを指定します。
- 使用する Hot Rod エンドポイントの SASL 認証メカニズムを指定します。
- 必要に応じて 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>
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>
6.4.1.2. Hot Rod エンドポイント認証メカニズム
Data Grid は、Hot Rod コネクターを使用して以下の SASL 認証メカニズムをサポートします。
認証メカニズム | 説明 | 関連する詳細 |
---|---|---|
|
プレーンテキスト形式の認証情報を使用します。 |
|
|
ハッシュアルゴリズムとナンス値を使用します。ホットロッドコネクターは、強度の順に、 |
|
|
ハッシュアルゴリズムとナンス値に加えてソルト値を使用します。ホットロッドコネクターは、 |
|
|
Kerberos チケットを使用し、Kerberos ドメインコントローラーが必要です。対応する |
|
|
Kerberos チケットを使用し、Kerberos ドメインコントローラーが必要です。対応する |
|
| クライアント証明書を使用します。 |
|
|
OAuth トークンを使用し、 |
|
6.4.1.3. SASL Quality of Protection (QoP)
SASL メカニズムが整合性とプライバシー保護設定に対応している場合は、qop
属性を使用して Hot Rod コネクター設定に追加することができます。
QoP 設定 | 説明 |
---|---|
| 認証のみ。 |
| 整合性保護による認証。 |
| 整合性とプライバシー保護による認証。 |
6.4.1.4. SASL ポリシー
SASL ポリシーを使用すると、Hot Rod コネクターが使用できる認証メカニズムを制御できます。
ポリシー | 説明 | デフォルト値 |
---|---|---|
| セッション間の forward secrecy をサポートする SASL メカニズムのみを使用します。これは、1 つのセッションに分割しても、将来のセッションに分割するための情報が自動的に提供されないことを意味します。 | false |
| クライアント認証情報が必要な SASL メカニズムのみを使用してください。 | false |
| 単純な受動的攻撃の影響を受けやすい SASL メカニズムは使用しないでください。 | false |
| アクティブな非辞書攻撃の影響を受けやすい SASL メカニズムは使用しないでください。 | false |
| 受動的な辞書攻撃の影響を受けやすい SASL メカニズムは使用しないでください。 | false |
| 匿名ログインを許可する 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>
前述の設定により、Hot Rod コネクターは GSSAPI
メカニズムを使用します。これは、すべてのポリシーに準拠する唯一のメカニズムであるためです。
6.4.2. REST 認証の設定
特定の SASL 認証メカニズムを使用して、クライアントとの認証を Data Grid サーバーセキュリティーレルムに対して認証するように設定します。
手順
-
REST コネクター設定に
authentication
定義を追加します。 - REST コネクターが認証に使用する Data Grid セキュリティーレルムを指定します。
- REST エンドポイントが使用する SASL 認証メカニズムを指定します。
- 必要に応じて 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>
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>
6.4.2.2. REST エンドポイント認証メカニズム
Data Grid は、REST コネクターを使用して以下の認証メカニズムをサポートします。
認証メカニズム | 説明 | 関連する詳細 |
---|---|---|
|
プレーンテキスト形式の認証情報を使用します。暗号化された接続でのみ |
HTTP |
|
ハッシュアルゴリズムとナンス値を使用します。REST コネクターは、 |
|
|
Kerberos チケットを使用し、Kerberos ドメインコントローラーが必要です。対応する |
|
|
OAuth トークンを使用し、 |
|
| クライアント証明書を使用します。 |
|
第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 は、カスタムクラスのランタイムデプロイメントをサポートしません。
手順
- JAR ファイルでサーバータスクの実装をパッケージ化します。
以下のように、サーバーのタスクの完全修飾名が含まれる
META-INF/services/org.infinispan.tasks.ServerTask
ファイルを追加します。example.HelloTask
-
JAR ファイルを Data Grid サーバーの
$RHDG_HOME/server/lib
ディレクトリーにコピーします。 - クラスを 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
ペア - 値は一重引用符 (') または二重引用符 (") で区切ります。
プロパティー | 説明 |
---|---|
| 実行モードを定義し、次の値を持ちます。
|
| スクリプトを実行する ScriptEngine を指定します。 |
| ScriptEngine を設定する代替方法としてファイル名の拡張子を指定します。 |
| ユーザーがスクリプトを実行する必要があるロールを指定します。 |
| このスクリプトの有効なパラメーター名の配列を指定します。このリストに含まれていないパラメーターを指定する呼び出しによって例外が生じます。 |
| オプションで、データおよびパラメーターおよび戻り値を保存する MediaType(MIME タイプ) を設定します。このプロパティーは、特定のデータフォーマットのみをサポートするリモートクライアントに便利です。
現在、データに String UTF-8 形式を使用するように、 |
7.2.1.2. スクリプトバインディング
Data Grid は、内部オブジェクトをスクリプト実行のバインディングとして公開します。
バインディング | 説明 |
---|---|
| スクリプトが実行されるキャッシュを指定します。 |
| データをキャッシュにシリアル化するために使用するマーシャラーを指定します。 |
|
キャッシュの |
| スクリプトを実行するスクリプトマネージャーのインスタンスを指定します。このバインディングを使用して、スクリプトから他のスクリプトを実行することができます。 |
7.2.1.3. スクリプトパラメーター
Data Grid を使用すると、スクリプトを実行するためのバインディングとして名前付きパラメーターを渡すことができます。
パラメーターは name,value
のペアで、name
は文字列、value
はマーシャラーが解釈できる任意の値になります。
以下のスクリプトの例では、multiplicand
と multiplier
の 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
ロールを持っている必要があります。
手順
必要に応じてスクリプトを定義します。
たとえば、単一の Data Grid サーバーで実行し、2 つのパラメーターを持ち、JavaScript を使用して指定の値を掛ける
multiplication.js
という名前のファイルを作成します。// mode=local,language=javascript multiplicand * multiplier
次の例のように、Data Grid への CLI 接続を開き、
task
コマンドを使用してスクリプトをアップロードします。[//containers/default]> task upload --file=multiplication.js multiplication
スクリプトが利用可能であることを確認します。
[//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 トランスポート設定でターゲットおよびソースクラスターの一意の名前を指定する必要があります。環境に応じて、異なるネットワークインターフェイスを使用し、ターゲットクラスターとソースクラスターを分離するためにポートオフセットを指定することもできます。
手順
ソースクラスターから移行する各キャッシュについて、ターゲットクラスターに
aRemoteCacheStore
を追加します。リモートキャッシュストアは Hot Rod プロトコルを使用して、リモート Data Grid クラスターからデータを取得します。リモートキャッシュストアをターゲットクラスターに追加する場合は、ソースクラスターからデータをレイジーに読み込み、クライアント要求を処理します。
すべての要求の処理を開始するために、クライアントをターゲットクラスターに切り替えます。
- クライアント設定をターゲットクラスターの場所で更新します。
- クライアントを再起動します。
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 設定で、各キャッシュの同期を実行する必要があります。
手順
ターゲットクラスターに移行する 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 を使用できます。ターゲットクラスター内の各ノードをソースクラスターから切断します。
たとえば、ソースクラスターから 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. 詳細
以下は、特定の順序でサーバーに関する追加情報の一覧です。
- 同じサーバーによって処理されるすべてのコンテナーは同じスレッドプールとトランスポートを共有します。