Oracle® Fusion Middleware

Oracle WebLogic Serverサーバーの起動と停止の管理

12c (12.1.2)

E48062-01(原本部品番号:E28102-01)

2013年6月

このドキュメントでは、Oracle WebLogic Serverの起動、停止、およびサーバーのライフサイクルを管理する方法について説明します。また、サーバーの障害を回避したり、サーバーの障害から回復したりするためのWebLogic機能についても説明します。

Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理, 12c (12.1.2)

E48062-01

Copyright © 2007, 2013, Oracle and/or its affiliates.All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サーバーのライフサイクル管理の新機能と変更点

2 サーバーの起動と停止

- サーバーの起動:始める前に

- ドメインのバージョン要件

- 起動スクリプトによる管理サーバーの起動

- java weblogic.Serverコマンドによる管理サーバーの起動

- WLSTとノード・マネージャを使用した管理サーバーの起動

- ノード・マネージャを使用しないWLSTによる管理サーバーの起動

- 起動スクリプトによる管理対象サーバーの起動

- 管理コンソールからの管理対象サーバーの起動

- WLSTとノード・マネージャを使用した管理対象サーバーおよびクラスタの起動

- java weblogic.Serverコマンドによる管理対象サーバーの起動

- 管理サーバーにアクセスできない場合の管理対象サーバーの起動

- WebLogic Server起動時のランタイム使用量の制限

- Server Type起動コマンド

- 制限事項

- サーバーの起動と停止を行うためのユーザー資格証明の指定

- ドメインの初期管理ユーザーの指定

- 起動IDファイル

- 管理サーバーの起動IDファイルの作成

- java weblogic.Serverコマンドを使用した管理サーバーの起動IDファイルの作成

- 管理対象サーバーの起動IDファイルの作成

- サーバー起動時に起動IDファイルが使用される仕組み

- 起動後の起動IDファイルの削除

- ユーザーweblogicに関する制限事項

- ノード・マネージャを使用してサーバーを起動するときのユーザー資格証明の指定

- 他の起動タスク

- Javaクラス・ファイルをグローバルに使用可能にする方法

- 管理対象サーバーの管理サーバーへの接続の構成

- WebLogic ServerインスタンスのJavaオプションの指定

- サーバーを実行するJVMの変更

- サーバー・レベル起動と停止クラスの構成

- ドメイン全体のサーバー・パラメータのカスタマイズ

- WebLogic Serverのインスタンスの停止

- 停止スクリプトによるサーバーの停止

- JVMの強制停止

3 WindowsサービスとしてのWebLogic Serverインスタンスの設定

- Windowsサービスの設定:主な手順

- サーバー固有のスクリプトの作成

- 管理サーバーへの接続の構成

- 管理サーバーと管理対象サーバーの起動順序の強制

- 正常停止の有効化

- サーバー・インスタンスを停止するJavaクラス

- 標準出力および標準エラーのファイルへのリダイレクト

- デフォルトのローテーション条件の変更

- クラスパスへのクラスの追加

- サーバー固有のスクリプトの実行

- 設定の検証

- サービスの実行に使用するユーザー・アカウントの検証

- 「サービス」ウィンドウの使用によるサーバー・インスタンスの停止または再起動

- Windowsサービスとして設定されているサーバーの削除

- Windowsサービスとして設定されているサーバーの起動資格証明の変更

4 サーバー障害の回避とサーバー障害からの回復

- 障害回避機能と障害リカバリ機能

- 過負荷保護機能

- クラスタ化サービスのフェイルオーバー

- 障害が発生したサーバー・インスタンスの自動再起動

- サーバー・レベルの移行

- サービス・レベルの移行

- 管理対象サーバー独立モード

- 障害リカバリのためのディレクトリとファイルのバックアップ

- ドメインの構成ディレクトリのバックアップ

- LDAPリポジトリのバックアップ

- SerializedSystemIni.datとセキュリティ証明書のバックアップ

- WebLogic Serverの終了コードと障害後の再起動

- 障害の発生した管理サーバーの再起動

- 管理サーバーの再起動

- 管理サーバー・シナリオの再起動

- 別のマシンでの管理サーバーの再起動

- 管理対象サーバーと再起動された管理サーバー

- 障害の発生した管理対象サーバーの再起動

- 管理サーバーにアクセスできる場合の管理対象サーバーの起動

- 管理サーバーにアクセスできない場合の管理対象サーバーの起動

- 管理対象サーバー独立モードの理解

- MSIモードとノード・マネージャ

- MSIモードとセキュリティ・レルム

- MSIモードとSSL

- MSIモードとデプロイメント

- MSIモードとドメイン・ログ・ファイル

- MSIモードと管理対象サーバーの構成の変更

- MSIモードでの管理対象サーバーの起動

- 障害に関するその他のトピック

5 サーバーのライフサイクルの理解

- サーバーのライフサイクルの図

- サーバーの状態の取得と使用

- サーバー・ライフサイクルにおけるサーバーの状態の理解

- SHUTDOWN状態

- STARTING状態

- STANDBY状態

- ADMIN状態

- RESUMING状態

- RUNNING状態

- SUSPENDING状態

- FORCE_SUSPENDING状態

- SHUTTING_DOWN状態

- FAILED状態

- サーバーのライフサイクル・コマンドの使用について

- 起動

- スタンバイ・モードでの起動

- 管理モードでの起動

- 再開

- 正常な中断

- 強制中断

- 正常な停止

- 正常な停止の制御

- 停止操作とアプリケーションのアンデプロイメント

- 強制停止

- 中断および停止時における処理中の作業の処理

- RMIサブシステム

- Webコンテナ

- タイマー・サービス

- アプリケーション・サービス

- EJBコンテナ

- JMSサービス

- JDBCサービス

- トランザクション・サービス

A サーバーの起動と停止:クイック・リファレンス

- WebLogic Serverのインスタンスの起動

- WebLogic Serverのインスタンスの停止

はじめに

ここでは、このガイド『Oracle WebLogic Serverサーバーの起動と停止の管理』で使用されるアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

次の項では、『Oracle WebLogic Serverサーバーの起動と停止の管理』の内容と構成について説明します。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連ドキュメント

- サーバーのライフサイクル管理の新機能と変更点

ドキュメントのスコープと対象読者

このドキュメントでは、Oracle WebLogic Serverの起動、停止、およびサーバーのライフ・サイクルを管理する方法について説明します。また、サーバーの障害を回避したり、サーバーの障害から回復したりするためのWebLogic機能についても説明します。

このドキュメントは、インストールされたWebLogic Serverのモニターおよび管理に携わるシステム管理者およびオペレータを対象としています。その内容は、デプロイメントからテストおよび本番まで、ソフトウェア・プロジェクトのすべての段階に関連しています。

Java Platform, Enterprise Edition (Java EE)技術、Web技術、オブジェクト指向プログラミング技術、およびJavaプログラミング言語について読者が精通していることを前提としています。

このドキュメントの手引き

このドキュメントの構成は次のとおりです。

- 第1章「概要とロードマップ」では、このドキュメントの構成および関連ドキュメントについて説明します。

- 第2章「サーバーの起動と停止」では、サーバー・インスタンスを起動および停止する複数の方法について説明します。

- 第3章「WindowsサービスとしてのWebLogic Serverインスタンスの設定」では、WebLogic Serverインスタンスを、Windowsホスト・コンピュータ内のWindowsサービスとして設定する手順について説明します。

- 第4章「サーバー障害の回避とサーバー障害からの回復」では、WebLogic Serverインスタンスのフェイルオーバー手順について説明します。

- 第5章「サーバーのライフサイクルの理解」では、WebLogic Serverインスタンスの起動から停止までの操作面について説明します。

- 付録A「サーバーの起動と停止:クイック・リファレンス」では、WebLogic Serverインスタンスを起動および停止するための単純な手順について説明します。

関連ドキュメント

- 構成ウィザードによるドメインの作成

- Oracle WebLogic Serverドメインの構成の理解

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプ

サーバーのライフサイクル管理の新機能と変更点

このリリースで導入されたWebLogic Serverの包括的な新機能一覧は、『Oracle WebLogic Serverの新機能』を参照してください。

2 サーバーの起動と停止

この章では、WebLogic Serverでサーバー・インスタンスを起動および停止する方法について説明します。どの方法を選択するかを、管理コンソールとコマンド・ラインのどちらを使用するか、およびサーバーのライフサイクルの管理にノード・マネージャを使用するかどうかによって判断します。どの方法でサーバーを起動しても、最終的に一連の構成オプションを渡してJava仮想マシン(JVM)が初期化されます。サーバー・インスタンスはJVM内で動作し、JVMでは1つのサーバー・インスタンスのみホストできます。

この章の内容は以下のとおりです。

- サーバーの起動:始める前に

- ドメインのバージョン要件

- 起動スクリプトによる管理サーバーの起動

- java weblogic.Serverコマンドによる管理サーバーの起動

- WLSTとノード・マネージャを使用した管理サーバーの起動

- ノード・マネージャを使用しないWLSTによる管理サーバーの起動

- 起動スクリプトによる管理対象サーバーの起動

- 管理コンソールからの管理対象サーバーの起動

- WLSTとノード・マネージャを使用した管理対象サーバーおよびクラスタの起動

- java weblogic.Serverコマンドによる管理対象サーバーの起動

- 管理サーバーにアクセスできない場合の管理対象サーバーの起動

- WebLogic Server起動時のランタイム使用量の制限

- サーバーの起動と停止を行うためのユーザー資格証明の指定

- 他の起動タスク

- WebLogic Serverのインスタンスの停止

サーバーの起動と停止の簡潔な説明については、付録A「サーバーの起動と停止:クイック・リファレンス」を参照してください。

注意:

管理コンソールでの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーの起動と停止に関する項、およびクラスタに関する項にある様々な起動や停止の手順を参照してください。障害が発生したサーバー・インスタンスおよびクラスタの再起動については、「サーバー障害の回避とサーバー障害からのリカバリ」を参照してください。

サーバーの起動:始める前に

選択するサーバーの起動管理方法や実行済みのセット・アップ・タスクに応じて、サーバー・インスタンスを起動する前に以下の手順の実行が必要になる場合があります。

- バージョン要件を満たす: 「ドメインのバージョン要件」

- ドメインを作成する: Oracle WebLogic Serverの理解の管理タスクに応じた適切な技術の選択に関する項

- ユーザーの資格証明を指定する : 「サーバーの起動と停止を行うユーザー資格証明の指定」

- ノード・マネージャを設定する: 『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの一般的な構成に関する項

- 管理対象サーバーの管理サーバーへの接続を構成する: 「管理対象サーバーの管理サーバーへの接続の構成」

- Java起動オプションを指定する : 「WebLogic ServerインスタンスのJavaオプションの指定」

ドメインのバージョン要件

同一の管理ドメイン内のWebLogic Serverインスタンスはすべて、メジャーおよびマイナー・バージョンが同じである必要があります。1つのドメイン内でサーバーのバージョンを混在させることはできません。ドメイン内のサーバー・インスタンスは、管理サーバーと管理対象サーバーのパッチ・セット・レベルが管理対象サーバーより高い場合、様々なパッチ・セット・レベルにできます。たとえば、管理対象サーバーがバージョン10.3.0である場合、管理サーバーにはバージョン10.3.0、10.3.1以降を使用できます。ただし、管理対象サーバーが10.3.1の場合、管理サーバーは10.3.1以降である必要があります。また、クラスタ内のすべてのサーバー・インスタンスは同じパッチ・セット・レベルにある必要があります。

起動スクリプトによる管理サーバーの起動

管理サーバーは、ドメインの構成データを管理するWebLogic Serverインスタンスです。通常、開発環境では、管理サーバーを起動し、アプリケーションをすぐにその管理サーバーにデプロイすれば十分です。本番環境では、アプリケーションを実行する管理対象サーバーを作成します。管理サーバーと管理対象サーバーの詳細は、『Oracle WebLogic Serverドメインの構成の理解』のWebLogic Serverドメインの理解に関する項を参照してください。

管理サーバーは、デフォルトの起動スクリプトを使用して起動することも、独自の起動スクリプトを作成して起動することもできます。管理サーバーをWebLogic Server付属の起動スクリプトを使用して起動するには:

1. ドメインをまだ作成していない場合は、構成ウィザードまたはWebLogic Scripting Tool (WLST)を使用して作成します。
『構成ウィザードによるドメインの作成』または『WebLogic Scripting Toolの理解』のWLSTオフラインを使用したドメインの作成に関する項を参照してください。

2. ドメインを作成したコンピュータでシェル(コマンド・プロンプト)をオープンします。

3. ドメインを配置したディレクトリに移動します。
デフォルトでは、このディレクトリはORACLE_HOME\user_projects\domains\DOMAIN_NAMEです(DOMAIN_NAMEはドメインのルート・ディレクトリです)。(このディレクトリの名前はドメインの名前です。)

4. 以下のいずれかのスクリプトを実行します。

- bin/startWebLogic.cmd (Windows)

- bin\startWebLogic.sh (UNIXおよびWindows。Windowsの場合、このスクリプトはMKSおよびCygnus BASH UNIXシェル・エミュレータをサポート)

注意:

WebLogic Serverが提供する構成ウィザードのテンプレートを使用すると、ドメイン・ディレクトリにstartWebLogicという名前の起動スクリプトが作成されます。別のソースから提供されたドメイン・テンプレートを使用する場合、ウィザードで起動スクリプトが作成されないか、または別の名前のスクリプトが作成される可能性があります。ウィザードで起動スクリプトを作成するかどうか、および別のスクリプト名を付けるかどうかは、テンプレートの設計者の判断によって異なります。

startWebLogic.cmdを使用してWebLogic Serverを起動するときに、次のエラーが発生します。

Enter username to boot WebLogic server:weblogic
<Error> <Security> <BEA-090782> <Server is Running in Production Mode and Native Library(terminalio)
to read the password securely from commandline is not found>
<Notice> <WebLogicServer> <BEA-000388> <JVM called WLS shutdown hook. The server will force shutdown now>
<Alert> <WebLogicServer> <BEA-000396> <Server shutdown has been requested by <WLS Kernel>>
<Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN>

このエラーは、64ビットOSで32ビットのJDKをインストールすると発生します。このエラーを回避するには、64ビットOSで64ビットのJDKをインストールします。

startWebLogicスクリプトは、次のことを行います。

1. DOMAIN_NAME\bin\setDomainEnv.cmd(UNIXではsetDomainEnv.sh)を呼び出して、環境変数を設定します。DOMAIN_NAMEは、ORACLE_HOME\user_projects\domains\DOMAIN_NAMEなどのドメインを配置したディレクトリです。ORACLE_HOMEは、Oracle WebLogic Serverをインストールした際にOracleホームとして指定したディレクトリです。

注意:

setDomainEnvは、startWebLogicスクリプトなどの他のスクリプトがソースとなるように指定されます。setDomainEnvは、インタラクティブ・シェル内から直接呼び出さないでください。そうすることにより、使用するドメインで予期できない問題が発生する可能性があります。

2. java weblogic.Serverコマンドを実行して、WebLogic Serverインスタンスを実行するよう構成されたJVMを起動します。
サーバーの起動プロセスが正常に完了すると、次のメッセージが標準出力(デフォルトではコマンド・ウィンドウ)に書き込まれます。

<Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>

java weblogic.Serverコマンドによる管理サーバーの起動

weblogic.Serverクラスは、WebLogic Serverインスタンスのメイン・クラスです。Javaコマンドでweblogic.Serverを直接呼び出すことで、サーバー・インスタンスを起動します。

注意:

以下の理由から、java weblogic.Serverは主に初期の開発時に使用し、本番システムを起動する標準のメカニズムとしては使用しないことをお薦めします。

- Oracle Middlewareホーム・ディレクトリの外部にある製品ディレクトリを選択した場合、java weblogic.Serverは機能しません。

- java weblogic.Serverを実行した場合、WebLogic Serverの実行時にパッチが認識されません。

詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンドライン・リファレンス、およびweblogic.Serverコマンドラインを使用したサーバー・インスタンスの起動を参照してください。

WLSTとノード・マネージャを使用した管理サーバーの起動

ノード・マネージャは、WebLogic Serverインスタンスのリモート制御用ユーティリティです。ノード・マネージャを使用すると、管理対象サーバーの制御とモニター、管理サーバーの起動、停止、および再起動を行うことができます。

これらのノード・マネージャの機能には、WebLogic Scripting Toolコマンドおよびスクリプトを使用してアクセスできます。WLSTがノード・マネージャに接続された状態でnmStartコマンドを使用すると、ノード・マネージャで管理サーバーのモニター、停止、および再起動がサポートされます。

WLSTとノード・マネージャを使用して管理サーバーを起動する方法については、『WebLogic Scripting Toolの理解』のWLSTとノード・マネージャを使用したサーバー管理に関する項を参照してください。ノード・マネージャがこのプロセスを実行する仕組みについては、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャが管理サーバーを起動する仕組みに関する項を参照してください。

システムの障害や再起動の際にノード・マネージャが自動的に再起動されるように、オペレーティング・システムのサービスとしてノード・マネージャを実行し、ノード・マネージャを使用して管理サーバーおよび管理対象サーバーの起動や再起動を行うことをお薦めします。

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の起動サービスとしてのノード・マネージャの実行に関する項を参照してください。

ノード・マネージャを使用しないWLSTによる管理サーバーの起動

WLST startServerコマンドは、ノード・マネージャを使用せずに管理サーバーを起動します。サーバーはWLSTとは別個のプロセスで実行されます。WLSTを終了しても、サーバーは停止されません。『WebLogic Scripting Toolの理解』のノード・マネージャを使用しない管理サーバーの起動に関する項を参照してください。

起動スクリプトによる管理対象サーバーの起動

管理対象サーバーは、デプロイされたアプリケーションを実行するWebLogic Serverインスタンスです。管理対象サーバーは、そのすべての構成およびデプロイメント情報について管理サーバーを参照します。通常、本番環境では管理対象サーバーを使用してアプリケーションを実行します。

管理対象サーバーと管理サーバーの詳細は、『Oracle Weblogic Serverドメインの構成の理解』のWebLogic Serverドメインに関する項を参照してください。

WebLogic Serverに付属している構成ウィザードのテンプレートを使用すると、ドメイン・ディレクトリにstartManagedWebLogicという起動スクリプトが作成されます。このスクリプトで管理対象サーバーを起動できます。このスクリプトを使用して、クラスタ内のすべての管理対象サーバーを起動できます。

ドメイン・ディレクトリ・ファイルの詳細は、『Oracle Weblogic Serverドメインの構成の理解』のドメイン構成ファイルに関する項を参照してください。

このスクリプトは、サーバーの起動と管理にノード・マネージャを使用しません。かわりに、Javaコマンドを使用して、WebLogic Serverインスタンスのメイン・クラスのweblogic.Serverクラスを呼び出します。Javaコマンドでのweblogic.Serverの呼び出しの詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド・ライン・リファレンスに関する項を参照してください。

WebLogic Serverスクリプトで管理対象サーバーを起動するには:

1. 前提となる作業については、「サーバーの起動:始める前に」を参照してください。

2. 管理対象サーバーをまだ作成していない場合は作成します。
『構成ウィザードによるドメインの作成』またはOracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの作成に関する項を参照してください。

3. まだ起動していない場合は、ドメインの管理サーバーを起動します。

4. 管理対象サーバーをホストしているコンピュータのシェル(コマンド・プロンプト)で、startManagedWebLogicスクリプトが格納されたディレクトリに移動します。

- DOMAIN_NAME\bin\startManagedWebLogic.cmd (Windows)

