アプリケーション環境のアップグレードのロードマップ

2 アプリケーション環境のアップグレードのロードマップ

アップグレードのロードマップを使用して、Oracle WebLogic Serverアプリケーション環境のアップグレードに必要な手順を識別します。WebLogicのアプリケーション環境をアップグレード、構成およびデプロイすると、WebLogicのアプリケーション環境のアップグレードが完了します。

アップグレードのプランニング

WebLogicアプリケーション環境をアップグレードする前に、アップグレード・パスをプランニングします。アップグレードのプランニングには、アプリケーション環境のインベントリの生成、サポートされるシステム構成の確認、アプリケーション環境の互換性情報の確認、およびアップグレード・パスの作成が含まれます。

使用している環境のすべてのアップグレード要件に対応する計画を策定するには、次のステップを実行します。

ステップ1: アプリケーション環境のインベントリの実施

次のコンポーネントを指定することで、アプリケーション環境のインベントリを生成します。

管理サーバーとそれが存在するコンピュータ
管理対象サーバーとそれが動作しているコンピュータ
アプリケーションの場所(すべての外部クライアント・アプリケーションも含む)
次のような外部リソース:
- 永続データとアプリケーション・データの保存に使用されているデータベース
- ファイアウォール
- ロード・バランサ
アプリケーション環境を構築するのに必要なタスクの自動化に使用されているツール、スクリプト、テンプレート、およびソース・コード

「アップグレード・プロセスの概要」にアプリケーション環境の例がありますので(図1-1)、参考にしてください。

ステップ2: サポート対象構成情報の確認

WebLogic Server 14.1.2.0.0でサポートされる構成(たとえば、JDKバージョン、オペレーティング・システム・バージョン、Webサーバー・バージョン、データベース・バージョン)は変更されました。ご使用の環境を、これらの製品および他の製品のサポートされるバージョンにアップグレードする必要がある場合があります。

サポートされる構成の詳細は、Oracle Technology Network (OTN)上のOracle Fusion Middlewareのサポートされるシステム構成を参照してください。

データベースについては、次の点に注意してください。

インストール・プログラムに含まれる評価版データベース(サンプル・アプリケーションやコード例用またはデモンストレーション・データベースとして提供されます)はDerbyです。Derbyは、Java、JDBCおよびSQL標準に基づくオープン・ソースのリレーショナル・データベース管理システムです。Derbyの詳細は、http://db.apache.org/derby/を参照してください。
Oracle Thinドライバは、WebLogic Serverのインストールに含まれています。
Oracle OCIデータベース・ドライバからThinデータベース・ドライバに移行する場合は、生成されたJDBCモジュールからserverプロパティを削除する必要があります。たとえば:
```
<property> 
  <name>server</name> 
  <value>servername</value> 
</property> 
```
Oracle Thin DriverはWebLogic Serverでインストールされ、使用できる準備が整います。これらのドライバの使用の詳細は、Oracle WebLogic Server JDBCデータ・ソースの管理のWebLogic ServerでインストールされるJDBCドライバに関する項を参照してください。

ステップ3: 互換性情報の確認

ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 14.1.2.0.0のアプリケーション環境で動作します。

ステップ4: アップグレード計画の作成

以上のステップで収集した情報を使用して、アプリケーション環境のアップグレード計画を作成します。

アップグレード・プロセスのスコープとタイミングは、ビジネス・ニーズに応じて特定します。次の点に注意してください:

現在本番環境にデプロイされているアプリケーション環境をアップグレードすることはお薦めしません。開発中またはテスト中のアプリケーション環境をアップグレードし、アップグレードした環境を本番環境にプロモートする前に、標準的な品質保証およびパフォーマンス・チューニングを行うことをお薦めします。
重要なアップグレードの実行後にWebLogic Serverを起動すると、WebLogic Server、WebLogic Server上にレイヤー化された製品またはアプリケーション(あるいはそのすべて)が、既存のデータ・ファイルおよびデータベース表に元に戻せない変更を加える可能性があります。たとえば、デフォルトのファイル・ストアは、古いバージョンではロードできなくなるように変更される場合があります。重要なアップグレードには、メジャー・バージョン、マイナー・バージョンおよびパッチ・セットからのアップグレードや、ファイルまたはデータベース形式を変更する特定のパッチ/アプリケーションからのアップグレードが含まれます。
たとえば、アプリケーション環境に多数のクラスタリングされたドメインがあり、多数のアプリケーションがデプロイされているなど、アプリケーション環境が複雑な場合は、アプリケーション環境のコンポーネントを段階的にアップグレードすることを推奨します。
管理するシステムの多様性とコストを最小限に抑えるため、単一のアプリケーション環境で使用されるWebLogic Serverのバージョン数を制限することを推奨します。
WebLogicドメインでRDBMSセキュリティ・ストアを使用する場合は、RDBMSセキュリティ・ストアが構成された新しいドメインを作成すること推奨します。RDBMSセキュリティ・ストアを使用するドメインが作成済であっても、新しいドメインを作成し、そのドメインに既存のセキュリティ・レルムを移行してください。既存のドメインにはRDBMSセキュリティ・ストアを組み込まないでください。『Oracle WebLogic Serverセキュリティの管理』のRDBMSセキュリティ・ストアの管理に関する項を参照してください。

