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