| Oracle® Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理 12c (12.1.2) E48062-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理 12c (12.1.2) E48062-01 |
|
前 |
次 |
この章では、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ディレクトリを更新する管理対象サーバーに通知を行います。そのため、各管理対象サーバーは常に構成データの最新のコピーをローカルにキャッシュします。
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サーバーのバックアップの構成に関する項を参照してください。
サーバー・インスタンスが停止すると、終了コードが返されます。終了コードの値は、サーバー・プロセスが終了したときの状態に関する情報を示します。ノード・マネージャの制御下にあるサーバー・インスタンスが終了した場合、ノード・マネージャは終了コードからそのサーバー・インスタンスを再起動するかどうかを判断します。高可用性エージェントやスクリプトは、サーバーの終了コードから、サーバー・インスタンスの終了後に行うアクションを決定します。次の表にサーバーの終了コードの定義を示します。
表4-1 WebLogic Serverの終了コード
| 終了コードの値 | 意味 | 再起動の推奨 |
|---|---|---|
|
0より小さい |
負の値は、状態の遷移中にサーバー・インスタンスに障害が発生し、安定した状態で終了しなかったたことを示します。 例: 構成が無効なサーバー・インスタンスに対してスタンバイ・モードで起動コマンドが発行されると、サーバー・インスタンスは遷移途中の |
サーバーを再起動しないでください。サーバー・プロセス終了の原因になった問題を診断します。 |
|
0 |
停止コマンド(正常な停止または強制停止)の結果としてサーバー・プロセスが正常に終了したことを示します。 |
なし。 |
|
0より大きい |
正の値は、サーバー・インスタンス自身が1つまたは複数のサブシステムが不安定になっていると判断して終了したことを示します。 例: メモリー不足状態やスタック・スレッドを検出してサーバー・インスタンスが自身を停止します。 |
サーバー・インスタンスは再起動できます。 |
次の項では、障害後に管理サーバーを起動する方法について説明します。
|
注意: ノード・マネージャを使用すると、障害の発生した管理サーバーを自動的に再起動できます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』の「ノード・マネージャの概要」の管理サーバーと管理対象サーバーの再起動に関する項を参照してください。 |
第2章「サーバーの起動と停止」を参照してください。
表4-2 管理サーバーの再起動のシナリオ
| リスニング・アドレスの定義 | 同じまたは異なるマシーンで同じIPアドレスの使用 | 異なるマシンで異なるIPアドレスの使用 |
|---|---|---|
|
未定義 |
|
|
|
ホストのDNS名またはIPアドレス |
|
|
|
複数のホストにマップされたDNS名 |
|
|
マシンのクラッシュにより、同じマシンで管理サーバーを再起動できない場合は、次のようにして実行中の管理対象サーバーの管理を回復できます。
新しい管理マシンでWebLogic Serverソフトウェアをインストールします(インストールされていない場合)。
アプリケーション・ファイルをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバーがこれらのファイルを使用できるようにします。新しいファイル・システム上でのアプリケーション・ファイルの相対位置は、元の管理サーバーのファイル・システムと同じにする必要があります。
構成およびセキュリティ・データをバックアップからコピーするか、または共有ディスクを使用して、新しい管理サーバーがこれらのファイルを使用できるようにします。詳細は、障害リカバリのためのディレクトリとファイルのバックアップを参照してください。
新しいホスト・マシンのIPアドレスでconfig.xmlを更新します。リスニング・アドレスを空白に設定した場合、これを変更する必要がありません。例:
<server> <name>AdminServer</name> ... <listen-address></listen-address> </server>
config.xmlを手動で編集できます。または、WLSTオフラインを使用して、リスニング・アドレスを更新します。
新しいマシンで管理サーバーを再起動します。
管理サーバーが実行を停止して、そのドメインの管理対象サーバーは実行を続けた場合、各管理対象サーバーは、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モードで起動できません(再起動のみ可能)。通常の起動では、ノード・マネージャは管理サーバーへのアクセスを必要とします。管理サーバーにアクセスできない場合は、管理対象サーバーのホスト・マシンにログインして管理対象サーバーを起動する必要があります。
管理対象サーバーは、セキュリティ・レルムにアクセスできないと起動プロセスを完了できません。
WebLogic Serverがインストールしたセキュリティ・レルムを使用する場合、管理サーバーはドメインのセキュリティ・データを格納するためにLDAPサーバーを保持します。すべての管理対象サーバーは、このLDAPサーバーをレプリケートします。管理サーバーに障害が発生した場合、MSIモードで動作する管理対象サーバーはレプリケートしたLDAPサーバーをセキュリティ・サービス用に使用します。
サード・パーティのセキュリティ・プロバイダを使用する場合、管理対象サーバーはセキュリティ・データにアクセスできなければ起動プロセスを完了できません。
サーバー用にSSLを設定した場合、各サーバーには独自の証明書ファイル、キー・ファイル、およびその他のSSL関連ファイルのセットが必要になります。ドメインの構成ファイルにサーバーごとのこれらのファイルのパス名が格納されている場合でも、管理対象サーバーは、SSL関連ファイルを管理サーバーから取得しません。MSIモードで起動した場合、SSL関連ファイルがアクセスできるマシンに格納されていれば、それらのファイルをコピーまたは移動する必要はありません。
各WebLogic Serverインスタンスは、そのローカル・ログ・ファイルとドメイン全体のログ・ファイルにログ・メッセージを書き込みます。ドメイン・ログ・ファイルは、ドメイン内のすべてのサーバーのメッセージを表示できる一元的な場所を提供します。
通常、管理対象サーバーはメッセージを管理サーバーに転送して、管理サーバーがそのメッセージをドメイン・ログ・ファイルに書き込みます。ただし、MSIモードで動作している管理対象サーバーはそのローカル・サーバー・ログ・ファイルにメッセージを書込み続け、メッセージをドメイン・ログ・ファイルに転送しません。
詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のサーバー・インスタンスからドメイン・ログへのメッセージ転送の仕組みを参照してください。
|
注意: 障害の発生した管理対象サーバーが、障害の発生時に移行可能なサービスのアクティブなサーバーとして機能していた、クラスタリングされた管理対象サーバーであった場合は、『Oracle WebLogic Serverクラスタの管理』の現在アクティブなホストがない場合の移行に関する項で説明されている手順を実行します。MSIモードで管理対象サーバーを起動しないでください。 |
MSIモードで管理対象サーバーを起動するには:
管理対象サーバーのルート・ディレクトリにconfigサブディレクトリがあることを確認します。
configディレクトリがない場合は、管理サーバーのルート・ディレクトリ(またはバックアップ)から管理対象サーバーのルート・ディレクトリにコピーします。
|
注意:
|
コマンド・ラインまたはスクリプトで管理対象サーバーを起動します。方法については、第2章「サーバーの起動と停止」を参照してください。
管理対象サーバーは、管理サーバーからアクセスされるまではMSIモードで動作します。このシナリオでの管理サーバーの再起動については、「障害の発生した管理サーバーの再起動」を参照してください。
障害の発生したサーバー・インスタンスからのJMSデータの回復の詳細は、『Oracle WebLogic Server JMSリソースの管理』のWebLogic JMSクラスタリングの構成に関する項を参照してください。
障害発生後のトランザクション回復の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のサーバー障害発生後のトランザクション回復に関する項を参照してください。
管理サーバーの起動を妨害する破損した、または使用不可能な組込みLDAPサーバー・ファイルからのリカバリの詳細は、『Oracle WebLogic Serverセキュリティの管理』の「組込みLDAPサーバーの管理」のバックアップとリカバリに関する項を参照してください。
