ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverドメイン構成の理解
11gリリース1 (10.3.6)
B55525-04
  目次へ移動
目次

前
 
 

4 構成の変更の管理

構成の変更をドメイン内に配布する安全で予測可能な手段を提供するため、Oracle WebLogic Serverでは、2フェーズ・コミット・データベース・トランザクションに少し似ている変更管理プロセスを導入しました。次の節では、構成の変更管理について説明します。

変更管理の概要

各ドメインの構成は、ドメインの構成ディレクトリに格納されているXMLドキュメントに記述されます。実行時には、ドメイン内の各Oracle WebLogic Serverインスタンスが、このドキュメントに記述された構成のインメモリー表現を作成します。ドメインの構成のインメモリー表現とは、構成MBeanと呼ばれる読取り専用の管理対象Bean (MBean)のセットです。

管理サーバーは、読取り専用の構成MBeanに加え、編集可能な複数の構成MBeanも保持します(図4-0を参照)。これらの構成MBeanを編集するには、JMXクライアント(管理コンソール、WLST、または作成したクライアント)を使用してロックを取得する必要があります。

編集可能な構成MBeanのロックを保持している間は、インメモリーの変更を保存できます。保存した変更は、管理サーバーによってドメイン・ディレクトリ内の保留中の構成ドキュメントに書き込まれます。Oracle WebLogic Serverインスタンスは、それらの変更がアクティブ化されるまで変更を消費しません。

変更をアクティブ化すると、ドメイン内の各サーバーが、その変更を適用できるかどうかを判断します。すべてのサーバーが変更を適用できる場合は、ドメインの構成ドキュメントのコピーが更新されます。その後、構成MBeanの作業用コピーが更新されて変更が完了します(図4-3を参照)。

Oracle WebLogic Serverの変更管理プロセスは、ドメインおよびサーバーの構成データの変更に対して適用されます。セキュリティまたはアプリケーション・データには適用されません。

サーバーの再起動が必要な変更

構成の変更には、実行中に有効にできるものもありますが、影響を受けるサーバーを再起動しないと有効にならないものもあります。サーバーを再起動せずに有効にできる構成の変更を「動的な」変更と呼び、サーバーの再起動が必要な構成の変更を「動的でない」変更と呼ぶことがあります。管理コンソールでは、変更の有効化にサーバーの再起動が必要な属性には次のアイコンが付いています。

「サーバーの再起動が必要」アイコン
図nondynchange.gifの説明

動的な構成属性の編集内容は、アクティブ化されると有効になります。その際、影響を受けるサーバーやシステム・リソースの再起動は不要です。動的でない構成属性の編集内容は、影響を受けるサーバーやシステム・リソースを再起動しないと有効にはなりません。

動的でない構成設定を編集した場合、動的な構成設定に対する編集内容は再起動するまでは有効になりません。つまり、動的な属性と動的でない属性の編集を一度に行った場合、編集内容の一部分だけがアクティブ化されることはありません。

構成変更ツール

『Oracle Fusion Middleware Oracle WebLogic Serverの紹介』の「システム管理ツールおよびAPIの概要」で説明しているように、様々なOracle WebLogic Serverツールを使用して構成を変更できます。

  • 管理コンソール

  • WebLogic Scripting Tool

  • JMX API

どのツールを使用して構成を変更しても、Oracle WebLogic Serverは基本的には同じように変更プロセスを処理します。

JMXと構成MBeanによる構成の変更方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「WebLogic Server MBeanについて」を参照してください。WLSTによる構成の変更の詳細は、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』の「既存ドメインの構成」を参照してください。

構成監査

WebLogic監査プロバイダまたは他の監査セキュリティ・プロバイダを使用して、Oracle WebLogic Server構成の変更に関する監査情報を記録できます。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の「構成監査の有効化」を参照してください。

管理コンソールでの変更管理

WebLogic Server 管理コンソールでは、構成の変更管理プロセスを「チェンジ・センター」ペインに一元化しています。

図4-1 チェンジ・センター

図4-1の説明が続きます
「図4-1 チェンジ・センター」の説明

管理コンソールを使用して構成を変更する場合は、まず、チェンジ・センターで「ロックして編集」ボタンをクリックする必要があります。「ロックして編集」をクリックすると、ドメイン(編集ツリー)内のすべてのサーバーの編集可能な構成MBeanのセットをまとめてロックすることになります。


注意:

ドメイン構成ロック機能は、プロダクション・ドメインでは常に有効になっています。開発ドメインでは有効にしたり無効にしたりできます。また、新しい開発ドメインを作成するときは、デフォルトで無効になっています。Oracle Fusion Middleware Oracle WebLogic Serverの管理コンソール・オンライン・ヘルプの「ドメイン構成ロックの有効化と無効化」を参照してください。

