| Oracle® Fusion Middleware Oracle Coherenceの管理 12c (12.2.1) E69908-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
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に増大する必要があります。
関連項目: 「ソケット・バッファ・サイズ」
開発段階では、開発者は一般に、最新の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 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.reliablecoherence.replicated.transport.reliablecoherence.optimistic.transport.reliablecoherence.invocation.transport.reliablecoherence.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を本番環境で使用するときに明示的に指定する必要があります。本番モードにモードを変更するには、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用のリモート・クライアントの開発を参照してください。
オペレーション構成は、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でのアプリケーションの開発』を参照してください。
キャッシュ構成は、キャッシュ・レベルの構成に関連するもので、次の内容が含まれます。
キャッシュ・トポロジ(<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のチーミングを参照してください。
