WebLogic Server のコンフィグレーションと管理
|
 |
 |
|
WebLogic Server インスタンスは常に、特定の動作状態にあります。コマンド (起動、停止、およびサスペンドなど) は、サーバ インスタンスの状態に特定の変化をもたらします。以下の節では、WebLogic Server の状態、状態の遷移、およびライフサイクル コマンドについて説明します。
WebLogic Server インスタンスが遷移できる一連の状態の変遷のことを、サーバのライフサイクルと言います。図 7-1 は、サーバのライフサイクル、および WebLogic Server の動作状態間の関係を示しています。
各状態と、状態間の関係を理解するには、「WebLogic Server の状態について」を参照してください。
WebLogic Server は、サーバ インスタンスの現在の状態、およびサーバ インスタンスが起動してからこれまでに起こった状態の遷移に関する情報を表示および保存します。この情報は、以下の作業を行う管理者にとって有益です。
サーバ インスタンスの状態には、以下の複数の方法でアクセスできます。
weblogic.management.runtime.ServerRuntimeMBean の getState() メソッドを使用すれば、プログラム的にサーバ インスタンスの状態を取得できます。getstate を発行します。詳細については、『WebLogic JMX Service プログラマーズ ガイド』の「実行時の情報へのアクセス」を参照してください。 以降の節では、サーバ インスタンスの主要な状態、その状態と関連する処理、およびその状態が状態遷移のシーケンスにどのように収まるのかを説明します。
SHUTDOWN 状態のサーバ インスタンスは、コンフィグレーションされていますが、アクティブではありません。サーバ インスタンスは、正常な停止または強制停止の結果として SHUTDOWN 状態になります。
正常な停止は、サーバ インスタンスが RUNNING または STANDBY 状態にあるときに開始されます。正常な停止のプロセスでは、次のように状態が遷移します。
RUNNINGSUSPENDINGSTANDBYSHUTTING DOWNSHUTDOWN
「正常な停止」を参照してください。
強制停止は、あらゆるサーバ状態から開始されます。強制停止のプロセスでは、次のように状態が遷移します。
あらゆる状態STANDBYSHUTTING DOWNSHUTDOWN
「強制停止」を参照してください。
Administration Console オンライン ヘルプの「サーバの起動と停止」を参照してください。
STARTING 状態のサーバ インスタンスは、要求を受け付け、アプリケーションの処理を実行する準備をします。サーバ インスタンスは、STARTING 状態では要求を受け付けられません。
サーバ インスタンスが起動すると、そのサーバ インスタンスはコンフィグレーション データの取得、カーネルレベルのサービスの開始、サブシステムレベルのサービスの初期化、アプリケーションのデプロイ、および起動クラスのロードと実行を行います。起動プロセスの詳細については、「起動」を参照してください。
サーバ インスタンスは、起動コマンドの結果として SHUTDOWN 状態からのみ STARTING 状態に入ることができます。
Administration Console オンライン ヘルプの「サーバの起動と停止」を参照してください。
STANDBY 状態のサーバでは、すべてのサービスと内部アプリケーション (Administration Console など) が初期化されており、管理コマンドを受け入れたり、クラスタの通信に参加したりできます。 内部以外のアプリケーションは部分的にデプロイされており、サーバを RUNNING 状態に移行すると、サーバは残りのデプロイメント プロセスを完了します。STANDBY 状態のサーバは外部クライアントからの要求は受け付けません。
サーバ インスタンスは、以下の場合に STANDBY 状態になります。
スタンバイ モードでサーバ インスタンスを起動すると、特に可用性の高い環境でサーバを「ホット」バックアップとして使用可能な状態にしておくことができます。スタンバイ モードで起動したサーバ インスタンスは、障害の発生したサーバ インスタンスの代わりとしてすぐに実行状態にすることができます。
スタンバイ モードで起動されるサーバ インスタンスは、次のように状態が遷移します。
STANDBY 状態を経験します。 正常な停止のプロセスで、サーバ インスタンスの状態は次のように遷移します。
RUNNINGSUSPENDINGSTANDBYSHUTTING DOWNSHUTDOWN
強制停止のプロセスで、サーバ インスタンスの状態は次のように遷移します。
サーバ インスタンスは、再開コマンドの結果として RESUMING 状態に入ります。STANDBY から再開されるサーバ インスタンスは、次のように状態が遷移します。
RUNNING 状態のサーバ インスタンスはクライアントにサービスを提供し、クラスタの正メンバーとして動作できます。サーバ インスタンスは、以下の場合に RUNNING 状態に入ります。
サーバ インスタンスは、正常な停止の過程でこの状態に入ります。SUSPENDING 状態のサーバは、処理中の作業の事前に定義済みの部分を処理します。SUSPENDING 状態のサーバ インスタンスが処理中の作業で実行する処理については、「処理中の作業の処理」を参照してください。処理中の作業が完了すると、サーバは SUSPENDING 状態から SHUTTING_DOWN 状態に進みます。
正常な停止のプロセスで、サーバ インスタンスの状態は次のように遷移します。
RUNNINGSUSPENDINGSTANDBYSHUTTING DOWNSHUTDOWN
サーバ インスタンスは、正常な停止または強制停止の結果として SHUTDOWN 状態になります。
正常な停止のプロセスで、サーバ インスタンスの状態は次のように遷移します。
RUNNINGSUSPENDINGSTANDBYSHUTTING DOWNSHUTDOWN
「正常な停止」を参照してください。
強制停止のプロセスで、サーバ インスタンスの状態は次のように遷移します。
「強制停止」を参照してください。
サーバ インスタンスは、1 つまたは複数の重要なサービスが機能しなくなると FAILED 状態に入ります。1 つまたは複数の重要なサブシステムで障害を検出すると、サーバ インスタンスはその状態を FAILED に設定して、アプリケーションを適切にホストできないことを示します。
FAILED 状態から回復するためには、サーバ インスタンスは手動または自動 (ホスト マシンでノード マネージャがコンフィグレーションされている場合) で停止および再起動する必要があります。自動的な再起動については、「障害の発生した管理対象サーバの停止」を参照してください。
サーバ インスタンスは、RUNNING 状態からのみ FAILED 状態に入ることができます。
サーバ インスタンスにアクセスできない場合、そのサーバは UNKNOWN 状態にあります。
障害が発生したか、強制停止された管理対象サーバをノード マネージャが起動する場合、そのノード マネージャは補足的なサーバの状態を定義します (「ノード マネージャと管理対象サーバの状態」を参照)。それらの状態は Administration Console に表示されるため、再起動プロセスのステータスを目で確認することができます。
ノード マネージャについては、「ノード マネージャの概要」を参照してください。
この節では、サーバ インスタンスの状態に影響する主要なコマンドと、そのコマンドの結果としてサーバ インスタンスが実行する処理を説明します。 ライフサイクル コマンドの発行については、Administration Console オンライン ヘルプの「サーバの起動と停止」を参照してください。
ノード マネージャを使用する環境の主要なライフサイクル イベントに関連するノード マネージャの処理については、「ライフサイクル操作でのノード マネージャの通信」を参照してください。
サーバ インスタンスが起動すると、そのサーバ インスタンスは次のように機能します。
管理サーバは、ドメインの config.xml からドメイン コンフィグレーション データ (セキュリティ コンフィグレーション データなど) を取得します。
管理対象サーバはコンフィグレーション データとセキュリティ データを取得するために管理サーバにアクセスします。 SSL が設定されている場合、管理対象サーバは、証明書ファイル、キー ファイルなどの独自の SSL 関連ファイルを使用し、残りのコンフィグレーション データとセキュリティ データを取得するために管理サーバにアクセスします。
正常な停止では、進行中の特定のアプリケーション処理を完了するための時間が WebLogic Server サブシステムに与えられます。正常な停止の過程で完了される作業は、処理中の作業と呼ばれます。正常な停止の過程では、サブシステムは処理中の作業を完了し、特定のシーケンスで同期的にサスペンドされます。そのため、フロントエンド サブシステムがサスペンドされているときにも、JDBC 接続プールなどのバックエンド サブシステムは利用可能となります。
注意 : 正常な停止プロセスでは、停止処理と WebLogic 実行キュー スレッドで処理中の作業を同期させます。スレッドを作成するアプリケーションでは、アプリケーション スレッドで保留されている処理中の作業を制御する必要があります。この制御は、停止クラスを使用することで実現できます。
次のリストは、サブシステムがサスペンドになる順序を示しています。各サブシステムは、次のサブシステムがサスペンドの準備を始める前にその処理中の作業を完了します。
ServerMBean には、正常な停止プロセスの長さを制御する新しい属性が 2 つ追加されています。それらの値は、[サーバ
以降の節では、正常な停止の過程で各サブシステムがサスペンドになるときにどのように進行中の作業を処理するのかを説明します。
Remote Method Invocation (RMI) サブシステムは、3 段階でサスペンドになります。このプロセスの各段階は、次の段階が始まる前に完了します。
以上の段階を経た後は、リモート クライアント要求は許可されません。管理者特権のある要求と内部システム呼び出しは受け付けられます。
クラスタ化されたサーバ インスタンスがサスペンドを準備するように指示された場合、RMI システムはすべてのインメモリ レプリケーション呼び出しを拒絶し、他のクラスタ メンバーがレプリケート セッションのための新しいホストを選択できるようにします。
サスペンドを準備するよう指示された後の Web コンテナ サブシステムは、新しいセッション要求を拒否します。既存のセッションは、その永続性手法に従って処理されます。
保留セッションの完了は省略可能です。 すべてのセッションを直ちに中止するには、Administration Console の [サーバweblogic.Admin で -ignoreSessions オプションを使用します。
タイマー サービスは、アプリケーション実行キューで動作しているすべてのトリガを取り消します。アプリケーション実行キューには、デフォルト キューと ExecuteQueueMBean を通じてコンフィグレーションされたキューがあります。
アプリケーション サービスは、サスペンドの前にアプリケーション キューの保留作業を完了します。アプリケーション実行キューには、デフォルト キューと ExecuteQueueMBean を通じてコンフィグレーションされたキューがあります。
EJB コンテナは、メッセージ駆動型 Bean (MDB) をサスペンドします。
Java Messaging Service (JMS) は、それ自身にサスペンドのマークを付けます。これにより、新しい要求は拒否されます。JMS システムは、以下の手順で正常にサスペンドします。
停止するサーバ インスタンスに JMS サーバが含まれている場合 :
停止するサーバ インスタンスに JMS 接続ファクトリが含まれている場合 :
通常、JMS サブシステムの正常なサスペンドの各ステップはすばやく (1 秒未満で) 実行されます。ただし、要求が通常よりも速いディスク I/O を必要とする場合 (たとえば、100 MB のメッセージの永続「送信」の要求など) は、クライアント要求を完了するのにこれより長い時間がかかることもあります。
JMS サーバへの接続の数、JMS 接続ファクトリのコンシューマの数、および関連する実行時情報は、JMSRuntimeMbean、JMSConnectionRuntimeMBean、JMSConsumerRuntimeMBean を始めとする JMS 実行時 MBean を使用してモニタできます。
JDBC サービスは、接続プール中のアイドル状態の接続を閉じます。
注意 : 接続がまだ使用されている場合は、JDBC サービスの停止が失敗し、正常な停止は完了しません。アプリケーションがまだ接続を使用している場合、サーバ インスタンスを停止するには強制停止コマンドを使用します。詳細については、「強制停止」を参照してください。
トランザクション サービスは、トランザクション マネージャの保留トランザクション数がゼロになってからサスペンドします。すべての保留トランザクションを完了するのは、トランザクション タイムアウトのコンフィグレーション次第では時間がかかります。
保留トランザクションが原因で正常な停止に時間がかかりすぎる場合は、強制停止コマンドで停止できます。強制的な停止では、すべてのサブシステムのすべての保留作業がサスペンドされます。
正常な停止と強制停止の両方で、サブシステムはアプリケーションを適切にアンデプロイします。この処理の結果として、サーブレットの destroy() または ejbRemove() などのアプリケーション コードが呼び出されることがあります。停止シーケンスにおいては、JMS、JDBC、およびトランザクションはアプリケーションが停止した後で停止します。これにより、アプリケーション コードから JMS、JDBC、およびトランザクションの各サービスにアクセスすることが可能になります。
強制停止は、即座に実行されます。WebLogic Server のサブシステムが、現在進行中のすべてのアプリケーション処理をサスペンドします。強制停止は、どの状態のサーバ インスタンスでも実行できます。
致命的な例外によって強制停止が失敗した場合は、ServerMBean の ServerLifecycleTimeoutVal 属性に指定した秒数後にサーバが終了します。
強制停止の過程で行われるアンデプロイメント プロセス、および関連するプログラミング上の考慮事項については、「停止操作とアプリケーションのアンデプロイメント」を参照してください。
|
|
|