- DOMAIN_NAME/bin/startManagedWebLogic.sh (UNIX)
DOMAIN_NAMEは、ドメインを配置したディレクトリです。デフォルトでは、このディレクトリはORACLE_HOME\user_projects\domains\DOMAIN_NAMEです。

5. 以下のいずれかのコマンドを入力します。

- startManagedWebLogic.cmd managed_server_name admin_url (Windows)

- startManagedWebLogic.sh managed_server_name admin_url (UNIX)
managed_server_nameには管理対象サーバー名、admin_urlにはドメインの管理サーバーのリスニング・アドレス(ホスト名、IPアドレスまたはDNS名)およびポート番号を指定します。

たとえば次のコマンドでは、startManagedWebLogic.cmdを使用してmyManagedServerという管理対象サーバーが起動されます。ドメインの管理サーバーのリスニング・アドレスはAdminHost:7001です。

c:\Oracle\Middleware\user_projects\domains\mydomain\bin\startManagedWebLogic.cmd myManagedServer http://AdminHost:7001

6. 起動する管理対象サーバーごとに、別のコマンド・シェルを開き、ステップ4と5を行います。別のマシン上の管理対象サーバーを起動する場合は、そのマシンにリモートまたはローカルでログインしてからステップ4と5を行います。

リモートのWebLogic Serverホストでの管理対象サーバーの実行の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のリモート・マシンにおける管理対象サーバーの作成と起動に関する項を参照してください。

管理サーバーへの接続を構成する方法については、管理対象サーバーの管理サーバーへの接続の構成を参照してください。

startManagedWebLogicスクリプトは、次のことを行います。

1. startWebLogicスクリプトを呼び出します。このスクリプトは、ORACLE_HOME\user_projects\domains\DOMAIN_NAME\bin\setDomainEnv.cmd(UNIXではsetDomainEnv.sh)を呼び出して環境変数を設定します。ORACLE_HOMEは、Oracle WebLogic Serverをインストールした際にOracleホームとして指定したディレクトリです。

注意:

setDomainEnvは、startWebLogicスクリプトなどの他のスクリプトがソースとなるように指定されます。setDomainEnvは、インタラクティブ・シェル内から直接呼び出さないでください。そうすることにより、使用するドメインで予期できない問題が発生する可能性があります。

2. java weblogic.Serverコマンドを実行して、WebLogic Serverインスタンスを実行するよう構成されたJVMを起動します。
サーバーの起動プロセスが正常に完了すると、次のメッセージが標準出力(デフォルトではコマンド・ウィンドウ)に書き込まれます。

<Notice> <WebLogicServer> <000360> <Server started in RUNNING mode>

管理コンソールからの管理対象サーバーの起動

管理コンソールで管理対象サーバーを起動する場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理コンソールからの管理対象サーバーの起動に関する項を参照してください。

WLSTとノード・マネージャを使用した管理対象サーバーおよびクラスタの起動

WLSTとノード・マネージャを使用して管理対象サーバーおよびクラスタを起動する場合は、『WebLogic Scripting Toolの理解』のノード・マネージャを使用したドメイン内またはクラスタ内の管理対象サーバーの起動に関する項を参照してください。WebLogic Serverクラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogicクラスタの設定に関する項を参照してください。

java weblogic.Serverコマンドによる管理対象サーバーの起動

weblogic.Serverクラスは、WebLogic Serverインスタンスのメイン・クラスです。Javaコマンドでweblogic.Serverを直接呼び出すことで、サーバー・インスタンスを起動します。『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド・ライン・リファレンスに関する項およびweblogic.Serverコマンド・ラインを使用したサーバー・インスタンスの起動を参照してください。

管理サーバーにアクセスできない場合の管理対象サーバーの起動

通常、管理対象サーバーは起動時に管理サーバーにアクセスしてその構成情報を取得します。起動時に管理サーバーにアクセスできない場合、管理対象サーバーはローカルにキャッシュされた構成データをconfigディレクトリから読み込むことで構成を取得できます。

注意:

管理対象サーバー・インスタンスを初めて起動するときには、管理サーバーにアクセスできなくてはなりません。それ以後は、管理サーバーが使用できない場合でも管理対象サーバー・インスタンスを起動できます。

管理サーバーにアクセスできない場合の管理対象サーバーの起動の詳細は、「管理サーバーにアクセスできない場合の管理対象サーバーの起動」を参照してください。

WebLogic Server起動時のランタイム使用量の制限

通常、WebLogic Serverインスタンスの起動時には、EJB、JMS、コネクタ、クラスタリング、デプロイメント、管理などすべてのサービスが起動します。ただし、WebLogic Serverに備わっている起動オプションを使用した場合には、これらのサービスの一部を起動対象から除外して、ランタイム範囲を軽量化できます。この起動モードを使用すると、WebLogic Serverの起動時間が短くなり、ホスト・マシンのリソース範囲が小さくなります。

WebLogic Serverインスタンスで起動対象とするサービス群は、サーバー・タイプ・オプションを取るServer Type起動コマンドで定義します。このリリースには、次の2種類のサーバー・タイプ・オプションがあります。

- wls —すべてのサービスを起動(デフォルト)

- wlx —次に示すサービス以外のサービスを起動

- Enterprise JavaBeans (EJB)

- Java EEコネクタ・アーキテクチャ(JCA)

- Java Message Service (JMS)

WebLogic Serverインスタンスでこれらのサービスを使用する必要がない場合、軽量化ランタイムを実行するとパフォーマンスが大幅に向上する可能性があります。

Server Type起動コマンド

軽量化ランタイム・インスタンスは、いずれのWebLogicドメインでも実行できます。WebLogicドメインで、このサーバー・タイプをサポートするために構成設定を追加する必要はありません。ただし、JMSやメッセージング・ブリッジ・リソース、およびEJBやリソース・アダプタを含むアプリケーションは、wlxサーバー・タイプ・オプションを指定して起動したサーバーにはデプロイできません。

軽量化ランタイム・インスタンスを起動するには、次のweblogic.Serverコマンド・オプションを指定します。

-DserverType="wlx"

-DserverType="wlx"オプションは、WebLogic Serverを起動するための次のいずれの方法で使用できます。

- コマンド・ラインで直接起動。「java weblogic.Serverコマンドによる管理サーバーの起動」や「java weblogic.Serverコマンドによる管理対象サーバーの起動」を参照してください。

- サーバー起動スクリプトで起動。「起動スクリプトによる管理サーバーの起動」や「起動スクリプトによる管理対象サーバーの起動」を参照してください。

- WLSTで起動。『WebLogic Scripting Toolの理解』のサーバーのライフ・サイクルの管理に関する項を参照してください。

- ノード・マネージャの使用時。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。

- weblogic.Serverコマンドを使用したドメインの作成時。『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド・ラインを使用したドメインの作成を参照してください。

制限事項

WebLogic Serverの軽量化ランタイム・インスタンスに関しては、次のような制限事項があります。

- WebLogic Serverには、内部的にEJBサービスを使用するサービスがいくつか存在します。軽量化ランタイム・インスタンスを起動すると、次のようないくつかの機能が使用できなくなります。

- 管理EJB群
これらのEJB群はJSR-77をサポートするために使用されるものです。このEJBサービスが無効になると、JSR-77もサポートされなくなります。ただし、これ以外の管理APIはすべて使用可能なままとなります。

- WebLogic Server 9.0または9.1のリモート・デプロイヤ
リモート・デプロイヤEJBは、WebLogic Server 9.0および9.1のweblogic.Deployerユーティリティでのみ、-remoteオプションの指定時に使用されます。weblogic.Deployerユーティリティの-remoteオプションは、バージョン9.2以降のリリースで引き続き使用できます。

- 管理サーバーを軽量化ランタイム・インスタンスとして起動した場合、管理コンソールにはJMS、EJB、およびリソース・アダプタへのリンクは表示されません。これによって、管理サーバーのサーバー・タイプを視覚的に識別できます。ただし、管理サーバーをデフォルトのサーバー・タイプとして起動した場合(つまりwlxサーバー・タイプ・オプションで起動していない場合)には、管理コンソールでもドメイン内で実行されている軽量化管理対象サーバー・インスタンスが識別されません。

サーバーの起動と停止を行うためのユーザー資格証明の指定

WebLogic Serverインスタンスを起動および停止するには、ドメインのサーバーの起動および停止を許可されているユーザーの資格証明を指定する必要があります。ユーザーの資格証明、ロール、および許可の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

表2-1に、WebLogic Serverインスタンスの起動時にユーザー資格証明を指定する方法を示します。

表2-1 ユーザー資格証明の指定

これを指定した場合...

サーバー・インスタンスはこれを行います...

コマンド・ライン上でユーザー名とパスワード。

それらを使用し、いずれの資格証明も要求しません。

boot.properties内にユーザー名とパスワード。

それらを使用し、いずれの資格証明も要求しません。

コマンド・ライン上でユーザー名もパスワードもなし。

- ユーザー名の入力を要求します。

- パスワード入力を2回要求します。

コマンド・ライン上でユーザー名(パスワードなし)。

- コマンド・ラインからのユーザー名を使用します。

- パスワード入力を2回要求します。

コマンド・ライン上でパスワード(ユーザー名なし)。

- ユーザー名の入力を要求します。

- コマンド・ラインからのパスワードを無視し、パスワード入力を2回要求します。

次の項では、次に示すタスクについて説明します。

- ドメインの初期管理ユーザーの指定

- 起動IDファイル

- ノード・マネージャを使用してサーバーを起動するときのユーザー資格証明の指定

ドメインの初期管理ユーザーの指定

ドメインを作成するときには、構成ウィザードによって、初期管理ユーザーのユーザー名とパスワードの指定が要求されます。構成ウィザードは、この情報を基に次の処理を行います。

1. ユーザーをAdministratorsセキュリティ・グループに割り当てます。
Administratorsグループには、WebLogic Serverの起動と管理について最高レベルの権限が付与されます。管理者権限の詳細は、『Oracle Weblogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

2. ユーザーをmyrealmセキュリティ・レルムに追加します。
セキュリティ・レルムは、ユーザー名を認証したり、ユーザーがアクセスできるリソースの種類を指定したり、WebLogicリソースの他のセキュリティ関連サービスを提供したりするコンポーネント(プロバイダ)の集合です。WebLogic Serverはmyrealmセキュリティ・レルムをインストールして、それをデフォルトで使用します。

管理コンソールでは、ユーザーをセキュリティ・レルムに追加できます。WebLogic Serverのインストールしたもの以外の認証プロバイダを使用する場合は、そのプロバイダの管理ツールを使用して管理者権限を持つユーザーを少なくとも1つ作成する必要があります。

3. 開発モードでドメインを作成すると、ウィザードによって、管理サーバーのルート・ディレクトリにあるsecurityディレクトリに起動IDファイルが作成されます。起動IDファイルには、ユーザー名とパスワードの暗号化バージョンが格納されています。これにより、以後サーバーをインスタンス化するときにはログイン・プロンプトが回避されます。「起動IDファイル」を参照してください。
本番モードのドメインでは、サーバーの起動時にコマンド・ラインでユーザー資格証明を入力するように求められます。

起動IDファイル

起動IDファイルは、WebLogic Serverのインスタンスの起動および停止に関するユーザーの資格証明を格納するテキスト・ファイルです。管理サーバーは、ユーザーに資格証明の提示を求めずに、このファイルを参照してユーザーの資格証明情報を取得できます。起動IDファイルでは資格証明が暗号化されているので、起動スクリプトまたは停止スクリプトに暗号化されていない資格証明を格納するより、起動IDファイルを使用した方が安全性は確保されます。起動IDファイルがない場合は、サーバーの起動時にユーザー名とパスワードの入力を要求します。

java weblogic.Serverコマンドを呼び出すスクリプトで管理対象サーバーを起動する場合や、直接java weblogic.Serverコマンドを呼び出す場合、管理対象サーバーからでも起動IDファイルを参照することができます。管理対象サーバーと管理サーバーが同じルート・ディレクトリを使用する場合、管理対象サーバーから管理サーバーのboot.propertiesファイルを参照できます。管理対象サーバーのsecurityディレクトリに有効なboot.propertiesファイルがある場合は、その起動プロセスでデフォルトでこのファイルが使用されます。boot.propertiesファイルは、ドメイン内のサーバー・インスタンスごとに異なったものにできます。

ノード・マネージャを使用して管理対象サーバーを起動すると、サーバーの起動に使用された資格証明がノード・マネージャによって暗号化され、自動再起動に使用するサーバー固有のboot.propertiesファイルに保存されます。このファイルは、DOMAIN_NAME/servers/SERVER_NAME/data/nodemanagerにあります。DOMAIN_NAMEはドメインを配置したディレクトリの名前であり、SERVER_NAMEはサーバーの名前です。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの構成ファイルとログ・ファイルに関する項を参照してください。

次の項では、起動IDファイルの使い方について説明します。

- 管理サーバーの起動IDファイルの作成

- java weblogic.Serverコマンドを使用した管理サーバーの起動IDファイルの作成

- 管理対象サーバーの起動IDファイルの作成

- サーバー起動時に起動IDファイルが使用される仕組み

- 起動後の起動IDファイルの削除

- ユーザーweblogicに関する制限事項

管理サーバーの起動IDファイルの作成

構成ウィザードを使用して開発モードでドメインを作成すると、暗号化された起動IDファイルが管理サーバーのルート・ディレクトリにあるsecurityディレクトリに作成されます。ドメイン・ディレクトリ・ファイルの詳細は、『Oracle WebLogic Serverドメイン構成の理解』のドメイン・ディレクトリの内容を参照してください。

管理サーバーの起動IDファイルが未作成の場合や、ユーザー名とパスワードのプロンプトを回避する場合は、次の手順で起動IDファイルを作成します。

1. 管理サーバーを少なくとも1回起動し、コマンド・ラインでユーザーの資格証明を指定します。
管理サーバーの初回の起動プロセスでは、サーバーが起動IDファイルを使用できるよう事前に用意されていなければならないセキュリティ・ファイルが生成されます。

2. 以下の2行をテキスト・ファイルに挿入します。

username=username
password=password

ユーザー名とパスワードの値はデフォルト・セキュリティ・レルムの認可プロバイダの既存のユーザー・アカウントと一致し、サーバーを起動および停止する許可を持つロールに属している必要があります。ロールおよび許可の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

3. ファイルを保存します。
ファイルをboot.propertiesとしてサーバーのルート・ディレクトリにあるsecurityディレクトリに保存すると、サーバーはそれ以降の起動サイクルで自動的にこのファイルを使用します。詳細は、「サーバー起動時に起動IDファイルが使用される仕組み」を参照してください。

このファイルを使用して初めてサーバーを起動すると、サーバーはファイルを読み込み、ユーザー名とパスワードの暗号化バージョンでこのファイルを上書きします。

java weblogic.Serverコマンドを使用した管理サーバーの起動IDファイルの作成

注意:

この手法を使用するのは、コマンド・ラインからjava weblogic.Serverコマンドを呼び出す場合のみとしてください。管理サーバーの起動にスクリプトを使用する場合は、次の理由により、この項で説明する手法を使用しないことをお薦めします。

- 起動スクリプト内に暗号化されていないパスワードを格納することが必要となります。

- スクリプトを実行するたびに、サーバーは指定されたユーザーの資格証明で起動し、その後新しい起動IDファイルを作成します。

前の項「管理サーバーの起動IDファイルの作成」の手順を実行する代わりに、コマンド・ラインで直接weblogic.Serverクラスを呼び出し、Javaコマンドに次のオプションを含めることで起動IDファイルを作成できます。

-Dweblogic.management.username=username
-Dweblogic.management.password=password
-Dweblogic.system.StoreBootIdentity=true

これらのオプションにより、サーバー・インスタンスは指定されたユーザーの資格証明で起動し、その後それらはboot.propertiesという名前のファイルに格納されます。

たとえば、次のコマンドはmyAdminServerという名前の管理サーバーを起動して、起動IDファイルを作成します。

java -Dweblogic.management.username=weblogic
-Dweblogic.management.password=password
-Dweblogic.system.StoreBootIdentity=true
-Dweblogic.Name=myAdminServer weblogic.Server

コマンド・ラインから直接weblogic.Serverクラスを呼び出すには、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド・ライン・リファレンスを参照してください。

管理対象サーバーの起動IDファイルの作成

管理対象サーバーが管理サーバーと同じルート・ディレクトリを使用する場合、管理サーバーと同じboot propertiesファイルを使用できます。ノード・マネージャを使用して管理対象サーバーを起動する場合は、起動IDファイルを作成する必要はありません。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの構成ファイルとログ・ファイルに関する項を参照してください。

管理対象サーバー・インスタンスの起動IDファイルを作成するには:

1. ドメインの管理サーバーを起動して、必要なセキュリティ・ファイルが管理サーバーのドメイン・ディレクトリおよびルート・ディレクトリのsecurityディレクトリにあることを確認します。ファイルがない場合は、管理サーバーによって生成されます。
ドメイン・ディレクトリ・ファイルの詳細は、『Oracle Weblogic Serverドメインの構成の理解』のドメイン構成ファイルに関する項を参照してください。

2. 以下の2行をテキスト・ファイルに挿入します。

username=username
password=password

ユーザー名とパスワードの値はデフォルト・セキュリティ・レルムの認可プロバイダの既存のユーザー・アカウントと一致し、サーバーを起動する許可を持つロールに属している必要があります。ロールおよび許可の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

3. ファイルを保存します。
ファイルをboot.propertiesとしてサーバーのルート・ディレクトリにあるsecurityディレクトリに保存すると、サーバーはそれ以降の起動サイクルで自動的にこのファイルを使用します。詳細は、「サーバー起動時に起動IDファイルが使用される仕組み」を参照してください。

4. 起動IDファイルを作成する、ドメイン内の管理対象サーバーごとに、ステップ2と3を繰り返します。
このファイルを使用して初めてサーバーを起動すると、サーバーはファイルを読み込み、ユーザー名とパスワードの暗号化バージョンでこのファイルを上書きします。

サーバー起動時に起動IDファイルが使用される仕組み

サーバー・インスタンスは、その起動プロセスで次のように起動IDファイルを使用します。

- サーバーのsecurityディレクトリに有効なboot.propertiesファイルがある場合、その起動プロセスでこのファイルがデフォルトで使用されます。サーバーのルート・ディレクトリの詳細は、『Oracle WebLogic Serverドメインの構成の理解』のサーバーのルート・ディレクトリを参照してください。

- 別のファイルを指定する場合は(またはサーバーのsecurityディレクトリに起動IDファイルを格納しない場合は)、サーバーのweblogic.Server起動コマンドで次の引数を指定できます。
-Dweblogic.system.BootIdentityFile=filename

filenameは、有効な起動IDファイルの完全修飾パス名。

startWebLogicスクリプトでこの引数を指定するには、-Dweblogic.system.BootIdentityFileをJAVA_OPTIONS変数の値として追加します。例:

set JAVA_OPTIONS=-Dweblogic.system.BootIdentityFile=C:\Oracle\user_domains\mydomain\myidentity.prop

- サーバー・インスタンスの起動サイクルで起動IDファイルを使用しない場合は、サーバーのweblogic.Server起動コマンドで以下のオプションを指定します。
-Dweblogic.management.username=username

-Dweblogic.management.password=password

これらのオプションにより、サーバー・インスタンスは、起動IDファイルをすべて無視し、起動サイクルで起動IDファイルをサーバーで使用するようにする、その他の起動オプションをオーバーライドします。

注意:

