| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server ドメイン管理 > 障害が発生したサーバの回復 |
|
WebLogic Server ドメイン管理
|
ドメイン内の障害が発生した WebLogic Server インスタンスは、いくつかの方法を用いて回復できます。これらすべての方法では、ドメインのコンフィグレーション データとセキュリティ データをバックアップしておく必要があります。
管理サーバは、自身のコンフィグレーション ファイルを使用してドメインを管理します。このため、管理サーバが障害によって使用不能になった場合に備えて、アーカイブ コピーを保存しておくことをお勧めします。アーカイブを作成するには、定期バックアップ、フォールト トレラント ディスク、変更時の手動によるファイルのコピーなど、一般的な方法を使用できます。管理サーバに障害が発生した場合は、バックアップ ファイルを新しいマシンにコピーして、そのマシン上で管理サーバを再起動します。
デフォルトでは、管理サーバはドメインのコンフィグレーション データを domain_name¥config.xml というファイルに格納します。ここで domain_name はドメインのルート ディレクトリです。Administration Console、weblogic.Admin コマンド、または JMX API のいずれかを使用してドメイン内のサーバに対して行ったコンフィグレーションの変更の多くは、config.xml ファイルに保持されます。たとえば、WebLogic Server インスタンスをコンフィグレーションする MBean は、自身のデータを config.xml に保持します。
注意: サーバを起動するときには、異なるコンフィグレーション ファイルを使用してそのサーバをコンフィグレーションできます。詳細については、『管理者ガイド』の「weblogic.Server コマンドの使用」を参照してください。
管理サーバがその起動シーケンスを正常に完了し、要求を処理する準備が整うと、管理サーバは自身のコンフィグレーション ファイルを次のファイルに保存します。
config.xml と config.xml.booted のバックアップ コピーを作成しておくことをお勧めします。特定のセッション中に行ったコンフィグレーションの変更を元に戻す必要がある場合、config.xml.booted に定義されているコンフィグレーションに戻すことができます。
また、1 つまたは複数の管理対象サーバをコンフィグレーションして、ドメインのコンフィグレーション データの一部をレプリケートすることもできます。この章のドメインのコンフィグレーション ファイルのレプリケートでは、このレプリケーションの設定について説明します。
管理サーバは、ドメインのセキュリティ データを管理する役割を果たします。このため、管理サーバに障害が発生した場合に備えて、そのセキュリティ データをアーカイブしておくことをお勧めします。管理サーバが使用不能になった場合、セキュリティ データを変更することはできません。
使用するセキュリティ プロバイダごとに、WebLogic Security フレームワークは管理 Bean (MBean) を起動してプロバイダのコンフィグレーションを管理します。コンフィグレーションをサーバ セッション間で保持するために、ドメインは domain_name¥userConfig¥Security というディレクトリに MBean リポジトリを作成します。サーバを起動すると、サーバはこのリポジトリのデータを使用して実行時キャッシュを作成します。管理サーバは、キャッシュ内のデータに基づいて userConfig¥Security ディレクトリを定期的に更新します。また、サーバを停止するときにも MBean リポジトリが更新されます。
次のいずれかの方法を使用して、セキュリティ MBean リポジトリ (バイナリ フォーマット) をバックアップできます。
次の節では、XML ファイルを使用してセキュリティ データをバックアップおよびデバッグする方法について説明します。
セキュリティ コンフィグレーション データの XML ファイルへのダンプ
WebLogicMBeanDumper ユーティリティは、domain_name¥userConfig 内のデータを読み込んで XML ファイルを出力します。このユーティリティは MBean リポジトリ内のデータを使用するので、サーバを起動しなくても WebLogicMBeanDumper を使用できます。
すべてのセキュリティ プロバイダ MBean のデータをダンプするには、次の手順に従います。
WL_HOME¥server¥bin¥setWLSEnv.cmd (Windows の場合)
WL_HOME/server/bin/setWLSEnv.sh (UNIX の場合)
詳細については、『管理者ガイド』の「クラスパスの設定」を参照してください。
リスト4-1 に、セキュリティ MBean データが格納された出力ファイルの一部を示します。XML フォーマットは次のとおりです。
コード リスト 4-1 XML フォーマットのセキュリティ MBean インスタンス
<?xml version="1.0" encoding="UTF-8"?>
<MBeans>
<SetMBean
DisplayName="DefaultRoleMapper"
ObjectName="Security:Name=myrealmDefaultRoleMapper"
Type="weblogic.management.security.providers.authorization.DefaultRoleMap
per"
>
<Attributes Realm="Security:Name=myrealm">
<Defaulted AttributeNames="RoleDeploymentEnabled"/>
</Attributes>
</SetMBean>
...
</MBeans>
ダンプした XML ファイルに対しては、次の変更を加えることができます。
次の節で説明するように修正済み XML ファイルをロードする場合、WebLogicMBeanLoader ユーティリティはこのファイル内のデータに基づいてリポジトリを再生成します。
ドメインの MBean リポジトリ内のデータを WebLogicMBeanDumper で生成した XML ファイルに置き換えるには、次の手順に従います。
WL_HOME¥server¥bin¥setWLSEnv.cmd (Windows の場合)
WL_HOME/server/bin/setWLSEnv.sh (UNIX の場合)
詳細については、『管理者ガイド』の「クラスパスの設定」を参照してください。
ドメイン内のすべてのセキュリティ MBean を再生成して WebLogic Server によってインストールされたコンフィグレーションに戻す場合、次の手順に従います。
管理サーバは、デフォルト値を持つインストールされたセキュリティ プロバイダを使用する新しいセキュリティ MBean リポジトリを生成します。このインストールされたコンフィグレーションを持つサーバにログオンするには、ドメインの作成時に指定した管理ユーザ名を入力する必要があります。詳細については、『管理者ガイド』の「初期管理ユーザ名の指定」を参照してください。
WebLogic Server と一緒にインストールされるデフォルトの認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、自身のデータを LDAP サーバに格納します。各 WebLogic Server には、組み込み LDAP サーバが存在します。管理サーバには、すべての管理対象サーバにレプリケートされるマスター LDAP サーバが存在します。これらのインストールされたプロバイダを使用するセキュリティ レルムが存在する場合、次のディレクトリ ツリーをバックアップすることをお勧めします。
ここで domain_name はドメインのルート ディレクトリで、adminServer は管理サーバが実行時データやセキュリティ データなどを格納するために生成するディレクトリです。各 WebLogic Server はこのディレクトリを生成しますが、バックアップが必要なのは管理サーバ上の LDAP データだけです。
たとえば、セキュリティ レルムは WebLogic Server と一緒にインストールされるデフォルト認証プロバイダを使用します。管理サーバの名前が myAdminServer、ドメインの名前が myDomain の場合、次のディレクトリ ツリーをバックアップします。
ldap ディレクトリの下の ldapfiles サブディレクトリには、LDAP サーバのデータ ファイルが格納されています。このディレクトリ内のデータ ファイルには、ユーザ、グループ、グループ メンバー、ポリシー、およびロール情報が格納されます。ldap ディレクトリの他のサブディレクトリには、LDAP サーバのメッセージ ログなどの情報およびレプリケートされる LDAP サーバに関するデータが格納されます。
ldap ディレクトリ ツリーのバックアップ中に自分または他人がいずれかのセキュリティ プロバイダのデータを変更した場合、ldapfiles サブディレクトリ内のファイルのバックアップが不整合な状態になる可能性があります。たとえば、誰かがインストールされたデフォルト認証プロバイダを使用してユーザを追加しようとする場合、その作業の開始時から終了時の間にバックアップが開始される場合もあります。
1 日に一度、サーバは書き込み処理を中断して LDAP データの専用バックアップを作成します。このバックアップは ZIP ファイルで ldap¥backup ディレクトリに格納され、書き込み処理が再開されます。このバックアップは整合性が保証されますが、最新のセキュリティ データが含まれていない場合があります。
この LDAP バックアップのコンフィグレーションについては、Administration Console オンライン ヘルプの「組み込み LDAP サーバのバックアップのコンフィグレーション」を参照してください。
管理対象サーバの LDAP データをバックアップする必要はありません。マスター LDAP サーバは、自身に更新が行われると各管理対象サーバの LDAP をレプリケートします。ドメインの管理サーバが使用不能になると、WebLogic セキュリティ プロバイダはセキュリティ データを変更できません (管理対象サーバの LDAP リポジトリは複製であるため変更できません)。
SerializedSystemIni.dat およびセキュリティ証明書のバックアップ
すべてのサーバは、SerializedSystemIni.dat という名前のファイルを作成し、サーバのルート ディレクトリに格納します。このファイルには、サーバの起動時に必要な暗号化されたセキュリティ データが格納されます。このファイルはバックアップが必要です。
サーバが SSL を使用する場合、セキュリティ証明書とキーもバックアップする必要があります。これらのファイルの場所はユーザがコンフィグレーションできます。
管理対象サーバが動作を続けている状況で管理サーバがダウンした場合、ドメインの管理を回復するために、すでに動作している管理対象サーバを再起動する必要はありません。アクティブなドメインの管理を回復する手順は、管理サーバが起動したときと同じマシンで管理サーバを再起動できるかどうかによって異なります。
管理対象サーバが動作を続けている状況で WebLogic 管理サーバを再起動する場合、管理サーバでは動作している管理対象サーバの存在を検出できます。
注意: 起動コマンドと起動スクリプトに -Dweblogic.management.discover=false が含まれていないことを確認してください。これが含まれていると、管理サーバは動作している管理対象サーバを検出できません。-Dweblogic.management.discover の詳細については、『管理者ガイド』の「よく使用される任意指定の引数」を参照してください。
ドメインのルート ディレクトリには、running-managed-servers.xml というファイルが含まれています。このファイルは、管理サーバが認識している管理対象サーバのリストです。管理サーバの起動時に、管理サーバはこのリストを使用して動作している管理対象サーバの存在をチェックします。
管理サーバを再起動しても、管理対象サーバは静的属性のコンフィグレーションを更新しません。静的属性とは、サーバがその起動プロセス中にのみ参照する属性です。静的なコンフィグレーション属性の変更を反映するためには、WebLogic Server を再起動する必要があります。管理対象サーバを検出した場合、管理サーバでは管理対象サーバをモニタするか、またはサーバの動作中にコンフィグレーションできる属性 (動的属性) の値を実行時に変更することしかできません。
マシンのクラッシュにより、同じマシンで管理サーバを再起動できない場合は、次のようにして動作している管理対象サーバの管理を回復できます。
注意: 起動コマンドと起動スクリプトに -Dweblogic.management.discover=false が含まれていないことを確認してください。これが含まれていると、管理サーバは動作している管理対象サーバを検出できません。-Dweblogic.management.discover の詳細については、『管理者ガイド』の「よく使用される任意指定の引数」を参照してください。
管理サーバは、起動時に管理対象サーバと通信して、管理サーバが異なる IP アドレスで動作していることを通知します。
通常、管理対象サーバは起動時に管理サーバとやり取りしてそのコンフィグレーション情報を取得します。起動時に管理対象サーバが指定された管理サーバに接続できない場合、コンフィグレーション ファイルおよびその他のファイルを直接読み込むことによって自身のコンフィグレーションを取得できます。
このような方法で起動する管理対象サーバは、管理対象サーバ独立モードで動作します。このモードでは、サーバはキャッシュされたアプリケーション ファイルを使用して、そのサーバに割り当てられているアプリケーションをデプロイします。管理サーバとの通信が回復するまで、管理対象サーバのコンフィグレーションを変更することはできません。
管理対象サーバ独立モードが有効になっており (サーバのデフォルト設定)、管理対象サーバの起動時に管理サーバが使用不能の場合、管理対象サーバは自身のルート ディレクトリから次のファイルを検索します。
デフォルトでは、サーバはそのルート ディレクトリがサーバ起動コマンドを発行するディレクトリだと見なします。
管理サーバと同じドメインおよび同じマシンで動作する場合、管理対象サーバはデフォルトで管理サーバとルート ディレクトリを共有します。このような管理対象サーバを起動した場合、管理対象サーバはコンフィグレーション ファイルを自動的に発見します。
管理対象サーバが管理サーバとそのルート ディレクトリを共有しない場合は、以下のいずれかが可能です。
注意: サーバ用に SSL を設定した場合、各サーバには独自の証明書ファイル、キー ファイル、およびその他の SSL 関連ファイルのセットが必要になります。管理対象サーバは、SSL 関連ファイルを管理サーバから取得しません (ドメインのコンフィグレーション ファイルにサーバごとのこれらのファイルのパス名が格納されている場合でも)。管理対象サーバ独立モードで起動した場合、SSL 関連ファイルがアクセスできるマシンに格納されていれば、それらのファイルをコピーまたは移動する必要はありません。
ノード マネージャを使用してサーバを管理対象サーバ独立モードで起動することはできません。ノード マネージャを使用する場合、管理サーバが存在する必要があります。管理サーバが使用不能の場合、ローカル ホストにログオンして管理対象サーバを起動する必要があります。ノード マネージャの詳細については、ノード マネージャによるサーバの可用性の管理を参照してください。
デフォルトのサーバ インスタンスは、そのインスタンスの起動元のディレクトリがそのルート ディレクトリであると判断します。 サーバのルート ディレクトリの詳細については、「サーバのルート ディレクトリ」を参照してください。
コンフィグレーション データのレプリケーションを有効にした場合で (ドメインのコンフィグレーション ファイルのレプリケートを参照)、かつ管理サーバの動作中に少なくとも 1 度管理対象サーバを起動した場合は、msi-config.xml と SerializedSystemIni.dat がすでにサーバのルート ディレクトリに存在します。 boot.properties ファイルはレプリケートされません。 まだ管理対象サーバのルート ディレクトリにない場合は、作成する必要があります。 詳細については、『管理者ガイド』の「ユーザ名とパスワードのプロンプトの回避」を参照してください。
msi-config.xml と SerializedSystemIni.dat がルート ディレクトリにない場合は、以下のいずれかを行うことができます。
WebLogic Server の各インスタンスは、ログ メッセージをそのローカル ログ ファイルとドメイン全体のログ ファイルに書き込みます。 ドメイン ログ ファイルからは、ドメイン内のすべてのサーバのメッセージを表示できます。
通常、管理対象サーバはメッセージを管理サーバに転送し、管理サーバはそのメッセージをドメイン ログ ファイルに書き込みます。 ただし、管理対象サーバの動作モードが MSI モードである場合は、管理対象サーバが直にドメイン ログ ファイルに書き込みます。
デフォルトでは、ローカル ログ ファイルとドメイン ログ ファイルのパス名は、管理対象サーバのルート ディレクトリを基準とした相対パスです。 それらのデフォルト設定を使用し、管理対象サーバがそのルート ディレクトリに配置されていて、かつ管理サーバとルート ディレクトリを共有していない場合、MSI モードで動作する管理対象サーバはそれ専用のドメイン ログ ファイルをそのルート ディレクトリに作成します。
管理対象サーバが管理サーバとルート ディレクトリを共有しているか、ドメイン ログの絶対パス名が指定された場合、MSI モードの管理対象サーバは管理サーバが作成したドメイン ログ ファイルに書き込みを行います。
注意: 管理対象サーバには、その既存のファイルに書き込むためのパーミッションが必要です。 管理サーバと管理対象サーバを異なるオペレーティング システム アカウントで実行する場合は、両方のユーザ アカウントが書き込みパーミッションを持つようにドメイン ログ ファイルのファイル パーミッションを変更する必要があります。
コンフィグレーション ファイルに加え、サーバはセキュリティ レルムにアクセスしなければ起動プロセスを完了できません。
WebLogic Server がインストールしたセキュリティ レルムを使用する場合、管理サーバはドメインのセキュリティ データを格納するために LDAP サーバを保持します。すべての管理対象サーバは、この LDAP サーバをレプリケートします。管理サーバに障害が発生した場合、管理対象サーバ独立モードで動作する管理対象サーバはレプリケートした LDAP サーバをセキュリティ サービス用に使用できます。
サード パーティのセキュリティ プロバイダを使用する場合、管理対象サーバはセキュリティ データにアクセスできなければ起動プロセスを完了できません。
管理対象サーバ独立モードには、必須のコンフィグレーション ファイルを管理サーバのルート ディレクトリから管理対象サーバのルート ディレクトリに 5 分ごとにコピーするオプションが用意されています。バックアップ方針、およびドメインのコンフィグレーションの更新頻度によっては、このオプションは大きいファイルをネットワーク上でコピーすることで生じるパフォーマンス コストに見合わない場合があります。
この機能を利用するには、その前に必ず必要な環境を初期化する必要があります。
警告: 別のサーバとインストレーションまたはルート ディレクトリを共有するサーバに対してはファイルのレプリケーションを有効にしないでください。両方のサーバで予測できないエラーが発生する可能性があります。
Administration Console オンライン ヘルプの「ドメインのコンフィグレーション ファイルのレプリケート」を参照してください。
管理対象サーバが管理サーバにアクセスしてコンフィグレーション ファイルをそのルート ディレクトリにコピーした後、その管理対象サーバでは管理対象サーバ独立モードで起動するときにそのコピーを使用することができます。
このオプションでは、起動 ID ファイルはレプリケートされません。 起動 ID ファイルの詳細については、『管理者ガイド』の「ユーザ名とパスワードのプロンプトの回避」を参照してください。
-Dweblogic.management.discover=true (デフォルト設定) の場合、管理サーバは起動時に動作している管理対象サーバの存在を検出します。起動時に、管理サーバは running-managed-servers.xml ファイルの永続コピーを参照し、すべての管理対象サーバにその存在を通知します。管理対象サーバが管理対象サーバ独立モードで動作している場合、管理対象サーバはこの自己管理モードを非アクティブ化し、新しいコンフィグレーション変更通知を受け取るために管理サーバに自身を登録します。
このシナリオでの管理サーバの再起動については、管理対象サーバの動作中における管理サーバの再起動を参照してください。
デフォルトでは、管理対象サーバ独立モードは有効になっています。このモードの無効化については、Administration Console オンライン ヘルプの「管理対象サーバの独立の無効化」を参照してください。
WebLogic Server 7.0 には、ドメイン内のサーバの信頼性と可用性を向上させるための自動状態モニタ機能が用意されています。各 WebLogic Server 内の選択されたサブシステムは、そのサブシステムに固有の条件に基づいて自身の状態をモニタします。たとえば、JMS サブシステムは JMS スレッド プールの状態をモニタし、コア サーバ サブシステムはデフォルトおよびユーザ定義の実行キュー統計をモニタします。個々のサブシステムは、整合性および信頼性のある状態で動作できないと判断した場合、ホスト サーバに自己の状態を「障害」として登録します。
また、各 WebLogic Server は登録されているすべてのサブシステムの状態をチェックして、サーバの全体的な有効性を調べます。1 つまたは複数の重要なサブシステムが FAILED 状態に達していることを発見した場合、サーバは自己の状態を FAILED に設定して、アプリケーションを適切にホストできないことを示します。
ノード マネージャ アプリケーションと一緒に使用すると、サーバ自動状態モニタでは障害が発生したサーバを自動的に再起動します。これにより、ドメインの全体的な信頼性が向上し、管理者の介入が不要になります。詳細については、ノード マネージャによるサーバの可用性の管理を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