アップグレードの準備

アップグレード・プロセスを開始する前に、アプリケーションに適用されるアップグレードの互換性の問題があるかどうかを確認する必要があります。次に、実行中のサーバー・インスタンスを停止し、ドメイン内のアプリケーション・コンポーネントをバックアップします。

次のステップを確認して、アップグレードに向けてシステムを準備します。

ステップ1: アプリケーションの確認(必要に応じてアンデプロイ)

ドメインをアップグレードする前に、WebLogic Serverアプリケーションをアンデプロイする必要はありません。ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 14.1.2.0.0のアプリケーション環境で動作します。アプリケーションで非推奨になったAPIまたは削除されたAPIが使用されている場合は、実行時に警告または例外が発生するおそれがあります。

WebLogicには、未使用のAPIを識別したり、移行タスクを自動的に実行するレシピをアクティブ化することで、アプリケーションの移行プロセスを簡素化するのに役立つツールが用意されています。

WebLogic移行分析ツールは、WebLogic Serverから削除されたか使用されなくなったWebLogicアプリケーション内のAPIを識別するコマンドライン・ユーティリティです。WebLogic移行分析ツールの使用方法の詳細は、「使用されないAPIの識別」を参照してください。
WebLogic OpenRewriteレシピ・プロジェクトで使用するのは標準のOpenRewriteモジュールで、新しいWebLogicバージョンまたは更新されたJDKに移行する必要があるWebLogic Serverアプリケーションのユーザーを使用対象として設計されています。詳細は、「OpenRewriteレシピを使用したWebLogicアプリケーションの移行」を参照してください。

OpenRewriteレシピを使用したWebLogicアプリケーションの移行

OpenRewriteレシピを使用すると、WebLogicアプリケーションを新しいバージョンのWebLogicおよびJavaに簡単に移行できます。

Oracle WebLogicのOpenRewriteレシピには、Rewriteモジュールが実装されており、WebLogicアプリケーションを新しいバージョンのWebLogicおよびJavaに移行する際に一般的なタスクが実行されます。

独自のWebLogicアプリケーションに対してこれらのレシピをアクティブ化する方法の詳細は、WebLogic OpenRewriteプロジェクトのパブリックWebLogic Rewrite GitHubリポジトリにあるGetting Started Readmeを参照してください。

使用されないAPIの識別

新しいバージョンに含まれなくなったクラスとAPIを把握して、アプリケーションを正常にデプロイするために必要な変更に対処することが重要です。WebLogic移行分析ツールを使用して、このようなクラスとAPIを識別します。

WebLogic移行分析ツールは、WebLogicサーバー14.1.2.0.0で削除された(つまり使用されなくなった) WebLogicアプリケーション内のAPIを識別してレポートを生成する、コマンドライン・ユーティリティです。このレポートの目的は、実行中のWebLogicサーバーのクラスパスにある削除(weblogic.jarなど)のみを表示することです。このレポートは、クラスに含まれないすべてのjarファイルについてのレポートを目的とはしていません。WebLogicアプリケーションに関連付けられているもののみがレポートされます。

ノート:

このレポートでは、存在しない(つまり非推奨になった) APIとクラスに関連する潜在的なすべての問題を把握することはできません。たとえば、リフレクションを使用している場合、このレポートでは検出されません。同様に、このレポートによって、ライブラリが削除されたために問題を引き起こした可能性があると示されることがありますが、そのライブラリの独自のコピーが別の場所にある場合もあります。

移行分析ツールを実行するには、次を実行します:

java -jar $WL_HOME/server/lib/weblogic.migration-analysis-tool.jar <archive-file-name> <archive-2> <archive-3>

ここで、<archive-file-name>パラメータは分析対象のファイルです。たとえば:

java -jar $WL_HOME/server/lib/weblogic.migration-analysis-tool.jar /tmp/em_example.war

ステップ2: アプリケーション環境内のサーバーの停止

アプリケーション環境をアップグレードする前に、アプリケーション環境内のすべてのサーバーを停止する必要があります。

ステップ3: アプリケーション環境のバックアップの作成

アプリケーション環境をアップグレードする前に、表2-1に示されているコンポーネントを手動でバックアップすることをお薦めします。ドメイン内のすべてのマシンに関連する情報をバックアップする必要があります。

表2-1 アプリケーション環境のバックアップに関する推奨事項

コンポーネント	推奨事項
ドメイン・ディレクトリ	管理サーバーとアプリケーション環境で定義されているリモートの管理対象サーバーのドメイン・ディレクトリをすべてバックアップします。ノート: アップグレードするドメインの自動バックアップを行っていた、ドメイン・アップグレード・ウィザードは、WebLogic Serverで提供されなくなりました。ドメインをアップグレードする前に、ドメイン・ディレクトリを手動でバックアップする必要があります。
アプリケーション、アプリケーション・データ、および永続データ	ドメイン・ディレクトリの外にあるアプリケーションとデータをすべてバックアップします。
ログ・ファイル	ログに記録されたすべてのメッセージの記録を維持する必要がある場合は、ログ・ファイルをバックアップします。ログ・ファイルにより大量のディスク容量が消費されることがあるので、ログ・ファイルを保持する必要がない場合は、ディスク容量を節約するため削除することもできます。

