ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Coherenceの管理
12c (12.1.3)
E56211-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

6 本番チェックリスト

この章では、開発環境またはテスト環境から本番環境に移行するときに、計画および考慮する必要のある分野についてのチェックリストを示します。説明されているソリューションとベスト・プラクティスについては、必要に応じて実装する必要があります。Coherence*Extendを使用するときの追加の推奨事項は、Oracle Coherenceのリモート・クライアントの開発を参照してください。

この章には次の項が含まれます:

6.1 データグラムとマルチキャストの推奨事項

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

データグラム・テスト・ユーティリティを実行して実際のネットワーク速度をテストし、大量のデータをプッシュするためのネットワーク容量を確認する必要があります。本番デプロイメントの前に、データグラム・テストの実行が成功する必要があります。詳細は、第3章「ネットワーク・パフォーマンス・テストの実行」を参照してください。さらに、パブリッシャとコンシューマの比率を高めてデータグラム・テスト・ユーティリティを実行する必要もあります。単一パブリッシャと単一コンシューマでは良好に見えるネットワークも、パブリッシャの数が増加すると完全に機能しなくなる可能性があります。

マルチキャストの使用の検討

マルチキャストという用語は、1台のサーバーから情報パケットを送信し、そのパケットをネットワークによって複数のサーバーに並列的に配信する機能を意味します。Coherenceは、マルチキャストとマルチキャストフリーの両方のクラスタリングをサポートしています。マルチキャストは多くのサーバー通信に有効なオプションであるため、可能なかぎりマルチキャストを使用することをお薦めします。また、可能な場合は、既知の専用マルチキャスト・アドレスを使用して、マルチキャストの可用性を確保してください。

ただし、次のような理由からマルチキャストを使用できない場合があります。

マルチキャストの可用性テスト

マルチキャスト・テストを実行して、マルチキャストが機能するかどうかを検証し、本番環境に適した(最小の)TTL値を確認する必要があります。本番デプロイメントの前に、マルチキャスト・テストの実行が成功する必要があります。詳細は、第4章「マルチキャスト接続テストの実行」を参照してください。

デプロイメントにマルチキャストを使用できないアプリケーションでは、ユニキャストを使用し、ウェル・ノウン・アドレスを設定する必要があります。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

ネットワーク・デバイスの構成

データグラムまたはマルチキャスト・テストのどちらかが失敗した場合や、結果が良好でない場合は、使用中のネットワーク・デバイスに構成上の問題がある可能性があります。またテストが問題なく終了し、結果が完璧であっても、ネットワーク・デバイスの構成に問題が潜んでいる可能性があります。

「ネットワークのチューニング」の推奨事項を確認してください。

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

一意のクラスタの作成

一意のクラスタにより、クラスタ・メンバーがネットワーク上の既存のクラスタに間違って参加することがなくなります。クラスタの完全な分離を確実にするには、各クラスタに専用のマルチキャストIPアドレスとポートを構成し、一意のクラスタ名を構成します。詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

クラスタ化環境でのテスト

POCまたはプロトタイプ段階が完了してからロード・テストが開始されるまでの間、アプリケーションが非クラスタ化構成で開発およびテストされることは珍しくありません。主なテストを非クラスタ化構成で実行すると、アプリケーションのアーキテクチャや実装上の問題が検出されず、後の段階、さらには本番に移行してから問題が発覚する可能性があります。

アプリケーションを本番稼働する前に、必ずクラスタ化構成でテストしてください。クラスタ化されたテストが開発プロセスに自然に含まれるようにするには、いくつかの方法があります。例:

本番ネットワークの速度の評価