管理コンソールを使用して構成を変更したら、該当するページで「保存」をクリックします。この操作を行っても、変更はすぐに有効にはなりません。かわりに、「保存」をクリックすると、変更内容が編集ツリーと、DOMAIN_NAME/pending/config.xmlファイルおよび関連する構成ファイルに保存されます。変更は、「チェンジ・センター」の「変更のアクティブ化」をクリックしたときに有効になります。構成の変更は、この時にドメイン内の各サーバーに配信されます。各サーバーに変更が適用可能な場合、その変更内容は有効になります。(ただし、サーバーの再起動が必要な変更もあります。)変更を受け入れないサーバーがあった場合は、ドメイン内のすべてのサーバーからすべての変更がロールバックされます。変更は保留状態になり、その状態の変更を編集して問題を解決するか、元の状態に戻すかのどちらかを選択できます。

開発ドメインの場合、管理コンソールには、自動アクティブ化モデルがあります。「変更のアクティブ化」をクリックするかわりに、保存時に変更が自動的にアクティブ化されます。これは開発ドメインのデフォルトの動作で、本番ドメインで有効化できません。「ロックを自動取得して変更をアクティブ化」コンソール・プリファレンス・オプションの選択を解除して、この動作を無効化できます。

構成の変更管理のプロセス

構成の変更は、どのJMXツール(管理コンソール、WLST、またはJMX API)を使用する場合でも、基本的に同じように行われます。以下の手順では、ドメインの管理サーバーを起動するところから、プロセスを詳細に説明します。

  1. 管理サーバーは起動時に、ドメインの構成ファイル(config.xmlファイルと、config.xmlファイルによって参照される補助構成ファイル)を読み込み、そのデータを使用して、次のMBeanツリーをメモリー内でインスタンス化します。

    • 管理サーバー上にあるリソースの現在の構成を含む構成MBeanの読取り専用のツリー。

    • ドメイン内のすべてのサーバーのすべての構成MBeanの編集可能なツリー。


      注意:

      管理サーバーは、実行時MBeanツリーとDomainRuntime MBeanツリーもインスタンス化しますが、これらは構成の管理には使用されません。

  2. 構成の変更を始めるには、次の手順に従います。

    1. 現在の構成でロックを取得します。

    2. 任意のツール(管理コンソール、WLST、JMX APIなど)を使用して、必要な変更を行います。

    3. 管理コンソールの「保存」ボタン、WLST saveコマンド、またはConfigurationManagerMBeansave操作を使用して、config.xmlファイルの保留中バージョンに変更を保存します。

  3. 構成マネージャ・サービスは、編集MBeanツリーのすべてのデータを、pendingという名前のディレクトリで、別の構成ファイルのセットとして保存します。図4-2を参照してください。

    pendingディレクトリはドメインのルート・ディレクトリのすぐ下にあります。たとえば、ドメインの名前がmydomainである場合、保留中のconfig.xmlファイルのデフォルトのパス名はmydomain/pending/config.xmlになります。

    図4-2 管理サーバーの保留中のconfig.xmlファイル

    図4-2の説明が続きます
    「図4-2 管理サーバーの保留中のconfig.xmlファイル」の説明

  4. さらに変更を行うか、行った変更を取り消します。

  5. 変更が済んだら、管理コンソールのチェンジ・センターにある「変更のアクティブ化」ボタン、WLST activateコマンド、またはConfigurationManagerMBeanactivate操作を使用して、変更内容をドメイン内でアクティブ化します。

    変更をアクティブ化すると、次のことが行われます(図4-3を参照)。

    1. 構成マネージャ・サービスは、ドメイン内の各サーバー・インスタンスで、サーバーのルート・ディレクトリ内のconfigディレクトリに、保留中の構成ファイルをコピーします。

      管理対象サーバーが管理サーバーとルート・ディレクトリを共有している場合、ConfigurationManagerMBeanは保留中の構成ファイルをコピーしません。つまり、管理対象サーバーは管理サーバーのconfigディレクトリを使用します。

    2. 各サーバー・インスタンスは、現在の構成と保留中の構成を比較します。

    3. 各サーバー内のサブシステムは、新しい構成を使用できるかどうかを表明します。

      いずれかのサブシステムが変更を使用できないと表明した場合、アクティブ化プロセス全体がロールバックされ、ConfigurationManagerMBeanは例外を送出します。変更内容を修正して変更のアクティブ化を再試行するか、または、ロックを解放できます。ロックを解放した場合、編集用の構成MBeanツリーと保留中の構成ファイルは、読取り専用の構成MBeanツリーと構成ファイルの状態に戻ります。

    4. すべてのサーバーのすべてのサブシステムで変更内容を使用できる場合、構成マネージャ・サービスは、ドメイン内の各サーバー・インスタンスにある読取り専用の構成ファイルを、保留中の構成ファイルで置き換えます。

    5. 各サーバー・インスタンスは、各Beanと読取り専用の構成MBeanツリーを、新しい構成ファイルの変更内容に従って更新します。サーバーの再起動が必要な変更が1つまたは複数ある場合、この処理はサーバーの再起動時に行われます。

    6. 保留中の構成ファイルは、pendingディレクトリから削除されます。


      注意:

      変更のアクティブ化が完了する(ステップf)前に管理サーバーがクラッシュした場合、ステップaで保存された保留中の構成ファイルは、再起動時に管理サーバーで回復されます。ログ・ファイルでは、このプロセスはconfig recoveryと表示されます。

  6. 正常なアクティブ化では、終了時にロックが自動的に解放されます。さらに変更を加える場合、ロックを新たに取得する必要があります。

    アクティブ化が失敗した場合、ロックは保持されます。タイムアウト期間を構成して、構成マネージャ・サービスにロックを解放させることができます。