コンポーネント

推奨事項

ドメイン・ディレクトリ

管理サーバーとアプリケーション環境で定義されているリモートの管理対象サーバーのドメイン・ディレクトリをすべてバックアップします。

ノート: アップグレードするドメインの自動バックアップを行っていた、ドメイン・アップグレード・ウィザードは、WebLogic Serverで提供されなくなりました。ドメインをアップグレードする前に、ドメイン・ディレクトリを手動でバックアップする必要があります。

アプリケーション、アプリケーション・データ、および永続データ

ドメイン・ディレクトリの外にあるアプリケーションとデータをすべてバックアップします。

ログ・ファイル

ログに記録されたすべてのメッセージの記録を維持する必要がある場合は、ログ・ファイルをバックアップします。ログ・ファイルにより大量のディスク容量が消費されることがあるので、ログ・ファイルを保持する必要がない場合は、ディスク容量を節約するため削除することもできます。

ステップ4: 必要なOracle製品のインストール

アプリケーション環境をアップグレードする前に、ドメイン内のすべてのコンピュータに必要なOracle WebLogic Server 14.1.2.0.0製品をインストールする必要があります。Oracle WebLogic製品のインストールの詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。

ステップ5: 環境の設定

アップグレードする環境を設定するには:

MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開きます。
WebLogic ServerクラスをCLASSPATH環境変数に、WL_HOME\server\binをPATH環境変数に追加します。WL_HOMEはWebLogic Serverのインストール先の最上位ディレクトリです。

WL_HOME\server\bin\setWLSEnvスクリプトを実行すると、これらの変数を設定できます。

ノート:

UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

アプリケーション環境のアップグレード

アプリケーション環境を最新バージョンのWebLogicサーバーにアップグレードするには、ドメインをバックアップし、管理サーバーのホスト・マシンをアップグレードし、ノード・マネージャを構成して、各管理対象サーバー・インスタンスをアップグレードします。

この表に、アプリケーション環境のアップグレード・ステップの概要を示します。各ステップは、ドメイン内のすべてのマシンに対して、この表に示されている順序で実行する必要があります。

表2-2 アプリケーション環境のアップグレード手順

タスク	説明
ドメインのバックアップ	管理サーバーのドメインをアップグレードする前に、必ずドメインをバックアップしてください。「ドメインのバックアップ」を参照してください
WebLogicドメインのアップグレード(管理サーバー)	再構成ウィザードを実行して、管理サーバーをホストするコンピュータ上のWebLogicドメインをアップグレードします。ノート: 管理対象サーバーのドメインをアップグレードする前に管理サーバーのドメインを完全にアップグレードすることをお薦めします。元のドメインのノード・マネージャ構成、およびアップグレードされたドメインの目的のノード・マネージャ構成に応じて、再構成ウィザードを使用してノード・マネージャをアップグレードできることがあります。「ノード・マネージャのアップグレード手順の決定」を参照してください
ノード・マネージャ構成の完了	これが必要となるのは、既存のドメインがホストごとのノード・マネージャ構成を使用していて、アップグレードされたドメインでドメインごとのノード・マネージャの使用を続行する場合のみです。「ノード・マネージャ構成の完了」を参照してください
各管理対象サーバーのドメインをバックアップします。	管理対象サーバーのドメインをアップグレードする前に、ドメインのバックアップ・コピーを作成します。
WebLogicドメインのアップグレード(リモートの管理対象サーバー)	`pack`および`unpack`コマンドまたはWLST `writeTemplate()`コマンドをオンライン・モードで使用して、管理対象サーバーをホストするすべてのコンピュータ上のWebLogicドメインをアップグレードします。関連項目: リモート・マシンの管理対象サーバー・ドメインの更新 PackおよびUnpackコマンドによるテンプレートとドメインの作成ノート: `unpack`コマンドは、WebLogicドメインに対する`pack`の実行に使用したものと同じバージョンでのみ機能します。管理サーバーと同じコンピュータにある管理対象サーバーについては、これ以上アップグレードのステップを実行する必要はありません。

アップグレードのトラブルシューティング

いずれかのステップでアップグレード・プロセスが失敗すると、再構成ウィザードが失敗の理由を示すメッセージを表示してから、アップグレード・プロセスが終了します。

アップグレード・プロセスを続行するには、次のステップを実行します。

「ステップ3: アプリケーション環境のバックアップの作成」で作成したバックアップ・ファイルを使用してアプリケーション環境を元の状態にリストアします
再構成ウィザードにより報告された障害を修正します。
ドメインをアップグレードするために再構成ウィザードをもう一度実行します。

アップグレード時またはアップグレード後に問題が発生した場合は、『Oracle WebLogic Serverリリース・ノート』の既知の問題と回避策に関する項を参照して問題をトラブルシューティングしてください。