WebLogic Server のコンフィグレーションと管理
|
 |
 |
|
さまざまなイベントが、サーバ インスタンスの障害の原因となり得ます。1 つ障害が発生すると、それが原因で別の障害が発生することがよくあります。電力の損失、ハードウェアの誤作動、オペレーティング システムのクラッシュ、ネットワークの分割、およびアプリケーションの予期せぬ動作はすべて、サーバ インスタンスの障害の要因となります。
可用性の必要条件によっては、クラスタ アーキテクチャを実装して障害の影響を最小限に止めることができます。WebLogic Server クラスタのフェイルオーバについては、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタのフェイルオーバとレプリケーション」を参照してください。ただし、クラスタ環境であってもサーバ インスタンスは周期的に障害を起こすので、回復プロセスの用意をしておくことが必要です。
以下の節では、障害の発生したサーバ インスタンスの回復についての情報とその手順を説明します。
この節では、障害からの回復をサポートする WebLogic の機能について説明します。
WebLogic Server の自動状態モニタ機能は、ドメイン内のサーバ インスタンスの信頼性と可用性を向上させます。各 WebLogic Server インスタンス内の選択されたサブシステムは、そのサブシステムに固有の条件に基づいて自身の状態をモニタします。たとえば、JMS サブシステムは JMS スレッド プールの状態をモニタし、コア サーバ サブシステムはデフォルトおよびユーザ定義の実行キュー統計をモニタします。個々のサブシステムは、整合性および信頼性のある状態で動作できないと判断した場合、ホスト サーバに自己の状態を「障害」として登録します。
また、各 WebLogic Server インスタンスは登録されているサブシステムの状態をチェックして、全体的な有効性を調べます。1 つまたは複数の重要なサブシステムが FAILED 状態に達している場合、サーバ インスタンスは自己の状態を FAILED に設定して、アプリケーションを適切にホストできないことを示します。
ノード マネージャと一緒に使用すると、サーバ自動状態モニタでは障害が発生したサーバを自動的に再起動します。これにより、ドメインの全体的な信頼性が向上し、管理者の介入が不要になります。「ノード マネージャの機能」を参照してください。
ノード マネージャおよび自動再起動の動作をコンフィグレーションするには、「ノード マネージャのコンフィグレーション」を参照してください。
管理対象サーバは起動時に管理サーバにアクセスして、コンフィグレーション情報を取得しようとします。起動時に管理サーバにアクセスできない場合、管理対象サーバはコンフィグレーション ファイルおよびセキュリティ ファイルを直接読み込むことでコンフィグレーションを取得できます。この方法で起動した管理対象サーバは、「管理対象サーバ独立 (MSI) モード」で実行されます。デフォルトでは、MSI モードは有効です。MSI モードの無効化については、Administration Console オンライン ヘルプの「管理対象サーバの独立の無効化」を参照してください。
管理対象サーバ独立モードの管理対象サーバは、そのルート ディレクトリで以下のファイルを探します。
msi-config.xml - ドメインの config.xml のレプリカ。ドメインのコンフィグレーション ファイルが config.xml 以外の名前であっても、MSI モードの管理対象サーバは常に msi-config.xml という名前のコンフィグレーション ファイルを探します。SerializedSystemIni.dat boot.properties - ユーザ名とパスワードの暗号化バージョンが格納されているオプションのファイル。詳細については、Administration Console オンライン ヘルプの「起動 ID ファイル」を参照してください。デフォルトのサーバ インスタンスは、それがそのルート ディレクトリから起動されているものと判断します。サーバのルート ディレクトリの詳細については、「サーバのルート ディレクトリ」を参照してください。
「セキュリティ データのバックアップ」の説明どおりにコンフィグレーション データのレプリケーションを有効にし、管理サーバの実行時に少なくとも 1 度管理対象サーバを起動している場合は、msi-config.xml と SerializedSystemIni.dat がすでにサーバのルート ディレクトリにあります。boot.properties ファイルはレプリケートされません。管理サーバのルート ディレクトリにまだない場合は、作成する必要があります。詳細については、Administration Console オンライン ヘルプの「起動 ID ファイル」を参照してください。
msi-config.xml と SerializedSystemIni.dat がルート ディレクトリにない場合は、以下のいずれかを行います。
config.xml および SerializedSystemIni.dat をコピーする。次に、そのコンフィグレーション ファイルの名前を msi-config.xml に変更します。 path 起動オプションを使用して、これらのファイルが格納されているディレクトリを指定する。 各 WebLogic Server インスタンスは、そのローカル ログ ファイルとドメイン全体のログ ファイルにログ メッセージを書き込みます。ドメイン ログ ファイルは、ドメイン内のすべてのサーバのメッセージを表示できる一元的な場所を提供します。
通常、管理対象サーバはメッセージを管理サーバに転送して、管理サーバがそのメッセージをドメイン ログ ファイルに書き込みます。ただし、管理対象サーバが MSI モードで動作している場合は、その管理対象サーバがドメイン ログ ファイルに書き込みます。
デフォルトでは、ローカル ログ ファイルとドメイン ログ ファイルのパス名は管理対象サーバのルート ディレクトリを基準に相対的です。そのようなデフォルト設定で、管理対象サーバが管理サーバとルート ディレクトリを共有せずそれ専用のルート ディレクトリに配置されていて、かつ MSI モードで動作している場合、その管理対象サーバはそれ専用のドメイン ログ ファイルをそのルート ディレクトリに作成します。
管理対象サーバが管理サーバとルート ディレクトリを共有しているか、ドメイン ログの絶対パスを指定した場合、MSI モードの管理対象サーバは管理サーバが作成したドメイン ログ ファイルに書き込みを行います。
注意 : 管理対象サーバには、既存のファイルに書き込むパーミッションが必要です。管理サーバと管理対象サーバを別々のオペレーティング システム アカウントで実行する場合は、両方のユーザ アカウントが書き込みパーミッションを持つようにドメイン ログ ファイルのファイル パーミッションを修正する必要があります。
管理対象サーバは、セキュリティ レルムにアクセスできないと起動プロセスを完了できません。
WebLogic Server がインストールしたセキュリティ レルムを使用する場合、管理サーバはドメインのセキュリティ データを格納するために LDAP サーバを保持します。すべての管理対象サーバは、この LDAP サーバをレプリケートします。管理サーバに障害が発生した場合、MSI モードで動作する管理対象サーバはレプリケートした LDAP サーバをセキュリティ サービス用に使用します。
サード パーティのセキュリティ プロバイダを使用する場合、管理対象サーバはセキュリティ データにアクセスできなければ起動プロセスを完了できません。
サーバ用に SSL を設定した場合、各サーバには独自の証明書ファイル、キー ファイル、およびその他の SSL 関連ファイルのセットが必要になります。管理対象サーバは、SSL 関連ファイルを管理サーバから取得しません (ドメインのコンフィグレーション ファイルにサーバごとのこれらのファイルのパス名が格納されている場合でも)。MSI モードで起動した場合、SSL 関連ファイルがアクセスできるマシンに格納されていれば、それらのファイルをコピーまたは移動する必要はありません。
MSI モードで起動する管理対象サーバは、そのステージング ディレクトリ (serverroot/stage/appName) からアプリケーションをデプロイします。
MSI モードで管理対象サーバを起動する場合は、管理サーバとの通信が復元されるまでコンフィグレーションを変更できません。
ノード マネージャでは、サーバ インスタンスを MSI モードで起動できません (再起動のみ可能)。通常の起動では、ノード マネージャは管理サーバへのアクセスを必要とします。管理サーバにアクセスできない場合は、管理対象サーバのホスト マシンにログインして管理対象サーバを起動する必要があります。
管理対象サーバ独立モードには、必須のコンフィグレーション ファイルを管理対象サーバのルート ディレクトリに 5 分ごとにコピーするオプションが用意されています。このオプションでは、起動 ID ファイルはレプリケートされません。起動 ID ファイルの詳細については、Administration Console オンライン ヘルプの「起動 ID ファイル」を参照してください。
デフォルトでは、管理対象サーバはこれらのファイルをレプリケートしません。バックアップ方針、およびドメインのコンフィグレーションの更新頻度によっては、このオプションは大きいファイルをネットワーク上でコピーすることで生じるパフォーマンス コストに見合わない場合があります。
管理対象サーバがドメインのコンフィグレーション ファイルをレプリケートできるようにするには、Administration Console オンライン ヘルプの「管理対象サーバの独立に関するドメインのコンフィグレーション ファイルのレプリケート」を参照してください。
-Dweblogic.management.discover=true (デフォルト設定) の場合、管理サーバは起動時に動作している管理対象サーバの存在を検出します。
起動時に、管理サーバは running-managed-servers.xml ファイルの永続コピーを参照し、ファイルにリストされているすべての管理対象サーバにその存在を通知します。
管理サーバにアクセスできない状態のときに管理対象サーバ独立モードで起動した管理対象サーバは、running-managed-servers.xml にリストされません。管理サーバと管理対象サーバの接続を再確立するには、weblogic.Admin DISCOVERMANAGEDSERVER コマンドを使用します。『WebLogic Server コマンド リファレンス』の「DISCOVERMANAGEDSERVER」を参照してください。
管理サーバが起動して、MSI モードの管理対象サーバにアクセスすると、その管理対象サーバは MSI モードを非アクティブ化し、将来のコンフィグレーション変更通知に備えて管理サーバに登録します。
サーバ インスタンスの障害から回復するには、ドメインのコンフィグレーション データおよびセキュリティ データにアクセスする必要があります。この節では、WebLogic Server で自動的に実行されるファイルのバックアップ、および管理者が行うべき推奨のバックアップ手順について説明します。
デフォルトでは、管理サーバはドメインのコンフィグレーション データを domain_nameconfig.xml というファイルに格納します。ここで domain_name はドメインのルート ディレクトリです。
config.xml は、管理サーバの障害でオリジナルのコピーが利用できない場合に備えて安全な場所にバックアップします。管理サーバに障害が発生した場合は、バックアップ バージョンを別のマシンにコピーし、その新しいマシン上で管理サーバを再起動します。
デフォルトでは、管理サーバは domain-name/configArchive ディレクトリに config.xml を 5 バージョンまでアーカイブします。
ドメインのコンフィグレーションに対する変更を保存すると、管理サーバは前のコンフィグレーションを domain-name\configArchive\config.xml#n に保存します。管理サーバがファイルを configArchive ディレクトリに保存するたびに、#n サフィックスの値がインクリメントされます (コンフィグレーションされたコピー数まで。デフォルトは 5)。その後、ドメインのコンフィグレーションを変更するたびに、以下の処理が行われます。
MedRec ドメインで、MedRecServer によって現在使用されているコンフィグレーション ファイルは WL_HOME\samples\domains\medrec\config.xml です。Administration Console を使用してサーバ インスタンスを追加すると、[作成] ボタンをクリックした時点で、MedRecServer によって古い config.xml ファイルが WL_HOME\samples\domains\medrec\configArchive\config.xml#2 として保存されます。
新しいファイル WL_HOME\samples\domains\medrec\config.xml は、新しいサーバ インスタンスの追加された MedRec ドメインを表します。前のファイル WL_HOME\samples\domains\medrec\configArchive\config.xml#2 には、新しいサーバ インスタンスが作成される前の MedRec ドメイン コンフィグレーションが格納されています。
次にコンフィグレーションを変更すると、現在の config.xml ファイルが config.xml#3 として保存されます。ドメインに 4 回変更を加えた後は、configArchive ディレクトリには config.xml#2、config.xml#3、config.xml#4、および config.xml#5 という 4 つのファイルが格納されています。次にコンフィグレーションを変更すると、古い config.xml が config.xml#5 として保存されます。前の config.xml#5 は、config.xml#4 という名前に変更されます。古い config.xml#2 は削除されます。
ドメイン コンフィグレーションがアーカイブされるバージョン数をコンフィグレーションするには、次の手順に従います。
domain-nameconfigArchive のファイルの他に、管理サーバは起動プロセスのキー ポイントでドメインのコンフィグレーションをバックアップする以下の 2 つのファイルを作成します。
domain-name\config-file.xml.original - 管理サーバが解析してサブシステム データを追加する直前のコンフィグレーション ファイル。domain-name\config-file.xml.booted - 管理サーバが正常に起動した直後のコンフィグレーション ファイル。config.xml が破損した場合は、このファイルを使用して管理サーバを起動することができます。ドメインのコンフィグレーションが config.xml に格納されている場合、ドメインの管理サーバを起動したときに、その管理サーバは次のように動作します。
管理サーバは、解析および修正の行われた config.xml を使用します。ドメインのコンフィグレーションを更新すると、古い config.xml が domain-name\configArchive\MyConfig.xml#2 にコピーされます。
WebLogic Security サービスは、そのコンフィグレーション データを config.xml ファイルだけでなく、LDAP リポジトリや他のファイルにも格納します。
WebLogic Server と一緒にインストールされるデフォルトの認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、自身のデータを LDAP サーバに格納します。各 WebLogic Server には、組み込み LDAP サーバが存在します。管理サーバには、すべての管理対象サーバにレプリケートされるマスター LDAP サーバが存在します。これらのインストールされたプロバイダを使用するセキュリティ レルムが存在する場合は、次のディレクトリ ツリーの最新のバックアップを維持する必要があります。
domain_name はドメインのルート ディレクトリ、adminServer は管理サーバが実行時データやセキュリティ データを格納するディレクトリです。
各 WebLogic Server に LDAP ディレクトリがありますが、バックアップする必要があるのは管理サーバ上の LDAP データだけです。各管理対象サーバの LDAP データは、セキュリティ データが更新されたときにマスター LDAP サーバによってレプリケートされます。WebLogic セキュリティ プロバイダは、ドメインの管理サーバがアクセスできないときにはセキュリティ データを変更できません。管理対象サーバ上の LDAP リポジトリはレプリカであり、変更できません。
ldap/ldapfiles サブディレクトリには、LDAP サーバのデータ ファイルが格納されています。このディレクトリ内のファイルには、ユーザ、グループ、グループ メンバー、ポリシー、およびロール情報が格納されます。ldap ディレクトリの他のサブディレクトリには、LDAP サーバのメッセージ ログおよびレプリケートされた LDAP サーバのデータが格納されます。
セキュリティ プロバイダのコンフィグレーションは、LDAP データのバックアップが進行している間は更新しないでください。管理者がユーザを追加するなどの変更が、ldap ディレクトリ ツリーのバックアップ中に行われると、ldapfiles サブディレクトリのバックアップに矛盾が生じるおそれがあります。もしそれが起こると、「LDAP ファイルのバックアップ」で説明されているように、一貫性はあるが、バージョンの古い LDAP バックアップが用意されることになります。
1 日に一度、サーバは書き込み処理を中断して LDAP データの専用バックアップを作成します。このバックアップは ZIP ファイルで ldap\backup ディレクトリに格納され、書き込み処理が再開されます。このバックアップは整合性が確保されますが、最新のセキュリティ データが含まれていない場合があります。
LDAP バックアップのコンフィグレーションについては、Administration Console オンライン ヘルプの「組み込み LDAP サーバのバックアップのコンフィグレーション」を参照してください。
すべてのサーバは、SerializedSystemIni.dat という名前のファイルを作成し、サーバのルート ディレクトリに格納します。このファイルには、サーバの起動時に必要な暗号化されたセキュリティ データが格納されます。このファイルはバックアップが必要です。
サーバが SSL を使用する場合、セキュリティ証明書とキーもバックアップする必要があります。これらのファイルの場所はユーザがコンフィグレーションできます。
アプリケーション サービスを回復する手順は、アプリケーションの性質とユーザの要求によって決まります。特に、以下の要素が回復プロセスに影響します。
以降の節では、障害後に管理サーバを起動する方法について説明します。
障害の発生した管理サーバを再起動するときに、ドメイン内で管理対象サーバが動作していない場合は、特殊な手順は必要ありません。通常どおりに管理サーバを起動します。Administration Console オンライン ヘルプの「サーバの起動と停止」を参照してください。
管理対象サーバが動作を続けている状況で管理サーバがダウンした場合、ドメインの管理を回復するために、すでに動作している管理対象サーバを再起動する必要はありません。アクティブなドメインの管理を回復する手順は、管理サーバが起動したときと同じマシンで管理サーバを再起動できるかどうかによって異なります。
管理対象サーバが動作を続けている状況で WebLogic 管理サーバを再起動する場合、管理サーバでは動作している管理対象サーバの存在を検出できます。
注意 : 起動コマンドと起動スクリプトに -Dweblogic.management.discover=false が含まれていないことを確認してください。これが含まれていると、管理サーバは動作している管理対象サーバを検出できません。-Dweblogic.management.discover の詳細については、「weblogic.Server コマンドライン リファレンス」の「サーバ通信」を参照してください。
ドメインのルート ディレクトリには、ドメイン内の管理対象サーバのリストおよびそれらの管理対象サーバが動作しているのかどうかの情報が含まれるファイル running-managed-servers.xml があります。再起動した管理サーバは、このファイルをチェックして、どの管理対象サーバがその動作が停止する前に管理サーバの制御下にあったのかを確認します。
管理対象サーバが正常にまたは強制的に停止すると、running-managed-servers.xml のそのステータスが「not-running」に更新されます。管理サーバは、それが再起動したときに、「not-running」ステータスの管理対象サーバは検出しません。システムのクラッシュが原因で動作を停止する管理対象サーバ、あるいは JVM またはコマンド プロンプト (シェル) を強制終了することで停止された管理対象サーバのステータスは、running-managed-servers.xml で「running」とされています。管理サーバはそのような管理対象サーバの検出を試み、その管理対象サーバが停止していることを確認した時点で例外を送出します。
管理サーバを再起動しても、管理対象サーバは静的属性のコンフィグレーションを更新しません。静的属性とは、サーバがその起動プロセス中にのみ参照する属性です。静的なコンフィグレーション属性の変更を反映するためには、サーバ インスタンスを再起動する必要があります。管理対象サーバを検出した場合、管理サーバでは管理対象サーバをモニタするか、またはサーバの動作中にコンフィグレーションできる属性 (動的属性) の値を実行時に変更することしかできません。
マシンのクラッシュにより、同じマシンで管理サーバを再起動できない場合は、次のようにして動作している管理対象サーバの管理を回復できます。
起動コマンドと起動スクリプトに -Dweblogic.management.discover=false が含まれていないことを確認してください。これが含まれていると、管理サーバは動作している管理対象サーバを検出できません。-Dweblogic.management.discover の詳細については、「weblogic.Server コマンドライン リファレンス」の「サーバ通信」を参照してください。
管理サーバは、起動時に管理対象サーバと通信して、管理サーバが異なる IP アドレスで動作していることを通知します。
以降の節では、障害後に管理対象サーバを起動する方法について説明します。トランザクションおよび JMS に関連する回復の考慮事項については、「障害に関するその他のトピック」を参照してください。
障害の発生した管理対象サーバから管理サーバにアクセスできる場合は、以下のことを行えます。
起動時に管理サーバにアクセスできない場合、管理対象サーバはローカルにキャッシュされたコンフィグレーション データを読み込むことでコンフィグレーションを取得できます。この方法で起動した管理対象サーバは、「管理対象サーバ独立 (MSI) モード」で実行されます。MSI モードの説明、および管理対象サーバが MSI モードで起動するためにアクセスする必要のあるファイルについては、「管理対象サーバ独立モード」を参照してください。
注意 : 障害の発生した管理対象サーバが、障害の発生時に移行可能サービスのアクティブなサーバとして機能していた、クラスタ化されている管理対象サーバであった場合は、『WebLogic Server クラスタ ユーザーズ ガイド』の「現在アクティブなホストがない場合の移行」で説明されている手順を実行します。MSI モードで管理対象サーバを起動しないでください。
MSI モードで管理対象サーバを起動するには、次の手順に従います。
SerializedSystemIni.dat ファイルをコピーします。 注意 : -Dweblogic.RootDirectory=path 起動オプションを使用して、これらのファイルが格納されているルート ディレクトリを指定することもできます。
管理対象サーバは、管理サーバからアクセスされるまでは MSI モードで動作します。このシナリオでの管理サーバの再起動については、「管理対象サーバの動作中における管理サーバの再起動」を参照してください。
障害の発生したサーバ インスタンスからの JMS データの回復については、『WebLogic JMS プログラマーズ ガイド』の「JMS サーバの移行可能対象のコンフィグレーション」を参照してください。
障害後のトランザクションの回復については、Administration Console オンライン ヘルプの「別のマシンへのサーバの移動」および「サーバに障害が発生した後のトランザクションの回復」を参照してください。
|
|
|