| Oracle Coherence開発者ガイド リリース3.5 B56039-01 |
|
 戻る |
 次へ |
|
注意: 本番環境へのCoherenceのデプロイメントは、開発環境でCoherenceを使用する場合とは大きく異なります。開発環境は、本番環境の様々な課題を反映していません。 |
Coherenceは開発環境では非常にシンプルな形で使用される傾向があるため、開発者はCoherenceを使用するアプリケーションを本番環境に移行する場合に、必要な計画手順や事前準備を実行しないことがあります。このドキュメントは、次のことを目的としています。
本番ソフトウェアをデプロイする際の複雑性について正当な評価を作成する。これは特に、大規模なインフラストラクチャ・ソフトウェアやエンタープライズ・アプリケーションに該当します。
Coherenceをデプロイする際に計画が必要な領域を列挙する。
列挙した領域を本番で認識する必要がある理由を定義する。
列挙した各領域に対して、固有のアプローチおよびソリューションを提案または要求する。
本番環境へのデプロイメントにおけるリスクを最小限に抑えるためのチェックリストを作成する。
ここでは、次の項目に関するデプロイメント時の推奨事項を示します。
開発段階では、開発者のローカル・マシンに存在するCoherence対応のアプリケーションが、他の開発者のマシンで実行されているアプリケーションと知らないうちにクラスタを形成する可能性があります。
開発者は通常、各自のワークステーションでCoherenceをローカルに使用し、テストします。これには、次のような方法が使用されます。
マルチキャストTTLをゼロに設定する。
ループバックを使用する。
開発者ごとに他の開発者と異なるマルチキャスト・アドレスとポートを使用する。
これらの方法のいずれかが利用できない場合、複数の開発者が同じネットワークを使用していると、別の開発者がローカルに実行しているアプリケーション・インスタンスと自身のCoherenceがクラスタ化されることがあります。実際に、この現象は比較的多く発生しており、開発者がこのことを認識していない場合は混乱を招きます。
次の行をJVMの起動パラメータに追加することで、コマンドラインから簡単にTTLをゼロに設定できます。
-Dtangosol.coherence.ttl=0
バージョン3.2以降のCoherenceでは、すべての開発者が簡単にTTLをゼロに設定できるようになっています。coherence.jarファイルのtangosol-coherence-override-dev.xmlを編集して、TTL設定を次のように変更します。
<time-to-live system-property="tangosol.coherence.ttl">0</time-to-live>
一部のUNIXオペレーティング・システム（LinuxおよびMac OS Xの一部のバージョンを含む）では、TTLをゼロに設定するだけではクラスタを単独のマシンとして分離するのに不十分な場合があります。安全性を確保するには、開発者ごとに個別のクラスタ名を割り当てます。たとえば、開発者のメール・アドレスをクラスタ名として使用します。クラスタ通信がネットワークを介して他の開発者のマシンに対して実行されても、異なるクラスタ名を使用していることにより、起動を試行しているノードではエラーが発生します。
クラスタが完全に分離されるようにするには、各開発者に個別のマルチキャストIPアドレスとポートを指定します。簡単な方法として、開発者の内線番号をマルチキャスト・アドレスの一部とポート番号（またはポート番号の一部）に使用している組織もあります。マルチキャストIPアドレスとポートの構成の詳細は、「multicast-listener」を参照してください。
開発段階では、クラスタ機能がテストされない場合がよくあります。
POCまたはプロトタイプ段階が完了してからロード・テストが開始されるまでの間、アプリケーションが非クラスタ構成で開発およびテストされることは珍しくありません。しかしこれは危険です。非クラスタ構成を主とするテストでは、アプリケーションのアーキテクチャや実装上の問題が検出されず、後の段階、さらには本番に移行してから問題が発覚する可能性があります。
アプリケーションは、開発の進捗に合せて、必ずクラスタ構成でテストしてください。たとえば、次のような方法を使用すれば、開発工程にもクラスタ構成のテストを簡単に組み込むことができます。
ローカルにクラスタ構成を作成して（開発者自身のマシンで2つ以上のインスタンスを実行して）テストする。単一マシンでのクラスタ化はTTL=0設定で機能するため、この方法は、TTL=0と設定するだけで実現します。
クラスタ化したテスト環境にユニット・テストおよびリグレッション・テストを導入する。この方法は、開発者個人では忘れてしまったり、時間がなくて実行できないようなクラスタ構成でのテストを自動的に実行する場合に役立ちます。
本番ネットワークの種類と速度
ほとんどの本番ネットワークはギガビット・イーサネットをベースとしていますが、より低速の100Mbイーサネットや、より高速の10ギガビット・イーサネットをベースとしている場合もわずかながらあります。重要なことは、本番ネットワークのトポロジ、およびCoherenceを実行するすべてのサーバーの接続に使用するデバイス一式を把握しておくことです。たとえば、サーバーの接続に使用するスイッチが10個ある場合、それらがすべて同じ種類（製造元と型）かどうか、速度はすべて同じかどうか、サーバーは利用可能なネットワーク速度をサポートしているかどうかなどを確認します。
一般に、すべてのサーバーは、信頼できるフル・スイッチド・ネットワークを共有する必要があります。これは通常、単一スイッチを共有することを意味します（理想的には、可用性を確保するために、サーバーごとにパラレル・スイッチとネットワーク・カードを2つずつ使用します）。この主な理由は2つあります。まず、複数のスイッチを使用すると、ほとんどの場合、有効なネットワーク容量が減少します。もう1つの理由は、マルチスイッチ環境ではネットワークのパーティション化イベントが発生しやすくなるため、部分的なネットワーク障害によって2組以上のサーバーの接続が損なわれます。パーティション化イベントの発生はまれですが、Coherenceのキャッシュ・サーバーでは、理想的には共通のスイッチを共有することをお薦めします。
複数のスイッチが帯域幅に及ぼす影響を説明するために、単一スイッチに接続された複数のサーバーを考えてみましょう。サーバーを増設するに従って、各サーバーにはスイッチ・バックプレーンから専用の帯域幅が割り当てられます。たとえば、フル・スイッチド・ギガビット・バックプレーンでは、各サーバーにはインバウンド帯域幅とアウトバウンド帯域幅が1ギガビットずつ割り当てられるため、合計2Gbpsの全二重帯域幅になります。サーバーが4つの場合、帯域幅の合計は8Gbpsになります。サーバーが8つになれば、合計は16Gbpsです。このようにして、スイッチの上限まで帯域幅は増加します（実際には、通常のギガビット・スイッチの範囲は160〜192Gbpsです）。ところが、4Gbpsの（8Gbpsの全二重）リンクで接続された2つのスイッチの例を考えてみましょう。この場合、各スイッチにサーバーが追加されるたびに、これらのサーバーには、1スイッチ当たり最大4サーバー分までの完全なメッシュ帯域幅が割り当てられます（つまり、一方のスイッチ上の4つのサーバーは、いずれももう一方のスイッチ上の4つのサーバーと最大速度で通信できます）。しかし、サーバーを追加すると、スイッチ間リンクにボトルネックが生じる可能性があります。たとえば、一方のスイッチ上の5つのサーバーが、もう一方のスイッチ上の5つのサーバーにそれぞれ1Gbpsの速度でデータを送信したとすると、合計5Gbpsの通信が4Gbpsのリンクによって制限されます。実際の制限は、サーバーごとのトラフィックや、リンク上を実際に移動する必要があるトラフィックの量に応じて、かなり高くなる場合があります。また、ネットワーク・プロトコルのオーバーヘッドや不規則なトラフィック・パターンなどの要素によっても、使用可能な範囲がアプリケーション・パースペクティブから大幅に減少する場合があります。
ネットワーク速度の混在および競合は避けてください。すべてのサーバーが同じ速度でネットワークに接続でき、さらにサーバー間のすべてのスイッチとルーターが同じ速度またはより高い速度で実行されるようにします。
オラクル社では、GigE以上の高速イーサネットを強く推奨しています。ギガビット・イーサネットは2004年以降に構築されたほとんどのサーバーでサポートされており、ギガビット・スイッチは経済的で入手しやすく、広く普及しています。
アプリケーションをデプロイする前に、データグラム・テストを実行して実際のネットワーク速度をテストし、大量のデータをプッシュするためのネットワーク容量を確認する必要があります。さらに、パブリッシャとコンシューマの比率を高めてデータグラム・テストを実行する必要もあります。単一パブリッシャと単一コンシューマでは良好に見えるネットワークも、パブリッシャの数が増加すると完全に機能しなくなる可能性があり、このような現象がCisco 6500シリーズ・スイッチのデフォルト構成で発生しているためです。詳細は、「Cisco社製スイッチへのデプロイ」を参照してください。
本番デプロイメントでのマルチキャストの使用
マルチキャストとは、1つのサーバーから情報パケットを送信し、そのパケットをネットワークを通じて複数のサーバーに同時に配信する機能です。Coherenceは、マルチキャストとマルチキャストフリーの両方のクラスタ化をサポートしています。マルチキャストは多くのサーバー通信に有効なオプションであるため、可能なかぎりマルチキャストを使用することをお薦めします。一方、次のような場合はマルチキャストを使用できません。
マルチキャストの使用が組織で許可されていない。
特定のタイプのネットワーク装置でマルチキャストが機能しない。たとえば、WANルーターの多くは、マルチキャスト・トラフィックを使用できないかサポートしていません。
技術的な理由によりマルチキャストが使用できない。たとえば、スイッチによってはマルチキャスト・トラフィックがサポートされていない場合があります。
まず、マルチキャストを使用するかどうかを決定します。つまり、目的のデプロイメント構成にマルチキャストを使用するかどうかを決定します。
マルチキャストを使用するアプリケーションをデプロイする前に、マルチキャスト・テストを実行して、マルチキャストが機能するかどうかを検証し、本番環境に適した（最小の）TTL値を確認する必要があります。詳細は、第15章「マルチキャスト接続テストの実行」を参照してください。
デプロイメントにマルチキャストを使用できないアプリケーションでは、WKA構成を使用する必要があります。詳細は、「well-known-addresses」および「ネットワーク・プロトコル」を参照してください。
最適なネットワーク・デバイス構成
前述のデータグラム・テストまたはマルチキャスト・テストが失敗した場合、または良い結果が得られなかった場合は、使用中のネットワーク・デバイスに構成上の問題がある可能性があります。またテストが問題なく終了し、結果が完璧であっても、ネットワーク・デバイスの構成に問題が潜んでいる可能性があります。
「ネットワークのチューニング」の推奨事項を確認してください。
持続するネットワーク障害のクラスタでの処理方法
Coherenceのクラスタ・プロトコルは、様々な接続障害を検出して処理する能力を備えています。クラスタ・サービスは、接続の問題を識別し、問題のあるクラスタ・ノードを強制的に切り離して、再びクラスタに参加させることができます。このようにして、クラスタでは、一貫性のある共有状態がメンバー間で確実に維持されます。
詳細は、「停止検出」を参照してください。次の各項も参照してください。
開発段階では、開発者はパフォーマンスに関して非現実的な期待を抱くことがあります。
ほとんどの開発者は、比較的高速なワークステーションを使用しています。非クラスタ環境で単一ユーザー・アクセスのみ（開発者のアクセスのみ）を再現して行う傾向があるテストの結果を総合すると、アプリケーションの応答性がきわめて高いように思えてしまう可能性があります。
要件に、同時ユーザー負荷をシミュレートしながら実行できる現実的なロード・テストの構築を追加してください。
テストは常にクラスタ構成で同時ユーザー負荷をシミュレートしながら実行してください。
開発段階では、ハードウェア・リソースが不十分だと、開発者の生産性が損なわれる可能性があります。また、特定のタイプの品質にも悪影響を及ぼす可能性があります。
Coherenceは、すべての一般的なワークステーション・ハードウェアと互換性があります。開発者は通常、ノートブック、デスクトップ、ワークステーションなどを含むPCまたはAppleハードウェアを使用しています。
開発者のシステムには、最新のIDE、デバッガ、アプリケーション・サーバー、データベースおよび少なくとも2つのクラスタ・インスタンスを実行するための膨大なRAMが必要です。メモリーの使用方法は様々ですが、開発者のシステムの生産性を保証するには、2GB以上のメモリー構成が推奨されます。デスクトップ・システムおよびワークステーションは、通常、最小限の追加コストで4GBに構成できます。
開発者のシステムには、2つ以上のCPUコアが推奨されます。これは同時に開発者の作業効率の向上にもつながりますが、実際の目的は、マルチスレッド関連のコード品質を高めることにあります。複数のスレッドの同時実行に関連するバグの多くが、マルチCPUシステム（複数のプロセッサ・ソケットやCPUコアで構成されるシステム）でしか再現されないためです。
Coherenceのデプロイメントでサポートおよび推奨されるサーバー・ハードウェア・プラットフォーム
端的にいえば、オラクル社では、次に示すように、お客様によって標準化されたハードウェアまたは本番デプロイメント用に選択されたハードウェアをサポートするよう努めています。
オラクル社のお客様は、ほぼすべての主要なサーバー・ハードウェア・プラットフォームを使用しています。その大多数はコモディティx86サーバーを使用しており、Sun Sparc（Niagraを含む）サーバーおよびIBM Powerサーバーを使用しているお客様もかなりいます。
オラクル社では、IntelとAMDの両方のコモディティx86サーバーでCoherenceを継続的にテストしています。
オラクル社は、Intel、Apple、IBMの各社から、ハードウェア、チューニング・アシスタントおよびテスト・サポートの提供を受けています。
オラクル社では、すべてのIBMサーバー・プラットフォームに対するCoherenceの内部認定を少なくとも年1回実施しています。
オラクル社およびAzul社では、新しく発表された48コアのVega 2チップを含め、Azulアプライアンスに対するCoherenceのテストを定期的に実施しています。
サーバー・ハードウェアをまだ購入していない場合は、次の推奨事項に留意してください（2006年12月現在）。
最もコスト効果の高いサーバー・ハードウェア・プラットフォームは、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以上に構成することを強くお薦めします。数十〜数百ギガバイト、またはそれ以上の大容量のデータをメモリーに格納するアプリケーションでは、1サーバー当たり16GBまたは32GBのRAMのコスト効果を評価することが推奨されます。2006年12月現在、コモディティ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は本質的にはスケールアウト・テクノロジです。個々のサーバーで複数のJVMを使用することにより、大規模なサーバー環境を効果的に拡張できますが、本来の操作モードは、数台の小規模なサーバー環境（2または4ソケットのコモディティ・サーバーなど）を拡張するためのものです。特に、フェイルオーバーおよびフェイルバックは、大規模な構成ほど効果的です。サーバー障害による影響も低減します。経験則では、クラスタには少なくとも4つの物理サーバーを配置することをお薦めします。一般的なWAN構成では、データ・センターごとに独立したクラスタ（通常はExtend-TCPで相互接続されます）を配置します。これにより、個々のサーバーの合計数（1データ・センター当たり4サーバー×データ・センター数）は増加します。
Coherenceは小規模なクラスタ（物理サーバー1〜3台）にデプロイされることも多くありますが、その場合、負荷の高い状況でサーバーに障害が発生したときのリスクが増大します。前述のネットワークの項で説明したように、Coherenceクラスタは、理想的には単一スイッチに制限されます（例: 物理サーバー96台未満）。使用例によっては、CPUバウンドまたはメモリーバウンドのアプリケーションは（ネットワークバウンドアプリケーションに比べて）、大規模なクラスタのほうが満足に動作する場合もあります。
また、多数の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（記載順）です。したがって、開発用とデプロイメント用のオペレーティング・システムが同じである可能性はほとんどありません。
所定のテストは、必ずターゲットのオペレーティング・システムで実行してください。
Coherenceのデプロイメントでサポートおよび推奨されるサーバーのオペレーティング・システム
オラクル社は、各種のLinuxディストリビューション（カスタムのLinuxビルドを使用する場合も含む）、Sun Solaris、IBM AIX、Windows Vista/2003/2000/XP、Apple Mac OS X、OS/400およびz/OS上でのテストを実行し、これらのオペレーティング・システムをサポートしています。その他、HP-UXや、各種のBSD UNIXディストリビューションを実行するケースもサポートしています。
サーバーのオペレーティング・システムをまだ決定していない場合は、次の推奨事項に留意してください（2006年12月現在）。
コモディティx86サーバーには、Linux 2.6カーネルをベースとするLinuxディストリビューションが推奨されます。2.6ベースのLinuxディストリビューションのほとんどは、Coherenceの実行に適した環境を提供することが予想されますが、オラクル社ではさらに、RedHat Enterprise Linux（バージョン4以降）およびSuse Linux Enterprise（バージョン10以降）を推奨しています。また、RedHat Fedora Core 5やKNOPPIX Live CDなどのディストリビューションを使用した定期的なテストも実施しています。
Coherenceのデプロイ先オペレーティング・システムについては、付録M「プラットフォーム固有のデプロイに関する考慮事項」を確認し、その指示に従ってください。
仮想メモリー（ディスクへのページング）の使用は避けます。
Coherenceベースのアプリケーションでは、主要なデータ管理の役割（専用キャッシュ・サーバーなど）がJavaベースのプロセスでホストされます。最新のJavaディストリビューションは、仮想メモリーでは効率よく機能しません。特にガベージ・コレクション（GC）操作では、メモリーがディスクにページングされる場合、桁違いに速度が低下することがあります。最新のコモディティ・ハードウェアと最新のJVMを使用する場合、妥当なヒープ・サイズ（512MB〜2GB）のJavaプロセスは、すべてのプロセス・メモリーがRAMに作成される場合には、通常2〜3秒でガベージ・コレクションを完了します。しかし、JVMが部分的にディスクに存在する場合は、実行に何分もかかるようになります。ガベージ・コレクションの実行中、ノードは長時間無応答になるため、クラスタ内の他のノードの選択肢は、無応答ノードの応答を待つ（この間、アプリケーションのアクティビティは部分的にブロックされます）か、または無応答ノードを障害ノードとみなしてフェイルオーバー処理を実行するかのいずれかになります。どちらも適切な選択ではないため、ガベージ・コレクションによる必要以上の一時停止を避けることが重要です。JVMは、物理RAMに固定するか、少なくともJVMがディスクにページングされないように構成することをお薦めします。
定期的なプロセス（日次バックアップ・プログラムなど）は、CoherenceのJVMがディスクにページングされる原因となるメモリー使用量の急増を招く可能性があるので注意が必要です。
次の各項も参照してください。
開発段階では、開発者は一般に、最新のSun JVM、またはMac OS X JVMなどの直接派生製品を使用します。
本番環境で異なるJVMを使用する場合、主に次のような問題が生じます。
コマンドラインの違い。シェル・スクリプトおよびバッチ・ファイルに問題が生じる場合があります。
ロギングおよびモニタリングの違い。開発テスト時にログの分析およびライブJVMの監視に使用していたツールを本番環境で使用できなくなる可能性があります。
最適なGC構成、およびGCのチューニング方法の大きな違い。
スレッド・スケジューリング時の動作、ガベージ・コレクションの動作とパフォーマンス、およびコード実行パフォーマンスの違い。
所定のテストは、必ず本番環境で使用するJVMで実行してください。
推奨されるJVMの構成オプション
JVMの構成オプションはバージョンおよびベンダーによって異なりますが、一般には次のことが推奨されます。
-serverオプションを使用すると、パフォーマンスが大幅に向上します。
-Xmsと-Xmxの両方に同じヒープ・サイズを使用すると、Sun JVMおよびJRockit JVMでのパフォーマンスが大幅に向上し、フェイル・ファストのメモリー割当てを実現できます。各種のJVMのデプロイメントにおける、次の具体的な考慮事項を参照してください。
単純なチューニングの場合、ヒープ・サイズは1GBが妥当です。このサイズにすると、各JVMのオーバーヘッドとガベージ・コレクション・パフォーマンスのバランスがとれます。
大きなヒープ・サイズも使用可能であり一般に使用されていますが、ガベージ・コレクションの一時停止を常に管理可能にするためのチューニングが必要な場合があります。
JVMでOutOfMemoryErrorが発生すると、エラーが未解決の状態のままになることがあり、クラスタに悪影響を与える可能性があります。OutOfMemoryErrorが発生した場合は、JVMでリカバリを試みられるようにするのではなく、JVMを終了するように構成することをお薦めします。一般的なJVMでこのように構成する方法については、次の具体的なデプロイメントの考慮事項を参照してください。
Coherenceのデプロイメントでサポートおよび推奨されるJVM
Oracle Coherenceのバージョンとの関連性
Coherence 3.xバージョンは、Sun JDKバージョン1.4、1.5、およびこれらのバージョンに対応するJVMでサポートされます。Coherence 3.3以上は、バージョン1.6のJVMでもサポートされます。
Coherenceバージョン2.x（現在のリリース・レベルは2.5.1）は、Sun JDKバージョン1.2、1.3、1.4、1.5、およびこれらのバージョンに対応するJVMでサポートされます。
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サーバーには、Sun JVMが推奨されます。一般的には、最新バージョンを使用することをお薦めします。次に例を示します。
|
注意: テストおよびデプロイメントには、使用するプラットフォームおよびCoherenceバージョンに基づいて、サポートされる最新のSun JVMを使用することをお薦めします。バージョン1.5以降のJVMでCoherenceを実行すると、1.5より古いバージョンのJVMで実行した場合と比較して、パフォーマンスが大幅に向上することが確認されています。 |
基本的には、本番に移行する前の特定時点で、JVMのベンダーとバージョンを選択して十分にテストし、そのJVMでテスト中およびステージング中に検出されたすべての不具合を修正する必要があります。本番への移行には、そのJVMを使用することをお薦めします。間断ない可用性が要求されるアプリケーションでは、承認の前に、そのJVMで長期にわたる（少なくとも2週間）アプリケーション・ロード・テストを実行する必要があります。
Coherenceのデプロイ先JVMについては、付録M「プラットフォーム固有のデプロイに関する考慮事項」を確認し、その指示に従ってください。
すべてのノードで同じベンダーとバージョンのJVMを実行する必要性について
CoherenceはPure Javaソフトウェアであるため、クラスタ内のJVMのベンダーとバージョンがどのような組合せであっても実行できます。オラクル社では、このような構成についてもテストしています。
JVMが異なると、Javaオブジェクトのシリアライズ形式も若干異なる可能性があることに注意してください。したがって、あるJVMでシリアライズされたオブジェクトがネットワークを介してベンダーまたはバージョンの異なるJVMに渡された場合、そのJVMでオブジェクトをデシリアライズしようとすると、非互換性の問題が生じる可能性があります。幸いにも、Javaのシリアライズ形式はここ数年変わっていないため、この種の問題が発生する可能性はほとんどありません。しかし、本番環境にデプロイする前に、混合構成をテストして、シリアライズの整合性を確認することを強くお薦めします。
次の各項も参照してください。
Coherenceの機能に最低限必要とされる権限セットは、security.policyファイル内で指定されています。これは、Coherenceインストールの一部として同梱されています。このファイルは、coherence/lib/security/security.policyにあります。Javaセキュリティ・マネージャを使用する場合は、Coherenceが正常に機能するように、これらの権限を付与する必要があります。
インスツルメント処理された管理および監視ソリューションを使用するときは注意してください。
Javaベースの管理および監視ソリューションには、インスツルメンテーション（バイトコード操作やClassLoader置換など）を使用しているものがあります。主なベンダーの最新バージョンには既知の未解決の問題はありませんが、オラクル社では過去の問題も監視しています。
開発段階では開発モードを使用します。
Coherenceのダウンロードには、すべてのエディションとモードをサポートするフル機能のCoherence製品が含まれています。デフォルトの構成は、開発モードのGrid Editionです。
Coherenceは、開発モードまたは本番モードのいずれかで動作するように構成できます。これらのモードには機能に対するアクセス制限はありませんが、デフォルトの構成設定が一部異なります。たとえば開発モードでは、開発プロセスを簡略化するために、クラスタを高速起動できます。
開発やテストなど、本番移行前のすべてのアクティビティには、開発モードを使用することをお薦めします。これは安全のための重要な機能であり、開発モードのノードが本番クラスタに参加するのを自動的に阻止できます。本番モードは、Coherenceを本番環境で使用するときに明示的に指定する必要があります。
Coherenceは、お客様のライセンス契約に基づき、限定された機能セットをサポートするように構成することもできます。
本番環境で使用できるCPUのエディションと数は、ライセンス契約に明記されたライセンス取得済のものだけです。
本番環境以外で運用する場合は任意のCoherenceエディションを実行できますが、ライセンス契約に明記されたエディションのみを使用することをお薦めします。これにより、アプリケーションで知らないうちに無許可の機能が使用されることを防止できます。
クラスタ内のノードはすべて、同じライセンスのエディションとモードを使用する必要があります。
Oracle Coherence 3.4以降、お客様固有のライセンス・キーは本番デプロイメントに使用されなくなりました。
本番環境では、すべてのクラスタ・メンバーに必要なライセンスをすべて取得するようにしてください。サーバーのハードウェア構成（プロセッサ・ソケット、プロセッサ・パッケージ、CPUコアなどの数やタイプ）は、Coherenceに付属するProcessorInfoユーティリティを使用して検証できます。
ProcessorInfoプログラムの結果がライセンス構成と異なる場合は、プログラムの出力内容と実際の構成内容をOracleサポート・サービスまでメールでお送りください。
エディションおよびモードの構成
エディションおよびモード関連の情報は、tangosol-coherence.xml（coherence.jar内）の<license-config>コンフィギュレーション・セクションにあります。
例A-2 Coherenceライセンス構成のサンプル
<license-config>
<edition-name system-property="tangosol.coherence.edition">GE</edition-name>
<license-mode system-property="tangosol.coherence.mode">dev</license-mode>
</license-config>
license-modeは、クラスタ内のモードの混在を防ぐだけでなく、使用されるオペレーション・オーバーライド・ファイルを指定します。devモードの場合はtangosol-coherence-override-dev.xmlファイルが使用され、prodモードを指定した場合はtangosol-coherence-override-prod.xmlファイルが使用されます。使用されるオーバーライド・ファイルはモードによって制御されるため、<license-mode>構成要素はベースのtangosol-coherence.xmlファイルでのみ使用でき、オーバーライド・ファイル内では使用できません。
これらの要素は、coherence.jarの対応するcoherence.dtdで定義します。このエディションは、コマンドラインでコマンドライン・オーバーライドを使用して指定することも可能です。
-Dtangosol.coherence.edition=RTC
有効な値を表A-1に示します。
表A-1 tangosol.coherence.editionの有効な値
| 値 | 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として使用して接続できます。
オーバーライドの詳細は、付録L「コマンドラインのオーバーライド」を参照してください。
RTCノードは、Coherence TCMPまたはCoherence Extendを使用してクラスタに接続できます。Extendを介して接続する場合は、Extendを使用した場合のみ接続されるように、そのノードでTCMPを無効にすることをお薦めします。TCMPを無効にするには、システム・プロパティtangosol.coherence.tcmp.enabledを使用します。「packet-publisher」の<enabled>サブ要素を参照してください。
オペレーション・コンフィギュレーションは、クラスタ・レベルのCoherenceの構成に関連しており、次のものが含まれます。
クラスタおよびメンバー・ディスクリプタ
ネットワーク設定
セキュリティ
メンバーシップ制限
アクセス制御
暗号化
オペレーション・コンフィギュレーションは通常、tangosol-coherence-override.xmlファイルを使用して構成します。このファイルの詳細は、「オペレーション・コンフィギュレーション・デプロイメント・ディスクリプタ」を参照してください。
このファイルの内容は、開発環境と本番環境とで異なる可能性があります。2つの環境には大きな相違があるため、ファイルの内容の相違は環境ごとに個別に管理することをお薦めします。本番環境のオペレーション・コンフィギュレーション・ファイルは、アプリケーション開発者が管理するのではなく、本番システムの運用により精通したシステム管理者の管理下に置く必要があります。
クラスタ・ノードは、いずれも同じオペレーション・コンフィギュレーション・ディスクリプタを使用する必要があります。集中型のコンフィギュレーション・ファイルは、tangosol.coherence.overrideシステム・プロパティでファイルの場所をURLで指定することにより管理およびアクセスできます。ノード固有の値は、各システム・プロパティで指定できます。プロパティの詳細は、付録L「コマンドラインのオーバーライド」を参照してください。
オーバーライド・ファイルには、カスタマイズする構成要素のサブセットのみを記述します。こうすると、構成が読み取りやすくなるだけでなく、将来のCoherenceリリースで更新されるデフォルトを使用できるようになります。すべてのオーバーライド要素は、要素のID属性も含め、元のtangosol-coherence.xmlから正確にコピーする必要があります。
メンバー・ディスクリプタには、クラスタ・メンバーの位置とロールの定義に有用な、詳細な識別情報を指定できます。これらの情報を指定しておくと、問題が発生した場合にリモート・ノードのロールを識別しやすくなるため、大規模なクラスタの管理に役立ちます。
キャッシュ・コンフィギュレーションは、個々のキャッシュ・レベルでのCoherenceの構成に関連しており、次のものが含まれます。
キャッシュ・トポロジ（<distributed-scheme>、<replicated-scheme>、<near-scheme>など）
キャッシュ容量（<local-scheme>の<high-units>サブ要素を参照）
キャッシュの冗長性レベル（<distributed-scheme>の<backup-count>サブ要素）
キャッシュ・コンフィギュレーションは通常、coherence-cache-config.xmlファイルを使用して構成します。このファイルの詳細は、「キャッシュ・コンフィギュレーション・デプロイメント・ディスクリプタ」を参照してください。
coherence.jarに含まれるデフォルトのcoherence-cache-config.xmlファイルは、サンプルとして提供されているもので、本番環境での使用には適しません。各自のアプリケーションのニーズに合った定義を使用して、独自のキャッシュ・コンフィギュレーション・ファイルを作成することをお薦めします。
クラスタ・ノードは、いずれも同じキャッシュ・コンフィギュレーション・ディスクリプタを使用する必要があります。集中型のコンフィギュレーション・ファイルは、tangosol.coherence.cacheconfigシステム・プロパティでファイルの場所をURLで指定することにより管理およびアクセスできます。
各キャッシュの使用シナリオに最も適したキャッシュ・トポロジを選択してください。
割り当てられたJVMのヒープ・サイズに基づいて、キャッシュ・サイズを制限することが重要です。キャッシュを完全にロードすることがないと予想される場合でも、制限を設けることで、後に予想がはずれた場合にアプリケーションがOutOfMemoryExceptionsになることを防止できます。
ヒープ・サイズが1GBの場合、キャッシュ記憶域には、最大でもヒープの3/4のサイズを割り当てます。デフォルトの1レベルのデータ冗長性を使用する場合、これは各サーバのキャッシュを375MBのプライマリ・データ領域と375MBのバックアップ・データ領域に制限することを意味します。キャッシュ記憶域に割り当てるメモリー容量は、JVMに確保されたヒープ領域内に収める必要があります。詳細は、SunのGCのチューニング・ガイドを参照してください。
同じキャッシュ・サービス名に複数のキャッシュ・スキームを定義した場合、最初にロードされるスキームによってサービス・レベルのパラメータが決まることに注意する必要があります。特に、<distributed-scheme>の<partition-count>、<backup-count>および<thread-count>サブ要素は、同じサービスのすべてのキャッシュで共有されます。
複数のキャッシュで同じキャッシュ・サービスを使用する場合は、サービス関連の要素を一度だけ定義し、それらの要素を使用する様々なキャッシュ・スキームで継承されるようにすることをお薦めします。
キャッシュごとに異なる値の要素を定義する場合は、複数のサービスを構成してもかまいません。
パーティション・キャッシュの場合、Coherenceでは、キャッシュの構成やヒープ・サイズに関係なく、すべてのキャッシュ・サービスに記憶域の役割が均等に割り当てられます。そのため、すべてのキャッシュ・サーバー・プロセスには同じヒープ・サイズを構成することが推奨されます。追加のリソースを使用するマシンには、マシンのリソースを効率的に利用するために、複数のキャッシュ・サーバーを使用できます。
パーティション・キャッシュ間の記憶域としての役割が均等になるようにするには、<distributed-scheme>の<partition-count>サブ要素を、使用するキャッシュ・サーバー数の2乗以上の素数に設定します。
キャッシュ・ストアによってバッキングされるキャッシュでは、キャッシュ・ストアへのリクエストが入出力時にブロックされることがあるため、スレッド・プールを使用して親サービスを構成することをお薦めします。プールを有効にするには、<distributed-scheme>要素の<thread-count>サブ要素を使用します。キャッシュ・ストアベース以外のキャッシュでは、スレッドを増やしてもパフォーマンスが向上する可能性がないため、スレッドは無効にしておくことをお薦めします。
明示的に指定しないかぎり、いずれのクラスタ・ノードも記憶域が有効化されます。つまり、キャッシュ・サーバーとして機能します。したがって、本番環境で記憶域を有効化および無効化するノードを制御することが重要になります。これを制御するには、tangosol.coherence.distributed.localstorageシステム・プロパティをtrueまたはfalseに設定します。一般に、専用キャッシュ・サーバーを除く他のすべてのクラスタ・ノードでは、記憶域が無効に構成されます。クラスタに参加してなんらかの処理を実行した後にクラスタを離れるような短時間のプロセスでは、クラスタ内のノードの記憶域が有効になっていると不必要な再パーティション化が発生するため、この制御は特に重要になります。システム・プロパティの詳細は、<distributed-scheme>の<local-storage>サブ要素を参照してください。
大規模なクラスタにおける特別な留意事項
<distributed-scheme>の<partition-count>サブ要素には、一般に、記憶域を有効化したノードの数の2乗に近い素数を設定することが推奨されます。しかしこれは、小中規模のクラスタには適していますが、大規模なクラスタではオーバーヘッドが大幅に増加する可能性があります。記憶域を有効にしたJVMが128以上あるクラスタでは、パーティション数を約16,381に固定する必要があります。
400以上のTCMPノードで構成されるCoherenceクラスタでは、Coherenceが使用するデフォルトの最大パケット・サイズを増やす必要があります。デフォルトの1468をクラスタのサイズに応じて増やします。つまり、600ノードで構成されるクラスタでは、最大パケット・サイズを50%増加します。最大パケット・サイズは、Coherenceオペレーション・コンフィギュレーション・ファイルの一部として構成します。この設定の変更方法の詳細は、「packet-size」を参照してください。
何百ものJVMで構成される大規模なクラスタでは、<multicast-listener>を有効にすることも推奨されます。これを有効にすると、クラスタ全体の転送効率が高まります。クラスタ全体の転送はまれにしか発生しませんが、発生した場合、大規模なクラスタでは、マルチキャストによる多大な効果を得ることができます。
Coherenceの停止検出アルゴリズムは、2つ以上のクラスタ・ノード間で発生する持続的な接続の切断に基づいています。他のノードとの接続が失われたことを認識したノードは、どのような処理を行う必要があるかを他のクラスタ・ノードに相談します。
他のノードに相談しようとしたときに、このノードは他のどのノードとも通信できないことを知り、自身がクラスタから切り離されたものと推測します。このような状況は、ノードのネットワーク・アダプタのプラグを物理的に抜くことによって発生する可能性があります。このようなイベントでは、切り離されたノードは自身のクラスタ・サービスを再起動して、クラスタに参加しなおそうとします。
それでも他のクラスタ・ノードと接続できない場合、このノードはwell-knownアドレスの構成に応じて、新しい独立したクラスタを形成するか、さらに大規模なクラスタを探し続けます。いずれの場合も、接続が回復すると、切り離されたクラスタ・ノードは実行中のクラスタに再び参加します。クラスタに再び参加する過程で、ノードの以前のクラスタ状態は、保持していたキャッシュ・データも含めて破棄されます。これは、すでにそのデータの所有権がクラスタ内の残りのノードによって（バックアップからリストアすることで）引き継がれているためです。
接続が失われた状態では、ノードが他のノードの状態を識別できないことは明らかです。つまり、単一ノードの視点から見ると、ローカル・ネットワーク・アダプタの障害も、ネットワーク全体のスイッチ障害もまったく同じに見えるため、これらの障害はいずれも前述のように同じ方法で処理されます。重要な違いは、スイッチ障害の場合、すべてのノードがクラスタに参加しなおそうとするため、クラスタ全体を再起動することと同じことになり、以前の状態とデータがすべて削除されるという点です。
いうまでもなく、すべてのデータが削除されることは望ましくありません。したがって、スイッチ障害時にこれを回避するには、追加の予防策をとる必要があります。これには、次のようなオプションがあります。
許容可能な停止時間を長くする: ノードがクラスタから除外されるまでに無応答の状態でいられる最大時間は、<packet-delivery>の<timeout-milliseconds>サブ要素で構成します。本番構成のデフォルトは1分です。この値を増やすと、クラスタは接続が回復するまでさらに長い時間待つことができます。この値を増やした場合のデメリットは、接続を失ったのが1つのノードのみであっても、処理に長時間かかる場合があることです。
外部ストレージにデータを維持する: 読取り/書込みバッキング・マップを使用すると、クラスタは外部ストレージにデータを維持するため、再起動後にそこからデータを取得できます。ライトビハインド（<read-write-backing-map-scheme>の<write-delay>サブ要素）が無効に設定されているかぎり、スイッチ障害イベントでデータが失われることはありません。この対策のデメリットは、同期的に外部ストレージへ書込みを行うことで、キャッシュ更新操作の待機時間が増加し、外部ストレージがボトルネックになる可能性があることです。
ノードの再起動を遅らせる: クラスタの停止検出処理は、接続が回復するまでノードの再起動を遅延するように変更できます。接続が回復するまで再起動を遅延すると、切り離されたノードは、接続が切断された時点で有効だったすべてのデータを保持したまま稼働し続けることができます。接続が回復すると、ノードの相互検出が行われ、新しいクラスタが形成されます。新しいクラスタを形成する際は、最上位のノードを除くすべてのノードの再起動が必要になります。結果的に、ノードの大半が再起動してそれぞれのデータを削除することになるため、この動作はデフォルトの動作とほぼ同じになります。この対策が有効なのは、レプリケーション・キャッシュが上位ノードとして使用されていて、ほとんどのノードのデータ・コピーが再起動後も維持される場合です。再起動の遅延を有効にするには、tangosol.coherence.departure.thresholdシステム・プロパティをクラスタ・サイズより大きな値に設定する必要があります。
|
注意: Microsoft Windows上で実行している場合は、ネットワーク・アダプタが切断されたときに、Windowsによってネットワーク・アダプタが無効化されないようにすることも必要です。そのためには、1:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableDHCPMediaSenseという、WindowsのDWORD型のレジストリを追加して、値を1に設定します。名前とは異なり、この設定は静的IPにも影響します。 |
ネットワーク・レベルのフォルト・トレランスを追加する: クラスタのネットワーク・インフラストラクチャに冗長層を追加すると、個々のネットワーク装置に障害が発生しても、接続が遮断されることはありません。これは通常、マシンごとに2つ以上のネットワーク・アダプタを使用し、各アダプタを別々のスイッチに接続することで実現します。これはCoherenceの機能というよりは、むしろ基礎となるオペレーティング・システムまたはネットワーク・ドライバの機能です。Coherenceに必要な唯一の変更は、物理ネットワーク・アダプタではなく、仮想ネットワーク・アダプタにバインドするよう構成することです。この形式のネットワーク冗長性は、オペレーティング・システムによって様々な名称で呼ばれています。詳細は、Linuxのボンディング、SolarisのトランキングおよびWindowsのチーミングを参照してください。
Coherence 3.4以降、tangosol-license.xmlファイルは非推奨になっています。