ほとんどの本番ネットワークは、ギガビット・イーサネット(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の通信が許可されるように、必要に応じてファイアウォールを構成してください。次のリストは、一般的なデフォルト・ポートと、ポートを構成する追加の分野を示しています。

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

この項で説明する推奨事項は、キャッシュのおおよそのサイズを計算するために使用します。キャッシュに必要なサイズを把握することは、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バイト

索引コストは、小さなオブジェクトに対しては比較的高いものになりますが、これは定数であるためオブジェクトが大きくなるほどコストが低くなります。

キャッシュのサイズ設定は、厳密な技法ではありません。オブジェクトのサイズと最大数について仮定する必要があります。完全な例は、次のとおりです。

次のように、索引サイズを計算します。

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%)

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

現実的な負荷テストの計画

一般に、デプロイメントは、比較的高速なワークステーションで行われます。さらに、通常、テストはクラスタ化されていない状態で行われ、単一のユーザー・アクセス(開発者のみ)を示す傾向があります。このような環境では、アプリケーションの応答性が非常に高く観測されることがあります。

本番環境に移行する前に、クラスタ構成内で同時ユーザーの負荷をシミュレートした現実的な負荷テストが実行されていることを確認してください。

本番環境に移行する前の適切なハードウェアでの開発

Coherenceは、すべての一般的なワークステーション・ハードウェアと互換性があります。開発者は通常、ノートブック、デスクトップ、ワークステーションなどを含むPCまたはAppleハードウェアを使用しています。

開発者のシステムには、最新のIDE、デバッガ、アプリケーション・サーバー、データベースおよび少なくとも2つのクラスタ・インスタンスを実行するための膨大なRAMが必要です。メモリーの使用方法は様々ですが、開発者のシステムの生産性を保証するには、2GB以上のメモリー構成が推奨されます。

サーバー・ハードウェア・プラットフォームの選択

オラクル社では、お客様によって標準化されたハードウェアまたは本番デプロイメント用に選択されたハードウェアをサポートするよう努めています。

サーバー・ハードウェアをまだ購入していない場合は、次の推奨事項に留意してください。

サーバーのRAMは4GB以上に構成することを強くお薦めします。大容量(数十GBから数百GB、またはそれ以上)のデータをメモリーに格納するアプリケーションでは、1台のサーバー当たり16GBまたは32GBのRAMのコスト効果を評価してください。また、大容量のRAMを搭載したサーバーは、その分だけ1台で実行する必要のあるCoherenceノード(JVM)の数も多くなるため、CPUコアの数を増やすと効果的であることに注意してください。データ量の多いアプリケーションではCPUに対するRAMの比率を高くし、処理量の多いアプリケーションではその比率を低くする必要があります。たとえば、IDベースの操作(キャッシュのアクセスと更新)が主体の15個のCoherenceキャッシュ・サーバー・ノードを実行するサーバーでは、RAMを32GB、CPUを2つのデュアルコアXeonにすれば十分な場合がありますが、アプリケーションで索引付け、並列問合せ、エントリ・プロセッサ、並列集計などのCoherence機能を頻繁に使用する場合は、サーバーのRAMを16GB、CPUを2つのクアッドコアXeonにするとより効果的です(CPU対RAMの比率が4対1に増加するため)。

ネットワーキングには、1000Mbps以上(たとえば、ギガビット・イーサネット以上)を強く推奨します。NICは、標準のPCIではなく、PCI-XやPCIeなどの高帯域幅のバスに配置します。

サーバー数の計画

Coherenceは本質的にはスケールアウト・テクノロジです。ナチュラル・モードの操作は、多数のサーバー(たとえば、2ソケットまたは4ソケットの商用サーバー)におよびます。ただし、Coherenceは、サーバーごとに複数のJVMを使用することで、効率的に少数の大規模サーバーにスケール・アップすることもできます。フェイルオーバーとフェイルバックは、クラスタ内に存在するサーバー数が多くなるほど効率が高くなり、1つのサーバー障害の影響が軽減されます。1つのクラスタには、最小で4台の物理サーバーを含めて、障害時のデータ損失の可能性を最小限に抑える必要があります。一般的なWAN構成では、データ・センターごとに独立したクラスタ(通常はExtend-TCPで相互接続されます)を配置します。これにより、個々のサーバーの合計数(1データ・センター当たり4台のサーバー×データ・センター数)は増加します。

