| Oracle® Coherence管理者ガイド リリース3.7.1 B71688-01 |
|
 前 |
 次 |
この章では、開発環境またはテスト環境から本番環境に移行するときに、計画および考慮する必要のある分野についてのチェックリストを示します。実装するソリューションとベスト・プラクティスについては、必要に応じて説明します。Coherence*Extendを使用するときの追加の推奨事項は、『Oracle Coherenceクライアント・ガイド』を参照してください。
この章には次の項が含まれます:
一意のクラスタの作成
一意のクラスタにより、クラスタ・メンバーがネットワーク上の既存のクラスタに間違って参加することがなくなります。クラスタの完全な分離を確実にするには、各クラスタに専用のマルチキャストIPアドレスとポートを構成し、一意のクラスタ名を構成します。詳細は、『Oracle Coherence開発者ガイド』を参照してください。
クラスタ環境でのテスト
POCまたはプロトタイプ段階が完了してからロード・テストが開始されるまでの間、アプリケーションが非クラスタ構成で開発およびテストされることは珍しくありません。主なテストを非クラスタ構成で実行すると、アプリケーションのアーキテクチャや実装上の問題が検出されず、後の段階、さらには本番に移行してから問題が発覚する可能性があります。
アプリケーションを本番稼働する前に、必ずクラスタ構成でテストしてください。たとえば、次のような方法を使用すれば、開発工程にもクラスタ構成のテストを簡単に組み込むことができます。
開発者は、ローカルにクラスタ化した構成(開発者自身のコンピュータで2つ以上のインスタンスを実行する構成)でテストしてください。単一のコンピュータでのクラスタ化はTTL=0設定で機能するため、この方法は、TTL=0と設定するだけで実現します。
クラスタ化したテスト環境にユニット・テストおよびリグレッション・テストを導入します。この方法は、開発者個人では忘れてしまったり、時間がなくて実行できないようなクラスタ構成でのテストを自動的に実行する場合に役立ちます。
本番ネットワークの速度の評価
ほとんどの本番ネットワークは、ギガビット・イーサネット(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のリンクによって制限されます。実際の制限は、サーバーごとのトラフィックや、リンク上を実際に移動するトラフィックの量に応じて、かなり高くなる場合があります。また、ネットワーク・プロトコルのオーバーヘッドや不規則なトラフィック・パターンなどの要素によっても、使用可能な範囲がアプリケーション・パースペクティブから大幅に減少する場合があります。
ネットワーク速度の混在および競合は避けてください。すべてのサーバーが同じ速度でネットワークに接続でき、サーバー間のすべてのスイッチとルーターが同じ速度またはより高い速度で実行されるようにします。
アプリケーションをデプロイする前に、データグラム・テスト・ユーティリティを実行して実際のネットワーク速度をテストし、大量のデータをプッシュするためのネットワーク容量を確認する必要があります。詳細は、第4章「ネットワーク・パフォーマンス・テストの実行」を参照してください。さらに、パブリッシャとコンシューマの比率を高めてデータグラム・テスト・ユーティリティを実行する必要もあります。単一パブリッシャと単一コンシューマでは良好に見えるネットワークも、パブリッシャの数が増加すると完全に機能しなくなる可能性があり、このような現象がCisco 6500シリーズ・スイッチのデフォルト構成で発生しているためです。詳細は、「Cisco社製スイッチへのデプロイ」を参照してください。
マルチキャストの使用の検討
マルチキャストという用語は、1台のサーバーから情報パケットを送信し、そのパケットをネットワークによって複数のサーバーに並列的に配信する機能を意味します。Coherenceは、マルチキャストとマルチキャストフリーの両方のクラスタ化をサポートしています。マルチキャストは多くのサーバー通信に有効なオプションであるため、可能なかぎりマルチキャストを使用することをお薦めします。また、可能な場合は、既知の専用マルチキャスト・アドレスを使用して、マルチキャストの可用性を確保してください。
ただし、次のような理由からマルチキャストを使用できない場合があります。
マルチキャストの使用が組織で許可されていません。
特定のタイプのネットワーク装置でマルチキャストが機能しない。たとえば、WANルーターの多くは、マルチキャスト・トラフィックを使用できないかサポートしていません。
技術的な理由によりマルチキャストが使用できない。たとえば、スイッチによってはマルチキャスト・トラフィックがサポートされていない場合があります。
最初に、目的のデプロイメント構成にマルチキャストを使用するかどうかを決定します。
マルチキャストを使用するアプリケーションをデプロイする前に、マルチキャスト・テストを実行して、マルチキャストが機能するかどうかを検証し、本番環境に適した(最小の)TTL値を確認する必要があります。詳細は、第5章「マルチキャスト接続テストの実行」を参照してください。
デプロイメントにマルチキャストを使用できないアプリケーションでは、WKA構成を使用する必要があります。詳細は、『Oracle Coherence開発者ガイド』を参照してください。
ネットワーク・デバイスの構成
データグラム・テストとマルチキャスト・テストのどちらかが失敗した場合や、結果が良好でない場合は、使用中のネットワーク・デバイスに構成上の問題がある可能性があります。またテストが問題なく終了し、結果が完璧であっても、ネットワーク・デバイスの構成に問題が潜んでいる可能性があります。
「ネットワークのチューニング」の推奨事項を確認してください。
継続的なネットワーク停止に対する計画
Coherenceのクラスタ・プロトコルは、様々な接続障害を検出して処理できます。クラスタ・サービスは、接続の問題を識別し、問題のあるクラスタ・ノードを強制的に切り離して、再びクラスタに参加させることができます。このようにして、クラスタでは、一貫性のある共有状態がメンバー間で確実に維持されます。
詳細は、「停止検出の推奨事項」を参照してください。また、「Cisco社製スイッチへのデプロイ」も参照してください。
この項で説明する推奨事項は、キャッシュのおおよそのサイズを計算するために使用します。キャッシュに必要なサイズを把握することは、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%の領域を追加して余裕を持たせます。
JVMのメモリー要件を追加した場合、キャッシュのメモリー要件の完全な計算式は、次のように表されます。
キャッシュ・メモリーの要件 = ((キャッシュ・エントリのサイズ + 索引のサイズ) × 2 (プライマリおよびバックアップ用)) + JVMの作業用メモリー(1GB JVMの約30%)
現実的な負荷テストの計画
一般に、デプロイメントは、比較的高速なワークステーションで行われます。さらに、通常、テストはクラスタ化されていない状態で行われ、単一のユーザー・アクセス(開発者のみ)を示す傾向があります。このような環境では、アプリケーションの応答性が非常に高く観測されることがあります。
本番環境に移行する前に、クラスタ構成内で同時ユーザーの負荷をシミュレートした現実的な負荷テストが実行されていることを確認してください。
本番環境に移行する前の適切なハードウェアでの開発
Coherenceは、すべての一般的なワークステーション・ハードウェアと互換性があります。開発者は通常、ノートブック、デスクトップ、ワークステーションなどを含むPCまたはAppleハードウェアを使用しています。
開発者のシステムには、最新のIDE、デバッガ、アプリケーション・サーバー、データベースおよび少なくとも2つのクラスタ・インスタンスを実行するための膨大なRAMが必要です。メモリーの使用方法は様々ですが、開発者のシステムの生産性を保証するには、2GB以上のメモリー構成が推奨されます。通常、デスクトップ・システムおよびワークステーションは、4GBに構成できます。
開発者のシステムには、マルチスレッド化に関連するコードの品質を向上するために、複数のCPUコアが搭載されている必要があります。複数スレッドの同時実行に関連する不具合の多くは、マルチCPUシステム(複数のプロセッサ・ソケットまたはCPUコアを含むシステム)でのみ確認できます。
サーバー・ハードウェア・プラットフォームの選択
オラクル社では、お客様によって標準化されたハードウェアまたは本番デプロイメント用に選択されたハードウェアをサポートするよう努めています。
オラクル社のお客様は、ほぼすべての主要なサーバー・ハードウェア・プラットフォームを使用しています。その大多数はコモディティx86サーバーを使用しており、Sun Sparc (Niagraを含む)サーバーおよびIBM Powerサーバーを使用しているお客様もかなりいます。
オラクル社では、IntelとAMDの両方のコモディティx86サーバーでCoherenceを継続的にテストしています。
オラクル社は、Intel、Apple、IBMの各社から、ハードウェア、チューニング・アシスタントおよびテスト・サポートの提供を受けています。
オラクル社では、すべてのIBMサーバー・プラットフォームに対するCoherenceの内部認定を実施しています。
オラクル社およびAzul社では、48コアのVega 2チップを含め、Azulアプライアンスに対するCoherenceのテストを定期的に実施しています。
サーバー・ハードウェアをまだ購入していない場合は、次の推奨事項に留意してください。
最もコスト効果の高いサーバー・ハードウェア・プラットフォームは、1から2個のプロセッサ・ソケットと1プロセッサ・ソケット当たり2から4個のCPUコアを搭載する、IntelまたはAMDのコモディティx86です。AMDオペレーティング・システムを選択する場合は、プロセッサ・ソケットを2つ搭載しているシステムを強く推奨します。単一ソケット・システムでは、通常、メモリー容量が半分になるためです。Intelの場合は、以前のIntel Xeon CPUよりも、WoodcrestおよびClovertown Xeonを強く推奨します。新しいXeonでは、64ビットのサポートが著しく進化し、消費電力と熱放射が大幅に低減され、パフォーマンスが格段に向上しています。これらの新しいXeonは、現時点で最速のコモディティx86 CPUです。また、FB-DIMMと呼ばれる完全バッファ型メモリーを使用することで、プロセッサ・ソケットの数に関係なく、サーバーごとに大容量のメモリーをサポートできます。
サーバーのRAMは4GB以上に構成することを強くお薦めします。大容量(数十GBから数百GB、またはそれ以上)のデータをメモリーに格納するアプリケーションでは、1台のサーバー当たり16GBまたは32GBのRAMのコスト効果を評価してください。商用x86サーバーのRAMは、DIMM当たり2GBの密度で容易に利用できます。高密度のRAMを提供するベンダーは少なく、価格もかなり割増しになります。そのため、8個のメモリー・スロットを搭載するサーバーでは、16GBのみサポートするほうがコスト効果が高くなります。また、大容量の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などの高帯域幅のバスに配置します。PCI-Xの場合、独立した、または軽負荷の133MHzバスにNICを配置すると、パフォーマンスが大幅に向上する可能性があります。「バスに関する考慮事項」も参照してください。
サーバー数の計画
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数の構成方法を決定するには、次の規則に従います。
3台以上のサーバーを使用する必要があります。2台のサーバーのみでグリッドを構成した場合、1台のサーバーのJVM数がもう一方のサーバーのJVM数と一致しなくなった時点で、マシンの安全性は保証されなくなります。したがって、最初は2台のサーバーで同数のJVMが実行されていても、1つのJVMに障害が発生すれば、グリッド内のマシンの安全な状態は強制的に損なわれます。4台以上のサーバーを使用すると最も安定性のあるトポロジが実現しますが、他の規則にも準拠している場合は、3台のサーバーのみでも安全性は確保できます。
クラスタ内で最も多くJVMを配置するサーバーでは、そのJVMの数がクラスタ内の他のすべてのサーバーのJVMの合計数を超えないようにします。
最も少なくJVMを配置するサーバーでは、最も多く配置するサーバーの少なくとも半数のJVMを実行することをお薦めします。この規則は、小規模のクラスタには特に重要になります。
安全性は、JVMの数がクラスタ内のすべてのコンピュータの台数に近くなるほど高くなります。これは、前述のどの規則よりも一般的なプラクティスです。
オペレーティング・システムの選択
Coherenceを使用するアプリケーションの開発に使用されるオペレーティング・システムの上位3つは、Windows 2000/XP (~85%)、Mac OS X (~10%)およびLinux (~5%)です。本番デプロイメントに使用されるオペレーティング・システムの上位4つは、Linux、Solaris、AIXおよびWindows(記載順)です。したがって、開発用とデプロイメント用のオペレーティング・システムが同じである可能性はほとんどありません。所定のテストは、必ずターゲットのオペレーティング・システムで実行してください。
オラクル社は、各種のLinuxディストリビューション(カスタムのLinuxビルドを使用する場合も含む)、Sun Solaris、IBM AIX、Windows Vista/2003/2000/XP、Apple Mac OS X、OS/400およびz/OS上でのテストを実行し、これらのオペレーティング・システムをサポートしています。その他、HP-UXや、各種のBSD UNIXディストリビューションを実行するケースもサポートしています。
サーバーのオペレーティング・システムをまだ決定していない場合は、次の推奨事項に留意してください。
コモディティx86サーバーには、Linux 2.6カーネルをベースとするLinuxディストリビューションが推奨されます。2.6ベースのLinuxディストリビューションのほとんどは、Coherenceの実行に適した環境を提供することが予想されますが、オラクル社ではさらに、Red Hat Enterprise Linux(バージョン4以降)やSuse Linux Enterprise(バージョン10以降)など、Oracle Unbreakable LinuxでサポートされているLinuxをお薦めします。また、RedHat Fedora Core 5やKNOPPIX Live CDなどのディストリビューションを使用した定期的なテストも実施しています。
Coherenceのデプロイ先オペレーティング・システムについては、第2章「プラットフォーム固有のデプロイに関する考慮事項」を確認し、その指示に従ってください。
仮想メモリー(ディスクへのページング)の使用は避けます。
Coherenceベースのアプリケーションでは、主要なデータ管理の役割(専用キャッシュ・サーバーなど)がJavaベースのプロセスでホストされます。最新のJavaディストリビューションは、仮想メモリーでは効率よく機能しません。特にガベージ・コレクション(GC)操作では、メモリーがディスクにページングされる場合、桁違いに速度が低下することがあります。最新の商用ハードウェアと最新のJVMを使用する場合、妥当なヒープ・サイズ(512MBから2GB)のJavaプロセスは、すべてのプロセス・メモリーがRAMに作成される場合には、通常数秒でガベージ・コレクションを完了します。しかし、JVMが部分的にディスクに存在する場合は、実行に何分もかかるようになります。ガベージ・コレクションの実行中、ノードは長時間無応答になるため、クラスタ内の他のノードの選択肢は、無応答ノードの応答を待つ(この間、アプリケーションのアクティビティは部分的にブロックされます)か、無応答ノードを障害ノードとみなしてフェイルオーバー処理を実行するかのいずれかになります。どちらにしても適切な選択ではないため、ガベージ・コレクションによる過度の一時停止を避けることが重要です。JVMは設定ヒープ・サイズで構成して、ヒープが使用可能なRAMメモリーを使い果たさないようにする必要があります。さらに、定期的なプロセス(日次バックアップ・プログラムなど)は、メモリー使用の急増によってCoherenceのJVMがディスクにページングされるないように監視する必要があります。
「スワッピング」も参照してください。
開発段階では、開発者は一般に、最新のOracle JVM、またはMac OS X JVMなどの直接派生製品を使用します。
本番環境で異なるJVMを使用する場合、主に次のような問題が生じます。
コマンドラインの違い。シェル・スクリプトおよびバッチ・ファイルに問題が生じる場合があります。
ロギングおよびモニタリングの違い。開発テスト時にログの分析およびライブJVMの監視に使用していたツールを本番環境で使用できなくなる可能性があります。
最適なGC構成、およびGCのチューニング方法の大きな違い。
スレッド・スケジューリング時の動作、ガベージ・コレクションの動作とパフォーマンス、およびコード実行パフォーマンスの違い。
所定のテストは、必ず本番環境で使用するJVMで実行してください。
JVMの選択
Oracle Coherenceのバージョンとの関連性
Coherenceは、Oracle JVM 1.6アップデート23でサポートされます。
JVMの選択は、他のソフトウェアにも左右される場合があります。例:
IBMでは、IBM JVM上で実行されるIBM WebSphereのみをサポートしています。ほとんどの場合、JVMにはIBM SovereignまたはJ9が使用されますが、WebSphereがSun Solaris/Sparcで実行される場合、JVMはIBM独自のソース・コードではなく、Sun JVMのソース・コードを使用して構築されます。
Oracle WebLogicには、通常、WebLogicで使用するためのJVMが付属しています。一部のプラットフォームで使用されているOracle WebLogic JRockit JVMがこれに当たります。
Apple Mac OS X、HP-UX、IBM AIXなどのオペレーティング・システムは、1つのJVMベンダー(それぞれApple、HP、IBM)しかサポートしていません。
特定のソフトウェア・ライブラリとフレームワークは、比較的新しいJava機能を使用しているため、最小限のJavaバージョン要件が伴います。
LinuxまたはWindowsを実行するコモディティx86サーバーにはOracle JVMをお薦めします。一般的には、最新バージョンを使用することをお薦めします。
|
注意: テストおよびデプロイメントには、使用するプラットフォームおよびCoherenceバージョンに基づいて、サポートされる最新のOracle JVMを使用することをお薦めします。 |
基本的には、本番に移行する前の特定時点で、JVMのベンダーとバージョンを選択して十分にテストし、そのJVMでテスト中およびステージング中に検出されたすべての不具合を修正する必要があります。本番への移行には、そのJVMを使用することをお薦めします。間断ない可用性が要求されるアプリケーションでは、承認の前に、そのJVMで長期にわたる(少なくとも2週間)アプリケーション・ロード・テストを実行する必要があります。
Coherenceのデプロイ先JVMについては、第2章「プラットフォーム固有のデプロイに関する考慮事項」を確認し、その指示に従ってください。
JVMオプションの設定
JVMの構成オプションはバージョンおよびベンダーによって異なりますが、一般には次のことをお薦めします。特定のJVMの考慮事項については、第2章「プラットフォーム固有のデプロイに関する考慮事項」を参照してください。
-serverオプションを使用すると、パフォーマンスが大幅に向上します。
-Xmsと-Xmxの両方に同じヒープ・サイズを使用すると、OracleおよびJRockit JVMでのパフォーマンスが大幅に向上し、フェイル・ファストのメモリー割当てを実現できます。
ガベージ・コレクションを監視します。特に巨大なヒープを使用する場合は、-verbose:gc、-XX:+UseConcMarkSweepGC、-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のシリアライズ形式はここ数年変わっていないため、この種の問題が発生する可能性はほとんどありません。しかし、本番環境にデプロイする前に、混合構成をテストして、シリアライズの整合性を確認することを強くお薦めします。
次の各項も参照してください。
セキュリティ権限の確保
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="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ファイルの前に、クラスパスに含まれている場合)は、どのモードが選択されていても使用され、すべてのモード固有オーバーライド・ファイルをオーバライドします。
エディションの選択
|
注意: 現在は、エディションの切替えを使用しないことをお薦めします。この切替えがライセンスの制限を適用するために使用されることはなくなりました。 |
クラスタ内のノードはすべて、同じライセンスのエディションとモードを使用する必要があります。本番環境では、すべてのクラスタ・メンバーに必要なライセンスをすべて取得するようにしてください。サーバーのハードウェア構成(プロセッサ・ソケット、プロセッサ・パッケージ、CPUコアなどの数やタイプ)は、Coherenceに付属するProcessorInfoユーティリティを使用して検証できます。例:
java -cp coherence.jar com.tangosol.license.ProcessorInfo
ProcessorInfoプログラムの結果がライセンス構成と異なる場合は、プログラムの出力内容と実際の構成内容をサポート問題として送信してください。
デフォルトのエディションは、Grid Editionです。エディションを変更するには、オペレーション・オーバーライド・ファイルを編集して、<license-config>要素内に、表7-1に定義されているエディション名を含む<edition-name>を追加します。例:
... <license-config> <edition-name system-property="tangosol.coherence.edition">EE</edition-name> </license-config> ...
オペレーション・デプロイメント・ディスクリプタではなく、tangosol.coherence.editionシステム・プロパティを使用して、ライセンス・エディションを指定します。例:
-Dtangosol.coherence.edition=EE
表7-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開発者ガイド』を参照してください。集中型の構成ファイルは、各クラスタ・ノードのtangosol.coherence.overrideシステム・プロパティの値として、URLを指定することで保守およびアクセスできます。例:
-Dtangosol.coherence.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ファイルは、サンプルとして提供されているもので、本番環境での使用には適しません。アプリケーション固有の定義には、必ずキャッシュ構成ファイルを使用してください。
すべてのクラスタ・ノードは、可能な場合は、同じキャッシュ構成ディスクリプタを使用する必要があります。集中型の構成ファイルは、各クラスタ・ノードの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乗以上の素数を設定する必要があります。
キャッシュ・ストアによってバッキングされるキャッシュでは、キャッシュ・ストアへのリクエストが入出力時にブロックされることがあるため、スレッド・プールを使用して親サービスを構成することをお薦めします。プールを有効にするには、<distributed-scheme>要素の<thread-count>サブ要素を使用します。キャッシュ・ストアベース以外のキャッシュでは、スレッドを増やしてもパフォーマンスが向上する可能性がないため、スレッドは無効にしたままにします。
明示的に指定しないかぎり、いずれのクラスタ・ノードも記憶域が有効化されます。つまり、キャッシュ・サーバーとして機能します。したがって、本番環境で記憶域を有効化および無効化するノードを制御することが重要になります。記憶域を制御するには、tangosol.coherence.distributed.localstorageシステム・プロパティをtrueまたはfalseに設定します。一般に、専用キャッシュ・サーバーの記憶域のみを有効にします。その他のクラスタ・ノードはすべて、記憶域を無効にするように構成します。これは、なんらかの作業のためにクラスタに参加して、その後でクラスタから離れるような短期間プロセスには特に重要です。このようなノードの記憶域が有効にしてあると、不要な再パーティション化が発生します。
各キャッシュ構成要素の詳細は、『Oracle Coherence開発者ガイド』を参照してください。
<distributed-scheme>要素の<partition-count>サブ要素には、記憶域を有効化したノードの数の2乗に近い素数を設定することを一般にお薦めします。この計算式は、オーバーヘッドが大きくなりすぎるため大規模なクラスタには理想的ではありません。記憶域を有効にしたJVMが128以上あるクラスタでは、パーティション数を約16,381に固定する必要があります。
400以上のTCMPノードで構成されるCoherenceクラスタでは、そのCoherenceが使用するデフォルトの最大パケット・サイズを増やす必要があります。デフォルトの1468をクラスタのサイズに応じて増やします。つまり、600ノードで構成されるクラスタでは、最大パケット・サイズを50%増加します。簡単な計算式では、ノードごとに4バイト、つまりmaximum_packet_size = maximum_cluster_size * 4Bとなります。最大パケット・サイズは、Coherenceオペレーション構成ファイルの一部として構成されます。最大パケットサイズの構成の詳細は、『Oracle Coherence開発者ガイド』を参照してください。
何百ものJVMで構成される大規模なクラスタでは、マルチキャストを有効にすることをお薦めします。これを有効にすると、クラスタ全体の転送効率が高まります。クラスタ全体の転送はまれにしか発生しませんが、発生した場合、大規模なクラスタでは、マルチキャストによる多大な効果を得ることができます。
Coherenceの停止検出アルゴリズムは、2つ以上のクラスタ・ノード間で発生する持続的な接続の切断に基づいています。他のノードとの接続が失われたことを認識したノードは、どのような処理を行う必要があるかを他のクラスタ・ノードに相談します。
他のノードに相談しようとしたときに、このノードは他のどのノードとも通信できないことを知り、自身がクラスタから切り離されたものと推測します。このような状況は、ノードのネットワーク・アダプタのプラグを物理的に抜くことによって発生する可能性があります。このようなイベントでは、切り離されたノードは自身のクラスタ・サービスを再起動して、クラスタに参加しなおそうとします。
それでも他のクラスタ・ノードと接続できない場合、このノードはwell-knownアドレスの構成に応じて、新しい独立したクラスタを形成するか、さらに大規模なクラスタを探し続けます。いずれの場合も、接続が回復すると、切り離されたクラスタ・ノードは実行中のクラスタに再び参加します。クラスタに再び参加する過程で、ノードの以前のクラスタ状態は、保持していたキャッシュ・データも含めて破棄されます。これは、そのデータの所有権がクラスタ内の残りのノードによって(バックアップからリストアすることで)引き継がれているためです。
接続が失われた状態では、ノードが別のノードの状態を識別できないことは明らかです。単一ノードの場合、ローカル・ネットワーク・アダプタの障害も、ネットワーク全体のスイッチ障害もまったく同じに見えるため、これらの障害はいずれも前述のように同じ方法で処理されます。重要な違いは、スイッチ障害の場合、すべてのノードがクラスタに参加しなおそうとするため、クラスタ全体を再起動することと同じことになり、以前の状態とデータがすべて削除されるという点です。
すべてのデータが削除されることは望ましくないため、スイッチ障害時にこれを回避するには、追加の予防策をとる必要があります。次のオプションがあります。
検出間隔を増加する: クラスタは、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のチーミングを参照してください。
