クラスタ・メンバーの起動および終了

キャッシュ・サーバーの起動

キャッシュ・サーバーは、キャッシュしたデータを保存するクラスタ・メンバーです。クラスタは、多数のキャッシュ・サーバーで構成される場合があります。各キャッシュ・サーバーはそれぞれ専用のJVMを使用します。

この項には次のトピックが含まれます:

DefaultCacheServerクラスの概要

キャッシュ・サーバーを起動するには、com.tangosol.net.DefaultCacheServerクラスを使用します。キャッシュ・サーバーはコマンド行から起動するか、またはプログラムによって起動できます。キャッシュ・サーバーを起動する際は、次の引数を使用します。

クラスパスで見つかるキャッシュ構成ファイルの名前、またはグリッド・アーカイブ(GAR)へのパス。両方が指定された場合、GARが優先されます。GARは、Coherenceアプリケーションからなるアーティファクトを含み、特定のディレクトリ構造を保持します。GARは、ディレクトリとして残すことも、.gar拡張子を付けてアーカイブ化することもできます。Oracle Coherenceの管理のCoherence GARモジュールの構築を参照してください。
GARのアプリケーション名(オプション)。名前を指定しない場合は、アーカイブ名が使用されます。(ディレクトリ名、または.gar拡張子なしのファイル名)。この名前は、クラスタ上の別のアプリケーションに使用されるアプリケーション・スコープを提供します。
停止済のサービスを確認する間隔(秒数)。停止したサービスは、自動的に開始するように設定されている場合のみ、自動的に開始されます(キャッシュ構成ファイルの<autostart>要素で構成します)。引数が指定されなかった場合のデフォルト値は5秒です。

親トピック: キャッシュ・サーバーの起動

コマンド行からのキャッシュ・サーバーの起動

通常、キャッシュ・サーバーはコマンド行から起動します。Javaの-cpオプションを使用して、coherence.jarファイルの場所およびtangosol-coherence-override.xmlファイルとcoherence-cache-config.xmlファイルの場所を指定します。これらの構成ファイルの場所は、クラスパス上でcoherence.jarファイルよりも前の位置に記述する必要があります。そうしなかった場合、coherence.jarファイルにあるデフォルトの構成ファイルを使用してキャッシュ・サーバーのインスタンスが起動します。構成の理解を参照してください。

次の例では、キャッシュ・サーバー・メンバーを起動し、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スクリプトが用意されています。スクリプトは、Windows用(cache-server.cmd)およびUNIXベース・プラットフォーム用(cache-server.sh)の両方に対して使用できます。このスクリプトを使用すると、基本的な環境を設定してDefaultCacheServerクラスを実行できます。多くの場合、このスクリプトは特定のクラスタに合せて変更したうえで使用します。

ヒント:

テスト中は、各キャッシュ・サーバーを一意に特定する複数のスクリプトをそれぞれ異なる名前で作成しておくと便利なことがあります。たとえば、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クラスのサブクラスを作成し、このクラスのメソッドを無効にして、目的とする任意のカスタム処理を実行できます。

親トピック: キャッシュ・サーバーの起動

キャッシュ・クライアントの起動

キャッシュ・クライアントは、クラスタに参加してそのクラスタのサービスとやりとりするクラスタ・メンバーです。キャッシュ・クライアントには、キャッシュとの間でデータをやりとりするアプリケーションのような単純なものもあれば、キャッシュにあるデータを処理するデータ・グリッド演算アプリケーションのような複雑なものもあります。キャッシュ・クライアントとキャッシュ・サーバーとの大きな違いは、一般的にクラスタの記憶域にはキャッシュ・クライアントは関与しないという点です。

この項には次のトピックが含まれます:

親トピック: クラスタ・メンバーの起動および終了

ローカル記憶域の無効化

パーティション・キャッシュ・サービス(分散キャッシュ)を使用するキャッシュ・クライアントでは、パーティション化したデータを保持しないようにします。記憶域を無効にしたキャッシュ・クライアントは良好なパフォーマンスを示し、使用するリソースも少なくてすみます。パーティション化したデータを分散する範囲は、キャッシュ・サーバー・インスタンスどうしのみとする必要があります。

