さまざまなイベントが、サーバ インスタンスの障害の原因となり得ます。1 つ障害が発生すると、それが原因で別の障害が発生することがよくあります。電力の損失、ハードウェアの誤作動、オペレーティング システムのクラッシュ、ネットワークの分割、およびアプリケーションの予期しない動作はすべて、サーバ インスタンスの障害の要因となります。
高可用性が必要とされる場合は、クラスタ アーキテクチャを実装して障害の影響を最小限に抑えることができます (WebLogic Server クラスタのフェイルオーバの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタのフェイルオーバとレプリケーション」を参照)。ただし、クラスタ環境であってもサーバ インスタンスは周期的に障害を起こす可能性があるので、回復プロセスの用意をしておくことが必要です。
以下の節では、障害の発生したサーバ インスタンスの回復に関する情報とその手順について説明します。
WebLogic Server には、サーバ障害からの回復やサーバ障害の回避を支援するいくつかの機能が用意されています。
WebLogic Server では、アプリケーションのパフォーマンスと安定性に影響するシステム負荷の増加を検出できます。これにより管理者は、あらかじめ定義された負荷のしきい値に達すると自動的に実行される障害回避アクションをコンフィグレーションできます。
過負荷保護機能は、予期しないレベルのアプリケーション トラフィックやリソース使用率が原因で発生する障害の回避に役立ちます。
WebLogic Server では、以下の一定の条件が満たされると障害の回避が試みられます。
ワーク マネージャの容量を超過したとき
HTTP セッション数があらかじめ指定されたしきい値まで増加したとき
メモリ不足状態が発生しそうなとき
アプリケーションを WebLogic Server クラスタでホストすることにより、アプリケーションの信頼性と可用性を向上させることができます。EJB や Web アプリケーションなどのクラスタ化可能なサービスは、クラスタ内の各管理対象サーバに均等にデプロイできます。その結果、サービスがデプロイされている 1 つのサーバ インスタンスで障害が発生しても、そのサービスはサービスを中断することもステートを失うこともなくクラスタ内の別のサーバにフェイルオーバされます。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタのフェイルオーバとレプリケーション」を参照してください。
WebLogic Server の自動状態モニタ機能は、ドメイン内のサーバ インスタンスの信頼性と可用性を向上させます。各 WebLogic Server インスタンス内の選択されたサブシステムは、そのサブシステムに固有の条件に基づいて自身の状態をモニタします。たとえば、JMS サブシステムは JMS スレッド プールの状態をモニタし、コア サーバ サブシステムはデフォルトおよびユーザ定義の実行キュー統計をモニタします。個々のサブシステムは、一貫性および信頼性のある状態で動作できないと判断した場合、ホスト サーバに自身の状態を「障害」として登録します。
また、各 WebLogic Server インスタンスは登録されているサブシステムの状態をチェックして、全体的な有効性を判断します。1 つまたは複数の重要なサブシステムが FAILED
状態に達している場合、サーバ インスタンスは自身の状態を FAILED
に設定して、アプリケーションを適切にホストできないことを示します。
サーバ自動状態モニタでは、ノード マネージャを使用して、障害の発生したサーバを自動的に再起動できます。これにより、ドメインの全体的な信頼性が向上し、管理者の介入が不要になります。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』の「ノード マネージャとシステム クラッシュの回復」を参照してください。
WebLogic Server には、クラスタ化されたサーバ インスタンスを移行する機能が用意されています。移行できるようにコンフィグレーションされているクラスタ化されたサーバは、障害が発生した場合には管理者からのコマンドで、または自動的に、あるマシンから別のマシンにそのまま全部移動できます。移行プロセスにより、そのサーバ インスタンスで実行中のサービスはすべて別のマシンで利用可能になりますが、障害の発生時に実行されていたシングルトン サービスのステート情報は利用できません。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サーバ全体の移行」を参照してください。
WebLogic Server では、前の節で説明したサーバ レベルの移行機能だけでなく、個々のシングルトン サービスの移行もサポートされています。シングルトン サービスとは、クラスタ内で実行されるものの、常にクラスタ内の 1 つのインスタンス上のみで実行されなければならないサービス (JMS や JTA トランザクション回復システムなど) のことです。
管理者は、JMS サーバや JTA トランザクション回復サービスをクラスタ内のサーバ インスタンス間で移行できます。これは、サーバ インスタンスの障害への対応として、あるいは定期的な保守の一環として行います。この機能により、ホストのサーバで障害が発生した場合に代理のサーバ上でサービスを速やかに再開できるため、クラスタ内の固定サービスの可用性が向上します。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行」を参照してください。
管理対象サーバはドメイン コンフィグレーションのローカル コピーを保持します。起動時に管理サーバに接続することで、その管理対象サーバの最後の停止以降にドメイン コンフィグレーションに対して行われた変更を取得します。起動時に管理サーバにアクセスできない場合、管理対象サーバはローカルにキャッシュされたコンフィグレーション情報を使用できます。これは、その管理対象サーバが最後に停止した時点のコンフィグレーションです。管理サーバにアクセスしてコンフィグレーションの更新をチェックせずに起動した管理対象サーバは、管理対象サーバ独立 (MSI) モードで実行されます。デフォルトでは、MSI モードは有効になっています。MSI モードの無効化の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「管理対象サーバ独立の無効化」を参照してください。
サーバ インスタンスの障害から回復するには、ドメインのコンフィグレーション データおよびセキュリティ データにアクセスする必要があります。この節では、WebLogic Server で自動的に実行されるファイルのバックアップ、および管理者が行うべき推奨のバックアップ手順について説明します。
サーバ インスタンスの障害から回復するには、ドメインのコンフィグレーション データおよびセキュリティ データにアクセスする必要があります。WebLogic Security サービスは、そのコンフィグレーション データを config.xml
ファイルだけでなく、LDAP リポジトリや他のファイルにも格納します。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ドメインのコンフィグレーションについて』の「ドメイン コンフィグレーション ファイル」を参照してください。
デフォルトでは、管理サーバはドメインのコンフィグレーション データを domain_name
\config
ディレクトリに格納します。domain_name
はドメインのルート ディレクトリです。
config
ディレクトリは、管理サーバの障害でオリジナルのコピーが利用できない場合に備えて安全な場所にバックアップします。管理サーバに障害が発生した場合は、バックアップ バージョンを別のマシンにコピーし、その新しいマシン上で管理サーバを再起動します。
管理対象サーバは起動するたびに管理サーバにアクセスし、ドメイン コンフィグレーションに対して変更が行われている場合にはドメインの config
ディレクトリのローカル コピーを更新します。
処理中にドメイン コンフィグレーションに対して変更が行われると、管理サーバはローカルの /config
ディレクトリを更新する管理対象サーバに通知を行います。そのため、各管理対象サーバは常にコンフィグレーション データの最新のコピーをローカルにキャッシュします。
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 Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「組み込み LDAP サーバのバックアップのコンフィグレーション」を参照してください。
サーバ インスタンスが停止すると、終了コードが返されます。終了コードの値は、サーバ プロセスが終了したときの状態に関する情報を示します。ノード マネージャの制御下にあるサーバ インスタンスが終了した場合、ノード マネージャは終了コードからそのサーバ インスタンスを再起動するかどうかを判断します。高可用性エージェントやスクリプトは、サーバの終了コードから、サーバ インスタンスの終了後に行うアクションを決定します。次の表にサーバの終了コードの定義を示します。
表 4-1 WebLogic Server の終了コード
終了コードの値 | 意味 | 再起動の推奨 |
---|---|---|
ゼロより小さい場合 |
負の値は、状態の遷移中にサーバ インスタンスに障害が発生し、安定した状態で終了しなかったたことを示す。 例 : コンフィグレーションが無効なサーバ インスタンスに対してスタンバイ モードで起動コマンドが発行されると、サーバ インスタンスは遷移途中の |
サーバを再起動しないこと。サーバ プロセス終了の原因になった問題を診断する。 |
0 |
停止コマンド (正常な停止または強制停止) の結果としてサーバ プロセスが正常に終了したことを示す。 |
なし。 |
ゼロより大きい場合 |
正の値は、サーバ インスタンス自身が 1 つまたは複数のサブシステムが不安定になっていると判断して終了したことを示す。 例 : メモリ不足状態やスタック スレッドを検出してサーバ インスタンスが自身を停止する。 |
サーバ インスタンスは再起動できる。 |
以降の節では、障害後に管理サーバを起動する方法について説明します。
注意 : ノード マネージャを使用すると、障害の発生した管理サーバを自動的に再起動できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』の「ノード マネージャの概要」の「管理サーバおよび管理対象サーバの再起動」を参照してください。 |
「サーバの起動と停止」を参照してください。
表 4-2 管理サーバの再起動のシナリオ
リスン アドレスの定義 | 管理サーバの再起動 - 同マシン | 管理サーバの再起動 - 別マシン |
---|---|---|
未定義 |
|
|
ホストの DNS 名または IP アドレス |
|
|
複数のホストにマップされた DNS 名 |
|
|
マシンのクラッシュにより、同じマシンで管理サーバを再起動できない場合は、次のようにして実行中の管理対象サーバの管理を回復できます。
新しい管理マシンで WebLogic Server ソフトウェアをインストールします (インストールされていない場合)。
アプリケーション ファイルをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバがこれらのファイルを使用できるようにします。新しいファイル システム上でのアプリケーション ファイルの相対位置は、元の管理サーバのファイル システムと同じにする必要があります。
コンフィグレーション データとセキュリティ データをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバがこれらのデータを使用できるようにします。詳細については、「障害回復のためのディレクトリとファイルのバックアップ」を参照してください。
新しいマシンで管理サーバを再起動します。
以降の節では、障害後に管理対象サーバを起動する方法について説明します。トランザクションおよび JMS に関連する回復の考慮事項については、「障害に関するその他のトピック」を参照してください。
障害の発生した管理対象サーバから管理サーバにアクセスできる場合は、以下のことを行えます。
ノード マネージャを使用して手動または自動で再起動する。この動作をサポートするように、ノード マネージャと管理対象サーバをコンフィグレーションする必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ノード マネージャ管理者ガイド』の「管理対象サーバの起動、停止、中断、および再起動」を参照してください。
コマンドまたはスクリプトを使用して手動で起動する。手順については、「サーバの起動と停止」を参照してください。
起動時に管理サーバにアクセスできない場合、管理対象サーバはローカルにキャッシュされたコンフィグレーション データを config
ディレクトリから読み込むことでコンフィグレーションを取得できます。この方法で起動した管理対象サーバは、「管理対象サーバ独立 (MSI) モード」で実行されます。
管理対象サーバは、起動時に管理サーバと通信して、そのコンフィグレーション情報を取得しようとします。起動時に管理サーバにアクセスできない場合、管理対象サーバはコンフィグレーション ファイルおよびセキュリティ ファイルを直接読み込むことでコンフィグレーションを取得できます。このような方法で起動された管理対象サーバは、「管理対象サーバ独立 (Managed Server Independence : MSI) モード」で実行されます。デフォルトでは、MSI モードは有効になっています。MSI モードの無効化の詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「管理対象サーバ独立の無効化」を参照してください。
管理対象サーバ独立モードでは、管理対象サーバは以下のことを行います。
ローカルの config
ディレクトリで config.xml
(ドメインの config.xml
のレプリカ) を検索する。
自身の security
ディレクトリで SerializedSystemIni.dat
と boot.properties
(ユーザ名とパスワードの暗号化バージョンが格納されているファイル) を検索する。詳細については、「サーバの起動と停止を行うユーザ資格の指定」を参照してください。
サーバのドメイン ディレクトリの上記の場所に config.xml
および SerializedSystemIni.dat
がない場合は、管理サーバのドメイン ディレクトリからこれらのファイルをコピーできます。
ノード マネージャでは、サーバ インスタンスを MSI モードで起動できません (再起動のみ可能)。通常の起動では、ノード マネージャは管理サーバへのアクセスを必要とします。管理サーバにアクセスできない場合は、管理対象サーバのホスト マシンにログインして管理対象サーバを起動する必要があります。
管理対象サーバは、セキュリティ レルムにアクセスできないと起動プロセスを完了できません。
WebLogic Server がインストールしたセキュリティ レルムを使用する場合、管理サーバはドメインのセキュリティ データを格納するために LDAP サーバを保持します。すべての管理対象サーバは、この LDAP サーバをレプリケートします。管理サーバに障害が発生した場合、MSI モードで動作する管理対象サーバはレプリケートした LDAP サーバをセキュリティ サービス用に使用します。
サード パーティのセキュリティ プロバイダを使用する場合、管理対象サーバはセキュリティ データにアクセスできなければ起動プロセスを完了できません。
サーバ用に SSL を設定した場合、各サーバには独自の証明書ファイル、キー ファイル、およびその他の SSL 関連ファイルのセットが必要になります。ドメインのコンフィグレーション ファイルにサーバごとのこれらのファイルのパス名が格納されている場合でも、管理対象サーバは、SSL 関連ファイルを管理サーバから取得しません。MSI モードで起動した場合、SSL 関連ファイルがアクセスできるマシンに格納されていれば、それらのファイルをコピーまたは移動する必要はありません。
各 WebLogic Server インスタンスは、そのローカル ログ ファイルとドメイン全体のログ ファイルにログ メッセージを書き込みます。ドメイン ログ ファイルは、ドメイン内のすべてのサーバのメッセージを表示できる一元的な場所を提供します。
通常、管理対象サーバはメッセージを管理サーバに転送して、管理サーバがそのメッセージをドメイン ログ ファイルに書き込みます。ただし、MSI モードで動作している管理対象サーバはそのローカル サーバ ログ ファイルにメッセージを書き込み続け、メッセージをドメイン ログ ファイルに転送しません。
詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』の「サーバ インスタンスからドメイン ログへのメッセージ転送の仕組み」を参照してください。
注意 : 障害の発生した管理対象サーバが、障害の発生時に移行可能なサービスのアクティブなサーバとして機能していた、クラスタ化された管理対象サーバであった場合は、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「現在アクティブなホストがない場合の移行」で説明されている手順を実行します。MSI モードで管理対象サーバを起動しないでください。 |
MSI モードで管理対象サーバを起動するには、次の手順に従います。
管理対象サーバのルート ディレクトリに config
サブディレクトリがあることを確認します。
config
ディレクトリがない場合は、管理サーバのルート ディレクトリ (またはバックアップ) から管理対象サーバのルート ディレクトリにコピーします。
注意 : -Dweblogic.RootDirectory =path 起動オプションを使用して、これらのファイルが格納されているルート ディレクトリを指定することもできます。 |
コマンドラインまたはスクリプトで管理対象サーバを起動します。
管理対象サーバは、管理サーバからアクセスされるまでは MSI モードで動作します。このシナリオでの管理サーバの再起動については、「障害の発生した管理サーバの再起動」を参照してください。
障害の発生したサーバ インスタンスからの JMS データの回復については、『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』の「WebLogic JMS クラスタ化のコンフィグレーション」を参照してください。
障害発生後のトランザクションの回復の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「サーバに障害が発生した後のトランザクションの回復」を参照してください。