![]() ![]() ![]() ![]() |
この節では、WebLogic のアプリケーション環境のアップグレードを準備し、実行する方法について説明します。ここで説明するトピックは以下のとおりです。
WebLogic 9.x からアップグレードする場合は、「WebLogic Server 9.0、9.1、または 9.2 アプリケーション環境から 10.0 へのアップグレード」を参照してください。
アプリケーション環境のアップグレードを計画することは、アップグレード プロセスの重要な手順の 1 つです。使用している環境のすべてのアップグレード要件に対応する計画を策定するには、次の手順に従います。
次の表に示されているコンポーネントのチェックリストを使用して、アプリケーション環境のインベントリを実施します。「アップグレード プロセスの概要」にアプリケーション環境の例がありますので (図 1-1)、参考にしてください。
アプリケーション環境に含まれるすべてのハードウェアおよびソフトウェア コンポーネントのサポート状況を確認します。次の表に、サポート状況を確認する必要のある重要なコンポーネントを示します。
|
|||
|
|||
ほとんどの WebLogic Server アプリケーションは、修正を加えることなく WebLogic Server 10.0 のアプリケーション環境で動作します。ただし、実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、「WebLogic Server 10.0 の旧リリースとの互換性」で確認してください。
以上の手順で収集した情報を使用して、アプリケーション環境のアップグレード計画を作成します。アップグレード プロセスのスコープとタイミングは、ビジネス ニーズに応じて特定します。次の点に注意してください。
http://edocs.beasys.co.jp/e-docs/wls/docs100/ejb/message_beans.html
) を参照してください。
アプリケーション環境をアップグレードする前に、次の手順を実行する必要があります。
ドメインをアップグレードする前に、WebLogic Server アプリケーションをアンデプロイする必要はありません。ほとんどの WebLogic Server アプリケーションは、修正を加えることなく WebLogic Server 10.0 のアプリケーション環境で動作します。実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、「WebLogic Server 10.0 の旧リリースとの互換性」で互換性情報を確認してください。アプリケーションで非推奨になった API または削除された API が使用されている場合は、実行時に警告または例外が発生するおそれがあります。
アプリケーション環境をアップグレードする前に、アプリケーション環境内のすべてのサーバを停止する必要があります。
アップグレード プロセス中、ドメインのバックアップを行うことができます (「ドメインのバックアップ」を参照)。ただし、ウィザードはドメイン ディレクトリのみをアーカイブするため、ファイル パーミッションは維持されません。
アプリケーション環境をアップグレードする前に、次の表に示されているコンポーネントを手動でバックアップすることをお勧めします。ドメイン内のすべてのマシンに関連する情報をバックアップする必要があります。
アプリケーション環境をアップグレードする前に、ドメイン内のすべてのマシンに必要な 10.0 BEA Products をインストールする必要があります。BEA Products 10.0 のインストールの詳細については、『インストール ガイド』(http://edocs.beasys.co.jp/e-docs/common/docs100/install/index.html
) を参照してください。
注意 : | WebLogic Server 10.0 より前のバージョンでノード マネージャを使用している場合は、10.0 製品をインストールするときに、ノード マネージャのリスン ポートを、10.0 より前のバージョンで使用されているポートと同じ番号に設定するようにしてください。ノード マネージャのリスン ポートのデフォルト値は 5556 です。 |
コンフィグレーションによっては、ドメイン内で管理サーバからリモートの管理対象サーバが 1 つまたは複数のマシンで実行されていることがあります。このタイプのコンフィグレーションの場合、リモートの管理対象サーバをホストするすべてのマシンのドメイン ディレクトリをアップグレードする必要があります。
リモートのドメイン ディレクトリを準備するには、管理サーバのホスト マシン上にあるアップグレード前のドメイン ディレクトリのルート ディレクトリから以下のファイルをリモートの管理対象サーバのホスト ドメインのルート ディレクトリにコピーする必要があります。
注意 : | コンフィグレーション内のデータベースが WebLogic Server 10.0 と互換性がない場合、サポートされているデータベースにデータをアップグレードしなければ、新しいアプリケーション環境でデータを使用することはできません。詳細については、「手順 4 : アップグレード計画の作成」を参照してください。 |
次の図に、アプリケーション環境をアップグレードするのに必要な手順を示します。
次の表に、アプリケーション環境のアップグレード手順の概要を示します。手順には、必須のものと省略可能なものがあります。各手順は、ドメイン内のすべてのマシンに対して実行する必要があります。
|
|||
|
|||
|
WebLogic アップグレード ウィザードを使用したアプリケーション環境のアップグレードが完了したら、必要に応じて次の手順を実行する必要があります。
必ずしもすべての手順を実行する必要があるわけではありません。以下の説明に基づいて、アプリケーション環境に必要な手順を決定してください。
MBean の階層構造に最近加えられた変更により、既存のコンフィグレーションおよび管理スクリプト (WLST、wlconfig
、weblogic.Admin
、Ant など) は 10.0 環境で必ずしも動作しない可能性があります。WebLogic Server 10.0 の新しい機能を利用するように、スクリプトを変更することをお勧めします。WebLogic Server の新機能と MBean 階層に加えられた変更の詳細については、『リリース ノート』の「WebLogic Server 10.0 の新機能」(http://edocs.beasys.co.jp/e-docs/wls/docs100/notes/new.html
) を参照してください。
以下の節では、スクリプト ツール、カスタム コンフィグレーション テンプレート、および SNMP について詳しく説明します。
次のコンフィグレーションおよび管理ツールは、WebLogic Server 9.0 から非推奨となりました。
weblogic.Admin
ユーティリティ。詳細については、http://edocs.beasys.co.jp/e-docs/wls/docs100/admin_ref/cli.html
を参照してください。
現在これらのユーティリティのいずれかを使用している場合は、次の節で説明されているように、WebLogic Scripting Tool を使用することをお勧めします。
WebLogic Scripting Tool (WLST) は、コマンドライン形式のスクリプト インタフェースで (Jython で構築)、WebLogic ドメインのコンフィグレーションに使用することができます。WLST を使用することで、WebLogic Server 管理者は、対話形式で、または実行可能なスクリプトにより、管理タスクを実行し、WebLogic Server コンフィグレーションの変更を開始することができます。
WebLogic Platform 8.1 のリリースに伴い、WLST は BEA の dev2dev サイトから評価用として入手できるようになりましたが、WebLogic Platform 8.1 製品には正式なものとして同梱されていません。WLST は、WLST Online と WLST Offline の 2 つの形式で提供されていました。
WebLogic Server 10.0 では、WLST Online と WLST Offline は 1 つのツールとして提供されます。WLST では、WebLogic Server 10.0 の管理機能とコンフィグレーション機能が完全にサポートされています。WLST の詳細については、『WebLogic Scripting Tool ガイド』(http://edocs.beasys.co.jp/e-docs/wls/docs100/config_scripting/index.html
) を参照してください。
注意 : | WLST Online は、WebLogic Server 9.0、9.1、9.2、および 10.0 で実行できます。WLST Offline は、WebLogic Server 9.0、9.1、9.2、および 10.0 で実行できます。 |
10.0 より前の他のツールと同様に、MBean の階層構造に最近加えられた変更により、既存の WLST スクリプトは 9.2 または 10.0 で必ずしも動作しない可能性があります。WebLogic Server 9.2 と 10.0 の新しい機能を利用するように、スクリプトを変更することをお勧めします。
WebLogic Server の新機能と MBean 階層に加えられた変更の詳細については、『リリース ノート』の「WebLogic Server 10.0 の新機能」(http://edocs.beasys.co.jp/e-docs/wls/docs100/notes/new.html
) を参照してください。
次の表は、WebLogic Platform 8.1 Template Builder で作成されたカスタム コンフィグレーション テンプレートをアップグレードするのに必要な手順の概要を示しています。
http://edocs.beasys.co.jp/e-docs/wls/docs100/notes/new.html ) を参照。
|
|
|
SNMP マネージャを使用して WebLogic Server をモニタする場合は、次の手順に従います。
MIB は、BEA_HOME
/wlserver_10.0/server/lib/BEA-WEBLOGIC-MIB.asn1
にあります。WebLogic Server は、既存の管理対象オブジェクトのオブジェクト識別子 (OID) を変更するのではなく、新しい管理対象オブジェクトの新しい OID を追加します。
非推奨の管理対象オブジェクトの一覧については、『WebLogic Server MBean リファレンス』の「Deprecated MBeans」(http://edocs.beasys.co.jp/e-docs/wls/docs100/wlsmbeanref/core/index.html
) を参照してください。非推奨の MBean の説明には、置換 MBean へのポインタも含まれています。SNMP の管理対象オブジェクトはそれぞれ MBean 属性に対応します。
注意 : | 多数の BEA 専用の実行時 MBeans が MIB から削除されています。これらの MBeans は、非推奨の MBeans の一覧に含まれていません。詳細については、『確認済みおよび解決済みの問題』(http://edocs.beasys.co.jp/e-docs/wls/docs100/issues/index.html ) を参照してください。 |
アプリケーション環境の 10.0 へのアップグレードを完了するには、起動スクリプトへのカスタマイズの再適用が必要になる場合があります。以下の節では、デフォルト起動スクリプトおよびカスタム起動スクリプトをカスタマイズする方法について説明します。
アップグレード ウィザードによるアップグレード プロセスでは、デフォルト起動スクリプトに対して行われたカスタマイズの内容 (JAVA_OPTIONS
環境変数の設定など) は保持されません。アップグレード プロセスが完了した後に、デフォルト起動スクリプトを再びカスタマイズする必要があります。
ドメインを 10.0 にアップグレードすると同時に 5.1 より前のバージョンの PointBase を継続して使用する場合は、5.1 より前のバージョンの PointBase データベースの JAR ファイルを CLASSPATH
環境変数定義の先頭に追加する必要があります。これを行うには、setDomainEnv
ファイル内の set CLASSPATH
文を更新します。
注意 : | WebLogic Server ドメインには、5.1 以前のバージョンの PointBase のみ使用できます。 |
カスタム起動スクリプトを作成した場合は、次の手順に従って手動で更新する必要があります。
アップグレード プロセス中にノード マネージャをアップグレードする場合は、WebLogic ドメインをホストしているマシンをノード マネージャに登録する必要があります。これを実行するには、nmEnroll
コマンドを使用します。
注意 : | 管理サーバと管理対象サーバが実行されるようコンフィグレーションされているマシンに nodemanager.domains ファイルがあり、管理サーバと管理対象サーバが同じドメイン ディレクトリを共有している場合は、手動でそのドメインのエントリを < domain-name >=< domain-directory > という形式でファイルに含めることができます。 |
注意 : | デフォルトでは、このファイルは WL_HOME /common/nodemanager (WL_HOME は WebLogic Server のインストール先のルート ディレクトリ) にあります。 |
注意 : | 詳細については、『サーバの起動と停止の管理』の「他のコンフィグレーション情報」に記載されている「nodemanager.domains ファイルのコンフィグレーション」(http://edocs.beasys.co.jp/e-docs/wls/docs100/server_start/nodemgr.html#wp1100920 ) を参照してください。 |
nmEnroll
コマンドを実行すると、WL_HOME
/common/nodemanager
ディレクトリ (WL_HOME
は WebLogic Server のインストール先のルート ディレクトリ) にある nodemanager.domains
ファイルのドメインに関する情報が更新されます。nodemanager.domains
ファイルは、ノード マネージャ インスタンスが制御するドメインを指定するファイルです。このファイルを使用することにより、スタンドアロン クライアントでドメイン ディレクトリを明示的に指定する必要がなくなります。
また、このコマンドを実行すると、管理サーバから以下のファイルがダウンロードされます。
nmEnroll
コマンドを使用してマシンをノード マネージャに登録するには、次の手順に従います。
http://edocs.beasys.co.jp/e-docs/wls/docs100/config_scripting/using_WLST.html#setting_up_your_environment
) の説明に従って、環境を設定します。http://edocs.beasys.co.jp/e-docs/wls/docs100/config_scripting/using_WLST.html#invoke_wlst
) の説明に従って、WLST を呼び出します。
手順 2 の説明に従って、WebLogic Server インスタンスを起動し、connect
コマンドを使用して WLST をサーバに接続します。
nmEnroll
コマンドを入力して、WLST を実行するマシンをノード マネージャに登録します。 nm_password.properties
) と SerializedSystemIni.dat
ファイルの保存先のドメイン ディレクトリのパス。デフォルトでは、この 2 つのファイルは、起動した WLST が格納されているディレクトリに保存されます。nodemanager.domains
ファイルは、このディレクトリに保存されます。デフォルトでは、WL_HOME
/common/nodemanager
(WL_HOME
は WebLogic Server のインストール先のルート ディレクトリ) です。
たとえば、ドメイン ディレクトリが c:/bea/mydomain/common/nodemanager
に指定されおり、ノード マネージャのデフォルトのホーム ディレクトリ (WL_HOME
/common/nodemanager
) が使用されている場合、WLST が実行されているマシンをノード マネージャに登録するには、次のコマンドを使用します。
wls:/mydomain/serverConfig>nmEnroll('c:/bea/mydomain/common/nodemanager')
Enrolling this machine with the domain directory atc:\bea\mydomain\common\nodemanager
....
Successfully enrolled this machine with the domain directory at C:\bea\mydomain\common\nodemanager
wls:/mydomain/serverConfig>
詳細については、『WebLogic Scripting Tool ガイド』の「nmEnroll
」(http://edocs.beasys.co.jp/e-docs/wls/docs100/config_scripting/reference.html#nmEnroll
) を参照してください。
管理サーバを起動したら、JAVA_HOME
、BEA_HOME
、CLASSPATH
などのリモート サーバ起動オプションが対象の管理対象サーバにインストールされている WebLogic Server 10.0 を参照していることを確認します。これは、Administration Console オンライン ヘルプの「管理対象サーバの起動引数のコンフィグレーション」(http://edocs.beasys.co.jp/e-docs/wls/docs100/ConsoleHelp/taskhelp/startstop/ConfigureStartupArgumentsForManagedServers.html
) で説明されているように、Administration Console を使用して行います。
警告 : リモート サーバ起動オプションが正しく設定されていないと、ノード マネージャを使用して管理対象サーバを起動するときに、次のようなメッセージがログ ファイルに書き込まれることがあります。このメッセージは再帰的に送信されるため、最終的に使用可能なディスク容量がすべて消費されるおそれがあります。
No config.xml was found.
Would you like the server to create a default configuration and boot?(y/n):
java.io.IOException: The handle is invalid
at COM.jrockit.io.FileNativeIO.read(III)I(Native Method)
at COM.jrockit.io.NativeIO.read(Ljava.io.FileDescriptor;II)I(Unknown Source)
at COM.jrockit.io.NativeIOInputStream.read(II)I(Unknown Source)
at COM.jrockit.io.NativeIOInputStream.read(I[BI)I(Unknown Source)
at COM.jrockit.io.NativeIOInputStream.read([BII)I(Unknown Source)
at java.io.FileInputStream.read([BII)I(Unknown Source)
アプリケーション環境をプロダクション環境にプロモートする前に、標準的な品質保証およびパフォーマンス チューニングを行います。テスト アプリケーション環境でアプリケーション (外部クライアント アプリケーションを含む) の動作をテストすることをお勧めします。非推奨となった API または削除された API がアプリケーションで使用されている場合は、実行時に警告または例外が発生するおそれがあります。発生した場合は、アプリケーション環境をプロダクション環境にプロモートする前に、必要な修正を行う必要があります。
すべてのテスト基準をクリアしていれば、「手順 4 : アップグレード計画の作成」で定義したアップグレード計画に従って、アプリケーション環境をプロダクション環境にプロモートすることができます。
新しい 10.0 のアプリケーション環境がプロダクション環境にデプロイされたら、既存の環境から新しい環境にリクエストをリダイレクトできるようになります。このようにして、最終的には、既存の環境を廃止することができます。これは、ロード バランサなどを使用して行います。
アップグレード プロセスの手順で問題が発生したら、WebLogic アップグレード ウィザードは問題が発生した理由を示すメッセージを表示してから終了します。ウィザードを続行するには、次の手順に従います。
![]() ![]() ![]() |