図4-3 管理対象サーバーでの変更のアクティブ化

図4-3の説明が続きます
「図4-3 管理対象サーバーでの変更のアクティブ化」の説明

構成ロック

管理コンソール、WLST、管理APIのどれを使用する場合でも、編集セッションを開始するときに、構成MBeanの編集ツリー上でロックを取得します。

構成の変更をロックしただけでは、同じ管理者ユーザー・アカウントによる構成の編集の衝突を防ぐことはできません。たとえば管理コンソールを使用して構成の変更のロックを取得した後に、同じユーザー・アカウントでWebLogic Scripting Toolを使用した場合、管理コンソールで開始したのと同じ編集セッションにアクセスすることになり、WebLogic Scripting Toolでの変更操作はロック・アウトされません。管理を行う各スタッフに別々の管理者ユーザー・アカウントを持たせることで、このような状況が発生するリスクを減らすことができます。それでも、同じユーザー・アカウントを使用する同じスクリプトの複数のインスタンスがある場合は、同様の問題が起きる可能性があります。

このような状況のリスクをさらに減らすために、「排他的な」構成変更ロックを取得することができます。排他的な構成ロックを取得した場合、それ以降に同じ所有者が編集セッションの開始を試行すると、その試行は、編集セッションのロックが解放されるまで待機させられます。WLSTを使用して排他的な構成ロックを取得するには、startEditコマンドで排他的引数としてtrueを使用します。

wls:/mydomain/edit> startEdit(60000, 120000, true)

管理APIを使用して排他的な構成ロックを取得するには、ConfigurationMBean.startEdit操作の排他的パラメータでtrueを使用します。

Object [] startEdit(60000, 120000, true)

次のいずれかに該当する場合は、互換性MBeanサーバーを使用してドメイン構成を変更することはできません。

  • 既存の編集セッションがあるか、または

  • 以前の編集セッションの、保留中の変更が保存されていますが、まだアクティブ化されていません。

非推奨になったweblogic.management.MBeanHomeインタフェースで使用される互換性MBeanサーバーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「非推奨になったMBeanHomeおよび型保障インタフェース」を参照してください。

変更の衝突の解決

複数の変更をアクティブ化せずに保存しているときに、一部の変更によって前の変更が無効になるような場合、構成マネージャ・サービスは、変更を保存する前に、手動で無効の部分を解決するように要求します。

構成管理の状態図

構成マネージャ・サービスでは、図4-4に示した一連の状態をたどります。

図4-4 構成管理の状態図

図4-4の説明が続きます
「図4-4 構成管理の状態図」の説明

構成の変更の制限

ドメインを読取り専用に設定することで、構成の変更からブロックすることができます。それには、WLSTまたは管理APIを使用して、JMXMBean構成MBeanのEditMBeanServerEnabled属性をfalseに設定します。

ドメインを読取り専用に設定すると、管理コンソール、WLSTオンライン、または管理APIを使用して、その構成を変更できなくなります。ドメインを再び編集可能にするには、config.xmlファイルをテキスト・エディタで直接編集するか、WLSTオフラインを使用した後で、影響を受けるサーバーを再起動します。

また、ドメインの構成に対する適切なアクセス制御を確立して、適切なセキュリティ・ロールを持つユーザーのみにアクセスを制限してください。WebLogic監査プロバイダまたは他の監査セキュリティ・プロバイダを使用して、Oracle WebLogic Server構成の変更に関する監査情報を記録することもできます。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の「構成監査の有効化」を参照してください。