Oracle® Fusion Middleware

Oracle Coherenceの管理

12c (12.2.1)

E69908-02(原本部品番号:E55624-05)

2016年2月

システム管理者およびオペレータ用ドキュメントで、Coherenceアプリケーションをデプロイする方法、および本番環境をCoherence用にチューニングする方法が説明されています。

Oracle Fusion Middleware Oracle Coherenceの管理, 12c (12.2.1)

E69908-02

Copyright © 2008, 2016, Oracle and/or its affiliates  All rights reserved.

原本著者: Joseph Ruzzi

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- 12c (12.2.1)での新機能と変更された機能

- 12c (12.2.1)に関するこのドキュメントにおけるその他の大きな変更

第I部 基本的な管理

1 Coherenceアプリケーションのデプロイ

- スタンドアロンCoherenceアプリケーションのデプロイ

- データ層のデプロイ

- アプリケーション層のデプロイ

- Extendクライアント用プロキシ層のデプロイ

- Extendクライアントのデプロイ

- CoherenceアプリケーションのWebLogic Serverへのデプロイ

- WebLogic Server Coherence統合機能の概要

- WebLogic Server用のCoherenceアプリケーションのパッケージ化

- Coherence GARモジュールの構築

- GARモジュールのEARモジュール内へのパッケージ化

- Coherence用のWebLogic Serverドメイン・トポロジの設定

- Coherenceクラスタ構成の作成

- Coherenceデプロイメント層の作成

- Coherenceデプロイメント層用の管理対象Coherenceサーバーの作成

- CoherenceアプリケーションのWebLogic Serverドメインへのデプロイ

- データ層GARのデプロイ

- アプリケーション層EARのデプロイ

- プロキシ層GARのデプロイ

- 基本的なCoherence管理タスクの実行

- Coherenceアプリケーションのアプリケーション・サーバー(汎用)へのデプロイ

- アプリケーション・サーバー・ライブラリとしてのCoherenceのデプロイ

- Java EEモジュール内へのCoherenceのデプロイ

- EAR内へのCoherenceのデプロイ

- WAR内へのCoherenceのデプロイ

- 単一クラスタでの複数のアプリケーションの実行

- スコープ名の指定

- WebLogic Server内のアプリケーションのスコープ設定

- Java EE環境(汎用)内のアプリケーションのスコープ設定

- Java EE環境内のアプリケーションの分離

- Java EE環境内のアプリケーション・データの共有

- スタンドアロン環境内のアプリケーションのスコープ設定

- カスタム・スコープ・リゾルバの指定

2 ネットワーク・パフォーマンス・テストの実行

- データグラム・テスト・ユーティリティの実行

- データグラム・ネットワーク・パフォーマンスのテスト方法

- ポイント・ツー・ポイント・データグラム・テストの実行

- 双方向データグラム・テストの実行

- 分散データグラム・テストの実行

- データグラム・レポート統計の理解

- メッセージ・バス・テスト・ユーティリティの実行

- メッセージ・バス・パフォーマンスのテスト方法

- ポイント・ツー・ポイント・メッセージ・バス・テストの実行

- 双方向メッセージ・バス・テストの実行

- 分散メッセージ・バス・テストの実行

- メッセージ・バス・レポート統計の理解

3 マルチキャスト接続テストの実行

- マルチキャスト・テスト・ユーティリティの実行

- マルチキャストのテスト方法

- マルチキャスト通信のトラブルシューティング

4 パフォーマンス・チューニング

- オペレーティング・システムのチューニング

- ソケット・バッファ・サイズ

- 高分解能タイムソース(Linux)

- データグラム・サイズ(Microsoft Windows)

- スレッド・スケジューリング(Microsoft Windows)

- スワッピング

- ロード・バランシング・ネットワーク割込み(Linux)

- ネットワークのチューニング

- ネットワーク・インタフェースの設定

- ネットワーク・インフラストラクチャの設定

- スイッチとサブネットに関する考慮事項

- イーサネットのフロー制御

- パスMTU

- 10GbEに関する考慮事項

- TCPに関する考慮事項

- JVMのチューニング

- サイズ設定に関する基本的な推奨事項

- ヒープ・サイズに関する考慮事項

- 一般的なガイドライン

- アプリケーション・ヒープからのキャッシュの移動

- ガベージ・コレクションの監視

- Coherence通信のチューニング

- 検証

- データ・アクセス・パターン

- データ・アクセスの分散(ホット・スポット)

- クラスタ・ノード・アフィニティ

- 読取り/書込み率とデータ・サイズ

- キャッシュにおける読取りと書込みのインターリーブ

5 本番チェックリスト

- ネットワーク・パフォーマンス・テストとマルチキャストの推奨事項

- ネットワークの推奨事項

- キャッシュ・サイズ計算の推奨事項

- ハードウェアの推奨事項

- オペレーティング・システムの推奨事項

- JVMの推奨事項

- Oracle Exalogic Elastic Cloudの推奨事項

- セキュリティの推奨事項

- アプリケーション・インストゥルメンテーションの推奨事項

- Coherenceのモードおよびエディション

- Coherenceオペレーション構成の推奨事項

- Coherenceキャッシュ構成の推奨事項

- 大規模なクラスタ構成の推奨事項

- 停止検出の推奨事項

第II部 高度な管理

6 キャッシュの永続化

- 永続性の概要

- 永続依存性

- オンデマンドでのキャッシュの永続化

- キャッシュのアクティブな永続化

- スナップショットを使用したキャッシュ・サービスの永続化

- スナップショットの作成

- スナップショットのリカバリ

- スナップショットの削除

- スナップショットのアーカイブ

- スナップショット・アーカイブ・ディレクトリの定義

- ディレクトリ・スナップショット・アーカイバの指定

- スナップショット・アーカイブ操作の実行

- スナップショットのアーカイブ

- アーカイブされたスナップショットの取得

- アーカイブされたスナップショットの削除

- アーカイブされたスナップショットのリスト

- アーカイブされたスナップショット・ストアのリスト

- カスタム・スナップショット・アーカイバの作成

- カスタム・スナップショット・アーカイバ実装の作成

- カスタム・スナップショット・アーカイバ定義の作成

- カスタム・スナップショット・アーカイバの指定

- アクティブ永続性モードの有効化

- アクティブな永続性を使用する場合のパーティション数の変更

- 事前定義済の永続性環境の変更

- 事前定義済の永続性ディレクトリの変更

- 永続性環境の作成

- 永続性環境の定義

- 永続性モードの構成

- 永続性ディレクトリの構成

- 永続性環境を使用するためのキャッシュ・サービスの構成

- アクティブな永続化に失敗した場合のレスポンスの作成

- 永続性リカバリのクォーラムの構成

- 永続性JMX通知のサブスクライブ

- 永続性の管理

- 永続記憶域の計画

- 永続記憶域の使用の監視

- 永続性遅延の監視

- 一時的なものとしてのキャッシュの構成

7 クラスタ間のキャッシュのレプリケート

- フェデレーテッド・キャッシュの概要

- フェデレーテッド・キャッシュの設定の一般的な手順

- フェデレーション参加者の定義

- フェデレーション参加者のデフォルト設定の変更

- レプリケーション・トポロジの理解

- レプリケーション・トポロジの定義

- アクティブ/パッシブ・トポロジの定義

- アクティブ/アクティブ・トポロジの定義

- ハブおよびスポーク・トポロジの定義

- 集中型レプリケーション・トポロジの定義

- カスタム・トポロジの定義

- フェデレーテッド・キャッシュ・スキームの定義

- フェデレーテッド・キャッシュとレプリケーション・トポロジの関連付け

- 宛先キャッシュのオーバーライド

- フェデレーション・サービス・リソースの使用の制限

- レプリケーション競合の解決

- フェデレーテッド接続イベントの処理

- フェデレーテッド変更ベントの処理

- フェデレーション通信への特定のネットワーク・インタフェースの使用

- フェデレーテッド接続のロード・バランシング

- フェデレーション・ベースのロード・バランシングの使用

- カスタムのフェデレーション・ベース・ロード・バランシングの戦略の実装

- クライアントベースのロード・バランシングの使用

- フェデレーテッド・キャッシュの管理

- クラスタ参加者のステータスの監視

- レプリケーションのパフォーマンスおよびスループットの監視

A プラットフォーム固有のデプロイに関する考慮事項

- Oracle HotSpot JVMへのデプロイ

- ヒープ・サイズ

- AtomicLong

- OutOfMemoryError

- IBM JVMへのデプロイ

- OutOfMemoryError

- ヒープ・サイズの設定

- Linuxへのデプロイ

- TSC高分解能タイムソース

- Solarisへのデプロイ

- Solaris 10 (x86とSPARC)

- Solaris 10のネットワーキング

- Solarisネットワーク・インタフェース・カード

- Solarisリンク・アグリゲーション

- Windowsへのデプロイ

- パフォーマンス・チューニング

- 個人用ファイアウォール

- 切断されたネットワーク・インタフェース

- OS Xへのデプロイ

- マルチキャストとIPv6

- ソケット・バッファのサイズ設定

- z/OSへのデプロイ

- EBCDIC

- マルチキャスト

- AIXへのデプロイ

- マルチキャストとIPv6

- 仮想マシンへのデプロイ

- マルチキャスト接続

- パフォーマンス

- フォルト・トレランス

- Cisco社製スイッチへのデプロイ

- バッファ・スペースとパケットの一時停止

- 大規模ネットワークでのマルチキャスト接続

- マルチキャストの停止

- マルチキャストの存続時間

- Foundry社製スイッチへのデプロイ

- マルチキャスト接続

- IBM BladeCenterへのデプロイ

- MACアドレスの均一性とロード・バランシング

B ログ・メッセージのリファレンス

- TCMPのログ・メッセージ

- 構成のログ・メッセージ

- パーティション・キャッシュ・サービスのログ・メッセージ

はじめに

『Oracle Coherenceの管理』へようこそ。このドキュメントでは、Coherenceのクラスタおよびキャッシュを管理する際の主な管理概念と詳細な手順について説明します。

対象読者

このドキュメントは、次の読者を対象としています。

- 主な対象読者: ネットワーク環境内でCoherenceクラスタを管理する必要のある管理者およびオペレータ。

- その他の対象読者: Coherence管理のオプションを理解する必要のあるシステム・アーキテクトおよび開発者。

対象読者には、JavaとJavaEEについての詳しい知識が必要です。また、このガイドに示す例では、Oracle Coherence製品をインストールして使用することが必要です。ユーザーには、コマンド行スクリプトの実行についての詳しい知識が必要です。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティへの取り組みについては、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)にアクセスしてください。

Oracleサポートへのアクセス

サポートを購入したオラクル社のお客様は、My Oracle Supportを介して電子的なサポートにアクセスできます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

詳細は、次のOracle Coherenceドキュメントを参照してください。

- Oracle Coherence*WebでのHTTPセッション・マネージメントの管理

- Oracle Coherenceでのアプリケーションの開発

- Oracle Coherenceリモート・クライアントの開発

- 『Oracle Coherenceのインストール』

- 『Oracle Coherenceの統合』

- 『Oracle Coherenceのマネージメント』

- 『Oracle Coherenceの保護』

- Oracle Coherence Java APIリファレンス

- Oracle Coherence C++ APIリファレンス

- Oracle Coherence .NET APIリファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドで説明する新機能

次のトピックでは、Oracle Coherenceの新機能と変更された機能について、およびこのガイドに記載されるその他の重要な変更について紹介し、詳細情報へのリンクを提供します。

12c (12.2.1)での新機能と変更された機能

このドキュメントでのOracle Coherence 12c (12.2.1)に含まれる新機能と変更された機能は次のとおりです。

- 永続性: Coherence分散キャッシュのバックアップとリカバリを管理します。詳細は、「キャッシュの永続化」を参照してください。

- フェデレーテッド・キャッシュ: 地理的に分散した複数のクラスタ間でキャッシュ・データをレプリケートおよび同期します。「クラスタ間のキャッシュのレプリケート」を参照してください。

12c (12.2.1)に関するこのドキュメントにおけるその他の大きな変更

12c (12.2.1)でこのガイドは何箇所か更新されています。次の表に、追加または変更された項を示します。

- マルチキャスト接続テストの実行に関する手順を改訂しました。「マルチキャスト接続テストの実行」を参照してください。

- デフォルトのクラスタ・ポートの変更に関する手順を改訂しました。「デフォルトのクラスタ・ポートの変更」を参照してください。

- IPv4およびIPv6の推奨事項を改訂しました。「一貫したIPプロトコルの確保」を参照してください。

- ファイアウォール・ポート構成に関する項を追加しました。「ファイアウォール・ポート構成に対する計画」を参照してください。

- Oracle Exalogic Elastic Cloudの推奨事項を改訂しました。「Oracle Exalogic Elastic Cloudの推奨事項」を参照してください。

- 新しいログ・メッセージを追加しました。「ログ・メッセージのリファレンス」を参照してください。

第I部 基本的な管理

第I部は、次の章で構成されています。

- Coherenceアプリケーションのデプロイ

- ネットワーク・パフォーマンス・テストの実行

- マルチキャスト接続テストの実行

- パフォーマンス・チューニング

- 本番チェックリスト

1 Coherenceアプリケーションのデプロイ

この章では、Coherenceをスタンドアロン・アプリケーションとしてデプロイする手順と、Java EEアプリケーションとしてデプロイする手順について説明します。WebLogic Serverに固有の手順についても説明しています。

この章の内容は次のとおりです。

- スタンドアロンCoherenceアプリケーションのデプロイ

- CoherenceアプリケーションのWebLogic Serverへのデプロイ

- Coherenceアプリケーションのアプリケーション・サーバー(汎用)へのデプロイ

- 単一クラスタでの複数のアプリケーションの実行

スタンドアロンCoherenceアプリケーションのデプロイ

スタンドアロンCoherenceアプリケーションは、異なるロールを実行する分散プロセスから構成されます。デプロイメントの場合、これらのプロセスをそのロールに基づいた層に論理的にグループ化すると有益な場合がありますが、これはデプロイメントの要件ではありません。最も一般的な層は、データ層、アプリケーション層、プロキシ層およびExtendクライアント層です。層により、共通のアーティファクト、パッケージ化およびスクリプトを定義して各層用に設定できるためデプロイメントが容易になります。

この項には次のトピックが含まれます:

- データ層のデプロイ

- アプリケーション層のデプロイ

- Extendクライアント用プロキシ層のデプロイ

- Extendクライアントのデプロイ

データ層のデプロイ

データ層はキャッシュ・オブジェクトを格納するキャッシュ・サーバーから構成されます。Coherenceアプリケーションでは、データ層に任意の数のキャッシュ・サーバーが必要な場合があります。キャッシュ・サーバーの数は、キャッシュに予想されるデータの量と、そのデータをバックアップしてサーバー障害後も存続させる必要があるかどうかに依存します。各キャッシュ・サーバーがCoherenceクラスタ・メンバーで独自のJVMプロセスで稼働し、複数のキャッシュ・サーバーを1つの物理サーバー上で連結できます。アプリケーション用キャッシュ・サーバーの数の計画の詳細は、「キャッシュ・サイズ計算の推奨事項」および「ハードウェアの推奨事項」を参照してください。

キャッシュ・サーバーは、通常、com.tangosol.net.DefaultCacheServerクラスを使用して起動されます。このクラスにはmainメソッドが含まれ、コマンド行から起動されます。キャッシュ・サーバーの起動の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

次のアプリケーション・アーティファクトは、キャッシュ・サーバーでデプロイされることがあります。

- オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。

- POFシリアライザおよびドメイン・オブジェクト

- 問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。

- イベント処理実装。

- データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。

アプリケーション・アーティファクトをデータ層にパッケージ化する方法に制限はありません。ただし、アーティファクトはサーバーのクラスパスにあり、すべての構成ファイルがcoherence.jarライブラリの前にある必要があります(デフォルトの名前を使用している場合)。それ以外の場合、coherence.jarライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、単一のキャッシュ・サーバーがAPPLICATION_HOME\configディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME\lib\myClassesライブラリにある実装クラスを使用します。

java -server -Xms4g -Xmx4g -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

(オペレーション・オーバーライド・ファイルを変更せずに)構成オーバーライドをシステム・プロパティとして含める場合、javaコマンドに対して-D引数として含めることができます。便利な方法としてCOHERENCE_HOME\bin\cache-serverスクリプトを再利用して適宜変更できます。

GARデプロイメント

Coherenceアプリケーション・アーティファクトは、グリッド・アーカイブ(GAR)としてパッケージ化してDefaultCacheServerクラスでデプロイできます。GARは特定のディレクトリ構造に準拠し、アプリケーション・ディスクリプタを含みます。GARパッケージ化の詳細は、「Coherence GARモジュールの構築」を参照してください。手順はWebLogicサーバー・デプロイメントの一部として含まれていますが、DefaultCacheServerクラスでデプロイ中のGARにも適用できます。

次の例では、キャッシュ・サーバーを起動してMyGar.garファイルにパッケージ化されているアプリケーション・アーティファクトを使用します。デフォルト名(MyGAR)はアプリケーション名として使用され、クラスタ上のアプリケーションの有効範囲を提供します。

java -server -Xms4g -Xmx4g -cp APPLICATION_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar

デフォルト名は引数として別の名前を指定することでオーバーライドできます。有効なDefaultCacheServer引数の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。アプリケーション・スコープの詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。

アプリケーション層のデプロイ

アプリケーション層は、キャッシュ操作を実行する任意の数のクライアントから構成されます。キャッシュ操作には、キャッシュへのオブジェクトのロード、キャッシュされたオブジェクトの使用、キャッシュされたデータの処理およびキャッシュ保守の実行などがあります。クライアントはCoherenceクラスタ・メンバーですが、データの格納は行いません。

次のアプリケーション・アーティファクトは、クライアントとともにデプロイされることがあります。

- オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。

- POFシリアライザおよびドメイン・オブジェクト

- 問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。

- イベント処理実装。

- データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。

アプリケーション・アーティファクトをアプリケーション層にパッケージ化する方法に制限はありません。クライアントでは、そのアプリケーションのクラスパスにCOHERENCE_HOME/lib/coherence.jarライブラリを含める必要があります。Coherence構成ファイルは、クラスパスに含まれcoherence.jarライブラリの前にある必要があります(デフォルトの名前を使用している場合)。それ以外の場合、coherence.jarライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、クライアントがAPPLICATION_HOME\configディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME\lib\myClassesライブラリにある実装クラスを使用します。

java -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.MyApp

(オペレーション・オーバーライド・ファイルを変更せずに)システム・プロパティの構成オーバーライドを含める場合、javaコマンドに対して-D引数として含めることができます。たとえば、クライアントへの格納を無効にするには、tangosol.coherence.distributed.localstorageシステム・プロパティを次のように使用できます。

java -Dcoherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.MyApp

注意:

キャッシュ・サーバーへのデプロイメントにGARが使用されている場合、キャッシュ・サービスはアプリケーション・スコープ名によって制限されます。クライアントは同じアプリケーション・スコープ名を使用する必要があります。それ以外の場合、クライアントはキャッシュ・サービスにアクセスできません。アプリケーション・スコープ名の指定の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。

Extendクライアント用プロキシ層のデプロイ

プロキシ層はExtendクライアントのリクエストを処理するプロキシ・サーバーから構成されます。プロキシ層では任意の数のプロキシ・サーバーが必要な場合があります。プロキシ・サーバーの数は、予想されるExtendクライアントの数および予想されるクライアントのリクエスト負荷に依存します。各プロキシ・サーバーがクラスタ・メンバーで独自のJVMプロセスを実行し、複数のプロキシ・サーバーを1つの物理サーバー上で連結できます。Extendクライアントの詳細およびプロキシの設定の詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

プロキシ・サーバーは、通常、com.tangosol.net.DefaultCacheServerクラスを使用して起動されます。このクラスにはmainメソッドが含まれ、コマンド行から起動されます。キャッシュ・サーバーの起動の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。プロキシ・サーバーとキャッシュ・サーバーとの違いは、プロキシ・サーバーはデータを格納しない点と、Extendクライアントのリクエストを処理するプロキシ・サービスをホストしないという点です。

次のアプリケーション・アーティファクトは、プロキシとともにデプロイされることがあります。

- オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。

- POFシリアライザおよびドメイン・オブジェクト。ExtendクライアントがC++または.NETを使用して実装されている場合、オブジェクトのJavaバージョンも特定のユース・ケース用にデプロイする必要があります。

- 問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。

- イベント処理実装。

- データ・ソースからオブジェクトをキャッシュする際のキャッシュ・ストアおよびローダー実装。

アプリケーション・アーティファクトをプロキシ層にパッケージ化する方法に制限はありません。ただし、アーティファクトはサーバーのクラスパスにあり、すべての構成ファイルがcoherence.jarライブラリの前にある必要があります。それ以外の場合、coherence.jarライブラリにあるデフォルトの構成ファイルがロードされます。次の例では、単一のプロキシ・サーバーがAPPLICATION_HOME\configディレクトリにある構成ファイルを使用して起動し、APPLICATION_HOME\lib\myClassesライブラリにある実装クラスを使用します。

java -server -Xms512m -Xmx512m -Dcoherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer

GARデプロイメント

Coherenceアプリケーション・アーティファクトは、グリッド・アーカイブ(GAR)としてパッケージ化してDefaultCacheServerクラスでデプロイできます。GARは特定のディレクトリ構造に準拠し、アプリケーション・ディスクリプタを含みます。GARパッケージ化の詳細は、「Coherence GARモジュールの構築」を参照してください。手順はWebLogicサーバー・デプロイメントの一部として含まれていますが、DefaultCacheServerクラスでデプロイ中のGARにも適用できます。

次の例では、プロキシ・サーバーを起動してMyGar.garファイルにパッケージ化されているアプリケーション・アーティファクトを使用します。デフォルト名(MyGAR)はアプリケーション名として使用され、クラスタ上のアプリケーションの有効範囲を提供します。

java -server -Xms512m -Xmx512m -Dcoherence.distributed.localstorage=false -cp APPLICATION_HOME\config;APPLICATION_HOME\lib\myClasses.jar;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar

デフォルト名は引数として別の名前を指定することでオーバーライドできます。有効なDefaultCacheServer引数の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。アプリケーション・スコープの詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。

Extendクライアントのデプロイ

ExtendクライアントはJava、C++または.NETアプリケーションとして実装されます。また、RESTクライアントAPIを提供する任意のクライアント・テクノロジでCoherenceクラスタにキャッシング・サービスを使用できます。ExtendクライアントはCoherenceキャッシュを使用するアプリケーションですが、Coherenceクラスタのメンバーではありません。これらのクライアントに固有のデプロイメントの詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

次のCoherenceアーティファクトは、Extendクライアントとともにデプロイされることがあります。

- オペレーション・オーバーライド構成ファイル、キャッシュ構成ファイルおよびPOFユーザー・タイプ構成ファイルなどの構成ファイル。

- POFシリアライザおよびドメイン・オブジェクト。

- 問合せ、エントリ・プロセッサ、エントリ・アグリゲータなどのデータ・グリッド処理実装。

- イベント処理実装。

CoherenceアプリケーションのWebLogic Serverへのデプロイ

WebLogic Serverには、WebLogic Serverドメイン内にCoherenceアプリケーションをデプロイして管理できる方法を標準化するCoherence統合機能が含まれています。この統合機能により、管理者は使い慣れたWebLogic Serverコンポーネントとインフラストラクチャ(Java EEスタイルのパッケージ化とデプロイメント、リモート・サーバー管理、サーバー・クラスタ、WebLogic Scripting Tool (WLST)自動化や管理コンソールからの構成など)を使用して分散Coherence環境の設定ができます。

この項で説明する手順は、WebLogicサーバーについてある程度の知識があることを想定しています。また、WebLogicサーバー・ドメインが作成済であることを想定しています。すべての手順の説明では、WebLogic Server管理コンソールを使用します。WebLogic Server管理コンソールの使用の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。Coherenceクラスタの構成および管理の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。

この項には次のトピックが含まれます:

- WebLogic Server Coherence統合機能の概要

- WebLogic Server用のCoherenceアプリケーションのパッケージ化

- Coherence用のWebLogic Serverドメイン・トポロジの設定

- CoherenceアプリケーションのWebLogic Serverドメインへのデプロイ

- 基本的なCoherence管理タスクの実行

WebLogic Server Coherence統合機能の概要

CoherenceはWebLogic Serverと統合されます。統合により、Coherenceクラスタ・メンバーのライフサイクルを、管理対象サーバーのライフサイクルに合せ、つまり、サーバーJVMの開始と終了に合せてCoherenceクラスタ・メンバーを開始および終了することになります。クラスタの最初のメンバーがクラスタ・サービスを開始し、シニア・メンバーになります。

その他のJava EEモジュールと同様に、Coherenceは、グリッド・アーカイブ(GAR)という独自のアプリケーション・モジュールをサポートします。GARには、Coherenceアプリケーションのアーティファクトが格納され、デプロイメント・ディスクリプタが含まれています。GARは、その他のJava EEモジュールと同じ方法でデプロイおよびアンデプロイするため、クラスタ・サービス・ライフタイムから分離されます。Coherenceアプリケーションは、サービスの名前空間ごと、およびクラス・ローダーごとに分離されます。

Coherenceは、通常、Weblogic Serverドメイン内への機能的分離を提供する層に設定されます。最も一般的な層は、データをキャッシングするためのデータ層およびキャッシュされたデータを使用するためのアプリケーション層です。プロキシ・サーバー層およびExtendクライアント層は、Coherence*Extendを使用する際に設定する必要があります。HTTPセッション層は、Coherence*Webを使用する際に設定する必要があります。Coherence*WebのデプロイおよびHTTPセッション・データの管理の手順は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。

Coherenceクラスタに関連付けられたWebLogic管理対象サーバーは、管理対象Coherenceサーバーと呼ばれます。各層内の管理対象Coherenceサーバーは個別に管理することもできますが、通常はそれぞれのWebLogicサーバー・クラスタに関連付けられます。GARは、データ層サーバーおよびプロキシ層サーバーごとにデプロイする必要があります。その後で、同一のGARは1つのEAR内にパッケージ化し、それぞれのアプリケーションおよびExtendクライアント層サーバーにデプロイします。クライアント層とは別の専用の記憶域層を使用することが、最適なパフォーマンスを実現するためのベスト・プラクティスになります。

WebLogic Server用のCoherenceアプリケーションのパッケージ化

Coherenceアプリケーションは、GARモジュールとしてデプロイメントするためにパッケージ化する必要があります。GARモジュールは、Coherenceアプリケーションから成るアーティファクトを含み、特定のディレクトリ構造を保持します。GARは、アーカイブ化解除されたディレクトリとして残すことも、.gar拡張子を付けてアーカイブ化することもできます。GARは、スタンドアロン・モジュールとしてデプロイするか、EAR内にデプロイします。EARは複数のGARモジュールを含むことができません。

Coherence GARモジュールの構築

Coherence GARモジュールを構築する手順は、次のとおりです。

1. 次のGARディレクトリ構造を作成します。

/
/lib/
/META-INF/

2. Coherenceキャッシュ構成ファイルと、POF構成ファイル(必要な場合)をGAR内のディレクトリに追加します。次に例を示します。

/
/lib/
/META-INF/coherence-cache-config.xml
/META-INF/pof-config.xml

注意:

構成ファイルは、GARのルート・ディレクトリに格納しないでください。構成ファイルがルート・ディレクトリに格納されている場合は、ここに示したデフォルト名は使用しません。そのかわりに、これらの構成ファイルはシステム・クラスパス内に格納されたcoherence.jarファイルからロードされます。

3. coherence-application.xmlデプロイメント・ディスクリプタ・ファイルを作成して、このファイルを/META-INFディレクトリに保存します。Coherence GARには、META-INFディレクトリ内にあるcoherence-application.xmlデプロイメント・ディスクリプタが含まれている必要があります。デプロイメント・ディスクリプタが存在することで、有効なGARが示されます。

/
/lib/
/META-INF/coherence-application.xml
/META-INF/coherence-cache-config.xml
/META-INF/pof-config.xml

4. coherence-application.xmlファイルを編集して、手順2で追加した構成ファイルの場所を指定します。次に例を示します。

<?xml version="1.0"?>
<coherence-application>
xmlns="http://xmnls.oracle.com/coherence/coherence-application">
<cache-configuration-ref>META-INF/coherence-cache-config.xml
</cache-configuration-ref>
<pof-configuration-ref>META-INF/pof-config.xml</pof-configuration-ref>
</coherence-application>

注意:

- 構成ファイルは、GARにローカルにコピーするかわりに、ネットワーク上に格納してURLで参照できます。

- キャッシュ構成ファイルは実行時にクラスタ・キャッシュ構成ファイルでオーバーライドできます。詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。

- キャッシュ構成ファイルは実行時にJNDIプロパティを使用してオーバーライドすることもできます。『Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』および『Oracle WebLogic Serverクラスタの管理』を参照してください。

5. すべてのCoherenceアプリケーションのJavaクラス(エントリ・プロセッサ、アグリゲータ、フィルタなど)を該当パッケージ構造内のルート・ディレクトリに配置します。

6. すべてのライブラリ依存性を/libディレクトリに格納します。

7. ルート・ディレクトリからJavaのjarコマンドを使用して、.gar拡張子を付けてアーカイブを圧縮します。次に例を示します。

jar cvf MyApp.gar *

GARモジュールのEARモジュール内へのパッケージ化

GARモジュールはEARモジュール内にパッケージ化して、他のモジュールから参照できるようにする必要があります。EARモジュールの作成方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』を参照してください。

GARモジュールをEARモジュール内に含める手順は、次のとおりです。

1. EARのルート・ディレクトリにGARと、Coherenceを使用するすべてのアプリケーション・モジュール(WAR、EJBなど)をコピーします。

2. META-INF/weblogic-application.xmlディスクリプタを編集し、<module>要素を使用してGARへの参照を含めます。参照は、EARがデプロイされたときにGARがデプロイされるために必要です。次に例を示します。

<?xml version = '1.0'>
<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application
http://www.bea.com/ns/weblogic/weblogic-application/1.0/
weblogic-application.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-application">
<module>
<name>MyAppGAR</name>
<type>GAR</type>
<path>MyApp.gar</path>
</module>
</weblogic-application>

Coherence用のWebLogic Serverドメイン・トポロジの設定

CoherenceはWebLogic Serverドメインの各種ドメイン・トポロジをサポートすることで、様々なレベルのパフォーマンス、スケーラビリティおよび使いやすさを実現します。たとえば、開発時には単一の管理対象Coherenceサーバー・インスタンスを、キャッシュ・サーバーとしても、キャッシュ・クライアントとしても使用できます。単一サーバー・トポロジは、設定と使用が容易ですが、最適なパフォーマンスまたはスケーラビリティを提供しません。本番の場合、Coherenceは、通常、WebLogic Serverクラスタを使用して設定します。1つのWebLogic Serverクラスタが、Coherenceデータ層として使用され、1つ以上のキャッシュ・サーバーをホストします。Coherenceアプリケーション層には別のWebLogic Serverクラスタが使用され、1つ以上のキャッシュ・クライアントをホストします。そして、(必要な場合) 1つ以上の管理対象Coherenceプロキシ・サーバーをホストするCoherenceプロキシ層、および拡張クライアントをホストするCoherence拡張クライアント層には、さらに別のWebLogic Serverクラスタが使用されます。階層型トポロジのアプローチにより、最適なスケーラビリティとパフォーマンスが提供されます。ドメイン・トポロジは、常にアプリケーションの要件に基づいている必要があります。

Coherence用のドメイン・トポロジを作成する際には、次のガイドラインを使用してください。

- ドメインは、通常、単一のCoherenceクラスタを含んでいます。

- 1つのCoherenceクラスタには、複数のWebLogic Serverクラスタを関連付けることができます。

- Coherenceクラスタに関連付けられた管理対象サーバーは、管理対象Coherenceサーバーとみなされ、Coherenceクラスタ・メンバーと同じになります。

- 別の管理対象Coherenceサーバー・インスタンス(可能ならば別のWebLogic Serverクラスタ)を使用して、Coherenceのキャッシュ・サーバーとクライアントを分離します。

- WebLogic Serverドメイン内で管理されるCoherenceメンバーは、スタンドアロンのJVMメンバーで構成される外部のCoherenceクラスタに参加してはいけません。スタンドアロンのJVMクラスタ・メンバーを、WebLogic Serverドメイン内で管理することはできません。

Coherenceクラスタの作成

WebLogic Serverコンソールを使用して、Coherenceクラスタを作成するには:

1. コンソールのホーム・ページの「環境」セクションで、「Coherenceクラスタ」をクリックします。

2. 「Coherenceクラスタのサマリー」ページで、「新規」をクリックします。

3. 「Coherenceクラスタ構成の作成」ページの「名前」フィールドに、クラスタの名前を入力します。

4. 「次へ」をクリックして、手順6に進みます。

または

「カスタム・クラスタ構成ファイルの使用」チェック・ボックスをクリックして選択します。WebLogic Server MBeanは、ほとんどのユース・ケースに十分な操作設定のサブセットを公開します。ただし、操作設定の完全な制御が必要になる高度なユース・ケースの場合は、クラスタ構成ファイル(tangosol-coherence-override.xmlファイルなど)を使用できます。「次」をクリックします。クラスタ操作設定の使用方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

注意:

外部クラスタ構成ファイルの使用をお薦めするのは、提供されているMBeanでは使用できない操作設定に対してのみです。つまり、外部クラスタ構成ファイルとMBeanの両方で同じ操作設定を構成することは避けてください。

5. Coherenceクラスタ構成ファイルの作成画面から、管理サーバーに格納されたクラスタ構成ファイルのパスと名前を「ファイル・パス」フィールドに入力します。「次へ」をクリックして、手順7に進みます。

6. 「Coherenceクラスタのアドレス指定」セクションからデフォルトのクラスタリング・モード(ユニキャスト)をそのまま使用して、必要に応じてポートを変更します。マルチキャストを使用するには、ドロップダウン・リストを使用して「マルチキャスト」を選択し、クラスタ用の一意のマルチキャスト・アドレスとポートを指定します。「次」をクリックします。

ユニキャストが使用されている場合、クラスタはCoherenceクラスタ(マシン当たり1つ)の管理対象Coherenceサーバー・インスタンスに基づいて自動的にウェル・ノウン・アドレス(WKA)のリストを作成します。メンバーの数を変更する場合は、管理コンソールを使用してクラスタ定義を編集し、独自のWKAリストを定義できます。アドレスは、localhostではなくホスト上の実際のIPアドレスを使用して入力する必要があります。それ以外の場合は管理対象Coherenceサーバーは他のクラスタ・メンバーに参加できなくなります。WKAの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

7. Coherenceクラスタ・メンバー・セクションで、Coherenceクラスタに加える管理対象CoherenceサーバーまたはWebLogic Serverクラスタをクリックして選択します。管理対象サーバーやWebLogicクラスタがまだ定義されていない場合は、このセクションを省略します。

8. 「終了」をクリックします。「Coherenceクラスタの概要」画面が表示され、「Coherenceクラスタ」表にクラスタが一覧表示されます。

Coherenceデプロイメント層の作成

WLSドメインにCoherenceを設定する際に優先されるアプローチでは、Coherenceキャッシュのサーバー、クライアントおよびプロキシを、同一のCoherenceクラスタに関連付けられた別々の層に分割します。一般に、各層は管理対象Coherenceサーバーの独自のWebLogic Serverクラスタに関連付けられます。ただし、1つの層が複数のスタンドアロン管理対象Coherenceサーバーから構成されていることもあります。前者のアプローチを使用すると、Coherenceの管理とスケールは最も簡単になります。これは、管理対象CoherenceサーバーはWebLogic ServerクラスタのCoherence設定を継承してデプロイメントできるためです。この項の手順を使用して、データ層、アプリケーション層およびプロキシ層に個別のWebLogic Serverクラスタを作成します。WebLogic Serverクラスタ作成の詳細な手順は、Oracle WebLogic Serverのクラスタ管理を参照してください。

Coherenceデプロイメント層を作成するには:

1. コンソールのホーム・ページの「環境」セクションで、「クラスタ」をクリックします。

2. 「クラスタの概要」ページから、「新規」をクリックして「クラスタ」を選択します。

3. 「新しいクラスタの作成」ページから、「名前」フィールドを使用してWebLogic Serverクラスタの名前を入力します。

4. デフォルトのメッセージングング・モード(ユニキャスト)をそのまま使用して、必要に応じてブロードキャスト・チャネルを変更します。または、ドロップダウン・リストから「マルチキャスト」を選択して、個別のマルチキャスト・アドレスとポートを必要に応じて指定します。

5. 「OK」をクリックします。「クラスタのサマリー」画面が表示され、「クラスタ」表にクラスタが一覧表示されます。

6. 「クラスタ」表で、構成するクラスタをクリックします。

7. 「Coherence」タブの「Coherenceクラスタ」ドロップダウン・リストを使用して、Coherenceクラスタを選択してこのWebLogic Serverクラスタに関連付けます。「保存」をクリックします。デフォルトでは、このWebLogic Serverクラスタに割り当てた管理対象Coherenceサーバーは、記憶域が有効なCoherenceメンバー(キャッシュ・サーバー)になります。これについては、「ローカル記憶域有効」フィールドに示されます。

8. 手順1から6を繰り返して、アプリケーション層に使用する別のWebLogic Serverクラスタを作成します。「Coherence」タブで、「Coherenceクラスタ」ドロップダウン・リストを使用して、このWebLogic Serverクラスタに関連付けるCoherenceクラスタを選択します。

9. 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、アプリケーション層でストレージを無効にします。このWebLogic Serverクラスタに割り当てられる管理対象Coherenceサーバーは、ストレージが無効なCoherenceメンバー(キャッシュ・ファクトリ・クライアント)になります。「保存」をクリックします。

10. (該当する場合)手順1から6を繰り返して、プロキシ層に使用する別のWebLogic Serverクラスタを作成します。「Coherence」タブで、「Coherenceクラスタ」ドロップダウン・リストを使用して、このWebLogic Serverクラスタに関連付けるCoherenceクラスタを選択します。

11. 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、プロキシ層でストレージを無効にします。このWebLogic Serverクラスタに割り当てた管理対象Coherenceサーバーは、記憶域が無効なCoherenceメンバーになります。「保存」をクリックします。

12. (該当する場合)手順1から6を繰り返して、Extendクライアント層に使用する別のWebLogic Serverクラスタを作成します。「Coherence」タブで、「Coherenceクラスタ」ドロップダウン・リストを使用して、このWebLogic Serverクラスタに関連付けるCoherenceクラスタを選択します。

13. 「ローカル記憶域有効」チェック・ボックスをクリックして、チェック・マークを削除し、プロキシ層でストレージを無効にします。このWebLogic Serverクラスタに割り当てた管理対象Coherenceサーバーは、記憶域が無効なCoherenceメンバーになります。「保存」をクリックします。

Coherenceデプロイメント層用の管理対象Coherenceサーバーの作成

Coherenceクラスタに関連付けられた管理対象サーバーは、Coherenceクラスタのメンバーになり、管理対象Coherenceサーバーと呼ばれます。この項の手順を使用して、管理対象サーバーを作成し、そのサーバーをWebLogic Serverクラスタに関連付けます。このクラスタは、Coherenceデプロイメント層として構成します。管理対象サーバーは、WebLogic ServerクラスタからCoherence設定を自動的に継承します。同様に、既存の管理対象CoherenceサーバーもWebLogic Serverクラスタに関連付けできます。管理対象サーバーの作成手順および構成手順の詳細は、Oracle WebLogic Server管理コンソール・オンラン・ヘルプを参照してください。

Coherenceデプロイメント層用の管理対象サーバーを作成するには:

1. コンソールのホーム・ページの「環境」セクションで、「サーバー」をクリックします。

2. 「新規」をクリックして、新しい管理対象サーバーを作成します。

3. 「新しいサーバーの作成」ページで、必要に応じてサーバーのプロパティを入力します。

4. 「はい」オプションをクリックして、既存のクラスタにサーバーを追加し、ドロップダウン・リストを使用してCoherence層として構成するWebLogic Serverクラスタを選択します。管理対象サーバーは、WebLogic ServerクラスタからCoherence設定を継承します。

5. 「終了」をクリックします。「サーバーのサマリー」ページが表示され、新しいサーバーが示されます。

6. これらの手順を繰り返して、必要に応じて追加の管理対象サーバーを作成します。

7. 「制御」タブをクリックし、サーバーを選択してから「起動」をクリックします。サーバーの起動の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。

CoherenceアプリケーションのWebLogic Serverドメインへのデプロイ

各Coherenceデプロイメント層には、Coherenceアプリケーション・モジュールを含める必要があります。アプリケーション・モジュールのデプロイで、GARのキャッシュ構成ファイルに定義されたサービスが開始します。Coherenceアプリケーションをパッケージ化する方法の詳細は、「WebLogic Server用のCoherenceアプリケーションのパッケージ化」を参照してください。コンソールを使用してアプリケーションをデプロイする方法の詳細は、WebLogic Server管理コンソール・ヘルプを参照してください。

Coherenceモジュールは、次のようにデプロイします。

- データ層(キャッシュ・サーバー): スタンドアロンのGARをデータ層の各管理対象Coherenceサーバーにデプロイします。データ層がWebLogic Serverクラスタとして設定されている場合、GARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。

- アプリケーション層(キャッシュ・クライアント): GARおよびクライアント実装(WebアプリケーションやEJBなど)を格納するEARをクラスタ内の各管理対象Coherenceサーバーにデプロイします。アプリケーション層がWebLogic Serverクラスタとして設定されている場合、EARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。

- プロキシ層(プロキシ・サーバー): スタンドアロンのGARをプロキシ層の各管理対象Coherenceサーバーにデプロイします。プロキシ層がWebLogic Serverクラスタとして設定されている場合、GARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象Coherenceサーバーにモジュールがコピーされます。

注意:

プロキシ層の管理対象Coherenceサーバーには、キャッシュ構成ファイルにプロキシ・サービスの定義が含まれている必要があります。同じGARを各層にデプロイしてから、クラスタレベル・キャッシュ構成ファイルを使用してプロキシ層サーバーのみのキャッシュ構成ファイルをオーバーライドできます。クラスタレベル・キャッシュの指定の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。

- Extendクライアント層(Extendクライアント) – GARおよびExtendクライアント実装を含むEARが、Extendクライアントをホストする各管理対象サーバーにデプロイされます。Extendクライアント層がWebLogic Serverクラスタとして設定されている場合、EARがクラスタにデプロイされ、WebLogicデプロイメント・インフラストラクチャで各管理対象サーバーにモジュールがコピーされます。

注意:

Extend層の管理対象サーバーには、キャッシュ構成ファイルにリモート・キャッシュ・サービスの定義が含まれている必要があります。同じGARを各層にデプロイしてから、クラスタレベル・キャッシュ構成ファイルを使用してExtend層サーバーのみのキャッシュ構成ファイルをオーバーライドできます。クラスタレベル・キャッシュの指定の詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。

データ層GARのデプロイ

データ層にGARをデプロイするには:

1. コンソールのホーム・ページの「デプロイ済みリソース」セクションで、「デプロイメント」をクリックします。

2. 「インストール」をクリックします。

3. 「アプリケーション・インストール・アシスタント」ページで、デプロイするGARを見つけて選択します。「次」をクリックします。

4. GARのデプロイ先になるデータ層(WebLogic Serverクラスタまたはスタンドアロンの管理対象Coherenceサーバー)を選択します。「次」をクリックします。

5. 「送信元」のアクセシビリティ設定を編集し、各ターゲットにモジュールをコピーするオプションを選択します。「終了」をクリックします。「デプロイメントのサマリー」ページが表示され、「デプロイメント」表にGARが一覧表示されます。

6. デプロイメントの一覧からGARのチェック・ボックスを選択して、「開始」をクリックします。

アプリケーション層EARのデプロイ

アプリケーション層にEARをデプロイするには:

1. コンソールのホーム・ページの「デプロイ済みリソース」セクションで、「デプロイメント」をクリックします。

2. 「インストール」をクリックします。

3. 「アプリケーション・インストール・アシスタント」ページで、デプロイするEARを見つけて選択します。「次」をクリックします。

4. デフォルトのターゲット・スタイルをそのまま使用して、「次へ」をクリックします。

5. EARのデプロイ先になるアプリケーション層(WebLogic Serverクラスタまたはスタンドアロンの管理対象Coherenceサーバー)を選択します。「次」をクリックします。

6. 「送信元」のアクセシビリティ設定を編集し、各ターゲットにモジュールをコピーするオプションを選択します。「終了」をクリックします。「デプロイメントのサマリー」ページが表示され、「デプロイメント」表にEARが一覧表示されます。

7. デプロイメントの一覧からEARのチェック・ボックスを選択して、「開始」をクリックします。

プロキシ層GARのデプロイ

プロキシ層にGARをデプロイするには:

1. コンソールのホーム・ページの「デプロイ済みリソース」セクションで、「デプロイメント」をクリックします。

2. 「インストール」をクリックします。

3. 「アプリケーション・インストール・アシスタント」ページで、デプロイするGARを見つけて選択します。「次」をクリックします。

4. GARのデプロイ先になるプロキシ層(WebLogic Serverクラスタまたはスタンドアロンの管理対象Coherenceサーバー)を選択します。「次」をクリックします。

5. 「送信元」のアクセシビリティ設定を編集し、各ターゲットにモジュールをコピーするオプションを選択します。「終了」をクリックします。「デプロイメントのサマリー」ページが表示され、「デプロイメント」表にGARが一覧表示されます。

6. デプロイメントの一覧からGARのチェック・ボックスを選択して、「開始」をクリックします。

基本的なCoherence管理タスクの実行

管理者は、WebLogic Serverツールを使用して、WebLogicドメイン内のCoherence環境を管理します。これらのツールを使用すると、クラスタやクラスタ・メンバーの管理タスクが簡単になります。この項では、基本的な管理タスクを実行するために、管理コンソール・ツールを使用する方法の概要について説明します。これらのタスクを完了する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。WebLogic Scripting Tool (WLST)の使用の詳細は、『WebLogic Scripting Toolの理解』を参照してください。

表1-1 管理コンソールでの基本的な管理タスク

目的

使用対象

Coherenceクラスタの作成

「Coherenceクラスタ」ページ

クラスタ・メンバーの追加または削除、またはCoherenceクラスタからのWebLogic Serverクラスタの追加または削除

Coherenceクラスタの「設定」ページにある「メンバー」タブ。

Coherenceクラスタのユニキャスト設定またはマルチキャスト設定の構成

Coherenceクラスタの「設定」ページにある「一般」タブ。ユニキャストを選択した場合、デフォルトのウェル・ノウン・アドレス構成は、「Well Knownアドレス」タブを使用してオーバーライドできます。

Coherenceクラスタを構成するためのカスタム構成ファイルの使用

Coherenceクラスタの「設定」ページにある「一般」タブ

クラスタ・メンバーへのキャッシュ構成ファイルのインポート、およびGARにデプロイしたキャッシュ構成ファイルのオーバライド

Coherenceクラスタの「設定」ページにある「構成」タブ

ロギングの構成

Coherenceクラスタの「設定」ページにある「ロギング」タブ

Coherenceクラスタへの管理対象サーバーの割当て

管理対象サーバーの「設定」ページにある「Coherence」タブ

Coherenceクラスタ・メンバーのプロパティの構成

管理対象サーバーの「設定」ページにある「Coherence」タブ

WebLogic ServerクラスタとCoherenceクラスタとの関連付け、およびクラスタの管理対象Coherenceサーバーの記憶域の有効化または無効化

WebLogic Serverクラスタの「設定」ページにある「Coherence」タブ

Coherenceクラスタに関連付けられたWebLogic Serverクラスタへの管理対象サーバーの割当て

管理対象サーバーの「設定」ページにある「一般」タブ

Coherenceアプリケーションのアプリケーション・サーバー(汎用)へのデプロイ

WebLogic Server以外のアプリケーション・サーバーにデプロイされるJava EEアプリケーションには、Coherenceをデプロイするための2つのオプション(アプリケーション・サーバー・ライブラリとして、またはJava EEモジュールの一部としてデプロイ)があります。Coherenceクラスタのメンバーにはクラス・ローダーのスコープが設定されています。そのため、オプションの選択によってデプロイメント・シナリオが異なります。Coherenceがアプリケーション・サーバー・ライブラリとしてデプロイされている場合、すべてのモジュールは単一のクラスタ・メンバーを共有します。その一方で、Coherenceがモジュールの一部としてデプロイされている場合、Java EEモジュールは、そのモジュール自体がクラスタ・メンバーになります。どちらのオプションにも利点と前提条件があり、一般的にクラスタ・メンバーが他のモジュールから分離されている程度とリソース利用率とのバランスが取られます。

注意:

Coherence*WebのデプロイおよびHTTPセッション・データのクラスタリングの手順は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。

アプリケーション・サーバー・ライブラリとしてのCoherenceのデプロイ

Coherenceをアプリケーション・サーバー・ライブラリとしてデプロイできます。このデプロイメント・シナリオでは、アプリケーション・サーバーの起動クラスパスをCOHERENCE_HOME/lib/coherence.jarライブラリが含まれるように変更します。また、キャッシュに配置するオブジェクトはすべて、サーバーのクラスパスで使用できる必要があります。ライブラリをサーバーのクラスパスに追加する手順は、アプリケーション・サーバーのベンダーのドキュメントを参照してください。

このシナリオでは、サーバーのコンテナにデプロイされたすべてのアプリケーションで1つのクラスタ・メンバーを共有するようになります。このシナリオでは、Coherenceクラスの1つのコピーのみがJVMにロードされるため、リソース使用率が最小限に抑えられます。このデプロイメント・スタイルを選択したときに、Coherenceアプリケーションを相互に分離する手順の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。

Java EEモジュール内へのCoherenceのデプロイ

CoherenceをEARファイルまたはWARファイル内にデプロイできます。一般に、このデプロイメント・スタイルは、アプリケーション・サーバーの実行時環境に変更を加える必要がなく、クラスタ・メンバーはEARまたはWARのどちらかに分離されているため、優先的に選択されます。

EAR内へのCoherenceのデプロイ

CoherenceをEARの一部としてデプロイできます。このデプロイメント・シナリオでは、EAR内のすべてのWebアプリケーションで1つのクラスタ・メンバーを共有することになります。EARごとにCoherenceクラスのコピーが1つのみロードされるため、リソース使用率は中程度になります。ただし、クラスタ・メンバーによる、いずれか1つのモジュールの使用が、すべてのWebアプリケーションに影響を与える可能性があります。Coherenceアプリケーションを相互に分離する手順の詳細は、「単一クラスタでの複数のアプリケーションの実行」を参照してください。

Coherenceをエンタープライズ・アプリケーション内にデプロイする手順は次のとおりです。

1. coherence.jarライブラリを、エンタープライズ・アプリケーションのディレクトリ構造内の任意の場所にコピーします。

2. テキスト・エディタを使用して、META-INF/application.xmlデプロイメント・ディスクリプタを開きます。

3. アプリケーション・ディレクトリの最上位に対する相対パスおよびCoherenceライブラリの名前が含まれる<java>要素を追加します。次に例を示します。

<application>
<display-name>MyApp</display-name>
<module>
<java>coherence.jar</java>
</module>
...
</application>

4. キャッシュに配置するオブジェクトすべてを前述の方法でアプリケーションに追加します。

5. ディスクリプタを保存して閉じます。

6. アプリケーションをパッケージ化してデプロイします。

WAR内へのCoherenceのデプロイ

CoherenceをWebアプリケーションの一部としてデプロイできます。このデプロイメント・シナリオでは、それぞれのWebアプリケーションが固有のクラスタ・メンバーを持ち、他のすべてのWebアプリケーションから分離されるようになります。このシナリオでは、Coherenceを含むWebアプリケーションがデプロイされる数と同じ数のCoherenceクラスのコピーがロードされるため、リソースを最も大量に使用します。このシナリオは、1つのアプリケーション・サーバーに数個のWebアプリケーションのみをデプロイする場合に適しています。

CoherenceをWebアプリケーション内にデプロイする手順は次のとおりです。

1. WebアプリケーションのWEB-INF/libディレクトリにcoherence.jarライブラリをコピーします。

2. キャッシュに配置するすべてのオブジェクトが、WEB-INF/libディレクトリまたはWEB-INF/classesディレクトリに配置されていることを確認します。

3. アプリケーションをパッケージ化してデプロイします。

単一クラスタでの複数のアプリケーションの実行

Coherenceは、独自のCoherenceキャッシュとサーバーのセットを定義すれば、複数のアプリケーションが同一のクラスタを使用する共有環境にデプロイできます。このようなシナリオの場合、各アプリケーションは、スコープ名を含む独自のキャッシュ構成ファイルを使用します。このスコープ名によって、アプリケーション間でキャッシュとサービスを共有できるようにするかどうかを制御します。

この項の内容は、次のとおりです。

- スコープ名の指定

- WebLogic Server内のアプリケーションのスコープ設定

- Java EE環境(汎用)内のアプリケーションのスコープ設定

- スタンドアロン環境内のアプリケーションのスコープ設定

- カスタム・スコープ・リゾルバの指定

スコープ名の指定

<scope-name>要素を使用して、キャッシュ構成ファイル内でキャッシュとサービスを一意に特定するサービスの名前空間を指定します。これが指定されていると、すべてのキャッシュとサービスは分離され、同一クラスタで実行する他のアプリケーションからは使用できなくなります。

次の例では、accountsというスコープ名を構成します。これにより、その構成に基づいて作成されたConfigurableCacheFactoryインスタンスでインスタンス化されるすべてのサービスは、接頭辞としてaccountsを使用するようになります。スコープ名は、キャッシュ・ファクトリ・インスタンスの属性であり、キャッシュ・ファクトリのインスタンスにのみ影響します。

注意:

この接頭辞は、サービス名にのみ使用します。キャッシュ名には使用しません。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>accounts</scope-name>
</defaults>
<caching-scheme-mapping>
...

WebLogic Server内のアプリケーションのスコープ設定

WebLogic Serverにデプロイするときには、デプロイされた複数のCoherenceアプリケーション(GAR)が、サービスの名前空間ごと、およびデフォルトのClassLoaderごとにWebLogic Server内で分離されるため、スコープ名の構成は必要ありません。ただし、スコープ名はGAR間でキャッシュを共有するために構成することもできます。キャッシュ構成ファイルでのスコープの直接構成は、通常、上級ユーザー・ケースで実行されます。

デプロイメント名は、GARのデプロイ時にデフォルトのスコープ名として使用されます。デプロイメント名がデプロイ中に指定されない場合、アーティファクト名がデプロイメント名として使用されます。たとえば、MyApp.garモジュールの場合、デフォルトのデプロイメント名はMyAppです。EARにパッケージ化されたGARの場合、デプロイメント名はweblogic-application.xmlファイルのGARに指定されたモジュール名です。

Java EE環境(汎用)内のアプリケーションのスコープ設定

アプリケーション・サーバー・ライブラリまたはEARの一部としてCoherenceをデプロイすると、複数のアプリケーションが単一のクラスタ・メンバー(1つのJVM)として同一のクラスタを使用できます。このようなデプロイメント・シナリオでは、複数のアプリケーションが、単一のcoherence-cache-config.xmlファイルで構成された1つのCoherenceのキャッシュとサービスのセットを使用することを選択できます。このタイプのデプロイメントは、アプリケーションのデプロイメントが調整された制御環境においてのみお薦めします(また、その場合にのみ実用的になります)。キャッシュ間、サービス間およびその他の構成設定間で衝突する可能性が高く、想定外の結果を招くことがあります。さらに、Coherenceノードの1つのアプリケーションの使用が、すべてのアプリケーションに影響を及ぼす可能性もあります。

別の方法として、各アプリケーションに独自のキャッシュ構成ファイルを含めるようにします。この構成ファイルでは、そのアプリケーションに固有のキャッシュとサービスを定義します。この構成は、キャッシュ構成ファイル内の<scope-name>要素を使用して指定したスコープ名で分離されます。同様に、アプリケーションは、その他のアプリケーションが必要とするときにはキャッシュとサービスの共有を明示的に許可できます。このシナリオでは、それぞれが1つのアプリケーションに関連する複数のConfigurableCacheFactoryインスタンスが、1つのJVMに含まれていることを想定しています。

Java EE環境内のアプリケーションの分離

次の例では、2つのWebアプリケーション(trade.warおよびaccounts.war)を分離するために必要な手順を示します。これにより、それぞれのアプリケーションのキャッシュとサービスを相互に使用しないようにします。

1. tradeアプリケーション用のキャッシュ構成ファイル(たとえば、trade-cache-config.xml)を作成します。この構成ファイルでは、tradeというスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>trade</scope-name>
</defaults>
...

2. accountsアプリケーション用のキャッシュ構成ファイル(たとえば、accounts-cache-config.xml)を作成します。この構成ファイルでは、accountsというスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>accounts</scope-name>
</defaults>
...

3. 各キャッシュ構成ファイルが、それぞれのWARファイル(通常は、WEB-INF/classesディレクトリ内にあります)に含まれていることを確認します。これにより、アプリケーションは実行時に構成ファイルをロードして使用できるようになります。

Java EE環境内のアプリケーション・データの共有

各アプリケーションは、それらのキャッシュとサービスへのアクセスを許可することで、データを共有できます。次の例では、Webアプリケーション(trade.war)が別のアプリケーション(accounts.war)のキャッシュとサービスにアクセスできるようにする手順を示します。

1. tradeアプリケーション用のキャッシュ構成ファイル(たとえば、trade-cache-config.xml)を作成します。この構成ファイルでは、tradeというスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>trade</scope-name>
</defaults>
...

2. accountsアプリケーション用のキャッシュ構成ファイル(たとえば、accounts-cache-config.xml)を作成します。この構成ファイルでは、accountsというスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>accounts</scope-name>
</defaults>
...

3. 各キャッシュ構成ファイルが、それぞれのWARファイル(通常は、WEB-INF/classesディレクトリ内にあります)に含まれていることを確認します。これにより、アプリケーションは実行時に構成ファイルをロードして使用できるようになります。

4. tradeアプリケーションには、accountsアプリケーションのキャッシュとサービスにアクセスするためのaccounts-cache-config.xmlファイルも含める必要があります。

5. これにより、tradeアプリケーションは、accountsアプリケーション用のキャッシュ・ファクトリを作成するために、次のパターンを使用できるようになります。

ClassLoader loader = ...
CacheFactoryBuilder builder = CacheFactory.getCacheFactoryBuilder();
ConfigurableCacheFactory tradesCcf =
builder.getConfigurableCacheFactory(tradesUri, loader);
ConfigurableCacheFactory accountsCcf =
builder.getConfigurableCacheFactory(accountsUri, loader);

スタンドアロン環境内のアプリケーションのスコープ設定

単一のCoherenceクラスタを使用するスタンドアロン・アプリケーションには独自のキャッシュ構成ファイルを含めることができますが、これらの構成は単一のConfigurableCacheFactoryに結合されます。ConfigurableCacheFactoryとDefaultCacheServerの間には1対1の関係があるため、単一のクラスタ・ノード内でアプリケーションのスコープを設定できません。そのかわりに、DefaultCacheServerの1つ以上のインスタンスはキャッシュ構成ごとに開始される必要があり、各キャッシュ構成にスコープ名を含める必要があります。

次の例では、2つのアプリケーション(tradeおよびaccounts)を分離します。これにより、それぞれのアプリケーションが相互のキャッシュとサービスを使用しないようにします。

1. tradeアプリケーション用のキャッシュ構成ファイル(たとえば、trade-cache-config.xml)を作成します。この構成ファイルでは、tradeというスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>trade</scope-name>
</defaults>
...

2. DefaultCacheServerインスタンスを開始します。このインスタンスは、trade-cache-config.xmlキャッシュ構成ファイルをロードします。

3. accountsアプリケーション用のキャッシュ構成ファイル(たとえば、accounts-cache-config.xml)を作成します。この構成ファイルでは、accountsというスコープ名を定義し、そのアプリケーション用のすべてのキャッシュ・スキーム定義を含めます。

<?xml version='1.0'?>

<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<scope-name>accounts</scope-name>
</defaults>
...

4. DefaultCacheServerインスタンスを開始します。このインスタンスは、accounts-cache-config.xmlキャッシュ構成ファイルをロードします。

注意:

アプリケーション間でデータを共有する場合、それらのアプリケーションは同一のキャッシュ構成ファイルを使用する必要があります。Coherenceでは、同一のスコープ名を指定する複数のキャッシュ構成の使用をサポートしていません。

カスタム・スコープ・リゾルバの指定

com.tangosol.net.ScopeResolverインタフェースを使用すると、コンテナとアプリケーションが実行時に特定のConfigurableCacheFactoryのスコープ名を変更して、アプリケーション間の分離を強制(または無効化)できるようになります。ScopeResolverインタフェースを実装し、必要に応じてカスタム機能に追加します。

カスタム・スコープ・リゾルバを有効にするには、<cache-factory-builder-config>ノード内の<scope-resolver>要素を使用して、実装クラスの完全修飾名をオペレーション・オーバライド・ファイルに定義する必要があります。次に例を示します。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cache-factory-builder-config>
<scope-resolver>
<class-name>package.MyScopeResolver</class-name>
</scope-resolver>
</cache-factory-builder-config>
<coherence>

<instance>要素で、<class-factory-name>要素および<method-name>要素を指定することもできます。前者の要素は、ScopeResolverインスタンスを作成するファクトリ・クラスを使用します。後者の要素は、オブジェクトをインスタンス化するファクトリ・クラスに対して静的なファクトリ・メソッドを指定します。次の例では、MyScopeResolverFactoryクラスのgetResolverメソッドを使用して、カスタム・スコープ・リゾルバのインスタンスを取得しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cache-factory-builder-config>
<scope-resolver>
<class-factory-name>package.MyScopeReolverFactory</class-factory-name>
<method-name>getResolver</method-name>
</scope-resolver>
</cache-factory-builder-config>
<coherence>

実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次の例では、isDeployedパラメータにtrueを設定しています。

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cache-factory-builder-config>
<scope-resolver>
<class-name>package.MyScopeResolver</class-name>
<init-params>
<init-param>
<param-name>isDeployed</param-name>
<param-value>true</param-value>
</init-param>
</init-params>
</scope-resolver>
</cache-factory-builder-config>
<coherence>

2 ネットワーク・パフォーマンス・テストの実行

この章では、複数のコンピュータ間のネットワーク・パフォーマンスをテストする手順について説明します。データグラム・ユーティリティおよびメッセージ・バス・ユーティリティという2つのユーティリティが用意されています。本番デプロイメントの前に、両方のテストの実行に成功する必要があります。

この章の内容は次のとおりです。

- データグラム・テスト・ユーティリティの実行

- メッセージ・バス・テスト・ユーティリティの実行

データグラム・テスト・ユーティリティの実行

Coherenceデータグラム・テスト・ユーティリティは、複数のコンピュータ間のネットワーク・パフォーマンスをテストしてチューニングするために使用します。このユーティリティにより、Coherenceクラスタ管理通信に対応するようネットワークが最適に構成されます。テストには次の2種類があります。サーバーのペアのパフォーマンスをテストすることにより、それらが正しく構成されているかどうかを確認するポイント・ツー・ポイント・テストと、ネットワーク自体が正しく機能しているかどうかを確認する分散データグラム・テストです。どちらのテストの実行にも成功する必要があります。

データグラム・テストは、3種類のモード(パケット・パブリッシャまたはパケット・リスナー、あるいはその両方)のいずれかで動作します。このユーティリティを実行すると、パブリッシャがパケットをリスナーに送信し、そのリスナーがスループットや成功率などの統計を測定します。このテストの結果に基づいて環境をチューニングして、最大のパフォーマンスを実現します。詳細は、「パフォーマンス・チューニング」を参照してください。

データグラム・テスト・ユーティリティを実行するには、コマンド行からcom.tangosol.net.DatagramTestクラスを使用するか、COHERENCE_HOME/binディレクトリにあるdatagram-testスクリプトを実行します。スクリプトは、WindowsベースのプラットフォームとUNIXベースのプラットフォームの両方に用意されています。

次の例は、DatagramTestクラスの使用方法を示しています。

java -server -cp coherence.jar com.tangosol.net.DatagramTest <command value> <command value> ...

次の例は、スクリプトの使用方法を示しています。

datagram-test <command value> <command value> ...

表2-1 では、データグラム・テスト・ユーティリティで利用できるコマンド行オプションについて説明しています。

表2-1 データグラム・テスト・ユーティリティのコマンド行オプション

コマンド

必須/オプション

適用範囲

説明

デフォルト

-local

オプション

両方

バインド先のローカル・アドレス、addr:portの形式で指定

localhost:9999

-packetSize

オプション

両方

作業対象パケットのサイズ、バイト単位で指定

1468

-payload

オプション

両方

各パケットに含めるデータ量パケット・サイズを一致させるには、0を使用

0

-processBytes

オプション

両方

処理対象の各パケットのバイト数(4の倍数)

4

-rxBufferSize

オプション

リスナー

受信バッファのサイズ、パケット単位で指定

1428

-rxTimeoutMs

オプション

リスナー

接続が閉じられるまでの非アクティブ時間

1000

-txBufferSize

オプション

パブリッシャ

送信バッファのサイズ、パケット単位で指定

16

-txRate

オプション

パブリッシャ

データ送信の速度、メガバイト単位で指定

無制限

-txIterations

オプション

パブリッシャ

終了前に公開するパケット数を指定

無制限

-txDurationMs

オプション

パブリッシャ

終了前に公開する期間を指定

無制限

-reportInterval

オプション

両方

レポートを出力する間隔、パケット単位で指定

100000

-tickInterval

オプション

両方

ティック・マークを出力する間隔

1000

-log

オプション

リスナー

測定したパフォーマンスの表形式レポートを保存するファイルの名前

なし

-logInterval

オプション

リスナー

ログに測定結果を出力する間隔

100000

-polite

オプション

パブリッシャ

パブリッシャが公開を実行する前に、リスナーの接続を待つかどうかを示すスイッチ

オフ

-provider

オプション

両方

使用するソケット・プロバイダ(system、tcp、ssl、file:xxx.xml)

system

arguments

オプション

パブリッシャ

空白で区切られた公開先アドレスのリスト、addr:portの形式で指定

なし

データグラム・ネットワーク・パフォーマンスのテスト方法

この項には、ポイント・ツー・ポイント・データグラム・テストと分散データグラム・テストを実行するための手順が含まれます。どちらのテストの実行にも成功する必要があり、その際に重大なパフォーマンスの問題やパケットの損失が発生していないことも示す必要があります。テスト統計の解釈の詳細は、「データグラム・レポート統計の理解」を参照してください。

ポイント・ツー・ポイント・データグラム・テストの実行

この項の例では、サーバーA (IPアドレス195.0.0.1)と、サーバーB (IPアドレス195.0.0.2)という2つのサーバー間のネットワーク・パフォーマンスのテスト方法を示します。一方のサーバーはパケット・パブリッシャとして動作し、もう一方はパケット・リスナーとして動作します。パブリッシャは可能なかぎり高速にパケットを送信し、リスナーはパフォーマンス統計を測定して報告します。

まず、サーバーA上のリスナーを起動します。次に例を示します。

datagram-test.sh

[ENTER]を押すと、ユーティリティは、パケット受信の準備が完了していることを示します。例2-1 にサンプル出力を示します。

例2-1 リスナーの起動からの出力

starting listener: at /195.0.0.1:9999
packet size: 1468 bytes
buffer size: 1428 packets
report on: 100000 packets, 139 MBs
process: 4 bytes/packet
log: null
log on: 139 MBs

デフォルトでは、このテストにより、1428個のパケット(約2MB)を十分に保持できるネットワーク受信バッファの割当てが試行されます。このバッファの割当てができない場合、ユーティリティはエラーを報告して終了します。-rxBufferSizeパラメータを使用して要求するバッファのサイズを小さくするか、オペレーティング・システムのネットワーク・バッファの設定を大きくしてください。オペレーティング・システムのバッファを大きくすると、最適なパフォーマンスが得られます。Coherence向けのオペレーティング・システムのチューニングの詳細は、「本番チェックリスト」を参照してください。

サーバーBでパブリッシャを起動して、サーバーAに向けてパブリッシュします。次に例を示します。

datagram-test.sh servera

[ENTER]を押すと、Server Bのテスト・インスタンスによってリスナーとパブリッシャの両方が起動されます。ただし、この構成ではリスナーは使用しません。例2-2 は、Server Bのコマンド・ウィンドウに表示されるサンプル出力を示しています。

例2-2 データグラム・テスト: サーバーでのリスナーとパブリッシャの起動

starting listener: at /195.0.0.2:9999
packet size: 1468 bytes
buffer size: 1428 packets
report on: 100000 packets, 139 MBs
process: 4 bytes/packet
log: null
log on: 139 MBs

starting publisher: at /195.0.0.2:9999 sending to servera/195.0.0.1:9999
packet size: 1468 bytes
buffer size: 16 packets
report on: 100000 packets, 139 MBs
process: 4 bytes/packet
peers: 1
rate: no limit

no packet burst limit
oooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooOoooooooooO

データがネットワーク上に出力(Output)されると、一連のoとOのマークが表示されます。oはそれぞれ1000パケットを表し、10,000パケットごとにOのインジケータが表示されます。

サーバーAでは、これに対応してネットワーク入力(Input)を表すiとIのマークのセットが表示されます。これは、2つのテスト・インスタンスが通信していることを示します。

双方向データグラム・テストの実行

ポイント・ツー・ポイント・テストは、双方向モードで実行することもできます。このモードでは、サーバーがパブリッシャとリスナーとして動作します。ポイント・ツー・ポイント・テストで使用したのと同じテスト・インスタンスを使用して、サーバーAのインスタンスにサーバーBのアドレスを指定します。たとえば、サーバーAで次のコマンドを実行します。

datagram-test.sh -polite serverb

-politeパラメータを使用して、このテスト・インスタンスに対し、データの受信を開始するまでパブリッシュを開始しないように指示します。前述の同じコマンドをサーバーBで実行します。

datagram-test.sh servera

分散データグラム・テストの実行

分散テストは、3台以上のコンピュータのパフォーマンスをテストするために使用します。たとえば、1つのリスナーをターゲットにするように、2つのパブリッシャを設定できます。このスタイルのテストは単純な1対1のテストと比較してはるかに現実的で、他の方法では確認できないネットワークのボトルネックを特定できる場合があります。

次の例では、4台のコンピュータ間でダイアグラム・テストを実行します。

サーバーAの場合:

datagramtest.sh -txRate 100 -polite serverb serverc serverd

サーバーBの場合:

datagramtest.sh -txRate 100 -polite servera serverc serverd

サーバーCの場合:

datagramtest.sh -txRate 100 -polite servera serverb serverd

サーバーDの場合:

datagramtest.sh -txRate 100 servera serverb serverc

このテスト・シーケンスでは、すべてのノードは他のすべてのノードに、1秒当たりで合計100MBを送信します(1ノード当たり33MB/秒に相当)。完全にスイッチが設定された1GbEネットワークでは、パケットを失うことなくこれを達成できる必要があります。

テストの実行を簡略化するために、すべてのノードは同一のターゲット・リストを使用して起動できます。自分自身への送信も行われますが、このループバック・データは容易に除外できます。最後のノードが起動されるまで他のすべてのノードが遅延するため、最後のノードを除くすべてのノードは、-politeスイッチを使用して起動することが重要です。

データグラム・レポート統計の理解

テストのそれぞれの側(パブリッシャとリスナー)から定期的にパフォーマンス統計がレポートされます。パブリッシャでは、ネットワーク上にデータを公開する速度のみがレポートされます。次に例を示します。

Tx summary 1 peers:
life: 97 MB/sec, 69642 packets/sec
now: 98 MB/sec, 69735 packets/sec

このレポートには、現在の送信速度(前回のレポート以降)と存続期間の送信速度の両方が記載されます。

表2-2 は、リスナーでレポートできる統計について説明しています。

表2-2 リスナーの統計

要素

説明

Elapsed

レポート対象の時間間隔

Packet size

受信したパケットのサイズ

Throughput

パケットの受信速度

Received

受信したパケット数

Missing

失われていることが検出されたパケットの数

Success rate

合計送信パケット数に対する受信パケット数の割合

Out of order

着信順序が乱れているパケットの数

Average offset

パケットの着信順序の乱れの程度を示すインジケータ

パブリッシャの場合と同様、現在と存続期間の両方の統計がレポートされます。次の例は、一般的なリスナーのレポートを示しています。

Lifetime:
Rx from publisher: /195.0.0.2:9999
elapsed: 8770ms
packet size: 1468
throughput: 96 MB/sec
68415 packets/sec
received: 600000 of 611400
missing: 11400
success rate: 0.9813543
out of order: 2
avg offset: 1

Now:
Rx from publisher: /195.0.0.2:9999
elapsed: 1431ms
packet size: 1468
throughput: 98 MB/sec
69881 packets/sec
received: 100000 of 100000
missing: 0
success rate: 1.0
out of order: 0
avg offset: 0

特に重要な項目は、throughputとsuccess rateです。目標は、success rateを可能なかぎり1.0近くに維持しながら、最高のthroughputを見つけることです。100Mbネットワークの設定では、約10MB/秒の速度を達成する必要があります。1Gbネットワークの設定では、約100MB/秒の速度を達成する必要があります。これらの速度を実現するには、なんらかの速度調整が必要になります。ネットワークがこれらの速度を達成できない場合、または速度がかなり低い場合、ネットワーク構成の問題がある可能性が非常に高いです。ネットワーク・パフォーマンスのチューニングの詳細は、「ネットワークのチューニング」を参照してください。

速度調整

-txRate Mパラメータを組み込むことによって、テストのパブリッシャ側で、MB/秒単位のデータ速度を指定して速度を調整できます。Mは、テストでネットワークに設定される最大MB/秒を表します。

メッセージ・バス・テスト・ユーティリティの実行

Coherenceメッセージ・バス・テスト・ユーティリティは、メッセージ・バスの実装のパフォーマンス特性とそれらが動作するネットワークのテストに使用します。このユーティリティにより、クラスタ・データ・サービス間の通信に対応するようネットワークが最適に構成されます。具体的には、このユーティリティを使用して、Exalogic以外のシステムに対するデフォルト・トランスポートであるTCPメッセージ・バス(TMB)の実装と、Exalogicシステムに対するデフォルト・トランスポートであるインフィニバンド・メッセージ・バス(IMB)の実装をテストできます。このテストの結果に基づいて環境をチューニングすることで、最大のパフォーマンスを実現します。詳細は、「TCPに関する考慮事項」を参照してください。

メッセージ・バス・テスト・ユーティリティを実行するには、コマンドラインからcom.oracle.common.net.exabus.util.MessageBusTestクラスを使用します。次の例は、MessageBusTestクラスの使用方法を示しています。

java -server -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest <command value> <command value> ...

表2-3では、メッセージ・バス・テスト・ユーティリティで使用できるコマンドライン・オプションについて説明しています。

表2-3 メッセージ・バス・テスト・ユーティリティのコマンドライン・オプション

コマンド

必須/オプション

説明

デフォルト

-bind

必須

作成する1つ以上のローカル・エンド・ポイントのリスト

なし

-peer

必須

送信先となる1つ以上のリモート・エンド・ポイントのリスト

なし

-rxThreads

オプション

バウンド・エンドポイント(リエントラント不可)ごとの受信スレッド数

-txThreads

オプション

バウンド・エンドポイントごとの送信スレッド数

-msgSize

オプション

送信するメッセージ・サイズの範囲で、min[..max]形式で指定します。

4096

-chunkSize

オプション

1単位として処理するバイト数を定義します。つまり、byteの場合は1、longの場合は8で、0 (ゼロ)を指定すると無効になります

-cached

オプション

可能であればメッセージ・オブジェクトを再利用して、バッファ・マネージャのオーバーヘッドを軽減します

-txRate

オプション

ターゲットのアウトバウンド・データ率(Mbps)

-txMaxBacklog

オプション

テストで送信スレッドごとに生成される最大バックログ。

-rxRate

オプション

ターゲットのインバウンド・データ率(Mbps)-rxThreadsが0 (ゼロ)以下の場合、使用できません。

-flushFreq

オプション

フラッシュ前に送信するメッセージ数、または自動の場合は0

0

-latencyFreq

オプション

待機時間のサンプリングまでに送信するメッセージ数

100

-noReceipts

オプション

指定した場合は受信を使用せず、GCにメッセージの再利用を任せます

false

-manager

オプション

使用するバッファ・マネージャ(net、directまたはheap)

net

-depotFactory

オプション

Depotインスタンスの取得に使用するファクトリ・クラスの完全修飾名

-reportInterval

オプション

レポートの間隔

5秒

-polite

オプション

指定した場合、このインスタンスは接続するまで送信を開始しません

-block

オプション

指定した場合、レスポンスの待機中、送信スレッドでブロックされます

false

-relay

オプション

指定した場合、受信されたメッセージはピアの1つにリレーされます

false

-ignoreFlowControl

オプション

指定した場合、フロー・コントロール・イベントは無視されます。フロー・コントロール・イベントを無視する場合は、-txMaxBacklogコマンドを使用してメモリー不足エラーを防ぎます

false

-poll

オプション

指定した場合、PollingEventCollectorの実装が使用され、イベントをすべてキューに入れて適合する場合のみ返します。通常、ポーリング・コレクタには、-rxThreadsコマンドを1に設定する必要があります。

-prompt

オプション

指定した場合、各送信前にユーザーにプロンプトが表示されます

-tabular

オプション

指定した場合、出力に表形式が使用されます

-warmup

オプション

ウォームアップのために廃棄される期間またはメッセージ数

0

-verbose

オプション

指定した場合、詳細デバッグ出力が可能になります

メッセージ・バス・パフォーマンスのテスト方法

この項では、TMBトランスポートに対するポイント・ツー・ポイント・メッセージ・バス・テストおよび分散メッセージ・バス・テストの実行手順を説明します。どちらのテストの実行にも成功する必要があり、その際に重大なパフォーマンスの問題やエラーが発生していないことも示す必要があります。

ポイント・ツー・ポイント・メッセージ・バス・テストの実行

この項の例では、サーバーA (IPアドレス195.0.0.1)と、サーバーB (IPアドレス195.0.0.2)という2つのサーバー間のネットワーク・パフォーマンスのテスト方法を示します。サーバーAはサーバーとして動作し、サーバーBはクライアントとして動作します。

まず、サーバーA上のリスナーを起動します。次に例を示します。

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000

[ENTER]を押すと、ユーティリティは、メッセージ受信の準備が完了していることを示します。例2-3 にサンプル出力を示します。

例2-3 サーバー・リスナーの起動からの出力

OPEN event for tmb://195.0.0.1:8000

サーバーBでクライアントを起動し、サーバーAにメッセージを送信させます。次に例を示します。

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000

サーバーBのテスト・インスタンスによってクライアントとサーバー・リスナーの両方が起動されます。メッセージ・バス・テストは、常に双方向通信を実行します。デフォルト・モードでは、クライアントはサーバーにメッセージを絶え間なく送信し、サーバーは定期的にクライアントに応答します。この構成では、通信の大部分がクライアントからサーバーへのものであるのに対し、サーバーからクライアントへの通信は頻度が低いので待機時間の測定を考慮に入れます。例2-4 は、Server Bのコマンド・ウィンドウに表示されるサンプル出力を示しています。

注意:

例2-4のパフォーマンス結果は、ご使用のネットワーク環境を示していない可能性もあります。

例2-4 メッセージ・バス・テスト — クライアントおよびサーバーの起動

OPEN event for tmb://195.0.0.2:8001
CONNECT event for tmb://195.0.0.1:8000 on tmb://195.0.0.2:8001
now:  throughput(out 65426msg/s 2.14gb/s, in 654msg/s 21.4mb/s),
latency(response(avg 810.71us, effective 1.40ms, min 37 .89us, max 19.59ms),
receipt 809.61us), backlog(out 42% 1556/s 48KB, in 0% 0/s 0B), connections 1,
errors 0
life: throughput(out 59431msg/s 1.94gb/s, in 594msg/s 19.4mb/s),
latency(response(avg 2.12ms, effective 3.85ms, min 36.32us, max 457.25ms),
receipt 2.12ms), backlog(out 45% 1497/s 449KB, in 0% 0/s 0B), connections 1,
errors 0

デフォルトのテストでは、最大帯域幅を使用して最大量のメッセージのプッシュを試行しますが、待機時間が長くなります。-blockコマンドを使用し、データのストリーミングをリクエストとレスポンスで切り替えてテストすると、ネットワークの最小待機時間の改善が示されます。

now:  throughput(out 17819msg/s 583mb/s, in 17820msg/s 583mb/s),
latency(response(avg 51.06us, effective 51.06us, min 43.42us, max 143.68us),
receipt 53.36us), backlog(out 0% 0/s 0B, in 0% 0/s 0B), connections 1, errors 0
life: throughput(out 16635msg/s 545mb/s, in 16635msg/s 545mb/s),
latency(response(avg 56.49us, effective 56.49us, min 43.03us, max 13.91ms),
receipt 59.43us), backlog(out 0% 0/s 2.18KB, in 0% 0/s 744B), connections 1,
errors 0

双方向メッセージ・バス・テストの実行

ポイント・ツー・ポイント・テストは、双方向モードで実行することもできます。このモードでは、サーバーがクライアントとサーバーの両方として動作します。ポイント・ツー・ポイント・テストで使用したのと同じテスト・インスタンスを使用します。たとえば、サーバーAで次のコマンドを実行します。

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000 -peer tmb://serverb:8000 -polite

-politeパラメータを使用して、このテスト・インスタンスに対し、データの受信を開始するまでパブリッシュを開始しないように指示します。サーバーBで次を実行します。

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000

分散メッセージ・バス・テストの実行

分散テストは、3台以上のコンピュータのパフォーマンスをテストするために使用します。このスタイルのテストは単純な1対1のテストと比較してはるかに現実的で、他の方法では確認できないネットワークのボトルネックを特定できる場合があります。

次の例では、4台のコンピュータ間で双方向メッセージ・バス・テストを実行します。

サーバーAの場合:

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://servera:8000 -peer tmb://serverb:8000 tmb://serverc:8000 tmb://serverd:8000 -polite

サーバーBの場合:

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverb:8000 -peer tmb://servera:8000 tmb://serverc:8000 tmb://serverd:8000 -polite

サーバーCの場合:

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverc:8000 -peer tmb://servera:8000 tmb://serverb:8000 tmb://serverd:8000 -polite

サーバーDの場合:

java -cp coherence.jar com.oracle.common.net.exabus.util.MessageBusTest -bind tmb://serverd:8000 -peer tmb://servera:8000 tmb://serverb:8000 tmb://serverc:8000 -polite

最後のノードが起動されるまで他のすべてのノードが遅延するため、最後のノードを除くすべてのノードは、-politeスイッチを使用して起動することが重要です。

メッセージ・バス・レポート統計の理解

メッセージ・バス・テストのそれぞれの側(クライアントとサーバー)から定期的にパフォーマンス統計がレポートされます。出力例は、リクエストを送信しているクライアントからのものです。

throughput(out 17819msg/s 583mb/s, in 17820msg/s 583mb/s),
latency(response(avg 51.06us, effective 51.06us, min 43.42us, max 143.68us),
receipt 53.36us), backlog(out 0% 0/s 0B, in 0% 0/s 0B), connections 1, errors 0

レポートには、前回のレポート以降の統計(now:)と集計した存続期間の統計(life:)の両方が出力されます。

表2-2では、メッセージ・バス統計について説明します。

表2-4 メッセージ・バスの統計

要素

説明

throughput

送受信される1秒当たりのメッセージ量と送信率

latency

メッセージの応答および受信にかかった時間

backlog

送信および処理を待機中のメッセージ数

connections

メッセージ・リスナー間のオープン接続数

errors

失われていることが検出されたメッセージの数。

特に重要な項目は、throughputとlatencyです。目標は、待機時間が長くにならず、可能なかぎり多くのネットワーク帯域幅を使用することです。帯域幅の使用量が少なく、待機時間が長い場合は、TCPの設定のチューニングを検討してください。バックログまたはエラー率が高い場合も、ネットワーク構成の問題を示している可能性があります。ネットワーク・パフォーマンスのチューニングの詳細は、「ネットワークのチューニング」を参照してください。

3 マルチキャスト接続テストの実行

この章では、Coherenceマルチキャスト・テスト・ユーティリティを使用して、ネットワーク環境がマルチキャスト通信をサポートしているかどうかを確認する手順について説明します。本番デプロイメントの前に、マルチキャスト・テストの実行が成功する必要があります。

この章の内容は次のとおりです。

- マルチキャスト・テスト・ユーティリティの実行

- マルチキャストのテスト方法

- マルチキャスト通信のトラブルシューティング

マルチキャスト・テスト・ユーティリティの実行

Coherenceマルチキャスト・テスト・ユーティリティは、2台以上のコンピュータ間でマルチキャストが有効にされているかどうかを判断するために使用します。このユーティリティは、負荷についてはテストしません。デフォルトでは、各インスタンスは2秒ごとに1つのマルチキャスト・パケットを送信します。ネットワークの負荷テストについては、「ネットワーク・パフォーマンス・テストの実行」を参照してください。

マルチキャスト・テスト・ユーティリティを実行するには、コマンド行からcom.tangosol.net.MulticastTestクラスを使用するか、COHERENCE_HOME/binディレクトリにあるmulticast-testスクリプトを実行します。スクリプトは、WindowsベースのプラットフォームとUNIXベースのプラットフォームの両方に用意されています。

次の例では、MulticastTestクラスを使用してユーティリティを実行します。

java com.tangosol.net.MulticastTest <command value> <command value> ...

次の例では、スクリプトを使用してユーティリティを実行します。

multicast-test <command value> <command value> ...

表3-1 では、マルチキャスト・テスト・ユーティリティで利用できるコマンド行オプションについて説明しています。

表3-1 マルチキャスト・テスト・ユーティリティのコマンド行オプション

コマンド

必須/オプション

説明

デフォルト

-local

オプション

送信を行うNICのアドレス、IPアドレスとして指定

localhost

-group

オプション

使用するマルチキャスト・アドレス、IP:ポートの形式で指定

237.0.0.1:9000

-ttl

オプション

マルチキャスト・パケットの有効時間

4

-delay

オプション

パケット送信間の遅延、秒単位で指定

2

-packetSize

オプション

送信するパケットのサイズ(デフォルトは、ローカルMTUに基づきます)

MTU

-display

オプション

予期しないパケットから表示されるバイト数

0

-translate

オプション

マルチキャスト・トラフィックのリッスンとパケットの変換

なし

マルチキャストのテスト方法

この項で示す例では、マルチキャスト・アドレス237.0.0.1、ポート9000(テストのデフォルト)で、サーバーA (IPアドレス195.0.0.1)とサーバーB (IPアドレス195.0.0.2)の2台のサーバー間でメッセージが送信できるかどうかをテストする方法について説明します。

注意:

テストで使用されるデフォルトのマルチキャスト・アドレスおよびポートは、Coherenceのデフォルトのアドレスおよびポートとは異なります。テストは、実際のCoherenceプロセスで使用されている同じアドレスおよびポートを使用して実行する必要があります。マルチキャスト用のデフォルトのアドレスおよびポートが成功するが、Coherenceのデフォルトが失敗する可能性があります。この原因としてよくあるのが、ローカル・ネットワーク・ポリシーの構成です。

最初にサーバーAで、このコンピュータまたはインタフェースを次のように単独でチェックして、195.0.0.1で使用可能なマルチキャスト・アドレス237.0.0.1、ポート9000があるかどうかを判定します。

コマンド・プロンプトで、次のコマンドを入力します。

multicast-test.sh -ttl 0

[Enter]を押すと、ユーティリティによって、順次マルチキャスト・パケットの送受信状況が表示されます。例3-1 にサンプル出力を示します。

例3-1 マルチキャスト・テスト・ユーティリティによって送信される順次マルチキャスト・パケット

Starting test on ip=servera/195.0.0.1, group=/237.0.0.1:9000,ttl=0
Configuring multicast socket...
Starting listener...
Tue Mar 17 15:59:51 EST 2008: Sent packet 1.
Tue Mar 17 15:59:51 EST 2008: Received test packet 1 from self.
Tue Mar 17 15:59:53 EST 2008: Sent packet 2.
Tue Mar 17 15:59:53 EST 2008: Received test packet 2 from self.
...

約5分間テストを実行し、障害がないことを確認します。テストを停止するには、[Ctrl]を押しながら[C]を押します。

前述のように表示されない場合は、マルチキャストが機能していません。また、TTLに0を指定することで、マルチキャスト・パケットがサーバーAから送信されないようにしていることに注目してください。

同じテストをサーバーBでも実行して、このポートの組合せでもマルチキャストが有効になっていることを確認できます。

次に、サーバーAとサーバーBの間のマルチキャスト通信をテストします。このテストでは、TTLにゼロ以外の値を使用して、それぞれのサーバーからパケットを送信できるようにします。デフォルトのテストではTTLに4が使用されますが、サーバーAとサーバーBの間のパケットのルーティングにさらに多くのネットワーク・ホップが必要な場合は、4より大きな値をTTLに指定します。

次のコマンドをそれぞれのサーバーのコマンド・ウィンドウに入力して[Enter]を押し、サーバーAとサーバーBのテストを開始します。

multicast-test.sh

次の例は、サーバーAのサンプル出力を示しています。

Starting test on ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4
Configuring multicast socket...
Starting listener...
Tue Mar 17 16:11:03 EST 2008: Sent packet 1.
Tue Mar 17 16:11:03 EST 2008: Received test packet 1 from self.
Tue Mar 17 16:11:05 EST 2008: Sent packet 2.
Tue Mar 17 16:11:05 EST 2008: Received test packet 2 from self.
Tue Mar 17 16:11:07 EST 2008: Sent packet 3.
Tue Mar 17 16:11:07 EST 2008: Received test packet 3 from self.
Tue Mar 17 16:11:09 EST 2008: Sent packet 4.
Tue Mar 17 16:11:09 EST 2008: Received test packet 4 from self.
Tue Mar 17 16:11:10 EST 2008: Received test packet 1 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:11 EST 2008: Sent packet 5.
Tue Mar 17 16:11:11 EST 2008: Received test packet 5 from self.
Tue Mar 17 16:11:12 EST 2008: Received test packet 2 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:13 EST 2008: Sent packet 6.
Tue Mar 17 16:11:13 EST 2008: Received test packet 6 from self.
Tue Mar 17 16:11:14 EST 2008: Received test packet 3 from ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:15 EST 2008: Sent packet 7.
Tue Mar 17 16:11:15 EST 2008: Received test packet 7 from self.
...

次の例は、サーバーBのサンプル出力を示しています。

Starting test on ip=serverb/195.0.0.2, group=/237.0.0.1:9000, ttl=4
Configuring multicast socket...
Starting listener...
Tue Mar 17 16:11:10 EST 2008: Sent packet 1.
Tue Mar 17 16:11:10 EST 2008: Received test packet 1 from self.
Tue Mar 17 16:11:11 EST 2008: Received test packet 5 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:12 EST 2008: Sent packet 2.
Tue Mar 17 16:11:12 EST 2008: Received test packet 2 from self.
Tue Mar 17 16:11:13 EST 2008: Received test packet 6 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
Tue Mar 17 16:11:14 EST 2008: Sent packet 3.
Tue Mar 17 16:11:14 EST 2008: Received test packet 3 from self.
Tue Mar 17 16:11:15 EST 2008: Received test packet 7 from ip=servera/195.0.0.1, group=/237.0.0.1:9000, ttl=4.
...

サーバーAとサーバーBの例では、マルチキャスト・パケットを発行して、自身のパケットと相手方のパケット確認しています。これは、マルチキャストのデフォルトのアドレスおよびポートを使用して、これらのサーバー間でマルチキャストが正しく機能していることを示します。

注意:

サーバーAは、サーバーBからのパケット1を受信するまでは自身のパケット(1-4)を観測します。

マルチキャスト通信のトラブルシューティング

双方向マルチキャスト通信が確立できない場合は、次のトラブルシューティングのヒントを使用してください。マルチキャストが正しく機能しない場合は、ネットワーク管理者またはシステム管理者に連絡して、原因の調査と状況への対処を依頼してください。

- ファイアウォール: マルチキャスト・テストを実行するコンピュータのいずれかでファイアウォールが採用されている場合は、ファイアウォールがトラフィックをブロックしている可能性があります。マルチキャスト・トラフィックを許可する方法の詳細は、オペレーティング・システムまたはファイアウォールのドキュメントを参照してください。

- スイッチ: マルチキャスト・トラフィックを転送するようにスイッチが構成されていることを確認します。

- 最初の成功後にマルチキャスト・テストが失敗する場合は、Coherenceノートで次を実行してみてください。

tcpdump -i nic_device igmp

nic_deviceは、NICデバイス名です。IGMP問合せメッセージ(v2またはv3のいずれか)がtcpdump出力に表示されていることを確認します。IGMP問合せメッセージを送受信できるようにスイッチが有効になっていることを確認します。また、定期的なIGMP問合せメッセージに応答するようにNICおよびOSネットワーキングが設定されていることを確認します。最後に、スイッチをチェックして、Coherenceサーバーで"IGMP結合"と"IGMP問合せメッセージ"の両方の確認応答が実行されることを確認します。次のように出力されます。

07:58:33.452537 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP
(2), length 40, options (RA))

longcoh06a1-priv.emea.kuoni.int > igmp.mcast.net: igmp v3 report, 1 group
record(s) [gaddr 192.168.0.5 to_ex, 0 source(s)]

07:58:43.294453 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP
(2), length 40, options (RA))

longcoh06a1-priv.emea.kuoni.int > igmp.mcast.net: igmp v3 report, 1 group
record(s) [gaddr 192.168.0.5 to_ex, 0 source(s)]

07:58:51.782848 IP (tos 0xc0, ttl 1, id 3133, offset 0, flags [none], proto
IGMP (2), length 36, options (RA))

10.241.113.40 > all-systems.mcast.net: igmp query v3 [max resp time 10s]

08:00:56.803800 IP (tos 0xc0, ttl 1, id 3134, offset 0, flags [none], proto
IGMP (2), length 36, options (RA))

10.241.113.40 > all-systems.mcast.net: igmp query v3 [max resp time 10s]
…

最初の2行は、マルチキャスト・グループに"参加する"サーバーです。残りの出力は、スイッチを起点とするIGMP問合せメッセージで、数分ごとに継続されます(それらを送信するようにスイッチが構成され、応答するようにNICが構成されている場合)。

- IPv6: IPv6をサポートするオペレーティング・システムでは、JavaがIPv4ではなくIPv6を介したマルチキャスト・トラフィックのルーティングを試行することがあります。Javaシステム・プロパティjava.net.preferIPv4Stack=trueを指定して、IPv4ネットワーキングを実施してみてください。Coherenceクラスタ・メンバーはすべてIPv4またはIPv6のいずれかを使用する必要があり、両方を混在して使用することはできません。

- ???の受信: テストで???の受信がレポートされた場合は、マルチキャスト・テスト以外のインスタンスから発信されたマルチキャスト・パケットを受信したことを示します。この状況は、テストを実行するときに、既存のCoherenceクラスタまたはその他のマルチキャスト・アプリケーションと同じマルチキャスト・アドレスを使用した場合に発生します。

- 複数のNIC: コンピュータに複数のネットワーク・インタフェースが存在する場合は、-local testパラメータを使用して、明示的にインタフェースを指定してください。たとえば、サーバーAにIPアドレスが195.0.0.1と195.0.100.1の2つのインタフェースがある場合、テストのコマンド行に-local 195.0.0.1を含めると、マルチキャスト・パケットが最初のインタフェースを使用するようになります。さらに、マルチキャスト・トラフィックが目的のネットワーク・インタフェースを通じて転送されるように、コンピュータのルーティング表を明示的に構成することも必要になる場合があります。これは、次のコマンドを発行することで実行できます。

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1

eth1は、マルチキャスト・トラフィックの送信先になるデバイスです。

- AIX: AIXシステムでは、マルチキャストに関して次の問題が発生する場合があります。

- IPv6: java.net.preferIPv4Stack=trueを指定することに加え、IPv4の名前解決を実行するためにオペレーティング・システムに追加の構成が必要になることがあります。/etc/netsvc.confファイルに、hosts=local,bind4を追加してください。

- 仮想IP (VIPA): AIXでは、VIPAを使用したマルチキャストがサポートされていません。VIPAを使用する場合は、VIPAでないデバイスにマルチキャストをバインドするか、またはマルチキャストを無効にしてCoherenceを実行します。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- MTU: マルチキャスト・デバイスのMTUを1500バイトに構成します。

- Cisco社製スイッチ: 既知の問題のリストについては、「Cisco社製スイッチへのデプロイ」を参照してください。

- Foundry社製スイッチ: 既知の問題のリストについては、「Foundry社製スイッチへのデプロイ」を参照してください。

4 パフォーマンス・チューニング

この章では、Coherenceソリューションをデプロイするときに、最大のパフォーマンスを発揮するように環境をチューニングする手順について説明します。も参照してください。

この章の内容は次のとおりです。

- オペレーティング・システムのチューニング

- ネットワークのチューニング

- JVMのチューニング

- Coherence通信のチューニング

- データ・アクセス・パターン

オペレーティング・システムのチューニング

この項の内容は、次のとおりです。

- ソケット・バッファ・サイズ

- 高分解能タイムソース(Linux)

- データグラム・サイズ(Microsoft Windows)

- スレッド・スケジューリング(Microsoft Windows)

- スワッピング

- ロード・バランシング・ネットワーク割込み(Linux)

ソケット・バッファ・サイズ

オペレーティング・システムのソケット・バッファを大きくすると、ガベージ・コレクション中のパケット・ロスを最小限にするのに役立ちます。各Coherenceソケットの実装では、デフォルトのソケット・バッファ・サイズの割当てを試行します。デフォルト・サイズの割当てができない場合は警告メッセージが各ソケットの実装に記録されます。次の例は、インバウンドUDPソケット・バッファのメッセージを示しています。

UnicastUdpSocket failed to set receive buffer size to 16 packets (1023KB); actual
size is 12%, 2 packets (127KB). Consult your OS documentation regarding increasing
the maximum socket buffer size. Proceeding with the actual value may cause
sub-optimal performance.

より大きいサイズのバッファを許可するようにオペレーティング・システムを構成することをお薦めします。ただし、<packet-buffer要素を使用して、Coherenceパケット・パブリッシャとユニキャスト・リスナーに別のバッファ・サイズを構成できます。パケット・バッファの設定の構成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

注意:

UNIXのほとんどのバージョンではデフォルトのバッファ制限が非常に小さく設定されていますが、これを少なくとも2MBに増大する必要があります。

Linuxの場合(rootとして実行):

sysctl -w net.core.rmem_max=2097152
sysctl -w net.core.wmem_max=2097152

Solarisの場合(rootとして実行):

ndd -set /dev/udp udp_max_buf 2097152

AIXの場合(rootとして実行):

no -o rfc1323=1
no -o sb_max=4194304

注意:

AIXでは、1MB、4MBおよび8MBのバッファ・サイズの指定のみサポートされます。

Windowsの場合:

Windowsにはデフォルトのバッファ・サイズ制限はありません。

その他:

その他のオペレーティング・システムにおけるバッファ・サイズの拡大については、該当するオペレーティング・システムのドキュメントを参照してください。

高分解能タイムソース(Linux)

Linuxには選択可能な高分解能タイムソースがいくつか用意されていますが、残念なことに、最速のタイムスタンプ・カウンタ(TSC)でも常に信頼性があるとはかぎりません。LinuxではTSCがデフォルトで選択され、起動時のチェックで非一貫性が検出されると、より低速で安全なタイムソースへの切替えが行われます。低速なタイムソースでは、問合せの実行にTSCタイムソースの10 - 30倍のコストがかかることがあり、Coherenceのパフォーマンスに多大な影響を与える可能性があります。TSCの詳細は、次を参照してください。

https://lwn.net/Articles/209101/

Coherenceおよび基礎となるJVMでは、オペレーティング・システムで使用しているタイムソースを認識しないことに注意してください。システム・ログ(/var/log/dmesg)をチェックして、次のメッセージが記載されていないかどうか確認することをお薦めします。

kernel: Losing too many ticks!
kernel: TSC cannot be used as a timesource.
kernel: Possible reasons for this are:
kernel:   You're running with Speedstep,
kernel:   You don't have DMA enabled for your hard disk (see hdparm),
kernel:   Incorrect TSC synchronization on an SMP system (see dmesg).
kernel: Falling back to a sane timesource now.

ログ・メッセージによると、これが、CPU使用率の変動(SpeedStep)、DMAの無効化、またはマルチCPUコンピュータに対する誤ったTSCの同期化などに起因して発生していることを示しています。前述のメッセージが存在する場合は、システム管理者に問い合せてその原因に対処し、TSCタイムソースを使用可能にしてください。

データグラム・サイズ(Microsoft Windows)

Microsoft Windowsでは、小さなデータグラムの送信時に使用される高速I/Oパスがサポートされます。デフォルト設定で小さいと見なされるデータグラムは、1024バイトです。この値をネットワークの最大転送単位(MTU)に合せて増加すると(通常は1500)、ネットワーク・パフォーマンスが著しく向上する可能性があります。

このパラメータを調整する手順は次のとおりです。

1. レジストリ エディタを実行します(regedit)。

2. レジストリ・キーHKLM\System\CurrentControlSet\Services\AFD\Parametersを見つけます。

3. 新しいDWORD値(Name: FastSendDatagramThreshold、Value: 1500 (10進数))を追加します。

4. 再起動します。

注意:

COHERENCE_HOME/bin/optimize.regスクリプトは、この変更を実行します。スクリプトを実行したら、コンピュータを再起動して変更を有効にします。

このパラメータの詳細は、http://technet.microsoft.com/en-us/library/bb726981.aspxの「Appendix C」を参照してください。

スレッド・スケジューリング(Microsoft Windows)

Windowsは、テスクトップ・アプリケーション用に最適化されています。2つのコンソール(DOSボックス)ウィンドウを開くと、その他のプロセスに優先度の高い実行中のスレッドがあっても、フォーカスのある1つのコンソールがCPUのほぼ100%を使用してしまうことがあります。このアンバランスを修正するには、フォアグラウンド・アプリケーションが軽量で動作するようにWindowsのスレッド・スケジューリングを構成する必要があります。

1. 「コントロール パネル」を開きます。

2. 「システム」を開きます。

3. 「詳細」タブを選択します。

4. 「パフォーマンス」の「設定」を選択します。

5. 「詳細」タブを選択します。

6. 「プロセッサのスケジュール」で「バックグラウンド サービス」を選択します。

注意:

COHERENCE_HOME/bin/optimize.regスクリプトは、この変更を実行します。スクリプトを実行したら、コンピュータを再起動して変更を有効にします。

スワッピング

スワッピング(ページングと呼ぶこともあります)とは、RAMメモリーで使用するアプリケーション・データを格納および取得するために、2次記憶域を使用することです。スワッピングは、オペレーティング・システムによって自動的に実行されます。通常、使用可能なRAMメモリーが使い果たされたときに発生します。スワッピングは、Coherenceのパフォーマンスに大きな影響を与える可能性があるため、その発生を回避する必要があります。通常、スワッピング自体がCoherenceノードのクラスタからの削除を表します。これは、そのノードがRAMからスワップされることで、長時間の無応答状態が発生するためです。詳細は、「仮想メモリーの使用(ディスクへのページング)の回避」を参照してください。

スワッピングを回避するには、コンピュータに十分な使用可能RAMメモリーを搭載するか、実行プロセスの数を把握して使用可能なすべてのRAMを使い果たさないようにします。vmstatやtop (UnixとLinux)、taskmgr (Windows)などのツールを使用して、スワップ・レートをモニターしてください。

Linuxのswappiness

Linuxでは、RAMに余裕があるときにも、プロセスやヒープの一部をスワップ・アウトするようにデフォルトで設定できます。swappinessは、最終的なメモリー・リクエストを処理するために実行されます。Coherence JVMに対するswappinessは避ける必要があります。Linuxではswappinessの設定値を0から100までの値に設定できます。値が大きいほど、楽観的なスワッピングが行われます。デフォルト値は60です。Coherenceについては、常に低い値(可能ならば0)を設定する必要があります。

現在設定されているswappiness値を確認するには、コマンド・プロンプトで次のコマンドを入力します。

cat /proc/sys/vm/swappiness

一時的にswappinessを設定するには、rootユーザーとして/proc/sys/vm/swappinessに値をエコーします。次の例では、値に0を設定しています。

echo 0 > /proc/sys/vm/swappiness

値を永続的に設定するには、/etc/sysctl.confファイルを次のように変更します。

vm.swappiness = 0

ロード・バランシング・ネットワーク割込み(Linux)

Linuxのカーネルでは、ハードウェア割込み要求を複数のCPUまたはCPUコア全体にバランシングする機能があります。この機能は、SMP IRQアフィニティと呼ばれ、システム・パフォーマンスとCPU使用率を向上します。Coherenceの場合、クラスタ・メンバーをホストするすべてのサーバーにイーサネット・カードの割込みをバランシングすることで、大幅なパフォーマンスの向上が得られる可能性があります。ほとんどのLinuxディストリビューションでは、irqbalanceもサポートされています。これは、最新のマルチコアおよびマルチソケット・システムのキャッシュ・トポロジと電源管理機能を認識します。

ほとんどのLinuxインストールでは、ネットワーク割込みのバランシングが構成されません。デフォルトのネットワーク割込みの動作では、すべてのネットワーク割込みの処理に1つのプロセッサ(通常はCPU0)を使用するため、大量のネットワーク・トラフィックがあると重大なパフォーマンス・ボトルネックになる可能性があります。ネットワーク割込みを複数のCPU間にバランシングすることで、ネットワークベースの操作のパフォーマンスが向上します。

SMP IRQアフィニティの構成方法の詳細は、要点のみが示された次のドキュメントを参照してください。

http://www.mjmwired.net/kernel/Documentation/IRQ-affinity.txt

システムのIRQの一覧を表示するには次のコマンドを実行します。この一覧には、IRQに割り当てられたデバイスと、そのデバイスに対して各プロセッサが処理した割込みの数が含まれます。

# cat /proc/interrupts

次の例は、1つのネットワーク・インタフェースを示す出力の一部です。この出力では、すべての割込みが同一のプロセッサ(CPU0)で処理されています。このネットワーク・カードには、複数の伝送および受信キューがあり、それらに独自のIRQが割り当てられています。複数のネットワーク・カードを使用するシステムは、追加のIRQを各カードに割り当てます。

CPU0       CPU1       CPU2       CPU3
65:      20041      0          0          0      IR-PCI-MSI-edge  eth0-tx-0
66:      20232      0          0          0      IR-PCI-MSI-edge  eth0-tx-1
67:      20105      0          0          0      IR-PCI-MSI-edge  eth0-tx-2
68:      20423      0          0          0      IR-PCI-MSI-edge  eth0-tx-3
69:      21036      0          0          0      IR-PCI-MSI-edge  eth0-rx-0
70:      20201      0          0          0      IR-PCI-MSI-edge  eth0-rx-1
71:      20587      0          0          0      IR-PCI-MSI-edge  eth0-rx-2
72:      20853      0          0          0      IR-PCI-MSI-edge  eth0-rx-3

目的は、1つのプロセッサではなく、4つのプロセッサ全体に割込みをバランシングすることです。理想としては、システムに装備されたプロセッサの全体的な使用率も評価して、どのプロセッサが割込みを処理できるかを判断します。mpstatを使用すると、システムのプロセッサの統計を表示できます。この統計には、過剰に使用されているプロセッサと十分に使用されていないプロセッサが表示されるため、すべてのCPUにネットワーク割込みをバランシングする最適な方法を判断する際に役立ちます。

SMP IRQアフィニティは、smp_affinityファイルで構成します。各IRQには専用のsmp_affinityファイルがあります。このファイルは、/proc/irq/irq_#/ディレクトリにあります。現在のIRQ(たとえば 65)のアフィニティ設定を確認するには、次のコマンドを実行します。

# cat /proc/irq/65/smp_affinity

戻される16進数値はビットマスクであり、IRQ 65の割込みがルーティングされるプロセッサを表します。値の各桁は、4個のCPUからなるグループを表します。4個のプロセッサのシステムの場合、4個のすべてのプロセッサのグループを表す16進数値は、f(つまり15)になり、次のようにマップされるときには00000fになります。

Binary       Hex
CPU 0    0001         1
CPU 1    0010         2
CPU 2    0100         4
CPU 3    1000         8
-----------------------
all      1111         f

1個のプロセッサまたはプロセッサのグループを対象にするには、ビットマスクを適切な16進数値に変更する必要があります。前述の例で示したシステムについて説明すると、IRQ 65のすべての割込みをCPU1にルーティングして、IRQ 66のすべての割込みをCPU2にルーティングするには、smp_affinityファイルを次のように変更します。

echo 000002 > /proc/irq/65/smp_affinity # eth0-tx-0
echo 000004 > /proc/irq/66/smp_affinity # eth0-tx-1

IRQ 65のすべての割込みをCPU1とCPU2の両方に振り分ける場合は、smp_affinityファイルを次のように変更します。

echo 000006 > /proc/irq/65/smp_affinity # eth0-tx-0

各IRQのすべての割込みを、すべてのCPUに振り分ける場合は、smp_affinityファイルを次のように変更します。

echo 00000f > /proc/irq/65/smp_affinity # eth0-tx-0
echo 00000f > /proc/irq/66/smp_affinity # eth0-tx-1
echo 00000f > /proc/irq/67/smp_affinity # eth0-tx-2
echo 00000f > /proc/irq/68/smp_affinity # eth0-tx-3
echo 00000f > /proc/irq/69/smp_affinity # eth0-rx-0
echo 00000f > /proc/irq/70/smp_affinity # eth0-rx-1
echo 00000f > /proc/irq/71/smp_affinity # eth0-rx-2
echo 00000f > /proc/irq/72/smp_affinity # eth0-rx-3

ネットワークのチューニング

- ネットワーク・インタフェースの設定

- ネットワーク・インフラストラクチャの設定

- スイッチとサブネットに関する考慮事項

- イーサネットのフロー制御

- パスMTU

- 10GbEに関する考慮事項

- TCPに関する考慮事項

ネットワーク・インタフェースの設定

ネットワーク・カード(NIC)が最大リンク速度および全二重で動作するよう構成されていることを確認します。この確認処理はオペレーティング・システムにより異なります。

Linuxの場合(rootとして実行):

ethtool eth0

インタフェース設定の調整方法および詳細は、ethtoolのmanページを参照してください。

Solarisの場合(rootとして実行):

kstat ce:0 | grep link_

これにより、インタフェース0のリンク設定が表示されます。重要な項目はlink_duplex (全二重は2)とlink_speed (Mbps単位)です。

注意:

Solaris 10上で実行する場合は、パケットの破損およびマルチキャスト接続の切断に関する問題(1000972.1および1000940.1)を確認してください。これらは多くの場合、EOFExceptions、パケット・データ読取り時の大きなギャップの警告または頻繁なパケット・タイムアウトとして顕在化します。Solaris 10システム上でCoherenceを使用する場合は、これら両方の問題に対するパッチの適用を強くお薦めします。

Windowsの場合:

1. 「コントロール パネル」を開きます。

2. 「ネットワーク接続」を開きます。

3. 目的のネットワーク・アダプタの「プロパティ」ダイアログを開きます。

4. 「構成」を選択します。

5. 「詳細設定」タブを選択します。

6. 「リンク速度とデュプレックス」でドライバ固有のプロパティを見つけます。

7. このプロパティを「自動検出」または特定のリンク速度とデュプレックスに設定します。

ネットワーク・インフラストラクチャの設定

複数のクラスタ・ノード間で数秒間にわたる通信の停止が頻繁に発生する場合は、スイッチのバッファ領域を拡大してみてください。このような通信の停止は、ローカルまたはリモートのGCに起因しない、複数ノードでの通信の遅延を特定する一連のCoherenceログ・メッセージにより特定できます。

例4-1 通信の遅延を示すメッセージ

Experienced a 4172 ms communication delay (probable remote GC) with Member(Id=7, Timestamp=2006-10-20 12:15:47.511, Address=192.168.0.10:8089, MachineId=13838); 320 packets rescheduled, PauseRate=0.31, Threshold=512

Cisco 6500シリーズなどの一部のスイッチでは、各イーサネット・ポートまたはASICで使用可能なバッファ領域の容量を構成できます。負荷の高いアプリケーションでは、デフォルトのバッファ領域の増大が必要になる場合があります。Ciscoでこれを実現するには、次を実行します。

fabric buffer-reserve high

この設定の詳細は、Ciscoのドキュメントを参照してください。

スイッチとサブネットに関する考慮事項

クラスタ・メンバーは複数のスイッチにわたって分割されていることがあり、複数のサブネットに含まれている可能性があります。ただし、そのようなトポロジによってスイッチ間リンクに過剰な負荷がかかるため、リンクでの障害発生時にクラスタが分割される可能性が高くなります。一般的に、その影響はクラスタとアプリケーションのパフォーマンスの低下をもたらす、通信遅延という形で顕在化します。影響を最小化するために、可能な場合は、すべてのクラスタ・メンバーを同一のスイッチとサブネットに配置することを常に検討してください。

関連項目: 「UDPおよびTCPの本番ネットワークの速度の評価」

イーサネットのフロー制御

全二重イーサネットにはフロー制御機能があります。これにより、固定リンクの受信側に合せて送信側の速度を低下させることができます。これは、受信側からイーサネットPAUSEフレームを送信側に送信することで実行します。PAUSEフレームで指定された期間、送信側は送信を停止します。この停止により、負荷の高くないコンピュータに送信するトラフィックも含め、送信側のすべてのトラフィックがブロックされます。これには行頭ブロック条件が含まれる場合があります。その場合、スイッチ上に過負荷のコンピュータが1つあると、その他すべてのコンピュータ速度が実質的に低下します。ほとんどのスイッチ・ベンダーは、スイッチ・リンク間のイーサネットのフロー制御を無効にして、多くてもコンピュータに直接接続されているポートでのみ使用することをお薦めします。この設定でも行頭ブロックは発生する可能性があるため、イーサネットのフロー制御は無効にすることをお薦めします。TCP/IPやCoherence TCMPなどのより高いレベルのプロトコルには、行頭ブロックの影響を受けず、低レベルのフロー制御も必要としない独自のフロー制御メカニズムがあります。

この問題の詳細は、http://www.networkworld.com/netresources/0913flow2.htmlを参照してください。

パスMTU

Coherenceはデフォルトで1500バイトのネットワークMTUを想定し、その想定に基づいて、1468バイトのデフォルトのパケット・サイズを使用しています。パケット・サイズがMTUを満たさないと、ネットワークは有効に活用されません。機器が使用するMTUが異なる場合は、ネットワーク・パスの最小MTUよりも32バイト小さい値を<packet-size設定に指定してCoherenceを構成します。

ノード間の完全なパスを経由する機器のMTUが不明な場合は、そのMTUを特定するために、標準のpingやtracerouteユーティリティを使用できます。たとえば、2つのコンピュータ間で一連のpingまたはtraceroute操作を実行します。それぞれの試行において、最初は大きいパケット・サイズを指定し、断片化されずにパケットが処理されるようになるまで徐々に値を下げていきます。

Linuxの場合:

ping -c 3 -M do -s 1468 serverb

Solarisの場合:

traceroute -F serverb 1468

Windowsの場合:

ping -n 3 -f -l 1468 serverb

その他のオペレーティング・システムについては、ドキュメントでpingまたはtracerouteコマンドについて調べて、断片化の回避方法を考慮した上でパケット・サイズを指定してください。

パケットを断片化する必要があるというメッセージが出力される場合、指定したサイズはパスのMTUより大きいことになります。断片化せずにパケットを送信できるサイズがわかるまでパケット・サイズを小さくしていきます。1468より小さいパケットを使用する必要がある場合は、MTUを少なくとも1500まで拡大するようネットワーク管理者に問い合せてください。

10GbEに関する考慮事項

多くの10ギガビット・イーサネット(10GbE)スイッチとネットワーク・インタフェース・カードは、1500バイトのイーサネット・フレーム標準よりも大きなフレーム・サイズをサポートしています。10GbEを使用するときには、そのテクノロジで許容されている最大値(イーサネットの場合は約16KB)にMTUを設定して、広い帯域幅がフル活用されていることを確認します。Coherenceは、ネットワークのMTUを自動的に検出して、それに応じてUDPソケット・バッファ・サイズを選択します。MTUサイズが1500バイト(標準)の場合は2MB、9000バイト(ジャンボ)の場合は4MB、9000バイト超(スーパー・ジャンボ)の場合は8MBが、UDPソケット・バッファ・サイズに選択されます。また、オペレーティング・システムのソケット・バッファも、大きいサイズに対応するように8MBに拡大していることも確認します。オペレーティング・システムの検出されたバッファが小さすぎるときには、Coherenceログに警告が記録されます。最後に、ネットワークのパフォーマンスとスループットを検証するために、データグラム・テストを必ず実行してください。このテストの実行手順の詳細は、「ネットワーク・パフォーマンス・テストの実行」を参照してください。

TCPに関する考慮事項

Coherenceでは、TCPメッセージ・バス(TMB)を利用して、クラスタ・データ・サービス間でメッセージを送信します。したがって、TCP用にネットワークを最適にチューニングする必要があります。Coherenceでは、バッファ設定などのTCP設定をオペレーティング・システムから継承します。ほとんどのサーバーでは、ネットワーク用にTCPがすでにチューニングされており、追加構成する必要はありません。ネットワーク用にCoherenceをチューニングするのではなく、ネットワーク用にTCPスタックをチューニングすることをお薦めします。

Coherenceには、ネットワーク・ノード間でのスループットおよび待機時間のテストに使用できるメッセージ・バス・テスト・ユーティリティが組み込まれています。このユーティリティの使用方法の詳細は、「メッセージ・バス・テスト・ユーティリティの実行」を参照してください。ネットワークが低いパフォーマンスを示す場合、適切に構成されていない可能性があるので、次の推奨設定を使用してください(これらの設定は、Linuxでデモを行ったものですが、他のオペレーティング・システムにも転換できます)。

#!/bin/bash
#
# aggregate size limitations for all connections, measured in pages; these values
# are for 4KB pages (getconf PAGESIZE)

/sbin/sysctl -w net.ipv4.tcp_mem='   65536   131072   262144'

# limit on receive space bytes per-connection; overridable by SO_RCVBUF; still
# goverened by core.rmem_max

/sbin/sysctl -w net.ipv4.tcp_rmem=' 262144  4194304  8388608'

# limit on send space bytes per-connection; overridable by SO_SNDBUF; still
# goverered by core.wmem_max

/sbin/sysctl -w net.ipv4.tcp_wmem='  65536  1048576  2097152'

# absolute limit on socket receive space bytes per-connection; cannot be
# overriden programatically

/sbin/sysctl -w net.core.rmem_max=16777216

# absolute limit on socket send space bytes per-connection; cannot be overriden;
# cannot be overriden programatically

/sbin/sysctl -w net.core.wmem_max=16777216

各接続では最低320KBを使用しますが、通常のメモリー不足では接続ごとに5MBを使用し、最終的にオペレーティング・システムはTCP用のシステム・バッファリング全体を1GB以下に維持しようとします。これらは、高速(10GbE以上)ネットワーク用のチューニングに基づいた推奨デフォルト値ですが、1GbEでも容認されます。

JVMのチューニング

- サイズ設定に関する基本的な推奨事項

- ヒープ・サイズに関する考慮事項

- ガベージ・コレクションの監視

サイズ設定に関する基本的な推奨事項

この項で示す推奨事項は、一般的な使用の場合には十分で、必要な設定作業は最小限です。JVMのサイズ設定時に考慮すべき第一の問題は、使用可能なRAMとガベージ・コレクション(GC)一時停止時間とのバランスです。

キャッシュ・サーバー

Coherenceキャッシュ・サーバーについての標準的で安全な推奨事項として、固定のヒープ・サイズを4GB以下にして実行することをお薦めします。さらに、増分ガベージ・コレクタを使用して、GC一時停止時間を最小限に抑えます。最後に、JVMコマンド行で-serverを指定して、すべてのCoherence JVMをサーバー・モードで実行することをお薦めします。これにより、長期間稼働するアプリケーションにいくつかの点で最適なパフォーマンスが得られます。

例:

java -server -Xms1g -Xmx1g -Xincgc -Xloggc: -cp coherence.jar com.tangosol.net.DefaultCacheServer

このサイズ設定では、より詳細なJVMチューニングの必要がなく、適切なパフォーマンスが得られます。ガベージ・コレクションの詳細は、「ガベージ・コレクションの監視」を参照してください。

最大20GBのヒープまでヒープ・サイズを大きくすることが可能であるため、本番環境では大きなヒープ・サイズが実装されていますが、それによりGC一時停止を最小限に抑えるためのJVMのモニターとチューニングがさらに重要になります。スクラッチ領域の容量を増やしてGCの圧縮がより迅速になるように、記憶域の比率の変更が必要になる場合もあります。また、大きなサイズのヒープの管理を最新の状態に向上させるために最新バージョンのJVMを利用することをお薦めします。詳細は、「ヒープ・サイズに関する考慮事項」を参照してください。

TCMPクライアント

長時間稼働するGCが原因で、Coherence TCMPクライアントが停止しているとの誤認識が生じる可能性があるため、Coherence TCMPクライアントも同様にサーバーをキャッシュするように構成する必要があります。

Extendクライアント

専門的に言えば、Coherence Extendクライアントはクラスタ・メンバーではなく、このため、長時間稼働するGCからの影響が小さいです。Extendクライアントの場合、Coherenceの埋込み先のアプリケーションで説明されているとおりに既存のガイドラインに従うことをお薦めします。

ヒープ・サイズに関する考慮事項

この項では、次の事項を決定します。

- システムに必要なCPUの数

- 各システムに必要なメモリーの量

- システムごとに実行するJVMの数

- JVMごとに構成するヒープのサイズ

すべてのアプリケーションがそれぞれ異なるため、この項をガイドラインとしてよく読む必要があります。適切な構成を選択するには次の質問に対する答えが必要になります。

- Coherenceキャッシュに格納することになるデータの量はどのくらいか。

- 待機時間とスループットに関するアプリケーション要件は何か。

- アプリケーションはどれくらいCPUまたはネットワーク集中型か。

サイズ設定は、不正確な技法です。パフォーマンスおよび負荷の頻繁なテストに代わるものはありません。

この項の内容は、次のとおりです。

- 一般的なガイドライン

- アプリケーション・ヒープからのキャッシュの移動

一般的なガイドライン

固定サイズのヒープを使用して実行すると、必要に応じてJVMでヒープを増大する必要がなくなり、パフォーマンスが向上します。固定のヒープ・サイズを指定するには、JVMオプションの-Xmsと-Xmxを同じ値に設定します。次に例を示します。

java -server -Xms4G -Xmx4G ...

1つのJVMプロセスでは、指定されているヒープ・サイズより多くのシステム・メモリーが消費されます。ヒープ・サイズ設定によって、JVMでアプリケーションに使用できるヒープの量が指定されますが、JVM自体もさらにメモリーを消費します。消費される量は、オペレーティング・システムおよびJVM設定によって異なります。たとえば、Linuxで実行し1GBのJVMで構成されたHotSpot JVMでは、約1.2GBのRAMが消費されます。JVMのメモリー使用量を外部で測定して、RAM負荷率が大きくなりすぎないようにすることが重要です。topやvmstatなどのツール、およびタスク・マネージャは、実際に使用されているRAMの量の特定に役立ちます。

記憶域の比率

指定したサイズのキャッシュ・サーバー内に格納できるデータの量として、プライマリ・キャッシュ記憶域のヒープの3分の1以下に使用を抑えることを基本的にお薦めします。これによって、次の3分の1をバックアップ記憶域に、最後の3分の1をスクラッチ領域に割り当てることができます。スクラッチ領域は、クラスの保持、一時オブジェクト、ネットワーク転送バッファ、GC圧縮などに使用します。<high-units>要素を構成して、<unit-calculator>要素にBINARY値を指定することによって、キャッシュごとにプライマリ記憶域を制限するようCoherenceを設定することができます。これらの設定は、バックアップ記憶域にも自動的に適用されます。

プライマリ記憶域とバックアップ記憶域の両方が、JVMに確保されている領域内に収まるようにすることが理想です(HotSpotベースのJVMの場合)。コレクタ生成のサイズ設定の詳細は、次のHotSpotのガベージ・コレクションのチューニング・ガイドを参照してください。

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

キャッシュ・トポロジとヒープ・サイズ

大きなデータセットには、パーティション・キャッシュまたはニア・キャッシュをお薦めします。Coherence JVMの数が変化してもキャッシュのパフォーマンスに大きな影響はありません。パーティション・キャッシュのスケーラビリティは、読取りと書込みのどちらについても直線的であるためです。レプリケート・キャッシュを使用すると、GCに対する負荷がきわめて大きくなります。

データ・グリッド操作用のキャパシティの計画

データ・グリッド操作(問合せや集計など)には、別のヒープ領域の要件があり、この操作を使用するときにはそれに応じた計画を立てる必要があります。データ・グリッド操作とは、メモリー内に保持される結果セットに含まれるキャッシュ・エントリのバイナリ表現のことです。操作によっては、このエントリは、その操作の期間中はデシリアライズされた形式で保持されることもあります。一般に、これは結果セット内の各エントリのメモリー量を倍増します。さらに、バッキング・マップの実装としてRAMまたはフラッシュのジャーナリングを使用しているときには、オブジェクトの格納方法に違いがあるために2番目のバイナリ・コピーが保持されます。2番目のバイナリ・コピーは、操作期間中も保持されるため、結果セット内の各エントリのための合計メモリーは3倍に増加します。

ヒープ・メモリーの使用率は、操作の実行対象になる結果セットのサイズと、処理される同時リクエストの数によって異なります。結果セットのサイズは、エントリの合計数と、各エントリのサイズに影響を受けます。記憶域キャッシュ・サーバーに維持された適度なサイズの結果セットは、ヒープのメモリーを使い果たす可能性はほとんどありません。ただし、結果セットが著しく大きい場合は、追加のメモリー要件によってヒープがメモリーを使い果たしてしまうことがあります。一般に、データ・グリッドの集計操作には巨大なデータセットが伴われるため、その他の操作よりも使用可能メモリーを使い果たしてしまう可能性が高くなります。

JVMのヒープ・サイズは、巨大な結果セットが予想されるときには、記憶域が有効なキャッシュ・サーバーで拡大しておく必要があります。ヒープの3分の1をスクラッチ領域に予約している場合(前述の推奨値)、割り当てられているスクラッチ領域が予想される結果セットのサイズをサポートできるようにします。別の方法として、データ・グリッド操作にはPartitionedFilter APIを使用できます。このAPIは、個別のバーティション・セットに対してグリッド操作を実行することで、メモリーの消費量を低減します。このAPIの詳細は、Oracle Coherence用Java APIリファレンスを参照してください。

システムごとに実行するJVMの数の決定

システムごとに実行するJVM(ノード)の数は、システムのプロセッサ/コア数とメモリー量によって異なります。出発点として、2つのコアごとに1つのJVMを実行することを計画してください。この推奨内容によって、次の要素のバランスが取れます。

- サーバーごとに複数のJVMを使用することによって、Coherenceでネットワーク・リソースをより効率的に使用できるようになります。Coherenceのpacket-publisherとpacket-receiverでは、JVMごとのスレッドの数が固定されます。コアを追加すると、それらのコア間でスケーラビリティを向上できるようにJVMを追加できます。

- JVMが多すぎると、プロセッサでの競合とコンテキスト・スイッチングが多くなります。

- JVMが少なすぎると、使用可能なメモリーを処理できない場合や、NICを完全に使用できない場合があります。

- 特に、大きなヒープ・サイズの場合、JVMには、長時間のGC休止を避けるための処理能力が必要です。

アプリケーションに応じて、1つのコアにつき1つになるまでJVMを追加できます。JVMの推奨数と構成されたヒープ・サイズも、ソケットごとのプロセッサ/コアの数とコンピュータのアーキテクチャによって異なる場合があります。

注意:

Coherenceを基本キャッシュ(get、put、removeの各操作)として使用する、キャッシュ・サーバー上にアプリケーション・クラス(エントリ・プロセッサ、アグリゲータ、問合せ、キャッシュ・ストア・モジュールなど)を持たないアプリケーションが、コア当たり1 JVMという制限を超えることがあります。この場合、正常なシナリオとフェイルオーバー・シナリオの両方を対象とするテストを行ってください。

ヒープのサイズ設定

ヒープ・サイズを検討する際は、適切なバランスを見つけることが重要です。下限はJVMごとのオーバーヘッドによって(または潜在的に数が増大する可能性のあるJVMの管理のしやすさによっても)決まります。たとえば、インフラストラクチャ・ソフトウェア(JMXエージェント、接続プール、内部JVM構造など)に100MBの固定オーバーヘッドがある場合、ヒープ・サイズが256MBのJVMを使用すると、非キャッシュ・データのオーバーヘッドは約40%になります。JVMヒープ・サイズの上限はメモリー管理のオーバーヘッドによって決まります。特に、GCの最大一時停止時間やGCに割り当てられているCPUの割合(およびその他のメモリー管理タスク)によって決まります。

GCは次の項目に影響を及ぼす可能性があります。

- Coherenceに対する操作の待機時間。ヒープが大きいほど、小さいヒープより待機時間が長くなり、予測が難しくなります。

- クラスタの安定性。非常に大きいヒープの場合、JVMはGC一時停止の間は応答しなくなるため、非常に長いガベージ・コレクション休止によって、クラスタ・メンバーが停止しているとTCMPが誤認識する可能性があります。TCMPではメンバーのヘルス状態を判断する際にGC一時停止が考慮されますが、ある時点でそのメンバーは停止していると判断される場合があります。

次のガイドラインが示されています。

- Oracle JVM 1.7の場合、ほとんどのアプリケーションに対して、控えめな4GBのヒープ・サイズをお薦めします。このサイズは、スループット、待機時間および安定性に基づいています。ただし、多数の小さなJVMから得られるパフォーマンスのメリットよりも、少数の大きなJVMから得られる管理の簡易化の方が重要になる一部のアプリケーションには、大きなヒープ・サイズ(最大20GB)が適しています。コア対ヒープの比率は、おおよそ1コア対2GBが理想的ですが、コアごとに数GB追加して余裕を持って使用できるようにします(3GBまたは4GB)。アプリケーションごとに違いがあるため、それに応じてGCをモニターする必要があります。

- OracleのConcurrent Mark and Sweep (CMS) GC (-XX:+UseConcMarkSweepGC)を使用して、CPU消費の増加と引換えにGCパフォーマンスを向上させます。

GC一時停止の長さは、ヒープ・サイズに対して直線的でなく、もっと悪い比率で増加します。つまり、ヒープ・サイズが2倍になると、一般に、GCによる一時停止時間は2倍より長くなります。GC一時停止は、アプリケーション使用状況の影響も受けます:

- ヒープ内のライブ・データ量が増すにつれ、一時停止時間が長くなります。ヒープ内のライブ・データが70%を超えないようにしてください。これにはプライマリ・データ、バックアップ・データ、インデックス、およびアプリケーション・データが含まれます。

- オブジェクト割当て率が高いと一時停止時間が長くなります。それぞれのネットワーク・パケットで多くのオブジェクトが生成されるため、単純なCoherenceアプリケーションでさえ、オブジェクト割当て率が高くなる場合があります。

- CPU集中型の処理によって、競合が増え、一時停止時間が長くなる場合もあります。

待機時間の要件に応じて、前述で推奨した値より大きいヒープ領域を割り当てることができますが、必ずシステムの負荷テストを実行してください。

アプリケーション・ヒープからのキャッシュの移動

パーティション・キャッシュの記憶域に専用のCoherenceキャッシュ・サーバー・インスタンスを使用すると、データがローカルに保存されなくなるため、アプリケーションJVMのヒープ・サイズが最小限に抑えられます。大半のパーティション・キャッシュ・アクセスはリモートで実行される(データの1/Nのみがローカルに保持される)ので、専用キャッシュ・サーバーを使用しても、通常は追加のオーバーヘッドはあまり増大しません。ニア・キャッシュ・テクノロジを使用することもできます。このテクノロジは、通常、ヒープ・サイズに最小限の影響しか及ぼしません(パーティション・キャッシュよりもさらに小さなサブセットをキャッシュするためです)。多くのアプリケーションでヒープ・サイズを著しく減らし、応答性を改善できます。

ローカルのパーティション記憶域は、coherence.distributed.localstorage Javaプロパティ(-Dcoherence.distributed.localstorage=falseなど)を使用して有効化(キャッシュ・サーバーの場合)または無効化(アプリケーション・サーバー・クライアントの場合)できます。

また、tangosol-coherence.xml(またはtangosol-coherence-override.xml)ファイルの<local-storage>設定を次のように変更して無効化することもできます。

例4-2 パーティション記憶域の無効化

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<!--
id value must match what's in tangosol-coherence.xml for DistributedCache
service
-->
<service id="3">
<init-params>
<init-param id="4">
<param-name>local-storage</param-name>
<param-value system-property="coherence.distributed.
localstorage">false</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>

記憶域が無効なクライアントがキャッシュにアクセスする前に、記憶域が有効なJVMが少なくとも1つ起動している必要があります。

ガベージ・コレクションの監視

長時間のGC一時停止時間はCoherenceクラスタに悪影響を与えることがあり、通常はノードの停止と区別が付きません。Javaアプリケーションは、このような一時停止中にパケットを送受信できません。オペレーティング・システムがバッファしているパケットの受信については、そのパケットは破棄されることがあるため、再送信する必要があります。このため、GC一時停止時間が最小限になるようにクラスタ・ノードのサイズを設定、調整することが重要です。一般的に、ノードの停止時間のうちGCによるものを10%未満に抑え、通常のGC一時停止時間を100ミリ秒未満に抑え、最大のGC一時停止時間を1秒程度にすることが必要です。

GCのチューニングの詳細は、次のHotSpotガベージ・コレクション・チューニング・ガイドを参照してください。

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

あるクラスタ・ノードが別のクラスタ・ノードについて一定時間応答のないことを検出した場合、ログ・メッセージが生成されます。このメッセージは一般に、ターゲットのクラスタ・ノードがGCサイクルにあることを示しています。

例4-3 ターゲットのクラスタ・ノードがガベージ・コレクション・モードであることを示すメッセージ

Experienced a 4172 ms communication delay (probable remote GC) with Member(Id=7, Timestamp=2006-10-20 12:15:47.511, Address=192.168.0.10:8089, MachineId=13838); 320 packets rescheduled, PauseRate=0.31, Threshold=512

PauseRateは、統計が最後にリセットされてからノードが応答なしと見なされるまでの時間の割合を示します。稼働時間に対して応答しない時間の割合が数パーセント以上あるとレポートされたノードは、GCのチューニングを調査する必要があります。

GCアクティビティは様々な方法でモニターでき、いくつかのOracle HotSpotメカニズムは次のとおりです。

- -verbose:gc(標準出力にGCログを書き込みます。出力先をカスタムの場所に変更する場合は、-Xloggcを使用します)

- -XX:+PrintGCDetails、-XX:+PrintGCTimeStamps、-XX:+PrintHeapAtGC、-XX:+PrintTenuringDistribution、-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime

- -Xprof: プロファイリングを有効にします。プロファイリングのアクティビティは、テストと本番デプロイメントとで区別する必要があり、リソースとパフォーマンスに対する影響を常にモニターする必要があります。

- JDKに含まれているJConsoleおよびVisualVM (VisualGCプラグインを含む)。

Coherence通信のチューニング

Coherenceには、ネットワーク上でのトラフィックの量を調整するための、<traffic-jamおよび<flow-control TCMP構成要素があります。これらの設定は、クラスタ・ノード内およびクラスタ・ノード間のパケット・フローの速度を制御するために使用します。これらの設定の構成方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

注意:

これらの設定のデフォルト値を変更すると、クラスタの通信に悪影響を及ぼす可能性があるため、通常はお薦めしません。

検証

前述の設定がパフォーマンスにどれほど影響しているかをチェックするには、クラスタ・ノードにパケットの損失や重複があるかどうかをチェックします。これは、様々なクラスタ・ノード上で次のJMXの統計を確認するとチェックできます。

- ClusterNodeMBean.PublisherSuccessRate: 1.0未満である場合は、パケットが失われ再送信されていることがわかります。レートが0.98未満であれば、調査および調整が必要になる場合があります。

- ClusterNodeMBean.ReceiverSuccessRate: - 1.0未満であれば、同じパケットが複数回受信されています(重複しています)。これは、パブリッシャがパケットの損失を過度に申告していることに起因している可能性があります。

- ClusterNodeMBean.WeakestChannel: 現在のノードとの通信が最も困難なリモート・クラスタ・ノードを特定します。

CoherenceのモニターにJMXを使用する方法は、Oracle Coherenceの管理を参照してください。

データ・アクセス・パターン

- データ・アクセスの分散(ホット・スポット)

- クラスタ・ノード・アフィニティ

- 読取り/書込み率とデータ・サイズ

- キャッシュにおける読取りと書込みのインターリーブ

データ・アクセスの分散(ホット・スポット)

大きなデータセットをキャッシュしている場合、一般には、そのデータセットのほんの一部で大半のデータ・アクセスに対応しています。たとえば、1000個のオブジェクトのデータセットの場合、操作の80%は100個のオブジェクトのサブセットに対するものになる場合があります。残り20%の操作は、その他900個のオブジェクトに対して実行される場合があります。言うまでもなく、最も高い投資対効果は、100個の最もアクティブなオブジェクトをキャッシュすることで得られます。残り900個のオブジェクトをキャッシュすると、さらに25%有効性の高いキャッシングを実現できますが、リソースについては900%の増大が必要になります。

ただし、すべてのオブジェクトが同頻度でアクセスされる場合(データセットの順次スキャンなど)は、同レベルの有効性を得るためにより多くのリソースが必要になります。この場合、0%を超えるキャッシュの有効性を実現するためには、100%のデータのキャッシュが必要になります(部分的にキャッシュされたデータセットの順次スキャンは、通常、MRU、LFUおよびMRU-LFUのエビクション・ポリシーに優先することに注意してください)。実際、ほとんどの非統合(ベンチマーク)データ・アクセス・パターンは不規則であるため、データのサブセットをキャッシュすることで処理速度は速くなります。

データのサブセットがアクティブであり、そのより小さなサブセットが特にアクティブである場合は、All無効化戦略を指定したニア・キャッシュの使用が非常に有用になることがあります(実際には、これは前述のルールの2層拡張になります)。

クラスタ・ノード・アフィニティ

Coherenceのニア・キャッシュ・テクノロジでは、特にPresent無効化戦略を指定している場合、クラスタ・ノード・アフィニティを透過的に利用します。このトポロジはスティッキーなロード・バランサで使用すると特に有用です。キャッシュのフロント部分がスラッシングされる(キャッシュ・エントリの存続期間が非常に短い)場合、Present無効化戦略のオーバーヘッドは(Allに比べて)高くなることに注意してください。これは、キー・レベルのイベント・リスナーの追加/削除のオーバーヘッドがより高いためです。一般にキャッシュはスラッシングしないよう調整されるため、通常は問題にはなりません。

読取り/書込み率とデータ・サイズ

一般には、次のキャッシュ・トポロジと使用例の組合せが最適です。

- レプリケート・キャッシュ: 少量の読取り頻度の高いデータ(メタデータなど)

- パーティション・キャッシュ: 大量の読取り/書込みデータ(大きなデータ・キャッシュなど)

- ニア・キャッシュ: パーティション・キャッシュに似ていますが、読取り頻度の高い段階的なアクセス・パターン(ホットスポットのある大きなデータ・キャッシュなど)やスティッキーなデータ・アクセス(スティッキーなHTTPセッション・データなど)で使用するとさらに有用です。同期化の方法(失効、非同期、同期)に応じて、最悪の場合のパフォーマンス・レベルは、パーティション・キャッシュと同等のレベルから、それよりも大幅に低いレベルまで変動します。

キャッシュにおける読取りと書込みのインターリーブ

インターリーブとは、キャッシュへの書込み間に発生するキャッシュの読取り数のことを指します。パーティション・キャッシュはインターリーブの影響を受けません(1:1のインターリーブで設計されているため)。一方、レプリケーション・キャッシュとニア・キャッシュは読取り頻度の高いキャッシュに合せて最適化されるため、読取り頻度の高いインターリーブ(各書込み間に10回の読取りなど)が適しています。これは、これら両方のキャッシュが、後続の読取りアクセス用にデータをローカルにキャッシュするためです。キャッシュへの書込みが行われると、ローカルにキャッシュされているこれらの項目は強制的にリフレッシュされますが、これは(ローカル・メモリー・ヒープからオブジェクトをフェッチするほぼゼロ・コストと比べて)比較的コストのかかる処理です。それでも、ニア・キャッシュ・テクノロジを使用する場合の最悪のパフォーマンス・レベルはパーティション・キャッシュと同レベルであり、パフォーマンス・ロスは最良のシナリオと比較した場合の損失になります。

インターリーブは(間接的にですが)読取り/書込み率に関係することに注意してください。たとえば、1:1の読取り/書込み率のニア・キャッシュでは、処理が非常に高速になるか(すべての書込み後にすべての読取りを実行)、非常に遅くなる可能性があります(1:1のインターリーブで書込みと読取りを交互に実行)。

5 本番チェックリスト

この章では、開発環境またはテスト環境から本番環境に移行するときに、計画および考慮する必要のある分野についてのチェックリストを示します。説明されているソリューションとベスト・プラクティスについては、必要に応じて実装する必要があります。Coherence*Extendを使用するときの追加の推奨事項は、Oracle Coherenceのリモート・クライアントの開発を参照してください。

この章の内容は次のとおりです。

- ネットワーク・パフォーマンス・テストとマルチキャストの推奨事項

- ネットワークの推奨事項

- キャッシュ・サイズ計算の推奨事項

- ハードウェアの推奨事項

- オペレーティング・システムの推奨事項

- JVMの推奨事項

- Oracle Exalogic Elastic Cloudの推奨事項

- セキュリティの推奨事項

- アプリケーション・インストゥルメンテーションの推奨事項

- Coherenceのモードおよびエディション

- Coherenceオペレーション構成の推奨事項

- Coherenceキャッシュ構成の推奨事項

- 大規模なクラスタ構成の推奨事項

- 停止検出の推奨事項

ネットワーク・パフォーマンス・テストとマルチキャストの推奨事項

TCPネットワーク・パフォーマンスのテスト

メッセージ・バス・テスト・ユーティリティを実行して実際のネットワーク速度をテストし、大量のTCPメッセージをプッシュするための性能を確認します。本番デプロイメントの前に、メッセージ・バス・テストの実行が成功する必要があります。詳細は、「メッセージ・バス・テスト・ユーティリティの実行」を参照してください。通常、ネットワーク用にTCPスタックがすでに構成されており、Coherence用に追加構成する必要はありません。TCPパフォーマンスが不十分な場合は、TCP設定の変更を検討してください。チューニングできる一般的なTCP設定については、「TCPに関する考慮事項」を参照してください。

データグラム・ネットワーク・パフォーマンスのテスト

データグラム・テスト・ユーティリティを実行して実際のネットワーク速度をテストし、データグラム・メッセージをプッシュするための性能を確認します。本番デプロイメントの前に、両方のテストの実行に成功する必要があります。詳細は、「ネットワーク・パフォーマンス・テストの実行」を参照してください。さらに、パブリッシャとコンシューマの比率を高めてデータグラム・テスト・ユーティリティを実行する必要もあります。単一パブリッシャと単一コンシューマでは良好に見えるネットワークも、パブリッシャの数が増加すると完全に機能しなくなる可能性があります。

マルチキャストの使用の検討

マルチキャストという用語は、1台のサーバーから情報パケットを送信し、そのパケットをネットワークによって複数のサーバーに並列的に配信する機能を意味します。Coherenceは、マルチキャストとマルチキャストフリーの両方のクラスタリングをサポートしています。マルチキャストの使用は、クラスタ構成を簡単にする場合に使用できます。ただし、次のような理由からマルチキャストを使用できない場合があります。

- マルチキャストの使用が組織で許可されていません。

- 特定のタイプのネットワーク装置でマルチキャストが機能しない。たとえば、WANルーターの多くは、マルチキャスト・トラフィックを使用できないかサポートしていません。

- 技術的な理由によりマルチキャストが使用できない。たとえば、スイッチによってはマルチキャスト・トラフィックがサポートされていない場合があります。

マルチキャスト・テストを実行して、マルチキャストが機能するかどうかを検証し、本番環境に適した(最小の)TTL値を確認する必要があります。本番デプロイメントの前に、マルチキャスト・テストの実行が成功する必要があります。詳細は、「マルチキャスト接続テストの実行」を参照してください。

デプロイメントにマルチキャストを使用できないアプリケーションでは、ユニキャストおよびウェル・ノウン・アドレス機能を設定する必要があります。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

ネットワーク・デバイスの構成

ネットワーク・パフォーマンス・テストおよびマルチキャスト・テストが問題なくすべて成功し、結果が完璧であっても、ネットワーク・デバイスの構成が必要になることがあります。「ネットワークのチューニング」の推奨事項を確認してください。

デフォルトのクラスタ・ポートの変更

デフォルトのクラスタ・ポートは7574で、ほとんどのユース・ケースでは変更する必要はありません。このポート番号または選択したその他のポートは、オペレーティング・システムのエフェメラル・ポートの範囲内にならないようにしてださい。エフェメラル・ポートは、他のプロセスにランダムに割り当てることができるため、起動時にCoherenceでポートにバインドできなくなる場合があります。ほとんどのオペレーティング・システムでは、エフェメラル・ポートの範囲は一般に32,768以上で開始されます。Red Hatなど、一部のバージョンのLinuxのエフェメラル・ポートの範囲は低くなっているため、ランダムなバインドによる障害を回避するために、特に注意が必要になります。

Linuxでは、エフェメラル・ポートの範囲を次のように問合せできます。

sysctl net.ipv4.ip_local_port_range

sysctl net.ipv4.ip_local_reserved_ports

最初のコマンドは、範囲の最初と最後を示す空白で区切られた2つの値で範囲を示します。2番目のコマンドは、予約済ポートのカンマ区切りのリスト(予約済ポートの範囲)を範囲から除外することを示します(例: 1,2,10-20,40-50など)。

目的のポートがエフェメラル範囲にあり、予約されていない場合は、予約済のセットを変更して、オプションでエフェメラル・ポート範囲を絞り込むことができます。これは、/etc/sysctl.confを編集してルートとして実行できます。次に例を示します。

net.ipv4.ip_local_port_range = 9000 65000
net.ipv4.ip_local_reserved_ports = 7574

ファイルの編集後に次を実行して、設定のリロードをトリガーできます。

sysctl -p

ネットワークの推奨事項

一貫したIPプロトコルの確保

java.net.preferIPv4Stackプロパティについて、クラスタ・メンバーで同じ設定を共有することをお薦めします。一般に、このプロパティは設定する必要がありません。同じマシンで複数のクラスタが稼働している場合、クラスタ・ポートを共有すると、クラスタではその設定についても同じ値を共有する必要があります。ループバック・アドレスでマルチキャストを実行するといったまれな状況では、この設定が必要になることもあります。

クラスタ化環境でのテスト

POCまたはプロトタイプ段階が完了してからロード・テストが開始されるまでの間、アプリケーションが非クラスタ化構成で開発およびテストされることは珍しくありません。主なテストを非クラスタ化構成で実行すると、アプリケーションのアーキテクチャや実装上の問題が検出されず、後の段階、さらには本番に移行してから問題が発覚する可能性があります。

アプリケーションを本番稼働する前に、必ずクラスタ化構成でテストしてください。クラスタ化されたテストが開発プロセスに自然に含まれるようにするには、いくつかの方法があります。例:

- 開発者は、ローカルにクラスタ化した構成(開発者自身のコンピュータで2つ以上のインスタンスを実行する構成)でテストできます。単一のコンピュータでのクラスタリングはTTL=0設定で機能するため、この方法は、TTL=0と設定するだけで実現します。

- クラスタ化されたテスト環境で実行するユニット・テストおよびリグレッション・テストを導入できます。この方法は、個々の開発者が忘れてしまったり時間がなくて実行できないかもしれない、クラスタ化されたテストを自動的に実行する場合に役立ちます。

UDPおよびTCPの本番ネットワークの速度の評価

ほとんどの本番ネットワークは、ギガビット・イーサネット(GbE)や100Mbイーサネットで構築されている部分が残されていますが、10ギガビット・イーサネット(10GbE)を基に構築されています。Coherenceには、GbEおよび10GbEを使用してください。10GbEをお薦めします。ほとんどのサーバーは10GbEをサポートしています。また、10GbEのスイッチは経済的で可用性が高く、広く普及しています。

本番ネットワークのトポロジと、Coherenceを実行するすべてのサーバーの接続に使用されているデバイスについて理解していることが重要です。たとえば、サーバーの接続に10台のスイッチが使用されている場合、それらはすべて同じタイプ(メーカーやモデル)のスイッチであるか。また、それらはすべて同じ速度であるか。サーバーは利用可能なネットワーク速度をサポートしているかどうかなどを確認します。

一般に、すべてのサーバーは、信頼できるフル・スイッチド・ネットワークを共有する必要があります。これは通常、単一スイッチを共有することを意味します(理想的には、可用性を確保するために、サーバーごとに並列スイッチとネットワーク・カードを2つずつ使用します)。この主な理由は2つあります。1つ目の理由は、複数のスイッチを使用すると、ほとんどの場合ネットワークの実効キャパシティが減少するためです。もう1つの理由は、マルチスイッチ環境ではネットワークのパーティション化イベントが発生しやすくなるため、部分的なネットワーク障害によって2組以上のサーバーの接続が切断されます。パーティション化イベントの発生はまれですが、Coherenceのキャッシュ・サーバーでは、理想的には共通のスイッチを共有することをお薦めします。

複数のスイッチが帯域幅に及ぼす影響を説明するために、単一スイッチに接続された複数のサーバーを考えてみましょう。サーバーを増設するに従って、各サーバーにはスイッチ・バックプレーンから専用の帯域幅が割り当てられます。たとえば、フル・スイッチド・ギガビット・バックプレーンでは、各サーバーにはインバウンド帯域幅とアウトバウンド帯域幅が1ギガビットずつ割り当てられるため、合計2Gbpsの全二重帯域幅になります。サーバーが4つの場合、帯域幅の合計は8Gbpsになります。サーバーが8つになれば、合計は16Gbpsです。このようにして、スイッチの上限まで帯域幅は増加します(実際には、通常のギガビット・スイッチの範囲は160から192Gbpsです)。ところが、4Gbpsの(8Gbpsの全二重)リンクで接続された2つのスイッチの例を考えてみましょう。この場合、各スイッチにサーバーが追加されるたびに、これらのサーバーには、1台のスイッチ当たり最大4台のサーバー分までの完全なメッシュ帯域幅が割り当てられます(つまり、一方のスイッチ上の4台のサーバーは、いずれももう一方のスイッチ上の4台のサーバーと最大速度で通信できます)。しかし、サーバーを追加すると、スイッチ間リンクにボトルネックが生じる可能性があります。たとえば、一方のスイッチ上の5台のサーバーが、もう一方のスイッチ上の5台のサーバーにそれぞれ1Gbpsの速度でデータを送信したとすると、合計5Gbpsの通信が4Gbpsのリンクによって制限されます。実際の制限は、サーバーごとのトラフィックや、リンク上を実際に移動するトラフィックの量に応じて、かなり高くなる場合があります。また、ネットワーク・プロトコルのオーバーヘッドや不規則なトラフィック・パターンなどの要素によっても、使用可能な範囲がアプリケーション・パースペクティブから大幅に減少する場合があります。

ネットワーク速度の混在および競合は避けてください。すべてのサーバーが同じ速度でネットワークに接続でき、サーバー間のすべてのスイッチとルーターが同じ速度またはより高い速度で実行されるようにします。

継続的なネットワーク停止に対する計画

Coherenceのクラスタ・プロトコルは、様々な接続障害を検出して処理できます。クラスタ化サービスは、接続の問題を識別し、問題のあるクラスタ・ノードを強制的に切り離して、再びクラスタに参加させることができます。このようにして、クラスタでは、一貫性のある共有状態がメンバー間で確実に維持されます。

詳細は、「停止検出の推奨事項」を参照してください。また、「Cisco社製スイッチへのデプロイ」も参照してください。

ファイアウォール・ポート構成に対する計画

ファイアウォールの外側に配置されたCoherenceクラスタ・メンバーは、ファイアウォールの内側に配置されたクラスタ・メンバーと通信できる必要があります。Coherenceの通信が許可されるように、必要に応じてファイアウォールを構成してください。次のリストは、一般的なデフォルト・ポートと、ポートを構成する追加の分野を示しています。

- クラスタ・ポート: デフォルトのマルチキャスト・ポートは7574です。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- ユニキャスト・ポート: UDPには2つのポートが必要であり、TMBでは1つのポートを使用します。デフォルトのユニキャスト・ポートは、オペレーティング・システムの使用可能なエフェメラル・ポート範囲から自動的に割り当てられます。ファイアウォールを越えて通信するクラスタの場合、ポートの範囲を指定してCoherenceがその範囲内で動作するようにできます。特定のポートではなく範囲を使用すると、複数のクラスタ・メンバーが同じマシン上に存在し、共通の構成を使用できるようになります。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

注意:

一般に、クラスタ内でのファイアウォールの使用は、(TCMPクライアントとTCMPサーバーの間であっても)アンチパターンであると見なされます。構成上のミスや信頼性の問題が発生しやすく、本番環境でのトラブルシューティングが困難な場合も多いからです。定義上は、クラスタ内のすべてのメンバーを信頼の置けるものと見なせます。信頼できないメンバーをクラスタに参加させてはならず、それらはCoherence Extendクライアントとして接続するか、サービス・レイヤー(HTTP、SOAなど)を使用して接続する必要があります。

- ポート7: クラスタ・メンバーのハードウェア障害を検出するために使用される、IpMonitorコンポーネントのデフォルト・ポートです。Coherenceは、このポートにバインドされず、リモート・マシンにpingを行う手段としてそのポートに接続を試みるだけです。Coherenceでヘルス・モニタリング・チェックを実行するには、ポートをオープン状態にする必要があります。

- プロキシ・サービスのポート: デフォルトでは、プロキシは一時ポートでリスニングします。ファイアウォールに基づいた構成では、このポートは、ファイアウォールでオープンできるポートの範囲に制限できます。ポートの範囲を使用すると、複数のクラスタ・メンバーが同じマシン上で実行され、単一の共通の構成を共有できるようになります。詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

- Coherence RESTのポート: Coherence RESTクライアントからのリモート接続を可能にするために使用される、任意の番号のポートです。詳細は、『Oracle Coherenceリモート・クライアントの開発』を参照してください。

キャッシュ・サイズ計算の推奨事項

この項で説明する推奨事項は、キャッシュのおおよそのサイズを計算するために使用します。キャッシュに必要なサイズを把握することは、JVMの必要数、物理メモリーの必要量、およびCPUとサーバーの必要数を判断する際に役立ちます。ハードウェアとJVMの推奨事項は、この章の後半で説明します。ここに示す推奨事項は、ガイドラインに過ぎません。正確なサイズを把握するには、アプリケーションの負荷とユース・ケースを考慮に入れた具体的なテストの結果を検証する必要があります。このテストでは、予想されるユーザーのボリューム、トランザクションのプロファイル、操作の処理などをシミュレートします。

原則として、プライマリ・データのバックアップ・コピーを1つ保持することを想定すると、物理ヒープ・サイズの少なくとも3倍のサイズを、データセット・サイズとして割り当てます。より正確に計算するには、キャッシュのサイズを次のように計算し、プライマリ・データの1つのバックアップ・コピーも想定に入れます。

キャッシュ容量 = エントリ数 * 2 * エントリ・サイズ

この場合:

エントリ・サイズ = キーのシリアライズ形式 + 値のシリアライズ形式 + 150バイト

たとえば、キャッシュに500万個のオブジェクトが含まれていて、そのオブジェクトのシリアル化された値とキーがそれぞれ100バイトと2KBだとします。

次のように、エントリ・サイズを計算します。

100バイト + 2048バイト + 150バイト = 2298バイト

次に、キャッシュ容量を計算します。

5000000 * 2 * 2298バイト = 21,915 MB

索引付けが使用されている場合は、索引サイズも考慮に入れる必要があります。順序付けされていないキャッシュ索引は、シリアライズ化された属性値とキーで構成されます。順序付けされた索引には、追加の前方および後方ナビゲーション情報が含まれます。

索引は、メモリーに格納されます。各ノードには、逆索引と通常索引用の2つの追加マップ(java.util.HashMapのインスタンス)が必要になります。逆索引のサイズは、値の基数(値定義域のサイズ、つまり重複しない値の数)になります。通常索引のサイズは、キー・セットのサイズになります。HashMapにかかる余分なメモリー・コストは、約30バイトになります。抽出された索引付きの値ごとにかかる余分なコストは、12バイト(オブジェクトの参照サイズ)と、その値自体のサイズになります。

たとえば、Long値の余分なサイズは20バイト(12バイト + 8バイト)になり、Stringの場合は12バイト + 文字列の長さになります。さらに、大きな基数による索引には追加の参照コスト(12バイト)と、格納された索引用の小さな追加コスト(約4バイト)もかかります。そのため、おおよその索引コストは次のように計算できます。

索引サイズ = 通常索引のマップ + 逆索引のマップ + 参照 + 値のサイズ

大きな基数の索引付けされたLong値の場合、次のような概算値になります。

30バイト + 30バイト + 12バイト + 8バイト = 80バイト

平均20文字の長さを持つ索引付けされたStringの場合、次のような概算値になります。

30バイト + 30バイト + 12バイト + (20バイト * 2) = 112バイト

索引コストは、小さなオブジェクトに対しては比較的高いものになりますが、これは定数であるためオブジェクトが大きくなるほどコストが低くなります。

キャッシュのサイズ設定は、厳密な技法ではありません。オブジェクトのサイズと最大数について仮定する必要があります。完全な例は、次のとおりです。

- 見積もられる平均エントリ・サイズ = 1k

- 見積もられるキャッシュ・オブジェクトの最大数 = 100k

- 20文字のString索引 = 5

次のように、索引サイズを計算します。

5 * 112バイト * 100k = 56MB

次に、キャッシュ容量を計算します。

100k * 2 * 1k + 56MB = ~312MB

各JVMはオンヒープ・データ自体を格納し、データを処理するために、ある程度の空き容量が必要になります。これは、1GBのヒープでは、約300MB以上になります。JVMは、ヒープとは別に約200MBのJVMのアドレス空間を処理します。そのため、312MBのデータを格納するには、2ノードのJVMクラスタ内の各ノードで次のメモリーが必要になります。

312MB(データ用) + 300MB(作業JVMヒープ) + 200MB (JVM実行可能ファイル) = 812MB(物理メモリーの量)

これは、最低限の必要ヒープ領域であることに注意してください。見積りの誤差と今後予想される成長を考慮に入れて、約10%の領域を追加して余裕を持たせます。また、M+Nの冗長性にあわせて調整します。たとえば、2台のサーバーでの障害発生を許容する必要のある、12メンバーからなるクラスタでは、キャッシュの合計容量が12台のサーバーではなく10台のサーバーに基づいている必要があります。

JVMのメモリー要件を追加した場合、キャッシュのメモリー要件の完全な計算式は、次のように表されます。

キャッシュ・メモリーの要件 = ((キャッシュ・エントリのサイズ + 索引のサイズ) * 2 (プライマリおよびバックアップ用)) + JVMの作業用メモリー(1GB JVMの約30%)

ハードウェアの推奨事項

現実的な負荷テストの計画

一般に、デプロイメントは、比較的高速なワークステーションで行われます。さらに、通常、テストはクラスタ化されていない状態で行われ、単一のユーザー・アクセス(開発者のみ)を示す傾向があります。このような環境では、アプリケーションの応答性が非常に高く観測されることがあります。

本番環境に移行する前に、クラスタ構成内で同時ユーザーの負荷をシミュレートした現実的な負荷テストが実行されていることを確認してください。

本番環境に移行する前の適切なハードウェアでの開発

Coherenceは、すべての一般的なワークステーション・ハードウェアと互換性があります。開発者は通常、ノートブック、デスクトップ、ワークステーションなどを含むPCまたはAppleハードウェアを使用しています。

開発者のシステムには、最新のIDE、デバッガ、アプリケーション・サーバー、データベースおよび少なくとも2つのクラスタ・インスタンスを実行するための膨大なRAMが必要です。メモリーの使用方法は様々ですが、開発者のシステムの生産性を保証するには、2GB以上のメモリー構成が推奨されます。

サーバー・ハードウェア・プラットフォームの選択

オラクル社では、お客様によって標準化されたハードウェアまたは本番デプロイメント用に選択されたハードウェアをサポートするよう努めています。

- オラクル社のお客様は、ほぼすべての主要なサーバー・ハードウェア・プラットフォームを使用しています。その大多数はコモディティx86サーバーを使用しており、Oracle SPARCサーバーおよびIBM Powerサーバーを使用しているお客様もかなりいます。

- オラクル社では、IntelとAMDの両方のコモディティx86サーバーでCoherenceを継続的にテストしています。

- オラクル社は、Intel、Apple、IBMの各社から、ハードウェア、チューニング・アシスタントおよびテスト・サポートの提供を受けています。

サーバー・ハードウェアをまだ購入していない場合は、次の推奨事項に留意してください。

サーバーのRAMは32GB以上に構成することを強くお薦めします。大容量(数十GBから数百GB、またはそれ以上)のデータをメモリーに格納するアプリケーションでは、1台のサーバー当たり128GBまたは256GBのRAMのコスト効果を評価してください。また、大容量のRAMを搭載したサーバーは、その分だけ1台で実行する必要のあるCoherenceノード(JVM)の数も多くなるため、CPUコアの数を増やすと効果的であることに注意してください。データ量の多いアプリケーションではCPUに対するRAMの比率を高くし、処理量の多いアプリケーションではその比率を低くする必要があります。

ネットワーキングには、1000Mbps以上(たとえば、ギガビット・イーサネット以上)を強く推奨します。NICは、標準のPCIではなく、PCI-XやPCIeなどの高帯域幅のバスに配置します。

サーバー数の計画

Coherenceは本質的にはスケールアウト・テクノロジです。ナチュラル・モードの操作は、多数のサーバー(たとえば、2ソケットまたは4ソケットの商用サーバー)におよびます。ただし、Coherenceは、サーバーごとに複数のJVMを使用することで、効率的に少数の大規模サーバーにスケール・アップすることもできます。フェイルオーバーとフェイルバックは、クラスタ内に存在するサーバー数が多くなるほど効率が高くなり、1つのサーバー障害の影響が軽減されます。1つのクラスタには、最小で4台の物理サーバーを含めて、障害時のデータ損失の可能性を最小限に抑える必要があります。一般的なWAN構成では、データ・センターごとに独立したクラスタ(通常はExtend-TCPで相互接続されます)を配置します。これにより、個々のサーバーの合計数(1データ・センター当たり4台のサーバー×データ・センター数)は増加します。

Coherenceは小規模なクラスタ(物理サーバー1台から3台)にデプロイされることも多くありますが、その場合、負荷の高い状況でサーバーに障害が発生したときのリスクが増大します。「UDPおよびTCPの本番ネットワークの速度の評価」で説明したように、Coherenceクラスタは、単一スイッチ(物理サーバー96台未満など)に限定することが理想的です。使用例によっては、コンピュートバウンドまたはメモリーバウンドのアプリケーションは(ネットワークバウンドアプリケーションに比べて)、大規模なクラスタの方が満足に動作する場合もあります。

また、多数のJVMを使用する少数のクラスタと、少数のJVMを使用する多数のクラスタとでは、後者が適切なオプションである場合がありますCoherenceの本番環境には、数百ものJVMを使用するケースがあります。この規模のクラスタを適切に準備するには注意が必要ですが、JVMが数十台しかない小規模なクラスタは簡単に実現します。WKAを使用してマルチキャストを無効にしたり、低速ネットワーク(100Mbpsイーサネットなど)を使用したりすると、ネットワーク効率が低下し、スケーリングが困難になることに注意してください。

JVMの使用数に基づいた必要なサーバー数の判断

信頼性のある、可用性の高い構成に必要なサーバー数を決定したり、記憶域として機能するJVM数の構成方法を決定するには、次の規則に従います。

- 3台以上のサーバーを使用する必要があります。2台のサーバーのみでグリッドを構成した場合、1台のサーバーのJVM数がもう一方のサーバーのJVM数と一致しなくなった時点で、マシンの安全性は保証されなくなります。したがって、最初は2台のサーバーで同数のJVMが実行されていても、1つのJVMに障害が発生すれば、グリッド内のマシンの安全な状態は強制的に損なわれます。JVMの数が等しくない場合、Coherenceでパーティションを割り当てる際に、メンバーごとに同等の使用率を確保しながら、プライマリ・コピーとバックアップ・コピーを別のマシンに配置することが困難になる可能性があります。そのため、推奨されているベスト・プラクティスでは3台以上の物理サーバーを使用します。

- クラスタ内で最も多くJVMを配置するサーバーでは、そのJVMの数がクラスタ内の他のすべてのサーバーのJVMの合計数を超えないようにします。

- 最も少なくJVMを配置するサーバーでは、最も多く配置するサーバーの少なくとも半数のJVMを実行することをお薦めします。この規則は、小規模のクラスタには特に重要になります。

- 安全性は、JVMの数がクラスタ内のすべてのコンピュータの台数に近くなるほど高くなります。これは、前述のどの規則よりも一般的なプラクティスです。

オペレーティング・システムの推奨事項

オペレーティング・システムの選択

オラクル社では次のオペレーティング・システム上でのテストを実行し、これらのオペレーティング・システムをサポートしています。

- 各種のLinuxディストリビューション

- Sun Solaris

- IBM AIX

- Windows

- Mac

- OS/400

- z/OS

- HP-UX

- 各種のBSD UNIXディストリビューション

コモディティx86サーバーには、Linuxディストリビューション(Linux 2.6カーネル以上)が推奨されます。Linuxディストリビューションのほとんどは、Coherenceの実行に適した環境を提供することが予想されますが、オラクル社ではさらに、Oracle Linux (Unbreakable Enterprise Kernelを使用したOracle Linuxを含む)や、Red Hat Enterprise Linux(バージョン4以上)、Suse Linux Enterprise(バージョン10以上)などをお薦めします。

Coherenceのデプロイ先オペレーティング・システムについては、「プラットフォーム固有のデプロイに関する考慮事項」を確認し、その指示に従ってください。

注意:

開発用と本番用のオペレーティング・システムは異なる場合があります。対象とする本番用オペレーティング・システムを定期的にテストするようにしてください。

仮想メモリー(ディスクへのページング)の使用は避けます。

Coherenceベースのアプリケーションでは、主要なデータ管理の役割(専用キャッシュ・サーバーなど)がJavaベースのプロセスでホストされます。最新のJavaディストリビューションは、仮想メモリーでは効率よく機能しません。特にガベージ・コレクション(GC)操作では、メモリーがディスクにページングされる場合、桁違いに速度が低下することがあります。適切にチューニングされたJVMでは、すべてのGCを1秒未満で実行できます。しかし、JVMが部分的にディスクに存在する場合は、実行に何分もかかるようになります。ガベージ・コレクションの実行中、ノードは長時間無応答になるため、クラスタ内の他のノードの選択肢は、無応答ノードの応答を待つ(この間、アプリケーションのアクティビティは部分的にブロックされます)か、無応答ノードを障害ノードとみなしてフェイルオーバー処理を実行するかのいずれかになります。どちらにしても適切な選択ではないため、ガベージ・コレクションによる過度の一時停止を避けることが重要です。JVMは設定ヒープ・サイズで構成して、ヒープが使用可能なRAMメモリーを使い果たさないようにする必要があります。さらに、定期的なプロセス(日次バックアップ・プログラムなど)は、メモリー使用の急増によってCoherenceのJVMがディスクにページングされるないようにモニターする必要があります。

関連項目: 「スワッピング」

ソケット・バッファ・サイズの増加

オペレーティング・システムのソケット・バッファを大きくして、ガベージ・コレクション時にJavaアプリケーションが一時停止している間に受信ネットワーク・トラフィックを処理できるようにする必要があります。UNIXのほとんどのバージョンではデフォルトのバッファ制限が非常に小さく設定されていますが、これを2MBに増大する必要があります。

関連項目: 「ソケット・バッファ・サイズ」

JVMの推奨事項

開発段階では、開発者は一般に、最新のOracle HotSpot JVM、またはMac OS X JVMなどの直接派生製品を使用します。

本番環境で異なるJVMを使用する場合、主に次のような問題が生じます。

- コマンド行の違い。シェル・スクリプトおよびバッチ・ファイルに問題が生じる場合があります。

- ロギングおよびモニタリングの違い。開発テスト時にログの分析およびライブJVMのモニターに使用していたツールを本番環境で使用できなくなる可能性があります。

- 最適なガベージ・コレクション構成、およびチューニング方法の大きな違い。

- スレッド・スケジューリング時の動作、ガベージ・コレクションの動作とパフォーマンス、およびコード実行パフォーマンスの違い。

所定のテストは、必ず本番環境で使用するJVMで実行してください。

JVMの選択

サポートされている最小のJVMバージョンは、『Oracle Coherenceのインストール』のシステム要件に関する項を参照してください。

JVMの選択は、他のソフトウェアにも左右される場合があります。次に例を示します。

- IBMでは、IBM JVM上で実行されるIBM WebSphereのみをサポートしています。ほとんどの場合、JVMにはIBM SovereignまたはJ9が使用されますが、WebSphereがOracle Solaris/Sparcで実行される場合、JVMはIBM独自のソース・コードではなく、Oracle JVMのソース・コードを使用して構築されます。

- Oracle WebLogicおよびOracle Exalogicには特定のJVMバージョンが含まれています。

- Apple Mac OS X、HP-UX、IBM AIXなどのオペレーティング・システムは、1つのJVMベンダー(それぞれApple、HP、IBM)しかサポートしていません。

- 特定のソフトウェア・ライブラリとフレームワークは、比較的新しいJava機能を使用しているため、最小限のJavaバージョン要件が伴います。

LinuxまたはWindowsを実行する商用x86サーバーでは、Oracle HotSpot JVMを使用します。一般に、最新バージョンを使用する必要があります。

注意:

テストおよびデプロイメントには、プラットフォームおよびCoherenceバージョンに基づいてサポートされる、最新のOracle HotSpot JVMを使用します。

本番に移行する前に、JVMのベンダーとバージョンを選択して十分にテストし、そのJVMでテスト中およびステージング中に検出されたすべての不具合を修正する必要があり、本番への移行には、そのJVMを使用することをお薦めします。間断ない可用性が要求されるアプリケーションでは、承認の前に、そのJVMで長期にわたる(少なくとも2週間)アプリケーション・ロード・テストを実行する必要があります。

Coherenceのデプロイ先のJVMについては、「プラットフォーム固有のデプロイに関する考慮事項」を確認し、その指示に従ってください。

JVMオプションの設定

JVMの構成オプションはバージョンおよびベンダーによって異なりますが、一般には次のことをお薦めします。

- -serverオプションを使用すると、パフォーマンスが大幅に向上します。

- -Xmsと-Xmxの両方に同じヒープ・サイズを使用すると、Oracle HotSpot JVMでのパフォーマンスが大幅に向上し、フェイル・ファストのメモリー割当てを実現できます。

- Concurrent Mark and Sweep (CMS)ガベージ・コレクションを使用すると、ガベージ・コレクション・パフォーマンスが向上します: -XX:+UseConcMarkSweepGC

- ガベージ・コレクションをモニターします。特に巨大なヒープを使用する場合は、-verbose:gc、-XX:+PrintGCDetails、-XX:+PrintGCTimeStamps、-XX:+PrintHeapAtGC、-XX:+PrintTenuringDistribution、-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTimeを指定します。

- JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試行できるようにするのではなく、JVMを終了するように構成します。Linuxの場合は-XX:OnOutOfMemoryError="kill -9 %p"、Windowsの場合は-XX:OnOutOfMemoryError="taskkill /F /PID %p"を設定します。

- JVMでメモリー不足のエラーが発生した場合は、-XX:+HeapDumpOnOutOfMemoryErrorを設定してヒープ・ダンプを取得してください。

混合JVM環境をテストするための計画

CoherenceはPure Javaソフトウェアであるため、クラスタ内のJVMのベンダーとバージョンがどのような組合せであっても実行できます。オラクル社では、このような構成についてもテストしています。

JVMが異なると、Javaオブジェクトのシリアライズ形式も若干異なる可能性があることに注意してください。したがって、あるJVMでシリアライズされたオブジェクトがネットワークを介してベンダーやバージョンの異なるJVMに渡された場合、そのJVMでオブジェクトをデシリアライズしようとすると、非互換性の問題が生じる可能性があります。幸いにも、Javaのシリアライズ形式はここ数年変わっていないため、この種の問題が発生する可能性はほとんどありません。しかし、本番環境にデプロイする前に、混合構成をテストして、シリアライズの整合性を確認することを強くお薦めします。

関連項目:

- 「Oracle HotSpot JVMへのデプロイ」

- 「IBM JVMへのデプロイ」

Oracle Exalogic Elastic Cloudの推奨事項

Oracle ExalogicおよびOracle Exalogic Elastic Cloudソフトウェアは、究極のパフォーマンス、信頼性およびスケーラビリティの基礎となっています。Coherenceは、特にOracle Exabusテクノロジを使用する際にこの基礎を利用するように最適化されています。Exabusは優れたハードウェア、ソフトウェア、ファームウェア、デバイス・ドライバおよび管理ツールから構成され、OracleのQuad Data Rate (QDR) InfiniBand技術をベースに構築されています。ExabusはすべてのOracle Exalogicシステム・コンポーネントを関連付ける高速通信(I/O)ファブリックを形成します。Exalogicの詳細は、『Oracle Exalogicエンタープライズ・デプロイメント・ガイド』を参照してください。

Oracle Coherenceには次の最適化が含まれます。

- トランスポート最適化
Oracle Coherenceではメッセージ・トランスポートにOracle ExabusメッセージングAPIを使用しています。APIは、Exalogic上でInfiniBandを利用するように最適化されています。APIはOracle Exalogic Elastic Cloudソフトウェアの一部で、Oracle Exalogicシステムでのみ利用できます。

特にOracle CoherenceではInfiniBand Message Bus (IMB)プロバイダを使用しています。IMBでは、ゼロ・メッセージ・コピー、カーネル・バイパス、予測通知およびカスタム・ヒープ外バッファをサポートするネイティブのInfiniBandプロトコルを使用しています。その結果、ホスト・プロセッサ負荷の減少、メッセージ・スループットの増加、割込みの減少およびガベージ・コレクションの一時停止が減少します。

Oracle ExalogicのデフォルトのCoherence設定では、サービス通信(データ転送)およびクラスタ通信にIMBを使用します。どちらのデフォルトも変更可能で、追加プロトコルがサポートされています。デフォルト・プロトコルの変更の詳細は、「信頼性のあるトランスポート・プロトコルの変更」を参照してください。

- エラスティック・データ最適化
エラスティック・データ機能は、バッキング・マップおよびバックアップ・データをRAMメモリーとソリッド・ステート・ディスク(SSD)などのデバイス間でシームレスに格納するために使用されます。この機能を使用すると、SSDへのデータの格納および読出しがほぼメモリー速度で可能になります。この機能には、ExalogicシステムでSSDメモリーを最も効率よく使用できるようにする動的チューニングが含まれています。エラスティック・データの有効化および構成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- Coherence*Web最適化
Coherence*Webは、WebLogicサーバーとCoherenceサーバー間のネットワークのパフォーマンスが向上するため、Exalogicシステム上でメリットがあります。ロックが無効なときに最適化セッション状態管理を有効にすることでネットワーク使用率を減らし、パフォーマンスをよくする拡張機能もあります(coherence.session.optimizeModifiedSessions=true)。Coherence*Webのコンテキスト・パラメータの詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。

より少ないJVMをより大きなヒープで使用することの検討

IMBプロトコルでは、より少ない待機時間を達成するためにより多くのCPU使用率が必要になります(特に低負荷時)。多数のJVM、より小さいヒープのJVM (12GB未満)または多数のJVMと小さいヒープを使用している場合、できるかぎりJVMの統合を検討してください。最大20GBまでの大きなヒープ・サイズは一般的で、アプリケーションとその許容範囲によってはそれよりも大きいヒープをガベージ・コレクションに使用できます。ヒープのサイズ設定の詳細は、「JVMのチューニング」を参照してください。

ヒュージ(ラージ)ページに対するアプリケーション・サポートの無効化

ヒュージ・ページ(ラージ・ページとも呼ばれます)のサポートは、Linux OSではデフォルトでExalogicノードで有効になっています。ただし、JVMの安定性の問題により、Javaアプリケーションではラージ・ページを有効にしないでください。たとえば、JVMを起動するときに-XX:+UseLargePagesオプションは使用しないでください。使用中のJVMのバージョンによっては、ラージ・ページがJVMでデフォルトで有効になることがあるため、-XX:-UseLargePagesを使用してそれらを明示的に無効にすることが最も安全な構成です。

注意:

ラージ・ページ・サポートに対する更新は、Exalogicの将来のリリースで予定されています。

信頼性のあるトランスポート・プロトコルの変更

Oracle Exalogicでは、Coherenceはその環境で使用可能な最も信頼性のあるトランスポートを自動的に選択します。デフォルトのCoherence設定では、SSLが有効でないかぎり、サービス通信(データ転送)およびクラスタ通信にInfiniBand Message Bus (IMB)を使用し、SSLが有効な場合はSDMBSを使用します。別のトランスポート・プロトコルを使用してパフォーマンスの改善を確認できます。ただし、プロトコルの変更を検討するのは、この項で前に説明した推奨事項に従った後のみにする必要があります。

注意:

デフォルトのトランスポート・プロトコルの明示的な設定が必要になる場合があるのは、Solaris Super Cluster環境のみです。推奨されるトランスポート・プロトコルはSDMBまたは(環境でサポートされている場合は) IMBになります。

次のトランスポート・プロトコルがExalogicで使用できます。

- datagram – UDPの使用を指定します。

- tmb – TCP Message Bus (TMB)プロトコルを指定します。TMBではTCP/IPのサポートが提供されます。

- tmbs – SSL対応TCP/IPメッセージ・バス・プロトコル。TMBSでは、SSLソケット・プロバイダの使用が必要です。『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- sdmb – Sockets Direct Protocol Message Bus (SDMB)を指定します。Sockets Direct Protocol (SDP)では、InfiniBandファブリック上でのストリーム接続のサポートが提供されます。SDPでは、既存のソケットベースの実装で透過的にInfiniBandを使用できます。

- sdmbs – SSL対応SDPメッセージ・バス。SDMBSでは、SSLソケット・プロバイダを使用する必要があります。『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- imb (Exalogicでのデフォルト) – InfiniBand Message Bus (IMB)。IMBは、TCMPがSSLで構成されていないかぎり、Exalogicシステムで自動的に使用されます。

すべてのクラスタ(ユニキャスト)通信に対して信頼性のあるトランスポートを構成するには、オペレーション・オーバーライド・ファイルを編集して、<unicast-listener>要素内に、プロトコルに設定されている<reliable-transport>要素を追加します。

注意:

デフォルトではすべてのサービスが構成済プロトコルを使用し、単一のトランスポート・インスタンスを共有します。一般的に、共有トランスポート・インスタンスは、サービス固有のトランスポート・インスタンスよりも少ないリソースを使用します。

<?xml version="1.0"?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<unicast-listener>
<reliable-transport
system-property="coherence.transport.reliable">imb
</reliable-transport>
</unicast-listener>
</cluster-config>
</coherence>

coherence.transport.reliableシステム・プロパティも信頼性のあるトランスポートを構成します。次に例を示します。

-Dcoherence.transport.reliable=imb

サービスに対して信頼性のあるトランスポートを構成するには、キャッシュ構成ファイルを編集して、スキーム定義内に、プロトコルに設定されている<reliable-transport>要素を追加します。次の例では、ExampleServiceと呼ばれるパーティション化されたキャッシュ・サービス・インスタンスに対して信頼性のあるトランスポートを設定する場合を示します。

注意:

サービスに信頼性のあるトランスポートを指定すると、<unicast-listener>要素によって定義された共有トランスポート・インスタンスではなく、サービス固有のトランスポート・インスタンスが使用されることになります。サービス固有のトランスポート・インスタンスは、パフォーマンスが高くなりますが、リソース消費量が増加するという代償があるため、厳選した優先度が高いサービスに対して慎重に使用する必要があります。一般的に、共有トランスポート・インスタンスでは、サービス固有のトランスポート・インスタンスよりもリソース消費量が少なくなります。

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">

<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>ExampleService</service-name>
<reliable-transport>imb</reliable-transport>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>

各サービス・タイプにも、それぞれ信頼性のあるトランスポートを設定するシステム・プロティがあります。このシステム・プロパティは、サービス・タイプのすべてのインスタンスに対して信頼性のあるトランスポートを設定します。システム・プロパティは次のとおりです。

- coherence.distributed.transport.reliable

- coherence.replicated.transport.reliable

- coherence.optimistic.transport.reliable

- coherence.invocation.transport.reliable

- coherence.proxy.transport.reliable

セキュリティの推奨事項

セキュリティ権限の確保

Coherenceの機能に最低限必要とされる権限セットは、security.policyファイル内で指定されています。これは、Coherenceインストールの一部として同梱されています。このファイルは、coherence/lib/security/security.policyにあります。Javaセキュリティ・マネージャを使用する場合は、Coherenceが正常に機能するように、これらの権限を付与する必要があります。

SSL要件に対する計画

Coherenceベースのアプリケーションは、必要に応じて様々なレベルのセキュリティを実装できます。このセキュリティには、クラスタ・メンバー間、およびCoherence*Extendクライアントとクラスタ間のSSLベースのセキュリティが含まれます。SSLが要件になる場合、信頼できる認証局によって検証および署名されたデジタル証明書がすべてのサーバーに用意されていることを確認します。また、そのデジタル証明書が、必要に応じてサーバーのキー・ストアと信頼ストアにインポートされていることも確認します。Coherence*Extendクライアントには、信頼キー・ストアが含まれている必要があります。このストアには、プロキシのデジタル証明書の署名に使用された認証局のデジタル証明書を格納します。SSLの設定手順の詳細は、Oracle Coherenceのセキュリティ保護を参照してください。

アプリケーション・インストゥルメンテーションの推奨事項

Javaベースの管理およびモニタリングのソリューションには、インストゥルメンテーション(バイトコード操作やClassLoader置換など)を使用しているものがあります。オラクル社は、過去に、そのようなソリューションに問題があることを見つけています。このようなソリューションは、主要なベンダーから現時点で問題が報告されていない場合でも慎重に使用してください。

Coherenceのモードおよびエディション

本番モードの選択

Coherenceは、評価モード、開発モードまたは本番モードで動作するように構成できます。これらのモードには機能に対するアクセス制限はありませんが、デフォルトの構成設定が一部異なります。たとえば開発モードでは、開発プロセスを簡略化するために、クラスタを高速起動できます。

開発モードは、開発やテストなどの本番前のあらゆるアクティビティに使用します。これは、開発ノードは本番ノードへの参加が制限されているために、重要な安全機能になります。開発モードは、デフォルトのモードです。本番モードは、Coherenceを本番環境で使用するときに明示的に指定する必要があります。本番モードにモードを変更するには、tangosol-coherence.xml (coherence.jar内にあります)を編集して、<license-mode>要素の値としてprodを入力します。次に例を示します。

...
<license-config>
...
<license-mode system-property="coherence.mode">prod</license-mode>
</license-config>
...

オペレーション・デプロイメント・ディスクリプタではなく、coherence.modeシステム・プロパティを使用して、ライセンス・モードを指定します。次に例を示します。

-Dcoherence.mode=prod

license-modeは、混合モードのクラスタリングを防ぐだけでなく、使用されるオペレーション・オーバーライド・ファイルを指定します。evalモードの場合は、tangosol-coherence-override-eval.xmlファイルが使用されます。devモードの場合は、tangosol-coherence-override-dev.xmlファイルが使用されます。また、tangosol-coherence-override-prod.xmlファイルは、prodモードが指定されている場合に使用されます。tangosol-coherence-override.xmlファイル(このファイルがcoherence.jarファイルの前に、クラスパスに含まれている場合)は、どのモードが選択されていても使用され、すべてのモード固有オーバーライド・ファイルをオーバライドします。

エディションの選択

注意:

エディションの切り替えは、ライセンス制限を実施しなくなりました。デフォルトの設定(GE)を変更しないでください。

クラスタ内のノードはすべて、同じライセンスのエディションとモードを使用する必要があります。本番環境では、すべてのクラスタ・メンバーに必要なライセンスをすべて取得するようにしてください。サーバーのハードウェア構成(プロセッサ・ソケット、プロセッサ・パッケージ、CPUコアなどの数やタイプ)は、Coherenceに付属するProcessorInfoユーティリティを使用して検証できます。次に例を示します。

java -cp coherence.jar com.tangosol.license.ProcessorInfo

ProcessorInfoプログラムの結果がライセンス構成と異なる場合は、プログラムの出力内容と実際の構成内容をサポート問題として送信してください。

デフォルトのエディションは、Grid Editionです。エディションを変更するには、オペレーション・オーバーライド・ファイルを編集して、<license-config>要素内に、表5-1 に定義されているエディション名を含む<edition-name>要素を追加します。次に例を示します。

...
<license-config>
<edition-name system-property="tangosol.coherence.edition">EE</edition-name>
</license-config>
...

オペレーション・デプロイメント・ディスクリプタではなく、coherence.editionシステム・プロパティを使用して、ライセンス・エディションを指定します。次に例を示します。

-Dcoherence.edition=EE

表5-1 Coherenceのエディション

値

Coherenceのエディション

互換性のあるエディション

GE

Grid Edition

RTC、DC

EE

Enterprise Edition

DC

SE

Standard Edition

DC

RTC

Real-Time Client

GE

DC

Data Client

GE、EE、SE

注意:

異なるエディションを実行しているクラスタ間は、Coherence*ExtendをData Clientとして使用して接続できます。

RTCノードでCoherence TCMPが使用されないようにする

Real-Timeクライアント・ノードは、Coherence TCMPまたはCoherence Extendを使用してクラスタに接続できます。Extendクライアントを使用することが目的の場合、クライアント側でTCMPを無効にして、必ずCoherence*Extendを使用してクラスタに接続するようにします。そうしないと、クライアントはクラスタのメンバーになります。TCMP通信を無効にする方法の詳細は、Oracle Coherence用のリモート・クライアントの開発を参照してください。

Coherenceオペレーション構成の推奨事項

オペレーション構成は、tangosol-coherence.xmlで定義されるクラスタ・レベル構成に関連するもので、次の項目が含まれます。

- クラスタとクラスタ・メンバーの設定

- ネットワーク設定

- 管理設定

- セキュリティ設定

通常、オペレーション構成はtangosol-coherence-override.xmlファイルを使用して構成します。オペレーション・オーバーライド・ファイルの指定方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

このファイルの内容は、多くの場合、開発環境と本番環境とで異なります。2つの環境には大きな相違があるため、ファイルの内容の相違は環境ごとに個別に管理することをお薦めします。本番オペレーション構成ファイルは、本番システムの動作を熟知したシステム管理者が保守する必要があります。

すべてのクラスタ・ノードは、同一のオペレーション構成オーバーライド・ファイルを使用する必要があり、ノード固有の値はシステム・プロパティを使用して指定する必要があります。システム・プロパティの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。集中型の構成ファイルは、各クラスタ・ノードのcoherence.overrideシステム・プロパティの値として、URLを指定することで保守およびアクセスできます。次に例を示します。

-Dcoherence.override=/net/mylocation/tangosol-coherence-override.xml

オーバーライド・ファイルには、変更するオペレーション要素のみを含める必要があります。さらに、id属性とsystem-property属性が要素に定義されている場合は、それらの属性を必ず含めます。

各オペレーション要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

Coherenceキャッシュ構成の推奨事項

キャッシュ構成は、キャッシュ・レベルの構成に関連するもので、次の内容が含まれます。

- キャッシュ・トポロジ(<distributed-scheme>、<near-scheme>など)

- キャッシュ容量(<high-units>)

- キャッシュ冗長性レベル(<backup-count>)

通常、キャッシュ構成はcoherence-cache-config.xmlファイルを使用して構成します。キャッシュ構成ファイルの指定方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

coherence.jarに含まれるデフォルトのcoherence-cache-config.xmlファイルは、サンプルとして提供されているもので、本番環境での使用には適しません。アプリケーション固有の定義には、必ずキャッシュ構成ファイルを使用してください。

すべてのクラスタ・ノードは、可能な場合は、同じキャッシュ構成ディスクリプタを使用する必要があります。集中型の構成ファイルは、各クラスタ・ノードのcoherence.cacheconfigシステム・プロパティの値として、URLを指定することで保守およびアクセスできます。次に例を示します。

-Dcoherence.cacheconfig=/net/mylocation/coherence-cache-config.xml

キャッシュは、部分的または完全なものとして分類できます。前者の場合、アプリケーションは、メモリー内にデータ・セット全体がロードされることを(予期しても)頼りにすることはありません。キャッシュ・ローダーやサイド・キャッシュ・パターンを使用するほとんどのキャッシャは部分キャッシュです。完全キャッシュでは、アプリケーションが正常に機能するためにキャッシュ内にデータ・セット全体が存在している必要があります(アプリケーションがキャッシュに対して主キー以外の問合せを発行していることが理由である場合が多い)。部分キャッシュでは、割り当てられたJVMヒープ・サイズに基づいてサイズを必ず制限してください。この制限により、アプリケーションがOutOfMemoryExceptionsエラーを起こさないようにします。キャッシュが満杯になるまでロードされることがないと予想できる場合にも、制限を設定して想定外の事態に備える必要があります。サイズ設定の推奨事項については、「JVMのチューニング」を参照してください。反対に、完全キャッシュに対してサイズ制限を設定した場合、正しくない結果になることがあります。

同じキャッシュ・サービス名に複数のキャッシュ・スキームを定義した場合、最初にロードされるスキームによってサービス・レベルのパラメータが決まることに注意する必要があります。特に、<distributed-scheme>の<partition-count>、<backup-count>および<thread-count>の各サブ要素は、同じサービスのすべてのキャッシュで共有されます。1つのサービスを定義して、それを各種のキャッシュ・スキームで継承することをお薦めします。キャッシュごとに異なる値の要素を定義する場合は、複数のサービスを構成してもかまいません。

パーティション・キャッシュの場合、Coherenceでは、キャッシュの構成やヒープ・サイズに関係なく、すべてのキャッシュ・サーバーに記憶域の役割が均等に割り当てられます。そのため、すべてのキャッシュ・サーバー・プロセスには同じヒープ・サイズを構成することをお薦めします。追加のリソースを使用するコンピュータには、コンピュータのリソースを効率的に利用するために、複数のキャッシュ・サーバーを使用できます。

パーティション・キャッシュ間の記憶域としての役割が均等になるようにするには、<distributed-scheme>要素の<partition-count>サブ要素に、予想されるキャッシュ・サーバー数の2乗以上の素数を設定する必要があります。

キャッシュ・ストアによってバッキングされるキャッシュでは、キャッシュ・ストアへのリクエストが入出力時にブロックされることがあるため、スレッド・プールを使用して親サービスを構成することをお薦めします。スレッド・プールは、キャッシュ・サーバーにおいてCPU集中型の操作(問合せ、集計、エントリ・プロセッサの処理など)を実行するキャッシュで使用することもお薦めします。プールを有効にするには、<distributed-scheme>要素の<thread-count>サブ要素を使用します。キャッシュ・ストアベース以外のキャッシュでは、スレッドを増やしてもパフォーマンスが向上する可能性がないため、スレッドは無効にしたままにします。

明示的に指定しないかぎり、いずれのクラスタ・ノードも記憶域が有効化されます。つまり、キャッシュ・サーバーとして機能します。したがって、本番環境で記憶域を有効化および無効化するノードを制御することが重要になります。記憶域を制御するには、coherence.distributed.localstorageシステム・プロパティをtrueまたはfalseに設定します。一般に、専用キャッシュ・サーバーの記憶域のみを有効にします。その他のクラスタ・ノードはすべて、記憶域を無効にするように構成します。これは、なんらかの作業のためにクラスタに参加して、その後でクラスタから離れるような短期間プロセスには特に重要です。このようなノードの記憶域が有効にしてあると、不要な再パーティション化が発生します。

各キャッシュ構成要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

大規模なクラスタ構成の推奨事項

- 16キャッシュ・サーバーを超えるラージ・クラスタ上の分散キャッシュで最適なパフォーマンスを確保するには、より多くのパーティションが必要です。デフォルトのパーティション数は257で、クラスタ内のキャッシュ・サーバーの数および各パーティションに格納されているデータの量に応じて増やす必要があります。パーティション数の構成および計算の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- 400クラスタ・メンバーを超えるラージ・クラスタ上でよりよいパフォーマンスを確保するには、最大パケット・サイズを増やす必要があります。デフォルトの1468をクラスタのサイズに応じて増やします。つまり、600ノードで構成されるクラスタでは、最大パケット・サイズを50%増加します。簡単な計算式では、ノードごとに4バイト、つまりmaximum_packet_size = maximum_cluster_size * 4Bとなります。最大パケット・サイズは、Coherenceオペレーション構成ファイルの一部として構成します。最大パケットサイズを構成する方法の詳細は、Oracle Coherenceでのアプリケーションの開発を参照してください。

- 何百ものクラスタ・メンバーで構成されるラージ・クラスタでは、マルチキャスト・クラスタ通信を有効にする必要があります。これを有効にすると、クラスタ全体の転送効率が高まります。クラスタ全体の転送はまれにしか発生しませんが、発生した場合、マルチキャストによる多大な効果を得ることができます。マルチキャストはオペレーション構成ファイルで有効に設定されます。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

停止検出の推奨事項

Coherenceの停止検出アルゴリズムは、2つ以上のクラスタ・ノード間で発生する持続的な接続の切断に基づいています。他のノードとの接続が失われたことを認識したノードは、どのような処理を行う必要があるかを他のクラスタ・ノードに相談します。

他のノードに相談しようとしたときに、このノードは他のどのノードとも通信できないことを知り、自身がクラスタから切り離されたものと推測します。このような状況は、ノードのネットワーク・アダプタのプラグを物理的に抜くことによって発生する可能性があります。このようなイベントでは、切り離されたノードは自身のクラスタ化サービスを再起動して、クラスタに参加しなおそうとします。

それでも他のクラスタ・ノードと接続できない場合、このノードはウェル・ノウン・アドレスの構成に応じて、新しい独立したクラスタを形成するか、さらに大規模なクラスタを探し続けます。いずれの場合も、接続が回復すると、切り離されたクラスタ・ノードは実行中のクラスタに再び参加します。クラスタに再び参加する過程で、ノードの以前のクラスタ状態は、保持していたキャッシュ・データも含めて破棄されます。これは、そのデータの所有権がクラスタ内の残りのノードによって(バックアップからリストアすることで)引き継がれているためです。

接続が失われた状態では、ノードが別のノードの状態を識別できないことは明らかです。単一ノードの場合、ローカル・ネットワーク・アダプタの障害も、ネットワーク全体のスイッチ障害もまったく同じに見えるため、これらの障害はいずれも前述のように同じ方法で処理されます。重要な違いは、スイッチ障害の場合、すべてのノードがクラスタに参加しなおそうとするため、クラスタ全体を再起動することと同じことになり、以前の状態とデータがすべて削除されるという点です。

すべてのデータが削除されることは望ましくないため、スイッチ障害時にこれを回避するには、追加の予防策をとる必要があります。次のオプションがあります。

- 検出間隔を増加する: クラスタは、TcpRingコンポーネントを使用する決定論的プロセス・レベルの障害検出と、IpMonitorコンポーネントを使用するハードウェア障害検出に依存しています。プロセス・レベルの検出は、数ミリ秒単位で実行され、ネットワークやマシンの障害は、デフォルトでは15秒以内に検出されます。これらの値を増やすと、クラスタは接続が回復するまでさらに長い時間待機するようになります。停止検出はデフォルトで有効になっていますが、<tcp-ring-listener要素で構成できます。障害検出の構成方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

- 外部ストレージにデータを維持する: 読取り/書込みバッキング・マップを使用すると、クラスタは外部ストレージにデータを維持するため、再起動後にそこからデータを取得できます。ライトビハインド(<read-write-backing-map-scheme>の<write-delay>サブ要素)が無効に設定されていれば、スイッチに障害が発生した場合にもデータは失われません。この対策のデメリットは、同期的に外部ストレージへ書込みを行うことで、キャッシュ更新操作の待機時間が増加し、外部ストレージがボトルネックになる可能性があることです。

- クラスタ・クォーラムを決定する: クラスタ・クォーラム・ポリシーでは、疑いのあるメンバーをクラスタ・サービスが終了するときに、クラスタに保持しておく必要があるクラスタ・メンバーの最小数を指定する必要があります。断続的なネットワーク停止時には、多くのクラスタ・メンバーがクラスタから削除されてしまう場合があります。クラスタ・クォーラムを使用すると、一定の数のメンバーが停止時に保持され、ネットワークの回復時に使用可能になります。クラスタ・クォーラムの構成方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

注意:

Windowsが切断時にネットワーク・アダプタを無効にしないようにするには、Windowsのレジストリに1:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableDHCPMediaSenseを追加して、DWORDに設定します。名前とは異なり、この設定は静的IPにも影響します。

- ネットワーク・レベルのフォルト・トレランスを追加する: クラスタのネットワーク・インフラストラクチャに冗長層を追加すると、個々のネットワーク装置に障害が発生しても、接続が遮断されることはありません。これは通常、コンピュータごとに2つ以上のネットワーク・アダプタを使用し、各アダプタを別々のスイッチに接続することで実現します。これはCoherenceの機能というよりは、むしろ基礎となるオペレーティング・システムまたはネットワーク・ドライバの機能です。Coherenceに必要な唯一の変更は、物理ネットワーク・アダプタではなく、仮想ネットワーク・アダプタにバインドするよう構成することです。この形式のネットワーク冗長性は、オペレーティング・システムによって様々な名称で呼ばれています。詳細は、Linuxのボンディング、SolarisのトランキングおよびWindowsのチーミングを参照してください。

第II部 高度な管理

第II部は、次の章で構成されます。

- キャッシュの永続化

- クラスタ間のキャッシュのレプリケート

6 キャッシュの永続化

この章では、Coherence永続性を使用して、キャッシュの内容を保存およびリカバリする手順について説明します。

この章の内容は次のとおりです。

- 永続性の概要

- 永続依存性

- オンデマンドでのキャッシュの永続化

- キャッシュのアクティブな永続化

- スナップショットを使用したキャッシュ・サービスの永続化

- スナップショットのアーカイブ

- アクティブ永続性モードの有効化

- 事前定義済の永続性環境の変更

- 永続性環境の作成

- アクティブな永続化に失敗した場合のレスポンスの作成

- 永続性リカバリのクォーラムの構成

- 永続性JMX通知のサブスクライブ

- 永続性の管理

- 一時的なものとしてのキャッシュの構成

永続性の概要

Coherence永続性は、Coherence分散キャッシュの永続性およびリカバリを管理する、一連のツールおよびテクノロジです。致命的障害や、計画的メンテナンスによるクラスタ再起動の後に迅速なリカバリができるように、キャッシュされたデータは保持されます。永続性とフェデレーテッド・キャッシュは必要に応じて共に使用できます。フェデレーテッド・キャッシュの使用の詳細は、「クラスタ間のキャッシュのレプリケート」を参照してください。

永続性モード

永続性は次の2つのモードで動作できます。

- オンデマンド永続性モード – キャッシュ・サービスは手動で永続化され、リクエスト時に永続性コーディネータを使用してリカバリされます。永続性コーディネータは、キャッシュ・サービスのスナップショットの作成、アーカイブおよびリカバリの操作を提供するMBeanインタフェースとして公開されています。

- アクティブ永続性モード – このモードでは、キャッシュの内容はすべてのミューテーションで自動的に永続化され、クラスタ/サービスの起動時に自動的にリカバリされます。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、オンデマンド・スナップショットを実行できます。

ディスク・ベースの永続記憶域

永続性では、データベースを永続性ストアに使用します。このデータベースは、パーティション・サービスのバッキング・マップ・パーティションの格納に使用されます。データベース・ファイルの場所は、各キャッシュ・サーバーのローカル・ディスクまたはストレージ・エリア・ネットワーク(SAN)の共有ディスクに格納できます。

注意:

データベース・ファイルは手動で編集しないでください。データベース・ファイルを編集すると、永続性エラーが発生する場合があります。

ローカル・ディスク・オプションにより、各クラスタ・メンバーが所有するサービス・パーティションの永続化データに各メンバーがアクセスできます。永続性は、キャッシュ・サーバー・ホスト・アドレスのリストを使用して、すべての記憶域メンバー間で調整されます。アドレス・リストにより、永続化されたすべてのパーティションがリカバリ中に検出されます。ローカル・ディスク記憶域では、高スループットと低遅延の記憶域メカニズムを提供しますが、パーティション・サービスでは、メモリー内バックアップ(ゼロより大きいbackup-count値)を利用して、マシンの安全性を保つ必要があります。

共有ディスク・オプションとアクティブ永続性モードの組合せにより、各クラスタ・メンバーがすべてのサービス・パーティションの永続化データにアクセスできます。共有ディスクを使用する利点は、記憶域が有効なすべてのメンバーが共有記憶域からパーティションをリカバリできるため、マシンの安全性を維持するために、パーティション・サービスでメモリー内バックアップ(backup-count値がゼロ以上)が不要になることです。メモリー内バックアップを無効にすると、ノードの障害発生時にリカバリの遅延を高める犠牲を払って、クラスタのキャッシュ容量が増加します。一般に、SANを使用すると、スループットと遅延が影響を受ける場合があるため、テストと監視を行うようにしてください。

注意:

サービスstatusHA統計では、メモリー内バックアップの置換えとして永続性が使用されている場合でも、バックアップ回数がゼロに設定されていると、ENDAGEREDステータスを示します。

ローカル・ディスクと共有ディスクの両方のアプローチでは、リカバリの開始前に永続性操作を実行するため必要な、クラスタ・メンバーの数を制御するクォーラム・ポリシーを利用できます。クォーラム・ポリシーにより、データ・リカバリが開始される前に、クラスタの起動の時間を考慮できます。

永続性構成

永続性は、Coherence構成ファイルを使用して宣言的に構成されるため、アプリケーション・コードを変更する必要はありません。オペレーション・オーバーライド・ファイルは、デフォルトの設定が受入れ可能でない場合は、基礎となる永続性実装の構成に使用されます。キャッシュ構成ファイルは、分散キャッシュでの永続性プロパティの設定に使用されます。

管理および監視

永続性は、MBean属性および操作を使用して監視および管理されます。スナップショットの作成やアーカイブなどの永続性操作は、PersistenceCoordinatorMBean MBeanを使用して実行されます。永続性の属性は、サービスの属性の一部に含まれ、ServiceMBean MBeanを使用して表示できます。

永続性の属性と統計は、persistenceおよびpersistence-detailsレポートで集計されます。永続性の統計は、Java VisualVMプラグインでも集計されます。どちらのツールでも、発生する可能性のあるリソースおよびパフォーマンス問題をトラブルシューティングできます。

永続依存性

永続性は、分散キャッシュに対してのみ使用可能で、集中パーティション割当て戦略を使用する必要があります。分散キャッシュは、デフォルトで集中パーティション割当て戦略を使用します。一般的ではありませんが、自律型またはカスタム・パーティション割当て戦略が使用されている可能性もあります。PartitionAssignment MBeanのStrategyName属性をチェックして、分散キャッシュに現在構成されている戦略を確認します。パーティション割当て戦略の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

オンデマンドでのキャッシュの永続化

キャッシュは、どの時点でもディスクに永続化が可能で、必要に応じてリカバリできます。

キャッシュをオンデマンドで永続化する手順:

1. 「スナップショットを使用したキャッシュ・サービスの永続化」で説明しているように、永続化コーディネータを使用して、スナップショットを作成、リカバリおよび削除します。

2. 必要に応じて、「事前定義済の永続性ディレクトリの変更」で説明しているように、永続性ファイルがディスクに書き込まれる場所を変更します。

3. 必要に応じて、「永続性リカバリのクォーラムの構成」で説明しているように、リカバリの実行に必要な記憶域メンバーの数を構成します。

キャッシュのアクティブな永続化

キャッシュは、ディスクに自動的に永続化され、クラスタの再起動時に自動的にリカバリされます。

キャッシュをアクティブに永続化する手順:

1. 「アクティブ永続性モードの有効化」で説明しているように、アクティブな永続性を有効にします。

2. 必要に応じて、「事前定義済の永続性ディレクトリの変更」で説明しているように、永続性ファイルがディスクに書き込まれる場所を変更します。

3. 必要に応じて、「アクティブな永続化に失敗した場合のレスポンスの変更」で説明しているように、アクティブな永続化に失敗した場合のサービスのレスポンス方法を変更します。

4. 必要に応じて、「永続性リカバリのクォーラムの構成」で説明しているように、リカバリの実行に必要な記憶域メンバーの数を構成します。

スナップショットを使用したキャッシュ・サービスの永続化

スナップショットは、PersistenceCoordinatorMBean MBeanを使用して手動で管理する必要がある、キャッシュ・サービスの内容のバックアップです。MBeanには、スナップショットを作成、リカバリおよび削除するための非同期操作が含まれます。スナップショットがリカバリされると、サービス全体がスナップショットの状態に自動的にリストアされます。MBeanを使用するには、JMXをクラスタに対して有効にする必要があります。JMX管理の有効化およびCoherence MBeanへのアクセスの詳細は、『Oracle Coherenceのマネージメント』を参照してください。

注意:

この項の手順は、JDK Java VisualVMツール用VisualVM-MBeansプラグインを使用して作成されています。Coherence-Java VisualVMプラグインをスナップショット操作の実行に使用することもできます。

スナップショットの作成

スナップショットを作成すると、オペレーション・オーバーライド構成ファイルの永続性環境定義内で指定したスナップショット・ディレクトリに、キャッシュ・サービスの内容が書き込まれます。

スナップショットを作成するには:

1. MBeanのリストから、「永続性」ノードを選択して展開します。

2. スナップショットを作成するサービスを展開し、PersistenceCoordinator MBeanを選択します。

3. 「操作」タブから、createSnapshot操作のフィールドにスナップショットの名前を入力します。

4. createSnapshotをクリックします。

スナップショットのリカバリ

スナップショットをリカバリすると、キャッシュ・サービスの内容がスナップショットからリストアされます。

スナップショットをリカバリする手順:

1. MBeanのリストから、「永続性」ノードを選択して展開します。

2. スナップショットをリカバリするサービスを展開し、PersistenceCoordinator MBeanを選択します。

3. 「操作」タブから、recoverSnapshot操作のフィールドにスナップショットの名前を入力します。

4. recoverSnapshotをクリックします。

操作が返されたら、永続性コーディネータでOperationStatusまたはIdle属性をチェックし、操作が完了した時間を確認します。スナップショットJMX通知をサブスクライブすることで、操作の完了時にアプリケーションに通知することができます。

スナップショットの削除

スナップショットを削除すると、スナップショットがスナップショット・ディレクトリから削除されます。キャッシュ・サービスは変更されないまま残ります。

スナップショットを削除する手順:

1. MBeanのリストから、「永続性」ノードを選択して展開します。

2. スナップショットを削除するサービスを展開し、PersistenceCoordinator MBeanを選択します。

3. 「操作」タブから、removeSnapshot操作のフィールドにスナップショットの名前を入力します。

4. removeSnapshotをクリックします。

スナップショットのアーカイブ

スナップショットは、中央の場所にアーカイブ可能で、後で取得またはリストアできます。スナップショットをアーカイブするには、アーカイブが格納されるディレクトリを定義し、アーカイブ・ディレクトリを使用するようにキャッシュ・サービスを構成する必要があります。アーカイブ操作は、PersistenceCoordinatorMBean MBeanを使用して実行されます。アーカイブの作成はスナップショットよりも低速ですが、スナップショットと異なり、アーカイブは移植可能です。

スナップショット・アーカイブ・ディレクトリの定義

スナップショットがアーカイブされるディレクトリは、ディレクトリ・スナップショット・アーカイバ定義を使用して、オペレーション・オーバーライド・ファイルに定義されます。必要に応じて、複数の定義を作成できます。

スナップショット・アーカイバ・ディレクトリを定義するには、<directory-archiver>要素を<snapshot-archivers>要素内に含めます。<archiver-directory>要素を使用して、スナップショット・アーカイブが格納されるディレクトリを入力します。id属性を使用して、一意の名前を定義に指定します。次に例を示します。

<snapshot-archivers>
<directory-archiver id="archiver1">
<archive-directory>/mydirectory</archive-directory>
</directory-archiver>
</snapshot-archivers>

ディレクトリ・スナップショット・アーカイバの指定

ディレクトリ・スナップショット・アーカイバを指定するには、分散スキーム内の永続性定義を編集して、オペレーション・オーバーライド構成ファイルに定義されるディレクトリ・スナップショット・アーカイバの名前を含めます。次に例を示します。

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<persistence>
<archiver>archiver1</archiver>
</persistence>
<autostart>true</autostart>
</distributed-scheme>

スナップショット・アーカイブ操作の実行

スナップショットのアーカイブは、PersistenceCoordinatorMBean MBeanを使用して手動で管理されます。MBeanには、スナップショットをアーカイブおよび取得するための非同期操作が含まれ、アーカイブをリストおよび削除するための操作も含まれます。

スナップショットのアーカイブ

スナップショットをアーカイブする手順:

1. MBeanのリストから、「永続性」ノードを選択して展開します。

2. スナップショットをアーカイブするサービスを展開し、PersistenceCoordinator MBeanを選択します。

3. 「操作」タブから、archiveSnapshot操作のフィールドにアーカイブの名前を入力します。

4. archiveSnapshotをクリックします。スナップショットは、オペレーション・オーバーライド構成ファイルに定義されるディレクトリ・アーカイバ定義に指定した場所にアーカイブされます。

永続性コーディネータでOperationStatus属性をチェックし、操作が完了した時間を確認します。

アーカイブされたスナップショットの取得

アーカイブされたスナップショットを取得する手順:

1. MBeanのリストから、「永続性」ノードを選択して展開します。

2. アーカイブされたスナップショットを取得するサービスを展開し、PersistenceCoordinator MBeanを選択します。

3. 「操作」タブから、retrieveArchivedSnapshot操作のフィールドに、アーカイブされたスナップショットの名前を入力します。

4. retrieveArchivedSnapshotをクリックします。アーカイブされたスナップショットは、ディレクトリ・アーカイバの場所からスナップショット・ディレクトリにコピーされ、サービス・バッキング・マップにリカバリできます。スナップショットのリカバリの詳細は、「スナップショットのリカバリ」を参照してください。

アーカイブされたスナップショットの削除

アーカイブされたスナップショットを削除する手順:

1. MBeanのリストから、「永続性」ノードを選択して展開します。

2. アーカイブされたスナップショットをパージするサービスを展開し、PersistenceCoordinator MBeanを選択します。

3. 「操作」タブから、removeArchivedSnapshot操作のフィールドに、アーカイブされたスナップショットの名前を入力します。

4. removeArchivedSnapshotをクリックします。アーカイブされたスナップショットは、アーカイブ・ディレクトリから削除されます。

アーカイブされたスナップショットのリスト

アーカイブされた現在のスナップショットのリストを取得する手順:

1. MBeanのリストから、「永続性」ノードを選択して展開します。

2. アーカイブされたスナップショットをリストするサービスを展開し、PersistenceCoordinator MBeanを選択します。

3. 「操作」タブから、listArchivedSnapshots操作をクリックします。アーカイブされたスナップショットのリストが返されます。

アーカイブされたスナップショット・ストアのリスト

アーカイブされたスナップショットの個別のストア、または一部をリストする手順:

1. MBeanのリストから、「永続性」ノードを選択して展開します。

2. アーカイブされたスナップショット・ストアをリストするサービスを展開し、PersistenceCoordinator MBeanを選択します。

3. 「操作」タブから、listArchivedSnapshotStores操作のフィールドに、アーカイブされたスナップショットの名前を入力します。

4. listArchivedSnapshotStoresをクリックします。アーカイブされたスナップショットのストアのリストが返されます。

カスタム・スナップショット・アーカイバの作成

デフォルトのディレクトリ・スナップショット・アーカイバ実装以外の方法を使用して、カスタム・スナップショット・アーカイバ実装を作成して、必要に応じてアーカイブを格納できます。たとえば、アーカイブを外部データベースに永続化し、Webサービスを使用してアーカイブをストレージ・エリア・ネットワークに格納したり、アーカイブをコンテンツ・リポジトリに格納したりできます。

カスタム・スナップショット・アーカイバ実装の作成

カスタム・スナップショット・アーカイバ実装を作成するには、AbstractSnapshotArchiverクラスを拡張するクラスを作成します。AbstractSnapshotArchiverの詳細は、Oracle Coherence Java APIリファレンスを参照してください。

カスタム・スナップショット・アーカイバ定義の作成

カスタム・スナップショット・アーカイバ定義を作成するには、<custom-archiver>要素を<snapshot-archivers>要素内に含め、id属性を使用して、一意の名前を定義に指定します。実装クラスの完全修飾名を含む<custom-archiver>要素内に<class-name>要素を追加します。次の例では、MyCustomArchiverという名前のカスタム実装の定義を作成します。

<snapshot-archivers>
<custom-archiver id="custom1">
<class-name>package.MyCustomArchiver</class-name>
</custom-archiver>
</snapshot-archivers>

アーカイバ・インスタンスの作成を処理するファクトリ・クラスが実装で使用されている場合は、<class-factory-name>要素を使用します。<method-name>要素を使用して、オブジェクトのインスタンス化を実行するファクトリ・クラスに静的ファクトリ・メソッドを指定します。次の例では、MyArchiverFactoryクラスのgetArchiverメソッドを使用して、スナップショット・アーカイバ・インスタンスを取得します。

<snapshot-archivers>
<custom-archiver id="custom1">
<class-factory-name>package.MyArchiverFactory</class-factory-name>
<method-name>getArchiver</method-name>
</custom-archiver>
</snapshot-archivers>

実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次の例では、UserNameパラメータをAdminに設定します。

<snapshot-archivers>
<custom-archiver id="custom1">
<class-name>package.MyCustomArchiver</class-name>
<init-params>
<init-param>
<param-name>UserName</param-name>
<param-value>Admin</param-value>
</init-param>
</init-params>
</custom-archiver>
</snapshot-archivers>

カスタム・スナップショット・アーカイバの指定

カスタム・スナップショット・アーカイバを指定するには、分散スキーム内の永続性定義を編集して、オペレーション・オーバーライド構成ファイルに定義されるカスタム・スナップショット・アーカイバの名前を含めます。次に例を示します。

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<persistence>
<archiver>custom1</archiver>
</persistence>
<autostart>true</autostart>
</distributed-scheme>

アクティブ永続性モードの有効化

アクティブ永続性は、すべてのサービスまたは特定のサービスに対して有効化できます。すべてのサービスでアクティブ永続性を有効にするには、coherence.distributed.persistence.modeシステム・プロパティをactiveに設定します。次に例を示します。

-Dcoherence.distributed.persistence.mode=active

値が指定されていない場合のデフォルト値は、on-demandです(オンデマンドの永続性を有効にします)。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、キャッシュのスナップショットを取得できます。

特定のサービスでアクティブ永続性を有効にするには、分散スキーム定義を変更し、<environment>要素を<persistence>要素内に含めます。<environment>要素の値をdefault-activeに設定します。次に例を示します。

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<persistence>
<environment>default-active</environment>
</persistence>
<autostart>true</autostart>
</distributed-scheme>

値が指定されていない場合のデフォルト値は、default-on-demandです(オンデマンドの永続性をサービスに対して有効にします)。

アクティブな永続性を使用する場合のパーティション数の変更

アクティブ永続性を使用している場合は、パーティション数を変更できません。サービスのパーティション数を変更すると、サービスの再起動時に、アクティブなすべてのデータが永続性のごみ箱に移動するため、元のパーティション数のリストア後にリカバリする必要があります。永続化されるデータは、同じパーティション数で実行されているサービスにのみリカバリできます。

アクティブ永続性が使用されている場合は、パーティション数が変更されていないことを確認します。パーティション数が変更されると、サービスの起動時に、次のようなメッセージが表示されます。

<Warning> (thread=DistributedCache:DistributedCachePersistence, member=1):
Failed to recover partition 0 from SafeBerkeleyDBStore(...); partition-count
mismatch 501(persisted) != 277(service); reinstate persistent store from
trash once validation errors have been resolved

このメッセージは、パーティション数の変更がサポートされておらず、現在アクティブなデータがごみ箱ディレクトリにコピーされたことを示しています。データをリカバリするには、次の手順を実行します。

1. クラスタ全体を停止します。

2. 各クラスタ・メンバーで影響を受けたクラスタとサービスで現在アクティブなディレクトリの内容を削除します。

3. アクティブなディレクトリへのサービスごとに、ごみ箱ディレクトリの内容を(再帰的に)コピーします。

4. パーティション数を元の値にリストアします。

5. クラスタを再起動します。

事前定義済の永続性環境の変更

オペレーション・デプロイメント・ディスクリプタには、事前定義済の2つの永続性環境定義が含まれます。

- default-active – アクティブ永続性が有効な場合に使用されます。

- default-on-demand – オンデマンド永続性が有効な場合に使用されます。

オペレーション・オーバーライド・ファイルまたはシステム・プロパティは、事前定義済の永続性環境のデフォルト設定のオーバーライドに使用されます。事前定義済の永続性環境には、次の構成があります。

<persistence-environments>
<persistence-environment id="default-active">
<persistence-mode>active</persistence-mode>
<active-directory
system-property="coherence.distributed.persistence.active.dir">
</active-directory>
<snapshot-directory
system-property="coherence.distributed.persistence.snapshot.dir">
</snapshot-directory>
<trash-directory
system-property="coherence.distributed.persistence.trash.dir">
</trash-directory>
</persistence-environment>
<persistence-environment-environment id="default-on-demand">
<persistence-mode>on-demand</persistence-mode>
<active-directory
system-property="coherence.distributed.persistence.active.dir">
</active-directory>
<snapshot-directory
system-property="coherence.distributed.persistence.snapshot.dir">
</snapshot-directory>
<trash-directory
system-property="coherence.distributed.persistence.trash.dir">
</trash-directory>
</persistence-environment>
</persistence-environments>

事前定義済の永続性ディレクトリの変更

事前定義済の永続性環境では、USER_HOMEディレクトリ内のcoherenceの名前のベース・ディレクトリを使用して、永続性ファイルを保存します。この場所には、アクティブな永続性ファイル、スナップショット永続性ファイルおよびごみ箱ファイルのディレクトリが含まれます。異なるローカル・ディレクトリまたはネットワーク上の共有ディレクトリに場所を変更できます。

注意:

永続性ディレクトリおよびファイル(meta.propertiesファイルを含む)は、手動で編集しないでください。ディレクトリおよびファイルを編集すると、永続性エラーが発生する場合があります。

永続性ファイルの事前定義済の場所を変更するには、<active-directory>、<snapshot-directory>および<trash-directory>要素を含めます(各要素は、永続性ファイルが保存されるそれぞれのディレクトリに設定されています)。次の例では、事前定義済のオンデマンド永続性環境を変更し、すべてのディレクトリの場所を/persistenceディレクトリに変更します。

<persistence-environments>
<persistence-environment id="default-on-demand">
<active-directory
system-property="coherence.distributed.persistence.active.dir">
/persistence/active</active-directory>
<snapshot-directory
system-property="coherence.distributed.persistence.snapshot.dir">
/persistence/snapshot</snapshot-directory>
<trash-directory
system-property="coherence.distributed.persistence.trash.dir">
/persistence</trash</trash-directory>
</persistence-environment>
</persistence-environments>

次のシステム・プロパティは、オペレーション・オーバーライド・ファイルを使用するかわりに、永続性ファイルの事前定義済の場所の変更に使用されます。

-Dcoherence.distributed.persistence.active.dir=/persistence/active
-Dcoherence.distributed.persistence.snapshot.dir=/persistence/snapshot
-Dcoherence.distributed.persistence.trash.dir=/persistence/trash

coherence.distributed.persistence.base.dirシステム・プロパティを使用して、デフォルトのディレクトリをUSER_HOMEディレクトリから変更します。

-Dcoherence.distributed.persistence.base.dir=persistence

永続性環境の作成

様々なキャッシュ・シナリオをサポートするために、複数の永続性環境をソリューションで定義および使用できます。永続性環境は、オペレーション・オーバーライド構成ファイルに定義され、キャッシュ構成ファイルの分散スキーム定義内で参照されます。

永続性環境の定義

永続性環境を定義するには、<persistence-environment>要素が含まれる<persistence-environments>要素を含めます。<persistence-environment>要素には、永続性環境の構成が含まれます。id属性を使用して環境に名前を付けます。id属性は、分散スキーム定義から永続性環境を参照する場合に使用されます。次の例では、environment1の名前の永続性環境を作成します。

<persistence-environments>
<persistence-environment id="enviornment1">
<persistence-mode></persistence-mode>
<active-directory></active-directory>
<snapshot-directory></snapshot-directory>
<trash-directory></trash-directory>
</persistence-environment>
</persistence-environments>

永続性モードの構成

永続性環境では、オンデマンドとアクティブの2つの永続性モードをサポートしています。オンデマンド永続性では、キャッシュ・サービスの永続化およびリカバリに永続性コーディネータを使用する必要があります。アクティブ永続性では、キャッシュ・サービスを自動的に永続化およびリカバリします。その場合も、永続性コーディネータをアクティブ永続性モードで使用して、キャッシュ・サービスを定期的に永続化できます。

永続性モードを構成するには、on-demandまたはactiveのいずれかに設定されている<persistence-mode>要素を含めます。値が指定されていない場合のデフォルト値は、on-demandです。次の例では、アクティブ永続性を構成します。

<persistence-environments>
<persistence-environment id="enviornment1">
<persistence-mode>active</persistence-mode>
<persistence-mode></persistence-mode>
<active-directory></active-directory>
<snapshot-directory></snapshot-directory>
<trash-directory></trash-directory>
</persistence-environment>
</persistence-environments>

永続性ディレクトリの構成

永続性環境では、キャッシュ・サービス・データをディスクに保存します。場所は必要に応じて構成可能で、ローカル・ドライブまたはネットワーク共有ドライブのいずれかにすることができます。ローカル・ドライブを構成している場合は、キャッシュ・サーバーで所有されるパーティションのみが、それぞれのローカル・ディスクに永続化されます。ネットワーク共有ドライブを構成している場合は、すべてのパーティションが同じ共有ディスクに永続化されます。

注意:

永続性ディレクトリおよびファイル(meta.propertiesファイルを含む)は、手動で編集しないでください。ディレクトリおよびファイルを編集すると、永続性エラーが発生する場合があります。

様々なディレクトリがアクティブ、スナップショットおよびごみ箱のファイルに使用され、それぞれ名前が付けられています。最上位のディレクトリのみを指定する必要があります。永続性ディレクトリを構成するには、<active-directory>、<snapshot-directory>および<trash-directory>要素を含めます(各要素は、永続性ファイルが保存されるディレクトリ・パスに設定されています)。値が指定されていない場合のデフォルト値は、USER_HOMEディレクトリです。次の例では、すべての永続性ファイルに/env1ディレクトリを構成します。

<persistence-environments>
<persistence-environment id="enviornment1">
<persistence-mode>on-demand</persistence-mode>
<active-directory>/env1</active-directory>
<snapshot-directory>/env1</snapshot-directory>
<trash-directory>/env1</trash-directory>
</persistence-environment>
</persistence-environments>

永続性環境を使用するためのキャッシュ・サービスの構成

キャッシュ・サービスで使用される永続化環境を変更するには、分散スキーム定義を変更し、<environment>要素を<persistence>要素内に含めます。<environment>要素の値を、オペレーション・オーバーライド構成ファイルに定義される永続性環境の名前に設定します。次に例を示します。

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<persistence>
<environment>environment1</environment>
</persistence>
<autostart>true</autostart>
</distributed-scheme>

アクティブな永続化に失敗した場合のレスポンスの作成

アクティブ永続性操作の実行中に発生する可能性のある永続性の失敗に対する、パーティション・キャッシュ・サービスのレスポンス方法を変更します。デフォルトのレスポンスは、サービスを即座に停止します。この動作は、永続性がサービスにとって重要な場合(例: キャッシュがデータ・バックアップの永続性に依存している場合)に最適です。ただし、永続性が重要でない場合は、サービスでリクエストを続行するように選択できます。

アクティブな永続化の失敗に対するサービスのレスポンスを変更するには、分散スキーム定義を編集して、<active-failure-mode>要素を<persistence>要素内に含め、値をstop-persistenceに設定します。値を指定しない場合は、デフォルト値(stop-service)が自動的に使用されます。次の例では、アクティブな永続化の失敗に対するレスポンスをstop-persistenceに変更します。

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<persistence>
<active-failure-mode>stop-persistence</active-failure-mode>
</persistence>
<autostart>true</autostart>
</distributed-scheme>

永続性リカバリのクォーラムの構成

永続性リカバリは、パーティション・クォーラム・ポリシーを使用して制御できます。クォーラムでは、リカバリの開始前に使用可能にする必要があるクラスタ記憶域メンバーの数を定義します。クォーラムを使用することで、クラスタの起動の時間を考慮し、少なすぎる記憶域メンバーが過負荷になることなく、パーティションを正常にリカバリできます。パーティション・クォーラム・ポリシーの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

リカバリ・クォーラムを構成するには、分散スキーム定義を変更し、<recover-quorum>要素を<partitioned-quorum-policy-scheme>要素内に含めます。<recover-quorum>要素値を、リカバリの開始前に使用可能にする必要がある記憶域メンバーの数に設定します。次に例を示します。

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<recover-quorum>2</recover-quorum>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>

共有ディスク・シナリオでは、すべてのパーティションが永続化され、単一の場所からリカバリされます。ただし、ローカル・ディスクのシナリオでは、各記憶域メンバーがローカル・ディスクからパーティションをリカバリします。ローカル・ディスク・ベースの記憶域でリカバリ・クォーラムを使用している場合は、永続性記憶域から孤立パーティションをリカバリするか、空のパーティションを割り当てる(永続性記憶域が使用できない、または失われている場合)必要があるクラスタに、記憶域が有効なホストのリストを定義する必要があります。

注意:

リカバリ・ホストを指定して、すべての永続化状態が使用可能になる前にリカバリが開始されないようにする必要があります。

アドレスのリストを定義するには、オペレーション・オーバーライド構成ファイルを編集し、<address>要素を使用してそれぞれ定義されたアドレスのリストが含まれる<address-provider>要素を含めます。id要素を使用して、アドレス・プロバイダ・リストに名前を付けます。id属性は、分散スキーム定義からリストを参照する場合に使用されます。次の例では、2つのメンバー・アドレスが含まれ、persistence_hostsという名前のアドレス・プロバイダ・リストを作成します。

<address-providers>
<address-provider id="persistence-host-list">
<address>HOST_NAME</address>
<address>HOST_NAME</address>
</address-provider>
</address-providers>

アドレス・プロバイダ・リストを参照するには、分散スキーム定義を変更し、<recovery-hosts>要素を<partitioned-quorum-policy-scheme>要素内に含め、値をアドレス・プロバイダ・リストの名前に設定します。次に例を示します。

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>Service1</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<partitioned-quorum-policy-scheme>
<recover-quorum>2</recover-quorum>
<recovery-hosts>persistence-hosts</recovery-hosts>
</partitioned-quorum-policy-scheme>
<autostart>true</autostart>
</distributed-scheme>

クォーラムが満たされていない場合、リカバリは続行されません。サービスまたはクラスタが停止している可能性があります。このシナリオをチェックするには、ServiceMBean MBeanのQuorumPolicy属性を表示し、recoverがアクションのリストに含まれているかどうかを確認します。

クラスタの起動後にデータがリカバリされていない場合は、次のログ・メッセージが表示され(新しいサービス・メンバーが起動するたび)、クォーラムが満たされていないことが示されます。

<Warning> (thread=DistributedCache:DistributedCachePersistence, member=1):
Action recover disallowed; all-disallowed-actions: recover(4)

クォーラムが満たされると、次のメッセージが表示されます。

<Warning> (thread=DistributedCache:DistributedCachePersistence, member=1):
All actions allowed

永続性JMX通知のサブスクライブ

PersistenceCoordinatorMBean MBeanには、アプリケーションが永続性操作の監視に使用できる一連の通知タイプが含まれます。通知タイプの詳細は、『Oracle Coherenceのマネージメント』を参照してください。

永続性JMX通知をサブスクライブするには、JMX NotificationListenerインタフェースを実装し、リスナーを登録します。次のコード・スニペットは、通知リスナーの登録を示します。サンプルのリスナー実装を含む完全な例は、Coherenceの例を参照してください。

...
MBeanServer server = MBeanHelper.findMBeanServer();
Registry registry = cluster.getManagement();
try
{
for (String sServiceName : setServices)
{
logHeader("Registering listener for " + sServiceName);
String sMBeanName = getMBeanName(sServiceName);
waitForRegistration(registry, sMBeanName);

ObjectName           oBeanName = new ObjectName(sMBeanName);
NotificationListener listener  = new
PersistenceNotificationListener(sServiceName);
server.addNotificationListener(oBeanName, listener, null, null);
f_mapListeners.put(oBeanName, listener);
}
...

永続性の管理

十分なディスク領域を確保し、永続性操作でキャッシュ操作に大幅な遅延が発生しないように、永続性を管理する必要があります。遅延はアクティブ永続性モードに特有で、永続性操作はキャッシュ操作とパラレルに実行されているため、キャッシュのパフォーマンスに影響する場合があります。

永続記憶域の計画

データの永続化には、十分な量のディスク領域が必要です。必要な量のキャッシュ・データを永続化するために、十分な領域がプロビジョニングされていることを確認します。次のガイドラインは、永続性のディスクのサイズを設定する場合に使用してください。

- アクティブ永続性のデータ記憶域の最小オーバーヘッドは、各サービスのパーティションごとに約30MBです。データ・アクセス・パターンおよびキーと値のサイズに応じて、ディスクの合計サイズは、シリアライズされたキーと値のサイズの5倍から15倍になることがあります。

- Coherence Java VisualVMプラグインと永続性レポートを使用して、領域可用性と使用状況を監視します。「永続記憶域の使用の監視」を参照してください。特に、ServiceMBean MBeanのPersistenceActiveSpaceUsed属性を使用して、各サービスとノードに使用される実際の永続性領域を監視します。

- 永続性データベース・オーバーヘッドの領域を計画します。

- すべてのパーティションは同じ場所に永続化されるため、記憶域に共有ディスクを使用する永続性構成では、キャッシュの可能な最大サイズを計画するようにしてください。たとえば、キャッシュの最大容量が8GBの場合、共有ディスクで少なくとも8GBの永続データとオーバーヘッドに対応できるようにする必要があります。

- ローカル・ディスクには、キャッシュ・サーバーで所有されるパーティションのみが永続化されるため、記憶域にローカル・ディスクを使用する永続性構成では、キャッシュ・サーバーの可能な最大キャッシュ容量を計画するようにしてください。たとえば、キャッシュ・サーバーの最大キャッシュ容量2GBの場合、ローカル・ディスクで少なくとも2GBの永続データとオーバーヘッドに対応できるようにする必要があります。

- アクティブとオンデマンドの両方の永続性が使用されている場合、追加の領域を計画します。キャッシュの各スナップショットにより、ディスク上の永続性ファイルのサイズが2倍になります。

- スナップショット・アーカイブに追加の領域を計画します。スナップショットの各アーカイブは、ディスク上のスナップショットのサイズよりわずかに少なくなります。

永続記憶域の使用の監視

永続記憶域を監視し、キャッシュ・データを永続化するための十分な領域がファイル・システムにあることを確認します。

Coherence-Java VisualVMプラグイン

Coherence-Java VisualVMプラグインの「永続性」タブを使用して、サービスでアクティブ永続性に使用されている領域の量を表示します。領域はバイトおよびメガバイトの両方の単位でレポートされます。このタブでは、サービスに使用可能な現在のスナップショットの現在の数がレポートされます。スナップショットの数を使用して、追加の領域使用を推定し、スナップショットを削除して空き領域を確保すべきかどうかを判断できます。

Coherenceレポート

永続性詳細レポート(persistence-detail.txt)を使用して、サービスでアクティブ永続性および永続性スナップショットの両方に使用されている領域の量を表示します。ディスク領域に使用可能な量もレポートされ、ディスクが容量に達しているかどうかを監視できます。

Coherence MBean

ServiceMBean MBeanの永続性の属性を使用して、サービスのすべての永続性記憶域の統計を表示します。MBeanには、アクティブ永続性および永続性スナップショットの両方の統計が含まれます。

永続性遅延の監視

アクティブ永続性を使用している場合の永続性の遅延を監視し、永続性操作によりキャッシュ操作が影響を受けていないことを確認します。高遅延は、ネットワークの問題により、共有ディスクへの永続性ファイルの書込みに遅延が発生しているか、ローカル・ディスク間の調整に遅延が発生していることを示す場合があります。

Coherence-Java VisualVMプラグイン

Coherence-Java VisualVMプラグインの「永続性」タブを使用して、永続性操作によりキャッシュ操作に加わっている遅延の量を表示します。時間はミリ秒でレポートされます。統計はサービスごとにレポートされ、すべての永続性操作の平均の遅延と最も高い遅延が表示されます。

Coherenceレポート

永続性詳細レポート(persistence-detail.txt)を使用して、永続性操作によりキャッシュ操作に発生している遅延の量を表示します。時間はミリ秒でレポートされます。サービスの各クラスタ・ノードのすべての永続性操作の平均の遅延と、最も高い遅延の統計が表示されます。統計を使用して、他のノードよりも高遅延が発生しているノードがないかを確認できます。

Coherence MBean

ServiceMBean MBeanの永続性の属性を使用して、永続性操作によりキャッシュ操作に発生している遅延の量を表示します。時間はミリ秒でレポートされます。サービスの各クラスタ・ノードのすべての永続性操作の平均の遅延と、最も高い遅延の統計が表示されます。統計を使用して、他のノードよりも高遅延が発生しているノードがないかを確認できます。

一時的なものとしてのキャッシュの構成

永続性が不要なキャッシュは、一時的なものとして構成できます。一時的なキャッシュは、永続性リカバリ操作ではリカバリされません。

注意:

永続性リカバリ操作では、キャッシュ・サービス全体が永続状態からリカバリされ、一時的なものとして構成されているキャッシュがリセットされます。

キャッシュは、分散スキーム定義の<backing-map-scheme>要素内の<transient>要素を使用して、一時的なものとして構成されます。ただし、永続性がサービスで常に有効になっているため、パラメータ・マクロを使用して、キャッシュごとに一時設定を構成します。次に例を示します。

<caching-scheme-mapping>
<cache-mapping>
<cache-name>nonPersistedCache</cache-name>
<scheme-name>distributed</scheme-name>
<init-params>
<init-param>
<param-name>transient</param-name>
<param-value>true</param-value>
</init-param>
</init-params>
</cache-mapping>
<cache-mapping>
<cache-name>persistedCache</cache-name>
<scheme-name>distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<distributed-scheme>
<scheme-name>distributed</scheme-name>
<service-name>DistributedService</service-name>
<backing-map-scheme>
<transient>{transient false}</transient>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>

注意:

<transient>要素のデフォルト値はfalseで、キャッシュ・データが永続化されることを示します。

7 クラスタ間のキャッシュのレプリケート

この章では、Coherenceフェデレーテッド・キャッシュ機能を使用して、クラスタ間でキャッシュ・データをレプリケートする手順について説明します。

この章の内容は次のとおりです。

- フェデレーテッド・キャッシュの概要

- フェデレーテッド・キャッシュの設定の一般的な手順

- フェデレーション参加者の定義

- フェデレーション参加者のデフォルト設定の変更

- レプリケーション・トポロジの理解

- レプリケーション・トポロジの定義

- フェデレーテッド・キャッシュ・スキームの定義

- フェデレーテッド・キャッシュとレプリケーション・トポロジの関連付け

- 宛先キャッシュのオーバーライド

- フェデレーション・サービス・リソースの使用の制限

- レプリケーション競合の解決

- フェデレーション通信への特定のネットワーク・インタフェースの使用

- フェデレーテッド接続のロード・バランシング

- フェデレーテッド・キャッシュの管理

フェデレーテッド・キャッシュの概要

フェデレーテッド・キャッシュ機能では、地理的に分散した複数のクラスタ間でキャッシュ・データを非同期にレプリケートします。キャッシュされたデータがクラスタ間でレプリケートされることで冗長性、オフサイト・バックアップ、および地理的に異なる場所にいるアプリケーション・ユーザーに対する複数アクセス・ポイントが提供されます。

複数レプリケーション・トポロジ

フェデレーテッド・キャッシュでは多彩なレプリケーション・テクノロジがサポートされています。これらには、アクティブ/アクティブ、アクティブ/パッシブ、ハブ/スポーク、集中型のレプリケーションなどがあります。トポロジでは、クラスタ間の一般的なレプリケーション戦略を定義し、様々なユース・ケースをサポートします。必要に応じて、カスタム・レプリケーション・トポロジを作成することもできます。

競合解決

フェデレーテッド・キャッシュでは、ローカルまたはリモートで格納されているキャッシュ・エントリの受入れ、拒否、または変更をアプリケーションで実行できます。競合解決は、レプリケーション・ルールを定義する場合に柔軟性を最大限に高めることができるアプリケーションです。

レプリケーション構成

フェデレーテッド・キャッシュは、Coherence構成ファイルを使用して構成されるため、アプリケーション・コードを変更する必要はありません。オペレーション・オーバーライド・ファイルは、フェデレーション参加者とフェデレーション・トポロジを構成するように使用されます。キャッシュ構成ファイルは、フェデレーテッド・キャッシュ・スキームの作成に使用されます。フェデレーテッド・キャッシュは、一種のパーティション・キャッシュ・サービスであり、フェデレーテッド・キャッシュ・サービス・インスタンスで管理されます。

管理および監視

フェデレーテッド・キャッシュは、FederationManagerMBean、DestinationMBean、OriginMBeanおよびTopologyMBean MBeanからの属性および操作を使用して管理されます。これらのMBeanにより、レプリケーションの開始と停止などの管理操作や、レプリケーション構成とパフォーマンス統計の監視を簡単に実行できます。これらの統計および操作の多くは、Coherence Java VisualVMプラグインから使用することもできます。

レプリケーション属性および統計は、federation-status、federation-originおよびfederation-destinationレポートで集計されます。レプリケーション統計は、Coherence Java VisualVMプラグインでも集計されます。どちらのツールでも、発生する可能性のあるリソースおよびパフォーマンス問題をトラブルシューティングできます。

また、分散キャッシュと同様、フェデレーテッド・サービスおよびキャッシュは、ServiceMBean MBeanおよびCacheMBean MBeanの属性操作、および関連するレポートとJava VisualVMプラグインのタブを使用して管理および監視できます。

フェデレーテッド・キャッシュの設定の一般的な手順

フェデレーテッド・キャッシュの設定手順:

1. フェデレーションに参加しているすべてのクラスタが稼働しており、各クラスタの少なくとも1つのキャッシュ・サーバーのアドレス(ホストおよびクラスタ・ポート)が判明していることを確認します。

2. 「フェデレーション参加者の定義」で説明しているように、フェデレーション内のクラスタ参加者のリストで、各クラスタを構成します。

3. 「レプリケーション・トポロジの定義」で説明しているように、クラスタ参加者間でデータがどのようにレプリケートされるかを指定するトポロジ定義で、各クラスタを構成します。

4. 「フェデレーテッド・キャッシュ・スキームの定義」で説明しているように、キャッシュ・データの格納に使用されるフェデレーテッド・キャッシュ・スキームで、各クラスタを構成します。

5. 「フェデレーテッド・キャッシュとレプリケーション・トポロジの関連付け」で説明しているように、定義済のレプリケーション・トポロジを使用するように、各クラスタでフェデレーテッド・キャッシュを構成します。

フェデレーション参加者の定義

フェデレーション内の各Coherenceクラスタは、フェデレーション参加者として定義する必要があります。フェデレーション参加者は、オペレーション・オーバーライド・ファイルに定義されます。フェデレーションの各クラスタのオペレーション・オーバーライド・ファイルには、フェデレーション対象の参加者のリストを含める必要があります。参加者のリストには、ローカル・クラスタ参加者およびリモート・クラスタ参加者を含める必要があります。

フェデレーション参加者を定義するには、<participants>要素内に任意の数の<participant>要素を含めます。<name>要素を使用して、参加者の名前を定義し、<remote-addresses>要素を使用して、参加者クラスタに配置されている少なくとも1つのキャッシュ・サーバーのソケット・アドレス(ホストおよびクラスタ・ポート)を定義します。次に例を示します。

<federation-config>
<participants>
<participant>
<name>LocalClusterA</name>
<remote-addresses>
<socket-address>
<address>192.168.1.7</address>
<port>7574</port>
</socket-address>
</remote-addresses>
</participant>
<participant>
<name>RemoteClusterB</name>
<remote-addresses>
<socket-address>
<address>192.168.10.16</address>
<port>7574</port>
</socket-address>
</remote-addresses>
</participant>
<participant>
<name>RemoteClusterC</name>
<remote-addresses>
<socket-address>
<address>192.168.19.25</address>
<port>7574</port>
</socket-address>
</remote-addresses>
</participant>
</participants>
</federation-config>

フェデレーション参加者のデフォルト設定の変更

フェデレーション参加者は、デフォルト設定をオーバーライドするように明示的に構成できます。各設定の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。デフォルト設定は次のとおりです。

- クラスタの起動時のクラスタ参加者のレプリケーションの状態

- 宛先クラスタに対する接続タイムアウト

- 宛先クラスタからの確認メッセージの送信タイムアウト

- レプリケートされたデータを送信するための最大帯域幅

- 単一のバッチでレプリケートされるエントリの最大数

- 参加者の場所のメタデータ

フェデレーション参加者のデフォルト設定を変更するには、クラスタのオペレーション・オーバーライド・ファイルを編集して、<participant>定義を変更します。必要に応じて、各設定の値を更新します。次に例を示します。

<participant>
<name>ClusterA</name>
<initial-action>start</initial-action>
<connect-timeout>2m</connect-timeout>
<send-timeout>6m</send-timeout>
<max-bandwidth>10</max-bandwidth>
<batch-size>25</batch-size>
<geo-ip>Philadelphia</geo-ip>
<remote-addresses>
<socket-address>
<address>localhost</address>
<port>7574</port>
</socket-address>
</remote-addresses>
</participant>

レプリケーション・トポロジの理解

レプリケーション・トポロジでは、フェデレーション内のクラスタ参加者間でデータがどのようにレプリケートおよび同期されるかを決定します。レプリケーション・トポロジでは、キャッシュ・データを送信できるクラスタ、キャッシュ・データを受信できるクラスタ、およびキャッシュ・データを再送信できるクラスタを定義します。これらのロールは明確に定義され、データが失われたり、複数回送信されないようにします。

サポートされるレプリケーション・トポロジは次のとおりです。

- アクティブ/パッシブ・トポロジ

- アクティブ/アクティブ・トポロジ

- ハブおよびスポーク・トポロジ

- 集中型レプリケーション・トポロジ

- カスタム・レプリケーション・トポロジ

アクティブ/パッシブ・トポロジ

アクティブ/パッシブ・トポロジは、アクティブ・クラスタからパッシブ・クラスタにデータをレプリケートする場合に使用されます。アクティブ・クラスタに置かれるデータは、パッシブ・クラスタにレプリケートされます。データがパッシブ・クラスタに置かれると、アクティブ・クラスタにはレプリケートされません。キャッシュ・データのコピーが読取り専用の操作に必要な場合、またはオフサイト・バックアップが必要な場合は、アクティブ/パッシブ・トポロジの使用を検討してください。

図7-1 に、アクティブ/パッシブ・トポロジの概念図を示します。

図7-1 アクティブ/パッシブ・トポロジ

アクティブ/アクティブ・トポロジ

アクティブ/アクティブ・トポロジは、アクティブ・クラスタ間でデータをレプリケートする場合に使用されます。あるアクティブ・クラスタ内に配置されるデータは、別のアクティブ・クラスタでレプリケートされます。アクティブ/アクティブ・トポロジにより、キャッシュ・データは常にクラスタ間で同期されます。地理的に分散した複数の場所のアプリケーションからローカル・クラスタ・インスタンスにアクセスできるようにするには、アクティブ/アクティブ・トポロジの使用を検討してください。

図7-2 に、アクティブ/アクティブ・トポロジの概念図を示します。

図7-2 アクティブ/アクティブ・トポロジ

ハブおよびスポーク・トポロジ

ハブおよびスポーク・トポロジは、単一のハブ・クラスタから複数のスポーク・クラスタにデータをレプリケートする場合に使用されます。ハブ・クラスタはデータの送信のみ可能で、スポーク・クラスタはデータの受信のみ可能です。地理的に分散したクラスタの複数のコピーが必要な場合は、ハブおよびスポーク・トポロジの使用を検討してください。各スポーク・クラスタは読取り専用を実行するためにローカル・アプリケーションで使用できます。

図7-3 に、ハブおよびスポーク・トポロジの概念図を示します。

図7-3 ハブおよびスポーク・トポロジ

集中型レプリケーション・トポロジ

集中型レプリケーション・トポロジは、単一のハブから複数のリーフ・クラスタにデータをレプリケートする場合に使用されます。さらに、各リーフでは、データをハブ・クラスタに送信可能で、ハブ・クラスタは、データを他のすべてのリーフ・クラスタに再送信する(繰り返す)ことができます。地理的に分散した複数の場所のアプリケーションからローカル・クラスタ・インスタンスにアクセスできるようにするには、集中型レプリケーション・トポロジの使用を検討してください。

図7-4 に、集中型レプリケーション・トポロジの概念図を示します。

図7-4 集中型レプリケーション・トポロジ

カスタム・レプリケーション・トポロジ

カスタム・レプリケーション・トポロジは、自由形式のトポロジの作成に使用されます。クラスタはグループに編成され、各クラスタはグループ内のロールで指定されます。ロールには、送信者、受信者またはリピータが含まれます。送信者の参加者は、ローカル・クラスタ上で発生している変更のレプリケートのみが可能です。リピータは、ローカル・クラスタの変更および他の参加者から受信した変更の両方をレプリケートします。グループ内の他のクラスタにデータをレプリケートできるのは、送信者およびリピータのクラスタのみです。事前定義済のレプリケーション・トポロジでキャッシュのフェデレーション要件に対応できない場合は、カスタム・レプリケーション・トポロジの作成を検討してください。

図7-5 に、1つの予想される構成のカスタム・レプリケーション・トポロジの概念図を示します。

図7-5 カスタム・レプリケーション・トポロジ

レプリケーション・トポロジの定義

レプリケーション・トポロジは、<federation-config>要素内のオペレーション・オーバーライド・ファイルに定義されます。使用するレプリケーション・トポロジが不明の場合は、この項の手順を完了する前に、「レプリケーション・トポロジの理解」を参照してくだい。

トポロジ定義には、トポロジで各クラスタ参加者が実行するレプリケーション・ロールが含まれます。複数のトポロジを定義可能で、参加者を複数のトポロジの一部にすることができます。参加者間でデータが予想通りにレプリケートされるようにするには、対応するレプリケーション・トポロジ定義がフェデレーション内の各クラスタに必要です。

注意:

トポロジが定義されていない場合、すべての参加者はアクティブ/アクティブ・トポロジ内にあると見なされます。

この項には次のトピックが含まれます:

- アクティブ/パッシブ・トポロジの定義

- アクティブ/アクティブ・トポロジの定義

- ハブおよびスポーク・トポロジの定義

- 集中型レプリケーション・トポロジの定義

- カスタム・トポロジの定義

アクティブ/パッシブ・トポロジの定義

アクティブ/パッシブ・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<active-passive>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<active>要素を使用して、アクティブ参加者を定義し、<passive>要素を使用して、パッシブ参加者を定義します。次に例を示します。

<federation-config>
...
<topology-definitions>
<active-passive>
<name>MyTopology</name>
<active>LocalClusterA</active>
<passive>RemoteClusterB</passive>
</active-passive>
</topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAでの変更はRemoteClusterBにレプリケートされますが、RemoteClusterBでの変更はLocalClusterAにレプリケートされません。

アクティブ/アクティブ・トポロジの定義

アクティブ/アクティブ・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<active-passive>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<active>要素を使用して、アクティブ参加者を定義します。次に例を示します。

<federation-config>
...
<topology-definitions>
<active-passive>
<name>MyTopology</name>
<active>LocalClusterA</active>
<active>RemoteClusterB</active>
</active-passive>
</topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAでの変更はRemoteClusterBにレプリケートされ、RemoteClusterBでの変更はLocalClusterAにレプリケートされます。

ハブおよびスポーク・トポロジの定義

ハブおよびスポーク・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<hub-spoke>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<hub>要素を使用して、ハブ参加者を定義し、<spoke>要素を使用して、スポーク参加者を定義します。次に例を示します。

<federation-config>
...
<topology-definitions>
<hub-spoke>
<name>MyTopology</name>
<hub>LocalClusterA</hub>
<spoke>RemoteClusterB</spoke>
<spoke>RemoteClusterC</spoke>
</hub-spoke>
</topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAでの変更はRemoteClusterBおよびRemoteClusterCにレプリケートされますが、RemoteClusterBおよびRemoteClusterCでの変更はLocalClusterAにレプリケートされません。

集中型レプリケーション・トポロジの定義

集中型レプリケーション・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<central-replication>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<hub>要素を使用して、ハブ参加者を定義し、<leaf>要素を使用して、リーフ参加者を定義します。次に例を示します。

<federation-config>
...
<topology-definitions>
<central-replication>
<name>MyTopology</name>
<hub>LocalClusterA</hub>
<leaf>RemoteClusterB</leaf>
<leaf>RemoteClusterC</leaf>
</central-replication>
</topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAでの変更はRemoteClusterBおよびRemoteClusterCにレプリケートされます。RemoteClusterBまたはRemoteClusterCでの変更はLocalClusterAにレプリケートされ、他のクラスタ参加者にデータが再送信されます。

カスタム・トポロジの定義

カスタム・トポロジを構成するには、オペレーション・オーバーライド・ファイルを編集して、<custom-topology>要素を<topology-definitions>要素内に含めます。<name>要素を使用して、このトポロジの参照に使用される名前を含めます。<groups>要素内の<group>要素を使用して、グループ内の各参加者のロール(送信者、リピータまたは受信者)を定義します。次に例を示します。

<federation-config>
...
<topology-definitions>
<custom-topology>
<name>MyTopology</name>
<groups>
<group>
<sender>LocalClusterA</sender>
<sender>RemoteClusterB</sender>
</group>
<group>
<repeater>LocalClusterA</repeater>
<receiver>RemoteClusterC</receiver>
</group>
</groups>
</custom-topology>
</topology-definitions>
</federation-config>

このトポロジでは、LocalClusterAまたはRemoteClusterBの変更はRemoteClusterCにレプリケートされます。RemoteClusterCでの変更は、LocalCluster AまたはRemoteClusterBにレプリケートされません。

フェデレーテッド・キャッシュ・スキームの定義

<federated-scheme要素は、フェデレーテッド・キャッシュの定義に使用されます。キャッシュ構成ファイルで、フェデレーテッド・キャッシュを必要な数だけ定義できます。<federated-scheme要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

クラスタ内の各参加者では、それぞれのキャッシュ構成ファイルにフェデレーテッド・キャッシュ・スキームを含める必要があります。すべての参加者のフェデレーテッド・キャッシュは、同じフェデレーテッド・サービス・インスタンスで管理する必要があります。サービスは、<service-name>要素を使用して指定されます。

例7-1 では、サービス・インスタンス名と同じスキーム名およびfederatedとして、federatedを使用する基本的なフェデレーテッド・キャッシュ・スキームを定義します。スキームは、キャッシュ名exampleにマップされます。<autostart>要素をtrueに設定すると、キャッシュ・サーバー・ノード上でフェデレーテッド・キャッシュ・サービスを開始します。

例7-1 フェデレーテッド・キャッシュ定義のサンプル

<?xml version="1.0" encoding="windows-1252"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>example</cache-name>
<scheme-name>federated</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</federated-scheme>
</caching-schemes>
</cache-config>

フェデレーテッド・キャッシュとレプリケーション・トポロジの関連付け

フェデレーテッド・キャッシュは、フェデレーション参加者にレプリケートされるデータのレプリケーション・トポロジに関連付ける必要があります。トポロジは、オペレーション・オーバーライド・ファイルに定義され、フェデレーテッド・キャッシュ定義から参照されます。レプリケーション・トポロジの定義の詳細は、「レプリケーション・トポロジの定義」を参照してください。

注意:

トポロジが定義されていない場合(すべての参加者がアクティブ/アクティブ・トポロジにいると見なされる)、またはトポロジが1つしか定義されていない場合は、トポロジ名をフェデレーテッド・スキーム定義に指定する必要はありません。

フェデレーテッド・キャッシュをレプリケーション・トポロジに関連付けるには、<topology>要素を<topologies>要素内に含め、<name>要素を使用して、オペレーション・オーバーライド・ファイルに定義されているレプリケーション・トポロジを参照します。次に例を示します。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<topologies>
<topology>
<name>MyTopology</name>
</topology>
</topologies>
</federated-scheme>

フェデレーテッド・キャッシュは、複数のレプリケーション・トポロジに関連付けることができます。次に例を示します。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<topologies>
<topology>
<name>MyTopology1</name>
</topology>
<topology>
<name>MyTopology2</name>
</topology>
</topologies>
</federated-scheme>

宛先キャッシュのオーバーライド

デフォルトでは、フェデレーション・サービスは、ローカル参加者に定義されているのと同じキャッシュ名を使用して、リモート参加者のキャッシュにデータをレプリケートします。必要に応じて、異なるリモート・キャッシュを明示的に指定できます。ただし、その場合も、各キャッシュは同じフェデレーション・サービスで管理する必要があり、キャッシュで<service-name>要素の同じ値を指定する必要があります。

デフォルトの宛先キャッシュをオーバーライドするには、<cache-name>要素を含め、リモート参加者の宛先キャッシュの名前に値を設定します。次に例を示します。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<topologies>
<topology>
<name>MyTopology</name>
<cache-name>fed-remote</cache-name>
</topology>
</topologies>
</federated-scheme>

フェデレーション・サービス・リソースの使用の制限

フェデレーション・サービスでは、内部キャッシュおよびジャーナルを使用して、レプリケーション中にキャッシュを保持します。内部キャッシュでは、レプリケートされるエントリの量とサイズに応じて、クラスタ・ノードで使用可能なすべてのリソースを消費できます。これにより、フェデレーションのすべてのクラスタが影響を受ける場合があります。このようなシナリオから保護するために、内部キャッシュのサイズを制限するように内部キャッシュを構成できます。上限に到達すると、クラスタ参加者は別のクラスタ参加者によってエラー状態にされ、参加者へのレプリケーションが停止します。

フェデレーション・サービス・リソースの使用を制限するには、フェデレーテッド・キャッシュ・スキームを編集して、<journalcache-highunits>要素を、上限に到達するまで内部キャッシュで許可されるキャッシュ・エントリの数に設定します。次に例を示します。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<journalcache-highunits>1000</journalcache-highunits>
</federated-scheme>

レプリケーション競合の解決

同じエントリの同時更新の間で発生する可能性のある競合の解決に必要となる、カスタム・ロジックをアプリケーションで実装できます。競合を解決するには、は、インターセプタを作成して、フェデレーション固有のイベント・タイプを取得し、必要に応じてカスタム・ロジックを実行します。競合解決ではCoherenceライブ・イベントを使用します(ライブ・イベントの使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照)。

フェデレーテッド接続イベントの処理

フェデレーテッド接続イベント(FederatedConnectionEvent)は、参加者とフェデレーテッド・サービス間の通信を表します。イベント・タイプには、CONNECTING、DISCONNECTED、BACKLOG_EXCESSIVE、BACKLOG_NORMALおよびERRORイベントが含まれます。フェデレーテッド接続イベントの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

フェデレーテッド接続イベントを処理する手順:

1. イベント・インターセプタを作成して、必要なイベント・タイプを処理し、必要に応じてカスタム・ロジックを実装します。イベント・インターセプタの作成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次の例に、ERRORイベントを処理し、参加者名をコンソールに出力するインターセプタを示します。

注意:

フェデレーテッド接続イベントは、イベントが発生したスレッドと同じスレッド上で発生します。これらのイベントを処理するインターセプタでは、ブロッキング操作を実行しないでください。

package com.examples

import com.tangosol.internal.federation.service.FederatedCacheServiceDispatcher;
import com.tangosol.net.events.EventDispatcher;
import com.tangosol.net.events.EventDispatcherAwareInterceptor;
import com.tangosol.net.events.federation.FederatedConnectionEvent;
import com.tangosol.net.events.annotation.Interceptor;
import java.util.Map;

@Interceptor(identifier = "testConnection", federatedConnectionEvents =
FederatedConnectionEvent.Type.ERROR)
public class ConnectionInterceptorImp implements
EventDispatcherAwareInterceptor<FederatedConnectionEvent>
{
@Override
public void onEvent(FederatedConnectionEvent event)
{
System.out.println("Participant in Error: " + event.getParticipantName());
}

@Override
public void introduceEventDispatcher(String sIdentifier, EventDispatcher
dispatcher)
{
if (dispatcher instanceof FederatedCacheServiceDispatcher)
{
dispatcher.addEventInterceptor(sIdentifier, this);
}
}
}

2. フェデレーテッド・キャッシュ・スキームにインターセプタを登録します。イベント・インターセプタの登録の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次に例を示します。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<interceptors>
<interceptor>
<name>MyInterceptor</name>
<instance>
<class-name>
com.examples.ConnectionInterceptorImp
</class-name>
</instance>
</interceptor>
</interceptors>
<topologies>
<topology>
<name>MyTopology</name>
</topology>
</topologies>
</federated-scheme>

3. インターセプタ実装が実行時にクラスパス上にあることを確認します。

フェデレーテッド変更ベントの処理

フェデレーテッド変更イベント(FederatedChangeEvent)は、ローカル参加者で発生するすべての変更のトランザクション・ビューを表します。単一のパーティションに属するすべての変更は、単一のFederatedChangeEventオブジェクトで取得されます。イベントから、キャッシュ名によって索引付けされるChangeRecordオブジェクトのマップが提供され、変更に関連する参加者名にもアクセスできます。ChangeRecordマップを通して、変更の受入れ、値の変更、または変更の拒否が可能です。オブジェクトでは、PofExtractorおよびPofUpdater APIを使用して、POFエントリの抽出または更新するための方法が提供されます。

イベント・タイプには、COMMITTING_LOCAL、COMMITTING_REMOTEおよびREPLICATINGイベントが含まれます。REPLICATINGイベントは、ローカル・エントリがリモート参加者にレプリケートされる前にディスパッチされます。このイベントは、エントリへの変更の事前レプリケートを実行する場合に使用されます。REPLICATINGイベント・インターセプタで実行される変更は、ローカル・キャッシュに反映されません。COMMITTING_LOCALイベントは、エントリがローカルに挿入される前にディスパッチされます。これは、ローカル競合の解決用に設計されています。COMMITTING_REMOTEイベントは、他の参加者からのエントリがローカルに挿入される前にディスパッチされます。これは、レプリケートするエントリとローカル・エントリ間の競合の解決用に設計されています。COMMITTING_LOCALおよびCOMMITTING_REMOTEイベントを処理して実行される変更は、ローカル参加者のキャッシュに反映されます。

注意:

- アクティブ/アクティブ・フェデレーション・トポロジでは、COMMITTING_REMOTEイベントの処理時にエントリに加えられた変更は、元の参加者に返送されます。これにより、サイクル・ループが発生する場合があり、アクティブ参加者間で変更がループし続けます。

- COMMITTING_LOCALイベントを取得するインターセプタは、パッシブ・スポーク参加者ではコールされません。

- 統合操作は、フェデレーション変更イベントには含まれません。

フェデレーテッド変更イベントを処理する手順:

1. イベント・インターセプタを作成して、必要なイベント・タイプを処理し、必要に応じてカスタム・ロジックを実装します。イベント・インターセプタの作成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次の例に、REPLICATINGイベントを処理し、エントリがレプリケートされる前にキー名を割り当てるインターセプタを示します。

package com.examples

import com.tangosol.coherence.federation.events.AbstractFederatedInterceptor;
import com.tangosol.coherence.federation.ChangeRecord;
import com.tangosol.coherence.federation.ChangeRecordUpdater;
import com.tangosol.net.events.annotation.Interceptor;
import com.tangosol.net.events.federation.FederatedChangeEvent;

@Interceptor(identifier = "yourIdentifier", federatedChangeEvents =
FederatedChangeEvent.Type.REPLICATING)
public static class MyInterceptor extends
AbstractFederatedInterceptor<String, String>
{
public ChangeRecordUpdater getChangeRecordUpdater()
{
return updater;
}

public class ChangeRecordUpdate implements ChangeRecordUpdater<String, String>
{
@Override
public void update(String sParticipant, String sCacheName,
ChangeRecord<String, String> record)
{
if (sParticipant.equals("NewYork") && (record.getKey()).equals("key"))
{
record.setValue("newyork-key");
}
}
}

private ChangeRecordUpdate updater = new ChangeRecordUpdate();
}

2. フェデレーテッド・キャッシュ・スキームにインターセプタを登録します。イベント・インターセプタの登録の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。次に例を示します。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<interceptors>
<interceptor>
<name>MyInterceptor</name>
<instance>
<class-name>
com.examples.MyInterceptor
</class-name>
</instance>
</interceptor>
</interceptors>
<topologies>
<topology>
<name>MyTopology</name>
</topology>
</topologies>
</federated-scheme>

3. インターセプタ実装が実行時にクラスパス上にあることを確認します。

フェデレーション通信への特定のネットワーク・インタフェースの使用

フェデレーション通信は、クラスタ通信に使用されるインタフェースと異なるネットワーク・インタフェースを使用するように構成できます。

異なるネットワーク構成をフェデレーション通信に使用する手順:

1. 各クラスタ参加者でオペレーション・オーバーライド・ファイルを編集して、対象のネットワーク・インタフェースにバインドされる個別のIPアドレスとポートのNameServiceアドレスを定義する<address-provider>要素を含めます。次に例を示します。

<cluster-config>
<address-providers>
<address-provider id="NameServiceAddress">
<socket-address>
<address system-property="coherence.nameservice.ip">
192.168.1.5</address>
<port system-property="coherence.nameservice.port">
10100</port>
</socket-address>
</address-provider>
</address-providers>
</cluster-config>

2. 参加者定義を変更して、リモート・アドレスを使用します。次に例を示します。

<federation-config>
<participants>
<participant>
<name>LocalClusterA</name>
<remote-addresses>
<address-prover>NameServiceAddress</address-provider>
</remote-addresses>
</participant>
...

3. クラスタメンバーの起動時(前述の例のLocalClusterA参加者)に、coherence.nameservice.addressproviderシステム・プロパティを使用して、ネーム・サービスのアドレス・プロバイダ定義を参照します。次に例を示します。

-Dcoherence.nameservice.addressprovider=NameServiceAddress

フェデレーテッド接続のロード・バランシング

フェデレーテッド・サービス・メンバー間の接続はロード・バランシングされます。デフォルトでは、接続を利用率の低いフェデレーテッド・サービス・メンバーに分散するフェデレーテッド・ベースの戦略が使用されます。必要に応じてカスタムの戦略の作成や、デフォルトの戦略の変更が可能です。また別の戦略として、アドレス・プロバイダ実装を作成するか、フェデレーテッド・サービス・メンバーへの接続のランダム化によってクライアントベースのロード・バランシングの戦略を実装できます。ランダム化のアプローチによってもたらされるバランシングは、フェデレーテッド・ベースのロード・バランシングと比べて最小限にとどまります。

フェデレーテッド・サービス・メンバー間の接続は、既存の接続数および受信メッセージのバックログに基づいて、フェデレーテッド・サービス・メンバー間で均等に分散されます。一般に、このアルゴリズムでは、最適なロード・バランシング戦略が提供されます。ただし、必要に応じて、異なるロード・バランシング戦略の実装を選択することもできます。

フェデレーション・ベースのロード・バランシングの使用

フェデレーション・ベースのロード・バランシングは、接続を複数の同じフェデレーション・サービスのメンバーで調整するデフォルトの戦略です。この戦略では、既存の接続数および受信メッセージのバックログに基づいて、フェデレーテッド・サービス・メンバー間で接続を均等に分散します。

フェデレーション・ベースのロード・バランシング戦略は、federationに設定された<load-balancer>要素を使用して、<federated-scheme>定義内に構成されます。わかりやすいように、次の例ではこの戦略を明示的に指定しています。ただし、戦略が指定されていない場合も、この戦略がデフォルトで使用されるため、フェデレーテッド・スキーム定義では必須ではありません。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<load-balancer>federation</load-balancer>
<topologies>
<topology>
<name>MyTopology</name>
</topology>
</topologies>
</federated-scheme>

カスタムのフェデレーション・ベース・ロード・バランシングの戦略の実装

com.tangosol.coherence.net.federationパッケージには、フェデレーテッド・サービスのメンバー間でクライアントの負荷を調節するために使用するAPIが含まれています。この項で説明するフェデレーテッド・ベースのロード・バランシングAPIの使用方法の詳細は、Oracle Coherence Java APIリファレンスを参照してください。

カスタムの戦略では、FederatedServiceLoadBalancerインタフェースを実装する必要があります。必要に応じて新規の戦略を作成するか、デフォルトの戦略(DefaultFederatedServiceLoadBalancer)を拡張または変更できます。

カスタムのフェデレーション・ベースのロード・バランシング戦略を有効にするには、フェデレーテッド・スキームを編集して、<instance>サブ要素を<load-balancer>内に含め、FederatedServiceLoadBalancerインタフェースを実装するクラスの完全修飾名を指定します。次の例では、MyFederationServiceLoadBalancerクラスに実装されているカスタムのフェデレーション・ベースのロード・バランシング戦略を有効します。

...
<load-balancer>
<instance>
<class-name>package.MyFederationServiceLoadBalancer</class-name>
</instance>
</load-balancer>
...

さらに、<instance要素では、FederatedServiceLoadBalancerインスタンスを作成するためのファクトリ・クラスを使用するために<class-factory-name要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name要素の使用もサポートされています。<instance要素の詳細な手順は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

クライアントベースのロード・バランシングの使用

クライアントベースのロード・バランシングの戦略は、フェデレーテッド・サービス・メンバー間での接続の分散を指定するcom.tangosol.net.AddressProvider実装に依存しています。アドレス・プロバイダ実装が提供されていない場合、構成済の各クラスタ参加者メンバーは、接続が成功するまでランダムな順序で試行されます。アドレス・プロバイダ実装の指定の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

クライアントベースのロード・バランシングの戦略は、clientに設定された<load-balancer>要素を使用して、<federated-scheme>定義内に構成されます。次に例を示します。

<federated-scheme>
<scheme-name>federated</scheme-name>
<service-name>federated</service-name>
<backing-map-scheme>
<local-scheme />
</backing-map-scheme>
<autostart>true</autostart>
<load-balancer>client</load-balancer>
<topologies>
<topology>
<name>MyTopology</name>
</topology>
</topologies>
</federated-scheme>

フェデレーテッド・キャッシュの管理

フェデレーテッド・キャッシュは、パフォーマンスとリソースの使用を最適にするために、クラスタおよび分散キャッシュと同じように、各クラスタ参加者で管理する必要があります。クラスタが適切に実行されていないと、フェデレーションの一部として含めたときに、パフォーマンスの問題が発生する場合があります。さらに、フェデレーテッド・キャッシュは、フェデレーション内のクラスタ参加者間で効率的なレプリケーション・パフォーマンスとスループット実現できるように管理する必要もあります。ワイド・エリア・ネットワーク・トポロジに固有の問題により、レプリケーション・パフォーマンスの監視が特に重要になります。

クラスタ参加者のステータスの監視

フェデレーション内の各クラスタ参加者のステータスを監視し、問題がないことを確認します。

Coherence-Java VisualVMプラグイン

Coherence Java VisualVMプラグインの「フェデレーション」タブを使用して、ローカル・クラスタ参加者のコンテキストから、各クラスタ参加者のステータスを表示します。つまり、各宛先クラスタ参加者がリストされ、そのステータスが表示されます。また、ローカル・クラスタ参加者の各ノードのレプリケーション状態が「アウトバウンド」タブにレポートされます。クラスタ参加者のステータスがErrorの場合は、「エラーの説明」フィールドを選択して、エラー・メッセージを表示します。

Coherenceレポート

フェデレーション宛先レポート(federation-destination.txt)を使用して、各宛先クラスタ参加者のステータスおよび各ノードのレプリケーション状態を時系列で表示します。

Coherence MBean

DestinationMBean MBeanの永続性の属性を使用して、各宛先クラスタ参加者のステータスおよびローカル・クラスタ参加者の各ノードのレプリケーション状態を表示します。

レプリケーションのパフォーマンスおよびスループットの監視

レプリケーション・パフォーマンスとスループットを監視し、大幅な遅延やデータの損失がなく、ローカル・クラスタ参加者が各参加者にデータをレプリケートしていることを確認します。パフォーマンおよびスループットの問題は、クラスタ参加者間のネットワーク接続またはローカル・クラスタ参加者に問題が発生していることを示す場合があります。

Coherence-Java VisualVMプラグイン

Coherence-Java VisualVMプラグインの「フェデレーション」タブを使用して、ローカル参加者から各宛先クラスタ参加者への現在のレプリケーション・パフォーマンスの統計とスループットを表示します。宛先クラスタ参加者を選択して、そのレプリケーション・パフォーマンス統計を表示し、「アウトバウンド」タブの「現行のスループット」列を表示して、ローカル・クラスタの各ノードから、選択した参加者へのスループットを確認します。「アウトバウンド」タブで各ノードを選択して、帯域幅の使用量とレプリケーション・パフォーマンスをグラフ・タブでそれぞれ確認します。最後に、「インバウンド」タブを選択して、宛先クラスタ参加者からローカル・クラスタ参加者へのデータの受信効率を表示します。

Coherenceレポート

フェデレーション宛先レポート(federation-destination.txt)およびフェデレーション・オリジン・レポート(federation-origin.txt)を使用して、レプリケーション・パフォーマンス統計を表示します。宛先レポートには、ローカル・クラスタ参加者の各ノードから各宛先クラスタ参加者へのデータの送信効率が表示されます。フェデレーション・オリジン・レポートには、宛先クラスタ参加者からローカル・クラスタ参加者の各ノードへのデータの受信効率が表示されます。

Coherence MBean

DestinationMBean MBeanおよびOriginMBean MBeanの永続性の属性を使用して、レプリケーション・パフォーマンス統計を表示します。DestinationMBean MBeanの属性には、ローカル・クラスタ参加者の各ノードから各宛先クラスタ参加者へのデータの送信効率が表示されます。OriginMBean MBeanには、宛先クラスタ参加者からローカル・クラスタ参加者へのデータの受信効率が表示されます。

A プラットフォーム固有のデプロイに関する考慮事項

この付録では、様々なプラットフォームにCoherenceをデプロイする際に考慮する問題を識別します。可能な場合は、その解決策も示します。

この付録の内容は次のとおりです。

- Oracle HotSpot JVMへのデプロイ

- IBM JVMへのデプロイ

- Linuxへのデプロイ

- Solarisへのデプロイ

- Windowsへのデプロイ

- OS Xへのデプロイ

- z/OSへのデプロイ

- AIXへのデプロイ

- 仮想マシンへのデプロイ

- Cisco社製スイッチへのデプロイ

- Foundry社製スイッチへのデプロイ

- IBM BladeCenterへのデプロイ

Oracle HotSpot JVMへのデプロイ

Oracle HotSpot JVMにCoherenceをデプロイする場合は、次の事項に留意してください。

ヒープ・サイズ

Coherenceでは、JVM当たりのヒープ・サイズを1 - 4GBに保つことをお薦めします。ただし、多数の小さなJVMから得られるパフォーマンスのメリットよりも、少数の大きなJVMから得られる管理の簡易化の方が重要になる一部のアプリケーションには、大きなヒープ・サイズ(最大20GB)が適しています。複数のキャッシュ・サーバーを使用すると、1台のコンピュータでより高い処理能力を実現できます。オラクル社のJVMには4GBを超えるヒープ・サイズが適していますが、GCの一時停止時間を最小限にするために、GCチューニングをお薦めします。チューニングの詳細は、オラクル社のGCチューニング・ガイドを参照してください。また、サイズの固定されたヒープでは通常、GC時間が短縮されるため、そのようなヒープで実行することもお薦めします。詳細は、「JVMのチューニング」を参照してください。

AtomicLong

使用可能なCoherenceが、並行性の高いAtomicLongクラスを利用すると、Long値に対して並行アトミック更新が可能となり、同期化は不要です。

サーバー・モードで実行し、安定した並行性の高いバージョンを確実に使用できるようにすることをお薦めします。JVMをサーバー・モードで実行するには、Javaコマンド行に-serverオプションを追加します。

OutOfMemoryError

JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。Sun JVMでこの設定を構成するパラメータは次のとおりです。

UNIXの場合:

-XX:OnOutOfMemoryError="kill -9 %p"

Windowsの場合:

-XX:OnOutOfMemoryError="taskkill /F /PID %p"

また、OutOfMemoryErrorがスローされた場合は、エラーの根本原因の調査に役立てるために、ヒープ・ダンプを生成するようにJVMを構成することをお薦めします。Sun JVMでこの機能を有効にするには次のフラグを使用します。

-XX:+HeapDumpOnOutOfMemoryError

IBM JVMへのデプロイ

IBM JVMにCoherenceをデプロイする場合は、次の事項に留意してください。

OutOfMemoryError

JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。IBM JVMでこの設定を構成するパラメータは次のとおりです。

UNIXの場合:

-Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec="kill -9 %pid"

Windowsの場合:

-Xdump:tool:events=throw,filter=java/lang/OutOfMemoryError,exec="taskkill /F /PID %pid"

ヒープ・サイズの設定

IBM社では、JVMに固定サイズのヒープを割り当てることを推奨していません。ほとんどの場合は、-Xmsにデフォルト値を使用することをお薦めします(つまり、この設定を省略して-Xmxのみを設定します)。詳細は、次のリンクを参照してください。

http://www.ibm.com/developerworks/java/jdk/diagnosis/

OutOfMemoryErrorがスローされた場合は、エラーの根本原因の調査に役立てるために、ヒープ・ダンプを生成するようにJVMを構成することをお薦めします。IBM JVMでは、デフォルトでOutOfMemoryErrorにヒープ・ダンプが生成されます。さらに構成を行う必要はありません。

Linuxへのデプロイ

LinuxにCoherenceをデプロイする場合は、次の事項に留意してください。

TSC高分解能タイムソース

Linuxには選択可能な高分解能タイムソースがいくつか用意されていますが、残念なことに、最速のタイムスタンプ・カウンタ(TSC)でも常に信頼性があるとはかぎりません。LinuxではTSCがデフォルトで選択され、起動時のチェックで非一貫性が検出されると、より低速で安全なタイムソースへの切替えが行われます。低速なタイムソースでは、問合せの実行にTSCタイムソースの10 - 30倍のコストがかかることがあり、Coherenceのパフォーマンスに多大な影響を与える可能性があります。TSCの詳細は、次を参照してください。

https://lwn.net/Articles/209101/

Coherenceおよび基礎となるJVMでは、オペレーティング・システムで使用しているタイムソースを認識しません。システム・ログ(/var/log/dmesg)をチェックして、次のメッセージが記載されていないかどうか確認することをお薦めします

kernel: Losing too many ticks!
kernel: TSC cannot be used as a timesource.
kernel: Possible reasons for this are:
kernel:   You're running with Speedstep,
kernel:   You don't have DMA enabled for your hard disk (see hdparm),
kernel:   Incorrect TSC synchronization on an SMP system (see dmesg).
kernel: Falling back to a sane timesource now.

ログ・メッセージによると、これが、CPU使用率の変動(SpeedStep)、DMAの無効化、またはマルチCPUコンピュータに対する誤ったTSCの同期化などに起因して発生していることを示しています。前述のメッセージが存在する場合は、システム管理者に問い合せてその原因を特定し、TSCタイムソースを使用可能にすることをお薦めします。

Solarisへのデプロイ

SolarisにCoherenceをデプロイする場合は、次の事項に留意してください。

Solaris 10(x86とSPARC)

Solaris 10上で実行している場合は、パケットの破損およびマルチキャストの切断に関する既知の問題があります。これらは多くの場合、EOFExceptions、パケット・データ読取り時の大きなギャップの警告または頻繁なパケット・タイムアウトとして顕在化します。Solaris 10システム上でCoherenceを使用する場合は、後述の両方の問題に対するパッチの適用を強くお薦めします。

Intelギガビット・ネットワーク・インタフェース・カード(NIC)にe1000gドライバを使用するSolaris 10システムに、データ整合性の問題が発生する可能性があります。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ALERT&id=1000972.1

パッチ118822-21 (SPARC)または118844-21 (x86またはx64)以降がインストールされているSolaris 10システムから送信される場合、IGMP (1)パケットにはIPルーター警告オプションが含まれていません。

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=ALERT&id=1000940.1

Solaris 10のネットワーキング

Solaris 10上で実行している場合は、パケットの破損およびマルチキャスト接続の切断について、前述の「Solaris 10 (x86とSPARC)」の問題を確認してください。これらは多くの場合、EOFExceptions、パケット・データ読取り時の大きなギャップの警告または頻繁なパケット・タイムアウトとして顕在化します。Solaris 10システム上でCoherenceを使用する場合は、これら両方の問題に対するパッチの適用を強くお薦めします。

Solarisネットワーク・インタフェース・カード

Solaris Mシリーズ・システムには、オンボードNIC (bge)およびPCI接続のNIC (nxge)が含まれます。オンボード・ギガビット・イーサネット・ポートは、ドメインの低帯域幅の管理ネットワーキング接続に使用され、トラフィック需要が大きい高パフォーマンス・クラスタ相互接続負荷用ではありません。Coherenceクラスタ・メンバーは、高帯域幅のクラスタ相互接続には常に専用のPCIe NICを使用する必要があります。

Solarisリンク・アグリゲーション

Solaris 11では、トランク・アグリゲーションとデータリンク・マルチパス(DLMP)アグリゲーションの2つのタイプのNICリンク・アグリゲーションがサポートされています。トランク・アグリゲーションではネットワーク・スイッチの使用が必要であり、これはリンク・アグリゲーション・コントロール・プロトコル(LCAP)をサポートしている必要があります。DLMPアグリゲーションでは、少なくとも1つのネットワーク・スイッチの使用が必要です。ただし、DLMPアグリゲーションを使用するときは、トランク・アグリゲーションをLCAPとともに使用するように構成されているスイッチがないことを確認してください。トランク・アグリゲーションからDLMPアグリゲーションに変更する場合、トランク・アグリゲーション用に以前作成したスイッチ構成を削除する必要があります。そのようにできなかった場合、パケットが失われ、ネットワーク帯域幅の利用が低くなる可能性があります。

Windowsへのデプロイ

WindowsにCoherenceをデプロイする場合は、次の事項に留意してください。

パフォーマンス・チューニング

初期状態のWindowsは、バックグラウンド・プロセスや重いネットワーク負荷に合せて最適化されているわけではありません。最適化するには、Coherenceインストールのbinディレクトリに含まれているoptimize.regスクリプトを実行します。実行する最適化の詳細は、「オペレーティング・システムのチューニング」を参照してください。

個人用ファイアウォール

コンピュータでファイアウォールを実行している場合は、複数のコンピュータで構成されるクラスタの形成が難しくなることがあります。これは、次のいずれかを実行すると解決できます。

- ファイアウォールの無効化。ただし、これは通常はお薦めしません。

- Coherenceを実行するJava実行可能ファイルに対する完全なネットワーク・アクセス権の付与。

- Coherenceに対する個別アドレスとポートの開放。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

切断されたネットワーク・インタフェース

Microsoft Windowsでは、ネットワーク・インタフェース・カード(NIC)がネットワークから取り外されると、そのカードに関連付けられたIPアドレスをオペレーティング・システムが無効にします。この結果、そのIPアドレスにバインドされているソケットがエラー状態になります。これにより、Coherenceノードがクラスタを終了し、NICがネットワークに再接続されるまでエラー状態になります。物理的に停止している間に、複数の連結されたJVMのクラスタ化を保持できるようにすることが望ましい場合は、IPアドレスを無効化しないようにWindowsを構成する必要があります。

このパラメータを調整する手順は次のとおりです。

1. レジストリ エディタを実行します(regedit)。

2. 次のレジストリ・キーを見つけます。

HKLM\System\CurrentControlSet\Services\Tcpip\Parameters

3. 次の新しいDWORD値を追加またはリセットします。

Name: DisableDHCPMediaSense
Value: 1 (boolean)

4. 再起動します。

キーワードの名前にDHCPが含まれていますが、この設定は静的IPアドレスと動的IPアドレスの両方に反映されます。詳細は、「Microsoft Windows TCP/IP Implementation Details」を参照してください。

http://technet.microsoft.com/en-us/library/bb726981.aspx#EDAA

OS Xへのデプロイ

OS XにCoherenceをデプロイする場合は、次の事項に留意してください。

マルチキャストとIPv6

OS Xは、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成します。それには、Javaコマンド行でシステム・プロパティjava.net.preferIPv4Stackをtrueに設定します。

ソケット・バッファのサイズ設定

通常、Coherenceでは2MB以上のバッファが必要ですが、OS Xの場合、このバッファ・サイズにするとカーネルのCPU時間が予想外に高くなり、スループットが低下する可能性があります。OS Xの推奨バッファ・サイズは768KBです。ただし、独自にチューニングして、より適したサイズを見つけることもできます。ソケット・バッファの構成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

z/OSへのデプロイ

z/OSにCoherenceをデプロイする場合は、次の事項に留意してください。

EBCDIC

デフォルトの文字セットがASCIIではなくEBCDICである環境にCoherenceをデプロイする場合、JARファイルからロードされる構成ファイルまたはクラスパスの構成ファイルがASCII形式であることを確認してください。ファイル・システムから直接ロードされた構成ファイルは、システムのネイティブ形式であるEBCDICで格納する必要があります。

マルチキャスト

状況によっては、IBM zSeriesのz/OS上の同じ論理パーティション(LPAR)内で実行されるCoherenceクラスタ・ノードは、相互に通信できません。(この問題は、zSeriesがLinux上で実行されている場合には発生しません。)

根本的な原因としては、z/OSでは、Coherenceで使用されるMulticastSocketを自動的に割り当てられたポートにバインドする可能性がある一方、Coherenceでは、クラスタ検出が適切に動作するように特定のポートを使用する必要のあることが挙げられます(Coherenceでは、必要なポートの使用のためにjava.net.MulitcastSocketを明示的に初期化しますが、同一のLPAR内で実行されるCoherenceのインスタンスが存在する場合は、その情報がz/OS上で無視されているように見えます。)

この解決策は、z/OS LPAR内ではCoherenceのインスタンスを1つのみ実行することです。複数のインスタンスが必要な場合は、Coherenceの各インスタンスを別々のz/OS LPARで実行する必要があります。または、ウェル・ノウン・アドレス機能を使用することもできます。ウェル・ノウン・アドレス機能の使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

AIXへのデプロイ

AIXにCoherenceをデプロイする場合は、次の事項に留意してください。

マルチキャストとIPv6

AIX 5.2以降では、デフォルトで、IPv4ではなくIPv6を使用してマルチキャストを実行するように設定されています。IPv6とIPv4が混在した環境で実行する場合には、IPv4を明示的に使用するようにJVMを構成します。それには、Javaコマンド行でシステム・プロパティjava.net.preferIPv4Stackをtrueに設定します。詳細は、『IBM 32-bit SDK for AIX User Guide』を参照してください。

仮想マシンへのデプロイ

Oracle Coherenceは、Oracle Fusion Middlewareのサポート・ポリシーに従います。Oracle Fusion Middlewareがサポートする仮想化およびパーティション化のテクノロジについては、次のリンクを参照してください。

http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.html

仮想マシンにCoherenceをデプロイする場合は、次の事項に留意してください。

マルチキャストの接続性

仮想化によりネットワーク・トポロジに別のレイヤーが追加されるため、マルチキャスト・ネットワーキングをサポートするように適切に構成する必要があります。マルチキャスト・ネットワーキングの構成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

パフォーマンス

仮想オペレーティング・システムで実行されるプロセスがギガビット・イーサネットを完全に使用できることはあまりありません。これはCoherenceに特有なことではなく、ネットワーク集中型の仮想アプリケーションの大半に当てはまります。

フォルト・トレランス

エントリ・キャッシュのバックアップが物理的に別個のハードウェアに存在するようにするには、追加の構成が必要になります。クラスタ・メンバーIDの構成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

Cisco社製スイッチへのデプロイ

Cisco社製スイッチを使用してCoherenceをデプロイする場合は、次の事項に留意してください。

バッファ・スペースとパケットの一時停止

一部のCisco社製スイッチでは、パケットの負荷が重いと、バッファ・スペースが不足し、数秒間の通信停止が頻繁に発生する場合があります。このような通信の停止は、ローカルまたはリモートのGCに起因しない複数ノードでの通信の遅延を指す、一連のCoherenceログ・メッセージにより特定できます。

Experienced a 4172 ms communication delay (probable remote GC) with Member(Id=7, Timestamp=2008-09-15 12:15:47.511, Address=xxx.xxx.x.xx:8089, MachineId=13838); 320 packets rescheduled, PauseRate=0.31, Threshold=512

Cisco 6500シリーズでは、各イーサネット・ポートまたはASICで使用可能なバッファ領域の容量を構成できます。負荷の高いアプリケーションでは、デフォルトのバッファ領域の増大が必要になる場合があります。これを実現するには、次を実行します。

fabric buffer-reserve high

この設定の詳細は、Ciscoのドキュメントを参照してください。

大規模ネットワークでのマルチキャスト接続

Cisco社のデフォルトのスイッチ構成では、IGMPスヌーピングを使用しているため、スイッチ間でのマルチキャスト・パケットの適切なルーティングがサポートされていません。この問題およびその解決策に関するCiscoのドキュメントを参照してください。

マルチキャストの停止

一部のCisco社製スイッチでは、マルチキャスト・グループのメンバーシップの維持が難しいため、既存のマルチキャスト・グループのメンバーが、通知されることなくマルチキャスト・グループから削除されることがあります。これにより、関連付けられたCoherenceノードに部分的な通信切断が発生し、クラスタからの離脱と再参加が強制的に行われます。このような停止はほとんどの場合、部分的な通信上の問題が検出されたことを示す次のCoherenceログ・メッセージによって識別できます。

A potential network configuration problem has been detected. A packet has failed to be delivered (or acknowledged) after 60 seconds, although other packets were acknowledged by the same cluster member (Member(Id=3, Timestamp=Sat Sept 13 12:02:54 EST 2008, Address=192.168.1.101, Port=8088, MachineId=48991)) to this member (Member(Id=1, Timestamp=Sat Sept 13 11:51:11 EST 2008, Address=192.168.1.101, Port=8088, MachineId=49002)) as recently as 5 seconds ago.

この問題を確認するには、実行中のクラスタと同じマルチキャスト・アドレスとポートを使用します。この問題がマルチキャスト・テスト・ノードに影響する場合は、マルチキャスト・テスト・メッセージの受信が突然停止したことが、そのログに記録されます。「マルチキャスト接続テストの実行」を参照してください。

次のテスト・ログはこの問題を示しています。

例A-1 マルチキャストの停止に関するログ

Test Node 192.168.1.100:

Sun Sept 14 16:44:22 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:23 GMT 2008: Received test packet 76 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:23 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:23 GMT 2008: Sent packet 85. Sun Sept 14 16:44:23 GMT 2008: Received test packet 85 from self.
Sun Sept 14 16:44:24 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:25 GMT 2008: Received test packet 77 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:25 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:25 GMT 2008: Sent packet 86.
Sun Sept 14 16:44:25 GMT 2008: Received test packet 86 from self. Sun Sept 14 16:44:26 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:27 GMT 2008: Received test packet 78 from ip=/192.168.1.101, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:27 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:27 GMT 2008: Sent packet 87.
Sun Sept 14 16:44:27 GMT 2008: Received test packet 87 from self.
Sun Sept 14 16:44:28 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:29 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:29 GMT 2008: Sent packet 88.
Sun Sept 14 16:44:29 GMT 2008: Received test packet 88 from self.
Sun Sept 14 16:44:30 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:31 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:31 GMT 2008: Sent packet 89.
Sun Sept 14 16:44:31 GMT 2008: Received test packet 89 from self.
Sun Sept 14 16:44:32 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???
Sun Sept 14 16:44:33 GMT 2008: Received 83 bytes from a Coherence cluster node at 182.168.1.100: ???

Test Node 192.168.1.101:

Sun Sept 14 16:44:22 GMT 2008: Sent packet 76.
Sun Sept 14 16:44:22 GMT 2008: Received test packet 76 from self.
Sun Sept 14 16:44:22 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:22 GMT 2008: Received test packet 85 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:23 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ??? Sun Sept 14 16:44:24 GMT 2008: Sent packet 77.
Sun Sept 14 16:44:24 GMT 2008: Received test packet 77 from self.
Sun Sept 14 16:44:24 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:24 GMT 2008: Received test packet 86 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:25 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:26 GMT 2008: Sent packet 78.Sun Sept 14 16:44:26 GMT 2008: Received test packet 78 from self.
Sun Sept 14 16:44:26 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:26 GMT 2008: Received test packet 87 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:27 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:28 GMT 2008: Sent packet 79.
Sun Sept 14 16:44:28 GMT 2008: Received test packet 79 from self.
Sun Sept 14 16:44:28 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:28 GMT 2008: Received test packet 88 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:29 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:30 GMT 2008: Sent packet 80.
Sun Sept 14 16:44:30 GMT 2008: Received test packet 80 from self.
Sun Sept 14 16:44:30 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:30 GMT 2008: Received test packet 89 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:31 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:32 GMT 2008: Sent packet 81.Sun Sept 14 16:44:32 GMT 2008: Received test packet 81 from self.
Sun Sept 14 16:44:32 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:32 GMT 2008: Received test packet 90 from ip=/192.168.1.100, group=/224.3.2.0:32367, ttl=4.
Sun Sept 14 16:44:33 GMT 2008: Received 83 bytes from a Coherence cluster node at 192.168.1.100: ???
Sun Sept 14 16:44:34 GMT 2008: Sent packet 82.

16:44:27に、最初のテスト・ノードで、他のコンピュータからのマルチキャスト・パケットの受信が停止しました。オペレーティング・システムにより、同一コンピュータ上のその他のプロセスからのマルチキャスト・トラフィックは、引き続き適切に転送されましたが、2番目のテスト・ノードからのテスト・パケット(79以降)は受信されませんでした。また、テスト・パケットおよび最初のノードによって生成されたクラスタのマルチキャスト・トラフィックは両方とも、引き続き2番目のノードに配信されました。これは、最初のノードがマルチキャスト・グループから通知なく削除されたことを示します。

このマルチキャストに関する問題が発生した場合は、Cisco社のテクニカル・サポートに連絡してください。または、ウェル・ノウン・アドレス機能を使用して、ユニキャストのみの構成に変更することも検討してください。ウェル・ノウン・アドレス機能の使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

マルチキャストの存続時間

Cisco 6500シリーズのルーターは、TTL(存続時間)の値が1のパケットを過剰に受信すると過負荷の状態になることがあります。さらに、TTLの設定が低いと単一グループのメンバーが過負荷になることもあります。CoherenceマルチキャストのTTL設定を、少なくともマルチキャスト・ドメインのサイズ(127または255)に設定し、クラスタが重複グループを使用していないことを確認してください。マルチキャストTTLの構成の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

Foundry社製スイッチへのデプロイ

Foundry社製スイッチを使用してCoherenceをデプロイする場合は、次の事項に留意してください。

マルチキャストの接続性

Foundry社製スイッチでは、マルチキャスト・トラフィックの処理が困難です。Foundry社製スイッチを使用してデプロイするときには、Coherenceクラスタに属するすべてのコンピュータがマルチキャスト通信できることを確認してください。「マルチキャスト接続テストの実行」を参照してください。

マルチキャストに関する問題が発生した場合は、well-known-addresses機能を使用してユニキャストのみの構成に変更することも検討してください。ウェル・ノウン・アドレス機能の使用の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

IBM BladeCenterへのデプロイ

IBM BladeCenterにCoherenceをデプロイする場合は、次の事項に留意してください。

MACアドレスの均一性とロード・バランシング

BladeCenterへの通常のデプロイには、それぞれ管理用とクラスタ・トラフィック用の2つのNICを備えたブレードが使用されます。デフォルトでは、BladeCenterのブレードに割り当てられるMACアドレスには均一性があるため、通常最初のNICには偶数のMACアドレスが、2番目のNICには奇数のMACアドレスが割り当てられます。また、中央のスイッチへのBladeCenterのアップリンクにも偶数個のチャンネルがある場合は、レイヤー2 (MACベース)のロード・バランシングにより、使用可能なアップリンクの全帯域幅が1セットのNICで消費されないように調整されます。すべてのNICは、偶数個または奇数個のチャンネルのどちらかにバインドされるためです。この問題は、スイッチではMACアドレスが基本的にランダムであるという前提によるものですが、BladeCenterには当てはまりません。この状況の対応策は次のとおりです。

- レイヤー3 (IPベース)のロード・バランシングを使用します(IPアドレスが同じ偶数/奇数パターンを踏襲しない場合)。

- この設定は、クラスタ・トラフィックの伝送を行うすべてのスイッチに適用する必要があります。

- 代替コンピュータの1番目と2番目のNIC間でMACアドレスを入れ替えることにより、MACアドレスの割当てをランダムにします。

- Linuxでは、ifconfigコマンドを使用してNICのMACアドレスを変更できます。

- その他のオペレーティング・システムでも、カスタム・ツールを使用して同様のタスクを実行できる場合があります。

B ログ・メッセージのリファレンス

この付録では、一般的なCoherenceのログ・メッセージと、メッセージの原因および可能な処置について説明します。

この付録は、次の各項で構成されています。

- TCMPのログ・メッセージ

- 構成のログ・メッセージ

- パーティション・キャッシュ・サービスのログ・メッセージ

TCMPのログ・メッセージ

TCMPに関連するログ・メッセージは次のとおりです。

Experienced a %n1 ms communication delay (probable remote GC) with Member %s

%n1: 通信遅延の待機時間(ミリ秒)、%s: 全メンバー情報。重大度: 2: 警告、5: デバッグ・レベル5、6: デバッグ・レベル6(遅延の長さによる)。

原因: このノードで、指定されたノードからの確認パケットの受信遅延が検出され、リモートGC(ローカルGCではなく)が原因である可能性が高いと判断されました。このメッセージは、指定されたノードから期限切れの確認パケットを受信しており、その問題がそのノードのGCが原因で発生したと推測されることを示しています。ネットワークまたはリモート・サーバーの処理速度の低下によって、この現象が発生する可能性がありますが、最も一般的な原因はGCであるため、これを最初に調査する必要があります。

処置: ガベージ・コレクションが長期化したり、頻度が高かったりすると、クラスタのパフォーマンスと可用性に悪影響を及ぼす場合があります。この警告が頻繁に表示される場合は、JVMヒープおよびGCの構成とチューニングを確認してください。詳細は、「パフォーマンス・チューニング」を参照してください。

Failed to satisfy the variance: allowed=%n1 actual=%n2

%n1: 許容最大待機時間(ミリ秒)、%n2: 実際の待機時間(ミリ秒)。重大要度: 3: 情報、5: デバッグ・レベル5(メッセージの発生頻度による)。

原因: Coherenceクラスタ検出プロトコルの最初のステップの1つとして、新しいノードと上位ノードとの間のクロックの差異が計算されます。このステップでは、ノード間のpeer-to-peerラウンドトリップ通信の待機時間が比較的短いと想定されます。デフォルトの構成済の最大許容待機時間(<maximum-time-variance構成要素の値)は16ミリ秒です。『Oracle Coherenceでのアプリケーションの開発』の<incoming-message-handler要素を参照してください。待機時間を超えると、このメッセージがログに記録され、待機時間のしきい値が大きくなり、以降のメッセージに反映されます。

処置: 待機時間が依然として非常に長い場合は(100ミリ秒超)、ネットワーク管理者に連絡して、「ネットワーク・パフォーマンス・テストの実行」を参照してください。

Created a new cluster "%s1" with Member(%s2)

%s1: クラスタ名、%s2: 全メンバー情報。重大度: 3: 情報。

原因: Coherenceノードが構成時間内(<join-timeout-milliseconds要素で指定されますが、「<multicast-listener要素」を参照してください)に既存のクラスタに参加しようとしましたが、他のノードからの応答をまったく受信しませんでした。そのため、指定された名前の新しいクラスタを作成しました(<cluster-name要素(「<member-identity要素」を参照)によって構成された名前か、マルチキャスト・リスナーのアドレスやポートまたは<well-known-addressesリストに基づいて計算された名前のいずれか)。メンバー情報には、ノードID、作成タイムスタンプ、ユニキャスト・アドレスとポート、ロケーション、プロセスID、ロールなどが含まれます。

処置: このノードがクラスタ内の最初のノードである場合、処置は特に必要ありません。そうでない場合は、オペレーション構成を確認して、このノードが既存クラスタに参加できない原因を調べる必要があります。

This Member(%s1) joined cluster "%s2" with senior Member(%s3)

%s1: このノードの全メンバー情報、%s2: クラスタ名、%s3: クラスタの上位ノードの全メンバー情報。重大度: 3: 情報。

原因: このCoherenceノードは既存クラスタに参加しました。

処置: このノードが既存クラスタに参加予定である場合、処置は特に必要ありません。それ以外の場合は、実行中のクラスタを特定して、修正処置について検討してください。

Member(%s) joined Cluster with senior member %n

%s: このノードが属するクラスタに参加した新しいノードの全メンバー情報、%n: クラスタの上位ノードのノードID。重大度: 5: デバッグ・レベル5。

原因: 新しいノードが既存のCoherenceクラスタに参加しました。

処置: なし。

Member(%s) left Cluster with senior member %n

%s: クラスタから離脱したノードの全メンバー情報、%n: クラスタの上位ノードのノードID。重大度: 5: デバッグ・レベル5。

原因: ノードがクラスタから離脱しました。この離脱の原因としては、プログラムによるシャットダウン、プロセスの終了(正常または異常)またはその他の通信障害(たとえば、ネットワークの切断または非常に長期のGCの一時停止)が考えられます。このメッセージは、ノードの離脱をレポートするものです。

処置: このノードの離脱が計画的なものである場合、処置は特に必要ありません。そうでない場合は、離脱したノードのログを分析する必要があります。

MemberLeft notification for Member %n received from Member(%s)

%n: 離脱したノードのノードID、%s: クラスタから離脱したノードの全メンバー情報。重大度: 5: デバッグ・レベル5。

原因: Coherenceノードが終了すると、いくつかのノードでは、他よりも早くこの離脱が検出されます。通常、TCPリング接続を介して接続されたノード(TCPリング・バディ)が最初にこれを検出します。このメッセージは、離脱を最初に検出したノードに関する情報を提供します。

処置: このノードの離脱が計画的なものである場合、処置は特に必要ありません。そうでない場合は、離脱したノードと離脱を検出したノードの両方のログを分析する必要があります。

Received cluster heartbeat from the senior %n that does not contain this %s ; stopping cluster service

%n - 上位サービス・メンバーID、%s - クラスタ・サービス・メンバーのID。重大度: 1: エラー。

原因: ハートビートが、クラスタ・メンバー・セットを含む上位クラスタ・サービス・メンバーからブロードキャストされています。このクラスタ・サービス・メンバーがブロードキャスト・セットの一部でない場合、上位メンバーはこのサービス・メンバーを利用不可能と判断し、メンバーに対するクラスタ・サービスが停止していると想定されます。これは通常、(ネットワークの問題または長時間のガベージ・コレクションが原因が考えられるために)メンバーが長時間クラスタとの通信を喪失し、クラスタから拒否された場合に発生します。

処置: クラスタの残りの部分は動作を継続すると推測されるため、修正処置が必要になるとはかぎりません。ただし、問題の根本原因の調査が必要になる場合もあります(特に一定の頻度で繰返し発生する場合)。

Service %s joined the cluster with senior service member %n

%s: サービス名、%n: 上位サービス・メンバーのID。重大度: 5: デバッグ・レベル5。

原因: 所定のノードでクラスタ化サービスが開始すると、Coherenceは特定のサービスを実行するすべてのクラスタ・ノード間でハンドシェイク・プロトコルを開始します。このメッセージは、このプロトコルが開始したことを通知するものです。この時点で上位ノードが不明の場合は、n/aと表示されます。

処置: なし。

This node appears to have partially lost the connectivity: it receives responses from MemberSet(%s1) which communicate with Member(%s2), but is not responding directly to this member; that could mean that either requests are not coming out or responses are not coming in; stopping cluster service

%s1: %s2に示されるメンバーと通信できるメンバー・セット、%s2: %s1に示されるメンバー・セットと通信できるメンバー。重大度: 1: エラー。

原因: このメンバーと%s2で示されたメンバー間の通信リンクが切断されました。しかし、%s1で示された証人セットは、%s2との通信の問題を報告しません。したがって、このノードは部分障害の状態であると見なされ、その結果、そのクラスタ・スレッドがシャットダウンされます。

処置: クラスタの残りの部分は動作を継続し、このノードは回復してクラスタに再参加すると推測されるため、修正処置が必要になるとはかぎりません。ただし、問題の根本原因の調査が必要になる場合もあります(特に一定の頻度で繰返し発生する場合)。

validatePolls: This senior encountered an overdue poll, indicating a dead member, a significant network issue or an Operating System threading library bug (e.g. Linux NPTL): Poll

重大度: 2: 警告

原因: ノードがクラスタに参加すると、各クラスタ・ノードとハンドシェイクを行います。ハンドシェイク・レスポンスが欠落しているため、このノードはサービスに参加できません。これに続くログ・メッセージは、このノードが取る修正処置を示します。

処置: このメッセージが再度表示される場合は、根本原因の詳細な調査が必要になることがあります。

Received panic from junior member %s1 caused by %s2

%s1 - 危機的状況を送信したクラスタ・メンバー、%s2 - 上位メンバーであると主張するメンバー。重大度2: 警告

原因: これは、(通常、ネットワーク・リンク障害のため)クラスタが複数のクラスタ・アイランドに分割された後に発生します。このメッセージは、この上位メンバーには上位メンバーであると主張しているその他のメンバーに関する情報がないため、その他の上位メンバーと通信できるまでは下位メンバーからの危機的状況が無視されることを示しています。

処置: この問題が頻繁に発生する場合は、クラスタが分割される根本原因を調査する必要があります。

Received panic from senior Member(%s1) caused by Member(%s2)

%s1: このノードで知られているクラスタ上位メンバー、%s2: 上位メンバーであると主張するメンバー。重大度: 1: エラー。

原因: これは、(通常、ネットワーク・リンク障害のため)クラスタが複数のクラスタ・アイランドに分割された後に発生します。リンクが回復し、対応するアイランドの上位メンバーが互いを認識すると、パニック・プロトコルが開始され、競合を解決します。

処置: この問題が頻繁に発生する場合は、クラスタが分割される根本原因を調査する必要があります。

Member %n1 joined Service %s with senior member %n2

%n1: サービスに参加するCoherenceノードのID、%s: サービス名、%n2: サービスの上位ノード。重大度: 5: デバッグ・レベル5。

原因: いずれかのクラスタ・ノードでクラスタ化サービスが開始されると、Coherenceは特定のサービスを実行するすべてのクラスタ・ノード間でハンドシェイク・プロトコルを開始します。このメッセージは、指定されたノードがハンドシェイクを正常に完了してサービスに参加したことを通知するものです。

処置: なし。

Member %n1 left Service %s with senior member %n2

%n1: サービスに参加するCoherenceノードのID、%s: サービス名、%n2: サービスの上位ノード。重大度: 5: デバッグ・レベル5。

原因: いずれかのクラスタ・ノードでクラスタ化サービスが終了すると、そのサービスを実行する他のすべてのノードにこのイベントが通知されます。このメッセージは、指定されたノードで指定されたクラスタ化サービスが終了したことを通知するものです。

処置: なし。

Service %s: received ServiceConfigSync containing %n entries

%s: サービス名、%n: サービス構成マップ内のエントリ数。重大度: 5: デバッグ・レベル5。

原因: サービスの上位メンバーは、指定のサービスを実行しているすべてのクラスタ・ノード間のサービス・ハンドシェイク・プロトコルの一部として、新しいノードのそれぞれについて、サービス構成マップの全コンテンツを更新します。パーティション・キャッシュ・サービスの場合は、完全なパーティション所有権カタログとすべての既存キャッシュの内部IDがこのマップに含まれます。このメッセージは、サービスの上位ノードの役割を新しいノードが引き継ぐ際に上位ノードでサービスが異常終了した場合にも送信されます。このメッセージは、指定されたノードが構成の更新を受信したことを通知するものです。

処置: なし。

TcpRing: connecting to member %n using TcpSocket{%s}

%s: 他のノードへのTcpRingコネクタとして機能するTcpSocketに関する全情報、%n: このノードが接続されるノードのID。重大度: 5: デバッグ・レベル5。

原因: Coherenceは、TcpRingと呼ばれる機能を利用して、プロセスの終了を迅速に検出します。TcpRingは、クラスタ内の異なるノード間でのTCP/IP接続のスパース・コレクションです。クラスタ内の各ノードが(可能であれば)別の物理的なボックスで実行されている1つ以上の他のノードに接続されます。この接続は、データ転送には使用されません。各リンクで1秒に1回単純なハートビート通信が送信されるだけです。このメッセージは、このノードと指定されたノードの間で接続が開始されたことを示しています。

処置: なし。

Rejecting connection to member %n using TcpSocket{%s}

%n: このノードへの接続を試行するノードのID、%s: 他のノードへのTcpRingコネクタとして機能するTcpSocketに関する全情報。重大度: 4: デバッグ・レベル4。

原因: 異なるノード上で実行されているTCPリング・デーモンが相互に、または同じノード上で同時に参加を試みることがあります。その場合、受信側のノードが、その接続が冗長であると判断して、着信接続リクエストを拒否することがあります。このメッセージは、このような状況が発生したときに、リクエストを拒否したノードによってログに記録されます。

処置: なし。

Timeout while delivering a packet; requesting the departure confirmation for Member(%s1) by MemberSet(%s2)

%s1: このノードが通信に失敗したノードの全メンバー情報、%s2: メンバーが離脱した疑いについて確認するよう要求された証人ノードに関する全情報。重大度: 2: 警告。

原因: Coherenceでは、すべてのデータ通信(大半はpeer-to-peerユニキャスト)にTMBが使用されますが、それ自体では、配信について保証されているわけではありません。それについては、Coherenceで使用されるクラスタ管理プロトコル(TCMP)で保証されています。TCMPデーモンは、すべての着信通信の確認(ACKまたはNACK)を行う役割があります。ACK間隔(ack-delay-milliseconds)の期限内に確認できなかったパケットが1つ以上ある場合、それらのパケットは再送信されます。パケットが最終的に確認できるまで、またはタイムアウト間隔(timeout-milliseconds)が経過するまで、この処理が繰り返されます。このときに、このメッセージがログに記録され、証人プロトコルによって、他のクラスタ・ノードで応答のないノードとの間に同様の通信遅延が発生したことがあるかどうかが確認されます。証人ノードは、ロールとロケーションを基準にして選択されます。

処置: クラスタの残りの部分は動作を継続し、このノードは回復してクラスタに再参加すると推測されるため、修正処置が必要になるとはかぎりません。ただし、問題の根本原因の調査が必要になる場合もあります(特に一定の頻度で繰返し発生する場合)。

This node appears to have become disconnected from the rest of the cluster containing %n nodes All departure confirmation requests went unanswered Stopping cluster service.

%n: このノードがメンバーとして属していたクラスタ内の他のノードの数。重大度: 1: エラー。

原因: 有効なJavaプロセス内のアクティブなノードが他のクラスタ・ノードとの通信を停止する場合があります。(想定される原因としては、ネットワーク障害、極端に長期にわたるGCの停止、プロセスのスワップアウトなどがあります。)その場合、他のクラスタ・ノードは、一時停止したノードのクラスタ・メンバーシップを無効にして、そのノードによるその後の通信の試行を完全に回避することを選択できます。その場合、プロセスがクラスタ通信を再開しようとすると、このメッセージがログに記録されます。

処置: クラスタの残りの部分は動作を継続し、このノードは回復してクラスタに再参加すると推測されるため、修正処置が必要になるとはかぎりません。ただし、問題の根本原因の調査が必要になる場合もあります(特に一定の頻度で繰返し発生する場合)。

A potential communication problem has been detected A packet has failed to be delivered (or acknowledged) after %n1 seconds, although other packets were acknowledged by the same cluster member (Member(%s1)) to this member (Member(%s2)) as recently as %n2 seconds ago Possible causes include network failure, poor thread scheduling (see FAQ if running on Windows), an extremely overloaded server, a server that is attempting to run its processes using swap space, and unreasonably lengthy GC times

%n1: パケットを配信または認識できなかった秒数、%s1: メッセージに示されたパケットの受信側、%s2: メッセージに示されたパケットの送信側、%n2: 前述の2つのメンバー間でパケットが正常に配信されてからの秒数。重大度: 2: 警告。

原因: 考えられる原因は、メッセージのテキストに示されています。

処置: この問題が頻繁に発生する場合は、根本原因を調査する必要があります。

Node %s1 is not allowed to create a new cluster; WKA list: [%s2]

%s1: クラスタへの参加を試みるノードのアドレス、%s2: WKAアドレスのリスト。重大度: 1: エラー。

原因: クラスタはWKAを使用するように構成されていますが、そのクラスタにはWKAリストにあるノードが存在しません。

処置: WKAリスト内のノードの少なくとも1つはクラスタに存在するようにするか、このノードのアドレスをWKAリストに追加します。

This member is configured with a compatible but different WKA list then the senior Member(%s) It is strongly recommended to use the same WKA list for all cluster members

%s: クラスタの上位ノード。重大度: 2: 警告。

原因: このノードのWKAリストが、上位ノードのWKAリストと異なります。異なるWKAリストを使用すると、様々なクラスタ・メンバーが他のクラスタ・メンバーと無関係に稼働する原因となり得ます。

処置: 2つのリストが意図的に異なっていることを確認するか、それらを同じ値に設定してください。

<socket implementation> failed to set receive buffer size to %n1 packets (%n2 bytes); actual size is %n3 packets (%n4 bytes) Consult your OS documentation regarding increasing the maximum socket buffer size Proceeding with the actual value may cause sub-optimal performance

%n1: Coherenceが割当てを試みたバッファに収まるパケットの数、%n2: Coherenceが割当てを試みたバッファのサイズ、%n3: 割り当てられた実際のバッファ・サイズに収まるパケットの数、%n4: 割り当てられたバッファの実際のサイズ。重大度: 2: 警告。

原因: 「オペレーティング・システムのチューニング」を参照してください。

処置: 「オペレーティング・システムのチューニング」を参照してください。

The timeout value configured for IpMonitor pings is shorter than the value of 5 seconds Short ping timeouts may cause an IP address to be wrongly reported as unreachable on some platforms

重大度: 2: 警告

原因: pingのタイムアウト値が5秒より小さくなっています。

処置: <tcp-ring-listener>要素内で構成されたpingタイムアウトは、5秒より大きくしてください。

Network failure encountered during InetAddress.isReachable(): %s

%n: スタック・トレース。重大度: 5: デバッグ・レベル5。

原因: IpMonitorコンポーネントがメンバーにpingを送信できないまま、構成されたタイムアウト間隔に達しています。

処置: メンバーが動作中であることを確認するか、ネットワークの停止を確認してください。<tcp-ring-listener>要素内で構成するpingタイムアウトは、そのネットワークに必要になるタイムアウトを考慮に入れて長くできます。

TcpRing has been explicitly disabled, this is not a recommended practice and will result in a minimum death detection time of %n seconds for failed processes

%n: パケット・パブリッシャの再送信タイムアウトで指定された秒数(デフォルトは5秒)。重大度: 2: 警告。

原因: TcpRingリスナー・コンポーネントが無効化されています。

処置: <tcp-ring-listener>要素内のTcpRingリスナーを有効化してください。

IpMonitor has been explicitly disabled, this is not a recommended practice and will result in a minimum death detection time of %n seconds for failed machines or networks

%n: パケット・パブリッシャの再送信タイムアウトで指定された秒数(デフォルトは5秒)。重大度: 2: 警告。

原因: IpMonitorコンポーネントが無効化されています。

処置: <tcp-ring-listener>要素内のTcpRingリスナーが有効化されたときに、IpMonitorコンポーネントを有効化します。

TcpRing connecting to %s

%s: このメンバーがTCP-Ringを形成するために結合しているクラスタ・メンバー重大度: 6: デバッグ・レベル6。

原因: このメッセージは、これと指定メンバーの間で接続が開始されたことを示しています。TCP-Ringは、プロセスの終了を迅速に検出するために使用されます。TCP-Ringとは、クラスタ内の異なるノード間でのTCP/IPベースの接続のスパース・コレクションのことです。

処置: なし。

TcpRing disconnected from %s to maintain ring

%s: このメンバーが切断されたクラスタ・メンバー。重大度: 6: デバッグ・レベル6。

原因: このメッセージは、このメンバーが指定メンバーから切断されたことと、指定されたメンバーがTCP-Ringのメンバーでないことを示しています。TCP-Ringは、プロセスの終了を迅速に検出するために使用されます。TCP-Ringとは、クラスタ内の異なるノード間でのTCP/IPベースの接続のスパース・コレクションのことです。

処置: メンバーが意図的に停止された場合、さらなる処置は必要ありません。それ以外の場合、そのメンバーは障害の発生またはネットワークの停止のためにクラスタから切り離されている可能性があります。メンバーを再起動します。

TcpRing disconnected from %s due to a peer departure; removing the member

%s: このメンバーが切断されたクラスタ・メンバー。重大度: 5: デバッグ・レベル5。

原因: このメッセージは、このメンバーが指定メンバーから切断されたことと、指定されたメンバーがTCP-Ringのメンバーでないことを示しています。TCP-Ringは、プロセスの終了を迅速に検出するために使用されます。TCP-Ringとは、クラスタ内の異なるノード間でのTCP/IPベースの接続のスパース・コレクションのことです。

処置: メンバーが意図的に停止された場合、さらなる処置は必要ありません。それ以外の場合、そのメンバーは障害の発生またはネットワークの停止のためにクラスタから切り離されている可能性があります。メンバーを再起動します。

TcpRing connection to "%s" refused ("%s1"); removing the member

%s: このメンバーが接続を拒否されたクラスタ・メンバー。%s1: 拒否メッセージ。重大度: 5: デバッグ・レベル5。

原因: 指定したメンバーは、このメンバーからのTCP接続を拒否した後でTCP-Ringから削除されています。

処置: メンバーが意図的に停止された場合、さらなる処置は必要ありません。それ以外の場合、そのメンバーは障害の発生またはネットワークの停止のためにクラスタから切り離されている可能性があります。メンバーを再起動します。

構成のログ・メッセージ

構成に関連するログ・メッセージは次のとおりです。

java.io.IOException: Configuration file is missing: "tangosol-coherence.xml"

重大度: 1: エラー。

原因: オペレーション構成ディスクリプタをロードできません。

処置: Javaコマンド行で指定されたクラス・パスからtangosol-coherence.xmlリソースがロードできることを確認してください。

Loaded operational configuration from resource "%s"

%s: オペレーション構成ディスクリプタの完全なリソース・パス(URI)。重大度: 3: 情報。

原因: Coherenceでは、指定された場所から、オペレーション構成ディスクリプタがロードされます。

処置: オペレーション構成ディスクリプタの場所がシステム・プロパティまたはプログラムを使用して明示的に指定されている場合は、レポートされたURIが予期されている場所と一致しているかどうかを確認してください。

Loaded operational overrides from "%s"

%s: オペレーション構成ディスクリプタ・オーバーライドのURI(ファイルまたはリソース)。重大度: 3: 情報。

原因: オペレーション構成ディスクリプタがポイントするオーバーライドの場所から、ディスクリプタのオーバーライドがロードされています。

処置: オペレーション構成ディスクリプタの場所が、システム・プロパティ、ディスクリプタ・オーバーライド、またはプログラムを使用して明示的に指定されている場合は、レポートされたURIが予期されている場所と一致しているかどうかを確認してください。

Optional configuration override "%s" is not specified

%s: オペレーション構成ディスクリプタ・オーバーライドのURI。重大度: 3: 情報。

原因: オペレーション構成ディスクリプタがオーバーライドの場所をポイントしていますが、その場所にはリソースがありません。

処置: オペレーション構成ディスクリプタ・オーバーライドが存在していなくてもよいかどうかを確認してください。

java.io.IOException: Document "%s1" is cyclically referenced by the 'xml-override' attribute of element %s2

%s1: オペレーション構成ディスクリプタまたはオーバーライドのURI、%s2: 間違った参照URIが含まれたXML要素の名前。重大度: 1: エラー。

原因: オペレーション構成オーバーライドが、それ自体をポイントしているかそのオーバーライドをポイントする別のオーバーライドをポイントしており、無限再帰が発生しています。

処置: 無効なxml-override属性値を修正してください。

java.io.IOException: Exception occurred during parsing: %s

%s: XMLパーサーのエラー。重大度: 1: エラー。

原因: 指定されたXMLが無効のため解析できません。

処置: XMLドキュメントを修正してください。

Loaded cache configuration from "%s"

%s: キャッシュ構成ディスクリプタのURI(ファイルまたはリソース)。重大度: 3: 情報。

原因: オペレーション構成ディスクリプタ、またはプログラムによって作成されたConfigurableCacheFactoryインスタンスが、すでにロードされているキャッシュ構成ディスクリプタをポイントしています。

処置: レポートされたURIが、予期されているキャッシュ構成ディスクリプタの場所と一致していることを確認してください。

パーティション・キャッシュ・サービスのログ・メッセージ

パーティション・キャッシュに関連するログ・メッセージは次のとおりです。

Asking member %n1 for %n2 primary partitions

%n1: このノードがパーティションの転送を依頼したノードのID、%n2: このノードが取得しようとしているパーティションの数。重大度: 4: デバッグ・レベル4。

原因: Coherenceノードで記憶域が有効なパーティション・サービスを開始すると、最初に、記憶域が有効な他のサービス・ノードと現在のパーティション所有情報を知らせる、構成の更新を受信します。この情報によって、再分散プロセスの後に各ノードが所有するパーティションの均等な所有数の計算が可能になります。このメッセージは、所有権を均等に分散できるようにするための特定のノードに対する転送リクエストが開始されたことを示しているわけではありません。

処置: なし。

Transferring %n1 out of %n2 primary partitions to member %n3 requesting %n4

%n1: このノードがリクエスト元のノードに転送するプライマリ・パーティションの数、%n2: このノードが現在所有しているプライマリ・パーティションの合計数、%n3: 転送先ノードのID、%n4: リクエスト元ノードが要求するパーティションの数。重大度: 4: デバッグ・レベル4。

原因: パーティション分散プロトコルでは、所有するプライマリ・パーティションの数が均等な所有数よりも少ないノードが、多く所有するノードに対して所有パーティションの一部の転送をリクエストします。所有者は、リクエストされた数以内の任意の数のパーティションを送信できます。このメッセージは、対応するプライマリ・データの転送の開始位置を示します。

処置: なし。

Transferring %n1 out of %n2 partitions to a machine-safe backup 1 at member %n3 (under %n4)

%n1: このノードが別のノードに転送するバックアップ・パーティションの数、%n2: このノードが現在所有している、消失する危険のある(バックアップがない)パーティションの合計数、%n3: 転送先ノードのID、%n4: 受領側が均等な所有数に達するために取得する必要のあるパーティション数。重大度: 4: デバッグ・レベル4。

原因: プライマリ・パーティションの所有権の調整が完了すると、ノードでは、強力なバックアップ・ポリシーを確実に実現するためのバックアップの分散が開始され、プライマリ所有者のコンピュータとは異なるコンピュータで実行されるノードにバックアップの所有権が割り当てられます。このメッセージは、対応するバックアップ・データの転送の開始位置を示します。

処置: なし。

Transferring backup%n1 for partition %n2 from member %n3 to member %n4

%n1: このノードが別のノードに転送しようとするバックアップ・パーティションの索引、%n2: 転送対象のパーティション数、%n3: このバックアップ・パーティションの前所有者のノードID、%n4: バックアップ・パーティションの転送先ノードのID。重大度: 5: デバッグ・レベル5。

原因: パーティション分散プロトコルでは、ノードが、そのプライマリ・パーティションのいずれかのバックアップの所有者に過負荷が生じていると判断した場合、そのノードバックアップの所有権を負荷の小さい別のノードに転送することを選択できます。このメッセージは、対応するバックアップ・データの転送の開始位置を示します。

処置: なし。

Failed backup transfer for partition %n1 to member %n2; restoring owner from: %n2 to: %n3

%n1: バックアップ転送が進行中だったパーティションの番号、%n2: バックアップ・パーティションの転送先のノードID、%n3: パーティションの前のバックアップ所有者のノードID。重大度: 4: デバッグ・レベル4。

原因: このノードは、新しいバックアップ所有者へのバックアップ・パーティションの転送中に、サービスから離脱しました。このノードは、バックアップの所有権を元のバックアップ所有者に戻しています。

処置: なし。

Deferring the distribution due to %n1 pending configuration updates

%n1: 構成の更新数。重大度: 5: デバッグ・レベル5。

原因: 定期的にスケジュールされた分散チェックの実行時に、このノードはグローバル所有権マップを更新(他のノードに所有権の変更を通知)していました。このノードは、以前の所有権の変更(ほとんどの場合は、すでに完了した転送によるもの)が完了し、サービスの他のメンバーによる確認が済むまで、以降のスケジュールされた分散チェックを延期します。

処置: なし。

Limiting primary transfer to %n1 KB (%n2 partitions)

%n1: 転送サイズの制限(KB)、%n2: 転送されたパーティションの数。重大度: 4: デバッグ・レベル4。

原因: ノードは、負荷の小さいノードから一部のプライマリ・パーティションの転送リクエストを受信した場合、任意の数のパーティション(要求された数以内)をリクエスト側に転送できます。転送のサイズは、<distributed-scheme要素内の<transfer-threshold要素によって制限されます。このメッセージは、transfer-thresholdの制限に従い、分散アルゴリズムによって転送が指定パーティション数に制限されたことを示しています。

処置: なし。

DistributionRequest was rejected because the receiver was busy Next retry in %n1 ms

%n1: 次回の分散チェックがスケジュールされるまでの期間(ミリ秒)。重大度: 6: デバッグ・レベル6。

原因: この(負荷の少ない)ノードは、別のノードに対して、1つ以上のパーティションの転送を求める分散リクエストを発行しました。しかし、そのノードは、以前のさらに別のノードとの間での転送を完了しようとしていたため、転送の開始を拒否しました。このノードは、少なくとも指定された期間待機してから(以前の転送が完了できるようにするため)、次の分散チェックを実行します。

処置: なし。

Restored from backup %n1 partitions

%n1: リストアされるパーティションの数。重大度: 3: 情報。

原因: このノードが所有するバックアップ・パーティションの一部のプライマリ所有者がサービスから離脱しました。このノードは、それらのパーティションをバックアップ記憶域からリストアしています(プライマリの所有権を引き継ぎます)。このメッセージの後には、リストア対象のパーティションのリストが続きます。

処置: なし。

Re-publishing the ownership for partition %n1 (%n2)

%n1: 所有権が再公開されるパーティションの番号、%n2: プライマリ・パーティションの所有者のノードIDか0(パーティションが孤立している場合)。重大度: 4: デバッグ・レベル4。

原因: サービス・メンバーシップの変更の発生時に、このノードは別のノードにパーティションを転送中であったため、再分散が必要です。このメッセージは、転送中のパーティションに関する所有権の情報をこのノードが再公開していることを示しています。

処置: なし。

%n1> Ownership conflict for partition %n2 with member %n3 (%n4!=%n5)

%n1: 所有権の競合の解決の試行回数、%n2: 所有権の問題が発生しているパーティション、%n3: パーティションの所有権に関する不一致のあるサービス・メンバーのノードID、%n4: このノードの所有権マップにおけるパーティションのプライマリ所有者のノードID、%n5: 別のノードの所有権マップにおけるパーティションのプライマリ所有者のノードID。重大度: 4: デバッグ・レベル4。

原因: パーティション所有者が流動的な状態のときにサービス・メンバーシップの変更が発生すると、一時的に所有権の同期がとれなくなり、調整が必要になる場合があります。このメッセージは、そのような競合が検出され、その解決が試みられていることを示しています。

処置: なし。

Unreconcilable ownership conflict; conceding the ownership

重大度: 1: エラー

原因: パーティション所有者が流動的な状態のときにサービス・メンバーシップの変更が発生すると、一時的に所有権の同期がとれなくなり、調整が必要になる場合があります。このメッセージは、2つのサービス間でパーティションに対する所有権の競合が解決できなかったことを示しています。競合を解決するために、一方のメンバーがパーティションの所有権を強制的に解除され、もう一方のメンバーがパーティションの所有権を上位メンバーに再公開します。

処置: なし

Multi-way ownership conflict; requesting a republish of the ownership

重大度: 1: エラー

原因: パーティション所有者が流動的な状態のときにサービス・メンバーシップの変更が発生すると、一時的に所有権の同期がとれなくなり、調整が必要になる場合があります。このメッセージは、サービス・メンバーと、記憶域が有効な最上位メンバーにパーティションの所有権に関する競合ビューがあることを示しています。競合を解決するために、パーティションの所有者がそのパーティションの所有権を再公開するまでパーティションは孤立していると宣言されます。

処置: なし

Assigned %n1 orphaned primary partitions

%n1: 再割当てされた孤立プライマリ・パーティションの数。重大度: 2: 警告。

原因: このサービス・メンバー(記憶域が有効な最上位のメンバー)により、1つ以上のパーティションにプライマリ所有者がないこと(孤立)が検出されました。複数のノードがサービスから同時に離脱したことが原因だと推定されます。残りのサービス・メンバーは、パーティションの所有権について合意し、その後、上位の記憶域がそれ自体に孤立パーティションを割り当てました。このメッセージの後には、割当て対象の孤立パーティションのリストが続きます。このメッセージは、対応するパーティションのデータが失われる恐れがあることを示しています。

処置: なし。

validatePolls: This service timed-out due to unanswered handshake request Manual intervention is required to stop the members that have not responded to this Poll

重大度: 1: エラー。

原因: ノードがクラスタ化サービスに参加すると、そのサービスを実行する各クラスタ化ノードとハンドシェイクを行います。ハンドシェイク・レスポンスが欠落しているため、このノードはサービスに参加できません。通常、これは応答しない(たとえば、デッドロック)サービス・スレッドにより発生します。

処置: 応答しないサービスを実行しているJVMを見つけてシャットダウンする修正処置が必要となる場合があります。詳細は、My Oracle SupportのNote 845363.1を参照してください。

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=231462233678969&id=845363.1&_afrWindowMode=0&_adf.ctrl-state=lp6w36vgb_4

com.tangosol.net.RequestPolicyException: No storage-enabled nodes exist for service service_name

重大度: 1: エラー。

原因: 記憶域が有効なサービス・メンバーがないサービスに対するキャッシュ・リクエストが発行されました。キャッシュ・リクエストを処理できるのは記憶域が有効なサービス・メンバーに限られるため、記憶域が有効なメンバーが1つ以上は必要です。

処置: 構成/デプロイメントをチェックして、キャッシュ・データを格納する予定のメンバーの記憶域が有効に構成されていることを確認してください。記憶域は、<distributed-scheme要素内の<local-storage要素を使用するメンバーに対して、または-Dcoherence.distributed.localstorageコマンド行オーバーライドを使用して有効化されます。

An entry was inserted into the backing map for the partitioned cache "%s" that is not owned by this member; the entry will be removed"

%s: 挿入が試行されたキャッシュ名。重大度: 1: エラー。

原因: パーティション・キャッシュのバッキング・マップには、そのメンバーが所有するキーのみを格納できます。キャッシュ・リクエストは、リクエストされたキーを所有するサービス・メンバーにルーティングされ、そのサービス・メンバーが、所有するキーのリクエストのみを処理することが保証されます。このメッセージは、メンバーが所有していないキーの挿入がキャッシュのバッキング・マップで検出されたことを示しています。ほとんどの場合、この原因は、キャッシュ・サーバーで実行されるユーザー・コードで、公開キャッシュAPI(たとえば、NamedCache)を使用せずにバッキング・マップが直接使用されたことです。このメッセージの後には、挿入場所を示すJava例外スタック・トレースが続きます。

処置: スタック・トレースで示されたユーザー・コードを調べて、バッキング・マップの操作に問題がないことを確認してください。このエラーは、KeyAssociationの実装方法が不適切であることを示す場合もあります。

Exception occurred during filter evaluation: %s; removing the filter...

%s: 評価時にエラーが発生したフィルタの説明。重大度: 1: エラー。

原因: このキャッシュに登録されたMapListenerのフィルタの評価中に例外がスローされました。そのため、一部のマップ・イベントが発行されない可能性があります。また、以降のエラーの発生を防ぐため、フィルタ(および関連付けられたMapListener)が削除されます。このメッセージの後には、エラーの発生場所を示すJava例外スタック・トレースが続きます。

処置: フィルタの実装および関連するスタック・トレースのエラーを確認してください。

Exception occurred during event transformation: %s; removing the filter...

%s: イベント変換時にエラーが発生したフィルタの説明。重大度: 1: エラー。

原因: 指定されたフィルタが、このキャッシュに登録されたMapListenerに対するMapEventを変換する際に、例外がスローされました。そのため、一部のマップ・イベントが発行されない可能性があります。また、以降のエラーの発生を防ぐため、フィルタ実装(および関連付けられたMapListener)が削除されます。このメッセージの後には、エラーの発生場所を示すJava例外スタック・トレースが続きます。

処置: フィルタの実装および関連するスタック・トレースのエラーを確認してください。

Exception occurred during index rebuild: %s

%s: 索引の再ビルド時に発生した例外のスタック・トレース。重大度: 1: エラー。

原因: 索引の追加または再ビルド中に例外がスローされました。ValueExtractorが正しく実装されていないことが原因として考えられます。このエラーが発生すると、関連する索引が削除されます。このメッセージの後には、エラーの発生場所を示すJava例外スタック・トレースが続きます。

処置: ValueExtractorの実装および関連するスタック・トレースのエラーを確認してください。

Exception occurred during index update: %s

%s: 索引の更新時に発生した例外のスタック・トレース。重大度: 1: エラー。

原因: 索引の更新中に例外がスローされました。ValueExtractorが正しく実装されていないことが原因として考えられます。このエラーが発生すると、関連する索引が削除されます。このメッセージの後には、エラーの発生場所を示すJava例外スタック・トレースが続きます。

処置: ValueExtractorの実装および関連するスタック・トレースのエラーを確認してください。

Exception occurred during query processing: %s

%s: 問合せの処理時に発生した例外のスタック・トレース。重大度: 1: エラー。

原因: 問合せの処理中に例外がスローされました。問合せで使用されるfilterの実装エラーが原因として考えられます。このメッセージの後には、エラーの発生場所を示すJava例外スタック・トレースが続きます。

処置: フィルタの実装および関連するスタック・トレースのエラーを確認してください。

BackingMapManager %s1: returned "null" for a cache: %s2

%s1: nullバッキング・マップを返したBackingMapManager実装のクラス名、%s2: BackingMapManagerからnullが返されたキャッシュの名前。重大度: 1: エラー。

原因: 指定されたキャッシュのバッキング・マップに対して、BackingMapManagerからnullが返されました。

処置: 指定されたBackingMapManagerの実装でエラーがないかを調べて、指定されたキャッシュのバッキング・マップが正しくインスタンス化されることを確認してください。

BackingMapManager %s1: failed to instantiate a cache: %s2

%s1: バッキング・マップの作成に失敗したBackingMapManager実装のクラス名、%s2: BackingMapManagerのエラーが発生したキャッシュの名前。重大度: 1: エラー。

原因: 指定されたキャッシュのバッキング・マップをインスタンス化しようとしたときに、BackingMapManagerから予期しない例外がスローされました。

処置: 指定されたBackingMapManagerの実装でエラーがないかを調べて、指定されたキャッシュのバッキング・マップが正しくインスタンス化されることを確認してください。

BackingMapManager %s1: failed to release a cache: %s2

%s1: バッキング・マップの解放に失敗したBackingMapManager実装のクラス名、%s2: BackingMapManagerのエラーが発生したキャッシュの名前。重大度: 1: エラー。

原因: 指定されたキャッシュのバッキング・マップを解放しようとしたときに、BackingMapManagerから予期しない例外がスローされました。

処置: 指定されたBackingMapManagerの実装でエラーがないかを調べて、指定されたキャッシュのバッキング・マップが正しく解放されることを確認してください。

Unexpected event during backing map operation: key=%s1; expected=%s2; actual=%s3

%s1: キャッシュで変更されていたキー、%s2: 進行中のキャッシュ操作から予期されるバッキング・マップ・イベント、%s3: 受信した実際のMapEvent。重大度: 6: デバッグ・レベル6。

原因: キャッシュ操作の実行中に、バッキング・マップで予期しないMapEventを受信しました。これは、バッキング・マップ上で同時操作が直接実行されたことを示しており、その原因はほとんどの場合、キャッシュ・サーバーで実行されるユーザー・コードで公開キャッシュAPI(たとえば、NamedCache)を使用せずにバッキング・マップが直接操作されたことです。

処置: バッキング・マップを直接変更する可能性があるユーザー・コードを調べて、バッキング・マップの操作に問題がないことを確認してください。

Application code running on "%s1" service thread(s) should not call %s2 as this may result in deadlock The most common case is a CacheFactory call from a custom CacheStore implementation

%s1: リエントラント・コールを実行したサービスの名前、%s2: リエントラント・コールが実行されたメソッドの名前。重大度: 2: 警告。

原因: 指定されたサービスでアプリケーション・コードを実行中に、リエントラント・コール(同一サービスに対するリクエスト)が実行されました。Coherenceでは、リエントラント・サービス・コールをサポートしていないため、サービス・スレッド上で実行されるあらゆるアプリケーション・コード(CacheStore、EntryProcessorなど)でキャッシュ・リクエストが発行されないようにする必要があります。

処置: サービス・スレッド上で実行されるアプリケーション・コードからリエントラント・コールを削除し、Oracle Coherenceによるアプリケーション開発で概要を説明している代替設計戦略を使用することを検討してください。

Repeating %s1 for %n1 out of %n2 items due to re-distribution of %s2

%s1: 再送信が必要なリクエストの説明、%n1: 再分散により未処理になった項目の数、%n2: リクエストされた項目の合計数、%s2: 再分散処理を実行中のためリクエストの再送信が必要なパーティションのリスト。重大度: 5: デバッグ・レベル5。

原因: キャッシュ・リクエストの発行時に、リクエストが参照するパーティションを所有するサービス・メンバーにリクエストが送信されました。リクエストが参照する1つ以上のパーティションで(たとえば、再分散などによる)転送処理を実行中の場合は、リクエストが(転送前の)パーティション所有者によって拒否され、新しいパーティション所有者に自動的に再送信されます。

処置: なし。

Error while starting cluster: com.tangosol.net.RequestTimeoutException: Timeout during service start: ServiceInfo(%s)

%s: 開始できないサービスに関する情報。重大度: 1: エラー。

原因: サービスへの参加時、クラスタ内のすべてのサービスが参加リクエストに応答する必要があります。1つ以上のノードに、タイムアウト期間内に応答しないサービスがあると、参加はタイムアウトします。

処置: My Oracle SupportのNote 845363.1を参照してください。

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=231462233678969&id=845363.1&_afrWindowMode=0&_adf.ctrl-state=lp6w36vgb_4

Failed to restart services: com.tangosol.net.RequestTimeoutException: Timeout during service start: ServiceInfo(%s)

%s: 開始できないサービスに関する情報。重大度: 1: エラー。

原因: サービスへの参加時、クラスタ内のすべてのサービスが参加リクエストに応答する必要があります。1つ以上のノードに、タイムアウト期間内に応答しないサービスがあると、参加はタイムアウトします。

処置: My Oracle SupportのNote 845363.1を参照してください。

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=231462233678969&id=845363.1&_afrWindowMode=0&_adf.ctrl-state=lp6w36vgb_4

Failed to recover partition 0 from SafeBerkeleyDBStore(...); partition-countmismatch 501(persisted) != 277(service); reinstate persistent store fromtrash once validation errors have been resolved

原因: アクティブ永続性が有効化されている間にパーティション数が変更されました。現在のアクティブなデータはごみ箱ディレクトリにコピーされます。

処置: 次の手順を完了してデータをリカバリします。

1. クラスタ全体を停止します。

2. 各クラスタ・メンバーで影響を受けたクラスタとサービスで現在アクティブなディレクトリの内容を削除します。

3. アクティブなディレクトリへのサービスごとに、ごみ箱ディレクトリの内容を(再帰的に)コピーします。

4. パーティション数を元の値にリストアします。

5. クラスタを再起動します。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。