| Oracle® Fusion Middleware Oracle WebLogic Serverのアップグレード 12c (12.2.1) E70005-02 |
|
 前 |
 次 |
このドキュメントでは、以前のリリースのWebLogic ServerからWebLogic Server 12cリリース1 (12.2.1)にサーバーおよびドメインをアップグレードする方法、および必要に応じてWebLogic Server 12.2.1で実行する既存のアプリケーションを更新する方法について説明します。WebLogic Server 12.2.1へのアップグレード時にアプリケーションを変更すると判断する場合や、アプリケーションの変更が必須となる場合もありますが、このドキュメントでは、アプリケーションの変更を行わずにWebLogic Server 12.2.1へアプリケーションを移動する際に考慮が必要な問題について説明します。
このドキュメントの手順は、次のアップグレード・シナリオに対応します。
WebLogic Server 10.3.xの任意のリリースからWebLogic Server 12.2.1へのアップグレード
WebLogic Server 12.1.xからWebLogic Server 12.2.1へのアップグレード
|
注意: WebLogic Server 10.3.1より前のリリースからアップグレードする場合は、「WebLogic Server 10.3.1より前のWebLogicバージョンからのアップグレード」を参照してください。 |
また、このドキュメントでは、既存のWebLogic Server 10.3.xまたは12.1.xドメインをWebLogic Server 12.2.1と互換性を持つように更新(再構成)する方法およびWebサービスをアップグレードする方法についても説明します。
WebLogic Serverは一般的に、WebLogic Serverのバージョン全体でハイレベルのアップグレード機能をサポートします。このドキュメントの目的は、WebLogic Serverアップグレード・サポートの提供と、アップグレード中に直面する可能性のある問題の特定によって迅速な解決を促すことです。
|
注意: 現在のJava EE環境およびデプロイされているアプリケーションを、Oracle Application Server 10gおよびOracle Containers for Java EE (OC4J)からWebLogic Server 12cリリース1 (12.2.1)にアップグレードする場合は、『Oracle Fusion Middleware Java EEアップグレード・ガイド』を参照してください。このドキュメントでは、WebLogic Serverのみを含むOracle製品のインストールのアップグレード・プロセスについて説明します。インストールが他のOracle Fusion Middleware製品に含まれる場合は、アップグレードを開始する前に、『Oracle Fusion Middlewareのアップグレードのプランニング』およびインストールにおける各Fusion Middleware製品のアップグレード・ガイドを参照してください。 |
WebLogic Server12.2.1には、Fusion Middleware再構成ウィザードが含まれていて、WebLogic Serverおよびご使用のアプリケーション環境のアップグレードを支援します。
ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 12.2.1の新たなアプリケーション環境で動作します。
この章の内容は次のとおりです。
アップグレード前に、WebLogic ServerとWebLogic Server 12.2.1のドメイン互換性要件を確認する必要があります。詳細は、『Oracle WebLogic Serverの理解』のドメイン内の互換性に関する項を参照してください。
次のトピックに進む前に、次の用語の説明をお読みください。
アップグレード - このドキュメントでは、アップグレードという用語は、WebLogic Serverをアップグレードし、既存のアプリケーションを未変更のまま、新規の(アップグレードされた)WebLogic Serverバージョンに移動するプロセスのことを指します。
再構成 - アップグレードしたWebLogic Serverのバージョンと互換性を持つように、以前のWebLogic Serverのバージョンで作成されたドメインをアップグレードするプロセスです。これは、再構成ウィザードまたはWLSTのいずれかを使用して実行できます。
アプリケーション環境 - アプリケーション環境には、アプリケーションとそのデプロイ先のWebLogicドメインが含まれます。また、そのドメインに関連するすべてのアプリケーション・データも含まれます。データベース・サーバー、ファイアウォール、ロード・バランサおよびLDAPサーバーなどのリソースが含まれる場合もあります。
移行 - アプリケーションやドメイン構成を、サード・パーティ製品からOracle製品に移動すること。
相互運用性 - (1)あるWebLogic Serverバージョンでデプロイされたアプリケーションが、別のWebLogic Serverバージョンでデプロイされた別のアプリケーションと通信する機能。(2) Oracle製品のコンポーネントが、標準のプロトコルを使用してサード・パーティ製のソフトウェアと通信する機能。
互換性 - あるWebLogic Serverリリースで構築されたアプリケーションを、アプリケーションが再構築されたかどうかに関係なく、別のWebLogic Serverリリースで実行できること。
WebLogic Server 10.3.1より前のWebLogicバージョンを現在使用している場合、バージョン12.2.1へのアップグレードには2段階のプロセスがあります。
最初に現在のインストール内容をWebLogic Server 10.3.6にアップグレードする必要があります。これを実行するには、WebLogic Serverアップグレード・ガイド(10.3.6)の説明に従ってください。http://docs.oracle.com/cd/E23943_01/web.1111/e13754/toc.htmを参照してください。ドメインをアップグレードするには、WebLogic Server 10.3.6ドメイン・アップグレード・ウィザードを使用してください。
|
注意: WebLogic Server 10.3.6アップグレード・インストーラをダウンロードするには、「My Oracle Support」に適切なパッチ番号を入力します。
|
このガイドの説明に従って、WebLogic Server 10.3.6をWebLogic Server 12.2.1にアップグレードします。
|
注意: WebLogic Server 12.1.2から、アップグレード・インストーラは提供されなくなりました。WebLogic Server 12.2.1を新しいディレクトリの場所にインストールする必要があります。既存のインストール上にインストールすることはできません。 |
アプリケーション環境のアップグレードに必要なプロセスは、アプリケーション・スコープにより異なります。アプリケーション環境は、WebLogicドメインとそれに関連付けられているアプリケーションおよびアプリケーション・データで構成されます。また、アプリケーション環境には、ファイアウォール、ロード・バランサ、LDAPサーバーなどの外部リソースも含まれます。図1-1に、WebLogicのアプリケーション環境の例を示します。
表1-1に、図1-1に示されているWebLogicアプリケーション環境のコンポーネントとそのアップグレード要件を示します。
表1-1 WebLogicのアプリケーション環境例のコンポーネントのアップグレード要件
| コンポーネント | 説明 | アップグレード要件 |
|---|---|---|
|
WebLogicドメイン |
管理サーバー(AS)と必要に応じて1台または複数の管理対象サーバー(MS1、MS2、MS3、MS4など)で構成されます。ドメイン内のサーバーは、複数のマシンにまがたる場合があります。さらに、重要なアプリケーションにロード・バランシングとフェイルオーバー保護を適用できるよう管理対象サーバーをクラスタとしてグループ化することができます。WebLogicドメインの詳細は、『Oracle WebLogic Serverドメイン構成の理解』のOracle WebLogicドメインの理解に関する項を参照してください。 |
ドメイン内のすべてのコンピュータのドメイン・ディレクトリをアップグレードします。 |
|
アプリケーション |
WebアプリケーションやEJBなどを含むすべてのJava EEアプリケーション。一般的に、アプリケーションはドメイン内の1つまたは複数の管理対象サーバーにデプロイされます。デプロイメント戦略に応じて、アプリケーションはコンピュータ上のローカルに配置したり、共有ディレクトリを使用してアクセスできます。さらに、外部クライアント・アプリケーションがファイアウォールの外側からアプリケーション環境にアクセスすることも可能です。 |
ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 12.2.1の新たなアプリケーション環境で動作します。詳細については、「旧リリースとの相互運用性および互換性」を参照してください。 |
|
外部リソース |
ドメインとアプリケーション・データを格納するためのデータベース、ロード・バランサ、ファイアウォールなどのソフトウェア・コンポーネント。 |
すべての外部リソースがWebLogic Server 12.2.1と互換性があることを確認します。詳細は、Oracle Technology NetworkにあるOracle Fusion Middlewareのサポートされるシステム構成のページを参照してください。 |
WebLogic Serverにデプロイされているビジネス・アプリケーションのアップグレードには、複数のWebLogic Serverアプリケーションのアップグレードが必要な場合があり、一部のケースでは次の目的のためにドメインも連動してアップグレードする場合があります。
使用対象のWebLogic Serverバージョンの整合性の維持
インストール全体における同一のサポートされた構成環境の使用
特定の相互運用性の要件への対応
たとえば、すべてのアプリケーションおよびドメインを同時にアップグレードする場合や、アップグレードを正確に定義された順序で行う場合、あるいは一部のアプリケーションおよびドメインをアップグレードする一方、その他のアプリケーションおよびドメインは旧バージョンのWebLogic Serverにそのまま残すような場合があります。
アップグレード・プロセスを開始する前に、アップグレードする環境の範囲と、どのアプリケーションをどの順序でアップグレードするかについて検討してください。このドキュメントの範囲では、アップグレードのすべての組合せを網羅することはできません。したがって、アップグレードを計画する前に、次の内容を考慮する必要があります。この内容は、単一ドメインで実行中の単一アプリケーションが関連するアップグレードを対象にしています。
一般的に推奨される手順は、開発環境でアプリケーションをアップグレードし、標準のQA、テストおよびステージング・プロセスを使用して、アップグレードされたアプリケーションを本番環境に移動することです。
アプリケーションのアップグレードでは通常、既存ドメインのアップグレードまたは新規ドメインの作成のどちらかを行います。このドメインから新バージョンのWebLogic Serverでアプリケーションを実行できます。アップグレードするアプリケーションをテストする目的のため、Fusion Middleware構成ウィザードまたは他の構成ツール(WLSTなど)を使用して、新規ドメインを作成する場合もあります。
|
注意: ドメインがバージョン10.3.1より前のWebLogic Serverバージョンを使用して作成された場合は、まずWebLogic Server 10.3.6にアップグレードする必要があります。「WebLogic Server 10.3.1より前のWebLogicバージョンからのアップグレード」を参照してください。WebLogic Server 10.3.6にアップグレードした後で、WebLogic Server 10.3.6ドメイン・アップグレード・ウィザードを実行して、ドメインをアップグレードします。その後、再構成ウィザードを使用して、ドメインをWebLogic Server 12.2.1にアップグレードできます。 |
WebLogic Serverのバージョン・アップグレードを計画する際は、Oracle Technology Network (OTN)のFusion Middlewareのサポート対象システム構成ページを参照して、アップグレードされた環境がOracleでサポートされていることを、特に次の点について確認します。
現行および計画中のJVMおよびJDKのバージョン
オペレーティング・システムのバージョン
データベースのバージョン
Webサービスのバージョン
WebLogic Serverで同時使用または実行されるその他の製品のバージョン。これは、アップグレードされた環境が、WebLogic Serverで使用しているOracleまたは他のベンダーの製品によってサポートされているかを確認するためです。
オラクル社は非推奨(つまり今後のリリースでは廃止予定)となったAPIおよび機能について文書化しており、現在も進行中です。この目的は、アップグレード性を維持するために使用を避けた方がいいAPIおよび機能について通知することです。現行のリリースで実際に廃止されているAPIおよび機能についても文書化されているため、以前のバージョンからアップグレードする場合は、対象のアプリケーションがアップグレードによる影響を受けるかどうかを判断できます。
APIおよび機能の廃止は累積方式です。たとえば、WebLogic Server 10.0からWebLogic Server 12.2.1にアップグレードする場合、アプリケーションはWebLogic Server 12.2.1で廃止されたAPIまたは機能に加えて、WebLogic Server 10.3で廃止されたAPIまたは機能による影響を受ける可能性があります。アップグレードの際は、WebLogic Serverのすべての対象バージョンに対する、非推奨および廃止となった機能に関するドキュメントをすべて確認してください。
WebLogic Serverアプリケーションの構成、デプロイ、起動/停止または監視に使用する、あらゆるオートメーション(WLSTスクリプトなど)にアップグレード・プロセスが与えうる影響を(ある場合は)考慮する必要があります。アップグレード対象のアプリケーションおよびドメインとともに、オートメーションのアップグレードも必要になる場合があります。
アプリケーションでのサードパーティ・ライブラリの使用によって発生しうる潜在的影響を考慮する必要があります。WebLogic Serverに埋め込まれている別バージョンの同一ライブラリと競合する可能性があるためです。特に、新バージョンのWebLogic Serverでは、WebLogic Serverに埋め込まれているオープン・ソース・ライブラリのバージョンが変更されている場合があります。旧バージョンのWebLogic Serverでは正常に動作するアプリケーションで、アップグレード後に新規クラス競合が発生することがあります。
サードパーティ・ライブラリが埋め込まれているアプリケーションをアップグレードする場合、Classloader Analysis Toolの使用と、WebLogic ServerアプリケーションのWebLogic Server 12.2.1へのアップグレード時にフィルタ・クラスローダーの使用を考慮する必要があります。このツールでは競合の特定、診断および解決が可能になり、アップグレード・プロセスも短縮される場合があります。
旧バージョンのWebLogic Serverでアプリケーションを実行中で、WebLogic Serverパッチまたはバグ修正を使用中の場合、アップグレード先のWebLogic Serverのバージョンにそのパッチまたはバグ修正が組み込まれているかどうかを調べる必要があります。
ほとんどの既存のWebLogic Server 10.3.1以降のアプリケーションは、修正を加えることなくWebLogic Server 12.2.1の新たなアプリケーション環境で動作します。実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、付録A「WebLogic Server 12.2.1の旧リリースとの互換性」で互換性情報を確認してください。アプリケーションで非推奨になったAPIまたは削除されたAPIが使用されている場合は、実行時に警告または例外が発生するおそれがあります。
この項では、既存のWebLogic Serverインストールにパッチを適用するために使用できる2つの方法について説明します。
顧客に対するサービスを中断せずにドメイン内のサーバーに更新をロールアウトする、高度に自動化された方法である「ダウンタイムなしのパッチ適用」を使用。この方法は、ドメインに3つ以上のノードが含まれ、パッチを適用するすべてのサーバーがクラスタに割り当てられている場合のみ使用できます。「ダウンタイムなしのパッチ適用について」を参照してください。
サーバーのローリング更新の手動実行。この処理も顧客に対するサービスを中断しませんが、手動の処理です。クラスタの一部でない個別のサーバーにパッチを適用する場合と、ドメインに含まれるノードが3つ未満の場合は、この方法を使用する必要があります。項1.7.1「ダウンタイムなしのパッチ適用について」を参照してください。
WebLogic Server 12.2.1現在、ダウンタイムなしのパッチ適用(ZDTパッチ適用)を使用して、WebLogic Serverインストールに対するパッチ、バンドル・パッチまたはパッチ・セット更新を適用する処理を自動化できます。ZDTパッチ適用を使用すると、OPatchAutoツール、WLSTまたはWebLogic Server管理コンソールを使用して、ドメイン内のサーバーの一部またはすべてにわたり、更新のロールアウトを編成できます。簡略化すると、内容は次のとおりです。
2番目のOracleホームの作成とパッチ適用。これは、手動で行うことも、OPatchAutoを使用して処理を自動化することもできます。
パッチが適用されたOracleホームをノードのすべてに配布。これも、手動で行うことも、OPatchAutoにさせることもできます。
OPatchAuto、WLSTまたはWebLogic Server管理コンソールを使用してパッチ適用ワークフローを構成し、ドメイン内の目的のサーバーを更新。
ZDTパッチ適用では、以前にZDTパッチ適用を使用してWebLogic Serverインストールに適用したパッチを、パッチ適用ワークフローを使用して元に戻すこともできます。
ZDTパッチ適用の詳細は、『ゼロ・ダウンタイム・パッチ適用ワークフローの管理』を参照してください。
WebLogic Serverのローリング更新とは、クラスタまたはドメイン全体を停止せずに、既存のWebLogic Serverインストールに、パッチ、バンドル・パッチまたはパッチ・セット更新をインストールするプロセスのことを指します。ローリング更新は、アクティブなクライアント・セッションの状態を保持します。ローリング更新プロセス中に、クライアント・セッションは、非アクティブ・サーバーからアクティブ・サーバーにフェイルオーバーされ、アプリケーション・ユーザーにシームレスな経験を提供します。
クラスタのローリング更新時に、クラスタ内の他のサーバーが操作を続行する間、クラスタ内の各サーバーは個別にパッチ適用および再起動されます。クラスタの一部ではない管理対象サーバー上でもローリング更新を実行できます。
|
注意: インストールにOracle Enterprise Manager (EM)が含まれる場合、Oracle Enterprise Manager Lifecycle Management管理者ガイドのソフトウェア・デプロイメントのパッチ適用に関する項を参照してください。 |
ローリング更新については、次の制限事項に留意してください。
ローリング更新を使用してWebLogic Serverの新しいマイナー・バージョンにアップグレードすることはできません(たとえばバージョン12.1.2から12.1.3へ)。個々のパッチ、パッチ・バンドルまたはパッチ・セット更新のみをインストールできます(たとえば12.1.2.0.0から12.1.2.0.1へ、12.1.2.0.1から12.1.2.0.2へ、12.1.2.0.0から12.1.2.0.5へ)。新しいマイナー・バージョンにアップグレードするには、新しいOracleホーム・ディレクトリで新しいバージョンをインストールする必要があります。詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。
管理サーバーが実行中のマシンは、管理対象サーバーのみを実行しているドメイン内のマシンと同じまたはそれ以降のバージョンのソフトウェアを実行している必要があるため、そのマシンを最初に更新する必要があります。
WebLogic Serverがインストールされているマシンの場合、そのマシンで複数のサーバーが実行中の場合は、ローリング更新を実行する前に、そのマシン上で管理サーバーが実行中の場合はそれを含め、マシン上のすべてのサーバーを停止する必要があります。
ドメイン内のすべてのサーバーが更新されるまで、ローリング更新プロセス中に構成変更を行わないでください。新しい構成オプションについては、特に注意が必要です。サーバーは処理できない設定を無視して、反応しないため、ローカル構成ファイルが適切に更新されません。また、新しい構成オプションを使用すると、ローリングの方法でのパッチ、パッチ・セットまたはパッチ・セット更新の削除を妨げる可能性があります。
Oracle WebLogic Serverのパッチ、バンドル・パッチまたはパッチ・セット更新を使用してローリング更新を実行するには、Oracle OPatchツールを使用します。一般的なプロセスは次のとおりで、管理サーバーで開始します。詳細は、OPatchを使用したパッチ適用を参照してください。
アプリケーション、データベース・スキーマ、その他のアプリケーション・データ、およびドメインをバックアップしています。
WebLogic Serverのパッチ、バンドル・パッチまたはパッチ・セット更新をクラスタ内のサーバーにダウンロードします。
アップグレードするマシン上のサーバーを停止します。
任意の保留中のプロセスを完了します。
サーバーを正常に停止します。
パッチまたはパッチ・セット更新を適用します。
サーバーを再起動します。
パッチを適用する必要がある各サーバー・マシンに対して、前述の手順を繰り返します。
|
注意: ベスト・プラクティスとして、アクティブなクライアント・セッションの状態を保持するには、アップグレード順序で次のマシン上のサーバーが停止するまで、適切な時間、待機する必要があります。待機する時間は、アプリケーションがアイドル・クライアント・セッションを無効化するのにかかる時間に応じて、5分から10分ほどになることがあります。 |