サーバー・インスタンスの起動にスクリプトを使用する場合は、起動スクリプト内に暗号化されていないパスワードを格納することが必要となるため、この手法を使用しないことをお薦めします。コマンドラインから直接weblogic.Serverクラスを呼び出す場合のみ、この手法を使用します。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド・ライン・リファレンスに関する項を参照してください。

- 起動サイクルでサーバーの起動IDファイルにアクセスできない場合、サーバーはコマンド・シェルでユーザー名とパスワードのプロンプトを表示し、メッセージをログ・ファイルに書き込みます。

特定のサーバー・インスタンスでは、そのインスタンスが作成した起動IDファイルのみを使用します。WebLogic Serverでは、サーバー・ルート・ディレクトリ間での起動IDファイルのコピーはサポートされていません。

たとえば、ServerAを使用して起動IDファイルを生成した場合、その起動IDファイルはServerAでのみ使用します。ServerAの起動IDファイルをServerBのsecurityディレクトリにコピーしないでください。代わりに、「管理サーバーの起動IDファイルの作成」または「管理対象サーバーの起動IDファイルの作成」で説明したようにServerBの起動IDファイルを作成します。

起動後の起動IDファイルの削除

サーバーの起動後に起動IDファイルを削除する場合は、サーバーのweblogic.Server起動コマンドで次の引数を指定できます。

-Dweblogic.system.RemoveBootIdentity=true

この引数は、サーバーが起動に使用したファイルのみ削除します。たとえば、-Dweblogic.system.BootIdentityFile=c:\secure\boot.MyServerを指定した場合は、サーバーのルート・ディレクトリにboot.propertiesというファイルがあっても、boot.MyServerのみが削除されます。別のコマンド・シェルを開き、各管理対象サーバーのweblogic.Server起動コマンドで-Dweblogic.system.RemoveBootIdentity=true引数を指定して、起動IDファイルを削除します。

startWebLogicスクリプトでこの引数を指定するには、-Dweblogic.system.RemoveBootIdentity=trueをJAVA_OPTIONS変数の値として追加します。例:

set JAVA_OPTIONS=-Dweblogic.system.RemoveBootIdentity=true

ユーザーweblogicに関する制限事項

WebLogic Serverサンプル・コンポーネントをインストールした場合、デフォルトのユーザーweblogicが作成されます。このユーザーにはWebLogic Serverを起動および停止する許可があります。ユーザーweblogicのパスワードを設定する場合、WebLogic Serverではboot.propertiesファイル内にあるこのパスワードが自動的に更新されることはありません。このファイルは、DOMAIN_NAME/servers/AdminServer/securityディレクトリにあります。

ユーザーweblogicのパスワードを更新すると、ユーザー名とその新しいパスワードを使用してWebLogic Serverインスタンスの起動を続行できるように、次のいずれかの方法が使用できます。

- boot.propertiesファイルを削除します。以後、WebLogic Serverを起動するたびに、ユーザー名とパスワードの入力を要求します。受け入れられるのは、ユーザーweblogicの変更後のパスワードです。

- 既存のboot.propertiesファイルを変更します。ユーザー名とパスワードを次のように変更します。

username=weblogic
password=password

以後、サーバーの起動プロセスでは、boot.propertiesファイルが再び暗号化されます。

警告:

本番マシンには、WebLogic Server Examplesをインストールしないでください。本番マシンにサンプル・ソフトウェアやその他の開発ツールを格納しないようにすると、それらを利用する侵入者がWebLogic Serverの本番マシンへの部分的なアクセス権を持つおそれを減らせます。

ノード・マネージャを使用してサーバーを起動するときのユーザー資格証明の指定

ノード・マネージャを使用して管理対象サーバーを起動する場合は、管理コンソールにある「構成」>「サーバーの起動」ページでユーザーの資格証明を指定する必要があります。これらの資格証明を指定しないと、ノード・マネージャはサーバーを起動しようとした時に例外をスローします。

管理コンソールまたは構成ウィザードを使用して管理対象サーバーを作成する場合、WebLogic Serverはサーバーの「構成」→「サーバーの起動」ページにユーザー資格証明を追加します。他のWebLogic Serverユーザー・アカウントでサーバー・インスタンスを実行する場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの起動引数の構成に関する項を参照してください。

他の起動タスク

次の項では、その他の起動タスクについて説明します。

- Javaクラス・ファイルをグローバルに使用可能にする方法

- 管理対象サーバーの管理サーバーへの接続の構成

- WebLogic ServerインスタンスのJavaオプションの指定

- サーバーを実行するJVMの変更

- サーバー・レベル起動と停止クラスの構成

- ドメイン全体のサーバー・パラメータのカスタマイズ

Javaクラス・ファイルをグローバルに使用可能にする方法

JavaクラスをWebLogic Serverでグローバルに使用可能にするには、2つの方法があります。

- $DOMAIN_DIR/lib環境変数を設定します。

- -Dweblogic.ext.dirs起動オプションを指定します。

いずれかまたは両方の方法を指定できます。両方とも指定する場合は、起動オプションで定義されたクラスの方が優先されます。

いずれの場合も、クラスは.jarファイルにパッケージ化されている必要があります。

管理対象サーバーの管理サーバーへの接続の構成

java weblogic.Serverコマンドを呼び出すスクリプトから管理対象サーバーを起動する場合や、java weblogic.Serverコマンドを直接呼び出す場合は、管理サーバーの適切なリスニング・アドレスが指定されていることを確認する必要があります。管理対象サーバーは、このアドレスを使用して管理サーバーから構成情報を取得します。

次の形式でリスニング・アドレスを指定します。

