| Oracle® Fusion Middleware Oracle Coherenceのインストール 12c (12.2.1.2.0) E82726-01 |
|
 前 |
 次 |
この章の内容は次のとおりです。
バージョン12.1.xからのアップグレード
バージョン3.7.1.xからのアップグレード
一般的な手順:
リリース・ノートをよく読み、使用している機能の変更点を確認します。
特に、デフォルトの動作の変更に注意します。
わずかな変更でも顧客SLAに影響を与える可能性があるため、QAおよびパフォーマンス・テストの期間を計画します。
Coherenceのアップグレードで必要な場合、JVMへのアップグレードを計画します。
任意の外部システムとの互換性をチェックします。
環境、ネットワーク、外部システムでの変更を、計画されたアップグレードと組み合せないようにします(または、製品の新しいリリースとして扱います)。
この項では、12.1.xから12.2.1.xへのアップグレードで、共通して実行するタスクについて説明します。
この項には次のトピックが含まれます:
maven-gar-pluginプラグインおよびmaven-gar-archetypeアーキタイプは、それぞれgar-maven-pluginおよびgar-maven-archetypeにリファクタリングされました。また、現在のバージョンは、12.2.1-0-0です。Mavenを使用して、Oracle Coherenceのアプリケーションを作成、ビルドおよびデプロイしている場合、使用するスクリプトを変更する必要があります。CoherenceでのMavenの使用方法の詳細は、『継続的インテグレーションによるアプリケーションの開発』を参照してください。
新しいデフォルトのキャッシュ構成ファイルは、coherence.jarライブラリに含まれています。新しいデフォルト構成は、以前の構成との下位互換性はありません。ソリューションが、以前のデフォルトのキャッシュ構成ファイルに依存する場合、新しいキャッシュ構成ファイルを記述し、必要なキャッシュ・マッピングを定義し、デフォルトのキャッシュ構成ファイルをオーバーライドすれば、問題を適切に解決できます。ソリューションがデフォルトのキャッシュ構成ファイルに依存しない場合、更新は必要ありません。
大幅な機能の拡張によりCoherenceのアドレスおよびポートを構成する方法が簡素化され、ソリューションの更新が必要な場合があります。拡張機能は次のとおりです。
Coherenceでは、現在、デフォルトのクラスタ・ポートとして、ポート7574をマルチキャスト通信で使用し、239.192.0.0をデフォルトのアドレスとして使用します。明示的に構成されたアドレスおよびポートは、今までどおり使用できます。ただし、以前のデフォルトに依存するソリューションは、新しいデフォルトを使用するために更新する必要があります。Oracle Coherenceでのアプリケーションの開発のクラスタのマルチキャスト・アドレスおよびポートの指定に関する項を参照してください。
ユニキャスト・ポートが、現在、自動的に選択されます。明示的に構成されたユニキャスト・ポートを、今までどおり使用できます。ただし、以前のデフォルト・ポートに依存するソリューションは、必要に応じて更新する必要があります。ほとんどの使用方法では、ユニキャスト・ポートは明示的に構成する必要がありません。Oracle Coherenceでのアプリケーションの開発のクラスタ・メンバーのユニキャスト・アドレスおよびポートの指定に関する項を参照してください。
WKAアドレスは現在、クラスタ・ポートを使用します。明示的なポートを含むWKAアドレスも引き続き考慮されますが、可用性の向上のため、ポートを含まない新しい形式をかわりに使用することをお薦めします。ただし、以前のデフォルト・ポートに依存するソリューションは、必要に応じて更新する必要があります。Oracle Coherenceでのアプリケーションの開発のWKAアドレスの指定に関する項も参照してください。
名前サービスは現在、自動的にクラスタ・ポートを使用します。明示的に構成されたプロキシ・アドレスを、今までどおり使用できます。ただし、プロキシの特定のために名前サービスに依存し、以前のデフォルト名前サービス・ポートに依存する拡張クライアントは、新しいデフォルトを使用するために更新する必要があります。同一のネットワーク上でプロキシとして実行され、名前サービスを使用するExtendクライアントでは、操作上の構成がクラスタと互換性があるかぎり、アドレスまたはポートを構成する必要はありません。Oracle Coherenceリモート・クライアントの開発の単一のプロキシ・サービスの定義に関する項を参照してください。
複数のクラスタは、現在、1つのクラスタ・ポートと、マルチキャスト・アドレスまたはWKAアドレスを共有することができます。多くの場合、クラスタ・ポートまたはマルチキャスト・アドレスを変更する必要はありません。SSLを使用するように構成されたクラスタは、共有をサポートしていません。加えて、IPv4 (-DpreferIPv4Stack=true)のみをサポートするように構成されたクラスタは、IPv4のみをサポートするように構成された他のクラスタとのみ共有できます。-DpreferIPv4Stack=trueの使用は通常必要ありません。ソリューションに、同一のネットワーク上に複数のクラスタが含まれる場合、Coherenceのデフォルトのアドレスとポートを使用し、アドレスとポートを明示的に構成しないようにしてください。共有アドレスおよびポートを使用する場合は、一意のクラスタ名を選択する必要があります。
クラスタ・データ・サービス間で使用されるデフォルトのプロトコルがUDPからTCPメッセージ・バス(TMB)に変更されました。UDPは引き続きクラスタの保守に使用されますが、TCPはパフォーマンスに比較的左右されるワークロードに使用されます。ほとんどのネットワークはすでにTCP用に最適に構成されているので、Coherence特有の構成は必要ありません。また、UDPとTCP間でネットワーク負荷の違いはほとんどありません。メッセージ・バス・テスト・ユーティリティが提供され、ネットワーク・ノード間のTMBのパフォーマンスのテストに使用できます。Oracle Coherenceの管理のメッセージ・バス・テスト・ユーティリティの実行に関する項を参照してください。TCPのチューニングの詳細は、Oracle Coherenceの管理のTCPの考慮事項に関する項を参照してください。
クラスタ・メンバー間でのファイアウォールの使用を必要とするソリューションでは、マルチキャストとユニキャストの両方の構成について、クラスタ・ポート(7574)をUDPとTCPの両方に対して開き、ポート7をCoherence TcpRing/IpMonitor停止検出に対して開くようにしてください最後に、ユニキャストのポート範囲をUDPとTCPの両方のトラフィックに対して開き、システムによって割り当てられているエフェメラル・ポートに依存するのではなく、ユニキャストのリスニング・ポート範囲を明示的に設定するようにしてください。ユニキャスト・ポートの構成の詳細は、Oracle Coherenceでのアプリケーションの開発のデフォルトのユニキャスト・ポートの変更を参照してください。
WebLogic Serverは、現在、coherence-rest.jarライブラリをサーバー・クラスパス内に含めます。WebLogicサーバー上にデプロイされた既存のCoherence RESTアプリケーションを再パッケージ化し、coherence-rest.jarライブラリをアプリケーションから削除する必要があります。Oracle Coherenceリモート・クライアントの開発のWebLogicサーバーへのデプロイに関する項を参照してください。
java -jar coherence.jarの実行により、レガシーCoherenceコンソールではなく、DefaultCacheServerインスタンスが起動します。ソリューションがコンソールに依存している場合、bin/coherenceスクリプトを使用するか、次を直接使用してコンソールを起動できます。
java -cp coherence.jar com.tangosol.net.CacheFactory
CohQLで使用可能なBACKUP CACHEおよびRESTORE CACHE文は、非推奨になりました。Coherenceの永続性および新しい永続性文を使用するには、これらのコマンドに依存するアプリケーションまたはスクリプトを更新する必要があります。『Oracle Coherenceでのアプリケーションの開発』を参照してください。
デフォルトのCoherence*Webセッション構成ファイルは、ニア・キャッシュ定義を含みません。ニア・キャッシュ構成に依存するアプリケーションは、デフォルトの構成ファイルをオーバーライドして、ニア・キャッシュ定義を定義する必要があります。ニア・キャッシュの定義の詳細は、Oracle Coherenceでのアプリケーションの開発のニア・キャッシュ・スキームの定義に関する項を参照してください。
Coherence*Webでは、現在、次のWebコンテナをサポートしていません。Apache Tomcat 5.5.n、Apache Tomcat 6.0.n、Caucho Resin 3.1.n、IBM WebSphere 5.n、IBM WebSphere 6.n、IBM WebSphere 7.n、Sun GlassFish 2.n、Sun Application Server 8.n、Oracle OC4J 10.1.3.n、Oracle OC4J 10.1.2.n、Oracle GlassFish 3.n、Oracle GlassFish 4.n、Jetty 6.1.n、Jetty 5.1.n、JBoss Application Server。Coherence HTTPセッション管理が必要なアプリケーションを移行し、サポートされているWebコンテナのバージョンを使用する必要があります。『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』を参照してください。
CoherenceとWebLogic Serverとの統合で以前使用されたactive-cache.jarライブラリは、WLSディストリビューションから削除されました。CoherenceとWLSの統合に依存するソリューションを再ファクタリングし、かわりにManaged Coherence Server統合を使用する必要があります。『Oracle Coherenceの管理』を参照してください。
暗号化フィルタは、現在、使用不可であり、今後、使用されません。暗号化フィルタに依存するソリューションを構成して、SSLを使用する必要があります。「Oracle Coherenceの保護」を参照してください。
TopLink Gridは、TopLink製品において非推奨になりました。アプリケーションは、JPA APIを使用するかわりに、データ・アクセス層でCoherence APIを使用するように再設計する必要があります。
Oracle Coherence GoldenGate HotCacheを使用するアプリケーションは、Coherenceバージョン12.1.xから12.2.1.xにアップグレードする際、特定のJVMクラスパスに対して追加のJARファイルを必要とします。また、それらのJVMクラスパスで12.2.1.xディストリビューションの別のJARファイルを参照する必要があります。
具体的には、すべてのキャッシュ・サーバーのJVM (記憶域が有効なクラスタ・メンバー)のクラスパスにORACLE_HOME/coherence/lib/coherence-hotcache.jarを含める必要があります。同様に、すべてのHotCache JVMのクラスパスに同じJARファイルを含める必要があります(HotCacheの構成で説明しているように、HotCache JVMのクラスパスはプロパティ・ファイルで構成します)。また、キャッシュ・サーバーとHotCache JVMのクラスパスを変更して、HotCacheで使用される12.2.1.xバージョンの別のJARファイルを参照する必要があります。それらのクラスパスは、12.2.1.xインストールの次のJARファイルを参照する必要があります(12.1.xインストールの同じJARファイルの旧バージョンではなく)。
ORACLE_HOME/coherence/lib/coherence.jar
ORACLE_HOME/oracle_common/modules/javax.persistence.jar
ORACLE_HOME/oracle_common/modules/oracle.toplink/eclipselink.jar
ORACLE_HOME/oracle_common/modules/oracle.toplink/toplink-grid.jar
この項では、Coherence 3.7.1.xアプリケーションの12.xへの移行で、共通して使用するタスクについて説明します。使用するCoherenceデプロイメントで必要なタスクを実行してください。ただし、これらのタスクは、12.1.xへアップグレードする際の問題を考慮してから実行してください。これは、この項の手順にとって代わる場合があります。バージョン12.1.xからのアップグレードを参照してください。
この項には次のトピックが含まれます:
次の手順に従って、CoherenceおよびCoherence*Webを使用してWebLogic Serverで実行するアプリケーションをアップグレードします。
すべてのExtendクライアントのカスタマ(Java、C++および.NET)において、Coherence*Extendクライアントをアップグレードする前にクラスタ側をアップグレードする必要があります。これは、Coherenceクライアントおよびプロキシ・アップグレード・ポリシーに準拠しています。Coherence*Extendの現行リリースと以前のバージョンとの互換性の詳細は、Oracle CoherenceのインストールのCoherence*Extendのバージョン間の互換性に関する項を参照してください。
次の項では、Coherence*Webのアップグレードに関する考慮事項を説明します。
以前のリリースのCoherence*Webに含まれていたcoherence-web-spi.warファイルは、非推奨です。WebLogic Server 12c (12.2.1.1)を使用している場合は、このファイルを使用または参照する必要はありません。coherence-web-spi.warファイルをWebLogic Server 12c (12.2.1.1)にデプロイしようとしても無視されます。
デプロイされたアプリケーションでCoherenceデータ・キャッシュを簡単に使用し、セッション管理のためにCoherence*Webをシームレスに統合するためのWebLogic Serverの機能の集合であるActiveCache (active-cache.jar)は、12.1.2リリース以降、非推奨となっています。
ユーザーは、現行リリースのために新しいWebLogic Server/Coherenceアプリケーションを開発するときに、管理対象Coherenceサーバーに移行する必要があります。管理対象Coherenceサーバーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。
以前のリリースでは、Coherence*Web SPIで使用されるCoherenceキャッシュ構成とサービスはsession-cache-config.xmlファイルで定義されていましたが、12c (12.2.1.1)以降は、Coherence*Webで使用されるCoherenceキャッシュ構成とサービスはdefault-session-cache-config.xmlファイルで定義されます。このファイルはcoherence-web.jarファイル内にあります。default-session-cache-config.xmlファイルで定義されているデフォルト・キャッシュ構成とサービス構成は、ほとんどすべてのWebアプリケーションに対応可能です。
Webアプリケーションでsession-cache-config.xmlという名前のファイルをパッケージ化して、独自のカスタム・セッション・キャッシュ構成を作成できます。詳細は、『Oracle Coherence*WebでのHTTPセッション・マネージメントの管理』のカスタム・セッション・キャッシュ構成ファイルの使用に関する項を参照してください
The 11gリリース1 (10.3.6)バージョンのActiveCacheは、『Oracle Fusion Middleware ActiveCacheの使用』に記載されています。このバージョンのActiveCacheは、WebLogic ServerおよびCoherence 12.1.2に対して機能しますが、記載されている手順の一部は不要になりました。
注意:
ActiveCacheは、12.1.2リリース以降、非推奨です。ユーザーは、管理対象Coherenceサーバーへ移行する必要があります。管理対象Coherenceサーバーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。
ActiveCacheデプロイメント・トポロジの選択に関する項では、ActiveCacheをデプロイできるアプリケーションとデータ層の組合せ、すなわちクラスタ・トポロジについて説明しています。ActiveCacheを使用してアプリケーションをアップグレードする場合、後方互換性が必要な場合以外はOut-of-Processトポロジを使用しないでください。現行リリースでは、WebLogic Out-of-Processトポロジの使用をお薦めします。管理対象Coherenceサーバーを使用すれば、WebLogic Out-of-Processトポロジの構成が容易に行えます。
Cache Configuration Fileの配置に関する項では、キャッシュ構成ファイルを配置する場所を説明しています。キャッシュ構成ファイルを保存する場所によってキャッシュ・スコープ(つまり、デプロイされたアプリケーションに対するキャッシュの可視性)が決まります。この項に記載している方法は有効ですが、キャッシュ構成をシステム・クラスパスに配置することは、サーバーでCoherenceを使用するアプリケーションが現在も今後も1つしか存在しない場合を除き、お薦めできません。
アプリケーションをパッケージする場合は、GARファイルの使用をお薦めします。キャッシュ構成ファイルは、GARファイルにパッケージ化されます。GARファイルおよびそのパッケージ化構造の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Oracle Coherenceアプリケーションの開発』を参照してください。
アプリケーション・サーバー・スコープのCoherenceクラスタの構成に関する項では、Coherenceキャッシュに直接アクセスしているWebLogic Serverインスタンス上でデプロイされたすべてのアプリケーションが、1つのCoherenceクラスタの一部となるような構成について説明しています。この手順では、手順1を実行しないでください。すなわち、coherence.jarおよびactive-cache.jarファイルをシステム・クラスパスに配置しないでください。active-cache.jarファイルでは、Coherence統合モジュールをクラスパスに追加するために、MANIFESTファイルでクラスパスを使用します。リリース12.1.2において、Coherence統合モジュールはcoherence.jarに加えてサーバー・クラスパスに常に存在します。
EARスコープのCoherenceクラスタの構成に関する項では、各EAR内にデプロイされたすべてのアプリケーションが、1つのCoherenceクラスタの一部となるような構成について説明しています。キャッシュは、EAR内のすべてのモジュールに対して表示されます。この項で説明している手順は、説明どおりには動作しません。coherence.jarがすでにシステム・クラスパスに配置されているため、「アプリケーション・スコープCoherenceクラスタにフィルタリング・クラスローダーを定義するには」の項に記載されている手順に従う必要があります。
EARスコープによる方法を使用する唯一の理由は、アプリケーションを他のCoherenceアプリケーションから分離するためです。この使用例は、GARファイルによるアプリケーション分離またはキャッシュ構成ファイルのscope要素を使用する方がうまく処理できます。別の使用例は、システム・クラスパスに配置されているものとは別バージョンのcoherence.jarを使用することですが、別バージョンの使用はお薦めできません。
WARスコープのクラスタの構成に関する項では、デプロイされた各Webアプリケーションが、独自のCoherenceクラスタになるような構成について説明しています。キャッシュは、個々のモジュールに対してのみ表示されます。この手順では、手順1および2を実行しないでください。coherence.jarおよびactive-cache.jarを共有ライブラリにデプロイせず、MANIFESTファイルにも記載しないでください。手順3を実行してCoherenceクラスタのシステム・リソースを参照することは可能ですが、管理対象サーバーをCoherenceクラスタのメンバーにする方法をお薦めします。
「例3-10 tangosol-coherence-override.xml」は、ロギングの構成を記述したカスタム・キャッシュ構成ファイルを示しています。ログの構成は不要です。
キャッシュ・サーバーの起動に関する項には、キャッシュ・サーバーを起動する数種類の方法が示されています。Out-of-Processトポロジを管理対象Coherenceサーバーで置き換えないでください。ノード・マネージャを使用したキャッシュ・サーバーの起動に関する項に記載されている手順を、WebLogic Serverにより管理されている外部キャッシュ・サーバーのかわりに管理対象Coherenceサーバーを使用して実行しないでください。
この項では、Coherence 12.1.2以降、非推奨となった機能の代替について説明します。
packet-poolおよびmessage-pool要素は非推奨です。Coherence 12c (12.2.1.1)では、APIでサイズ変更を処理するようになりました。アップグレードするには、すべての構成ファイルから要素を削除してください。
NamedCache lock APIは非推奨です。入力プロセッサAPI (JavaおよびC++用のEntryProcessor、および.NET用のIEntryProcessor)で提供されるロック・サポートをかわりに使用してください。
Coherence 12.1.2リリース以降、com.tangosol.run.xml.XmlConfigurableインタフェースは非推奨になりました。Coherenceでは、このインタフェースを使用して、XMLパラメータをカスタム・クラスのインスタンスに注入していました。
Coherence 12c (12.2.1.1)リリースでは、<param-value>要素内に<instance>および<class-scheme>(または、その他のカスタム・ネームスペース)をネストするXMLを記述して、パラメータを初期化できます。
たとえば、次のJavaコードを考えてみます。
public class MyClass
{
public MyClass(String s, OtherClass o, int i) { ... }
}
public class OtherClass
{
public OtherClass(String s) { ... }
}
次のXMLを記述して、MyClassおよびOtherClassクラスを初期化できます。XMLでは、MyClassクラスが文字列Hello Worldおよび整数42で初期化されます。MyClassクラス内にあるOtherClassクラスのインスタンスは、文字列Goodbye Worldで初期化されます。
<instance>
<class-name>MyClass</class-name>
<init-params>
<init-param>
<param-value>Hello World</param-value>
</init-param>
<init-param>
<param-value>
<instance>
<class-name>OtherClass</class-name>
<init-params>
<init-param>
<param-value>Goodbye World</param-value>
</init-param>
</init-params>
</instance>
</param-value>
</init-param>
<init-param>
<param-value>42</param-value>
</init-param>
</init-params>
</instance>
次の項では、Coherence 12c (12.2.1.1)のアップグレード時に考慮する必要がある問題について説明します。
Exalogic環境内では、DistributedCacheがInfiniband Message Bus (IMB)トランスポートにデフォルト設定されるようになりました。詳細は、Oracle Coherenceでのアプリケーションの開発のDistributedCacheサービス・パラメータに関する項にある<reliable-transport要素の説明を参照してください。
リモートRMIクライアント(別の物理コンピュータ)から接続するときは、java.rmi.server.hostname RMIシステム・プロパティの値をクラスタ・メンバーのIPアドレスに設定してスクリプトに追加してください。このアドレスによって、クライアントに送信されるRMIスタブに正しいサーバー・アドレスが含まれることが保証されます。詳細は、『Oracle Coherenceのマネージメント』のOracle Coherence MBeansへのリモート・アクセスの許可に関する項を参照してください。
キー・アソシエーションは、Extendクライアント上でデフォルトで処理されるようになります。クラスタ上のキー・クラスを強制的に処理するために、クラスタ上でキー・アソシエーションに依存している既存のクライアント実装(Javaクライアントを含む)でdefer-key-association-checkパラメータを設定する必要があります。
キー・アソシエーション処理をExtendクライアントによってではなくクラスタ側で実行するには、クライアント側キャッシュの構成で<remote-cache-scheme>要素内の<defer-key-association-check>要素をtrueに設定します。次に例を示します。
<remote-cache-scheme> ... <defer-key-association-check>true</defer-key-association-check> </remote-cache-scheme>
詳細は、『Oracle Coherenceリモート・クライアントの開発』のキー・アソシエーション・チェックの遅延に関する項を参照してください。
パフォーマンスよりもネットワーク・トラフィックの軽減を優先するために、デフォルトのニア・キャッシュ無効化戦略のautoが変更されました。12c (12.2.1.1)以前の無効化戦略のデフォルト動作は、allに設定してください。詳細は、Oracle Coherenceでのアプリケーションの開発のニア・キャッシュの無効化戦略に関する項を参照してください。
resource-config要素には、com.sun.jersey.api.core.ResourceConfigクラスを拡張するクラスの構成情報を記述します。このインスタンスは、HTTPアクセプタが、指定されたコンテキスト・パスにマップされたCoherence RESTアプリケーション用のリソース・クラスおよびプロバイダ・クラスをロードする際に使用されます。複数のリソース構成クラスを構成して、別々のコンテキスト・パスにマップできます。詳細は、『Oracle Coherenceリモート・クライアントの開発』の組込みHTTPサーバーを指定したデプロイに関する項を参照してください。
Invocable APIを使用するアプリケーションは、Coherence 3.7.1からCoherence 12.xへのアップグレードで、シリアライズ要件が変更されたために発生するエラーを受け取る場合があります。Coherence 3.7.1では、Invocableが自身を含むいくつかのノードに送信されると、リモート・メンバーへの送信用にシリアライズされる前にローカルの実行を開始する可能性があります。Invocableが非一時的なステートを更新すると、そのステートは遅延シリアライズの一部として他のノードに伝わります。
Coherence 12.xでは、Invocable APIをローカル・メンバーで使用するアプリケーションの場合、そのクラス(エントリ・プロセッサ、集計など)がシリアル化できる必要があります。
