| Oracle® Fusion Middleware Oracle Coherenceでのアプリケーションの開発 12c (12.2.1) E69903-02 |
|
 前 |
 次 |
この章では、キャッシュ・サーバーとキャッシュ・クライアントを起動する方法と停止する方法について基本的な説明を提供します。マルチキャストを使用する際のクラスタの構築に問題がある場合は、『Oracle Coherenceの管理』でマルチキャスト接続テストの実行方法を参照してください。
この章には次の項が含まれます:
キャッシュ・サーバーは、キャッシュしたデータを保存するクラスタ・メンバーです。複数のクラスタ・サーバーでクラスタを構成できます。各キャッシュ・サーバーはそれぞれ専用のJVMを使用します。
この項には次のトピックが含まれます:
キャッシュ・サーバーを起動するには、com.tangosol.net.DefaultCacheServerクラスを使用します。キャッシュ・サーバーはコマンド行から起動するか、またはプログラムによって起動できます。キャッシュ・サーバーを起動する際は、次の引数を使用します。
クラスパスで見つかるキャッシュ構成ファイルの名前、またはグリッド・アーカイブ(GAR)へのパス。両方が指定された場合、GARが優先されます。GARは、Coherenceアプリケーションからなるアーティファクトを含み、特定のディレクトリ構造を保持します。GARは、ディレクトリとして残すことも、.gar拡張子を付けてアーカイブ化することもできます。GARの作成の詳細は、『Oracle Coherenceの管理』を参照してください。
GARのアプリケーション名(オプション)。名前を指定しない場合は、アーカイブ名が使用されます。(ディレクトリ名、または.gar拡張子なしのファイル名)。この名前は、クラスタ上の別のアプリケーションに使用されるアプリケーション・スコープを提供します。
停止済のサービスを確認する間隔(秒数)。停止したサービスは、自動的に開始するように設定されている場合のみ、自動的に開始されます(キャッシュ構成ファイルの<autostart>要素で構成します)。引数が指定されなかった場合のデフォルト値は5秒です。
通常、キャッシュ・サーバーはコマンド行から起動します。Javaの-cpオプションを使用して、coherence.jarファイルの場所およびtangosol-coherence-override.xmlファイルとcoherence-cache-config.xmlファイルの場所を指定します。これらの構成ファイルの場所は、クラスパス上でcoherence.jarファイルよりも前の位置に記述する必要があります。そうしなかった場合、coherence.jarファイルにあるデフォルトの構成ファイルを使用してキャッシュ・サーバーのインスタンスが起動します。構成ファイルの詳細は、第3章「構成の理解」を参照してください。
次の例では、キャッシュ・サーバー・メンバーを起動し、COHERENCE_HOME\configディレクトリに存在する構成ファイルを使用し、2秒ごとにサービスの再起動を確認します。
java -server -Xms512m -Xmx512m -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer 2
次の例では、キャッシュ・サーバー・メンバーを起動し、MyGar.garファイル内にパッケージ化されたCoherenceアプリケーションのアーティファクトを使用します。デフォルトの名前(MyGAR)がアプリケーション名として使用されます。
java -server -Xms512m -Xmx512m -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar com.tangosol.net.DefaultCacheServer D:\example\MyGAR.gar
|
注意: クラスパスにあるキャッシュ構成ファイルよりも、GARファイル内にパッケージ化されたキャッシュ構成ファイルが優先されます。 |
キャッシュ・サーバー・インスタンスを容易に起動できるように、COHERENCE_HOME\bin\cache-serverスクリプトが用意されています。このスクリプトを使用すると、基本的な環境を設定してDefaultCacheServerクラスを実行できます。このスクリプトには、Windowsベース・プラットフォーム用とUNIXベース・プラットフォーム用の両方があります。多くの場合、このスクリプトは特定のクラスタに合せて変更したうえで使用します。
|
ヒント: テスト中は、各キャッシュ・サーバーを一意に特定する複数のスクリプトをそれぞれ異なる名前で作成しておくと便利なことがあります。たとえば、cahe-server-a、cache-server-bのようにします。 |
最後に、coherence.jarライブラリとともにjava -jarコマンドを使用することで、キャッシュ・サーバーをコマンド行で起動できます。キャッシュ・サーバーは、通常はテストとデモを目的とした場合に、このように起動されます。例:
java -jar COHERENCE_HOME\lib\coherence.jar
キャッシュ・サーバーを起動するときに、必要に応じてアプリケーションでDefaultCacheServerクラスを使用または拡張できます。たとえば、キャッシュ・サーバーとそのサービスを起動する前に、アプリケーション固有の設定や処理を実行できます。
次の例では、mainメソッドを使用してキャッシュ・サーバーを起動します。
String[] args = new String[]{"my-cache-config.xml", "5"};
DefaultCacheServer.main(args);
DefaultCacheServer(ConfigurableCacheFactory)コンストラクタは、ファクトリ・クラスを使用して、指定されたキャッシュ構成ファイルを使用するキャッシュ・サーバー・インスタンスを作成します。次の例では、ExtensibleConfigurableCacheFactoryの実装を使用し、DefaultCacheServerインスタンスを作成し、startAndMonitor(long)メソッドを使用して前の例と同様にキャッシュ・サーバーを起動します。
ExtensibleConfigurableCacheFactory.Dependencies deps =
ExtensibleConfigurableCacheFactory.DependenciesHelper.newInstance("my-cache-co
nfig.xml");
ExtensibleConfigurableCacheFactory factory;
factory = new ExtensibleConfigurableCacheFactory(deps);
DefaultCacheServer dcs = new DefaultCacheServer(factory);
dcs.startAndMonitor(5000);
staticメソッドであるstartDaemon()メソッドは、専用デーモン・スレッドでキャッシュ・サーバーを起動し、管理対象コンテナ内で使用することを目的としています。
2つの追加のstatic起動メソッド(start()およびstart(ConfigurableCacheFactory))を使用してキャッシュ・サーバーを起動し、制御を返すこともできます。ただし、多くの場合は、後方互換性を維持できるこれらのメソッドのかわりにキャッシュ・ファクトリ・クラスを使用します。
よりきめ細かい制御を必要とするアプリケーションでは、DefaultCacheServerクラスのサブクラスを作成し、このクラスのメソッドを無効にして、目的とする任意のカスタム処理を実行できます。DefaultCacheServerクラスの詳細は、Oracle Coherence Java APIリファレンスを参照してください。
キャッシュ・クライアントは、クラスタに参加してそのクラスタのサービスと相互作用するクラスタ・メンバーです。キャッシュ・クライアントには、キャッシュとの間でデータをやりとりするアプリケーションのような単純なものもあれば、キャッシュにあるデータを処理するデータ・グリッド演算アプリケーションのような複雑なものもあります。キャッシュ・クライアントとキャッシュ・サーバーとの大きな違いは、一般的にクラスタの記憶域にはキャッシュ・クライアントは関与しないという点です。
この項には次のトピックが含まれます:
パーティション・キャッシュ・サービス(分散キャッシュ)を使用するキャッシュ・クライアントでは、パーティション化したデータを保持しないようにします。記憶域を無効にしたキャッシュ・クライアントは良好なパフォーマンスを示し、使用するリソースも少なくてすみます。パーティション化したデータを分散する範囲は、キャッシュ・サーバー・インスタンスどうしのみとする必要があります。
coherence.distributed.localstorageシステム・プロパティを使用して、プロセス単位でローカル記憶域を無効化します。これにより、キャッシュ・クライアントとキャッシュ・サーバーで同じ構成ディスクリプタを使用できます。例:
java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dcoherence.distributed.localstorage=false com.MyApp
com.tangosol.net.CacheFactoryクラスを使用してキャッシュのインスタンスを取得するアプリケーションはクラスタのメンバーとなり、キャッシュ・クライアントと見なされます。次の例は、キャッシュ・クライアントを起動する最も一般的な方法を示しています。
CacheFactory.ensureCluster();
NamedCache cache = CacheFactory.getCache("cache_name");
キャッシュ・クライアントであるアプリケーションを起動するときは、Javaの-cpオプションを使用して、coherence.jarファイルの場所およびtangosol-coherence-override.xmlファイルとcoherence-cache-config.xmlファイルの場所を指定します。これらの構成ファイルの場所は、クラスパス上でcoherence.jarファイルよりも前の位置に記述する必要があります。そうしなかった場合、coherence.jarファイルにあるデフォルトの構成ファイルを使用してキャッシュ・サーバーのインスタンスが起動します。構成ファイルの詳細は、第3章「構成の理解」を参照してください。
次の例では、キャッシュ・クライアントであるアプリケーションを起動し、COHERENCE_HOME\configディレクトリに存在する構成ファイルを使用し、メンバー上の記憶域を無効化します。
java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dcoherence.distributed.localstorage=false com.MyApp
テスト用のCOHERENCE_HOME\bin\coherenceスクリプトが用意されており、このスクリプトでキャッシュ・クライアント・インスタンスを起動できます。このスクリプトでは、基本的な環境を設定し、記憶域を無効化して、プロンプトを返すCacheFactoryクラスを実行します。プロンプトは、キャッシュおよびクラスタとやり取りを行うコマンドを入力するために使用されます。このスクリプトには、Windowsベース・プラットフォーム用とUNIXベース・プラットフォーム用の両方があります。多くの場合、このスクリプトは特定のクラスタに合せて変更したうえで使用します。このクラスは、スクリプトを使用せずに、コマンド行から直接起動することもできます。例:
java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dcoherence.distributed.localstorage=false com.tangosol.net.CacheFactory
CoherenceアプリケーションがGARとしてパッケージ化されている場合は、クライアント・メンバーが起動された後にプロンプトでserverコマンドを使用して、CacheFactoryインスタンスによってGARをロードできます。
server [<path-to-gar>] [<app-name>]
次の例では、MyGar.garファイル内にパッケージ化されたCoherenceアプリケーションのアーティファクトをロードします。デフォルトの名前(MyGAR)がアプリケーション名として使用されます。
Map (?) server D:\example\MyGAR.gar
この項には次のトピックが含まれます:
クラスタ・メンバーをシャットダウンするには、UNIXプラットフォームではkillコマンド、WindowsプラットフォームではCtrl+cを使用することが普通です。これらのコマンドでは、JVMの通常の終了で呼び出される標準のJVMシャットダウン・フックを開始します。
|
注意: kill -9コマンドを発行すると、異常なJVM終了が始まり、シャットダウン・フックは実行されません。ただし、終了するサービスがノードセーフであることが(JMXの管理を使用した確認で)終了前にわかっている場合は、一般的には正常なシャットダウンは不要です。 |
シャットダウン・コマンドを受け取ったクラスタ・メンバーが実行するアクションは、オペレーション・オーバーライド・ファイルの<shutdown-listener>要素で構成します。次のオプションを使用できます。
none - 明示的なシャットダウン・アクションは実行しません。外部シャットダウンに対する動作が目的どおりであることをテストで検証済である場合を除き、本番ではこの値の設定をお薦めします。
force - (デフォルト)Cluster.stop()をコールすることにより、ノードのハードストップ(強制停止)を実行します。これは、デフォルトの初期状態の動作です。
graceful - Cluster.shutdown()をコールすることにより、通常のシャットダウンを実行します。
true - forceと同じ。
false - noneと同じ。
次の例では、シャットダウン・フックをnoneに設定します。
<?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>
<shutdown-listener>
<enabled system-property="coherence.shutdownhook">none</enabled>
</shutdown-listener>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルのかわりにcoherence.shutdownhookシステム・プロパティを使用して、シャットダウン・フックの動作を指定します。例:
-Dcoherence.shutdownhook=none
DefaultCacheServerクラスには、キャッシュ・サーバーのシャットダウンに使用するメソッドが2つ用意されています。
|
注意: DefaultCacheServerクラス自身がstaticメンバーとして保持しているインスタンスをシャットダウンするスタンドアロン・アプリケーションで、シャットダウンがコールされることを想定しています。 |
shutdown() - DefaultCacheServer.main()メソッドまたはDefaultCacheServer.start()メソッドを使用して別のスレッドで起動したキャッシュ・サーバーのシャットダウンに使用するstaticメソッドです。
shutdownServer() - このメソッドは、アプリケーションが保持しているDefaultCacheServerインスタンスに対してコールします。
ローリング再起動は、再起動中にデータを失うことなく、クラスタ内のキャッシュ・サーバーを再起動する技術です。ローリング再起動を使用すると、キャッシュ・サーバーを再起動している間も、そのキャッシュ・サーバーのデータをクラスタ上の他のキャッシュ・サーバーに再配布できます。クラスタ内の各キャッシュ・サーバーを順番に再起動して、クラスタ全体の再起動を効果的に行うことができます。
通常、ローリング再起動は、キャッシュ・サーバーやそのホスト・コンピュータを更新する必要がある場合や、キャッシュ・サーバーを新しいパッチ・セット・リリースまたはパッチ・セット更新リリースにアップグレードする場合に実行されます。ただし、この技術は、キャッシュ・データの一部を現在管理しているキャッシュ・サーバーを再起動するときにいつでも使用することもできます。
|
注意: クラスタをアップグレードするときに、ローリング再起動はパッチ・セットまたはパッチ・セット・リリースまたはパッチ・セット更新リリースにアップグレードするためにのみ使用でき、メジャーまたはマイナー・リリースのアップグレードでは使用できません。Oracle Fusion Middlewareのリリース番号の詳細は、『Oracle Fusion Middlewareの管理』を参照してください。 |
ローリング再起動には、最初に考慮しておくべき点があり、クラスタを起動する前に設定が必要です。次の前提条件を満たしていないクラスタでは、ローリング再起動を実行できません。
クラスタ内のキャッシュ・サーバーは、単一のキャッシュ・サーバーのシャットダウンを処理するための十分な容量を備えている必要があります(n - 1。nはクラスタ内のキャッシュ・サーバーの数)。キャッシュ・サーバーが最大容量での稼働に達すると、データの再配布中にメモリー不足の例外またはデータ・エビクションが発生する可能性があります。キャパシティ・プランニングの詳細は、『Oracle Coherenceの管理』を参照してください。
すべてのキャッシュ・サーバーでリモートJMX管理が有効になっていて、最低でも2つのキャッシュ・サーバーに稼働中のMBeanサーバーが含まれている必要があります。JConsoleなどのMBeanブラウザを使用して、MBeanサーバーに接続できることを確認してください。JMX管理の構成およびMBeanサーバー・インスタンスへの接続の詳細は、『Oracle Coherenceのマネージメント』を参照してください。
非同期バックアップを使用するようにキャッシュ・サービスが構成されている場合、stopメソッドまたはkill -9ではなく、shutdownメソッドを使用して、正しい順序でシャットダウンを実行します。そうしないと、非同期バックアップの完了前にメンバーがシャットダウンされる場合があります。shutdownメソッドは、すべての更新が完了することを保証します。
次の手順を使用して、キャッシュ・サーバーを再起動します。ホスト・コンピュータを再起動する場合は、コンピュータをシャットダウンする前にすべてのキャッシュ・サーバー・プロセスが停止していることを確認してください。
キャッシュ・サーバーを再起動するには:
MBeanブラウザを使用して、Coherence MBeanサーバーに接続します。再起動しようとしているキャッシュ・サーバーがMBeanサーバーをホストしていないことを確認します。
Coherence Service MBeanから、キャッシュ構成ファイル内で構成されているキャッシュに対応するクラスタ・サービスを選択します。
任意のクラスタ・メンバーのStatusHA属性をチェックし、属性の値がMACHINE-SAFEであることを確認します。MACHINE-SAFE状態は、所定のコンピュータで稼働しているキャッシュ・サーバーのすべてがデータを失わずに停止可能であることを示します。属性がMACHINE-SAFEでない場合は、再起動を実行する前に、(場合によっては別のコンピュータで)追加のキャッシュ・サーバーを起動する必要があります。StatusHA属性の詳細は、『Oracle Coherenceのマネージメント』を参照してください。
キャッシュ・サーバーをシャットダウンします。
MBeanブラウザから、StatusHA属性を再確認し、状態がMACHINE-SAFEに戻るまで待ちます。
キャッシュ・サーバーを再起動します。
MBeanブラウザから、StatusHA属性を再確認し、状態がMACHINE-SAFEに戻るまで待ちます。
他のキャッシュ・サーバーを再起動する場合は、ステップ4から7を繰り返します。
