4 サーバー障害の回避とサーバー障害からの回復
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モードは有効になっています。『Oracle WebLogic Server Administration Console オンラインヘルプ』の管理対象サーバーの独立の無効化に関する項を参照してください。
障害リカバリのためのディレクトリとファイルのバックアップ
バックアップは、既存のファイル、フォルダ、ディレクトリのコピーを作成してデータ損失の場合にそれらをリストアします。WebLogicサーバーが自動的に実行するバックアップはわずかで、管理者にも一部のバックアップ手順を実行するように促されます。これらの手順には、ドメイン構成ディレクトリ、LDAPリポジトリ、およびサーバー・アプリケーションに関連したその他のセキュリティ証明書が含まれます。
この項では、WebLogic Serverで自動的に実行されるファイルのバックアップ、および管理者が行うべき推奨のバックアップ手順について説明します。
サーバー・インスタンスの障害からリカバリするには、ドメインの構成データおよびセキュリティ・データにアクセスする必要があります。WebLogicセキュリティ・サービスは、その構成データをconfig.xml
ファイルのみでなく、LDAPリポジトリや他のファイルにも格納します。
Oracle WebLogic Server ドメイン構成の理解のドメイン構成ファイルを参照してください。
ドメインの構成ディレクトリのバックアップ
デフォルトでは、管理サーバーはドメインの構成データをdomain_name
\config
ディレクトリに格納します。domain_name
はドメインのルート・ディレクトリです。
config
ディレクトリは、管理サーバーの障害でオリジナルのコピーが使用できない場合に備えて安全な場所にバックアップします。管理サーバーに障害が発生した場合は、バックアップ・バージョンを別のマシンにコピーし、その新しいマシン上で管理サーバーを再起動します。
管理対象サーバーは起動するたびに管理サーバーにアクセスし、ドメイン構成に対して変更が行われている場合にはドメインのconfig
ディレクトリのローカル・コピーを更新します。
処理中にドメイン構成に対して変更が行われると、管理サーバーはローカルの/config
ディレクトリを更新する管理対象サーバーに通知を行います。そのため、各管理対象サーバーは常に構成データの最新のコピーをローカルにキャッシュします。
config
ディレクトリまたはサブディレクトリに構成されていないファイルを追加しないでください。構成されていないファイルには、ログ(.log)・ファイルおよびロック(.lck)・ファイルが含まれます。管理サーバーでは、すべての管理サーバー・インスタンスで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
ディレクトリに格納され、書込み処理が再開されます。このバックアップは一貫性が確保されますが、最新のセキュリティ・データが含まれていない場合があります。
『Oracle WebLogic Server Administration Console オンラインヘルプ』の組込みLDAPサーバーのバックアップの構成に関する項を参照してください。
WebLogic Serverの終了コードと障害後の再起動
サーバー・インスタンスが停止すると、終了コードが返されます。終了コードの値は、サーバー・プロセスが終了したときの状態に関する情報を示します。各サーバーの終了コードには重要な意味があり、特定の再起動に従うことをお薦めしています。
ノード・マネージャの制御下にあるサーバー・インスタンスが終了した場合、ノード・マネージャは終了コードからそのサーバー・インスタンスを再起動するかどうかを判断します。高可用性エージェントやスクリプトは、サーバーの終了コードから、サーバー・インスタンスの終了後に行うアクションを決定します。次の表にサーバーの終了コードの定義を示します。
表4-1 WebLogic Serverの終了コード
終了コードの値 | 意味 | 再起動の推奨 |
---|---|---|
0より小さい |
負の値は、状態の遷移中にサーバー・インスタンスに障害が発生し、安定した状態で終了しなかったたことを示します。 例: 構成が無効なサーバー・インスタンスに対してスタンバイ・モードで起動コマンドが発行されると、サーバー・インスタンスは遷移途中の |
サーバーを再起動しないでください。サーバー・プロセス終了の原因になった問題を診断します。 |
0 |
停止コマンド(正常な停止または強制停止)の結果としてサーバー・プロセスが正常に終了したことを示します。 |
なし。 |
0より大きい |
正の値は、サーバー・インスタンス自身が1つまたは複数のサブシステムが不安定になっていると判断して終了したことを示します。 例: メモリー不足状態やスタック・スレッドを検出してサーバー・インスタンスが自身を停止します。 |
サーバー・インスタンスは再起動できます。 |
障害の発生した管理サーバーの再起動
障害の発生した管理サーバーは、ノード・マネージャを使用するか、同じIPアドレスを共有する同一または異なるマシンに応じたリスニング・アドレスのシナリオを検討することで、再起動できます。
次の項では、障害後に管理サーバーを起動する方法について説明します。
ノート:
ノード・マネージャを使用すると、障害の発生した管理サーバーを自動的に再起動できます。『Oracle WebLogic Serverノード・マネージャの管理』の管理サーバーと管理対象サーバーの自動再起動に関する項を参照してください。
管理サーバーの再起動
サーバーの起動と停止を参照してください。
管理サーバーの再起動のシナリオ
表4-2 管理サーバーの再起動のシナリオ
リスニング・アドレスの定義 | 同じまたは異なるマシーンで同じIPアドレスの使用 | 異なるマシンで異なるIPアドレスの使用 |
---|---|---|
未定義 |
|
|
ホストのDNS名またはIPアドレス |
|
|
複数のホストにマップされたDNS名 |
|
|
管理対象サーバーと再起動された管理サーバー
管理サーバーが実行を停止して、そのドメインの管理対象サーバーは実行を続けた場合、各管理対象サーバーは、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での再接続の試みは停止されます。管理サーバーが再度停止したとき再接続しようとします。
障害の発生した管理対象サーバーの再起動
WebLogicサーバーには、管理サーバーのアクセス可能性に関係なく、障害の発生した管理対象サーバーを再起動する様々な方法が提供されています。管理対象サーバーがサーバー起動時に管理サーバーに接続できない場合、ローカルにキャッシュされた構成をconfigディレクトリから読み込むことで構成を取得できます。管理サーバーが障害の発生した管理対象サーバーからアクセス可能な場合、ノード・マネージャを使用して手動または自動で再起動するか、コマンド・スクリプトを使用して再起動できます。また、MSIモードで管理対象サーバーを再起動できます。
次の項では、障害後に管理対象サーバーを起動する方法について説明します。トランザクションおよびJMSに関連するリカバリの考慮事項については、「障害に関するその他のトピック」を参照してください。
管理サーバーにアクセスできる場合の管理対象サーバーの起動
障害の発生した管理対象サーバーから管理サーバーにアクセスできる場合は、次のことを行うことができます。
-
ノード・マネージャを使用して手動または自動で再起動します。この動作をサポートするように、ノード・マネージャと管理対象サーバーを構成する必要があります。『Oracle WebLogic Serverノード・マネージャの管理』の管理対象サーバーの起動、停止、一時停止、および再起動に関する項を参照してください。
-
コマンドまたはスクリプトを使用して手動で起動します。サーバーの起動と停止を参照してください。
管理サーバーにアクセスできない場合の管理対象サーバーの起動
起動時に管理サーバーにアクセスできない場合、管理対象サーバーはローカルにキャッシュされた構成データをconfig
ディレクトリから読み込むことで構成を取得できます。この方法で起動した管理対象サーバーは、「管理対象サーバー独立(MSI)モード」で実行されます。
管理対象サーバー独立モードの理解
管理対象サーバーは、起動時に管理サーバーと通信して、その構成情報を取得しようとします。起動時に管理サーバーにアクセスできない場合、管理対象サーバーは構成ファイルおよびセキュリティ・ファイルを直接読み込むことで構成を取得できます。この方法で起動した管理対象サーバーは、「管理対象サーバー独立(MSI)モード」で実行されます。デフォルトでは、MSIモードは有効になっています。MSIモードの無効化については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの独立の無効化に関する項を参照してください。
管理対象サーバー独立モードでは、管理対象サーバーは以下のことを行います。
-
ローカルの
config
ディレクトリでconfig.xml
(ドメインのconfig.xml
のレプリカ)を検索します。 -
自身の
security
ディレクトリでSerializedSystemIni.dat
とboot.properties
(ユーザー名とパスワードの暗号化バージョンが格納されているファイル)を検索します。「サーバーの起動と停止を行うためのユーザー資格証明の指定」を参照してください。
サーバーのドメイン・ディレクトリの前述の場所にconfig.xml
およびSerializedSystemIni.dat
がない場合は、管理サーバーのドメイン・ディレクトリからこれらのファイルをコピーできます。
MSIモードとセキュリティ・レルム
管理対象サーバーは、セキュリティ・レルムにアクセスできないと起動プロセスを完了できません。
WebLogic Serverがインストールしたセキュリティ・レルムを使用する場合、管理サーバーはドメインのセキュリティ・データを格納するためにLDAPサーバーを保持します。すべての管理対象サーバーは、このLDAPサーバーをレプリケートします。管理サーバーに障害が発生した場合、MSIモードで動作する管理対象サーバーはレプリケートしたLDAPサーバーをセキュリティ・サービス用に使用します。
サード・パーティのセキュリティ・プロバイダを使用する場合、管理対象サーバーはセキュリティ・データにアクセスできなければ起動プロセスを完了できません。
MSIモードとSSL
サーバー用にSSLを設定した場合、各サーバーには独自の証明書ファイル、キー・ファイル、およびその他のSSL関連ファイルのセットが必要になります。ドメインの構成ファイルにサーバーごとのこれらのファイルのパス名が格納されている場合でも、管理対象サーバーは、SSL関連ファイルを管理サーバーから取得しません。MSIモードで起動した場合、SSL関連ファイルがアクセスできるマシンに格納されていれば、それらのファイルをコピーまたは移動する必要はありません。
MSIモードとドメイン・ログ・ファイル
各WebLogic Serverインスタンスは、そのローカル・ログ・ファイルとドメイン全体のログ・ファイルにログ・メッセージを書き込みます。ドメイン・ログ・ファイルは、ドメイン内のすべてのサーバーのメッセージを表示できる一元的な場所を提供します。
通常、管理対象サーバーはメッセージを管理サーバーに転送して、管理サーバーがそのメッセージをドメイン・ログ・ファイルに書き込みます。ただし、MSIモードで動作している管理対象サーバーはそのローカル・サーバー・ログ・ファイルにメッセージを書込み続け、メッセージをドメイン・ログ・ファイルに転送しません。
『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のサーバー・インスタンスからドメイン・ログへのメッセージ転送の仕組みに関する項を参照してください。
MSIモードでの管理対象サーバーの起動
ノート:
障害の発生した管理対象サーバー・インスタンスが、障害の発生時に移行可能なサービスのアクティブなサーバーとして機能していた、クラスタリングされた管理対象サーバーであった場合は、『Oracle WebLogic Serverクラスタの管理』の現在アクティブなホストがない場合の移行に関する項で説明されているステップを実行します。MSIモードで管理対象サーバー・インスタンスを起動しないでください。
MSIモードで管理対象サーバーを起動するには:
障害に関するその他のトピック
サーバー障害とそのリカバリ処理については、その他の関連する障害トピックを参照してください。
障害の発生したサーバー・インスタンスからのJMSデータの回復の詳細は、『Oracle WebLogic Server JMSリソースの管理』のWebLogic JMSクラスタリングの構成に関する項を参照してください。
障害発生後のトランザクション回復の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のサーバーに障害が発生した後のトランザクションのリカバリに関する項を参照してください。
管理サーバーの起動を妨害する破損した、または使用不可能な組込みLDAPサーバー・ファイルからのリカバリの詳細は、『Oracle WebLogic Serverセキュリティの管理』のバックアップおよびリカバリに関する項を参照してください。