Coherenceは小規模なクラスタ(物理サーバー1台から3台)にデプロイされることも多くありますが、その場合、負荷の高い状況でサーバーに障害が発生したときのリスクが増大します。「本番ネットワークの速度の評価」の項で説明したように、Coherenceクラスタは、単一スイッチの範囲内に限定することが理想的です(例: 物理サーバー96台未満)。使用例によっては、コンピュートバウンドまたはメモリーバウンドのアプリケーションは(ネットワークバウンドアプリケーションに比べて)、大規模なクラスタの方が満足に動作する場合もあります。

また、多数のJVMを使用する少数のクラスタと、少数のJVMを使用する多数のクラスタとでは、後者が適切なオプションである場合がありますCoherenceの本番環境には、数百ものJVMを使用するケースがあります。この規模のクラスタを適切に準備するには注意が必要ですが、JVMが数十台しかない小規模なクラスタは簡単に実現します。WKAを使用してUDPマルチキャストを無効にしたり、低速ネットワーク(100Mbpsイーサネットなど)を使用したりすると、ネットワーク効率が低下し、スケーリングが困難になることに注意してください。

JVMの使用数に基づいた必要なサーバー数の判断

信頼性のある、可用性の高い構成に必要なサーバー数を決定したり、記憶域として機能するJVM数の構成方法を決定するには、次の規則に従います。

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

オペレーティング・システムの選択

オラクル社では次のオペレーティング・システム上でのテストを実行し、これらのオペレーティング・システムをサポートしています。

コモディティx86サーバーには、Linuxディストリビューション(Linux 2.6カーネル以上)が推奨されます。Linuxディストリビューションのほとんどは、Coherenceの実行に適した環境を提供することが予想されますが、オラクル社ではさらに、Oracle Linux (Unbreakable Enterprise Kernelを使用したOracle Linuxを含む)や、Red Hat Enterprise Linux(バージョン4以上)、Suse Linux Enterprise(バージョン10以上)などをお薦めします。

Coherenceのデプロイ先オペレーティング・システムについては、第2章「プラットフォーム固有のデプロイに関する考慮事項」を確認し、その指示に従ってください。


注意:

開発用と本番用のオペレーティング・システムは異なる場合があります。対象とする本番用オペレーティング・システムを定期的にテストするようにしてください。

仮想メモリー(ディスクへのページング)の使用は避けます。

Coherenceベースのアプリケーションでは、主要なデータ管理の役割(専用キャッシュ・サーバーなど)がJavaベースのプロセスでホストされます。最新のJavaディストリビューションは、仮想メモリーでは効率よく機能しません。特にガベージ・コレクション(GC)操作では、メモリーがディスクにページングされる場合、桁違いに速度が低下することがあります。適切にチューニングされたJVMでは、すべてのGCを1秒未満で実行できます。しかし、JVMが部分的にディスクに存在する場合は、実行に何分もかかるようになります。ガベージ・コレクションの実行中、ノードは長時間無応答になるため、クラスタ内の他のノードの選択肢は、無応答ノードの応答を待つ(この間、アプリケーションのアクティビティは部分的にブロックされます)か、無応答ノードを障害ノードとみなしてフェイルオーバー処理を実行するかのいずれかになります。どちらにしても適切な選択ではないため、ガベージ・コレクションによる過度の一時停止を避けることが重要です。JVMは設定ヒープ・サイズで構成して、ヒープが使用可能なRAMメモリーを使い果たさないようにする必要があります。さらに、定期的なプロセス(日次バックアップ・プログラムなど)は、メモリー使用の急増によってCoherenceのJVMがディスクにページングされるないようにモニターする必要があります。

「スワッピング」も参照してください。

ソケット・バッファ・サイズの増加

オペレーティング・システムのソケット・バッファを大きくして、ガベージ・コレクション時にJavaアプリケーションが一時停止している間に受信ネットワーク・トラフィックを処理できるようにする必要があります。UNIXのほとんどのバージョンではデフォルトのバッファ制限が非常に小さく設定されていますが、これを2MBに増大する必要があります。

