|
|
WebLogic Server インスタンスが遷移できる一連の状態の変遷のことを、サーバのライフサイクルといいます。WebLogic Server インスタンスは常に、特定の動作状態にあります。起動、停止、中断などのコマンドは、サーバ インスタンスの動作状態に所定の変化をもたらします。以下の節では、WebLogic Server の状態、状態の遷移、およびライフサイクル コマンドについて説明します。
図 5-1 は、サーバのライフサイクル、および状態とライフサイクル コマンドの間の関係を示しています。
各状態と、状態間の関係を理解するには、「サーバ ライフサイクルにおけるサーバの状態について」を参照してください。ライフサイクル コマンドについては、「サーバのライフサイクル コマンドの使用について」を参照してください。
WebLogic Server は、サーバ インスタンスの現在の状態、およびサーバ インスタンスが起動してからこれまでに起こった状態の遷移に関する情報を表示および保存します。この情報は、以下の作業を行う管理者にとって便利です。
weblogic.management.runtime.ServerRuntimeMBean の getState() メソッドを使用します。たとえば、時間のかかる正常な停止プロセスの進捗をモニタするには、独立したスレッドで getstate を発行します。詳細については、『WebLogic Server MBean リファレンス』の「ServerRuntimeMBean」を参照してください。
以下の節では、WebLogic Server のライフサイクルにおける各状態について説明します。
SHUTDOWN 状態の WebLogic Server インスタンスは、コンフィグレーションされていますが、アクティブではありません。
サーバ インスタンスは、停止コマンドまたは強制停止コマンドの結果として SHUTDOWN 状態になります。また、自動状態モニタの結果として状態が不安定になっていることを検出した場合には、サーバ インスタンスは自身を強制停止できます。障害の発生を検出した場合に自身を強制停止できるのは、AutoKillIfFailed 属性が true に設定されているサーバ インスタンスのみです。詳細については、「障害が発生したサーバ インスタンスの自動再起動」を参照してください。
起動コマンド、管理モードで起動コマンド、またはスタンバイ モードで起動コマンドを使用して、SHUTDOWN 状態のサーバ インスタンスを STARTING 状態に遷移できます。
WebLogic Server インスタンスは、STARTING 状態中に、起動コマンド、管理モードで起動コマンド、またはスタンバイ モードで起動コマンドの結果として SHUTDOWN 状態から STANDBY 状態に遷移します。
STARTING 状態では、サーバ インスタンスはクライアント要求も管理要求も受け付けることができません。
サーバ インスタンスは以下の方法でコンフィグレーション データを取得します。
config ディレクトリからドメイン コンフィグレーション データ (ドメインのセキュリティ コンフィグレーションを含む) を取得する。 | 注意 : | 管理対象サーバが管理サーバにアクセスできない場合、デフォルトでは管理対象サーバは、ローカルにキャッシュされたドメインの config ディレクトリのコピーを使用して管理対象サーバ独立モードで起動します。「管理対象サーバ独立モードについて」を参照してください。 |
サーバ インスタンスは、表 5-1 に示されているサービスを示された順序で起動します。
UserTransaction オブジェクトを取得したり、といったタスクを実行するユーティリティが提供される。
|
|||
STANDBY 状態のサーバ インスタンスは、通常のリスン ポートが閉じられているので要求を処理しません。管理ポートは開かれており、サーバ インスタンスを RUNNING 状態または SHUTDOWN 状態に遷移させるライフサイクル コマンドを受け付けます。それ以外の管理要求は受け付けられません。
STANDBY 状態で起動したサーバ インスタンスは、「ホット」バックアップとして待機させておくことができます。ホット バックアップは高可用性環境で便利な機能です。
サーバ インスタンスを STANDBY 状態にし、その状態のままにしておく唯一のライフサイクル コマンドが、スタンバイ モードで起動コマンドです。起動コマンドまたは管理モードで起動コマンドを発行すると、サーバ インスタンスは STANDBY 状態を経験します。
ADMIN 状態のとき、WebLogic Server は起動して実行状態にありますが、受け付けるのは管理操作のみとなり、ユーザはサーバおよびアプリケーション レベルの管理タスクを実行できます。ADMIN 状態のサーバ インスタンスの機能は、以下のとおりです。
admin ロールのユーザからの要求を受け付ける。admin ロールが付与されていないユーザからの要求は拒否される。ADMIN 状態でアクティブ化される。アプリケーションは、admin および AppTester ロールのユーザからの要求を受け付ける。アプリケーションの ADMIN 状態にあるアプリケーションにアクセスする、これらのロールのユーザには、管理機能だけでなく、すべてのアプリケーション機能に対するアクセス権がある。 ADMIN 状態から RUNNING 状態に (再開コマンドを使用して) 遷移させるときに有効になる。ClusterService はアクティブであり、他のクラスタ メンバーからのハートビートおよび通知をリスンする。他の管理対象サーバがクラスタに参加していることを検出できるが、他のクラスタ メンバーからは認識できない。
管理モードで起動コマンド、中断コマンド、または強制中断コマンドを使用して、サーバ インスタンスを ADMIN 状態に遷移できます。
起動コマンド、停止コマンド、または強制停止コマンドの結果として、サーバ インスタンスは ADMIN 状態を経験します。
ADMIN 状態のサーバ インスタンスを、再開コマンドを使用して RUNNING 状態に、あるいは停止コマンドまたは強制停止コマンドを使用して SHUTDOWN 状態に遷移できます。
この遷移状態中に、WebLogic Server は STANDBY 状態または ADMIN 状態から RUNNING 状態への移動に必要な処理を実行します。
再開コマンドを発行すると、サーバ インスタンスは RESUMING 状態に遷移します。起動コマンドを発行すると、サーバ インスタンスは RESUMING 状態を経験します。
RUNNING 状態では、WebLogic Server は完全に機能しており、クライアントにサービスを提供し、クラスタの正規メンバーとして機能できます。
サーバ インスタンスは、起動コマンドあるいは ADMIN 状態または STANDBY 状態からの再開コマンドの結果として、RUNNING 状態に遷移します。
RUNNING 状態のサーバ インスタンスを、中断コマンド、強制中断コマンド、停止コマンド、または強制停止コマンドを使用して SUSPENDING 状態または FORCE_SUSPENDING 状態に遷移できます。
この遷移状態中に、WebLogic Server は ADMIN 状態への移動に必要な処理を実行します。一部の WebLogic Server サブシステムおよびサービスを順に中断し、進行中のアプリケーション作業 (「処理中の」作業) の事前に定義済みの部分を完了します。
中断コマンドを発行すると、サーバ インスタンスは SUSPENDING 状態に遷移します。停止コマンドを発行すると、サーバ インスタンスは SUSPENDING 状態を経験します。
処理中の作業については、「中断および停止時における処理中の作業の処理」を参照してください。
| 注意 : | SUSPENDING 状態の間に、ワーク マネージャが、アプリケーション スレッドで保留されている処理中の作業を完了させます。詳細については、『サーバ環境のコンフィグレーション』の「ワーク マネージャについて」を参照してください。 |
この遷移状態中に、WebLogic Server は ADMIN 状態への移動に必要な処理を実行します。一部の WebLogic Server サブシステムおよびサービスを順に中断します。FORCE_SUSPENDING 状態では、WebLogic Server は、処理中の作業を正常に完了しません。進行中のアプリケーション作業は破棄されます。
強制中断コマンドまたは強制停止コマンドを発行すると、サーバ インスタンスは FORCE_SUSPENDING 状態を経験します。
この遷移状態では、WebLogic Server は、サブシステムおよびサービスの中断を完了し、アプリケーション要求も管理要求も受け付けません。
停止コマンドまたは強制停止コマンドを発行すると、サーバ インスタンスは SHUTTING_DOWN 状態を経験します。
メモリ不足例外やアプリケーション スレッドのスタック状態の結果として、あるいは 1 つまたは複数の重要なサービスが機能しなくなった場合に、実行中のサーバ インスタンスで障害が発生することがあります。サーバ インスタンスは自身の状態をモニタし、1 つまたは複数の重要なサブシステムが不安定になっていることを検出すると、自身の状態を FAILED と宣言します。
FAILED 状態のサーバ インスタンスは、管理要求にもクライアント要求にも対応できません。
FAILED 状態になると、サーバ インスタンスは障害のない状態に戻ろうとします。ADMIN 状態になる前に障害が発生した場合には、サーバ インスタンスはゼロより小さい終了コードを返して自身を停止します。サーバの終了コードについては、「WebLogic Server の終了コードと障害後の再起動」を参照してください。
ADMIN 状態になった後で (ただし、RUNNING 状態になる前) で障害が発生した場合には、サーバ インスタンスはデフォルトでは ADMIN 状態に戻ります (管理ポートが有効になっている場合)。
| 注意 : | 必要であれば、ADMIN 状態になった後に障害が発生した場合でも、ADMIN 状態に戻らずに停止するように、サーバ インスタンスをコンフィグレーションできます。 |
サーバ インスタンスは、どの状態からでも FAILED 状態になることができます。ただし、サーバ インスタンスが FAILED 状態になってからは、実行状態に直接戻ることはできません。FAILED 状態は致命的なものであり、サーバは RUNNING 状態に戻る前に、ADMIN または SHUTDOWN 状態に入る必要があります。
| 注意 : | 理論上、サーバは FAILED 状態に入った後、たとえば障害が発生した状態を引き起こしていたハングしているスレッドが、ハングしていない状態になった場合などには、再び使用可能になることがあり得ます。 |
| 注意 : | しかし、一度 FAILED 状態に入ると、サーバは RUNNING に戻る前に ADMIN または SHUTDOWN 状態に入る必要があります。 |
この節では、各ライフサイクル コマンド、その発行方法、およびサーバ インスタンスの状態への影響について説明します。詳細については、以下を参照してください。
サーバの状態とサーバのライフサイクルの間の関係を表す図については、図 5-1 を参照してください。
起動コマンドを実行すると、サーバ インスタンスは、SHUTDOWN 状態から RUNNING 状態に遷移します。起動コマンドでは、サーバ インスタンスの初期状態に応じて、状態が次のように遷移します。
SHUTDOWN
STARTINGSTANDBYADMINRESUMINGRUNNING
ServerMBean.StartupMode 属性を使用して、サーバ インスタンスの起動モードを指定できます。その値は Administration Console で表示され、コンフィグレーションできます。WLST を使用しても、java weblogic.Server 起動オプションとして指定してもコンフィグレーションできます。コマンドライン、Administration Console、または config.xml のいずれにも起動モードの値が指定されない場合、デフォルトでは RUNNING 状態で起動されます。
詳細については、Administration Console オンライン ヘルプの「起動モードの指定」および『コマンド リファレンス』の「サーバ属性をコンフィグレーションするためのオプション」を参照してください。
『WebLogic Scripting Tool ガイド』の「start」、「startServer」、および「nmStart」と、Administration Console オンライン ヘルプの「Administration Console からの管理対象サーバの起動」を参照してください。
スタンバイ モードを有効にする起動コマンドを実行すると、サーバ インスタンスは、SHUTDOWN 状態から STANDBY 状態に、次の状態遷移のシーケンスで遷移します。
『コマンド リファレンス』の「-Dweblogic.management.startupmode」、および Administration Console オンライン ヘルプの「スタンバイ モードでの管理対象サーバの起動」を参照してください。
管理モードを有効にする起動コマンドを実行すると、サーバ インスタンスは、SHUTDOWN 状態から ADMIN 状態に、次の状態遷移のシーケンスで遷移します。
『コマンド リファレンス』の「-Dweblogic.management.startupmode」、および Administration Console オンライン ヘルプの「管理モードでの管理対象サーバの起動」を参照してください。
再開コマンドを実行すると、サーバ インスタンスは、STANDBY 状態または ADMIN 状態から RUNNING 状態に、次の状態遷移のシーケンスで遷移します。
『WebLogic Scripting Tool ガイド』の「resume」、および Administration Console オンライン ヘルプの「サーバの再開」を参照してください。
正常な中断コマンドを実行すると、サーバ インスタンスは、RUNNING 状態から ADMIN 状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常に処理されます。
『WebLogic Scripting Tool ガイド』の「suspend」、および Administration Console オンライン ヘルプの「サーバの中断」を参照してください。
強制中断コマンドを実行すると、サーバ インスタンスは、RUNNING 状態から ADMIN 状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常には処理されません。
Administration Console オンライン ヘルプの「サーバの中断」を参照してください。
正常な停止コマンドを実行すると、サーバ インスタンスは、RUNNING 状態から SHUTDOWN 状態に、次の状態遷移のシーケンスで遷移します。このとき、進行中の作業は正常に処理されます。
RUNNINGSUSPENDINGADMINSHUTTING_DOWNSHUTDOWN
『WebLogic Scripting Tool ガイド』の「shutdown」、および Administration Console オンライン ヘルプの「サーバ インスタンスの停止」を参照してください。
ServerMBean には、正常な停止プロセスの長さを制御する 2 つの属性があります。それらの値は、[SERVER_NAME｜制御｜起動と停止] で表示され、コンフィグレーションできます。
Administration Console オンライン ヘルプの「正常な停止の制御」および「クラスタのサーバの停止」を参照してください。
正常な停止と強制停止の両方で、サブシステムはアプリケーションを適切にアンデプロイします。この処理の結果として、サーブレットの destroy() または ejbRemove() などのアプリケーション コードが停止時に呼び出されることがあります。停止シーケンスにおいては、JMS、JDBC、およびトランザクションはアプリケーションが停止した後で停止します。これにより、アプリケーション コードから JMS、JDBC、およびトランザクションの各サービスにアクセスすることが可能になります。
強制停止コマンドを実行すると、サーバ インスタンスは、どの状態からでも SHUTDOWN 状態に遷移します。このとき、進行中の作業は正常には処理されません。強制停止コマンドが RUNNING 状態のサーバ インスタンスに対して実行されると、状態が次のように遷移します。
RUNNINGFORCE_SUSPENDINGADMINSTANDBYSHUTDOWN
『WebLogic Scripting Tool ガイド』の「shutdown」、および Administration Console オンライン ヘルプの「サーバ インスタンスの停止」を参照してください。
強制停止は、即座に実行されます。WebLogic Server のサブシステムが、現在進行中のすべてのアプリケーション処理を停止します。強制停止は、どの状態のサーバ インスタンスでも実行できます。
致命的な例外によって強制停止が失敗した場合は、ServerMBean の ServerLifecycleTimeoutVal 属性に指定した秒数後にサーバが終了します。
| 注意 : | クラスタ内のサーバ インスタンスを強制停止しても、そのステートが別のサーバ インスタンスにレプリケートされていれば、クラスタ化されたサービスがクラスタ内の別のサーバ インスタンスにフェイルオーバされます。ただし、以下の例外があります。 |
強制停止時に行われるアンデプロイメント プロセス、および関連するプログラミング上の考慮事項については、「停止操作とアプリケーションのアンデプロイメント」を参照してください。
以下の節では、SUSPENDING 処理および SHUTTING_DOWN 処理で各サブシステムがどのように進行中の作業を処理するのかを説明します。
Remote Method Invocation (RMI) サブシステムは、3 段階で中断します。このプロセスの各段階は、次の段階が始まる前に完了します。
以上の段階を経た後は、リモート クライアント要求は許可されません。管理者特権のある要求と内部システム呼び出しは受け付けられます。
クラスタ化されたサーバ インスタンスが中断を準備するように指示された場合、RMI システムはすべてのインメモリ レプリケーション呼び出しを拒絶し、他のクラスタ メンバーがレプリケート セッションのための新しいホストを選択できるようにします。
中断を準備するように指示された後の Web コンテナ サブシステムは、新しいセッション要求を拒否します。既存のセッションは、その永続性手法に従って処理されます。
保留セッションの完了は省略可能です。すべてのセッションを直ちに中止するには、Administration Console の [SERVER_NAME｜制御｜起動と停止] ページの [停止時にセッションを無視] オプションを使用するか、または WLST の shutdown コマンドで -ignoreSessions オプションを使用します。
クラスタでプライマリ セッションが中止されると、正常に停止されるサーバ上のプライマリ セッションだけでなく、それに対応する、別のクラスタ化されたインスタンス上のレプリケートされたセッションも破棄されます。
タイマー サービスは、アプリケーション実行キューで動作しているすべてのトリガを取り消します。アプリケーション実行キューには、デフォルト キューと ExecuteQueueMBean を通じてコンフィグレーションされたキューがあります。
アプリケーション サービスは、中断の前にアプリケーション キューの保留作業を完了します。アプリケーション実行キューには、デフォルト キューと ExecuteQueueMBean を通じてコンフィグレーションされたキューがあります。
EJB コンテナは、メッセージ駆動型 Bean (MDB) を中断します。
Java Messaging Service (JMS) は、それ自身に中断のマークを付けます。これにより、新しい要求は拒否されます。JMS システムは、以下の手順で正常に中断します。
停止するサーバ インスタンスに JMS サーバが含まれている場合 :
停止するサーバ インスタンスに JMS 接続ファクトリが含まれている場合 :
通常、JMS サブシステムの正常な中断の各ステップはすばやく (1 秒未満で) 実行されます。ただし、要求が通常よりも速いディスク I/O を必要とする場合 (たとえば、100MB のメッセージの永続「送信」の要求など) は、クライアント要求を完了するのにこれより長い時間がかかることもあります。
JMS サーバへの接続の数、JMS 接続ファクトリのコンシューマの数、および関連する実行時情報は、JMSRuntimeMbean、JMSConnectionRuntimeMBean、JMSConsumerRuntimeMBean などの JMS 実行時 MBean を使用してモニタできます。
JDBC サービスは、接続プール中のアイドル状態の接続を閉じます。
| 注意 : | 接続がまだ使用されている場合は、JDBC サービスの停止が失敗し、正常な停止は完了しません。アプリケーションがまだ接続を使用している場合、サーバ インスタンスを停止するには強制停止コマンドを使用します。詳細については、「強制停止」を参照してください。 |
トランザクション サービスは、トランザクション マネージャの保留トランザクション数がゼロになってから中断します。すべての保留トランザクションを完了するのは、トランザクション タイムアウトのコンフィグレーション次第では時間がかかります。
保留トランザクションが原因で正常な停止に時間がかかりすぎる場合は、強制停止コマンドで停止できます。強制的な停止では、すべてのサブシステムのすべての保留作業が中断されます。
  
|