[protocol://]Admin-host:port

1. protocolには、以下のいずれかを指定します。

- t3

- t3s

- http

- https
ドメイン全体の管理ポートを使用する場合は、T3SまたはHTTPSプロトコルを指定する必要があります。値を指定しない場合は、T3が使用されます。

注意:

使用するプロトコルに関係なく、管理対象サーバーの構成の最初のダウンロードはHTTPまたはHTTPSで行われます。RMIサブシステムが初期化されると、サーバー・インスタンスでT3またはT3Sプロトコルを使用できるようになります。

2. Admin-hostには、以下のいずれかを指定します。

- localhost.
管理サーバーと同じコンピュータで管理対象サーバーを起動する場合のみ有効です。

- 管理サーバーをホストしているコンピュータのDNS名
複数のIPアドレスにマップする管理サーバーのDNS名の構成は、異なるIPアドレスで再起動した上の管理サーバーに再接続しようとする管理対象サーバーに対して特に役立ちます。詳細は、『管理対象サーバーと再起動された管理サーバー』を参照してください。

マルチサーバー・ドメインのデモ用証明書を使用する場合は、完全修飾DNS名を指定すると管理対象サーバー・インスタンスの起動が失敗します。この制限事項とその解決策については、『Oracle WebLogic Serverセキュリティの管理』のCertGenを使用する場合の制限事項に関する項を参照してください。

- 管理サーバーをホストしているコンピュータのIPアドレス
次のセキュリティ上の問題があるため、本番環境ではAdmin-hostにIPアドレスを使用しないことをお薦めします。

SSLポートを通じて管理サーバーに接続するために、管理対象サーバーは管理サーバーのホスト名がURLで指定されたホスト名と一致することを検証します。ホスト名の検証が有効になっている場合で、IPアドレスを指定すると、数値の並びであるIPアドレスが文字の並びであるホスト名と一致しないため接続は失敗します。

セキュリティがそれほど重要でない開発環境では、IPアドレスを指定するSSL接続が成功するように管理対象サーバーでホスト名検証を無効にできます。『Oracle WebLogic Serverセキュリティの管理』のホスト名検証の使用に関する項を参照してください。

管理サーバーが他のリスニング・アドレスを使用するように構成されている場合は、その構成されているリスニング・アドレスを指定する必要があります。

3. portには、以下のいずれかを指定します。

- ドメイン全体の管理ポート
構成された管理ポートは、ドメインの各管理対象サーバーで、ドメインの管理サーバーとの通信用に排他的に使用されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン全体の管理ポートの構成に関する項を参照してください。

ドメイン全体の管理ポートが有効になっている場合は、このポートを指定する必要があります。このポートを使用するには、T3SまたはHTTPSプロトコルを指定する必要があります。

- 管理サーバーのデフォルト・ネットワーク構成の非SSLリスニング・ポート(デフォルトは7001)
管理サーバーでこのリスニング・ポートが無効になっている場合は、このリストで説明されている他のリスニング・ポートのいずれかを使用する必要があります。このポートを使用するには、T3またはHTTPプロトコルを指定する必要があります。

- 管理サーバーのデフォルト・ネットワーク構成のSSLリスニング・ポート(デフォルトは7002)。
管理サーバーでこのリスニング・ポートが無効になっている場合は、このリストで説明されている他のリスニング・ポートのいずれかを使用する必要があります。このポートを使用するには、T3SまたはHTTPSプロトコルを指定する必要があります。

- 任意指定のカスタム・ネットワーク・チャネルと関連付けられたポート番号
ポートがSSLでセキュリティ設定されている場合は、T3SまたはHTTPSプロトコルを指定する必要があります。

4. 管理サーバーのホストIPアドレス、ホスト名、およびデフォルト・リスニング・ポートを確認するには、シェル(コマンド・プロンプト)で管理サーバーを起動します。サーバーの起動サイクルが正常に終了すると、次のようなメッセージが他のメッセージと一緒に標準出力に出力されます。

<Nov 5, 2004 12:16:04 PM EST> <Notice> <Server> <BEA-002613> <Channel "DefaultSecure[2]" is now
listening on 127.0.0.1:7012 for protocols iiops, t3s, ldaps, https.>
...
<Nov 5, 2004 12:16:04 PM EST> <Notice> <WebLogicServer> <BEA-000331> <Started WebLogic Admin Server
"MedRecServer" for domain "medrec" running in Development Mode>

SSLの有効化については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSSLの設定に関する項を参照してください。ネットワーク・チャネルの詳細は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。

WebLogic ServerインスタンスのJavaオプションの指定

Javaオプションを使用すると、WebLogic Serverインスタンスを実行するJVMの動作パラメータを構成できます。

Javaオプションでは、サーバーの構成を一時的にオーバーライドすることもできます。Javaオプションは、サーバーの現在のインスタンスのみに適用されます。それらはドメインのconfig.xmlファイルに保存されず、管理コンソールでは表示されません。たとえば、サーバーがポート7201でリスニングするよう構成されている場合に、Javaオプションを使用してポート7555でリスニングするようにサーバーを起動できます。その場合も、管理コンソールではサーバーがポート7201でリスニングするよう構成されていることが示されます。サーバーを次に起動するときにJavaオプションを使用しないと、そのサーバーはポート7201でリスニングします。

WebLogic Serverスクリプトを使用してサーバーを起動する場合、次の手順に従います。ノード・マネージャを使用してサーバーを起動する場合、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのノード・マネージャによって起動されたサーバーのJavaオプションの設定に関する項を参照してください。

1. WebLogic Server起動スクリプトのバックアップ・コピーを作成します。

- 管理サーバーを起動するスクリプトの場合は、DOMAIN_NAME\bin\startWebLogic.cmd (UNIXの場合はstartWebLogic.sh)をバックアップします。

- 管理対象サーバーを起動するスクリプトの場合は、DOMAIN_NAME\bin\startManagedWebLogic.cmd (UNIXの場合はstartManagedWebLogic.sh)をバックアップします。
DOMAIN_NAMEは、ドメインを配置したディレクトリの名前です。デフォルトでは、このディレクトリはORACLE_HOME\user_projects\domains\DOMAIN_NAMEです。

2. テキスト・エディタで起動スクリプトをオープンします。

3. set JAVA_OPTIONSコマンドを編集して、Javaオプションを指定します。複数のオプションを指定する場合は、各オプションをスペースで区切り、オプション全体を引用符で囲みます。例:

4. set JAVA_OPTIONS="-Xgc:gencopy -Xns:30"
詳細は、次を参照してください:

- WebLogic Serverインスタンスの実行時の動作を設定するJavaオプションの詳細は、「weblogic.Serverコマンド・ライン・リファレンス」。

- JAVA_OPTIONSの組合せ方法や重複する値の処理方法の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の起動スクリプトの使用に関する項。

- 他のJVMがサポートするJavaオプションの情報は、そのJVMベンダーが提供するドキュメント。

5. 起動スクリプトを保存します。

6. サーバーを起動します。

サーバーを実行するJVMの変更

ドメインを作成するときに、WebLogic Serverをインストールした際に使用したJDKのリストが構成ウィザードに表示されます。デフォルトのJDKはOracle HotSpotですが、インストールの際に別のJDKがインストールされ、それを使用している場合があります。

ドメインを作成した後で、使用するJVMを変更する場合は、次のようにしてスクリプトを変更できます。

1. JAVA_HOME変数の値を変更します。
使用するJDKの最上位ディレクトリの絶対パス名を指定します。

WindowsまたはLinuxプラットフォームでは、Oracle HotSpotを使用してください。

2. JAVA_VENDOR変数の値を変更します。
JDKのベンダーを指定します。有効な値は、実行しているプラットフォームによって異なります。詳細は、Oracle Technology Networkの「Oracle Fusion Middlewareのサポートされているシステム構成」を参照してください。

例:

- OracleまたはSunは、Oracle HotSpot JDKを使用していることを示します。これは、Oracle HotSpotをサポートするプラットフォームでのみ有効です。

- HPおよびIBMは、Hewlett PackardまたはIBMが提供するJDKを使用していることを示します。これらの値は、HPまたはIBMのJDKをサポートするプラットフォームでのみ有効です。

3. 実行中のサーバーをすべて再起動します。

サーバー・レベル起動と停止クラスの構成

起動/停止(SU/SD)クラスとは、アプリケーションにシステム全体に渡るカスタム・サービスを提供するために作成するJavaプログラムです。このクラスをWebLogic Serverクラスパスに追加し、サーバーの起動または停止時にロードして実行するように構成します。各クラスを1つ以上の専用サーバーにデプロイする必要があります。

デフォルトでは、起動クラスは、他のすべてのサーバーのサブシステムが初期化され、サーバーがモジュールをデプロイした後にロードされて実行されます。『Oracle WebLogic Serverへのアプリケーションのデプロイ』の起動クラスの実行およびデプロイメントの順序付けに関する項を参照してください。停止クラスは、サーバーを正常にシャットダウンするときにロードされて実行されます。

WebLogic Server 9.0は、SU/SDクラスに対する新しくシンプルなPOJOベース・アプローチを導入しました。このアプローチでは、SU/SDクラスにはstatic main(String args[])メソッドがあることだけが求められます。このメソッドは、クラスのインスタンスを作成した後にサーバーが呼び出します。SU/SDクラスに構成する引数は、String args []パラメータによって渡されます。

POJOベースのSU/SDクラスは、以前のバージョンと同じデプロイメントおよび構成手順を実行します。クラスをサーバーのクラスパスで使用可能にする必要があります。SU/SDクラスは管理コンソールを使用して構成され、最終的にはconfig.xmlにエントリとして保存されます。

詳細は、例2-1、例2-2、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・クラスを使用したサーバーの構成に関する項を参照してください。

例2-1 起動クラス

package sab.demo.utils;
public class StartupMain {
/**
* @param args
*/
public static void main(String[] args) {

log(StartupMain.class.getName() + "::main");
log("Arguments::");
for(int i=0;args!=null && i<args.length;i++) {
log("  arg[" + i + "]: " + args[i]);
}
}

private static void log(String msg) {
System.out.printf("  --> [SAB]: %s\n", msg);
}
}

例2-2 config.xml

<startup-class>
<name>StartupMain</name>
<target>AdminServer</target>
<deployment-order>1000</deployment-order>
<class-name>sab.demo.utils.StartupMain</class-name>
<arguments>arg1 arg2 arg3</arguments>
<failure-is-fatal>false</failure-is-fatal>
<load-before-app-deployments>false</load-before-app-deployments>
<load-before-app-activation>true</load-before-app-activation>
</startup-class>

ドメイン全体のサーバー・パラメータのカスタマイズ

すべてのドメインには、動的に生成されたドメインおよびsetDomainEnvなどのサーバー起動スクリプトがあります。起動スクリプトに行った変更は、その後のドメインのアップグレード操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

ドメインのすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするには、setUserOverrides.cmd(Windows)またはsetUserOverrides.sh(UNIX)というファイルを作成します。このファイルを構成すると、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド・ライン・オプションの指定または追加の環境変数の指定などを行うことができます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

サーバーの起動中にこのファイルが存在する場合は、起動順序に含められ、定義されたオーバーライドが有効になります。domain_home/binディレクトリにこのファイルを格納する必要があります。

次の例では、カスタム・ライブラリの追加方法および追加のjavaコマンド・ライン・オプションの指定方法を示します。

例2-3 setUserOverridesファイルでの起動のカスタマイズ例

# add custom libraries to the WebLogic Server system claspath
if [ "${POST_CLASSPATH}" != "" ] ; then
POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
else
POST_CLASSPATH="${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
fi

# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

WebLogic Serverのインスタンスの停止

管理コンソールを使用してWebLogic Serverインスタンスを停止することをお薦めします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・インスタンスの停止に関する項、正常な停止の制御に関する項およびクラスタ内のサーバーの停止に関する項を参照してください。

停止スクリプトによるサーバーの停止

WebLogic Serverが提供する構成ウィザードのテンプレートを使用すると、ドメイン・ディレクトリのbinディレクトリに、管理サーバーを停止するためのstopWebLogicという名前の停止スクリプトと、管理対象サーバーを停止するためのstopManagedWebLogicという名前の停止スクリプトが作成されます。これらのスクリプトを使用するには、SERVER_NAME、ADMIN_URL、USERID、およびPASSWORDを環境変数として設定するか、またはそれらをコマンド・ラインで指定する必要があります。stopWebLogicスクリプトの使用時にSERVER_NAMEが指定されていない場合、デフォルトでは管理サーバー名が使用されます。

- 管理サーバーの場合のスクリプトの呼出しは次のとおりです。
DOMAIN_NAME\bin\stopWeblogic.cmd username password admin_url (Windows)

DOMAIN_NAME/bin/stopWeblogic.sh username password admin_url (UNIX)

- 管理対象サーバーの場合のスクリプトの呼出しは次のとおりです。
DOMAIN_NAME\bin\stopManagedWeblogic.cmd managed_server_name admin_url username password (Windows)

DOMAIN_NAME/bin/stopManagedWeblogic.sh managed_server_name admin_url username password (UNIX)

注意:

コマンド・ラインでは、上記の順序でパラメータを指定します。ユーザー資格証明は、stopWebLogic.cmdではADMIN_URLの前に、stopManagedWebLogic.cmdではADMIN_URLの後に指定します。

JVMの強制停止

各WebLogic Serverインスタンスは、それ専用のJVMで動作します。上記の項で説明した方法でサーバー・インスタンスを停止できない場合は、オペレーティング・システム・コマンドを使用してJVMを強制停止できます。

警告:

JVMを強制停止すると、サーバーはただちにすべての処理を終了します。セッション・データはすべて失われます。サーバーがconfig.xmlファイルへの書込みを行っている間に管理サーバーのJVMを強制停止すると、config.xmlファイルが破損するおそれがあります。

JVMを強制停止する一般的な方法のいくつかを次に示します:

- サーバーを起動したシェル(コマンド・プロンプト)がまだ開いている場合は、[Ctrl]+[C]を押します。

- Windowsコンピュータでは、タスク・マネージャを使用してJVMを強制停止できます。

- UNIXコンピュータでは、psコマンドを使用してすべての実行中のプロセスをリストで表示できます。続いて、killコマンドを使用してJVMを強制停止できます。

3 WindowsサービスとしてのWebLogic Serverインスタンスの設定

この章では、Windowsホスト・コンピュータの起動時に自動的に起動されるように、WebLogic ServerインスタンスをWindowsサービスとして設定する方法について説明します。

Windowsでは、Microsoft 管理コンソール(MMC)、特に「サービス」で、Windowsサービスを開始、停止、および構成します。

WebLogic Serverでは、Windowsサービスとして設定したサーバー・インスタンスごとに、Windowsレジストリ内(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services)にキーが作成されます。このレジストリ・エントリには、サーバー名をはじめとする起動引数の情報が含まれています。

Windowsホストを起動するとき、Microsoft管理コンソールはWindowsレジストリ・キーの情報を使用してweblogic.Serverメイン・クラスを呼び出します。MMCは、ノード・マネージャを使用して管理対象サーバーを起動するように構成できないので、Windowsサービスとして実行しているサーバーでは、ノード・マネージャのモニター機能と自動再起動機能は使用できません。

ここでは、Windowsサービスとして実行するWebLogic Serverインスタンスを設定および管理する手順について説明します。

- Windowsサービスの設定:主な手順

- 設定の検証

- 「サービス」ウィンドウの使用によるサーバー・インスタンスの停止または再起動

- Windowsサービスとして設定されているサーバーの削除

- Windowsサービスとして設定されているサーバーの起動資格証明の変更

Windowsサービスの設定:主な手順

Windowsサービスを設定するには:

1. サーバー固有の変数を設定するスクリプトを作成し、WebLogic Serverマスター・スクリプトを呼び出します。詳細は、「サーバー固有のスクリプトの作成」を参照してください。

2. 管理対象サーバーをWindowsサービスとしてインストールする場合は、ドメインの管理サーバーの場所を示す変数を、サーバー固有のスクリプトに追加します。詳細は、管理サーバーへの接続の構成を参照してください。

3. 同じコンピュータでWindowsサービスとして実行する管理サーバーと管理対象サーバーの両方を設定したら、WebLogic Serverマスター・スクリプトを変更して、管理サーバーの起動サイクルが完了した後にのみ管理対象サーバーが起動されるようにします。詳細は、「管理サーバーと管理対象サーバーの起動順序の強制」を参照してください。

4. Windowsサービスを停止したときに、サーバー・インスタンスを正常に停止させたい場合は、Javaクラスを作成し、Microsoft管理コンソールによってそのクラスが呼び出されるようにマスター・スクリプトを変更します。詳細は、「正常停止の有効化」を参照してください。

5. サーバー・インスタンスから標準出力および標準エラーに出力されるメッセージ(スタック・トレースやスレッド・ダンプを含む)を表示したい場合は、標準出力および標準エラーをファイルにリダイレクトします。詳細は、「標準出力および標準エラーのファイルへのリダイレクト」を参照してください。

6. WebLogic Serverインスタンスから呼び出す追加のJavaクラスを作成した場合は、それらをサーバーのクラスパスに追加します。詳細は、「クラスパスへのクラスの追加」を参照してください。

7. サーバー固有のスクリプトを実行します。詳細は、「サーバー固有のスクリプトの実行」を参照してください。

サーバー固有のスクリプトの作成

ここで作成するスクリプトでは、サーバー固有の情報(サーバー・インスタンス名など)を特定するための変数に値を設定する必要があります。また、このスクリプトからマスター・スクリプトWL_HOME\server\bin\installSvc.cmd (WL_HOMEはWebLogic Serverのインストール・ディレクトリ)を呼び出す必要もあります。マスター・スクリプトからは、Windowsレジストリにキーを追加するwlsvcユーティリティが呼び出されます。

注意:

wlsvcの詳細は、コマンド・プロンプトにWL_HOME\server\bin\wlsvc -helpと入力します。WL_HOMEは、WebLogic Serverのインストール・ディレクトリです。

サーバー固有のスクリプトのサンプルについては、例3-1を参照してください。

サーバー固有のスクリプトを作成するには:

1. ドメインの管理サーバーのルート・ディレクトリにテキスト・ファイルを作成します。

2. このテキスト・ファイルに、以下に示す必須のbatchコマンドを追加します。各コマンドは別々の行に記述してください。

- SETLOCAL
これは、バッチ・ファイル内の環境変数のローカライゼーションを開始するbatchコマンドです。

- set DOMAIN_NAME=domain-name
domain-nameは、WebLogic Serverドメインの名前です。

- set USERDOMAIN_HOME=absolute-pathname
absolute-pathnameは、管理サーバーのルート・ディレクトリ(ドメインの構成ファイルが格納されているディレクトリ)のフルパス名です。『Oracle WebLogic Serverドメイン構成の理解』のサーバーのルート・ディレクトリの指定を参照してください。

- set SERVER_NAME=server-name
server-nameは、Windowsサービスとして設定する既存のサーバー・インスタンスの名前です。

3. このテキスト・ファイルに、以下に示す省略可能なbatchコマンドを追加します。各コマンドは別々の行に記述してください。

- set WLS_USER=username

- set WLS_PW=password
usernameは、サーバー・インスタンスを起動する権限を持つ既存のユーザーの名前、passwordはそのユーザーのパスワードです。wlsvcユーティリティでは、ログイン資格証明が暗号化され、Windowsレジストリに格納されます。

この方法は、サーバー・インスタンスが起動した時、ユーザー名とパスワードのプロンプトを回避するための2つのうちの1つの実行可能な方法です。この方法を使用するメリットは、サーバー・インスタンスのユーザー名またはパスワードを変更する場合は、Windowsサービスを削除し、新しいユーザー名とパスワードで新規のサービスを設定することが必要になるところにあります。かわりに、起動IDファイルも使用できます。起動IDファイルを使用して、Windowsサービスを変更することなく、ログイン資格証明を変更できます。詳細は、「起動IDファイル」を参照してください。

- set PRODUCTION_MODE=[true]
PRODUCTION_MODE変数をtrueに設定すると、サーバー・インスタンスは本番モードで起動します。この変数が指定されていない場合、またはfalseに設定されている場合は、サーバーは開発モードで起動します。開発モードと本番モードの詳細は、『構成ウィザードによるドメインの作成』のサーバー起動モードの構成に関する項を参照してください。

- set JAVA_OPTIONS=java-options
java-optionsは、Java仮想マシン(JVM)に渡す1つまたは複数のJava引数です。複数の引数を指定する場合はスペースで区切ります。WebLogic Server固有のJavaオプションのリストについては、『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド・ライン・リファレンスに関する項を参照してください。ご使用のJVMでサポートされた追加オプションがJVMベンダーによりドキュメント化されています。

- set JAVA_VM=-JVM-mode
JVM-modeは、JVMの実行モードを示すテキスト文字列です。指定する値は、使用しているJVMごとに異なります。

- set MEM_ARGS=[-XmsNumberm] [-XmxNumberm]
Numbermは、MB単位の数値です。-XmsNumberm引数はJVMの最小ヒープ・サイズを、-XmxNumberm引数はJVMの最大ヒープ・サイズを設定します。デフォルトの最小ヒープ・サイズは23MB、最大ヒープ・サイズは200MBです。

注意:

デフォルト以外のJVMヒープ・サイズを指定するには、WL_HOME\common\bin\commEnv.cmdでMEM_ARGS値を設定します。ただし、この変更は同じWL_HOME以下のすべてのドメインに影響します。

- set MAX_CONNECT_RETRIES=number_of_attempts

- set HOST=ip_address

- set PORT=port_number
number_of_attemptsは、WebLogic Serverインスタンスが起動しているかどうかを判断するために、Windowsサービスでステータスのチェックを実行する回数です。この変数とともにHOSTおよびPORTを指定すると、WebLogic Serverインスタンスが起動するまでWindowsサービスが待機します。ip_addressはWebLogic ServerインスタンスのIPアドレスで、port_numberはWeblogic Serverインスタンスがリクエストをリスニングするポートです。

4. スクリプトの末尾に、以下に示す必須のコマンドを追加します。

- call "WL_HOME\server\bin\installSvc.cmd"
WL_HOMEは、WebLogic Serverのインストール・ディレクトリのフルパス名です。このコマンドにより、WebLogic Serverのマスター・スクリプトが呼び出されます。

- ENDLOCAL
これは、バッチ・ファイル内の環境変数のローカライゼーションを終了するbatchコマンドです。

5. このテキスト・ファイルを、拡張子.cmdで保存します。デフォルトでは、Windowsコマンド・プロンプトによって拡張子.cmdにbatchファイルが関連付けられます。

管理サーバーへの接続の構成

管理対象サーバーをWindowsサービスとしてインストールする場合は、ドメインの管理サーバーの場所を示す変数を含める必要があります。管理対象サーバーの構成データは、管理対象サーバーから管理サーバーにアクセスして取得する必要があります。

また、先に管理サーバー(サービスではなく実際のサーバー)を起動し、その後で管理対象サーバーをWindowsサービスとして開始する必要があります。

管理サーバーへの接続を構成するには:

1. テキスト・エディタで、そのサーバー固有のスクリプトをオープンします。

2. このテキスト・ファイルで、SETLOCALコマンドとcallコマンドの間に次のコマンドを挿入します。

set ADMIN_URL=protocol://listen-address:listen-port

説明:

- protocolはhttpまたはhttps

- listen-addressは、管理サーバーのリスニング・アドレスです。

- listen-portは、管理サーバーのポート
詳細は、管理対象サーバーの管理サーバーへの接続の構成を参照してください。

例として、例3-1の太字部分を参照してください。

3. サーバー固有のスクリプトへの変更内容を保存します。

例3-1 管理対象サーバーをWindowsサービスとして設定するスクリプトのサンプル

echo off
SETLOCAL
set DOMAIN_NAME=myWLSdomain
set USERDOMAIN_HOME=d:\Oracle\Middleware\user_projects\domains\myWLSdomain
set SERVER_NAME=myWLSserver
set PRODUCTION_MODE=true
set
JAVA_OPTIONS=-Dweblogic.Stdout="d:\Oracle\Middleware\user_projects\domains\myWLSdomain\
stdout.txt" -Dweblogic.Stderr="d:\Oracle\Middleware\user_projects\domains\myWLSdomain\
stderr.txt"
set ADMIN_URL=http://adminserver:7501
set MEM_ARGS=-Xms40m -Xmx250m
call "d:\Oracle\Middleware\wlserver_12.1\server\bin\installSvc.cmd"
ENDLOCAL

注意:

このスクリプトのサンプルを使用して管理サーバーをWindowsサービスとして設定するには、ADMIN_URL変数を削除します。

例をコピー・アンド・ペーストするとき、末尾のスペースがないことを確認してください。

管理サーバーと管理対象サーバーの起動順序の強制

同じコンピュータでWindowsサービスとして実行する管理サーバーと管理対象サーバーの両方を設定したら、管理サーバーの後にのみ起動する管理対象サーバーを指定できます。

管理対象サーバーが、必ず管理サーバーWindowsサービスの後に起動されるようにするには:

1. WL_HOME\server\bin\installSvc.cmdマスター・スクリプトのバックアップ・コピーを作成します。

2. 管理サーバーがすでにWindowsサービスとしてインストールされている場合は、そのサービスを削除します。詳細は、「Windowsサービスとして設定されているサーバーの削除」を参照してください。

3. 管理サーバーをWindowsサービスとしてインストール(または再インストール)する前に、以下を行います。

1. テキスト・エディタで、WL_HOME\server\bin\installSvc.cmdマスター・スクリプトをオープンします。
スクリプト内の最後のコマンドは、wlsvc (Windowsレジストリを変更するWebLogic Serverユーティリティ)を呼び出すコマンドです。

2. installSvc.cmd内で、wlsvcユーティリティを呼び出すコマンドに次の引数を追加します。

-delay:delay_milliseconds

Microsoft管理コンソールが、サービス・ステータスをSERVER_START_PENDINGからSTARTEDへ変更するまで待機するミリ秒数を指定します。

たとえば、管理サーバーがその起動サイクルを完了してリクエストをリスニングできる状態になるまでに2分かかる場合は、-delay=120000と指定します。この場合、Windowsホスト・コンピュータを起動すると、Microsoft管理コンソールによってSERVER_START_PENDINGステータスが2分間報告されます。その後、ステータスがSTARTEDに変更されます。

この管理サーバーの変更後のwlsvc呼出しは次のようになります。

"%WL_HOME%\server\bin\wlsvc" -install
-svcname:"%DOMAIN_NAME%_%SERVER_NAME%"
-delay:120000
-javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%"
-extrapath:"%WL_HOME%\server\bin" -password:"%WLS_PW%"
-cmdline:%CMDLINE%

wlsvcの詳細は、コマンド・プロンプトにWL_HOME\server\bin\wlsvc -helpと入力します。WL_HOMEは、WebLogic Serverのインストール・ディレクトリです。

4. 管理サーバーWindowsサービスをインストールします。

5. 管理対象サーバーをWindowsサービスとしてインストールする前に、次の手順に従います。

1. テキスト・エディタで、WL_HOME\server\bin\installSvc.cmdマスター・スクリプトをオープンします。

2. installSvc.cmd内で、wlsvcユーティリティを呼び出すコマンドに次の引数を追加します。

-depend:Administration-Server-service-name

Administration-Server-service-nameは、管理サーバーWindowsサービスの名前です。サービス名を確認するには、「サービス」>「Microsoft管理コンソール」を参照します。

このオプションを指定した場合、Microsoft管理コンソールは、管理サーバーWindowsサービスによるSTARTEDステータスの報告を待機してから、管理対象サーバーWindowsサービスを開始します。

この管理対象サーバーの変更後のwlsvc呼出しは次のようになります。

"%WL_HOME%\server\bin\wlsvc" -install
-svcname:"%DOMAIN_NAME%_%SERVER_NAME%"
-depend:"wlsvc myDomain_myAdminServer"
-javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%"
-extrapath:"%WL_HOME%\server\bin" -password:"%WLS_PW%"
-cmdline:%CMDLINE%

また、Microsoft管理コンソールがサービスのSTARTEDステータスをいつ報告するかを構成したい場合は、管理対象サーバーWindowsサービスに-delay:delay_millisecondsオプションを追加できます。

正常停止の有効化

デフォルトでは、Microsoft管理コンソールを使用してサーバー・インスタンスを停止すると、サーバーのJava仮想マシン(JVM)を強制停止します。JVMを強制停止すると、サーバーはただちにすべての処理を終了します。セッション・データはすべて失われます。サーバーがconfig.xmlファイルへの書込みを行っている間に管理サーバーのJVMを強制停止すると、config.xmlファイルが破損するおそれがあります。

Microsoft管理コンソールから正常停止を可能にするには、次の手順を実行します:

1. weblogic.management.runtime.ServerRuntime.shutdown()メソッドを呼び出すJavaクラスを作成します。
このメソッドは、処理中のすべての作業を完了してからサーバーを正常に停止します。このようなクラスの例については、「サーバー・インスタンスを停止するJavaクラス」を参照してください。

2. WL_HOME\server\bin\installSvc.cmdマスター・スクリプトのバックアップ・コピーを作成します。

3. テキスト・エディタで、WL_HOME\server\bin\installSvc.cmdマスター・スクリプトを開いて以下を行います。

1. 前の手順で作成したクラスを、set CLASSPATH文に追加します。
たとえば、クラスをc:\myJarというファイルにアーカイブした場合、変更後の文は次のようになります。

set
CLASSPATH=%JAVA_HOME%\lib\tools.jar;%WL_HOME%\server\lib\weblogic_sp
.jar;%WL_HOME%\server\lib\weblogic.jar;c:\myJar;%CLASSPATH%

2. スクリプトの最後の行に次の引数を追加します。この行はwlsvcユーティリティを呼び出します。

-stopclass:javaclass

javaclassは、作成したクラスの完全なクラスパス名です。この引数を指定することにより、javaclassがロードされてから、そのpublic void static stop()メソッドが呼び出されます。

たとえば、例3-2のクラスをcom.myClassesにパッケージ化した場合、変更後のwlsvcコマンドは次のようになります。

"%WL_HOME%\server\bin\wlsvc" -install
-svcname:"%DOMAIN_NAME%_%SERVER_NAME%"
–stopclass:com.myClasses.ServerStopper
-javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%"
-extrapath:"%WL_HOME%\server\bin" -password:"%WLS_PW%"
-cmdline:%CMDLINE%

wlsvcの詳細は、コマンド・プロンプトにWL_HOME\server\bin\wlsvc -helpと入力します。WL_HOMEは、WebLogic Serverのインストール・ディレクトリです。

4. WebLogicサーバーの管理コンソールで、サーバーの「制御」ページで管理対象サーバーの正常停止動作を構成します。
正常な停止操作において、すべてのHTTPセッションをただちに中止するかどうかを設定したり、停止を強制するまでの待機時間を構成したりできます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの正常な停止の制御に関する項を参照してください。

5. Windowsサービスによって指定されているデフォルトのタイムアウト値を変更すべきかどうかを検討してください。
デフォルトでは、Microsoft管理コンソールを使用してWindowsサービスを停止する場合、サービスが停止するまで30秒待機してからサービスを強制停止し、システム・イベント・ログにタイムアウト・メッセージを印刷します。

-stopclassを使用してサーバーを正常停止する場合、30秒というタイムアウト値は、サーバーがすべての処理を正常に終了するには短すぎる可能性があります。

タイムアウト期間を構成するには、ServicesPipeTimeoutというREG_DWORDレジストリ値を、次のレジストリ・キーの下に作成します。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control

キー値はミリ秒で指定する必要があります。

この値は、Windowsオペレーティング・システムの起動時にレジストリから読み取られ、インストールされているすべてのサービスに影響します。

6. 変更後のWebLogic Serverマスター・スクリプトを保存します。

サーバー・インスタンスを停止するJavaクラス

以下のJavaクラスでは、JMX (Java Management Extensions)を使用してサーバー・インスタンスを停止します。各サーバーの管理属性と操作は、JMX管理対象Bean (MBean)を使用して公開されます。このようなMBeanの1つであるServerRuntimeは、サーバーを正常に停止するためのshutdown()メソッドを公開します。

例3-2に示すクラスでは、管理MBeanHomeインタフェースを使用しています。このインタフェースを使用すると、ドメイン内のすべてのサーバー・インスタンスのServerRuntime MBean操作を取得したり呼び出したりできます。

JMXプログラミングの詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。ServerRuntime MBeanの詳細は、WebLogic Server Javadocを参照してください。

例3-2 サーバー・インスタンスを停止するJavaクラス

import java.util.Set;
import java.util.Iterator;
import java.rmi.RemoteException;
import javax.naming.Context;
import javax.management.ObjectName;

import weblogic.jndi.Environment;
import weblogic.management.MBeanHome;
import weblogic.management.WebLogicMBean;
import weblogic.management.configuration.ServerMBean;
import weblogic.management.runtime.ServerRuntimeMBean;
import weblogic.management.runtime.ServerStates;
import weblogic.management.WebLogicObjectName;

public class ServerStopper {
public static void stop() throws Exception {
MBeanHome home = null;

//url of the Admin server
String url = "t3://qa113:7001";
String username = "system";
String password = "gumby1234";
ServerRuntimeMBean serverRuntime = null;
Set mbeanSet = null;
Iterator mbeanIterator = null;

try {
// Set ContextClassloader to prevent assertions
URL[] urls = { new File("/").toURL() };
Thread.currentThread().setContextClassLoader(new
URLClassLoader(urls));

Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(username);
env.setSecurityCredentials(password);
Context ctx = env.getInitialContext();
home = (MBeanHome)
ctx.lookup("weblogic.management.adminhome");
mbeanSet = home.getMBeansByType("ServerRuntime");
mbeanIterator = mbeanSet.iterator();

while(mbeanIterator.hasNext()) {
serverRuntime = (ServerRuntimeMBean)mbeanIterator.next();
if(serverRuntime.getState().equals(ServerStates.RUNNING)){
serverRuntime.shutdown();
}
}
} catch (Exception e) {
e.printStackTrace();
}
}
}

注意:

2つ以上のサーバー・インスタンスが稼働中の場合は、サンプルJavaクラスはすべてのサーバー・インスタンスを停止します。

標準出力および標準エラーのファイルへのリダイレクト

WebLogic ServerインスタンスをWindowsサービスとしてインストールする場合のデフォルトでは、サーバーやそのJVMから標準出力と標準エラーに出力されたメッセージは表示されません。

これらのメッセージを表示するには、標準出力および標準エラーからファイルにリダイレクトする必要があります。

1. WL_HOME\server\bin\installSvc.cmdマスター・スクリプトのバックアップ・コピーを作成します。

2. テキスト・エディタで、WL_HOME\server\bin\installSvc.cmdマスター・スクリプトをオープンします。

3. installSvc.cmdスクリプトの最後のコマンドで、wlsvcユーティリティが呼び出されるようにします。wlsvcコマンドの末尾に、次のコマンド・オプションを追加します。

-log:"pathname"

pathnameは、サーバーの標準出力と標準エラーへのメッセージを格納するファイルの完全修飾パスおよびファイル名です。

変更後のwlsvcコマンドは次のようになります。

"%WL_HOME%\server\bin\wlsvc" -install
-svcname:"%DOMAIN_NAME%_%SERVER_NAME%"
-javahome:"%JAVA_HOME%" -execdir:"%USERDOMAIN_HOME%"
-extrapath:"%WL_HOME%\server\bin" -password:"%WLS_PW%"
-cmdline:%CMDLINE%
-log:"d:\Oracle\Middleware\user_projects\domains\myWLSdomain\myWLSserver-stdout.txt"

4. デフォルトでは、Windowsサービスが24時間間隔でpathname-yyyy_mm_dd-hh_mm_ssという名前のファイルにメッセージをアーカイブします。新しいメッセージは、前の手順で指定したファイルに収集されます。
デフォルト動作の変更の詳細は、「デフォルトのローテーション条件の変更」を参照してください。

サービスをインストールしてWindowsホストを再起動したら、以下のいずれかの方法で、標準出力または標準エラーに書き込まれたメッセージを表示できます。

- 指定したファイルのコピーを作成し、そのコピーを表示します。コピーを作成するのは、Windowsファイル・システムでは開かれているファイルに対して書込みを行うことができないためです。

- メッセージがファイルに書き込まれるのと同時に表示します。その場合は、コマンド・プロンプトを開き、tailコマンドをサポートするDOSユーティリティを使用してtail -f stdout-filenameと入力します。

デフォルトのローテーション条件の変更

デフォルトでは、Windowsサービスが24時間間隔でpathname-yyyy_mm_dd-hh_mm_ssという名前のファイルにメッセージをアーカイブします。新しいメッセージは、サービスの設定時に指定したファイルに収集されます。

このアーカイブの時間間隔を変更したり、ローテーションの発生を時間間隔ではなくメッセージ・ファイルのサイズに基づいて設定したりできます。

Windowsサービスがメッセージ・ファイルをローテーションする際のデフォルト条件を変更するには:

1. Windowsサービスが実行されている場合はそれを停止します。

2. -log: pathname引数で指定したファイルを編集します。ファイルが存在しない場合は作成します。

たとえば、前の項のステップ3に示したサンプル・コマンドを発行した場合は、d:\Oracle\Middleware\wlserver_12.1\config\mydomain\myserver-stdout.txtというファイルを作成します。

3. 以下のいずれか1つを実行します。

- Windowsサービスで、ファイル・サイズには関係なく、特定の時間間隔でメッセージ・ファイルをローテーションする場合は、ファイルの先頭に以下の文を追加します。各文は別々の行に記述します(最後の行を記述した後、必ず「Enter」または「Return」を押してください)。

# ROTATION_TYPE = TIME
# TIME_START_DATE = date-in-required-format
# TIME_INTERVAL_MINS = number-of-minutes

TIME_START_DATEは、初回のローテーションを行う日時を示します。指定した日時をすでに過ぎている場合は、TIME_INTERVAL_MINSに指定した時間が経過すると同時に初回のローテーションが発生します。開始時間の指定には、Month Day Year Hour:Minutes:Secondsというフォーマットを使用する必要があります。

Monthには、グレゴリオ暦の月を示す英語の最初の3文字を指定します。

Dayには、グレゴリオ月の日を2桁で指定します。

Yearには、グレゴリオ暦の年を4桁で指定します。

Hour:Minutes:Secondsには、24時間表記で時間を指定します。

TIME_INTERVAL_MINSは、ファイルをローテーションする頻度を示します。

例:

# ROTATION_TYPE = TIME
# TIME_START_DATE = Jul 17 2003 05:25:30
# TIME_INTERVAL_MINS = 1440

指定した時間間隔が経過すると、ファイルがpathname-yyyy_mm_dd-hh_mm_ssという名前で保存されます。次に、pathnameという名前の新しいファイルが作成されます。この新しいファイルには、当初指定したすべてのヘッダーが含まれており、標準出力および標準エラーへの新しいメッセージはこのファイルに収集されます。

# ROTATION_TYPE = TIMEを指定しても、それ以外の行を記述していない場合は、メッセージ・ファイルが24時間間隔でローテーションされます。

- メッセージ・ファイルのサイズが指定値を超えたときにローテーションする場合は、ファイルの先頭に以下の文を追加します。各文は別々の行に記述します(最後の行を記述した後、必ず「Enter」または「Return」を押してください)。

# ROTATION_TYPE = SIZE
# SIZE_KB = file-size-in-kilobytes
# SIZE_TRIGGER_INTERVAL_MINS = polling-interval

SIZE_KBは、メッセージ・ファイルをローテーションをトリガーする最小ファイル・サイズ(KB)を示します。

SIZE_TRIGGER_INTERVAL_MINSは、ファイル・サイズをチェックする時間間隔(分)を示します。このヘッダーを含めない場合は、5分間隔でファイル・サイズがチェックされます。

例:

# ROTATION_TYPE = SIZE
# SIZE_KB = 1024
# SIZE_TRIGGER_INTERVAL_MINS = 3

チェックしたファイルのサイズが指定サイズを超えていると、そのファイルがpathname-yyyy_mm_dd-hh_mm_ssという名前で保存されます。次に、pathnameという名前の新しいファイルが作成されます。この新しいファイルには、当初指定したすべてのヘッダーが含まれており、標準出力および標準エラーへの新しいメッセージはこのファイルに収集されます。

# ROTATION_TYPE = SIZEを指定しても、それ以外の行を記述していない場合は、Windowsサービスは5分間隔でメッセージ・ファイルのサイズをチェックします。ファイル・サイズが1 MBを超えると、そのファイルはローテーションされます。

WebLogic Serverインスタンスからのスレッド・ダンプは、以下のいずれかの方法で標準出力に出力できます。

- WLST threadDumpコマンドを使用します。

- コマンド・プロンプトを開き、次のコマンドを入力します。
WL_HOME\bin\wlsvc -dump -svcname:service-name

WL_HOMEはWebLogic Serverのインストール・ディレクトリ、service-nameはサーバー・インスタンスを実行しているWindowsサービスです。

例:

D:\Oracle\Middleware\wlserver_12.1\server\bin\wlsvc -dump -svcname:mydomain_myserver

クラスパスへのクラスの追加

クラスパスとは、JVMから呼び出すことのできるJavaクラスの場所を宣言するものです。WebLogic Serverマスター・スクリプトを使用してサーバー・インスタンスをWindowsサービスとしてインストールする場合、マスター・スクリプトにはサーバー・インスタンスを実行するのに必要なすべてのクラスを指定します。独自のJavaクラスを追加してWebLogic Serverを拡張したい場合は、それらをクラスパスに追加する必要があります。

クラスをクラスパスに追加するには:

1. WL_HOME\server\bin\installSvc.cmdマスター・スクリプトのバックアップ・コピーを作成します。

2. テキスト・エディタで、WL_HOME\server\bin\installSvc.cmdマスター・スクリプトをオープンします。

3. クラスをset CLASSPATH文に追加します。
たとえば、クラスをc:\myJarというファイルにアーカイブした場合、変更後の文は次のようになります。

set
CLASSPATH=%JAVA_HOME%\lib\tools.jar;%WL_HOME%\server\lib\weblogic_sp.
jar;%WL_HOME%\server\lib\weblogic.jar;c:\myJar;%CLASSPATH%

注意:

Win32システムでは、コマンド・ラインの長さが2047文字に制限されています。Windowsサービスを起動するためのクラスパス設定が非常に長くなると、2047文字の制限を超える可能性があります。

この制限を回避するには、次のようにします。

1. set CLASSPATHコマンドの値を、別のテキスト・ファイルに記述します。

2. WL_HOME\server\bin\installSvc.cmdマスター・スクリプトを開き、set CMDLINEコマンドを探します。

3. set CMDLINEコマンド内で、-classpath \"%CLASSPATH%\"オプションを次のオプションで置き換えます。

-classpath @pathname\filename

pathname\filenameは、クラスパスの値が格納されているファイルのフルパスおよび名前です。

例:

set CMDLINE="%JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
-classpath @c:\myClasspath.txt -Dweblogic.Name=%SERVER_NAME%
-Dbea.home=\"D:\bea_70sp2\" -Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.server=\"%ADMIN_URL%\"
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy=\"%WL_HOME%\server\lib\weblogic.policy\"
weblogic.Server"

4. 変更後のWebLogic Serverマスター・スクリプトを保存します。

サーバー固有のスクリプトの実行

注意:

サーバー固有のスクリプトを実行するには、Windowsレジストリを変更する権限のあるユーザー・アカウントでWindowsコンピュータにログインする必要があります。

本番環境にWindowsサービスをインストールする場合は、管理者レベルの権限を持つオペレーティング・システム・ユーザー・アカウントでサービスを実行するのは避けるようにしてください。詳細は、「サービスの実行に使用するユーザー・アカウントの検証」を参照してください。

サーバー固有のスクリプトを実行するには:

1. コマンド・プロンプトを開き、管理サーバーのルート・ディレクトリ(サーバー固有のスクリプトが格納されているディレクトリ)に移動します。

2. サーバー固有のスクリプトの名前を入力します。
指定したスクリプトがbatchファイルとして実行されます。

スクリプトの実行が正常に完了すると、DOMAIN_NAME_SERVER_NAMEという名前のWindowsサービスが作成され、次のような行が標準出力に出力されます。

mydomain_myserver installed.

デフォルトの標準出力は、サーバー固有のbatchファイルを実行しているコマンド・プロンプトです。

3. WL_HOME\server\bin\installSvc.cmdマスター・スクリプトを変更した場合は、その変更を元に戻すことも検討してください。それにより、他のサーバー・インスタンスにも同じスクリプトを使用できるようになります。

設定の検証

WebLogic ServerをWindowsサービスとして正常に設定できたかどうかを検証するには、次の手順に従います。

1. コマンド・ウィンドウを開き、次のコマンドを入力します。

set PATH=WL_HOME\server\bin;%PATH%

2. 検証するドメイン・ディレクトリのすぐ上のディレクトリに移動します。たとえば、ORACLE_HOME\user_projects\domains\mydomainの設定を検証する場合は、ORACLE_HOME\user_projects\domainsに移動します。

3. 次のように入力します。

wlsvc -debug "yourServiceName"

たとえば、wlsvc -debug "mydomain_myserver"のようになります。

設定が正常に完了している場合は、wlsvc -debugコマンドを実行するとサーバーが起動します。スクリプトから次のようなエラーが返された場合は、指定したサービス名が正しいかどうかを確認してください。

Unable to open Registry Key ....... System\CurrentControlSet\Services\wlsvc example_examplesServer\Parameters

サービスの実行に使用するユーザー・アカウントの検証

本番環境でWebLogic Server Windowsサービスを実行する場合は、アクセス権限が制限された特別なオペレーティング・システム・ユーザー・アカウントで実行する必要があります。たとえば、そのOSユーザーは、Oracleファイルおよびあなたのドメイン・ファイルのみに対するアクセス権限を持つ必要があります。これは、これらのファイルへのアクセス権限を持つ唯一のユーザー・アカウントであることが必要です。

WebLogic Serverインスタンスが特別なOSユーザー・アカウントで実行されていることを確認するには:

1. Microsoft管理コンソールの「サービス」を開きます。
たとえば、Windows XPデスクトップの場合は次のようにします。

1. 「スタート」メニューをクリックします。

2. 「スタート」メニューで、「すべてのプログラム」>「管理ツール」>「サービス」と選択します。

2. 「サービス」画面で、「WebLogic Server Windows」サービスを右クリックし、「プロパティ」をクリックします。

3. 「プロパティ」ウィンドウで、「ログオン」タブを選択します。

4. 「ログオン」でこのアカウントを選択します。特別なOSユーザー・アカウントのユーザー名とパスワードを入力します。

5. 「OK」をクリックします。

注意:

ネットワーク・ドライブにアクセスする場合は、そのネットワーク・ドライブを共有するユーザー名でWindowsサービスを実行する必要があります。

「サービス」ウィンドウの使用によるサーバー・インスタンスの停止または再起動

サービス・インスタンスをWindowsサービスとして実行するように設定したあと、Microsoft管理コンソールの「サービス」ウィンドウを使用して、サーバーを停止・再起動できます。

デフォルトでは、Microsoft管理コンソールを使用してサーバー・インスタンスを停止すると、サーバーのJava仮想マシン(JVM)を強制停止します。JVMを強制停止すると、サーバーはただちにすべての処理を終了します。セッション・データはすべて失われます。サーバーがconfig.xmlファイルへの書込みを行っている間に管理サーバーのJVMを強制停止すると、config.xmlファイルが破損するおそれがあります。正常停止を有効にする方法は、「正常停止の有効化」を参照してください。

WindowsサービスとしてインストールされているWebLogic Serverインスタンスを停止または再起動するには:

1. 「スタート」 > 「すべてのプログラム」 > 「管理ツール」 > 「サービス」と選択します。

2. 「サービス」画面で、作成したサービスを検索します。デフォルトのサービス名はwlsvcから始まります。

3. サービス名を右クリックし、ショートカット・メニューから「コマンド」を選択します。

Windowsサービスとして設定されているサーバーの削除

WebLogic Serverインスタンスを実行するWindowsサービスを削除する場合は、wlsvcユーティリティを使用してWindowsレジストリから関連キーを削除するためのスクリプトを使用できます。Windowsサービスの削除は、ドメインの構成ファイルに保存されているサーバー・インスタンスの構成に影響しません。Windowsサービスを削除した後、起動スクリプトを使用して、また、管理対象サーバーの場合はノード・マネージャを使用して、WebLogic Serverインスタンスを起動できます。

スクリプトではまず、サーバー固有の情報(サーバー・インスタンスの名前など)を特定する変数の値を設定します。次に、マスター・アンインストール・スクリプトWL_HOME\server\bin\uninstallSvc.cmdを呼び出します(WL_HOMEはWebLogic Serverのインストール・ディレクトリ)。このマスター・スクリプトからは、Windowsレジストリからキーを削除するwlsvcユーティリティが呼び出されます。

サーバー固有のアンインストーラ・スクリプトのサンプルについては、例3-3を参照してください。

WebLogic Serverインスタンスを実行するWindowsサービスを削除するためのスクリプトを作成するには:

1. ドメインの管理サーバーのルート・ディレクトリ(config.xmlファイルが格納されているディレクトリ)にテキスト・ファイルを作成します。

2. このテキスト・ファイルに、以下に示す必須のbatchコマンドを追加します。各コマンドは別々の行に記述してください。

- SETLOCAL
これは、バッチ・ファイル内の環境変数のローカライゼーションを開始するbatchコマンドです。

- set DOMAIN_NAME=domain-name
domain-nameは、WebLogic Serverドメインの名前です。

- set SERVER_NAME=server-name
server-nameは、Windowsサービスとして削除する既存のサーバー・インスタンスの名前です。

- call "WL_HOME\server\bin\uninstallSvc.cmd"
WL_HOMEは、WebLogic Serverのインストール・ディレクトリのフルパス名です。これは、WebLogic Serverマスター・アンインストール・スクリプトを呼び出すコマンドです。

- ENDLOCAL
これは、バッチ・ファイル内の環境変数のローカライゼーションを終了するbatchコマンドです。

3. このテキスト・ファイルを、拡張子.cmdで保存します。デフォルトでは、Windowsコマンド・プロンプトによって拡張子.cmdにbatchファイルが関連付けられます。

4. サーバー固有のスクリプトの名前を入力します。
指定したスクリプトがbatchファイルとして実行されます。

削除スクリプトの実行が正常に完了すると、標準出力に次のような行が出力されます。

mydomain_myserver removed

デフォルトの標準出力は、batchファイルを実行しているコマンド・プロンプトです。

例3-3 Windowsサービスを削除するスクリプト

echo off
SETLOCAL
set DOMAIN_NAME=myWLSdomain
set SERVER_NAME=myWLSserver
call "D:\Oracle\Middleware\wlserver_12.1\server\bin\uninstallSvc.cmd"
ENDLOCAL

Windowsサービスとして設定されているサーバーの起動資格証明の変更

Windowsサービスを変更して、別のユーザー資格証明でWebLogic Serverインスタンスを実行できるようにするには、次のいずれか1つを行います。

- ユーザー名とパスワードを起動IDファイルから取得するようにWindowsサービスを設定した場合は、新しいユーザー名とパスワードを格納した起動IDファイルで既存のファイルを上書きできます。WebLogic Serverのデフォルト・セキュリティ・レルムに、既存ユーザーの名前を指定する必要があります。詳細は、「起動IDファイル」を参照してください。

- ユーザー名とパスワードをWindowsレジストリから取得するようにWindowsサービスを設定した場合は、そのWindowsサービスを削除して、新しいWindowsサービスを新しいユーザー名とパスワードで作成する必要があります。

1. WebLogic Serverインスタンスを実行するWindowsサービスをアンインストールします。詳細は、「Windowsサービスとして設定されているサーバーの削除」を参照してください。

2. サービスのインストールに使用したスクリプトをテキスト・エディタで開き、新しいユーザー名とパスワードを、set WLS_USERおよびset WLS_PWコマンドの値として入力します。これらの値は、WebLogicサーバーによって暗号化されてWindowsレジストリに格納されます。

3. スクリプトへの変更内容を保存します。

4. サーバー固有のスクリプトの名前を入力します。
指定したスクリプトがbatchファイルとして実行されます。

スクリプトが正常に実行されると、次の名前のWindowsサービスが作成されます:

DOMAIN_NAME_SERVER_NAME。そして、標準出力に次のような行が出力されます:

mydomain_myserver installed

デフォルトの標準出力は、サーバー固有のbatchファイルを実行しているコマンド・プロンプトです。

5. (オプション)スクリプト・ファイルからユーザー名とパスワードを削除します。

4 サーバー障害の回避とサーバー障害からの回復

この章では、WebLogic Serverを使用するときにサーバー障害を回避し、サーバー障害からリカバリする方法について説明します。各種イベントは、サーバー・インスタンスの障害に至る可能性があり、ある障害の状態が別の傷害に至る場合が多くあります。電力の損失、ハードウェアの誤作動、オペレーティング・システムのクラッシュ、ネットワークの分割、およびアプリケーションの予期しない動作はすべて、サーバー・インスタンスの障害の要因となります。高可用性が必要とされる場合は、クラスタリング・アーキテクチャを実装して障害の影響を最小限に抑えることができます。ただし、クラスタリング環境であってもサーバー・インスタンスは周期的に障害を起こす可能性があるので、リカバリ・プロセスの用意をしておくことが必要です。

この章の内容は以下のとおりです。

- 障害回避機能と障害リカバリ機能

- 障害リカバリのためのディレクトリとファイルのバックアップ

- WebLogic Serverの終了コードと障害後の再起動

- 障害の発生した管理サーバーの再起動

- 障害の発生した管理対象サーバーの再起動

- 障害に関するその他のトピック

WebLogic Serverクラスタのフェイルオーバーについては、『Oracle WebLogic Serverクラスタの管理』のクラスタのフェイルオーバーとレプリケーションに関する項を参照してください。

障害回避機能と障害リカバリ機能

WebLogic Serverには、サーバー障害からのリカバリやサーバー障害の回避を支援するいくつかの機能が用意されています。

過負荷保護機能

WebLogic Serverでは、アプリケーションのパフォーマンスと安定性に影響するシステム負荷の増加を検出できます。これにより管理者は、あらかじめ定義された負荷のしきい値に達すると自動的に実行される障害回避アクションを構成できます。

過負荷保護機能は、予期しないレベルのアプリケーション・トラフィックやリソース使用率が原因で発生する障害の回避に役立ちます。

WebLogic Serverでは、以下の一定の条件が満たされると障害の回避が試みられます。

- ワーク・マネージャの容量を超過したとき

- HTTPセッション数があらかじめ指定されたしきい値まで増加したとき

- メモリー不足状態が発生しそうなとき

クラスタ化サービスのフェイルオーバー

アプリケーションをWebLogic Serverクラスタでホストすることにより、アプリケーションの信頼性と可用性を向上させることができます。EJBやWebアプリケーションなどのクラスタ化可能なサービスは、クラスタ内の各管理対象サーバーに均等にデプロイできます。その結果、サービスがデプロイされている1つのサーバー・インスタンスで障害が発生しても、そのサービスはサービスを中断することもステートを失うこともなくクラスタ内の別のサーバーにフェイルオーバーされます。

詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタのフェイルオーバーとレプリケーションに関する項を参照してください。

障害が発生したサーバー・インスタンスの自動再起動

WebLogic Serverの自動状態モニター機能は、ドメイン内のサーバー・インスタンスの信頼性と可用性を向上させます。各WebLogic Serverインスタンス内の選択されたサブシステムは、そのサブシステムに固有の条件に基づいて自身のステータスをモニターします。たとえば、JMSサブシステムはJMSスレッド・プールの状態をモニターし、コア・サーバー・サブシステムはデフォルトおよびユーザー定義の実行キュー統計をモニターします。個々のサブシステムは、一貫性および信頼性のある状態で動作できないと判断した場合、ホスト・サーバーに自身の状態を「障害」として登録します。

また、各WebLogic Serverインスタンスは登録されているサブシステムの状態をチェックして、全体的な有効性を判断します。1つまたは複数の重要なサブシステムがFAILED状態に達している場合、サーバー・インスタンスは自身の状態をFAILEDに設定して、アプリケーションを適切にホストできないことを示します。

サーバー自動状態モニターでは、ノード・マネージャを使用して、障害の発生したサーバーを自動的に再起動できます。これにより、ドメインの全体的な信頼性が向上し、管理者の介入が不要になります。

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャとシステム・クラッシュ・リカバリに関する項を参照してください。

サーバー・レベルの移行

WebLogic Serverには、クラスタ化サーバー・インスタンスを移行する機能が用意されています。移行できるように構成されているクラスタ化サーバーは、障害が発生した場合には管理者からのコマンドまたは自動的に、あるマシンから別のマシンにすべて移動できます。移行プロセスにより、そのサーバー・インスタンスで実行中のサービスはすべて別のマシンで使用可能になりますが、障害の発生時に実行されていたシングルトン・サービスの状態情報は使用できません。詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

サービス・レベルの移行

WebLogic Serverでは、前の項で説明したサーバー・レベルの移行機能だけでなく、個々のシングルトン・サービスの移行もサポートされています。シングルトン・サービスとは、クラスタ内で実行されるものの、常にクラスタ内の1つのインスタンス上のみで実行されなければならないサービス(JMSやJTAトランザクション・リカバリ・システムなど)のことです。

管理者は、JMSサーバーやJTSトランザクション・リカバリ・サービスをクラスタ内のサーバー・インスタンス間で移行できます。これは、サーバー・インスタンスの障害への対応として、あるいは定期的な保守の一環として行います。この機能により、ホストのサーバーで障害が発生した場合に代理のサーバー上でサービスを速やかに再起動できるため、クラスタ内の固定サービスの可用性が向上します。

詳細は、『Oracle WebLogic Serverクラスタの管理』のサービスの移行に関する項を参照してください。

管理対象サーバー独立モード

管理対象サーバーは、ドメイン構成のローカル・コピーを保持します。管理対象サーバーは起動時に、管理対象サーバーが最後にシャットダウンされてから行われたドメイン構成に対する変更を取得するために、管理サーバーに接続します。起動時に管理サーバーにアクセスできない場合、管理対象サーバーはローカルにキャッシュされた構成情報を使用できます。これは、その管理対象サーバーが最後に停止した時点の構成です。構成の更新をチェックするために管理サーバーに接続せずに起動する管理対象サーバーは、管理対象サーバーの独立(MSI)モードで稼働しています。デフォルトでは、MSIモードは有効化されています。デフォルトでは、MSIモードは有効になっています。MSIモードの無効化については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの独立の無効化に関する項を参照してください。

障害リカバリのためのディレクトリとファイルのバックアップ

この項では、WebLogic Serverで自動的に実行されるファイルのバックアップ、および管理者が行うべき推奨のバックアップ手順について説明します。

サーバー・インスタンスの障害からリカバリするには、ドメインの構成データおよびセキュリティ・データにアクセスする必要があります。WebLogicセキュリティ・サービスは、その構成データをconfig.xmlファイルのみでなく、LDAPリポジトリや他のファイルにも格納します。

詳細は、『Oracle WebLogic Serverドメインの構成の理解』のドメイン構成ファイルに関する項を参照してください。

ドメインの構成ディレクトリのバックアップ

デフォルトでは、管理サーバーはドメインの構成データをdomain_name\configディレクトリに格納します。domain_nameはドメインのルート・ディレクトリです。

configディレクトリは、管理サーバーの障害でオリジナルのコピーが使用できない場合に備えて安全な場所にバックアップします。管理サーバーに障害が発生した場合は、バックアップ・バージョンを別のマシンにコピーし、その新しいマシン上で管理サーバーを再起動します。

管理対象サーバーは起動するたびに管理サーバーにアクセスし、ドメイン構成に対して変更が行われている場合にはドメインのconfigディレクトリのローカル・コピーを更新します。

処理中にドメイン構成に対して変更が行われると、管理サーバーはローカルの/configディレクトリを更新する管理対象サーバーに通知を行います。そのため、各管理対象サーバーは常に構成データの最新のコピーをローカルにキャッシュします。

LDAPリポジトリのバックアップ

WebLogic Serverと一緒にインストールされるデフォルトの認証プロバイダ、認可プロバイダ、ロール・マッピング・プロバイダ、および資格証明マッピング・プロバイダは、自身のデータをLDAPサーバーに格納します。各WebLogic Serverには、組込みLDAPサーバーが存在します。管理サーバーには、すべての管理対象サーバーにレプリケートされるマスターLDAPサーバーが存在します。これらのインストールされたプロバイダを使用するセキュリティ・レルムが存在する場合は、次のディレクトリ・ツリーの最新のバックアップを保持する必要があります。

domain_name\servers\ adminServer\data\ldap

domain_nameはドメインのルート・ディレクトリ、adminServerは管理サーバーが実行時データやセキュリティ・データを格納するディレクトリです。

各WebLogic ServerにLDAPディレクトリがありますが、バックアップする必要があるのは管理サーバー上のLDAPデータのみです。各管理対象サーバーのLDAPデータは、セキュリティ・データが更新されたときにマスターLDAPサーバーによってレプリケートされます。WebLogicセキュリティ・プロバイダは、ドメインの管理サーバーにアクセスできないときにはセキュリティ・データを変更できません。各管理対象サーバーのLDAPリポジトリはレプリカなので変更できません。

ldap\ldapfilesサブディレクトリには、LDAPサーバーのデータ・ファイルが格納されています。このディレクトリ内のファイルには、ユーザー、グループ、グループ・メンバーシップ、ポリシー、およびロール情報が格納されます。ldapディレクトリの他のサブディレクトリには、LDAPサーバーのメッセージ・ログおよびレプリケートされたLDAPサーバーのデータが格納されます。

セキュリティ・プロバイダの構成は、LDAPデータのバックアップが進行している間は更新しないでください。管理者によるユーザーの追加などの変更がldapディレクトリ・ツリーのバックアップ中に行われると、ldapfilesサブディレクトリのバックアップに矛盾が生じるおそれがあります。矛盾が発生した場合は、矛盾はないがおそらくは最新でないLDAPバックアップが使用可能です - 1日に一度、サーバーは書込み処理を一時停止してLDAPデータの専用バックアップを作成するからです。このバックアップはZIPファイルでldap\backupディレクトリに格納され、書込み処理が再開されます。このバックアップは一貫性が確保されますが、最新のセキュリティ・データが含まれていない場合があります。

LDAPバックアップの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの組込みLDAPサーバーのバックアップの構成に関する項を参照してください。

SerializedSystemIni.datとセキュリティ証明書のバックアップ

各サーバー・インスタンスでは/securityディレクトリにSerializedSystemIni.datという名前のファイルが作成されます。このファイルには、サーバーの起動時に必要な暗号化されたセキュリティ・データが格納されます。このファイルはバックアップが必要です。

サーバーがSSLを使用する場合、セキュリティ証明書とキーもバックアップする必要があります。これらのファイルの場所はユーザーが構成できます。

WebLogic Serverの終了コードと障害後の再起動

サーバー・インスタンスが停止すると、終了コードが返されます。終了コードの値は、サーバー・プロセスが終了したときの状態に関する情報を示します。ノード・マネージャの制御下にあるサーバー・インスタンスが終了した場合、ノード・マネージャは終了コードからそのサーバー・インスタンスを再起動するかどうかを判断します。高可用性エージェントやスクリプトは、サーバーの終了コードから、サーバー・インスタンスの終了後に行うアクションを決定します。次の表にサーバーの終了コードの定義を示します。

表4-1 WebLogic Serverの終了コード

終了コードの値

意味

再起動の推奨

0より小さい

負の値は、状態の遷移中にサーバー・インスタンスに障害が発生し、安定した状態で終了しなかったたことを示します。

例: 構成が無効なサーバー・インスタンスに対してスタンバイ・モードで起動コマンドが発行されると、サーバー・インスタンスは遷移途中のSTARTING状態で障害が発生し、STANDBY状態になりません。

サーバーを再起動しないでください。サーバー・プロセス終了の原因になった問題を診断します。

0

停止コマンド(正常な停止または強制停止)の結果としてサーバー・プロセスが正常に終了したことを示します。

なし。

0より大きい

正の値は、サーバー・インスタンス自身が1つまたは複数のサブシステムが不安定になっていると判断して終了したことを示します。

例: メモリー不足状態やスタック・スレッドを検出してサーバー・インスタンスが自身を停止します。

サーバー・インスタンスは再起動できます。

障害の発生した管理サーバーの再起動

次の項では、障害後に管理サーバーを起動する方法について説明します。

注意:

ノード・マネージャを使用すると、障害の発生した管理サーバーを自動的に再起動できます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の「ノード・マネージャの概要」の管理サーバーと管理対象サーバーの再起動に関する項を参照してください。

管理サーバーの再起動

第2章「サーバーの起動と停止」を参照してください。

管理サーバーの再起動のシナリオ

表4-2 管理サーバーの再起動のシナリオ

リスニング・アドレスの定義

同じまたは異なるマシーンで同じIPアドレスの使用

異なるマシンで異なるIPアドレスの使用

未定義

1. 同じIPアドレスの異なるマシンで管理サーバーを起動する場合
a.WebLogic Serverをインストールします。

b.データを移動します。

2. 管理サーバーを起動します。
実行中の管理対象サーバーは次のAdminReconnectIntervalSecsで自動的に再接続します。

3. 管理サーバーに障害が発生したときに実行されていなかった管理対象サーバーを起動する場合、コマンドの変更は不要です。

1. WebLogic Serverをインストールします。

2. データを移動します。

3. 管理サーバーを起動します。
管理対象サーバーは前の管理サーバーURLのみを使用するため、管理サーバーが停止したときに実行中の管理対象サーバーは再接続しません。詳細は、管理対象サーバーおよび再起動された管理サーバーを参照してください。

コマンド・ラインにおいて新しい管理サーバー・リスニング・アドレスを提供する管理対象サーバーを再起動します。

4. 管理サーバーが停止したとき実行されていなかった管理対象サーバーを起動するには、コマンド・ラインで新しい管理サーバー・リスニング・アドレスを指定します。

ホストのDNS名またはIPアドレス

1. 同じIPアドレスの異なるマシンで管理サーバーを起動する場合
a.WebLogic Serverをインストールします。

b.データを移動します。

2. 管理サーバーを起動します。
実行中の管理対象サーバーは次のAdminReconnectIntervalSecsで自動的に再接続します。

3. 管理サーバーに障害が発生したときに実行されていなかった管理対象サーバーを起動する場合、コマンドの変更は不要です。

1. WebLogic Serverをインストールします。

2. データを移動します。

3. 新しいホスト・マシンのIPアドレスでconfig.xmlを更新します。別のマシンでの管理サーバーの再起動を参照してください。

4. 管理サーバーを起動します。
管理対象サーバーは前の管理サーバーURLのみを使用するため、管理サーバーが停止したときに実行中の管理対象サーバーは再接続しません。詳細は、管理対象サーバーおよび再起動された管理サーバーを参照してください。

コマンド・ラインで新しい管理サーバー・リスニング・アドレスまたはDNS名を提供する管理対象サーバーを再起動します。

5. 管理サーバーが停止したとき実行されていなかった管理対象サーバーを起動するには、コマンド・ラインで新しい管理サーバー・リスニング・アドレスまたはDNS名を指定します。

複数のホストにマップされたDNS名

1. 同じIPアドレスの異なるマシンで管理サーバーを起動する場合
a.WebLogic Serverをインストールします。

b.データを移動します。

2. 管理サーバーを起動します。
実行中の管理対象サーバーは次のAdminReconnectIntervalSecsで自動的に再接続します。

3. 管理サーバーに障害が発生したときに実行されていなかった管理対象サーバーを起動する場合、コマンドの変更は不要です。

1. WebLogic Serverをインストールします。

2. データを移動します。

3. 新しいホスト・マシンのIPアドレスでconfig.xmlを更新します。別のマシンでの管理サーバーの再起動を参照してください。

4. 管理サーバーを起動します。
複数のIPにマップする管理サーバーURLに対してのDNS名で始める実行中の管理対象サーバーは、使用可能なすべてのURLでの管理サーバーに接続しようとします。管理対象サーバーによって、いずれかのURLで再起動された管理サーバーが検出されます。

5. 管理サーバーが停止したとき実行されていなかった管理対象サーバーを起動するには、コマンド・ラインでDNS名を指定します。

別のマシンでの管理サーバーの再起動

マシンのクラッシュにより、同じマシンで管理サーバーを再起動できない場合は、次のようにして実行中の管理対象サーバーの管理を回復できます。

1. 新しい管理マシンでWebLogic Serverソフトウェアをインストールします(インストールされていない場合)。

2. アプリケーション・ファイルをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバーがこれらのファイルを使用できるようにします。新しいファイル・システム上でのアプリケーション・ファイルの相対位置は、元の管理サーバーのファイル・システムと同じにする必要があります。

3. 構成およびセキュリティ・データをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバーがこれらのファイルを使用できるようにします。詳細は、障害リカバリのためのディレクトリとファイルのバックアップを参照してください。

- 新しいホスト・マシンのIPアドレスでconfig.xmlを更新します。リスニング・アドレスを空白に設定した場合、これを変更する必要がありません。例:

<server>
<name>AdminServer</name>
...
<listen-address></listen-address>
</server>

- config.xmlを手動で編集できます。または、WLSTオフラインを使用して、リスニング・アドレスを更新します。

4. 新しいマシンで管理サーバーを再起動します。

管理対象サーバーと再起動された管理サーバー

管理サーバーが実行を停止して、そのドメインの管理対象サーバーは実行を続けた場合、各管理対象サーバーは、ServerMBean属性のAdminReconnectIntervalSecondsで指定される間隔で管理サーバーに定期的に再接続しようとします。デフォルトでは、AdminReconnectIntervalSecondsは10秒です。

別のIPアドレスで管理サーバーが再起動された後管理対象サーバーを再接続するには、次の項目が必要です。

- 複数のIPアドレスにマップする管理サーバーURLに対してDNS名を構成します。たとえば、10.10.10.1および10.10.10.2にマップするwlsadminserverと名前付けられたDNSサーバー。

- 管理対象サーバーを起動するとき管理サーバーURLに対してDNS名を指定します。例:
-Dweblogic.management.server=protocol://wlsadminserver:port

または

startManagedWebLogic.cmd managed_server_name protocol://wlsadminserver:port

管理サーバーが停止したとき、管理対象サーバーは、すべての使用可能なURLで管理サーバーに再接続しようとします。いずれかのURLで管理サーバーにヒットすると管理対象サーバーに接続され、他のURLでの再接続の試みは停止されます。管理サーバーが再度停止したとき再接続しようとします。

障害の発生した管理対象サーバーの再起動

次の項では、障害後に管理対象サーバーを起動する方法について説明します。トランザクションおよびJMSに関連するリカバリの考慮事項については、「障害に関するその他のトピック」を参照してください。

管理サーバーにアクセスできる場合の管理対象サーバーの起動

障害の発生した管理対象サーバーから管理サーバーにアクセスできる場合は、次のことを行うことができます。

- ノード・マネージャを使用して手動または自動で再起動します。この動作をサポートするように、ノード・マネージャと管理対象サーバーを構成する必要があります。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の管理対象サーバーの起動、停止、中断および再起動に関する項を参照してください。

- コマンドまたはスクリプトを使用して手動で起動します。手順については、第2章「サーバーの起動と停止」を参照してください。

管理サーバーにアクセスできない場合の管理対象サーバーの起動

起動時に管理サーバーにアクセスできない場合、管理対象サーバーはローカルにキャッシュされた構成データをconfigディレクトリから読み込むことで構成を取得できます。この方法で起動した管理対象サーバーは、「管理対象サーバー独立(MSI)モード」で実行されます。

管理対象サーバー独立モードの理解

管理対象サーバーは、起動時に管理サーバーと通信して、その構成情報を取得しようとします。起動時に管理サーバーにアクセスできない場合、管理対象サーバーは構成ファイルおよびセキュリティ・ファイルを直接読み込むことで構成を取得できます。このような方法で起動された管理対象サーバーは、「管理対象サーバー独立(Managed Server Independence: MSI)モード」で実行されます。デフォルトでは、MSIモードは有効になっています。MSIモードの無効化については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの独立の無効化に関する項を参照してください。

管理対象サーバー独立モードでは、管理対象サーバーは以下のことを行います。

- ローカルのconfigディレクトリでconfig.xml(ドメインのconfig.xmlのレプリカ)を検索します。

- 自身のsecurityディレクトリでSerializedSystemIni.datとboot.properties(ユーザー名とパスワードの暗号化バージョンが格納されているファイル)を検索します。詳細は、「サーバーの起動と停止を行うためのユーザー資格証明の指定」を参照してください。

サーバーのドメイン・ディレクトリの前述の場所にconfig.xmlおよびSerializedSystemIni.datがない場合は、管理サーバーのドメイン・ディレクトリからこれらのファイルをコピーできます。

MSIモードとノード・マネージャ

ノード・マネージャでは、サーバー・インスタンスをMSIモードで起動できません(再起動のみ可能)。通常の起動では、ノード・マネージャは管理サーバーへのアクセスを必要とします。管理サーバーにアクセスできない場合は、管理対象サーバーのホスト・マシンにログインして管理対象サーバーを起動する必要があります。

MSIモードとセキュリティ・レルム

管理対象サーバーは、セキュリティ・レルムにアクセスできないと起動プロセスを完了できません。

WebLogic Serverがインストールしたセキュリティ・レルムを使用する場合、管理サーバーはドメインのセキュリティ・データを格納するためにLDAPサーバーを保持します。すべての管理対象サーバーは、このLDAPサーバーをレプリケートします。管理サーバーに障害が発生した場合、MSIモードで動作する管理対象サーバーはレプリケートしたLDAPサーバーをセキュリティ・サービス用に使用します。

サード・パーティのセキュリティ・プロバイダを使用する場合、管理対象サーバーはセキュリティ・データにアクセスできなければ起動プロセスを完了できません。

MSIモードとSSL

サーバー用にSSLを設定した場合、各サーバーには独自の証明書ファイル、キー・ファイル、およびその他のSSL関連ファイルのセットが必要になります。ドメインの構成ファイルにサーバーごとのこれらのファイルのパス名が格納されている場合でも、管理対象サーバーは、SSL関連ファイルを管理サーバーから取得しません。MSIモードで起動した場合、SSL関連ファイルがアクセスできるマシンに格納されていれば、それらのファイルをコピーまたは移動する必要はありません。

MSIモードとデプロイメント

MSIモードで起動する管理対象サーバーは、そのステージング・ディレクトリserver_root\stage\appNameからアプリケーションをデプロイします。

MSIモードとドメイン・ログ・ファイル

各WebLogic Serverインスタンスは、そのローカル・ログ・ファイルとドメイン全体のログ・ファイルにログ・メッセージを書き込みます。ドメイン・ログ・ファイルは、ドメイン内のすべてのサーバーのメッセージを表示できる一元的な場所を提供します。

通常、管理対象サーバーはメッセージを管理サーバーに転送して、管理サーバーがそのメッセージをドメイン・ログ・ファイルに書き込みます。ただし、MSIモードで動作している管理対象サーバーはそのローカル・サーバー・ログ・ファイルにメッセージを書込み続け、メッセージをドメイン・ログ・ファイルに転送しません。

詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のサーバー・インスタンスからドメイン・ログへのメッセージ転送の仕組みを参照してください。

MSIモードと管理対象サーバーの構成の変更

MSIモードで管理対象サーバーを起動する場合は、管理サーバーとの通信が復元されるまで構成を変更できません。

MSIモードでの管理対象サーバーの起動

注意:

障害の発生した管理対象サーバーが、障害の発生時に移行可能なサービスのアクティブなサーバーとして機能していた、クラスタリングされた管理対象サーバーであった場合は、『Oracle WebLogic Serverクラスタの管理』の現在アクティブなホストがない場合の移行に関する項で説明されている手順を実行します。MSIモードで管理対象サーバーを起動しないでください。

MSIモードで管理対象サーバーを起動するには:

1. 管理対象サーバーのルート・ディレクトリにconfigサブディレクトリがあることを確認します。
configディレクトリがない場合は、管理サーバーのルート・ディレクトリ(またはバックアップ)から管理対象サーバーのルート・ディレクトリにコピーします。

注意:

-Dweblogic.RootDirectory=path起動オプションを使用して、これらのファイルが格納されているルート・ディレクトリを指定することもできます。

2. コマンド・ラインまたはスクリプトで管理対象サーバーを起動します。方法については、第2章「サーバーの起動と停止」を参照してください。
管理対象サーバーは、管理サーバーからアクセスされるまではMSIモードで動作します。このシナリオでの管理サーバーの再起動については、「障害の発生した管理サーバーの再起動」を参照してください。

障害に関するその他のトピック

障害の発生したサーバー・インスタンスからのJMSデータの回復の詳細は、『Oracle WebLogic Server JMSリソースの管理』のWebLogic JMSクラスタリングの構成に関する項を参照してください。

障害発生後のトランザクション回復の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のサーバー障害発生後のトランザクション回復に関する項を参照してください。

管理サーバーの起動を妨害する破損した、または使用不可能な組込みLDAPサーバー・ファイルからのリカバリの詳細は、『Oracle WebLogic Serverセキュリティの管理』の「組込みLDAPサーバーの管理」のバックアップとリカバリに関する項を参照してください。

5 サーバーのライフサイクルの理解

この章では、サーバーのライフサイクル(WebLogic Serverインスタンスが遷移可能な一連の状態)について説明します。WebLogic Serverインスタンスは常に、特定の動作状態にあります。起動、停止、中断などのコマンドは、サーバー・インスタンスの動作状態に所定の変化をもたらします。

この章の内容は以下のとおりです。

- サーバーのライフサイクルの図

- サーバーの状態の取得と使用

- サーバー・ライフサイクルにおけるサーバーの状態の理解

- サーバーのライフサイクル・コマンドの使用について

- 中断および停止時における処理中の作業の処理

サーバーのライフサイクルの図

図5-1は、サーバーのライフサイクル、および状態とライフサイクル・コマンドの間の関係を示しています。

図5-1 サーバーのライフサイクル・コマンドに対する状態の遷移

各状態と、状態間の関係を理解するには、「サーバー・ライフサイクルにおけるサーバーの状態の理解」を参照してください。ライフサイクル・コマンドについては、「サーバーのライフサイクル・コマンドの使用について」を参照してください。

サーバーの状態の取得と使用

WebLogic Serverは、サーバー・インスタンスの現在の状態、およびサーバー・インスタンスが起動してからこれまでに起こった状態の遷移に関する情報を表示および保存します。この情報は、以下の作業を行う管理者にとって便利です。

- サーバー・インスタンスとそれがホストするアプリケーションの可用性をモニターする

- 起動や停止などの日常のタスクを行う

- アプリケーション・サービスの問題を診断する

- サーバー・インスタンスで障害やクラッシュが発生したときに、サービスの移行などの修正アクションを計画する

サーバーの状態を取得する方法は、次のとおりです。

- 管理コンソール - 以下の複数のページで状態情報が表示されます。

- 「サーバーのサマリー」ページ(「環境」>「サーバー」)で、「サーバー」表に、現在のドメインの各サーバー・インスタンスの現在の状態が表示されます。

- 「SERVER_NAME」>「監視」ページには、現在実行されているサーバー・インスタンスの状態、およびその状態になった日付と時刻が表示されます。

- 「診断」>「ログ・ファイル」には、サーバー・インスタンスが最後に起動してからこれまでに起こった状態遷移のタイムスタンプ付きメッセージが格納されています。

- プログラム: サーバーのweblogic.management.runtime.ServerRuntimeMBeanのgetState()メソッドを使用します。たとえば、時間のかかる正常な停止プロセスの進捗をモニターするには、独立したスレッドでgetstateを発行します。詳細は、Oracle WebLogic Server MBeanリファレンスのServerRuntimeMBeanに関する項を参照してください。

- WebLogic Scripting Tool: 『WebLogic Scripting Toolの理解』の実行時情報の取得に関する項を参照してください。

サーバー・ライフサイクルにおけるサーバーの状態の理解

次の項では、WebLogic Serverのライフサイクルにおける各状態について説明します。

SHUTDOWN状態

SHUTDOWN状態のWebLogic Serverインスタンスは、構成されていますが、非アクティブになっています。

サーバー・インスタンスは、停止コマンドまたは強制停止コマンドの結果としてSHUTDOWN状態になります。また、自動状態モニターの結果として状態が不安定になっていることを検出した場合には、サーバー・インスタンスは自身を強制停止できます。障害の発生を検出した場合に自身を強制停止できるのは、Auto Kill If Failed属性がtrueに設定されているサーバー・インスタンスのみです。詳細は、「障害が発生したサーバー・インスタンスの自動再起動」を参照してください。

起動コマンド、管理モードで起動コマンド、またはスタンバイ・モードで起動コマンドを使用して、SHUTDOWN状態のサーバー・インスタンスをSTARTING状態に遷移できます。

STARTING状態

WebLogic Serverインスタンスは、STARTING状態中に、起動コマンド、管理モードで起動コマンド、またはスタンバイ・モードで起動コマンドの結果としてSHUTDOWN状態からSTANDBY状態に遷移します。

STARTING状態では、サーバー・インスタンスはクライアント・リクエストも管理リクエストも受け付けることができません。

サーバー・インスタンスは以下の方法で構成データを取得します。

- 管理サーバーは、configディレクトリからドメインのセキュリティ構成とその他のドメイン構成データを取得します。

- 管理対象サーバーは構成データとセキュリティ・データを取得するために管理サーバーにアクセスします。SSL通信を使用するように構成されている場合、管理対象サーバーは、証明書ファイル、キー・ファイルなどの独自のSSL関連ファイルを使用して、残りの構成データとセキュリティ・データを取得するために管理サーバーにアクセスします。

注意:

管理対象サーバーが管理サーバーにアクセスできない場合、デフォルトでは管理対象サーバーは、ローカルにキャッシュされたドメインのconfigディレクトリのコピーを使用して管理対象サーバー独立モードで起動します。「管理対象サーバー独立モードの理解」を参照してください。

サーバー・インスタンスは、表5-1に示されているサービスを示された順序で起動します。

表5-1 STARTING状態で起動されるサービス

Service

機能

weblogic.management.provider.internal.BeanInfoAccessService

weblogic.management.PropertyService

weblogic.management.internal.DomainDirectoryService

weblogic.upgrade.domain.DomainUpgradeServerService

weblogic.management.upgrade.ConfigurationMigrationService

weblogic.deploy.service.internal.DeploymentService

weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService

weblogic.management.provider.internal.RuntimeAccessService

weblogic.diagnostics.lifecycle.DiagnosticInstrumentationService

weblogic.t3.srvr.BootService

カーネル、実行キュー、サーバー・ランタイムなどの基本的なサービスを含みます。

weblogic.management.provider.internal.DomainAccessService

管理サーバー専用のサービスのルート。

weblogic.diagnostics.lifecycle.DiagnosticFoundationService

ロギングおよびデバッグのコンテナ・サービス。

weblogic.nodemanager.NMService

サーバー・ステータスの変更をサーバー出力ストリームを介してノード・マネージャに報告する、ノード・マネージャ・サービス。

weblogic.timers.internal.TimerService

weblogic.rjvm.RJVMService

停止時に、管理サーバー接続以外のすべてのRJVMをクローズします。

weblogic.protocol.ProtocolService

weblogic.t3.srvr.DomainLibService

構成されたプロトコルを登録し、それらを発信トラフィックと着信構成で使用可能にします。管理対象サーバーでは、正確なアドレス情報を管理サーバーに提供できるように、起動シーケンスの早い段階でこのサービスが使用可能になっている必要があります。

weblogic.server.channels.ChannelService

このサービスは、構成の一貫性と登録されるプロトコルに依存します。起動シーケンスのこの時点までに、すべてのプロトコルの登録が完了している必要があります。

このサービスの起動後は、ServerChannelManager.findDefaultLocalServer Channel()などのアドレス情報が使用可能になります。

weblogic.server.channels.AdminPortService

weblogic.t3.srvr.ListenerService

weblogic.transaction.internal.PrimordialTransactionService

トランザクション・ヘルパーが初期化され、トランザクションをスレッドに関連付けたり、トランザクション・マネージャを取得したり、UserTransactionオブジェクトを取得したり、といったタスクを実行するユーティリティが提供されます。

起動シーケンスのこの時点では、トランザクション・サービス自体は有効になっていません。

weblogic.rmi.internal.RMIServerService

初期化のみに使用されるRMI起動サービス。

weblogic.jndi.internal.NamingService

weblogic.iiop.IIOPClientService

VM全体の委任機能をインストールします。

weblogic.management.PrimordialManagementService

weblogic.ldap.EmbeddedLDAP

weblogic.security.SecurityService

weblogic.jndi.internal.RemoteNamingService

weblogic.security.acl.internal.RemoteSecurityService

weblogic.rmi.cluster.RemoteBinderFactoryService

weblogic.cluster.ClusterService

weblogic.iiop.IIOPService

weblogic.protocol.ProtocolHandlerService

weblogic.management.internal.AdminService

weblogic.xml.registry.XMLService

weblogic.messaging.interception.MessageInterceptionService

weblogic.cluster.migration.rmiservice.MigratableRMIService

weblogic.messaging.interception.configuration.Configurator

weblogic.drs.internal.DataReplicationService

weblogic.management.provider.internal.EditAccessService

管理編集サービスを起動します。

weblogic.health.HealthMonitorService

weblogic.cluster.migration.MigrationService

weblogic.t3.srvr.T3InitializationService

BootServicesImplなどの、非推奨のT3サーバー・サービスを初期化します。

weblogic.server.channels.ChannelRuntimeService

起動シーケンスのこの時点後は、ServerRuntime.getListenAddress()などのアドレス情報と動的な更新が使用可能になります。

weblogic.store.admin.DefaultStoreService

weblogic.transaction.internal.TransactionService

weblogic.jdbc.common.internal.JDBCService

weblogic.connector.common.ConnectorService

weblogic.store.admin.StoreDeploymentService

weblogic.jms.JMSServiceServerLifeCycleImpl

weblogic.jms.BridgeService

weblogic.application.ApplicationShutdownService

正常な停止時に、保留中のアプリケーション作業をチェックします。アプリケーションもここで停止されます。

weblogic.messaging.saf.internal.SAFServerService

weblogic.ejb20.deployer.EJB20Service

weblogic.io.common.internal.FileService

weblogic.time.server.TimerService

停止時にアプリケーションのトリガーを取り消します。

weblogic.rmi.internal.HeartbeatHelperService

プロトコル専用のクライアントのハートビートをサポートします。

weblogic.servlet.internal.WebService

weblogic.webservice.conversation.internal.ConversationServiceImpl

weblogic.wtc.gwt.WTCServerLifeCycleImpl

com.beasys.CORBA.pool.weblogic.WLECService

weblogic.management.service.ManagedServerNotificationService

weblogic.webservice.WSServerService

weblogic.management.mbeanservers.runtime.internal.RuntimeServerService

実行時JMXサービス。

weblogic.management.mbeanservers.edit.internal.EditServerService

weblogic.management.mbeanservers.compatability.internal.CompatabilityMBeanServerService

weblogic.management.snmp.SNMPService

weblogic.management.deploy.classdeployment.ClassDeploymentService

起動クラスと停止クラスの処理を追加します。

weblogic.server.ServerLifeCycleService

サーバー・ライフサイクル実行時MBeanの作成を処理して、ドメインの制御を行えるようにします。

weblogic.server.channels.EnableAdminListenersService

サーバーがADMIN状態になる前に管理ポートを有効にします。

domainweblogic.diagnostics.lifecycle.DiagnosticSystemService

STANDBY状態

STANDBY状態のサーバー・インスタンスは、通常のリスニング・ポートがクローズされているためリクエストを処理しません。管理ポートはオープンされており、サーバー・インスタンスをRUNNING状態またはSHUTDOWN状態に遷移させるライフサイクル・コマンドを受け付けます。それ以外の管理リクエストは受け付けられません。

STANDBY状態で起動したサーバー・インスタンスは、「ホット」バックアップとして待機させておくことができます。ホット・バックアップは高可用性環境で便利な機能です。

サーバー・インスタンスをSTANDBY状態にし、その状態のままにしておく唯一のライフサイクル・コマンドが、スタンバイ・モードで起動コマンドです。起動コマンドまたは管理モードで起動コマンドを発行すると、サーバー・インスタンスはSTANDBY状態を経験します。

ADMIN状態

ADMIN状態のとき、WebLogic Serverは起動して実行状態にありますが、受け付けるのは管理操作のみとなり、ユーザーはサーバーおよびアプリケーション・レベルの管理タスクを実行できます。ADMIN状態のサーバー・インスタンスの機能は、以下のとおりです。

- 管理コンソールが使用できます。

- サーバー・インスタンスは、adminロールのユーザーからのリクエストを受け付けます。adminロールが付与されていないユーザーからのリクエストは拒否されます。

- アプリケーションは、アプリケーションのADMIN状態でアクティブ化されます。アプリケーションは、adminおよびAppTesterロールのユーザーからのリクエストを受け付けます。アプリケーションのADMIN状態にあるアプリケーションにアクセスする、これらのロールのユーザーには、管理機能だけでなく、すべてのアプリケーション機能に対するアクセス権があります。

- JDBC、JMS、およびJTAの各サブシステムはアクティブであり、それらに対する管理操作を実行できます。ただし、サーバーがADMIN状態にある場合、これらのサブシステムにアクセスするために管理者レベルの権限を有している必要はありません。

- デプロイメントまたは再デプロイメントは許可されます。それらは、サーバー・インスタンスをADMIN状態からRUNNING状態に(再開コマンドを使用して)遷移させるときに有効になります。

- ClusterServiceはアクティブであり、他のクラスタ・メンバーからのハートビートおよび通知をリスニングします。他の管理対象サーバーがクラスタに参加していることを検出できますが、他のクラスタ・メンバーからは認識できません。

管理モードで起動コマンド、中断コマンド、または強制中断コマンドを使用して、サーバー・インスタンスをADMIN状態に遷移できます。

起動コマンド、停止コマンド、または強制停止コマンドの結果として、サーバー・インスタンスはADMIN状態を経験します。

ADMIN状態のサーバー・インスタンスを、再開コマンドを使用してRUNNING状態に、あるいは停止コマンドまたは強制停止コマンドを使用してSHUTDOWN状態に遷移できます。

RESUMING状態

この遷移状態中に、WebLogic ServerはSTANDBY状態またはADMIN状態からRUNNING状態への移動に必要な処理を実行します。

再開コマンドを発行すると、サーバー・インスタンスはRESUMING状態に遷移します。起動コマンドを発行すると、サーバー・インスタンスはRESUMING状態を経験します。

RUNNING状態

RUNNING状態では、WebLogic Serverは完全に機能しており、クライアントにサービスを提供し、クラスタの正規メンバーとして機能できます。

サーバー・インスタンスは、起動コマンドあるいはADMIN状態またはSTANDBY状態からの再開コマンドの結果として、RUNNING状態に遷移します。

RUNNING状態のサーバー・インスタンスを、中断コマンド、強制中断コマンド、停止コマンド、または強制停止コマンドを使用してSUSPENDING状態またはFORCE_SUSPENDING状態に遷移できます。

SUSPENDING状態

この遷移状態中に、WebLogic ServerはADMIN状態への移動に必要な処理を実行します。一部のWebLogic Serverサブシステムおよびサービスを順に中断し、進行中のアプリケーション作業(「処理中の」作業)の事前に定義済みの部分を完了します。

中断コマンドを発行すると、サーバー・インスタンスはSUSPENDING状態に遷移します。停止コマンドを発行すると、サーバー・インスタンスはSUSPENDING状態を経験します。

処理中の作業については、「中断および停止時における処理中の作業の処理」を参照してください。

注意:

SUSPENDING状態の間に、ワーク・マネージャが、アプリケーション・スレッドで保留になっている処理中の作業を完了させます。ただし、この状態の間には新しい作業をワーク・マネージャにスケジューリングできません。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャの理解に関する項を参照してください。

FORCE_SUSPENDING状態

この遷移状態中に、WebLogic ServerはADMIN状態への移動に必要な処理を実行します。一部のWebLogic Serverサブシステムおよびサービスを順に中断します。FORCE_SUSPENDING状態では、WebLogic Serverは、処理中の作業を正常に完了しません。進行中のアプリケーション作業は破棄されます。

強制中断コマンドまたは強制停止コマンドを発行すると、サーバー・インスタンスはFORCE_SUSPENDING状態を経験します。

SHUTTING_DOWN状態

この遷移状態では、WebLogic Serverは、サブシステムおよびサービスの中断を完了し、アプリケーション・リクエストも管理リクエストも受け付けません。

停止コマンドまたは強制停止コマンドを発行すると、サーバー・インスタンスはSHUTTING_DOWN状態を経験します。

FAILED状態

メモリー不足例外やアプリケーション・スレッドのスタック状態の結果として、あるいは1つまたは複数の重要なサービスが機能しなくなった場合に、実行中のサーバー・インスタンスで障害が発生することがあります。サーバー・インスタンスは自身の状態をモニターし、1つまたは複数の重要なサブシステムが不安定になっていることを検出すると、自身の状態をFAILEDと宣言します。

FAILED状態になると、サーバー・インスタンスは障害のない状態に戻ろうとします。ADMIN状態になる前に障害が発生した場合には、サーバー・インスタンスはゼロより小さい終了コードを返して自身を停止します。サーバーの終了コードについては、「WebLogic Serverの終了コードと障害後の再起動」を参照してください。

ADMIN状態になった後で(ただし、RUNNING状態になる前)で障害が発生した場合には、サーバー・インスタンスはデフォルトではADMIN状態に戻ります(管理ポートが有効になっている場合)。

注意:

必要であれば、ADMIN状態になった後に障害が発生した場合でも、ADMIN状態に戻らずに停止するように、サーバー・インスタンスを構成できます。

サーバー・インスタンスは、どの状態からでもFAILED状態になることができます。ただし、サーバー・インスタンスがFAILED状態になってからは、実行状態に直接戻ることはできません。FAILED状態は致命的なものであり、サーバーはRUNNING状態に戻る前に、ADMINまたはSHUTDOWN状態に入る必要があります。

注意:

理論上、サーバーはFAILED状態に入った後、たとえば障害が発生した状態を引き起こしていたハングしているスレッドが、ハングしていない状態になった場合などには、再び使用可能になることがあり得ます。

しかし、一度FAILED状態に入ると、サーバーはRUNNINGに戻る前にADMINまたはSHUTDOWN状態に入る必要があります。

OverlaodProtectionMBeanを使用してSHUTDOWNなどの自動アクションを構成したり、サーバー・インスタンスがFAILED状態に入ったときにADMIN状態に移動したりできます。

サーバーのライフサイクル・コマンドの使用について

この項では、各ライフサイクル・コマンド、その発行方法、およびサーバー・インスタンスの状態への影響について説明します。詳細は、次を参照してください。

- ライフサイクル・コマンドの発行方法については、以下を参照してください。

- 『WebLogic Scripting Toolの理解』のライフサイクル・コマンドに関する項およびサーバーとサーバー・ライフサイクルの管理に関する項

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーの起動と停止に関する項

- 第2章「サーバーの起動と停止」

- ノード・マネージャを使用する環境の主要なライフサイクル・イベントに関連するノード・マネージャ・プロセスについては、『Oracle WebLogic Serverノード・マネージャの管理』のWebLogic Server環境でのノード・マネージャの機能に関する項を参照してください。

- 各ライフサイクル状態で発生する処理については、「サーバー・ライフサイクルにおけるサーバーの状態の理解」を参照してください。

サーバーの状態とサーバーのライフサイクルの間の関係を表す図については、図5-1を参照してください。

起動

起動コマンドを実行すると、サーバー・インスタンスは、SHUTDOWN状態からRUNNING状態に遷移します。起動コマンドでは、サーバー・インスタンスの初期状態に応じて、状態が次のように遷移します。

SHUTDOWN > STARTING > STANDBY > ADMIN > RESUMING > RUNNING

ServerMBean.StartupMode属性を使用して、サーバー・インスタンスの起動時の状態を指定できます。その値は管理コンソールで表示され、構成できます。WLSTを使用しても、java weblogic.Server起動オプションとして指定しても構成できます。コマンド・ライン、管理コンソール、またはconfig.xmlのいずれにも起動モードの値が指定されない場合、デフォルトではRUNNING状態で起動されます。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの起動モードの指定に関する項および『Oracle WebLogic Serverコマンド・リファレンス』のその他のサーバー構成オプションに関する項を参照してください。

コマンドの使い方

『WebLogic Server WLSTコマンド・リファレンス』のstartに関する項、startServerに関する項とnmStartに関する項、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプの管理コンソールからの管理対象サーバーの起動に関する項を参照してください。

スタンバイ・モードでの起動

スタンバイ・モードを有効にする起動コマンドを実行すると、サーバー・インスタンスは、SHUTDOWN状態からSTANDBY状態に、次の状態遷移のシーケンスで遷移します。

SHUTDOWN > STARTING > STANDBY

コマンドの使い方

『Oracle WebLogic Serverコマンド・リファレンス』の-Dweblogic.management.startupmodeに関する項、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのスタンバイ・モードでの管理対象サーバーの起動に関する項を参照してください。

管理モードでの起動

管理モードを有効にする起動コマンドを実行すると、サーバー・インスタンスは、SHUTDOWN状態からADMIN状態に、次の状態遷移のシーケンスで遷移します。

SHUTDOWN > STARTING > STANDBY > ADMIN

コマンドの使い方

『Oracle WebLogic Serverコマンド・リファレンス』の-Dweblogic.management.startupmodeに関する項、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプの管理モードでの管理対象サーバーの起動に関する項を参照してください。

再開

再開コマンドを実行すると、サーバー・インスタンスは、STANDBY状態またはADMIN状態からRUNNING状態に、次の状態遷移のシーケンスで遷移します。

STANDBY > ADMIN > RESUMING > RUNNING

コマンドの使い方

『WebLogic Server WLSTコマンド・リファレンス』のresumeに関する項、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーの再開に関する項を参照してください。

正常な中断

正常な中断コマンドを実行すると、サーバー・インスタンスは、RUNNING状態からADMIN状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常に処理されます。

RUNNING > SUSPENDING > ADMIN

コマンドの使い方

『WebLogic Server WLSTコマンド・リファレンス』のsuspendに関する項、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーの中断に関する項を参照してください。

強制中断

強制中断コマンドを実行すると、サーバー・インスタンスは、RUNNING状態からADMIN状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常には処理されません。

RUNNING > FORCE_SUSPENDING > ADMIN

コマンドの使い方

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーの中断に関する項を参照してください。

正常な停止

正常な停止コマンドを実行すると、サーバー・インスタンスは、RUNNING状態からSHUTDOWN状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常に処理されます。

RUNNING > SUSPENDING > ADMIN > SHUTTING_DOWN > SHUTDOWN

コマンドの使い方

『WebLogic Server WLSTコマンド・リファレンス』のshutdownに関する項、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・インスタンスの停止に関する項を参照してください。

正常な停止の制御

ServerMBeanには、正常な停止プロセスの長さを制御する2つの属性があります。これらの値については、「SERVER_NAME」>「制御」>「起動と停止」ページで確認および構成できます。

- 「停止時にセッションを無視」 - このオプションを有効にすると、WebLogic ServerはすべてのHTTPセッションをただちに中止し、完了やタイムアウトを待つことはありません。デフォルトのタイムアウトは1時間なので、破棄されたセッションのタイムアウトを待つと、正常な停止のプロセスが非常に長くなります。

- 「正常な停止のタイムアウト」 - サーバー・インスタンスが正常な停止を完了するタイムリミットを指定します。タイムアウト値を指定し、サーバー・インスタンスがその期間内に正常な停止を完了しない場合、WebLogic Serverはそのサーバー・インスタンスで強制停止を実行します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの正常な停止の制御に関する項およびクラスタ内のサーバーの停止に関する項を参照してください。

停止操作とアプリケーションのアンデプロイメント

正常な停止と強制停止の両方で、サブシステムはアプリケーションを適切にアンデプロイします。この処理の結果として、サーブレットのdestroy()またはejbRemove()などのアプリケーション・コードが停止時に呼び出されることがあります。停止シーケンスにおいては、JMS、JDBC、およびトランザクションはアプリケーションが停止した後で停止します。これにより、アプリケーション・コードからJMS、JDBC、およびトランザクションの各サービスにアクセスすることが可能になります。

強制停止

強制停止コマンドを実行すると、サーバー・インスタンスは、どの状態からでもSHUTDOWN状態に遷移します。このとき、進行中の作業は正常には処理されません。強制停止コマンドがRUNNING状態のサーバー・インスタンスに対して実行されると、状態が次のように遷移します。

RUNNING > FORCE_SUSPENDING > ADMIN > STANDBY > SHUTDOWN

コマンドの使い方

『WebLogic Server WLSTコマンド・リファレンス』のshutdownに関する項、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・インスタンスの停止に関する項を参照してください。

強制停止は、即座に実行されます。WebLogic Serverのサブシステムが、現在進行中のすべてのアプリケーション処理を停止します。強制停止は、どの状態のサーバー・インスタンスでも実行できます。

致命的な例外によって強制停止が失敗した場合は、ServerMBeanのServerLifecycleTimeoutVal属性に指定した秒数後にサーバーが終了します。

注意:

クラスタ内のサーバー・インスタンスを強制停止しても、その状態が別のサーバー・インスタンスにレプリケートされていれば、クラスタリングされたサービスがクラスタ内の別のサーバー・インスタンスにフェイルオーバーされます。ただし、以下の例外があります。

- セカンダリ・セッションがまだ作成されていないHTTPセッションをホストするサーバー・インスタンスに強制停止コマンドを発行すると、そのセッションは失われます。

- ステートフル・セッションEJBのレプリケートされたステートをホストするサーバー・インスタンスに強制停止コマンドを発行すると、そのEJBをホストするサーバー・インスタンス(プライマリ)に障害が発生した場合でも、レプリケートされた状態が存在しないため、そのEJBはフェイルオーバーされません。

強制停止時に行われるアンデプロイメント・プロセス、および関連するプログラミング上の考慮事項については、「停止操作とアプリケーションのアンデプロイメント」を参照してください。

中断および停止時における処理中の作業の処理

次の項では、SUSPENDING処理およびSHUTTING_DOWN処理で各サブシステムがどのように進行中の作業を処理するのかを説明します。

RMIサブシステム

Remote Method Invocation (RMI)サブシステムは、3段階で中断します。このプロセスの各段階は、次の段階が始まる前に完了します。

1. 非トランザクション・リモート・リクエストが、非トランザクションRMIサービスによって拒否されます。

2. クライアントが開始したトランザクション・サービスが、保留中のクライアント・トランザクションが完了するのを待ちます。

3. リモートRMIサービスが、トランザクションのあるなしに関係なくすべてのリモート・リクエストを拒否します。

以上の段階を経た後は、リモート・クライアント・リクエストは許可されません。管理者権限のあるリクエストと内部システム呼出しは受け付けられます。

クラスタ化サーバー・インスタンスが一時停止を準備するように指示された場合、RMIシステムはすべてのインメモリー・レプリケーション呼出しを拒絶し、他のクラスタ・メンバーがレプリケート・セッションのための新しいホストを選択できるようにします。

Webコンテナ

一時停止を準備するように指示された後のWebコンテナ・サブシステムは、新しいセッション・リクエストを拒否します。既存のセッションは、その永続性手法に従って処理されます。

- 永続性なし - 永続性のない保留中のセッションは完了できます。

- クラスタでのインメモリー・レプリケーション - セカンダリ・セッションのあるセッションはただちに中断されます。プライマリ・セッションにセカンダリ・セッションがない場合、Webコンテナはセカンダリ・セッションが作成されるか、またはセッションがタイムアウトになるまで待機します。

- JDBC永続性とファイル永続性 - Webコンテナは、データベースまたはファイル・ストアにレプリケートされたセッションをただちに中断します。

保留セッションの完了は省略可能です。すべてのセッションをただちに中止するには、管理コンソールのSERVER_NAME制御「起動と停止」ページの「停止時にセッションを無視」オプションを使用するか、WLSTのshutdownコマンドで-ignoreSessionsオプションを使用します。

クラスタでプライマリ・セッションが中止されると、正常に停止されるサーバー上のプライマリ・セッションだけでなく、それに対応する、別のクラスタ化インスタンス上のレプリケートされたセッションも破棄されます。

タイマー・サービス

タイマー・サービスは、アプリケーション実行キューで動作しているすべてのトリガーを取り消します。アプリケーション実行キューには、デフォルト・キューとExecuteQueueMBeanを通じて構成されたキューがあります。

アプリケーション・サービス

アプリケーション・サービスは、中断の前にアプリケーション・キューの保留作業を完了します。アプリケーション実行キューには、デフォルト・キューとExecuteQueueMBeanを通じて構成されたキューがあります。

EJBコンテナ

EJBコンテナは、メッセージドリブンBean (MDB)を中断します。

JMSサービス

Java Messaging Service (JMS)は、それ自身に中断のマークを付けます。これにより、新しいリクエストは拒否されます。JMSシステムは、以下の手順で正常に中断します。

停止するサーバー・インスタンスにJMSサーバーが含まれている場合:

- メッセージの割当のために待機しているすべての送信リクエストが即座に返されます。

- JMSサーバーに属する宛先のすべてのコンシューマがクローズされます。

- 永続ストアがクローズされます。

停止するサーバー・インスタンスにJMS接続ファクトリが含まれている場合:

- クライアント接続がクローズされます。

通常、JMSサブシステムの正常な中断の各ステップは迅速に(1秒未満で)実行されます。ただし、リクエストが通常よりも速いディスクI/Oを必要とする場合(たとえば、100MBのメッセージの永続「送信」のリクエストなど)は、クライアント・リクエストを完了するのにこれより長い時間がかかることもあります。

JMSサーバーへの接続の数、JMS接続ファクトリのコンシューマの数、および関連する実行時情報は、JMSRuntimeMbean、JMSConnectionRuntimeMBean、JMSConsumerRuntimeMBeanなどのJMS実行時MBeanを使用してモニターできます。

JDBCサービス

JDBCサービスは、接続プール中のアイドル状態の接続をクローズします。

注意:

接続がまだ使用されている場合は、JDBCサービスの停止が失敗し、正常な停止は完了しません。アプリケーションがまだ接続を使用している場合、サーバー・インスタンスを停止するには強制停止コマンドを使用します。詳細については、「強制停止」を参照してください。

トランザクション・サービス

トランザクション・サービスは、トランザクション・マネージャの保留トランザクション数がゼロになってから中断します。すべての保留トランザクションを完了するのは、トランザクション・タイムアウトの構成次第では時間がかかります。

保留トランザクションが原因で正常な停止に時間がかかりすぎる場合は、強制停止コマンドで停止できます。強制的な停止では、すべてのサブシステムのすべての保留作業が中断されます。

A サーバーの起動と停止:クイック・リファレンス

次の項では、WebLogic Serverのインスタンスを起動および停止するために頻繁に使われる単純な方法を説明します。

- WebLogic Serverのインスタンスの起動

- WebLogic Serverのインスタンスの停止

WebLogic Serverインスタンスの起動と停止の総合的な情報については、第2章「サーバーの起動と停止」を参照してください。

WebLogic Serverのインスタンスの起動

次の表では、WL_HOMEはWebLogic Serverの最上位のインストール・ディレクトリを表します。たとえば、c:\Oracle\Middleware\Oracle_Home\wlserver\などです。

表A-1 サーバー・インスタンスの起動

起動対象

手順

MedRecサーバー

呼出し:

ORACLE_HOME\user_projects\domains\medrec\bin\startWebLogic.cmd(Windows)

ORACLE_HOME/user_projects/domains/medrec/bin/startWebLogic.sh(UNIX)

サーバーは、medrecドメインで管理サーバーとして起動します。

詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

MedRecサーバー(Springバージョン)

呼出し:

ORACLE_HOME\user_projects\domains\medrec-spring\bin\startWebLogic.cmd(Windows)

ORACLE_HOME/user_projects/domains/medrec-spring/bin/startWebLogic.sh(UNIX)

サーバーは、medrec-springドメインで管理サーバーとして起動します。

詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

サンプル・サーバー

呼出し:

ORACLE_HOME\user_projects\domains\wl_server\bin\startWebLogic.cmd(Windows)

ORACLE_HOME/user_projects/domains/wl_server/bin/startWebLogic.sh(UNIX)

サーバーは、wl_serverドメインで管理サーバーとして起動します。

詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

作成した管理サーバー

呼出し:

DOMAIN_NAME\bin\startWebLogic.cmd (Windows)

DOMAIN_NAME/bin/startWebLogic.sh (UNIX)

DOMAIN_NAMEは、ドメインを配置したディレクトリの名前です(通常は、ORACLE_HOME\user_projects\domains\DOMAIN_NAME)。

サーバーがユーザー名とパスワードの入力を要求する場合は、サーバーを起動する許可を持つWebLogic Serverユーザーの名前を入力します。詳細は、サーバーの起動と停止を行うユーザー資格証明の指定を参照してください。

注意: 開発環境では、管理サーバーを起動し、アプリケーションを直接その管理サーバーにデプロイすれば通常は十分です。本番環境では、通常はアプリケーションを実行する管理対象サーバーを作成します。

管理対象サーバー

1. ドメインの管理サーバーを起動します。

2. 起動する管理対象サーバーをホストするコンピュータでノード・マネージャを起動します。
ノード・マネージャが実行されていない場合は、コマンド・プロンプトまたはスクリプトを使用して手動で起動できます。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの起動と停止に関する項を参照してください。

3. ドメインの管理コンソールを起動します。
『Oracle WebLogic Serverの理解』の管理コンソールの起動に関する項を参照してください。

4. ノード・マネージャが実行されているマシンに管理対象サーバーを割り当てることで、管理対象サーバーをノード・マネージャに関連付けます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのマシンの作成と構成に関する項およびサーバー・インスタンスのマシンへの割当てに関する項を参照してください。

5. 管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。

6. 右ペインで、「制御」タブを選択します。

7. サーバー・ステータス表で、起動するサーバーの名前の横にあるチェック・ボックスを選択して、「起動」をクリックします。

8. 「はい」をクリックして確認します。

管理対象サーバーを起動する他の方法については、第2章「サーバーの起動と停止」を参照してください。

管理対象サーバーのクラスタ

ノード・マネージャを使用してクラスタリングされた管理対象サーバーを起動する場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタ内の管理対象サーバーの起動に関する項を参照してください。

WebLogic Serverのインスタンスの停止

管理コンソールを使用してWebLogic Serverインスタンスを停止することをお薦めします。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・インスタンスの停止に関する項および正常な停止の制御に関する項を参照してください。

- クラスタ内の管理対象サーバーの正常な停止については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタ内のサーバーの停止に関する項を参照してください。

または、WebLogic Serverの停止スクリプトを呼び出してサーバーを停止することもできます。停止スクリプトによるサーバーの停止を参照してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。