「ソケット・バッファ・サイズ」も参照してください。

6.6 JVMの推奨事項

開発段階では、開発者は一般に、最新のOracle HotSpot JVM、またはMac OS X JVMなどの直接派生製品を使用します。

本番環境で異なるJVMを使用する場合、主に次のような問題が生じます。

所定のテストは、必ず本番環境で使用するJVMで実行してください。

JVMの選択

Oracle Coherenceでは次のバージョンのJVMをサポートしています。

JVMの選択は、他のソフトウェアにも左右される場合があります。例:

LinuxまたはWindowsを実行する商用x86サーバーでは、Oracle HotSpot JVMを使用します。一般に、最新バージョンを使用する必要があります。


注意:

テストおよびデプロイメントには、プラットフォームおよびCoherenceバージョンに基づいてサポートされる、最新のOracle HotSpot JVMを使用します。

本番に移行する前に、JVMのベンダーとバージョンを選択して十分にテストし、そのJVMでテスト中およびステージング中に検出されたすべての不具合を修正する必要があり、本番への移行には、そのJVMを使用することをお薦めします。間断ない可用性が要求されるアプリケーションでは、承認の前に、そのJVMで長期にわたる(少なくとも2週間)アプリケーション・ロード・テストを実行する必要があります。

Coherenceのデプロイ先JVMについては、第2章「プラットフォーム固有のデプロイに関する考慮事項」を確認し、その指示に従ってください。

JVMオプションの設定

JVMの構成オプションはバージョンおよびベンダーによって異なりますが、一般には次のことをお薦めします。特定のJVMの考慮事項については、第2章「プラットフォーム固有のデプロイに関する考慮事項」を参照してください。

混合JVM環境をテストするための計画

CoherenceはPure Javaソフトウェアであるため、クラスタ内のJVMのベンダーとバージョンがどのような組合せであっても実行できます。オラクル社では、このような構成についてもテストしています。

JVMが異なると、Javaオブジェクトのシリアライズ形式も若干異なる可能性があることに注意してください。したがって、あるJVMでシリアライズされたオブジェクトがネットワークを介してベンダーやバージョンの異なるJVMに渡された場合、そのJVMでオブジェクトをデシリアライズしようとすると、非互換性の問題が生じる可能性があります。幸いにも、Javaのシリアライズ形式はここ数年変わっていないため、この種の問題が発生する可能性はほとんどありません。しかし、本番環境にデプロイする前に、混合構成をテストして、シリアライズの整合性を確認することを強くお薦めします。

次の各項も参照してください。

6.7 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には次の最適化が含まれます。

より少ない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を使用します。別のトランスポート・プロトコルを使用してパフォーマンスの改善を確認できます。ただし、プロトコルの変更を検討するのは、この項で前に説明した推奨事項に従った後のみにする必要があります。

次のトランスポート・プロトコルが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="tangosol.coherence.transport.reliable">imb
         </reliable-transport>
      </unicast-listener>
   </cluster-config>
</coherence>

tangosol.coherence.transport.reliableシステム・プロパティも信頼性のあるトランスポートを構成します。例:

-Dtangosol.coherence.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>

各サービス・タイプにも、それぞれ信頼性のあるトランスポートを設定するシステム・プロティがあります。このシステム・プロパティは、サービス・タイプのすべてのインスタンスに対して信頼性のあるトランスポートを設定します。システム・プロパティは次のとおりです。


tangosol.coherence.distributed.transport.reliable
tangosol.coherence.replicated.transport.reliable
tangosol.coherence.optimistic.transport.reliable
tangosol.coherence.invocation.transport.reliable
tangosol.coherence.proxy.transport.reliable

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

セキュリティ権限の確保