coherence.distributed.localstorageシステム・プロパティを使用して、プロセス単位でローカル記憶域を無効化します。これにより、キャッシュ・クライアントとキャッシュ・サーバーで同じ構成ディスクリプタを使用できます。たとえば:

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dcoherence.distributed.localstorage=false com.MyApp

親トピック: キャッシュ・クライアントの起動

キャッシュ・クライアントを起動するためのCacheFactoryクラスの使用

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ファイルにあるデフォルトの構成ファイルを使用してキャッシュ・サーバーのインスタンスが起動します。構成の理解を参照してください。

次の例では、キャッシュ・クライアントであるアプリケーションを起動し、COHERENCE_HOME\configディレクトリに存在する構成ファイルを使用し、メンバー上の記憶域を無効化します。

java -cp COHERENCE_HOME\config;COHERENCE_HOME\lib\coherence.jar -Dcoherence.distributed.localstorage=false com.MyApp

テスト用のCOHERENCE_HOME\bin\coherenceスクリプトが用意されており、このスクリプトでキャッシュ・クライアント・インスタンスを起動できます。スクリプトは、Windows用(coherence.cmd)およびUNIXベース・プラットフォーム用(coherence.sh)の両方に対して使用できます。このスクリプトでは、基本的な環境を設定し、記憶域を無効化して、プロンプトを返すCacheFactoryクラスを実行します。プロンプトは、キャッシュおよびクラスタとやり取りを行うコマンドを入力するために使用されます。多くの場合、このスクリプトは特定のクラスタに合せて変更したうえで使用します。このクラスは、スクリプトを使用せずに、コマンド行から直接起動することもできます。たとえば:

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と同じ。

coherence.shutdown.timeoutシステム・プロパティには、シャットダウンの完了まで待機する時間を構成します。この時間が経過するとタイムアウトします。デフォルト値は、2分です。Coherenceアプリケーションで、永続性、ライトビハインド・キャッシュ・ストア、または2分を超える時間がかかるその他の非同期操作が使用される場合は、保留中の非同期操作が完了できるようにタイムアウトを長く構成する必要があります。このシステム・プロパティ値には、3s (3秒)、5m (5分)、または1h (1時間)のように時間を構成します。

正常なシャットダウンが完了するまでにかかる時間がcoherence.shutdown.timeoutの時間を超えると、JVMプロセスはハングしたと見なされ、haltを使用して突然終了します。シャットダウンがタイムアウトすると、未処理の非同期操作すべては完了しない可能性があります。このため、アプリケーション環境で発生する可能性がある未処理の非同期操作数に応じて、十分な長さになるようにcoherence.shutdown.timeoutを構成することが重要です。

次の例では、シャットダウン・フックを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の管理のリリース番号の形式を参照してください。

この項には次のトピックが含まれます:

親トピック: クラスタ・メンバーの起動および終了

ローリング再起動の前提条件

ローリング再起動には、最初に考慮しておくべき点があり、クラスタを再起動する前に設定が必要です。次の前提条件を満たしていないクラスタでは、ローリング再起動を実行できません。

クラスタ内のキャッシュ・サーバーは、単一のキャッシュ・サーバーのシャットダウンを処理するための十分な容量を備えている必要があります(n - 1。nはクラスタ内のキャッシュ・サーバーの数)。キャッシュ・サーバーが最大容量での稼働に達すると、データの再配布中にメモリー不足の例外またはデータ・エビクションが発生する可能性があります。Oracle Coherenceの管理のキャッシュ・サイズ計算の推奨事項を参照してください。
すべてのキャッシュ・サーバーでリモートJMX管理が有効になっていて、最低でも2つのキャッシュ・サーバーに稼働中のMBeanサーバーが含まれている必要があります。JConsoleなどのMBeanブラウザを使用して、MBeanサーバーに接続できることを確認してください。Oracle Coherenceの管理のJMXを使用したOracle Coherenceの管理を参照してください。

非同期バックアップを使用するようにキャッシュ・サービスが構成されている場合、stopメソッドまたはkill -9ではなく、shutdownメソッドを使用して、正しい順序でシャットダウンを実行します。そうしないと、非同期バックアップの完了前にメンバーがシャットダウンされる場合があります。shutdownメソッドは、すべての更新が完了することを保証します。

