ドメインのコンフィグレーションについて
|
 |
 |
|
コンフィグレーションの変更をドメイン内に配布する安全で予測可能な手段を提供するため、WebLogic Server では、2 フェーズ コミット データベース トランザクションに少し似ている変更管理プロセスを導入しました。以下の節では、コンフィグレーションの変更管理について説明します。
ドメインのコンフィグレーションは、ファイル システム上では config.xml ファイルが中心となる一連の XML コンフィグレーション ファイルによって表現され、実行時にはコンフィグレーション MBean の階層によって表現されます。ドメイン コンフィグレーションを編集するときは、管理サーバ上にあるコンフィグレーション MBean の独立した階層を編集します。編集プロセスを開始するには、編集階層でロックを取得して、他のユーザが変更を行えないようにします。変更を完了したら、その変更を保存します。ただし、変更をアクティブ化してドメイン内のすべてのサーバ インスタンスに配布するまで、その変更は有効になりません。変更がアクティブ化されると、各サーバでは、その変更を適用できるかどうかを判断します。すべてのサーバが変更を適用できる場合は、各サーバが動作中のコンフィグレーション階層を更新して、変更が完了します。
WebLogic Server の変更管理プロセスは、ドメインとサーバ コンフィグレーション データの変更にのみ適用され、セキュリティやアプリケーションのデータには適用されません。
コンフィグレーションの変更には、実行中に有効にできるものもありますが、影響を受けるサーバを再起動しないと有効にならないものもあります。サーバの再起動なしで有効にできるコンフィグレーションの変更を「動的な」変更と呼び、サーバの再起動が必要なコンフィグレーションの変更を「動的でない」変更と呼ぶことがあります。Administration Console では、サーバを再起動しないと変更が有効にならない属性には、次のアイコンが付いています。
動的なコンフィグレーション属性の編集内容は、アクティブ化されると有効になります。その際、影響を受けるサーバやシステムの再起動は不要です。これらの変更はアクティブ化されると、サーバおよび実行時の階層で利用できるようになります。動的でないコンフィグレーション属性の編集内容は、影響を受けるサーバやシステム リソースを再起動しないと有効にはなりません。
動的でないコンフィグレーション設定を編集した場合、動的なコンフィグレーション設定に対する編集内容は再起動するまでは有効になりません。つまり、動的な属性と動的でない属性の編集を一度に行った場合、編集内容の一部分だけがアクティブ化されることはありません。
「WebLogic Server システム管理の概要」の「システム管理ツールおよび API の概要」で説明しているように、さまざまな WebLogic Server ツールを使用してコンフィグレーションを変更することができます。
どのツールを使用してコンフィグレーションを変更しても、WebLogic Server は基本的には同じように変更プロセスを処理します。
JMX とコンフィグレーション MBean によるコンフィグレーションの変更方法の詳細については、『JMX によるカスタム管理ユーティリティの開発』の「Understanding WebLogic Server MBeans」を参照してください。WLST によるコンフィグレーションの変更の詳細については、『WebLogic Scripting Tool ガイド』の「Editing Configuration MBeans」を参照してください。
WebLogic 監査プロバイダまたは他の監査セキュリティ プロバイダを使用して、WebLogic Server コンフィグレーションの変更に関する監査情報を記録できます。『WebLogic Server のセキュリティ』の「Configuration Auditing」を参照してください。
WebLogic Administration Console では、コンフィグレーションの変更管理プロセスを [チェンジ センタ] ペインに一元化しています。
Administration Console を使用してコンフィグレーションを変更する場合は、まず、チェンジ センタで [ロックして編集] ボタンをクリックする必要があります。[ロックして編集] をクリックすると、ドメイン内のすべてのサーバのコンフィグレーション MBean の編集可能な階層 (編集ツリー) 上でロックを取得することになります。
Administration Console を使用してコンフィグレーションを変更したら、該当するページで [保存] (または [完了]) をクリックします。この操作を行っても、変更はすぐに有効にはなりません。代わりに、[保存] をクリックすると、変更内容が編集ツリーと、DOMAIN_NAME/pending/config.xml ファイルおよび関連するコンフィグレーション ファイルに保存されます。チェンジ センタで [変更のアクティブ化] をクリックしたときに、変更が有効になります。その時点で、コンフィグレーションの変更はドメイン内の各サーバに配布されます。各サーバに変更が適用可能な場合、その変更内容は有効になります (ただし、サーバの再起動が必要な変更もあります)。変更を受け入れないサーバがあった場合は、ドメイン内のすべてのサーバからすべての変更がロールバックされます。その変更は保留中の状態に置かれます。保留中の変更は、編集して問題を解決するか、元に戻すことができます。
コンフィグレーションの変更は、どの JMX ツール (Administration Console、WLST、または JMX API) を使用する場合でも、基本的に同じように行われます。以下の手順では、ドメインの管理サーバを起動するところから、プロセスを詳細に説明します。
config.xml ファイルと、config.xml ファイルによって参照される補助コンフィグレーション ファイル) を読み込み、そのデータを使用して、以下の MBean ツリーをメモリ内でインスタンス化します。注意 : 管理サーバは、実行時 MBean ツリーと DomainRuntime MBean ツリーもインスタンス化しますが、これらはコンフィグレーションの管理には使用されません。
pending という名前のディレクトリで、別のコンフィグレーション ファイルのセットとして保存します。図 4-2 を参照してください。pending ディレクトリはドメインのルート ディレクトリのすぐ下にあります。たとえば、ドメインの名前が mydomain である場合、保留中の config.xml ファイルのデフォルトのパス名は mydomain/pending/config.xml になります。
図 4-2 管理サーバの保留中の config.xml ファイル
activate コマンド、または ConfigurationManagerMBean の activate オペレーションを使用して、変更内容をドメイン内でアクティブ化します。変更をアクティブ化すると、次のことが行われます (図 4-3 を参照)。
pending ディレクトリに、保留中のコンフィグレーション ファイルをコピーします。 管理対象サーバが管理サーバとルート ディレクトリを共有している場合、ConfigurationManagerMBean は保留中のコンフィグレーション ファイルをコピーしません。つまり、管理対象サーバは管理サーバの保留中ファイルを使用します。
いずれかのサブシステムが変更を使用できないと表明した場合、アクティブ化プロセス全体がロールバックされ、ConfigurationManagerMBean は例外を送出します。変更内容を修正して変更のアクティブ化を再試行するか、または、ロックを解放できます。ロックを解放した場合、編集用のコンフィグレーション MBean ツリーと保留中のコンフィグレーション ファイルは、読み込み専用のコンフィグレーション MBean ツリーとコンフィグレーション ファイルの状態に戻ります。
Administration Console、WLST、管理 API のどれを使用する場合でも、編集セッションを開始するときに、コンフィグレーション MBean の編集ツリー上でロックを取得します。
コンフィグレーションの変更をロックしただけでは、同じ管理者ユーザ アカウントによるコンフィグレーションの編集の衝突を防ぐことはできません。たとえば Administration Console を使用してコンフィグレーションの変更のロックを取得した後に、同じユーザ アカウントで WebLogic Scripting Tool を使用した場合、Administration Console で開始したのと同じ編集セッションにアクセスすることになり、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 サーバの詳細については、『JMX によるカスタム管理ユーティリティの開発』の「Deprecated MBeanHome and Type-Safe Interfaces」を参照してください。
複数の変更をアクティブ化せずに保存しているときに、一部の変更によって前の変更が無効になるような場合、コンフィグレーション マネージャ サービスは、変更を保存する前に、手動で無効の部分を解決するように要求します。
コンフィグレーション マネージャ サービスでは、図 4-4 に示した一連の状態をたどります。
ドメインを読み込み専用に設定することで、コンフィグレーションの変更からブロックすることができます。それには、WLST または管理 API を使用して、JMXMBean コンフィグレーション MBean の EditMBeanServerEnabled 属性を false に設定します。
ドメインを読み込み専用に設定すると、Administration Console、WLST オンライン、または管理 API を使用して、そのコンフィグレーションを変更できなくなります。ドメインを再び編集可能にするには、config.xml ファイルをテキスト エディタで直接編集するか、WLST オンラインを使用した後で、影響を受けるサーバを再起動します。
また、ドメインのコンフィグレーションに対する適切なアクセス制御を確立して、適切なセキュリティ ロールを持つユーザのみにアクセスを制限してください。WebLogic 監査プロバイダまたは他の監査セキュリティ プロバイダを使用して、WebLogic Server コンフィグレーションの変更に関する監査情報を記録することもできます。『WebLogic Server のセキュリティ』の「Configuration Auditing」を参照してください。
|
|
|