Coherenceの機能に最低限必要とされる権限セットは、security.policyファイル内で指定されています。これは、Coherenceインストールの一部として同梱されています。このファイルは、coherence/lib/security/security.policyにあります。Javaセキュリティ・マネージャを使用する場合は、Coherenceが正常に機能するように、これらの権限を付与する必要があります。

SSL要件に対する計画

Coherenceベースのアプリケーションは、必要に応じて様々なレベルのセキュリティを実装できます。このセキュリティには、クラスタ・メンバー間、およびCoherence*Extendクライアントとクラスタ間のSSLベースのセキュリティが含まれます。SSLが要件になる場合、信頼できる認証局によって検証および署名されたデジタル証明書がすべてのサーバーに用意されていることを確認します。また、そのデジタル証明書が、必要に応じてサーバーのキー・ストアと信頼ストアにインポートされていることも確認します。Coherence*Extendクライアントには、信頼キー・ストアが含まれている必要があります。このストアには、プロキシのデジタル証明書の署名に使用された認証局のデジタル証明書を格納します。SSLの設定手順の詳細は、Oracle Coherenceのセキュリティ保護を参照してください。

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

Javaベースの管理およびモニタリングのソリューションには、インストゥルメンテーション(バイトコード操作やClassLoader置換など)を使用しているものがあります。オラクル社は、過去に、そのようなソリューションに問題があることを見つけています。このようなソリューションは、主要なベンダーから現時点で問題が報告されていない場合でも慎重に使用してください。

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

本番モードの選択

Coherenceは、評価モード、開発モードまたは本番モードで動作するように構成できます。これらのモードには機能に対するアクセス制限はありませんが、デフォルトの構成設定が一部異なります。たとえば開発モードでは、開発プロセスを簡略化するために、クラスタを高速起動できます。

開発モードは、開発やテストなどの本番前のあらゆるアクティビティに使用します。これは、開発ノードは本番ノードへの参加が制限されているために、重要な安全機能になります。開発モードは、デフォルトのモードです。本番モードは、Coherenceを本番環境で使用するときに明示的に指定する必要があります。本番モードにモードを変更するには、tangosol-coherence.xml (coherence.jar内にあります)を編集して、<license-mode>要素の値としてprodを入力します。例:

...
<license-config>
   ...
   <license-mode system-property="tangosol.coherence.mode">prod</license-mode>
</license-config>
...

オペレーション・デプロイメント・ディスクリプタではなく、tangosol.coherence.modeシステム・プロパティを使用して、ライセンス・モードを指定します。例:

-Dtangosol.coherence.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>要素内に、表6-1に定義されているエディション名を含む<edition-name>を追加します。例:

...
<license-config>
   <edition-name system-property="tangosol.coherence.edition">EE</edition-name>
</license-config>
...

オペレーション・デプロイメント・ディスクリプタではなく、tangosol.coherence.editionシステム・プロパティを使用して、ライセンス・エディションを指定します。例:

-Dtangosol.coherence.edition=EE

表6-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用のリモート・クライアントの開発を参照してください。

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

オペレーション構成は、tangosol-coherence.xmlで定義されるクラスタ・レベル構成に関連するもので、次の項目が含まれます。

通常、オペレーション構成はtangosol-coherence-override.xmlファイルを使用して構成します。オペレーション・オーバーライド・ファイルの指定方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

このファイルの内容は、多くの場合、開発環境と本番環境とで異なります。2つの環境には大きな相違があるため、ファイルの内容の相違は環境ごとに個別に管理することをお薦めします。本番オペレーション構成ファイルは、本番システムの動作を熟知したシステム管理者が保守する必要があります。

すべてのクラスタ・ノードは、同一のオペレーション構成オーバーライド・ファイルを使用する必要があり、ノード固有の値はシステム・プロパティを使用して指定する必要があります。システム・プロパティの詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。集中型の構成ファイルは、各クラスタ・ノードのtangosol.coherence.overrideシステム・プロパティの値として、URLを指定することで保守およびアクセスできます。例:

-Dtangosol.coherence.override=/net/mylocation/tangosol-coherence-override.xml