永続性を使用する場合、ローリング再起動はディスクに格納されているデータの形式に依存しませんが、致命的なイベントに直面した場合にクラスタをロールバックできる「セーブポイント」があることを確認するために、予防的なステップを実行できるシナリオがあります。ディスク上の永続ファイルは、新しいバージョンから以前のバージョンに移行するときに読み取れなくなることがあります。

したがって、ロール前に関連するサービスの永続スナップショットを実行することをお薦めします。スナップショットを使用したキャッシュ・サービスの永続化を参照してください。これは、アプリケーションの許容範囲に基づいて、サービスを一時停止しながら(グローバルな整合性を確保するために)実行することも、実行しないことも可能です。スナップショットは、ロール中に問題が発生した場合にクラスタをロールバックできる「セーブポイント」を提供します。

ノート:

Coherenceによって、ディスクに保存されているデータの形式が変更される場合があります。記憶域形式の変更を含むバージョンからローリングする場合、ロール/アップグレードの前にスナップショットを作成することを強くお薦めします。

親トピック: ローリング再起動の実行

ローリング再起動のためのキャッシュ・サーバーの再起動

次の手順を使用して、キャッシュ・サーバーを再起動します。ホスト・コンピュータを再起動する場合は、コンピュータをシャットダウンする前にすべてのキャッシュ・サーバー・プロセスが停止していることを確認してください。

ノート:

次の手順では、同じCoherence JARまたはORACLE_HOMEをどのキャッシュ・サーバーも共有しないと想定しています。一部のキャッシュ・サーバーで同じCoherence JARまたはORACLE_HOMEが共有されている場合は、サーバーを論理ユニットとして扱い、各サーバーで同時にステップを実行してください。

キャッシュ・サーバーを再起動するには:

MBeanブラウザを使用して、Coherence MBeanサーバーに接続します。再起動しようとしているキャッシュ・サーバーがMBeanサーバーをホストしていないことを確認します。
Coherence Service MBeanから、キャッシュ構成ファイル内で構成されているキャッシュに対応するクラスタ・サービスを選択します。
任意のクラスタ・メンバーのStatusHA属性をチェックし、属性の値がMACHINE-SAFEであることを確認します。MACHINE-SAFE状態は、所定のコンピュータで稼働しているキャッシュ・サーバーのすべてがデータを失わずに停止可能であることを示します。属性がMACHINE-SAFEでない場合は、再起動を実行する前に、(場合によっては別のコンピュータで)追加のキャッシュ・サーバーを起動する必要があります。Oracle Coherenceの管理のServiceMBeanを参照してください。
キャッシュ・サーバーをシャットダウンします。
MBeanブラウザから、StatusHA属性を再確認し、状態がMACHINE-SAFEに戻るまで待ちます。
キャッシュ・サーバーを再起動します。
MBeanブラウザから、StatusHA属性を再確認し、状態がMACHINE-SAFEに戻るまで待ちます。
他のキャッシュ・サーバーを再起動する場合は、ステップ4から7を繰り返します。

親トピック: ローリング再起動の実行

ローリング再起動後またはローリング再起動中の永続性ロールバック

ローリング再起動中に問題が発生した場合は、クラスタ全体をロールバックすることをお薦めします。新しいバージョンのアプリケーション(またはCoherenceあるいはその両方)を含むノードを以前のバージョンにロールバックするか、より深刻な場合はクラスタを完全に再起動することで、クラスタをロールバックできます。

移行先の新しいバージョンに、記憶域形式を変更するCoherenceパッチが含まれている場合(Oracle Coherenceリリース・ノートで強調表示)、永続ストアは古い形式と新しい形式が混在した状態になる可能性があります。

クラスタが完全に再起動されると、混在した状態によってリカバリに失敗し、失敗したストアがごみ箱に移動されます。この時点で、PersistenceManagerMBeanのforceRecovery操作(JConsoleではCoherence/Persistence/<servicename>/PersistenceCoordinatorなど)を選択して、リカバリできなかったパーティションの空のバージョンをCoherenceに強制的に復元させることができます。関連するサービスのスナップショットを作成した場合は、スナップショットをリカバリして、そのサービスの状態を元に戻すことができます。

親トピック: ローリング再起動の実行