オーバーライド・ファイルには、変更するオペレーション要素のみを含める必要があります。さらに、id属性とsystem-property属性が要素に定義されている場合は、それらの属性を必ず含めます。

各オペレーション要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

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

キャッシュ構成は、キャッシュ・レベルの構成に関連するもので、次の内容が含まれます。

通常、キャッシュ構成はcoherence-cache-config.xmlファイルを使用して構成します。キャッシュ構成ファイルの指定方法の詳細は、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

coherence.jarに含まれるデフォルトのcoherence-cache-config.xmlファイルは、サンプルとして提供されているもので、本番環境での使用には適しません。アプリケーション固有の定義には、必ずキャッシュ構成ファイルを使用してください。

すべてのクラスタ・ノードは、可能な場合は、同じキャッシュ構成ディスクリプタを使用する必要があります。集中型の構成ファイルは、各クラスタ・ノードのtangosol.coherence.cacheconfigシステム・プロパティの値として、URLを指定することで保守およびアクセスできます。例:

-Dtangosol.coherence.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>サブ要素を使用します。キャッシュ・ストアベース以外のキャッシュでは、スレッドを増やしてもパフォーマンスが向上する可能性がないため、スレッドは無効にしたままにします。

明示的に指定しないかぎり、いずれのクラスタ・ノードも記憶域が有効化されます。つまり、キャッシュ・サーバーとして機能します。したがって、本番環境で記憶域を有効化および無効化するノードを制御することが重要になります。記憶域を制御するには、tangosol.coherence.distributed.localstorageシステム・プロパティをtrueまたはfalseに設定します。一般に、専用キャッシュ・サーバーの記憶域のみを有効にします。その他のクラスタ・ノードはすべて、記憶域を無効にするように構成します。これは、なんらかの作業のためにクラスタに参加して、その後でクラスタから離れるような短期間プロセスには特に重要です。このようなノードの記憶域が有効にしてあると、不要な再パーティション化が発生します。

各キャッシュ構成要素の詳細なリファレンスは、『Oracle Coherenceでのアプリケーションの開発』を参照してください。

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

6.14 停止検出の推奨事項

Coherenceの停止検出アルゴリズムは、2つ以上のクラスタ・ノード間で発生する持続的な接続の切断に基づいています。他のノードとの接続が失われたことを認識したノードは、どのような処理を行う必要があるかを他のクラスタ・ノードに相談します。

他のノードに相談しようとしたときに、このノードは他のどのノードとも通信できないことを知り、自身がクラスタから切り離されたものと推測します。このような状況は、ノードのネットワーク・アダプタのプラグを物理的に抜くことによって発生する可能性があります。このようなイベントでは、切り離されたノードは自身のクラスタ化サービスを再起動して、クラスタに参加しなおそうとします。

それでも他のクラスタ・ノードと接続できない場合、このノードはウェル・ノウン・アドレスの構成に応じて、新しい独立したクラスタを形成するか、さらに大規模なクラスタを探し続けます。いずれの場合も、接続が回復すると、切り離されたクラスタ・ノードは実行中のクラスタに再び参加します。クラスタに再び参加する過程で、ノードの以前のクラスタ状態は、保持していたキャッシュ・データも含めて破棄されます。これは、そのデータの所有権がクラスタ内の残りのノードによって(バックアップからリストアすることで)引き継がれているためです。

接続が失われた状態では、ノードが別のノードの状態を識別できないことは明らかです。単一ノードの場合、ローカル・ネットワーク・アダプタの障害も、ネットワーク全体のスイッチ障害もまったく同じに見えるため、これらの障害はいずれも前述のように同じ方法で処理されます。重要な違いは、スイッチ障害の場合、すべてのノードがクラスタに参加しなおそうとするため、クラスタ全体を再起動することと同じことになり、以前の状態とデータがすべて削除されるという点です。

すべてのデータが削除されることは望ましくないため、スイッチ障害時にこれを回避するには、追加の予防策をとる必要があります。次のオプションがあります。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次